<div>> Some geoprocessing activities that are easy to do in ArcInfo are more-or-less as easy to do in PostGIS. <br></div>
<div>That caused another question I have regarding PostGIS: Is there any documentation around to help ArcGIS users learn PostGIS (and probably vice versa)? I'm thinkin about a listing or table similar (but function by function) like [1]</div>
<div> </div>
<div>- S.</div>
<div> </div>
<div>[1] <a href="http://www.bostongis.com/PrinterFriendly.aspx?content_name=sqlserver2008_postgis_mysql_compare">http://www.bostongis.com/PrinterFriendly.aspx?content_name=sqlserver2008_postgis_mysql_compare</a></div>
<div> </div>
<div class="gmail_quote">2009/1/30 Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Well, for sparse vs non-sparse, Martin's still-dreamy<br>PreparedIntersection() enhancement might actually make a good effect.<br>
<font color="#888888"><br>P<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br>On Thu, Jan 29, 2009 at 5:44 PM, Chris Hermansen<br><<a href="mailto:chris.hermansen@timberline.ca">chris.hermansen@timberline.ca</a>> wrote:<br>> I too would hope for someone to spend some quality time on this<br>
> problem. Here are a few other related thoughts:<br>><br>> * GOAI (that's Good Old ArcInfo, you know the one with AML, not the<br>> one that only runs on that funny O/S from WA) has pretty archaic<br>
> geoprocessing stuff built in, generally. For example, CLEAN<br>> (which will sometimes take a collection of points and linestrings<br>> and form a polygon network) has some serious limitations on the<br>
> amount of stuff it can process and its ability to deal with small<br>> infelicities in the data. Also, I don't think the code for UNION<br>> has changed much since, oh, 1987 or so... or maybe before that<br>
> even. I wonder if it's still FORTRAN...<br>> * I don't know if there is a canonical use case for the geometric<br>> union of two polygon themes. however, it's often used to overlay<br>
> a sparse theme of "areas of interest" or "planning units" or<br>> "special habitat zones" or "steep slopes" over a non-sparse theme<br>> of "forest" or "soils". In the GOAI context of course this is<br>
> done on a map-sheet by map-sheet basis, which is a wonderfully<br>> rudimentary form of spatial indexing. nevertheless, the sparse<br>> polygons are probably of similar size to the non-sparse polygons,<br>
> so a given "steep slope" polygon might overlap a few, or a few<br>> tens of, "soils" polygons. Lots of opportunity to reduce the<br>> amount of intervention required in these cases, rather than<br>
> blindly unravelling all the polygons from both themes into topology.<br>> * In the case of two non-sparse inputs, st_intersection() works as<br>> well as a geometric union would, so another possibility is to<br>
> "complete" the sparse polygon layer with a "world polygon" and<br>> then use st_intersection()<br>><br>> Maybe in my copious spare time I'll come up with a couple of test data<br>
> sets and do some testing on them...<br>><br>> Martin Davis wrote:<br>>> Chris, generally I agree (especially if the code is written in<br>>> Java... 8^). After I posted this I started thinking that probably a<br>
>> few more minutes/hours/days splunging through the C code would no<br>>> doubt reveal much about how it actually works. At the moment however<br>>> I can't even tell if it is memory-only or whether it uses external<br>
>> files to hold intermediate results!<br>>><br>>> I look forward to some cleverer programmer than me figuring out how to<br>>> integrate the Grass code with PostGIS...<br>>><br>>> Chris Hermansen wrote:<br>
>>> Martin, Martin, Martin: code is the best documentation there is! and<br>>>> besides, it's not written in Perl so how bad can it be :-)<br>>>><br>>>> Martin Davis wrote:<br>>>><br>
>>>> Have you looked at the code? I rest my case....<br>>>>><br>>>>> Paul Ramsey wrote:<br>>>>><br>>>>>> On Thu, Jan 29, 2009 at 8:42 AM, Martin Davis<br>>>>>> <<a href="mailto:mbdavis@refractions.net">mbdavis@refractions.net</a>> wrote:<br>
>>>>><br>>>>>><br>>>>>>> The basic approach to computing polygon overlays has been<br>>>>>>> well-understood<br>>>>>>> for a long time (although this does not imply well-documented!). The<br>
>>>>>> implementation however is quite tricky, especially if performance and<br>>>>>>> robustness is required. There is a notable lack of open-source<br>>>>>>> existing<br>
>>>>>> implementations - which should be an indication of just how<br>>>>>>> difficult this<br>>>>>>> really is.<br>>>>>>><br>>>>>> I believe the vector component of GRASS includes overlay (and of<br>
>>>>> course the raster component does too).<br>>>>>><br>>>>>> <a href="http://grass.itc.it/grass64/manuals/html64_user/v.overlay.html" target="_blank">http://grass.itc.it/grass64/manuals/html64_user/v.overlay.html</a><br>
>>>>><br>>>>>> P.<br>>>>>> _______________________________________________<br>>>>>> postgis-users mailing list<br>>>>>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>>>>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>>>>>><br>>>>>><br>
>>><br>>>><br>>>><br>>><br>><br>><br>> --<br>> Regards,<br>><br>> Chris Hermansen mailto:<a href="mailto:chris.hermansen@timberline.ca">chris.hermansen@timberline.ca</a><br>
> tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644<br>> Timberline Natural Resource Group · <a href="http://www.timberline.ca/" target="_blank">http://www.timberline.ca</a><br>> 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5<br>
><br>> _______________________________________________<br>> postgis-users mailing list<br>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br>