Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »



Module Maintainer:

Sanjay Patel


(red star)(red star)(red star)(red star)(red star)

Email Help:


IP Review:


The Geometry module is an experimental module implementing ISO 19107 (a.k.a. Topic 1 - Feature Geometry).

Gold Star Quality Assurance Check

(red star) IP Check: review.txt added, all headers are in place
(red star) Releasable: no blocking issues, but feedback from potential users is appreciated
(red star) Quality Assurance: 23.2% test coverage reported by clover
(red star) Stability: No planned API changes
(red star) Supported: Documentation available, module maintainer does watches user list, answers email.

Module Goals

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

IP Review

IP review is underway - known issue:

Module Status


Sources published at the moment are not in a final state and were posted to share the approach with other developers and help as a reference in implementation discussions. They may still be extended, modified and refactored.

Jody Garnett has a mandate to bring this module up to supported status:

  • user documentation
  • coverage testing
  • conformance testing (based on JTS testing)
  • etc ... see the developers guide.

Outstanding Issues

Issues pertaining to GeoTools Geometry implementations:

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.

Potentially relevant issues pertaining to the GeoAPI interfaces implemented by this code:

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it.
  • No labels