SpatiaLite without GEOS, how useful?

[David]

Because of licensing terms with the GEOS library I can not use it.  Is SpatiaLite useable without GEOS?  What I wanted to do was import Open Street Map data into SpatiaLite and query a subset of that data based on a bounding box.  I would be able to use GEOS enabled version of SpatiaLite to import the data.  The end-user would need to query the data for the entries located in the bounding box and return all those entries with a non GEOS enabled SpatiaLite.

If that functionality is not possible how difficult would it be for someone to implement the bare minimum GEOS methods needed by SpatiaLite to do this?

[mj10777]

Am Montag, 6. August 2012 04:35:15 UTC+2 schrieb David:

Because of licensing terms with the GEOS library I can not use it.  Is SpatiaLite useable without GEOS?  What I wanted to do was import

 Basicly the answer to this no, it is not usable.

I just tried this compiling the library with
./configure CFLAGS=-liconv --enable-geos=no --enable-geosadvanced=no

and tried :

SELECT Karte_Nummer,Karte_Name, Massstab, meters_width, meters_height, meters_area, meters_length
FROM
 maps_geometry
WHERE
 (
  ST_Contains(coord_geometry,ST_Transform(GeomFromText('POINT(13.37669944043396 52.51630196713876)',4326),3068))
 )
ORDER BY Massstab;

This is search all Maps and list the ones that contain the given point.
This should normally return 8 records, but fails because 'ST_Contains' is missing.
The logic for 'ST_Contains' is in gg_relations.c, where over 90% of the defined functions area based on GEOS.

Open Street Map data into SpatiaLite and query a subset of that data based on a bounding box.  I would be able to use GEOS enabled version of SpatiaLite to import the data.  The end-user would need to query the data for the entries located in the bounding box and return all those entries with a non GEOS enabled SpatiaLite.

 

If that functionality is not possible how difficult would it be for someone to implement the bare minimum GEOS methods needed by SpatiaLite to do this?

It would be very difficult, since much of the basic logic needed (and which other functions build on) would have to be reimplemented.
I’m afraid, that this would be like reinventing the wheel.
 

[a.fu...@lqt.it]

On Sun, 5 Aug 2012 19:35:15 -0700 (PDT), David wrote:
> Because of licensing terms with the GEOS library I can not use it.
>

David,

I don't agree that using GEOS poses too much licensing problems,
because this library is released under the LGPL terms.
and the LGPL exactly is the "permissive/relaxed" derivative of
the GPL specifically intended to allow proprietary (closed source)
applications linking free software libraries.

few technical details: under the strict GPL terms linking a single
line of GPLed code into a complex "derivative work" (i.e. application)
make the whole application GPLed as well. it's the well known
"viral/infective" clause.

on the other side the LGPL simply discards at all any viral clause;
so you can freely mix LGPLed code and your own proprietary code
into a complex "derivative work", but the LGPLed code will not
"infect" your own work; your code still remains legitimately
proprietary.

please note: SpatiaLite itself is released under the three-license
terms of the MPL: you can freely choose one between the GPL, LGPL
or MPL itself.
roughly speaking, the MPL is a little bit more relaxed than the
LGPL: MPL imposes less restrictions about redistribution, and
specifically allows static linking of MPLed libraries.

but differences between MPL and LGPL end here: MPL still is one
of the genuine "copyleft" licenses (may be, the most permissive
of them all), and should not confused with very weak licenses
such as BSD and MIT.

bye Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[a.fu...@lqt.it]

> Is SpatiaLite useable without GEOS?
>

absolutely YES; you simply have to build libspatialite omitting
to include the GEOS support:

./configure --disable-geos
make
sudo make install-strip

> What I wanted to do was import Open Street Map data into
> SpatiaLite and query a subset of that data based on a
> bounding box.

> <snip>

> The end-user would need to query the data for the entries

> located in the bounding box.
>

a gelded libspatialite (omitting GEOS) is fully able to fulfill
your requirements.
for simple bbox-based queries GEOS isn't a prerequisite.

> If that functionality is not possible how difficult would it
> be for someone to implement the bare minimum GEOS methods
> needed by SpatiaLite to do this?
>

I imagine that rewriting from scratch a geos-like library
will probably require many long years (and many developers).
limiting your ambitions to the "bare minimum" (a very vague
definition ...) will probably require many long months :-D

[David]

On Monday, August 6, 2012 2:47:33 AM UTC-5, sandro furieri wrote:

roughly speaking, the MPL is a little bit more relaxed than the
LGPL: MPL imposes less restrictions about redistribution, and
specifically allows static linking of MPLed libraries.

From my research and other messages on this list this seems to be one of the bigger issues.  Because of the LGPL on GEOS it appears you can not use SpatiaLite for an iOS app on the iTunes app store because it would have to be statically linked.   It is not clear to me if the LGPL would also be an issue on the Mac App Store.

[a.fu...@lqt.it]

> Because of the LGPL on GEOS it appears you can not use SpatiaLite
> for an iOS app on the iTunes app store because it would have to be
> statically linked.
> It is not clear to me if the LGPL would also be an issue on
> the Mac App Store.
>

so the problem isn't at all in GPL/LGPL: it simply arises from
arbitrary rules imposed by some specific vendor.

there are lots of equivalent alternatives available on the market;
many of them are much more "open source friendly", and someone
*is* genuine free sw by itself.
you are absolutely free to choose some more reasonable platform,
i.e. one not imposing highly disputable licensing restrictions.

[David]

On Monday, August 6, 2012 3:00:11 AM UTC-5, sandro furieri wrote:
> Is SpatiaLite useable without GEOS?
>

absolutely YES; you simply have to build libspatialite omitting
to include the GEOS support:

./configure --disable-geos
make
sudo make install-strip

Thanks Sandro.  Perhaps I am a little confused what the list at http://www.gaia-gis.it/gaia-sins/spatialite-sql-3.0.0.html shows then.  I was able to use MbrContains and MakePoint with SpatiaLite without GEOS enabled (libSpatialite.a is 10.1MiB now).  According to the SpaciaLite reference list those two functions require GEOS.  Why does this appear to work then without GEOS?

I tested with this query on the test-2.3.sqlite file:

 "SELECT * FROM Regions Where MbrContains(Geometry, MakePoint(%f, %f, %d))"
with the MakePoint arguments 540176.564, 5041228.401, 32632

sqlite3_column_text(statement, 1); 

returns the string LOMBARDIA