[gdal-dev] clipping linestrings with ogr2ogr may create points

[jratike80]

Hi,

I understand that it does not feel intuitive but the result is the same when
you compute an intersection for example with PostGIS

SELECT ST_AsText(ST_Intersection(ST_GeomFromText('LINESTRING ( 0 3, 3 8,
3.975762579723482 6, 6 9 )'),ST_GeomFromText('POLYGON (( 1 2, 1 6, 6 6, 6 2,
1 2 ))')));

Result:
GEOMETRYCOLLECTION(POINT(3.97576257972348 6),LINESTRING(1
4.66666666666667,1.8 6))

Geometrycollection is the only possibility if one input geometry must yield
one output geometry.  Ogr2ogr has already rather many options and your use
case may not be common enough for having its own switch.

If I had just to have the job done I would perhaps save the result first
into GeoPackage by using general geometries (-nlt geometry), re-run ogr2ogr
with -explodecollections into a new layer, and finally filter that by
geometrytype by using either the OGR SQL dialect or the SQLite dialect.

-Jukka Rahkonen-


kfj wrote
> Hi all!
> 
> I have a file with contour lines 'contour.shp' (made with gdal_contour) 
> which I want to clip with a rectangle. I was using this command to 
> obtain 'clipped.shp'
> 
> ogr2ogr -clipsrc 460000 5105000 465000 5110000 clipped.shp contour.shp
> 
> But whatever I tried, I got an error:
> 
> ERROR 1: Attempt to write non-linestring (GEOMETRYCOLLECTION) geometry 
> to ARC type shapefile.
> ERROR 1: Unable to write feature 84 from layer contour.
> ERROR 1: Terminating translation prematurely after failed
> 
> I took a good while to realize that the clipping actually produced a 
> single point, where one of the contours left the clipping rectangle, 
> came back to coincide with the clipping rectangle on this point and went 
> further out again.
> 
> The geometry looks like this:
> 
>            / <- linestring
>       *   /
>      / \ /
> ---*---*----  <- top of clipping rectangle
>    /    ^
>   /     | yields single point to the GEOMETRYCOLLECTION
> 
> So technically the result is correct. The single point is inside the 
> clipping rectangle, and therefore part of the output, which can't be 
> stored in the output shapefile because that already has linestrings in it.
> 
> I managed to avoid the problem by changing the clipping rectangle ever 
> so slightly:
> 
> ogr2ogr -clipsrc 460000.0001 5105000.0001 464999.9999 5109999.9999 \
>          clipped.shp contour.shp
> 
> And I can also save to other formats which can take several geometries, 
> like KML.
> 
> But I'm not quite happy with either of the solutions so I'd like to 
> discuss this issue. Are there maybe additional parameters to limit the 
> geometries resulting from clipping to linestrings, or to exclude 
> resulting isolated points from the output? If ogr2ogr were to output 
> linestrings an points separately instead of putting them in a 
> GEOMETRYCOLLECTION, I could use -skipfailures, but since the clipped 
> linestring is inside the GEOMETRYCOLLECTION, when using -skipfailures, 
> it is removed from the output as well - and missing contour lines on a 
> hillside stick out like a sore thumb.
> 
> So my issue is not strictly speaking a bug report, it's more about what 
> a user would expect when clipping a bunch of linestrings, namely to 
> receive back a bunch of linestrings, never mind geometrical correctness.
> 
> With regards
> Kay
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html