The Geometry module provides an implementation of OGC Feature Geometry Abstract Specification (ISO 19107) (a.k.a. Topic 1 - Feature Geometry).
|Table of Contents|
This project is:
- A collaboration University of Applied Sciences Cologne (Fachhochschule Köln) in collaboration with GeoTools and GeoAPI.
- Much of this code was copied from the JTS Topology Suite Version 1.7.2 and modified to work with ISO 19107 interfaces. This reuse is permitted under the terms of GNU Lesser General Public Licence.
- Was brought up to supported status by Graham Davis of Refractions Research
For more information on this module please contact:
- Prof. Dr. Jackson Roehrig
Institut für Technologie in den Tropen
Betzdorfer Strasse 2
- Sanjay Dominik Jena
- Graham Davis
Gold Star Quality Assurance Check
IP Check: review.txt added, all headers are in place
Releasable: no blocking issues, etc..
Quality Assurance: 50.1% test coverage reported by clover
Stability: No planned API changes
Supported: Documentation available, module maintainer watches user list, answers email.
This implementation is a project of Prof. Dr. Jackson Roehrig and Sanjay Dominik Jena of the University of Applied Sciences Cologne, Germany (Fachhochschule Köln).
We are implementing the Geometry of the ISO19107 with the following goals and limitations:
- implementation of the geometry objects (without TP_xxx topology). Limited to all classes except Solid/SolidBoundary, as well as to LineString/LineSegment as only implementation of CurveSegment.
- general longterm objective is an Implementation that handles 2D, 2.5D and 3D data. Storing data in all dimension is (obviously) not a problem. But there is vast difference between 2D and 3D spatial analyse operations.
- address the problem of limited memory, e.g. offer an interface for later possibility of storing some geometry data in order to relieve the limited memory capabilities (for example a Factory which returns Lists os some GM_xxx objects, the list can be implemented persistent afterwards).
- in some parts we will reuse code of the Java Topology Suite (JTS) and adopt to the Feature Geometry of the Abstract Specification. We do not "wrap" JTS classes. We copy chosen classes of the JTS under GNU Lesser License and fit these code to our implementation (and try to eleminate redundancies).
- Publicate the implementation under GNU Lesser License terms in the GeoTools project
As there aren´t existing too many approaches for a 19107 GeoAPI implementation yet, this implementation will serve as a test of the capability of the GeoAPI (in fact for TC211 too, since GeoAPI is partially derived from the TC211 specs) as well. Thus, we will report a list of suggestions to GeoAPI / GeoTools in order to contribute a part to the improvement of the GeoAPI by "Best Practise".
Adrian Custer is looking into the larger problems of making ISO19107 Geometry implementation that can respond to the CoordianteReferenceSystem definition by delegating to a range of operations. This module uses linear solutions (ie 2D space) for operations such as buffer and intersects; when working with geometries defined by great circles on a sphere a different implementation should be used.
In more simple terms; we need to have a double dispatch using both Geometry and CRS in order to determine the correct operation to execute.
For more information:
IP review is underway - known issue:
This module is now supported, user documentation is available here: Geometry Plugin.
Issues pertaining to GeoTools Geometry implementations:
Potentially relevant issues pertaining to the GeoAPI interfaces implemented by this code:
Testing and Conformance
The JTS XML tests have been imported, and a test suite has been created to run them. The following is the current status of which tests pass/fail and their associated bugs: