> Hello Nicolas,<br>> thank you for the reply. I don't have enough experience with postgis to<br>> understand how your suggestion helps.<br>> Do you suggest to loop over all linestrings (which is really slow!) after<br>
> st_dumppoints, or is there a single command that does the snapping at once?<br>> What is the advantage of the intermediate points table? st_snap works with a<br>> given tolerance, or st_distance can help to select close-by lines... where<br>
> do the points come in?<br>><br><br>I find useful to explode a linestring into its points to be able to identify pseudo-parallel lines: st_distance is not enough as perpendicular, touching lines will return 0 for the distance though they are not close to each other at each location.<br>
If all linestring points are within a given distance to a line, then chances are good these 2 lines are aligned.<br><br>This dump will be quite fast, though it will generate a big table (500 000 linestrings are still light to work with).<br>
st_snap will reduce precision for all your dataset. To identify lines that should be snapped or removed, the comparison between original lines and the point-dumped counterparts will be useful:<br><br><font face="courier new, monospace">-- creates the points table. Test contains original linestrings</font><div>
<div><font face="courier new, monospace">create table line_points as (</font></div><div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">     </span>select gid, (st_dumppoints(geom)).* </font></div>
<div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">  </span>from test</font></div><div><font face="courier new, monospace">);</font></div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace">-- finds all lines whose all points are closer than 50 meters to other lines</font></div><div><div><font face="courier new, monospace">with close_points as (</font></div>
<div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">  </span>select t.gid, l.gid as lgid, count(l.path[2])</font></div><div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">       </span>from test t, line_points l</font></div>
<div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">  </span>where st_dwithin(t.geom, l.geom, 50)</font></div><div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">        </span>and t.gid <> l.gid</font></div>
<div><font face="courier new, monospace"><span class="Apple-tab-span" style="white-space:pre">  </span>group by t.gid, lgid</font></div><div><font face="courier new, monospace">) select t.gid, t.geom </font></div><div><font face="courier new, monospace">from close_points c, test t </font></div>
<div><font face="courier new, monospace">where count = st_npoints(t.geom)</font></div><div><font face="courier new, monospace">and t.gid = c.lgid;</font></div></div><div><br></div>As said, this naive approach does not deal well with segmentized linestrings. It may then be useful to union these linestrings based on road attributes to generate "long" streets.</div>
<div><br>Nicolas </div>