GeoAPI

Geometry interfaces in wrong package

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0, 2.0
  • Fix Version/s: 2.0
  • Component/s: geometry
  • Labels:
    None
  • Number of attachments :
    0

Description

The following interfaces are currently defined in
org.opengis.spatialschema.geometry.primitive:

  • SurfacePatch
  • CurveInterpolation
  • SurfaceInterpolation

According ISO 19107, the should be in the "coordinate geometry" subpackage (i.e.
org.opengis.spatialschema.geometry.geometry).

Also, the following interfaces are currently defined in the
org.opengis.spatialschema.geometry.geometry|complex packages:

  • Boundary
  • ComplexBoundary

According ISO 19107, they should live in "primitive" sub-package (i.e.
org.opengis.spatialschema.geometry.primitive).

Issue Links

This issue depends upon:
GEO-150 Move primitive.CurveInterpolation to coordinate package Major Resolved
GEO-151 Move primitive.SurfacePatch and primitive.SurfaceInterpolation back to coordinate package Major Resolved
GEO-152 Move geometry.Boundary back to primitive package as in ISO 19107:2003 Major Resolved
GEO-147 Move primitive.CurveSegment to coordinate package Major Resolved
This issue is depended upon by:
GEO-1 Finish the creation of Java interfaces for geometries Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Desruisseaux added a comment -

CurveSegment needs to be moved too (from 'primitive' to 'geometry').

Show
Martin Desruisseaux added a comment - CurveSegment needs to be moved too (from 'primitive' to 'geometry').
Hide
Permalink
Martin Desruisseaux added a comment -

??? The curreng GeoAPI packaging is consistent with the UML rational rose files provided here:

http://www.isotc211.org/HMMG/

Which specification shall will follows? The above-cited rational rose files or the PDF document on the OGC web site?

Show
Martin Desruisseaux added a comment - ??? The curreng GeoAPI packaging is consistent with the UML rational rose files provided here: http://www.isotc211.org/HMMG/ Which specification shall will follows? The above-cited rational rose files or the PDF document on the OGC web site?
Hide
Permalink
Martin Desruisseaux added a comment -

Summary (again): the following classes are declared in different packages according OGC 01-101 (ISO 19107) and the ISO 211 UML schemas available at http://www.isotc211.org/HMMG/

Class name OGC 01-101 package www.isotc211.org package
---------------------- ------------------ ------------------------
SurfacePatch geometry primitive
CurveInterpolation geometry primitive
SurfaceInterpolation geometry primitive
Boundary primitive geometry
ComplexBoundary primitive complex

Since the schemas in "www.isotc211.org" are more recent, we assume that they are the one to follow.

Show
Martin Desruisseaux added a comment - Summary (again): the following classes are declared in different packages according OGC 01-101 (ISO 19107) and the ISO 211 UML schemas available at http://www.isotc211.org/HMMG/ Class name OGC 01-101 package www.isotc211.org package ---------------------- ------------------ ------------------------ SurfacePatch geometry primitive CurveInterpolation geometry primitive SurfaceInterpolation geometry primitive Boundary primitive geometry ComplexBoundary primitive complex Since the schemas in "www.isotc211.org" are more recent, we assume that they are the one to follow.
Hide
Permalink
Adrian Custer added a comment -

This is an update in January 2008 documenting the differences between GeoAPI and the published ISO specification ISO 190107:2003.

The differences are due to the differences in the UML schemas available in RationalRose format on the ISO TC 211 site with the published specification. Because the schemas are more recent, we assume they are correct. The update attempts to clarify Martin's last comment which is confusing because the GeoAPI naming scheme has changed.

Note 1: the GeoAPI classes all start with "org.opengis.geometry."

Note 2: I have not confirmed this by viewing the RationalRose schema because I don't have a copy of RationalRose. I have only observed the differences documented below between the GeoAPI location and the location in the published spec

REARRANGED CLASSES IN GEOAPI COMPARED TO THE PUBLISHED ISO 19107:2003

GeoAPI Class Published Spec Class Explanation

Geometry root.GM_Object for convenience
Boundary primitive.GM_Boundary (UML has this in coordinate.*) for convenience
DirectPosition coordinate.DirectPosition for convenience
Envelope coordinate.GM_Envelope for convenience
TransfiniteSet coordinate.TransfiniteSet <DirectPosition> for convenience

complex.ComplexBoundary primitive.GM_ComplexBoundary UML change

primitive.CurveInterpolation coordinate.GM_CurveInterpolation UML change
primitive.CurveSegement coordinate.GM_CurveSegement UML change?
primitive.SurfaceInterpolation coordinate.GM_SurfaceInterpolation UML change
primitive.SurfacePatch coordinate.GM_SurfacePatch UML change

