You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Joe White <wh...@gmail.com> on 2012/12/14 02:58:41 UTC
Geometry library / SIS-32
Hi, Everyone,
I've decided to revisit SIS-32, the TIKA/GDAL integration for spatial metadata from supported formats in TIKA. I'm starting to lay out the anticipated metadata, and the very first thing I run into is the Envelope of the image / vector data. Needless to say, this should be in some type of Geometry. I've been doing some initial research for this, and it seems that everyone's choice for this (JTS) is LGPL, which isn't APL compatible. Other suggestions are also ESRI's geometry library (not really appropriate for what we're doing) and some other LGPL/GPL libraries. Another suggestion is java.awt.geom, but it seems a little too unfinished to me. Does anyone out there have a suggestion for this, or are we basically in the position of having to roll our own support. Obviously, I'd rather find a pre-built binary we can live with, as long as the interface is ok, but if we have to build it out….
Joe
Re: Geometry library / SIS-32
Posted by Joe White <wh...@gmail.com>.
I agree with Chris and Martin. If we plan to roll our own set of geometry interfaces, then all we need is the desired architecture. We can fill that in over time as we need things, complete with tests. I'll see if I can lay hands on ISO 19107 to see what the layout looks like.
Joe
On Dec 14, 2012, at 12:19 PM, "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> wrote:
> Hey Martin,
>
> On 12/14/12 12:57 AM, "Martin Desruisseaux"
> <ma...@geomatys.fr> wrote:
>
>> Hello Chris
>>
>> The dependency injection mechanism would have prevented any JTS
>> dependency declaration in SIS. But anyway, I think we need a SIS
>> implementation if we can provide a real 3D library. But the fact that 2
>> Ph.D students worked on that with mitigated success suggests that the
>> difficulty is not to be underestimated.
>
> Yep agreed. And yes, I know to write a fully featured, amazing one is a
> huge investment. But, that's the point of Apache, and SIS, and projects,
> we're here for the long haul :)
>
>>
>> But if the goal is to provide the minimal infrastructure needed for
>> supporting SIS-32, then a possible approach is to identify the minimal
>> set of geometric objects needed, write this minimal set in a way that
>> "looks like" ISO 19107, then use them until a real ISO 19107 support is
>> available...
>
> +1, this makes total sense and is the way to go. Instead of considering
> how we can have our own "JTS" library in SIS today, let's consider the
> necessary baby steps to eventually getting there :) And writing the
> minimal set of geometric objects, incrementally, object by object, with
> tests, and functions, etc., seems to be the best approach.
>
> Cheers,
> Chris
>
>>
>> Martin
>>
>>
>> Le 14/12/12 15:29, Mattmann, Chris A (388J) a écrit :
>>> The big thing at Apache is to not introduce "surprises" downstream,
>>> e.g.,
>>> the need to download an LGPL library in order to do something
>>> interesting,
>>> while obfuscating it with APIs as part of the core ALv2 library. So I
>>> would not be in favor of any JTS dependency, even optional.
>>>
>>> I realize this is limiting in some fashion as JTS is fairly feature rich
>>> geometry library. But one of the goals of SIS is to provide a fully ALv2
>>> compatible, "no surprises" and feature rich package which means, unless
>>> JTS relicenses itself as ALv2 (which there have been some discussions
>>> regarding), then we can't use it in SIS.
>>>
>>> I am committed to helping with some alternative, so whatever we want to
>>> do
>>> as a community, even going all the way to rolling our own, let's simply
>>> do
>>> it, move forward, and deliver something awesome!
>>
>
Re: Geometry library / SIS-32
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On 12/14/12 12:57 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Chris
>
>The dependency injection mechanism would have prevented any JTS
>dependency declaration in SIS. But anyway, I think we need a SIS
>implementation if we can provide a real 3D library. But the fact that 2
>Ph.D students worked on that with mitigated success suggests that the
>difficulty is not to be underestimated.
Yep agreed. And yes, I know to write a fully featured, amazing one is a
huge investment. But, that's the point of Apache, and SIS, and projects,
we're here for the long haul :)
>
>But if the goal is to provide the minimal infrastructure needed for
>supporting SIS-32, then a possible approach is to identify the minimal
>set of geometric objects needed, write this minimal set in a way that
>"looks like" ISO 19107, then use them until a real ISO 19107 support is
>available...
+1, this makes total sense and is the way to go. Instead of considering
how we can have our own "JTS" library in SIS today, let's consider the
necessary baby steps to eventually getting there :) And writing the
minimal set of geometric objects, incrementally, object by object, with
tests, and functions, etc., seems to be the best approach.
Cheers,
Chris
>
> Martin
>
>
>Le 14/12/12 15:29, Mattmann, Chris A (388J) a écrit :
>> The big thing at Apache is to not introduce "surprises" downstream,
>>e.g.,
>> the need to download an LGPL library in order to do something
>>interesting,
>> while obfuscating it with APIs as part of the core ALv2 library. So I
>> would not be in favor of any JTS dependency, even optional.
>>
>> I realize this is limiting in some fashion as JTS is fairly feature rich
>> geometry library. But one of the goals of SIS is to provide a fully ALv2
>> compatible, "no surprises" and feature rich package which means, unless
>> JTS relicenses itself as ALv2 (which there have been some discussions
>> regarding), then we can't use it in SIS.
>>
>> I am committed to helping with some alternative, so whatever we want to
>>do
>> as a community, even going all the way to rolling our own, let's simply
>>do
>> it, move forward, and deliver something awesome!
>
Re: Geometry library / SIS-32
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
The dependency injection mechanism would have prevented any JTS
dependency declaration in SIS. But anyway, I think we need a SIS
implementation if we can provide a real 3D library. But the fact that 2
Ph.D students worked on that with mitigated success suggests that the
difficulty is not to be underestimated.
But if the goal is to provide the minimal infrastructure needed for
supporting SIS-32, then a possible approach is to identify the minimal
set of geometric objects needed, write this minimal set in a way that
"looks like" ISO 19107, then use them until a real ISO 19107 support is
available...
Martin
Le 14/12/12 15:29, Mattmann, Chris A (388J) a écrit :
> The big thing at Apache is to not introduce "surprises" downstream, e.g.,
> the need to download an LGPL library in order to do something interesting,
> while obfuscating it with APIs as part of the core ALv2 library. So I
> would not be in favor of any JTS dependency, even optional.
>
> I realize this is limiting in some fashion as JTS is fairly feature rich
> geometry library. But one of the goals of SIS is to provide a fully ALv2
> compatible, "no surprises" and feature rich package which means, unless
> JTS relicenses itself as ALv2 (which there have been some discussions
> regarding), then we can't use it in SIS.
>
> I am committed to helping with some alternative, so whatever we want to do
> as a community, even going all the way to rolling our own, let's simply do
> it, move forward, and deliver something awesome!
Re: Geometry library / SIS-32
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On 12/13/12 7:36 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Joe, Adam and all
>
>[...snip...]
>
>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...
Thanks for the history above on ISO 19107, etc.
The big thing at Apache is to not introduce "surprises" downstream, e.g.,
the need to download an LGPL library in order to do something interesting,
while obfuscating it with APIs as part of the core ALv2 library. So I
would not be in favor of any JTS dependency, even optional.
I realize this is limiting in some fashion as JTS is fairly feature rich
geometry library. But one of the goals of SIS is to provide a fully ALv2
compatible, "no surprises" and feature rich package which means, unless
JTS relicenses itself as ALv2 (which there have been some discussions
regarding), then we can't use it in SIS.
I am committed to helping with some alternative, so whatever we want to do
as a community, even going all the way to rolling our own, let's simply do
it, move forward, and deliver something awesome!
Cheers,
Chris
>
>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
>
Re: Geometry library / SIS-32
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
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
Re: Geometry library / SIS-32
Posted by Adam Estrada <es...@gmail.com>.
Joe,
There has been some recent activity involving foundation-level packages for metadata support, supervisor classes, converters, etc. but nothing has been checked in as of yet for robust geometry support. GeoToolkit has some support for this but I am not sure what parts can be included without JTS support. Yeah, JTS is LGPL and therefore cannot be used directly in SIS. Looking through the GTK sources, I do see some good stuff but have not dug deep enough in to it to be able to speak intelligently about it.
Martin, you wanna chime in here?
Adam
On Dec 13, 2012, at 8:58 PM, Joe White wrote:
> Hi, Everyone,
> I've decided to revisit SIS-32, the TIKA/GDAL integration for spatial metadata from supported formats in TIKA. I'm starting to lay out the anticipated metadata, and the very first thing I run into is the Envelope of the image / vector data. Needless to say, this should be in some type of Geometry. I've been doing some initial research for this, and it seems that everyone's choice for this (JTS) is LGPL, which isn't APL compatible. Other suggestions are also ESRI's geometry library (not really appropriate for what we're doing) and some other LGPL/GPL libraries. Another suggestion is java.awt.geom, but it seems a little too unfinished to me. Does anyone out there have a suggestion for this, or are we basically in the position of having to roll our own support. Obviously, I'd rather find a pre-built binary we can live with, as long as the interface is ok, but if we have to build it out….
>
> Joe
Re: Geometry library / SIS-32
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Joe,
+1 but we can't use LGPL or GPL, so we either have to roll our own or
figure something else out. Or get the JTS guys to move to ALv2 :)
Do you need a Geometry library to move forward on the Tika side? Can't we
just move forward with my Tika integration work I did in TIKA-605 through
the GDAL Java bindings?
Cheers,
Chris
On 12/13/12 5:58 PM, "Joe White" <wh...@gmail.com> wrote:
>Hi, Everyone,
>I've decided to revisit SIS-32, the TIKA/GDAL integration for spatial
>metadata from supported formats in TIKA. I'm starting to lay out the
>anticipated metadata, and the very first thing I run into is the Envelope
>of the image / vector data. Needless to say, this should be in some type
>of Geometry. I've been doing some initial research for this, and it
>seems that everyone's choice for this (JTS) is LGPL, which isn't APL
>compatible. Other suggestions are also ESRI's geometry library (not
>really appropriate for what we're doing) and some other LGPL/GPL
>libraries. Another suggestion is java.awt.geom, but it seems a little
>too unfinished to me. Does anyone out there have a suggestion for this,
>or are we basically in the position of having to roll our own support.
>Obviously, I'd rather find a pre-built binary we can live with, as long
>as the interface is ok, but if we have to build it outŠ.
>
>Joe