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