Create a GEOS geometry from a Spatialite Blob WKB directly

[Aurélien Albert]

Hi,

I'm using Spatialite to manage a vector data and execute some processing on it.

All my different processing codes use GEOS geometries as input, so for now I do that every time I read a geometry from database :

gaiaGeom = gaiaFromSpatiaLiteBlobWkb(blob, size);
geosGeom = gaiaToGeos(gaiaGeom)
gaiaFreeGeomColl(gaiaGeom);

processGeometry(geosGeom);

After some performances investigations, it appears that for simple geometry process, the time used to convert from GAIA to GEOS geometry represent an important part.

So, here is some questions :

1/ is there any way to decode a Spatialite BLOB to a GEOS geometry without decoding first to a GAIA geometry with the current Spatialite API ?

2/ if not, is it relevant to code it and integrate it in Spatialite source code (if I decide to code this method, I'll probably submit it for integration)

3/ I've never worked with GAIA geometry, always with GEOS geometry (the Spatialite component went after GEOS integration in my application). Is there any "functionnal" difference between GAIA and GEOS geometry ?

Thanks

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

On Fri, 6 Nov 2015 08:04:22 -0800 (PST), Aurélien Albert wrote:
> Hi,
>
> I'm using Spatialite to manage a vector data and execute some
> processing on it.
>
> All my different processing codes use GEOS geometries as input, so
> for
> now I do that every time I read a geometry from database :
>
> gaiaGeom = gaiaFromSpatiaLiteBlobWkb(blob, size);
> geosGeom = gaiaToGeos(gaiaGeom)
> gaiaFreeGeomColl(gaiaGeom);
>
> processGeometry(geosGeom);
>

Hi Aurélien,

if I correctly understand your questions you are using
libspatialite in the worst possible way.

libspatialite completely wraps GEOS, so there is
absolutely no reason to directly call any GEOS own
API; the optimal approach is always the one to
execute some Spatial SQL statement.
if such a SQL statement includes some function as
ST_Union(), ST_Difference(), ST_Overlaps() and
alike requiring some kind of GEOS support, then
case libspatialite will silently handle any data
conversion back and forth from the internal
binary BLOB format and the GEOS own binary format
as appropriate.

> After some performances investigations, it appears that for simple
> geometry process, the time used to convert from GAIA to GEOS geometry
> represent an important part.
>
> So, here is some questions :
>
> 1/ is there any way to decode a Spatialite BLOB to a GEOS geometry
> without decoding first to a GAIA geometry with the current Spatialite
> API ?
>

no, because it would be a completely nonsense: libspatialite
is a Spatial SQL engine, not a sparse collection of C API
intended to be called at random outside an SQL context.
every SQL function will obviously expect to receive its
geometry arguments (input) in the internal binary BLOB
format and will necessarily return (output) a geometry
in exactly the same BLOB format.

> 2/ if not, is it relevant to code it and integrate it in Spatialite
> source code (if I decide to code this method, I'll probably submit it
> for integration)
>

such a contribution will almost certainly be rejected, because it
has absolutely no sense and it completely negates the very basic
foundations of the internal data architecture.

you apparently seem to consider a SpatiaLite's own DB-file just
as a generic unqualified repository where to store arbitrarily
encoded geometries to be directly processed by some ad hoc
internal routine.
it's a completely misleading approach; SpatiaLite is a Spatial
SQL engine, and it's main purpose is to support Spatial
Processing by executing SQL functions and SQL queries.

> 3/ I've never worked with GAIA geometry, always with GEOS geometry
> (the Spatialite component went after GEOS integration in my
> application). Is there any "functionnal" difference between GAIA and
> GEOS geometry ?
>

they are "different", but very closely similar.
the main "functional" difference is in that GEOS does not
supports XYM and XYZM dimensions; just XY and XYZ are
supported.

just for the sake of curiosity: PostGIS too internally
encodes all geometries in its own "lwgeom" format, and
then silently converts back and forth from "lwgeom" to
GEOS when executing some SQL function requiring GEOS
support.
exactly as SpatiaLite does.

bye Sandro

[Aurélien Albert]

you apparently seem to consider a SpatiaLite's own DB-file just as a generic unqualified repository where to store arbitrarily encoded geometries to be directly processed by some ad hoc internal routine.

Yes

 

it's a completely misleading approach; SpatiaLite is a Spatial SQL engine, and it's main purpose is to support Spatial Processing by executing SQL functions and SQL queries.

In my application, I process geometries for different purpose : statistic computation, geometry transformations... Every geometry is defined as a GEOS geometry to take advantage of GEOS API. The processed geometries can be loaded from various data sources : WFS server, SHAPE file, OGDI datasets, client specific and proprietary data format...

Spatialite databases are just one of the many file formats handled.

Since my processing code is already existing and written using C++ and GEOS API, I can not rewrite it as SQL queries. And even if some processes can be re-coded this way, this is not possible for every one : some involve complex C++ code.

My question is motivated by the need to improve the processing of Spatialite databases in some specific cases.

 

 
they are "different", but very closely similar. the main "functional" difference is in that GEOS does not  supports XYM and XYZM dimensions; just XY and  XYZ are supported.

Thanks for this information, I didn't spotted this.

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

On Fri, 6 Nov 2015 12:04:21 -0800 (PST), Aurélien Albert wrote:
> In my application, I process geometries for different purpose :
> statistic computation, geometry transformations... Every geometry is
> defined as a GEOS geometry to take advantage of GEOS API. The
> processed geometries can be loaded from various data sources : WFS
> server, SHAPE file, OGDI datasets, client specific and proprietary
> data format...
>
> Spatialite databases are just one of the many file formats handled.
>

Hi Aurélien,

this latest informations make definitely clear your intended scopes;
you are not minimally interested to SpatiaLite itself (intended as
a Spatial DBMS) and you simply consider a SQLite db-file containing
SpatiaLite own BLOB geometries just as a generic input file.

all right, there is nothing wrong in this: there are other packages
already applying the same approach.
e.g. GDAL does not requires libspatialite support in order to
import data from a SpatiaLite DB (anyway libspatialite is
strictly required in order to export data into a SpatiaLite DB).
GDAL simply includes an internal module of its own intended to
translate a SpatiaLite BLOB geometry into an OGR binary geom
(the format internally adopted by GDAL/OGR) and it's all that
is needed in order to read data from a SpatiaLite backend.

adapting to your specific case: developing an internal function
directly returning a GEOS geometry from a SpatiaLite BLOB geom
can't realistically require more than one or two days.
after doing this your app 1) will no longer require to depend
on libspatialite 2) will probably run marginally faster.

here you can find a full technical description of the SpatiaLite
BLOB geometry format:
http://www.gaia-gis.it/gaia-sins/BLOB-Geometry.html

bye Sandro