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
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
