[gdal-dev] Missing features after copying layers from Shapefiles to SQLite

Jukka Rahkonen jukka.rahkonen at mmmtike.fi
Tue Mar 4 01:31:47 PST 2014


Nik Sands <nixanz <at> nixanz.com> writes:

> 
> Thanks Chaitanya,
> It's finally dawned on me that this is what the following is about in the
OGR SQLite format web page:
> 
> 
> Tables with multiple geometries
> Starting with OGR 1.10, tables that have multiple geometry columns
registered in geometry_columns can be used by OGR. For such tables, there
are as many OGR layers exposed as there are geometry columns. They are named
"table_name(geometry_column_name)".Note: this support is limited to
read-only operations.
> 
> Ah... so multiple geometries are NOT avaiable in this format for writable.
> 
> Your idea of forcing all geometries to multies is a good idea.  I'll have
to figure out the most efficient way to do this when converting an entire
layer at a time, but it's likely to be much better than the way I'm
currently doing it and would result in the same number of layers as the
original, which is preferable, especially when the user wants to manage
drawing styles for layers.
 
> Thanks for your idea.  I'm very grateful.

Hi,

You perhaps understood wrong what was said about multiple geometries.
Multipolygon is a single geometry. Multiple geometry columns means a
situation when one feature has many geometries, for example a polygon
geometry, simplified polygon geometry and point geometry presenting the
centroid of the polygon. All in one row in a same table but in three
geometry columns.

I think also that a standard solution in to create multilinesting and
multipolygon tables into Spatialite and write also simple geometries as
multivariants. Principally same for multipoints, but at least in data I
usually use such do not exist. But you know your data and can decide. It is
also possible to create a Spatialite table with a generic "GEOMETRY"
geometry type. Such table accepts all kind of geometries but it may me
tricky to use data in applications.

-Jukka Rahkonen-

> 
> Cheers,
> Nik.





More information about the gdal-dev mailing list