[postgis-users] noding problem

[Martin Davis]

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
>>>> 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