You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Peter Yuill <py...@objectix.com.au> on 2008/05/04 04:41:17 UTC
Spatial Functionality
Hi,
I responded to a recent post on the derby-user list on this topic. I am
working on a project to add spatial functionality to Derby through user
created tables and procedures. I am interested in taking the next step
and looking at incorporating spatial functionality in Derby.
The biggest issue I see is one of licensing. The concept of 'spatial
datatypes' might seem simple enough, but there is no real point without
spatial functions to go with them. The Open Geospatial Consortium (OGC)
http://www.opengeospatial.org published a standard set of these, and
there are a handful of high grade open source implementations. There is
a huge amount of work in these implementations, and they rely on very
specialized expertise. In the Java world there is just one that has
stood the test of time, the JTS Topology Suite
http://sourceforge.net/projects/jts-topo-suite/ . However JTS is LGPL,
and the prospect of re-engineering the functionality just to get an
Apache 2.0 license is mind boggling. Even worse, two of the OGC spatial
filters (Distance Within and Beyond) require Coordinate Reference System
(CRS) transformation if the database features are stored in a geographic
CRS. The obvious choice for that functionality is Geotools
http://geotools.codehaus.org/ , again LGPL. The Apache web site
indicates there are unresolved questions about the compatibility of
Apache 2.0 and GPL. Does anyone have more information on the status of
LGPL?
One alternative is to take the route that MySQL went. Leave out all the
secondary filtering and just support Minimum Bounding Rectangle (MBR)
queries. However the same question keeps surfacing on the MySQL spatial
list with monotonous regularity: when will MySQL get 'real' spatial
functionality. Personally I think a user-space solution is preferable to
a half-way solution like MySQL.
Regards,
Peter
Re: Spatial Functionality
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Peter,
I asked the legal discussion list for advice on how to proceed. Ian
Holsman, on the Lucene team, sent the following response. This may help
you untangle the licensing issue. Please keep the Derby list informed so
that we can help out as necessary. Patrick's email is
"Patrick.OLeary@corp.aol.com"
Thanks,
-Rick
Hi Rick.
I'd like to introduce you to Patrick. the maintainer of local lucene.
We're in the process of contributing locallucene
http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene.htm
(waiting on some internal meetings with lawyers). One of the features
they plan on adding is a ASL version of the geo spatial code. as they
are also using the same library as you guys.
I thought you two might like an introduction as your probably doing the
same kind of thing.
Regards
Ian
Peter Yuill wrote:
> Hi Rick,
> <Ri...@Sun.COM> said:
>
>> Peter Yuill wrote:
>>
>>> Hi,
>>>
>>> I responded to a recent post on the derby-user list on this topic. I am
>>> working on a project to add spatial functionality to Derby through user
>>> created tables and procedures. I am interested in taking the next step
>>> and looking at incorporating spatial functionality in Derby.
>>>
>>> The biggest issue I see is one of licensing. The concept of 'spatial
>>> datatypes' might seem simple enough, but there is no real point without
>>> spatial functions to go with them. The Open Geospatial Consortium (OGC)
>>> http://www.opengeospatial.org published a standard set of these, and
>>> there are a handful of high grade open source implementations. There is
>>> a huge amount of work in these implementations, and they rely on very
>>> specialized expertise. In the Java world there is just one that has
>>> stood the test of time, the JTS Topology Suite
>>> http://sourceforge.net/projects/jts-topo-suite/ . However JTS is LGPL,
>>> and the prospect of re-engineering the functionality just to get an
>>> Apache 2.0 license is mind boggling. Even worse, two of the OGC spatial
>>> filters (Distance Within and Beyond) require Coordinate Reference System
>>> (CRS) transformation if the database features are stored in a geographic
>>> CRS. The obvious choice for that functionality is Geotools
>>> http://geotools.codehaus.org/ , again LGPL. The Apache web site
>>> indicates there are unresolved questions about the compatibility of
>>> Apache 2.0 and GPL. Does anyone have more information on the status of
>>> LGPL?
>>>
>>>
>> Hi Peter,
>>
>> Thanks for working on this valuable contribution. We can ask the
>> legal-discuss list for advice about the licensing issues. Do you know
>> which version of the LGPL is used by the geospatial work? A quick glance
>> at the Geo Tools website indicated LGPL without specifying which
>> version. There are apparently two versions (2.1 and 3) according to the
>> Free Software Foundation:
>> http://www.fsf.org/licensing/licenses/index_html#LGPL
>>
>
> Both Geotools and JTS use LGPL 2.1
>
>
>> Thanks,
>> -Rick
>>
>>> One alternative is to take the route that MySQL went. Leave out all the
>>> secondary filtering and just support Minimum Bounding Rectangle (MBR)
>>> queries. However the same question keeps surfacing on the MySQL spatial
>>> list with monotonous regularity: when will MySQL get 'real' spatial
>>> functionality. Personally I think a user-space solution is preferable to
>>> a half-way solution like MySQL.
>>>
>>> Regards,
>>> Peter
>>>
>>>
Re: Spatial Functionality
Posted by Peter Yuill <py...@objectix.com.au>.
Hi Rick,
<Ri...@Sun.COM> said:
> Peter Yuill wrote:
> > Hi,
> >
> > I responded to a recent post on the derby-user list on this topic. I am
> > working on a project to add spatial functionality to Derby through user
> > created tables and procedures. I am interested in taking the next step
> > and looking at incorporating spatial functionality in Derby.
> >
> > The biggest issue I see is one of licensing. The concept of 'spatial
> > datatypes' might seem simple enough, but there is no real point without
> > spatial functions to go with them. The Open Geospatial Consortium (OGC)
> > http://www.opengeospatial.org published a standard set of these, and
> > there are a handful of high grade open source implementations. There is
> > a huge amount of work in these implementations, and they rely on very
> > specialized expertise. In the Java world there is just one that has
> > stood the test of time, the JTS Topology Suite
> > http://sourceforge.net/projects/jts-topo-suite/ . However JTS is LGPL,
> > and the prospect of re-engineering the functionality just to get an
> > Apache 2.0 license is mind boggling. Even worse, two of the OGC spatial
> > filters (Distance Within and Beyond) require Coordinate Reference System
> > (CRS) transformation if the database features are stored in a geographic
> > CRS. The obvious choice for that functionality is Geotools
> > http://geotools.codehaus.org/ , again LGPL. The Apache web site
> > indicates there are unresolved questions about the compatibility of
> > Apache 2.0 and GPL. Does anyone have more information on the status of
> > LGPL?
> >
> Hi Peter,
>
> Thanks for working on this valuable contribution. We can ask the
> legal-discuss list for advice about the licensing issues. Do you know
> which version of the LGPL is used by the geospatial work? A quick glance
> at the Geo Tools website indicated LGPL without specifying which
> version. There are apparently two versions (2.1 and 3) according to the
> Free Software Foundation:
> http://www.fsf.org/licensing/licenses/index_html#LGPL
Both Geotools and JTS use LGPL 2.1
> Thanks,
> -Rick
> > One alternative is to take the route that MySQL went. Leave out all the
> > secondary filtering and just support Minimum Bounding Rectangle (MBR)
> > queries. However the same question keeps surfacing on the MySQL spatial
> > list with monotonous regularity: when will MySQL get 'real' spatial
> > functionality. Personally I think a user-space solution is preferable to
> > a half-way solution like MySQL.
> >
> > Regards,
> > Peter
> >
>
Re: Spatial Functionality
Posted by Rick Hillegas <Ri...@Sun.COM>.
Peter Yuill wrote:
> Hi,
>
> I responded to a recent post on the derby-user list on this topic. I am
> working on a project to add spatial functionality to Derby through user
> created tables and procedures. I am interested in taking the next step
> and looking at incorporating spatial functionality in Derby.
>
> The biggest issue I see is one of licensing. The concept of 'spatial
> datatypes' might seem simple enough, but there is no real point without
> spatial functions to go with them. The Open Geospatial Consortium (OGC)
> http://www.opengeospatial.org published a standard set of these, and
> there are a handful of high grade open source implementations. There is
> a huge amount of work in these implementations, and they rely on very
> specialized expertise. In the Java world there is just one that has
> stood the test of time, the JTS Topology Suite
> http://sourceforge.net/projects/jts-topo-suite/ . However JTS is LGPL,
> and the prospect of re-engineering the functionality just to get an
> Apache 2.0 license is mind boggling. Even worse, two of the OGC spatial
> filters (Distance Within and Beyond) require Coordinate Reference System
> (CRS) transformation if the database features are stored in a geographic
> CRS. The obvious choice for that functionality is Geotools
> http://geotools.codehaus.org/ , again LGPL. The Apache web site
> indicates there are unresolved questions about the compatibility of
> Apache 2.0 and GPL. Does anyone have more information on the status of
> LGPL?
>
Hi Peter,
Thanks for working on this valuable contribution. We can ask the
legal-discuss list for advice about the licensing issues. Do you know
which version of the LGPL is used by the geospatial work? A quick glance
at the Geo Tools website indicated LGPL without specifying which
version. There are apparently two versions (2.1 and 3) according to the
Free Software Foundation:
http://www.fsf.org/licensing/licenses/index_html#LGPL
Thanks,
-Rick
> One alternative is to take the route that MySQL went. Leave out all the
> secondary filtering and just support Minimum Bounding Rectangle (MBR)
> queries. However the same question keeps surfacing on the MySQL spatial
> list with monotonous regularity: when will MySQL get 'real' spatial
> functionality. Personally I think a user-space solution is preferable to
> a half-way solution like MySQL.
>
> Regards,
> Peter
>