Given my headspace on cleaning up the crummy data I recently received, I'm not at all disappointed to receive a warning that I have some two-point, zero-length lines, and it certainly seems harmless to remove such creatures from my linework.
When I first saw the message I thought "oh these should be LINEs, not LINESTRINGs"... old Microstation synapses firing there :-) Martin Davis wrote: > 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 >>>>> >>>> >> >> >> > -- Regards, Chris Hermansen · mailto:[EMAIL PROTECTED] 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. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
