Chris,
When I originally determined the semantics for JTS for some reason I
thought that the OGC-SFS implied that two-point linestrings with both
points identical were invalid. Upon re-reading the spec I can't see
anything that actually states this. So perhaps this rule is overly
restrictive.
At least the situation is easy to check for and work around.
Martin
Chris Hermansen wrote:
Martin, everyone.
Just a coda to this noding problem.
As Martin pointed out, there is some exceedingly small nasty stuff in my
linework. In order to try to get rid of it, I tried both
st_simplify(the_geom,0.01) and st_snapToGrid(the_geom,0.01).
Both seemed to remove the problem, based on running st_union on the results.
st_simplify gave me back about half as many linestrings as st_snapToGrid.
The other thing that st_simplify gave me back was several linestrings,
which st_isValid() subsequently rejected with messages like:
NOTICE: Too few points in geometry component at or near point
1.2128e+06 906134
These seem to be two-point, zero-length linestrings, eg:
quesnel=# select numPoints(the_geom),length(the_geom) from step2b where
not isValid(the_geom);
numpoints | length
-----------+--------
2 | 0
2 | 0
2 | 0
...
Since the length of these linestrings is zero (or pretty close to it) I
decided to toss them in this case.
But I'm a bit puzzled as to the error messages from st_isValid(). I see
OGC docs that refer to "two point linestrings" so I'm not really sure
what st_isValid() is complaining about.
Does anyone have any ideas?
Martin Davis wrote:
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
