[postgis-users] PostGIS analogues to ArcInfo geoprocessing functions

[Stefan Keller]

> 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 <pramsey at opengeo.org>

> 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
> <chris.hermansen at timberline.ca> 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
> >>>>> <mbdavis at refractions.net> 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
> >>>>> postgis-users at postgis.refractions.net
> >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> > --
> > Regards,
> >
> > Chris Hermansen         mailto:chris.hermansen at timberline.ca
> > 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
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20090201/ba8000af/attachment.html>