Re: [Geotools-devel] Mini-proposal: new FeatureSource Hint dealing with in-datastore generalization

[Andrea A. <aa...@op...>]

Christian Müller ha scritto:
> Hi Andrea, a quick question about the proposed concept
> Concerning the 2 hints
> Hints.GENERALIZATION_DISTANCE
> Hints.PRESERVE_TOPOLOGY
> The idea is, that the renderer or any other component check if a 
> FeatureSource supports these 2 hints. If it does, the component 
> delegates the generalization/decimation job to the FeatureSource.
> Otherwise, the calling component does the decimaion for itself.
> True or false ?

Hmmm... good question.

The renderer probably wants both for a performance reason
(I don't know of any fast and topology preserving generalization
algorithm), but will probably do the
generalization in memory anyways, just because I don't want to
change the code drastically in a stable series (data access
and in memory generalization are in two very distant places code
wise). Thought I may try to fix that in trunk where there are
no expectations of stability, and thus avoid the in memory 
generalization if the data source can deal with it.

Hmmm.... it could be argued that if the data source is connected
using a very slow link then even a topology preserving algorithm
would be ok (e.g., cascading a remote GeoServer WFS with a store
that does know how to use the generalization vendor parameter),
so maybe the renderer is better off checking just the
GENERALIZATION_DISTANCE parameter support?

WFS will check if both are supported thought, as it needs topologically
valid data, so either both are supported, or an in memory generalization
will occurr.

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.