Thanks to everybody who helped me towards getting this working - it is now working correctly. The conversion process is a little slow for large data sets, but the results are excellent, and the Spatialite databases are MUCH faster for spatial filtered lookups than the Shapefiles I had been using before.
In the end it turns out that I had my code very nearly correct before looking at the code in ogr2ogr from which I then corrected my previous cludgy force-to-multi code to the following: OGR_F_SetGeometryDirectly(feature, OGR_G_ForceToMultiPoint(OGR_F_StealGeometry(feature))); (and other variants depending on the geometry type, of course). On 4 Mar 2014, at 9:58 pm, Nik Sands <nix...@nixanz.com> wrote: > Thanks for this information. > > I'd like to replicate that ogr2ogr PROMOTE_TO_MULTI functionality in my code, > but I'm having trouble figuring out how to do it. I guess I can take a look > at the ogr2ogr code. > > (I could also just include the entire ogr2ogr tool bundled into my app and > call it from the app, but that seems a bit of overkill for an iOS app, which > is best as lean as possible.) > > > On 4 Mar 2014, at 9:50 pm, a.furi...@lqt.it wrote: > >> Hi all, >> >> just yo better clarify some relevant details: >> >> a Shapefile can legitimately contain one the following shapes: >> Point, PolyLine, Polygon and MultiPoint; and there are further >> shape-codes intended to support extended XYZ or XYM dimensions, >> such as PointZ and PolyLineM >> >> please note: accordingly to the SHP model there is a very strong >> distinction between Point and MultiPoint; but a PolyLine can >> indifferently contain just a single line or a collection of >> many individual lines, and the same is for Polygons. >> >> on the opposite side, the standard OGC-SFS data model supports >> the following geometry classes: >> Point, Linestring, Polygon, MultiPoint, MultiLinestring, >> MultiPolygon and GeometryCollection; in this case too we have >> further classes supporting extending XYZ, XYM and XYZM >> dimensions, such as PointZ, LinestringM or PolygonZM. >> >> please note: the OGC-SFS model introduces a very sharp distinction >> between e.g. Linestring and MultiLinestring; a Linestring can >> contain just a single line, a MultiLinestring can contain any >> arbitrary number of individual lines ... THIS INCLUDING JUST ONE !!! >> and the same is for Point/MultiPoint and Polygon/MultiPolygon. >> >> quick conclusion: SHP geometry types doesn't exactly match >> OFC-SFS types, and there is enough room to introduce some >> dangerous inconsistency, e.g.: >> >> - the SHP PolyLine type could possibly match the Linestring type >> if (and only if) all PolyLines into the SHP will contain just >> a single line. >> - when some SHP PolyLine does actually contain more individual >> lines a MultiLinestring will always be required on the OGC-SFS >> side >> - anyway OGC-SFS MultiLinestring will always exactly match the >> SHP PolyLine type, even in the case of "mixed" Polylines >> sometimes being elementary and sometimes being complex. >> - the same considerations obviously apply to Polygon/MultiPolygon >> - conclusion: always assuming a Multi?? type is the safest approach, >> if you aren't absolutely sure about the actual SHP payload. >> >> ogr2ogr does actually has an argument nicely supporting >> all this (just pasted from the ogr2ogr man page): >> >> -nlt type: >> Define the geometry type for the created layer. >> One of NONE, GEOMETRY, POINT, LINESTRING, POLYGON, >> GEOMETRYCOLLECTION, MULTIPOINT, MULTIPOLYGON or >> MULTILINESTRING. Add "25D" to the name to get 2.5D >> versions. Starting with GDAL 1.10, PROMOTE_TO_MULTI >> can be used to automatically promote layers that mix >> polygon or multipolygons to multipolygons, and layers >> that mix linestrings or multilinestrings to multilinestrings. >> Can be usefull when converting shapefiles to PostGIS >> (and other target drivers) that implements strict checks >> for geometry type. >> >> it works for PostGIS, and it works for SpatiaLite as well. >> >> bye Sandro >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev