New TSPI classes for geometries and addresses in DDMS 5.0

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.

Rev 849 completes work on the addresses.

Rev 847 adds the TSPI address types.

Still TODO:

• Finish PostalAddress Builder.

• Update PostalAddress test cases.

• Shapes.

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 :->.

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

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