Opened 14 years ago

Closed 13 years ago

#326 closed defect (fixed)

Linemerge fails when fed zero-length lines

Reported by: mloskot Owned by: strk
Priority: major Milestone:
Component: Core Version: 3.1.0
Severity: Significant Keywords:
Cc:

Description

User xreal reported problem on IRC #geos channel that linemerge fails when fed zero-length lines

Paul said: that should be a pretty easy pre-test to add to linemerge (if zero-length, ignore)

Full story to grasp the context:

<xreal> http://paste.pocoo.org/show/172706/


SELECT name, (ST_Dump(merged_geom)).geom
FROM (
     SELECT name, ST_LineMerge(ST_Collect(linestring)) AS merged_geom
     FROM wherami
     WHERE linestring && SetSRID('BOX3D(7.5 50.0, 10.0 51.5)'::box3d, 4326)
     GROUP BY name
     ) AS subq;

<xreal> This is crashing my PostgrSQL-database on and on.
<xreal> Is the subquery getting too big?
<xreal> But why does it crash and restart in recovery mode?
<mloskot> have you tried without ST_Dump
<mloskot> ?
<xreal> No, let me try again.
<xreal> BTW: Here is the logfile: http://paste.pocoo.org/show/172712/
<xreal> without ST_Dump: Same problem.
<xreal> Wow, I didn't notice that log entry:
<xreal> many [local] EXPLAIN: CoordinateArraySequence.cpp:111: virtual const geos::geom::Coordinate& geos::geom::CoordinateArraySequence::getAt(size_t) const: Assertion `pos < vect->size()' failed.
<mloskot> xreal:  so, here we go, geos assertion caught
<xreal> mlsokot: How can I interpret it?
<mloskot> simply, index of coordinate being requested is out of range
<mloskot> ie. you have 3 coordinates in vector but you ask for 4th
<xreal> The funny thing: It works with a smaller BBOX ...
<pramsey> xreal: linemerge isn't broken in general :)
<pramsey> just in the case of the particular data you are handing it
<xreal> Is there a buggy coordinate set in my table?
<mloskot> xreal:  I'm afraid but without backtrace it may be very difficult to find out who exactly makes a mess
<xreal> to all: I want to merge all connected lines with the same name. Is this the right way to go?
<pramsey> yes.
<pramsey> however it won't work correctly unless the lines are noded first
<xreal> pramsey: Pardon, what does noded first mean?
<pramsey> they only touch at end points
* pramsey tries to remember the incantation that does a bulk noding operation. This might be a good question for postgis-users
<pramsey> in general though, you shouldn't be getting exceptions out of LineMerge, so finding the minimal set that generates the problem would be nice.
<xreal> pramsey: That's too high for me, I think ;-)
<xreal> pramsey: So I have to do Try and Error?
<pramsey> only if you want someone to look at the problem and fix it eventually
<pramsey> basically a problem will only get fixed if a developer can reproduce it locally
<pramsey> and that requires exact inputs, and the smaller the inputs the more likely people will look at it.
<pramsey> the best tickets in the postgis trac instance just have a line of SQL one can cut and paste
<xreal> pramsey: Of course I want to help fixing it ... I need this function ;-)
<xreal> The problem must be somewhere in this bbox: 7.1 51.0, 7.15 51.2
<xreal> Let me try further.
<wildintellect> pramsey, a good place to get ideas for line simplification http://mapshaper.org I'm sure we can find reference papers for the algorithms there
<xreal> Somewhere here: 7.11 51.0, 7.12 51.05
<xreal> shall I check the linestrings for valitidy?
<pramsey> lines are always valid
<pramsey> they might not be simple
<xreal> pramsey: Can you give me a hint, how to check this?
<xreal> WOW
<xreal> NOTICE:  Too few points in geometry component at or near point 7.1197 51.0164
<xreal> But there are no ST_Numpoints < 3 ...
<pramsey> st_issimple(geom)
* pramsey re-locates
* pramsey has quit (Quit: pramsey)
* ovaltofu (~vajda@nat08.metaweb.com) has joined #postgis
* ovaltofu has quit (Client Quit)
<xreal> Can anyone help me understanding the problem please?
<xreal> uh wait ... can the be two-point, but zero length?
<xreal> YESS!
<xreal> There is a zero-length linestring.
* X-Ray has quit (Ping timeout: 252 seconds)
* X-Ray (~kvirc@85.26.164.150) has joined #postgis
* pramsey (~pramsey@96.54.174.33) has joined #postgis
<xreal> pramsey: I fixed it!
<pramsey> how?
<xreal> ... zero length ...
<xreal> a linestring with >= 2 points, but zero length
<xreal> pramsey: So, end-to-end linestrings cannot be merged?
<pramsey> could you file a ticket in GEOS noting that linemerge fails when fed zero-length lines?
<pramsey> that should be a pretty easy pre-test to add to linemerge (if zero-length, ignore)

Environment:

PostgreSQL 8.3
PostGIS 1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
GEOS 3.1.0-CAPI-1.5.0

Change History (3)

comment:1 by imincik1, 14 years ago

Hi, I can confirm this bug. ST_LineMerge is crashing my PostgreSQL server until removing features with zero length.

select postgis_full_version();

postgis_full_version


POSTGIS="1.3.5" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS

(1 row)

PostgreSQL 8.3, Debian Lenny

comment:2 by strk, 14 years ago

Is this enough to crash ?

select st_linemerge('GEOMETRYCOLLECTION(LINESTRING EMPTY)');

If it is, sounds fixed here:

 POSTGIS="2.0.0SVN" GEOS="3.3.0-CAPI-1.6.1" 

Most likely also fixed with GEOS-3.2

comment:3 by strk, 13 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.