[postgis-users] noding problem

[Chris Hermansen]

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
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>     
>>
>>
>>   
>


-- 
Regards,

Chris Hermansen · mailto:clh at timberline.ca
tel:+1.604.714.2878 · fax:+1.604.733.0631
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5

C'est ma façon de parler.