Add shapeObj.DouglasPeuckerSimplifier() in MapScript?

[Steve Lime]

I'd vote to add a wrapper for these to mapgeos.c and then to
mapscript...

Steve

>>> Paul Ramsey <pramsey at REFRACTIONS.NET> 2/23/2007 6:12:53 PM >>>
Note that GEOS also has simplifying functions in it. A naive one, and a

"topology preserving" one that tries not to wreck polygons in the
process.

Steve Lime wrote:
> The API (that I knew about) is already exposed via mapscript. That
> generalization function
> is new to me. Easy enough to add to mapgeos.c and then mapscript.
> 
> Exposing it as a layer processing option is another matter and is a
> good fit for
> Tamas data adapter RFC. Note that I translated the Peucker algorithm
> from ESRI Avenue
> to MapScript (in perl) years ago (see
> http://mapserver.gis.umn.edu/community/scripts).
> 
> Steve 
> 
>>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 2/23/2007 4:35:01 PM
>>>>
> Daniel Morissette wrote:
>> We have a need to simplify (generalize) some shapefiles and we'll 
>> probably do that by hacking a local copy of MapScript to add a 
>> shapeObj.DouglasPeuckerSimplifier() that calls GEOS' 
>> DouglasPeuckerSimplifier() function.
>>
>> Should we consider integrating this new method in MapServer for
5.0?
> I 
>> realize that generalizing data is a bit off-topic for MapServer,
I'm
> 
>> sending this to find out whether others think this belongs in
> MapServer 
>> or not.
>>
>> Daniel
> 
> I think that exposing GEOS api via mapscript makes sense. A big part
of
> 
> working with mapserver is being able to prep the data that you will 
> ultimately serve. I think mapscript is a great way to do this. People

> that are already working with mapserver/mapscript could use it to do
a
> 
> variety of tasks in this area without having to download and learn
> other 
> tools. I do not think exposing these apis in mapscript should impose
a
> 
> lot of additional baggage on mapserver other than documenting them.
> 
> The other option might be to look at adding it to ogr or looking at a

> separate project to focused on building an opensource variant of 
> something like fme, which is probably outside the scope of your 
> immediate needs, but might be an interesting project none the less.
> 
> -Steve W


-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net 
   pramsey at refractions.net 
   Phone: 250-383-3022
   Cell: 250-885-0632