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

Even Rouault even.rouault at mines-paris.org
Tue Mar 4 02:57:39 PST 2014


Selon Nik Sands <nixanz at nixanz.com>:

> You are correct - I did misunderstand.  Thanks for further explaining the
> multiple geometries to me.  :-)
>
> So it looks like the best option for me is to make a copy of each source
> layer which may contain both single and multi variants (eg, point and
> multipoint features) and make the new SQLite layer use the multi variant (eg,
> multipoint) and perhaps I will need to convert every single variant feature
> (eg, point) to the multi variant (eg, multipoint).
>
> I've written some code to try to do this but its rather long and clumsy (and
> doesn't actually work as yet).  I can't help but think there's got to be a
> better way and that I'm doing it all wrong.  Is there any precedent or
> preferred way that this should be done?
>
> I think that perhaps my understanding of the API is a bit lacking in this
> area.

Your understanding is OK. The fact is that the ogr2ogr source code offers more
transformations (such as -nlt) than what OGR_DS_CopyDataSource() can currently
do. One option for you would be to use/adapt ogr2ogr source code. It is FOSS too
!

>
>
> On 4 Mar 2014, at 8:31 pm, Jukka Rahkonen <jukka.rahkonen at mmmtike.fi> wrote:
>
> > 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.
> >
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>




More information about the gdal-dev mailing list