GeoAPI
GEO-1

Finish the creation of Java interfaces for geometries

Details

Type: Task
Status: Open
Priority: Major
Resolution: Unresolved
Affects Version/s: 1.0, 2.0
Fix Version/s: None
Component/s: geometry
Labels:
None

Number of attachments :
0

Description

Interfaces were created in the order the appears in the ISO 19107 specification, up to (only partially included) GM_Conic. The rest of Java interfaces for geometries need to be created using the skeleton already available.

Special care must be taken regarding javadoc. The ISO 19107 has a very accurate documentation, with a fair amount of figures and equations. Javadoc is the longuest task during Java interface creation, and should not be skipped.

Issue Links

depends upon

GEO-14 Clash in the semantic of contains(...) method in CompositeCurve

GEO-138 Require Position homogeneity in PointArray

GEO-148 Rename CurveSegement.getCurve() to .getContainingCurve()

GEO-154 Define complex.Complex.getBoundary():ComplexBoundary, overriding the method from Geometry

GEO-155 Define (primitive.)Boundary.getBoundary() to return null

GEO-84 Incorrect return type on Polygon method

GEO-88 Unidirectional "Composition" aggregation implemented in the backwards direction too.

GEO-149 Add a parameterless length() method to GenericCurve

GEO-52 Geometry interfaces in wrong package

GEO-201 Align the geometry interfaces on the latest ISO 19107 draft

is duplicated by

GEOT-93 Create GeoAPI interfaces from OGC 2001-101 / ISO 19107

Show 6 more links (5 depends upon, 1 is duplicated by)

Activity

Ascending order - Click to sort in descending order

Martin Desruisseaux made changes - 11/Sep/04 6:24 AM

Field	Original Value	New Value
Component/s		geometry [ 11095 ]

Martin Desruisseaux made changes - 12/Sep/04 11:27 PM

Affects Version/s

1.1 [ 11051 ]

Martin Desruisseaux made changes - 22/Sep/04 5:35 PM

Assignee

Martin Desruisseaux [ desruisseaux ]

Martin Desruisseaux made changes - 22/Sep/04 5:35 PM

Status

Open [ 1 ]

In Progress [ 3 ]

Permalink

Martin Desruisseaux logged work - 22/Sep/04 8:44 PM

Time Spent:

3 hours

Added the following interfaces: Conic, Clothoid, OffsetCurve, Placement, AffinePlacement

Martin Desruisseaux made changes - 22/Sep/04 8:44 PM

Time Spent		3 hours [ 10800 ]
Remaining Estimate	2 weeks [ 1209600 ]	1 week, 6 days, 21 hours [ 1198800 ]

Hide

Permalink

Martin Desruisseaux added a comment - 30/Sep/04 10:22 PM

GeoAPI issues are now tracked on http://jira.codehaus.org/browse/GEO.

Show

Martin Desruisseaux added a comment - 30/Sep/04 10:22 PM GeoAPI issues are now tracked on http://jira.codehaus.org/browse/GEO .

Martin Desruisseaux made changes - 30/Sep/04 10:22 PM

Link

This issue is duplicated by ~~GEOT-93~~ [ ~~GEOT-93~~ ]

Permalink

Martin Desruisseaux logged work - 25/Oct/04 5:38 AM

Time Spent:

2 hours

Added Knot, KnotType, SplineCurve, PolynomialSpline and CubicSpline.

Martin Desruisseaux made changes - 25/Oct/04 5:39 AM

Remaining Estimate	1 week, 6 days, 21 hours [ 1198800 ]	1 week, 6 days, 19 hours [ 1191600 ]
Time Spent	3 hours [ 10800 ]	5 hours [ 18000 ]

Martin Desruisseaux made changes - 05/Feb/05 6:02 AM

Status

In Progress [ 3 ]

Open [ 1 ]

Permalink

Martin Desruisseaux logged work - 31/Mar/05 5:43 AM

Time Spent:

2 hours

Added the following interfaces in org.geotools.spatialschema.geometry.geometry package:

BicubicGrid.java
BilinearGrid.java
Cone.java
Cylinder.java
GriddedSurface.java
Sphere.java

Martin Desruisseaux made changes - 31/Mar/05 5:43 AM

Remaining Estimate	1 week, 6 days, 19 hours [ 1191600 ]	1 week, 6 days, 17 hours [ 1184400 ]
Time Spent	5 hours [ 18000 ]	7 hours [ 25200 ]

Martin Desruisseaux made changes - 28/Jun/05 6:01 AM

