[Java-collab] First contents in osgeom repository

Sun Aug 9 13:47:00 EDT 2009

Hello,

the announced initial population of the geometry collaboration SVN
repository (located at
http://svn.osgeo.org/geotools/trunk/spike/geometry for now) has been
completed. It's based on the geometry package of the deegree 3 core
module (to be precise: I used the deegree 3 interfaces of the geometry
type hierarchy, but no implementation code). It's meant as a starting
point to get the discussion and development rolling. Please provide any
comments and suggestions!

I would like to introduce you to what's there at the moment and why we
designed it the way it is.

In total, 61 Java files are currently present in the repository.

-- Geometry and geometry related types --

The interfaces provide a faithful representation for all kinds of
geometry elements that are allowed according to GML 3.1.1 (except for
the two elements gml:_ImplicitGeometry + gml:Grid which are still
missing). Note that the geometry elements in GML 3.2.1 are a subset of
GML 3.1.1 (I think they basically deprecated gml:MultiPolygon and
gml:MultiCurve and removed gml:Ring from the geometry substitution
group), which is why the interface design refers to 3.1.1 rather than
3.2.1 (comments?).

- 27 Geometry interfaces: A hierarchy of interfaces that corresponds to
the whole substitution group hierarchy gml:_Geometry. Additionally a
class that corresponds to gml:Envelope. More details below.
- 16 CurveSegment interfaces (package
org.osgeo.geometry.primitive.segments): Interfaces that allow to
represent any segments that curves (i.e. gml:Curve elements) may consist
of. Corresponds to the substitution group hierarchy gml:_CurveSegment.
- 8 SurfacePatch interfaces (package
org.osgeo.geometry.primitive.patches): Interfaces to represent the
patches that surfaces (i.e. gml:Surface elements) consist of.
Corresponds to the substitution group hierarchy gml:_SurfacePatch.
- 1 Points interface (org.osgeo.geometry.points.Points) that abstracts a
sequence of Point objects. The motivation for this interface is to allow
more compact and efficient representations than using lists or arrays of
Point objects. This is essential, as geometries are usually build from
many points, e.g. a detailed LineString consists of tens or hundreds
thousands of points.  Think: CoordinateSequence in JTS.

--- Other types ---

- 1 CRS interface (org.osgeo.commons.crs.CRS): Placeholder interface
that allows to represent CRS information.
- 4 UOM related interfaces (org.osgeo.commons.uom): These are included
so some methods (e.g. Geometry#isWithinDistance(...)) can be expressed
in a unit-aware fashion. Comments?
- 1 ObjectProperties interface (org.osgeo.commons.ObjectProperties):
Placeholder interface for properties that can be attached to Geometry
objects. One important use case are the GML standard properties that
each GML geometry object allows for (e.g. multiple gml:metaDataProperty
elements, gml:name and gml:description properties).
- 1 PrecisionModel interface
(org.osgeo.geometry.precision.PrecisionModel): Placeholder interface for
a precision definition that can be attached to geometries. It's not 100%
clear to me yet how this should be defined and how to interoperate with
topological operators, spatial analysis and the exporting of geometries.
- 2 beans that represent parameter sets needed for the definition of
certain curve segments:
org.osgeo.geometry.primitive.segments.AffinePlacement and
org.osgeo.geometry.primitive.Knot. I think that it doesn't make sense to
allow different implementations here, and therefore these are classes,
not interfaces.

--- Notes on the geometry types ---

Altough it deviates from the GML 3.1.1 geometry hierarchy, Envelope is
currently derived from Geometry (interestingly, in GML 3.0, gml:Envelope
was actually substitutable for gml:_Geometry). This was done for
pragmatic reasons, as we observed that one often has to deal with a
Geometry or an Envelope (e.g. in Filters). By making them derive a
common interface, such cases are simpler to be implemented/used. If we
don't have such a common type, many, many methods have to be defined and
implemented twice (e.g. Geometry#intersects(Geometry) and
Geometry#intersects(Envelope)). Alternatively, we could create a common
base type above Geometry/Envelope (e.g. GeomOrEnvelope). What do you think?

The Geometry interface currently specifies the following methods:

- The common batch of topological predicates (e.g.
#intersects(Geometry)). IMHO, these methods should be CRS aware, so a
geometry in EPSG:25832 may be checked for intersection against an
EPSG:4326 geometry. Coordinate transformation should be performed
on-the-fly. Comments?
- The common batch of spatial analysis operations (e.g.
#getIntersection(Geometry) or getConvexHull()). How should one treat
different CRS here?
- #getGeometryType() provides a way to differentiate the type of a
geometry object. Note that there are comparable methods on the deeper
levels of the hierarchy (e.g. Curve#getCurveType()). This was motivated
by the idea to ease the working with the (quite complex) hierarchy, for
example in drawing code. I am not a big fan of using instanceof tests
(as they are inherently unsafe), so I thought it would be nice to
provide a way to use the more safe and convenient switch statements for
this (safer,  as Eclipse creates warnings if you leave out any choices).
What do you think?
- #getId() / #setId(). As ids are very integral to GML, I provided
methods for working with the identifier.
- #getCoordinateSystem() / #setCoordinateSystem(...)
- #getAttachedProperties() / #setAttachedProperties(...) for coping with
the GML standard properties that each GML geometry object allows for
(e.g. multiple gml:metaDataProperty elements, gml:name and
gml:description properties).

Eagerly awaiting your feedback. Please let me know what you like / dislike.

Best regards,
Markus

-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19            53177 Bonn, Germany
phone ++49 +228 18496-0       fax ++49 +228 18496-29 
http://www.lat-lon.de         http://www.deegree.org