New TSPI classes for geometries and addresses in DDMS 5.0

Description

(Imported from Google Code)

  • New element, tspiolygon

  • New element, tspioint

  • New element, tspi:Envelope

  • New element, tspi:Circle

  • New element, tspi:Ellipse

  • New element, tspi:NumberedThoroughfareAddress

  • New element, tspi:UnnumberedThoroughfareAddress

  • New element, tspi:IntersectionAddress

  • New element, tspi:TwoNumberAddressRange

  • New element, tspi:LandmarkAddress

  • New element, tspi:USPSPostalDeliveryBox

  • New element, tspi:USPSPostalDeliveryRoute

  • New element, tspi:USPSGeneralDeliveryOffice

  • New element, tspi:GeneralAddressClass

Activity

Show:
Brian Uri
April 4, 2013, 7:37 AM

########################################

  1.  

    1.  

      1. Initial Cut at TSPI Shape Change ###
        ########################################

  1.  

    1.  

      1. Assumptions ###

  • It is unclear what the benefit of implementing every detail of the addr spec would be. Start off by creating 1 class per shape with the ability to spit out the raw XML. Then add sample code that can convert the classic DDMS address into an addr: address, since that will likely be the most supported use case.

  1.  

    1.  

      1. Modifications to Existing Classes ###

  • buri.ddmsence.ddms.summary.PostalAddress: Add new address types.

  1.  

    1.  

      1. New Classes ###

  • buri.ddmsence.AbstractTspiAddress
    String getXml()
    String getAction()

  • buri.ddmsence.summary.tspi.NumberedThoroughfareAddress

  • buri.ddmsence.summary.tspi.UnnumberedThoroughfareAddress

  • buri.ddmsence.summary.tspi.IntersectionAddress

  • buri.ddmsence.summary.tspi.TwoNumberAddressRange

  • buri.ddmsence.summary.tspi.LandmarkAddress

  • buri.ddmsence.summary.tspi.USPSPostalDeliveryBox

  • buri.ddmsence.summary.tspi.USPSPostalDeliveryRoute

  • buri.ddmsence.summary.tspi.USPSGeneralDeliveryOffice

  • buri.ddmsence.summary.tspi.GeneralAddressClass

Brian Uri
April 4, 2013, 9:12 PM

Hello Dr. Birkel,

I have been reviewing the TSPI implementation in DDMS 5.0 and noticed that GML allows some data to be defined externally via XLink. Specifically:

  • tspi:Circle, tspi:Ellipse, tspi:Envelope, and tspiolygon can be defined with internal coordinates (gmlos) or coordinates defined elsewhere (gmlointProperty).

  • All TSPI shapes inherit the gml:StandardObjectProperties attribute group, which allows an internal description (gml:description) or an external one (gml:descriptionReference).

From the perspective of a discovery use case, it seems like external references are of limited value. We would want to have as much information internal to the metacard/assertion as possible. It also seems like converting an external reference to an internal one is quite feasible during a transform from a payload to a metacard.

Do you see any value/harm in having DDMS prevent the use of external references (via Schematron) in some future version? I just wanted to pick your brain.

Thank you, and I hope all is well!

-----------------------------------------

Excellent point Brian. Fully agree that we should constrain such references to be within-scope of the metadata-record itself. Also, it’s very unusual to reference geometry-components, instead of referencing geometries-as-a-whole (“that gmloint, not that gmlos”). IMO, DDMS should disallow referencing geometry-components entirely. Reuse-by-reference should be restricted to referencing tspi:Circle and so on.

The referencing of geometry-components is the “poor mans” approach to achieving some of the computational/representational properties of shared-topology.

This is also a topic that I should address from the TSPI perspective as well, but more in the “note to readers” sense :->.

Brian Uri
April 4, 2013, 11:05 PM

Rev 847 adds the TSPI address types.

Still TODO:

  • Finish PostalAddress Builder.

  • Update PostalAddress test cases.

  • Shapes.

Brian Uri
April 5, 2013, 11:04 AM

Rev 849 completes work on the addresses.

Brian Uri
April 6, 2013, 7:22 AM

Rev 850 completes shapes.

The XML approach I used for addresses was so painless that I reproduced it for shapes. This provides some base functionality to DDMS 5.0 early adopters, and leaves room for growth/improvement in future releases of DDMSence. Because DDMS might change dramatically by NIEM policy goals, and because TSPI/ADDR are bigger than DDMS, it did not make sense to fully implement at this time.

Fixed

Assignee

Brian Uri

Reporter

Brian Uri

Labels

None

Fix versions

Priority

Medium