Opened 11 years ago

Closed 10 years ago

#2712 closed defect (fixed)

ST_Segmentize exception on Empty input: getPoint4d_p: point offset out of range

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 2.1.4
Component: postgis Version: 2.1.x
Keywords: Cc:

Description (last modified by robe)

This is similar to #2108

When I run below on:

SELECT postgis_full_version() || ' ' || version();
POSTGIS="2.1.2 r12389" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 64-bit

SELECT ST_Segmentize('LINESTRING EMPTY'::geometry, 0.5);

I get

ERROR:  getPoint4d_p: point offset out of range

Would seem to me that this should just return back a LINESTRING EMPTY.

Someone complained about a similar issue here: http://gis.stackexchange.com/questions/92552/postgis-error-getpoint4d-p-point-offset-out-of-range

Change History (3)

comment:1 by robe, 11 years ago

Description: modified (diff)

I was able to replicate the error with the data set in the stackexchange one, though I haven't tried in 2.0 to verify it is a new bug in 2.1. The final dataset that triggered the error does have a LINESTRING EMPTY row. Might be more than just LINESTRING EMPTY (such as how there ended up being a LINESTRING empty in first place). . Poster said this was not an issue in PostGIS 2.0. Ihaven't tried myself in a 2.0 install.

comment:2 by robe, 11 years ago

The starting chain that triggered the LINESTRING EMPTY was this:

 SELECT ST_AsText(ST_OffsetCurve('LINESTRING(1116773.8702957 7172132.24526899,1116768.15226771 7172128.54354244,1116752.61206679 7172126.30820484,1116742.74915991 7172090.05035972,1116746.60081429 7172083.8179674,1116759.05746531 7172082.54875741,1116767.82944119 7172087.37933384,1116770.23394219 7172116.41968508,1116768.15226771 7172128.54354244)'::geometry, 30));

Which returns a LINESTRING EMPTY. The linestring winds about itself. I was tempted to report that as a bug, but in retrospect, since the offset is so big relative to the line string and the offset would collapse into itself I don't think any valid linestring could ever be returned. -30 works just fine.

comment:3 by pramsey, 10 years ago

Resolution: fixed
Status: newclosed

Fixed in trunk at r12670, 2.1 at r12671

Note: See TracTickets for help on using tickets.