[Gdal-dev] downsampling shapefiles ?

[Pete Nagy]

I wrote a DP-like algorithm in c that also ensures the results do not
cross or have spurs, which for speed required a grid of polygon edges so
that only a subset of edges needed to be checked for the crossing
condition.  It also would have been nice to make sure that neighboring
polygons with shared edges could have been generalized together to
preserve the edge, so that snapping afterwards would not be needed, but I
did not go that far.  It would be a nice feature though if neighboring
countries retained nice borders after simplification!  Something to think
about if someone adds this - maybe I will some day but I'm booked now.

Cheers,

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Sat, 10 Sep 2005, Frank Warmerdam wrote:

> On 9/10/05, Schuyler Erle <schuyler at nocat.net> wrote:
> > I've been thinking about this myself -- I implemented Douglas-Peucker
> > simplification in OGR + Python, and it was pretty slow.
> >
> > I note that ogr2ogr could act as a command-line "filter" for vector
> > layers. Frank, how do you feel about the idea of having a plugin
> > architecture for ogr2ogr, so that a user could (say) specify a -plugin
> > option on the command line that dynamically loads an .so file at run
> > time. The plugin library would have hooks to parse command-line
> > options, and to take an OGR geometry from the input layer and have the
> > opportunity to return a different OGR geometry to be written to the
> > output layer? Line simplification is one possible use for this; vector
> > warping is another (which may not be that common of an operation, but
> > it is one I've had to contend with in the not-too-distant past)... I'm
> > sure we can collectively think of others.
>
> Schuyler,
>
> I don't think I would want to implement a plugin architecture for
> ogr2ogr itself.  It is just a (not very pretty) utility.  What might have
> better leverage is doing something similar for the OGR VRT format.
> So an OGR VRT datasource could include a pointer to an external
> plugin shared library that could apply various kinds of processing
> to the features going through the VRT.
>
> You could do this now by implementing a new format driver as
> a plugin, but then you are stuck implementing alot of extra driver
> logic.  A VRT plugin might be much simplified.  Just a function
> that receives OGRFeature's and can morph the feature or geometry
> as it wishes, possible removing or returning multiple features.
>
> Nevertheless, I think it would be better to build some broadly useful
> functions (like generlization) directly into OGR.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>