Hello Joe, Adam and all
Regarding geometry, I think that there is a lot of room for Joe's work.
Geotk code can be used as inspiration, but the geometry part of it may
be less mature than other parts (except maybe the Envelope part).
However the situation at the API level is a bit convolved:
Java2D is good for rendering and I like it. But it is not well suited
for spatial analysis (topology, etc.). Furthermore, Oracle seems to be
going toward JavaFX as a replacement for Swing [1], but also for Java2D.
So while I like Java2D and support using it, I think we are safer to
keep massive Java2D dependency close to the end of the stack, and keep
Java2D dependency minimal in the SIS core.
JTS is well known and widely spread. Even if we don't use it directly, I
think that we will be faced to situations where we will need to ensure
some kind of inter-operability with JTS anyway. I will come back on this
subject later in this email. But one important aspect to keep in mind is
that JTS is designed for handling two-dimensional geometries in a flat,
Cartesian space. Even if JTS Coordinate objects have (x,y,z) values, JTS
actually stores the 'z' value without using it. This cover a large
amount of needs, but we could also be more ambitious.
There is an international standard for geometric objects in spatial
information systems: ISO 19107. It is mentioned in [2], topic 1 -
"Feature geometry". Unfortunately this specification is not freely
available (most others are). But the key point is that this
specification covers the 1D, 2D and 3D cases and tries to handle
non-flat coordinate systems. SIS is already leading toward ISO 19115
(metadata) and ISO 19111 (referencing) supports. I think that if it
could be also ISO 19107 (geometry) compliant - including 3D support,
that would be a significant factor differentiating SIS from competition.
While the ISO 19107 specification is not available for free, you can get
a feeling of it by browsing the GeoAPI pending interfaces in the
"org.opengis.geometry.*" packages [3]. Note however that those
interfaces don't match exactly ISO 19107. We started to integrate
material from a planned ISO 19107 revision, and stopped because it was
apparently too early. So some Geometry interfaces are in a kind of mixed
state (note: the "pending" part of GeoAPI is the part which is not yet
standardized, so we can change it relatively easily).
However ISO 19107 is reputed very complex. Two Ph.D. students worked on
ISO 19107 implementation in Java [4], without completion to library used
in production. Most peoples are still using a simplified version of ISO
19107, known as "Simple Feature". Actually I think that JTS can be seen
as an implementation of the "Simple Feature" profile of ISO 19107. But
"Simple Feature" has the same limitations than JTS.
The ISO 19107 author (an Oracle researcher) is aware of that situation.
He is in the process right now of writing a new ISO 19107. Maybe in
order to avoid scaring peoples too much, he doesn't call that "ISO
19107". He does his work in the "Simple Feature" standard working group,
but despite the name this is really on the basis of ISO 19107. Ideally,
I think that we should wait for the new standard. But this work is still
in relatively early stage. Note for Adam and Chris: this will be
discussed at the OGC meeting in the Simple Features SWG session,
currently scheduled Monday, 14 January at 16:00 - 18:00 [5].
In order to use a progressive path, one approach that I would have liked
would have been to write ISO-19107 wrappers around the JTS library, and
put those wrappers in public domain in GeoAPI (we already provided
wrappers around the NetCDF library and around Proj.4 in public domain on
GeoAPI). The reason why we put them in public domain is that we consider
those wrappers as example of how GeoAPI can be implemented (they do not
need to be very sophisticated), and in the hope to encourage vendors to
use them as a starting point for their own products. This is because a
project like GeoAPI can make sense only if we convince more than one
software maker to implement the interfaces.
On SIS side, SIS would uses only the GeoAPI geometry interfaces. We
would have no direct JTS dependency in SIS. However JTS would be used
indirectly just by letting the user put himself the JTS JAR files in the
classpath - it should be detected automatically and used though the
wrappers. This would be a temporary solution until we have a real ISO
19107 implementation, and would probably be needed anyway for JTS
inter-operability...
In the particular case of Envelope, there is already a quite elaborated
class available [6]. But this is about the only one on the geometric side.
Martin
[1]
http://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html#6
[2] http://www.opengeospatial.org/standards/as
[3] http://www.geoapi.org/snapshot/pending/index.html
[4] http://www.geoapi.org/implementations.html
[5] http://www.opengeospatial.org/event/1301tcagenda
[6]
http://www.geotoolkit.org/apidocs/org/geotoolkit/geometry/GeneralEnvelope.html
