GML Geometry

Both deegree and GeoTools are running geometry constructs based on GML (or ISO19107 which GML builds on). These ideas go far beyond what is offered by the SFSQL implementation offered by JTS.

We have had a couple of IRC meetings and a Code Sprint http://wiki.osgeo.org/wiki/FOSS4G_2009_Code_Sprint#Geometry in order to start grabbing things together.

Direction

Discussions on java-collab email list have led to the following decisions.

• GML rather then ISO19107
• OSGEO to hold the resulting code; will create a "Lab" when we have code base and an agreed framework for collaboration
• LGPL
• Interface/Factory rather then Class

Planning

Some subset of Markus Schneider's proposal:

1. DONE - Remove all topological and spatial analysis methods in the interfaces from the SVN for now, so we can focus on sanitising the model.
2. Add factories. I would like to add two factories similar to the ones in the deegree 3 SVN:
   • SFS geometries:
     • http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/SimpleGeometryFactory.html
   • ISO 19107/GML 3
     • http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/GeometryFactory.html
   • In deegree 3, these factories are bound to a JTS-based implementation. As we only have interfaces for the geometry types in the osgeom repository for now (and no implementations), I would create interfaces from the factories.
3. Add a basic implementation that is just a bean representation without operations. We could finally start to add JUnit tests then.
4. Add GML parsers/exporters. I understood that one may want to keep this aspect out of the repository, but I don't see how we could test the difficulties in representing GML geometries (e.g external xlinks) without this. It also would make setting up geometries for testing much easier. Maybe we could keep the GML parsing/exporting isolated from the rest of the code.
5. Of course we would take on the operations subject again, when we find consensus here.