[postgis-users] PostGIS analogues to ArcInfo geoprocessing functions

[Chris Hermansen]

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