Selon Nik Sands <[email protected]>: > 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 <[email protected]> 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 > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
