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. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
