GeoAPI

Proposal for RecordType/Record implementation

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0
  • Fix Version/s: 2.3-M5
  • Component/s: util
  • Labels:
    None
  • Environment:
    all
  • Number of attachments :
    1

Description

Currently, RecordType is mapped to Class and Record is mapped to Object. This is fine on the surface, but does not permit the dynamic construction of arbitrary record types at runtime. The attached proposal fixes this by presenting an implementation of Figure 15 in ISO19103:2005(E). The interfaces "Schema", "RecordSchema", "Record" and "RecordType" all encapsulate dictionaries (Maps) which relate some form of LocalName to the indicated type. Figure 15 does not clearly indicate (to me) that the dictionary functionality should be publicly exposed, so I have included only the explicitly defined locate() method.

This Issue depends on GEO-71.

The Poseidon model attached to GEO-71 contains this diagram as well.

Issue Links

This issue is related to:
GEO-77 Standardized mapping: ISO 19103 -> Java/GeoAPI Blocker Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jody Garnett added a comment -

Hi Bryce, we got too alternatives - Deegree has Record extend Feature.

And we have both Feature and Record extend ComplexAttribute. The idea being that Expression works on Object (ie Attribute, Complex, Feature, Record) and can be used for to enable Filter to act as restricting "facets" for data validation.

Can I ask you review the feature model work and come back to this request ....

Show
Jody Garnett added a comment - Hi Bryce, we got too alternatives - Deegree has Record extend Feature. And we have both Feature and Record extend ComplexAttribute. The idea being that Expression works on Object (ie Attribute, Complex, Feature, Record) and can be used for to enable Filter to act as restricting "facets" for data validation. Can I ask you review the feature model work and come back to this request ....
Hide
Permalink
Martin Desruisseaux added a comment -

This is documented in the OGC Change Request document and the interfaces should have been updated accordingly, but not yet tested in GeoTools implementation. This issue is kept open for that reason.

Show
Martin Desruisseaux added a comment - This is documented in the OGC Change Request document and the interfaces should have been updated accordingly, but not yet tested in GeoTools implementation. This issue is kept open for that reason.
Hide
Permalink
Martin Desruisseaux added a comment -

The Record and related types were commited by Bryce a few years ago and have been quite stable. I did today a comparison with figure 15 in ISO 19103:2005. I added the Type interface as a safety, which was defined by ISO but not referenced in the original RecordType GeoAPI interface. This allow us to reference Type in the way ISO do, in a RecordType.getMemberTypes() method. With the addition of this change, the current interface seems to match raisonably well ISO 19103, so I'm closing this issue.

Show
Martin Desruisseaux added a comment - The Record and related types were commited by Bryce a few years ago and have been quite stable. I did today a comparison with figure 15 in ISO 19103:2005. I added the Type interface as a safety, which was defined by ISO but not referenced in the original RecordType GeoAPI interface. This allow us to reference Type in the way ISO do, in a RecordType.getMemberTypes() method. With the addition of this change, the current interface seems to match raisonably well ISO 19103, so I'm closing this issue.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.