<div dir="ltr">Yes, it was after a call to:<div style>OGR_G_SetPoint</div><div style>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!</div>
<div style><br></div><div style>Thanks,</div><div style>SImon</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 7:29 PM, Simon Lyngby Kokkendorff <span dir="ltr"><<a href="mailto:silyko@gmail.com" target="_blank">silyko@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Even, <br><br></div>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.<br>
<br></div> Thanks,<br>
</div>Simon<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 3:50 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Selon Simon Lyngby Kokkendorff <<a href="mailto:silyko@gmail.com" target="_blank">silyko@gmail.com</a>>:<br>
<div><br>
> Hi List,<br>
><br>
>    I am programming an application which can transform ogr-datasources<br>
> (using our own transformation library). In that process I use ogr (version<br>
> 1.10)  via the c-api to read and write datasources - usually it works like<br>
> a charm. However, when I try to write an output spatialite datasource, I<br>
> run into this error:<br>
><br>
> sqlite3_step() failed:<br>
><br>
> points2.GEOMETRY violates Geometry constraint [geom-type or SRID not<br>
> allowed] (19)<br>
><br>
><br>
> I am not sure whether it's an issue with the SRID or the geom-type /<br>
> format. I also see on the ogr-drivers page, that spatialite use a speciel<br>
> (wkb like?) format for the geometry column.<br>
<br>
</div>Yes, but this is an implementation detail from the point of view of users of<br>
OGR, that is hidden by the OGR API.<br>
<div><br>
><br>
><br>
> What I usually do is to clone an input feature, clone the geometry:<br>
><br>
><br>
> hGeometry = OGR_G_Clone(OGR_F_GetGeometryRef(hFeature_out));<br>
><br>
><br>
> perform some transformations and set the geometry (again):<br>
><br>
><br>
> OGR_F_SetGeometryDirectly(hFeature_out,hGeometry);<br>
><br>
><br>
> While this works for (most) input and output datasources, it produces the<br>
> error above for spatialite output. Perhaps because the internal geometry<br>
> reperesentation is wrong, or there is some other more strict check of<br>
> output srs - e.g. should I use  OGR_G_AssignSpatialReference to assign the<br>
> output spatial reference to the geometry?<br>
><br>
><br>
> Is there something obvious that I am missing here?<br>
<br>
</div>The driver takes responsibility of assigning the SRID automatically from the<br>
layer SRS. So the error is likely due to an attempt of inserting a geometry<br>
whose type doesn't match the layer geometry type. Spatialite is really strict on<br>
that: POLYGON != MULTIPOLYGON, and (perhaps I'm not sure) 2D != 2.5D<br>
<div><div><br>
><br>
><br>
> Best Regards,<br>
><br>
> Simon Kokkendorff,  Danish Geodata Agency<br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>