GML Geometry

From OSGeo
Revision as of 06:34, 26 October 2009 by Mays (talk | contribs) (update link to code sprint)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 in order to start grabbing things together.


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


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:
  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.