Fix Version/s		2.2 [ 11866 ]
Environment
Description	Interfaces were created in the order the appears in the ISO 19107 specification, up to (only partially included) GM_Conic. The rest of Java interfaces for geometries need to be created using the skeleton already available. Special care must be taken regarding javadoc. The ISO 19107 has a very accurate documentation, with a fair amount of figures and equations. Javadoc is the longuest task during Java interface creation, and should not be skipped.	Interfaces were created in the order the appears in the ISO 19107 specification, up to (only partially included) GM_Conic. The rest of Java interfaces for geometries need to be created using the skeleton already available. Special care must be taken regarding javadoc. The ISO 19107 has a very accurate documentation, with a fair amount of figures and equations. Javadoc is the longuest task during Java interface creation, and should not be skipped.

Hide

Permalink

Martin Desruisseaux added a comment - 01/Jul/05 1:01 AM

Added remaining interfaces for the "geometry" package. The "aggregate" package is now next on the list.

Show

Martin Desruisseaux added a comment - 01/Jul/05 1:01 AM Added remaining interfaces for the "geometry" package. The "aggregate" package is now next on the list.

Martin Desruisseaux made changes - 16/Feb/06 7:10 AM

Fix Version/s

2.2 [ 12386 ]

Hide

Permalink

Bryce Nordgren added a comment - 24/May/06 5:52 PM

Martin, the "coordinate geometry" package (Section 6.4 in ISO/DIS 19107) seems to be divided between java packages
"org.opengis.spatialschema.geometry" and "org.opengis.spatialschema.geometry.geometry". Can we combine these two java packages into one?

Is there a rationale for the division?

Show

Bryce Nordgren added a comment - 24/May/06 5:52 PM Martin, the "coordinate geometry" package (Section 6.4 in ISO/DIS 19107) seems to be divided between java packages "org.opengis.spatialschema.geometry" and "org.opengis.spatialschema.geometry.geometry". Can we combine these two java packages into one? Is there a rationale for the division?

Hide

Permalink

Martin Desruisseaux added a comment - 24/May/06 9:12 PM

The "org.opengis.spatialschema.geometry" package contained originaly the "root" classes in ISO 19107 terms. A few classes from section 6.4 were also put in this package because they seemed extensively used (DirectPosition, Envelope).

However, generally speaking, I'm unhappy with the package names in GeoAPI for the geometry part. I dislike especially "org.opengis.spatialschema.geometry.geometry" First, the repetition of "geometry" is not very nice. Second, I would have liked to drop the "spatialschema" part.

The mean problem is: are we allowed to change the package names, given that some implementations may already exists?

Show

Martin Desruisseaux added a comment - 24/May/06 9:12 PM The " org.opengis.spatialschema.geometry " package contained originaly the "root" classes in ISO 19107 terms. A few classes from section 6.4 were also put in this package because they seemed extensively used ( DirectPosition , Envelope ). However, generally speaking, I'm unhappy with the package names in GeoAPI for the geometry part. I dislike especially " org.opengis.spatialschema.geometry.geometry " First, the repetition of " geometry " is not very nice. Second, I would have liked to drop the " spatialschema " part. The mean problem is: are we allowed to change the package names, given that some implementations may already exists?

Hide

Permalink

Bryce Nordgren added a comment - 25/May/06 9:59 AM

Well, I looked around and I couldn't find any 19107 implementations except that one GT inherited from Sys Technologies. The bigger problem is the "non-implementations", the ones which just implement "DirectPosition" and "Envelope". Those might cause some heartburn if moved. We could "deprecate, then delete" in two successive release cycles.

If we're going to do anything, though, we should do it sooner rather than later. I think people are starting to want 19107 implementations due to the fact that more standards are being released which use geometry as a building block.

I agree totally about both naming issues. Perhaps "...geometry.geometry" could be "...geometry.coordinate" and spatialschema could just disappear?

Show

Bryce Nordgren added a comment - 25/May/06 9:59 AM Well, I looked around and I couldn't find any 19107 implementations except that one GT inherited from Sys Technologies. The bigger problem is the "non-implementations", the ones which just implement "DirectPosition" and "Envelope". Those might cause some heartburn if moved. We could "deprecate, then delete" in two successive release cycles. If we're going to do anything, though, we should do it sooner rather than later. I think people are starting to want 19107 implementations due to the fact that more standards are being released which use geometry as a building block. I agree totally about both naming issues. Perhaps "...geometry.geometry" could be "...geometry.coordinate" and spatialschema could just disappear?

Hide

Permalink

Bryce Nordgren added a comment - 25/May/06 12:44 PM

NOTE: The "...geometry.aggregate" package is incomplete. It's missing MultiSurface and MultiSolid. Should this be tracked under a different issue?

Show

Bryce Nordgren added a comment - 25/May/06 12:44 PM NOTE: The "...geometry.aggregate" package is incomplete. It's missing MultiSurface and MultiSolid. Should this be tracked under a different issue?

Bryce Nordgren made changes - 25/May/06 12:51 PM

Link

This issue is related to GEO-52 [ GEO-52 ]

Hide

Permalink

Bryce Nordgren added a comment - 25/May/06 12:51 PM

