[postgis-users] noding problem
Martin Davis
mbdavis at refractions.net
Wed Oct 24 17:27:43 PDT 2007
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
More information about the postgis-users
mailing list