[gdal-dev] Spatialite geometry format

[Simon Lyngby Kokkendorff]

Yes, it was after a call to:
OGR_G_SetPoint
that the geometry type was altered. Should really test if it's a 2.5D or 2D
geometry and use OGR_G_SetPoint_2D in the latter case!

Thanks,
SImon



On Mon, May 6, 2013 at 7:29 PM, Simon Lyngby Kokkendorff
<silyko at gmail.com>wrote:

> 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 <even.rouault at mines-paris.org
> > wrote:
>
>> Selon Simon Lyngby Kokkendorff <silyko at gmail.com>:
>>
>> > 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
>> >
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130506/c605760e/attachment.html>