Hi Even, I think you're right. The transformation seems to alter the geometry type somehow - need to debug a little more to see exactly what's going on.
Thanks, Simon On Mon, May 6, 2013 at 3:50 PM, Even Rouault <[email protected]>wrote: > Selon Simon Lyngby Kokkendorff <[email protected]>: > > > Hi List, > > > > I am programming an application which can transform ogr-datasources > > (using our own transformation library). In that process I use ogr > (version > > 1.10) via the c-api to read and write datasources - usually it works > like > > a charm. However, when I try to write an output spatialite datasource, I > > run into this error: > > > > sqlite3_step() failed: > > > > points2.GEOMETRY violates Geometry constraint [geom-type or SRID not > > allowed] (19) > > > > > > I am not sure whether it's an issue with the SRID or the geom-type / > > format. I also see on the ogr-drivers page, that spatialite use a speciel > > (wkb like?) format for the geometry column. > > Yes, but this is an implementation detail from the point of view of users > of > OGR, that is hidden by the OGR API. > > > > > > > What I usually do is to clone an input feature, clone the geometry: > > > > > > hGeometry = OGR_G_Clone(OGR_F_GetGeometryRef(hFeature_out)); > > > > > > perform some transformations and set the geometry (again): > > > > > > OGR_F_SetGeometryDirectly(hFeature_out,hGeometry); > > > > > > While this works for (most) input and output datasources, it produces the > > error above for spatialite output. Perhaps because the internal geometry > > reperesentation is wrong, or there is some other more strict check of > > output srs - e.g. should I use OGR_G_AssignSpatialReference to assign > the > > output spatial reference to the geometry? > > > > > > Is there something obvious that I am missing here? > > The driver takes responsibility of assigning the SRID automatically from > the > layer SRS. So the error is likely due to an attempt of inserting a geometry > whose type doesn't match the layer geometry type. Spatialite is really > strict on > that: POLYGON != MULTIPOLYGON, and (perhaps I'm not sure) 2D != 2.5D > > > > > > > Best Regards, > > > > Simon Kokkendorff, Danish Geodata Agency > > > > >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
