<div dir="ltr">Would it help to avoid processing lines which are already short?  (Hard to know without knowing the actual data size distribution).<div><br></div><div>Also, ST_LineMerge seems like it might be expensive.  Is is possible to avoid merging lines?  (This is creating longer lines, which seems like opposite to the point of the exercise) </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2019 at 1:33 PM Stephen Woodbridge <<a href="mailto:stephenwoodbridge37@gmail.com">stephenwoodbridge37@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I have a global dataset in SRS EPSG:4326 that are ocean depth contours. <br>
The problem is that these tend to be long and have huge bbox so spatial <br>
index does not help when trying to render them in mapserver.<br>
<br>
I plan was to chop these into shorter segments with a command like:<br>
<br>
bathymetry=# explain select depth,<br>
         feet,<br>
         st_linesubstring(geom, 0.5*n/length,<br>
         case when 0.5*(n+1)<length then 0.5*(n+1)/length else 1 end) as <br>
geom<br>
     from (<br>
         select a.depth,<br>
             -round(a.depth/0.3048) as feet,<br>
             st_linemerge(a.geom) as geom,<br>
             st_length(a.geom) as length<br>
         from c100 a<br>
         where st_length(a.geom)>0<br>
     ) as t<br>
     cross join generate_series(0,10000) as n<br>
     where n*0.5/length < 1;<br>
                                                 QUERY PLAN<br>
-----------------------------------------------------------------------------------------------------------<br>
  Nested Loop  (cost=0.00..549466002.55 rows=1345242667 width=1723)<br>
    Join Filter: (((((n.n)::numeric * 0.5))::double precision / <br>
st_length(a.geom)) < '1'::double precision)<br>
    ->  Seq Scan on c100 a  (cost=0.00..1279615.77 rows=4035728 width=1719)<br>
          Filter: (st_length(geom) > '0'::double precision)<br>
    ->  Function Scan on generate_series n  (cost=0.00..10.00 rows=1000 <br>
width=4)<br>
(5 rows)<br>
<br>
but running a restricted test query on 10,000 lines took 1.5 hours and <br>
with about 12M lines in the source table I estimate about 75 days to <br>
compute :(<br>
<br>
The 0.5 in the query is for 1/2 degree (~35 mile) max length. I can <br>
adjust that to say 1 deg but I suspect that will only nominally impact <br>
the run time (running a test to see).<br>
<br>
So is there a faster way to do this?<br>
<br>
Would smoothing the lines first help or would the cost of smooth and <br>
then dividing be about the same?<br>
<br>
-Steve W<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div>