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 , 14 years ago
comment:2 by , 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 , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Hi, I can confirm this bug. ST_LineMerge is crashing my PostgreSQL server until removing features with zero length.
select postgis_full_version();
(1 row)
PostgreSQL 8.3, Debian Lenny