[postgis-users] noding problem

[Martin Davis]

Chris,

There's a big difference between "looks ok" and "IS ok".  I suspect 
there are very tiny discrepancies between lines which appear to be fully 
coincident at normal zoom levels.  This would be a typical result from 
intersecting polygons which are "adjacent" but in fact not fully noded 
together.

I can envisage some kind of data cleaning operation which would "snap" 
and "crack" nodes and line segments in a set of geometries according to 
a specified tolerance.  Would that solve your problem?  Currently 
there's nothing like this in PostGIS.  It would be an interesting 
project to design  it...

Chris Hermansen wrote:
> I have isolated my problem with noding but I still don't know what
> causes it, nor how to fix it.
>
> By a succession of selections through smaller and smaller windows, I
> have two tables; one with  38 linestrings, one with 25.  The 38
> linestring table causes the st_union() to barf; the 25 linestring table 
> passes through st_union() just fine.
>
> When I zoom right in on the offending point reported by st_union(), I
> don't see anything suspicious looking.  The linework in that location
> appears to result from two polygons adjacent to each other, so it looks
> like "one line" in the data viewer, from both data sets.
>
> Given that the linework "looks" ok, is there a procedure for "forcing"
> it to be OK, kind of like the buffer(0) trick for polygons, that could
> be used to clean it up prior to st_union()?
>
> Thanks in advance!
>
> Kevin Neufeld wrote:
>   
>> Can you isolate the geometry that is causing the error?  If geos is
>> broken, it would be nice to have a test case.
>> IE. Try noding half the lines at a time, then try noding half of a
>> half, etc...
>>
>> -- Kevin
>>
>> Chris Hermansen wrote:
>>     
>>> Hi folks;
>>>
>>> I posted something a few days back on a noding problem I'm having, and
>>> received no answer.  At this point I have more details and I think there
>>> is something seriously wrong.
>>>
>>> This is Postgis 1.3.1 and GEOS 3.0.0rc4.
>>>
>>> The Postgis Wiki has an example of putting two somewhat overlapping
>>> polygon networks together:
>>>
>>> http://www.postgis.org/support/wiki/index.php?ExamplesOverlayTables
>>>
>>> Basically, two tables of polygons are converted into linestrings and put
>>> in a third table.
>>>
>>> Then, the table of linestrings is noded; in the Wiki, the code given is:
>>>
>>> CREATE TEMP TABLE noded_lines AS
>>>    SELECT St_Union(the_geom) AS the_geom
>>>    FROM all_lines;
>>>
>>> Right, my problem!  I have two tables with multi-polygons.  I convert
>>> them to polygons.  I use isValid() on their geometries to make sure that
>>> they are in good shape.
>>>
>>> Then!  I run the "noding query" - which I might add takes a
>>> loooooooooooooooong time - and in the end I see:
>>>
>>> dustin=# create temp table step2 as
>>> dustin-# select st_union(geom) as geom from step1;
>>> NOTICE:  TopologyException: found non-noded intersection between
>>> 1.40568e+06 507100, 1.40568e+06 507100 and 1.40568e+06 507100,
>>> 1.40568e+06 507100 1.40568e+06 507100
>>> ERROR:  GEOS union() threw an error!
>>>
>>> OK, now to me this doesn't seem at all fair!  If the st_union() command
>>> is supposed to node the linework then WHY is complaining about non-noded
>>> intersections?
>>>
>>> Thanks in advance for any light you can shed on this!
>>>
>>>   
>>>       
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>     
>
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022