Show
Adrian Custer added a comment - This is an update in January 2008 documenting the differences between GeoAPI and the published ISO specification ISO 190107:2003. The differences are due to the differences in the UML schemas available in RationalRose format on the ISO TC 211 site with the published specification. Because the schemas are more recent, we assume they are correct. The update attempts to clarify Martin's last comment which is confusing because the GeoAPI naming scheme has changed. Note 1: the GeoAPI classes all start with "org.opengis.geometry." Note 2: I have not confirmed this by viewing the RationalRose schema because I don't have a copy of RationalRose. I have only observed the differences documented below between the GeoAPI location and the location in the published spec REARRANGED CLASSES IN GEOAPI COMPARED TO THE PUBLISHED ISO 19107:2003 GeoAPI Class Published Spec Class Explanation Geometry root.GM_Object for convenience Boundary primitive.GM_Boundary (UML has this in coordinate.*) for convenience DirectPosition coordinate.DirectPosition for convenience Envelope coordinate.GM_Envelope for convenience TransfiniteSet coordinate.TransfiniteSet <DirectPosition> for convenience complex.ComplexBoundary primitive.GM_ComplexBoundary UML change primitive.CurveInterpolation coordinate.GM_CurveInterpolation UML change primitive.CurveSegement coordinate.GM_CurveSegement UML change? primitive.SurfaceInterpolation coordinate.GM_SurfaceInterpolation UML change primitive.SurfacePatch coordinate.GM_SurfacePatch UML change
Hide
Permalink
Adrian Custer added a comment -

REARRANGED CLASSES IN GEOAPI COMPARED TO THE PUBLISHED ISO 19107:2003

GeoAPI Class ........................................ Published Spec Class ..................................................... Explanation

Geometry ............................................. root.GM_Object ............................................................... for convenience
Boundary ............................................. primitive.GM_Boundary ................................................... (UML has this in coordinate.*) for convenience
DirectPosition ...................................... coordinate.DirectPosition ................................................. for convenience
Envelope .............................................. coordinate.GM_Envelope .................................................. for convenience
TransfiniteSet ...................................... coordinate.TransfiniteSet <DirectPosition> ..................... for convenience

complex.ComplexBoundary .................. primitive.GM_ComplexBoundary ....................................... UML change

primitive.CurveInterpolation ................ coordinate.GM_CurveInterpolation .................................... UML change
primitive.CurveSegement ..................... coordinate.GM_CurveSegement ......................................... UML change?
primitive.SurfaceInterpolation .............. coordinate.GM_SurfaceInterpolation ................................. UML change
primitive.SurfacePatch ......................... coordinate.GM_SurfacePatch ............................................ UML change

Show
Adrian Custer added a comment - REARRANGED CLASSES IN GEOAPI COMPARED TO THE PUBLISHED ISO 19107:2003 GeoAPI Class ........................................ Published Spec Class ..................................................... Explanation Geometry ............................................. root.GM_Object ............................................................... for convenience Boundary ............................................. primitive.GM_Boundary ................................................... (UML has this in coordinate.*) for convenience DirectPosition ...................................... coordinate.DirectPosition ................................................. for convenience Envelope .............................................. coordinate.GM_Envelope .................................................. for convenience TransfiniteSet ...................................... coordinate.TransfiniteSet <DirectPosition> ..................... for convenience complex.ComplexBoundary .................. primitive.GM_ComplexBoundary ....................................... UML change primitive.CurveInterpolation ................ coordinate.GM_CurveInterpolation .................................... UML change primitive.CurveSegement ..................... coordinate.GM_CurveSegement ......................................... UML change? primitive.SurfaceInterpolation .............. coordinate.GM_SurfaceInterpolation ................................. UML change primitive.SurfacePatch ......................... coordinate.GM_SurfacePatch ............................................ UML change
Hide
Permalink
Adrian Custer added a comment -

It seems that this is a big mess.

As shown in GEO-147, GEO-150, and GEO-151; all of these except ComplexBoundary should go back to the place they were published in ISO19107:2003.

Show
Adrian Custer added a comment - It seems that this is a big mess. As shown in GEO-147, GEO-150, and GEO-151; all of these except ComplexBoundary should go back to the place they were published in ISO19107:2003.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:

Time Tracking

Estimated:
30m
Original Estimate - 30 minutes
Remaining:
30m
Remaining Estimate - 30 minutes
Logged:
Not Specified
Time Spent - Not Specified
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.