<div dir="ltr">Hi,<div>I am dealing with the same types of data and issues as Jeff.</div><div>My procedure for data clean up is: </div><div>1) CSV files into PostGIS as points</div><div>1.1) ST_TRANSFORM to projected spatial reference (here EPSG:32621 / UTM zone 21 N WGS84)</div><div>2) ST_MAKELINE to "sub"-lines via PARTITION BY</div><div>3) Create a gridded polygon layer in same srid</div><div>4) Run equivalent to select cell_id, line_id from cells, lines where intersects(lines.geom, cells.geom </div><div>- but my postgis runs out of memory after a while. And I am sorry to say Spatial Analyst doesn't.</div><div>Is there more memory cheap way to do it in PostGIS (e.g. via the raster functions - although I haven't found i yet).</div><div><br></div><div>Karl</div><div><br>Den onsdag den 26. december 2012 09.58.43 UTC-3 skrev Jeff Adams - NOAA Affiliate:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Brent,<br><br>Thanks for the response. I don't think your original response made it into my inbox via the list, but now I see it on the website thread. That seems like it might be a viable alternative, I just worry about those vessel tracks that would be clearly outside of a particular grid cell, but whose buffer would bleed over. How did you handle this type of situation?<br>
<br>Jeff<br><br><div class="gmail_quote">On Mon, Dec 24, 2012 at 7:22 PM,  <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="xIMxnzyt3c4J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">pcr...@pcreso.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font:inherit" valign="top">Jeff,<br><br>Did you see my reply using vessel tracklines as vectors & a grid in Postgis to do exactly what you describe?<br>
<br>Given we were looking at benthic impact, we buffered the tracklines to create polygons representing the swept area of the deployed fishing gear. These were clipped by the cells, & we could generate statistics suca as the cumulative swept area of all tracks with each cell, number of times each cell was crossed, & given the tracklines have a timestamp associated with them, we could also look at the temporal pattern of tracks crossing cells, for things like seasonal impacts & variation between seasons. <br>
<br>Cheers,<br><br>  Brent Wood<br></td></tr></tbody></table></blockquote></div>
</blockquote></div></div>