The discussion of relocating packages/classes seems germane to GEO-52, which is closed as "wontfix". If we do anything to the packages, maybe these others could be rearranged as well?

Show

Bryce Nordgren added a comment - 25/May/06 12:51 PM The discussion of relocating packages/classes seems germane to GEO-52 , which is closed as "wontfix". If we do anything to the packages, maybe these others could be rearranged as well?

Hide

Permalink

Martin Desruisseaux added a comment - 25/May/06 4:05 PM

I would agree about dropping the "spatialschema" part and renaming the last "geometry" into something else (or move its content to the parent "geometry" package). I also believe that the two successive release cycles ("deprecate, then delete") would work at least in a J2SE 1.5 environment (because "covariant return type" would be of great help there). I'm not sure how we could do that in a J2SE 1.4 environment however.

We may propose that to OGC, and I agree that it would need to be done soon. We may target the OGC meeting in october 2006, since it is the only one I can attend in the next few months.

As you rightly point out, the "..geometry.aggregate" package is incomplete. The full topology package is also missing. I didn't had the time to finish them. They are actually the subject of this GEO-1 task. "Renaming geometry packages" should be a different JIRA task.

~~GEOT-52~~ was about moving 5 very specific interfaces; it was not a general discussion about package renaming. It was closed as "will not fix" simply because after more investigation, it appeared that those 5 interfaces were actually at the right place.

Show

Martin Desruisseaux added a comment - 25/May/06 4:05 PM I would agree about dropping the " spatialschema " part and renaming the last " geometry " into something else (or move its content to the parent " geometry " package). I also believe that the two successive release cycles ("deprecate, then delete") would work at least in a J2SE 1.5 environment (because "covariant return type" would be of great help there). I'm not sure how we could do that in a J2SE 1.4 environment however. We may propose that to OGC, and I agree that it would need to be done soon. We may target the OGC meeting in october 2006, since it is the only one I can attend in the next few months. As you rightly point out, the " ..geometry.aggregate " package is incomplete. The full topology package is also missing. I didn't had the time to finish them. They are actually the subject of this GEO-1 task. "Renaming geometry packages" should be a different JIRA task. GEOT-52 was about moving 5 very specific interfaces; it was not a general discussion about package renaming. It was closed as "will not fix" simply because after more investigation, it appeared that those 5 interfaces were actually at the right place.

Hide

Permalink

Martin Desruisseaux added a comment - 25/May/06 4:32 PM

Typo: ~~GEOT-52~~ above should have been GEO-52.

Show

Martin Desruisseaux added a comment - 25/May/06 4:32 PM Typo: GEOT-52 above should have been GEO-52 .

Jody Garnett made changes - 27/Apr/07 8:51 PM

Fix Version/s	2.1-M4 [ 11866 ]
Fix Version/s		2.1 [ 13446 ]

Jody Garnett made changes - 20/Aug/07 2:32 PM

Fix Version/s		2.1 [ 13678 ]
Fix Version/s	2.1-M7 [ 13446 ]
Fix Version/s	2.2 [ 12386 ]

Hide

Permalink

Jody Garnett added a comment - 04/Sep/07 8:47 PM

Martin can we close this bug now?

Show

Jody Garnett added a comment - 04/Sep/07 8:47 PM Martin can we close this bug now?

Jody Garnett made changes - 04/Sep/07 8:54 PM

Fix Version/s		2.1 [ 13697 ]
Fix Version/s	2.1-M8 [ 13678 ]

Hide

Permalink

Martin Desruisseaux added a comment - 05/Sep/07 8:25 AM

Do we have finished to create an interface for all ISO 19107 elements? It seems to me that we have not finished some packages like aggregates, and all topology interfaces?

Show

Martin Desruisseaux added a comment - 05/Sep/07 8:25 AM Do we have finished to create an interface for all ISO 19107 elements? It seems to me that we have not finished some packages like aggregates, and all topology interfaces?

Martin Desruisseaux made changes - 28/Nov/07 12:35 PM

Fix Version/s	2.1 [ 13697 ]
Description	Interfaces were created in the order the appears in the ISO 19107 specification, up to (only partially included) GM_Conic. The rest of Java interfaces for geometries need to be created using the skeleton already available. Special care must be taken regarding javadoc. The ISO 19107 has a very accurate documentation, with a fair amount of figures and equations. Javadoc is the longuest task during Java interface creation, and should not be skipped.	Interfaces were created in the order the appears in the ISO 19107 specification, up to (only partially included) {{GM_Conic}}. The rest of Java interfaces for geometries need to be created using the skeleton already available. Special care must be taken regarding javadoc. The ISO 19107 has a very accurate documentation, with a fair amount of figures and equations. Javadoc is the longuest task during Java interface creation, and should not be skipped.
Fix Version/s		3.0 [ 12389 ]