To say it in your words Hmmmmmmmmm.......... there is something missing.
Scenario 1) A data source supports Hints.GENERALIZATION_DISTANCE but does NOT support Hints.PRESERVERE_TOPOLOGY. This indicates that the data source has some precalculated, topological correct generalizations which it will return. The final generalization is handled by the renderer/wfs client. Scenario 2) A data source supports Hints.GENERALIZATION_DISTANCE AND supports Hints.PRESERVERE_TOPOLOGY. This indicates that the data source returns already generalized geometries, no final generalization takes place in the renderer/wfs client. Unfortunately, this implies that the data source must be able to do both types of generalization, and this is not alway the case I am thinking about the jdbc-ng-db2 data source, where I have the possibility to call a db2 sql function ST_GENERALIZE(geom,distance) for the preserving generalization, but I have no possibility to do the type of generalization needed for the renderer. ( Unless I register a db2 stored procedure using the Decimation class, but this is a special feature). I think we need a third hint Hints.IGNORE_TOPOLOGY and we have the following valid combinations Scenario 1) Hints.GENERALIZATION_DISTANCE Scenario 2a) Hints.GENERALIZATION_DISTANCE,Hints.PRESERVERE_TOPOLOGY Data store supports topological correct generalization Scenario 2b) Hints.GENERALIZATION_DISTANCE,Hints.IGNORE_TOPOLOGY Data store supports topological incorrect generalization Scenario 2c) Hints.GENERALIZATION_DISTANCE,Hints.PRESERVERE_TOPOLOGY,IGNORE_TOPOLOGY Data store supports both kinds of generalization And finally , if a datastore supports Hints.GENERALIZATION_DISTANCE, always use it. This is interesting for 2a) and 2b) in the case of not supporting the generalization type but having precalculated generalized geometries. Uff, so far so good, did I forget something ? Andrea Aime writes: > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
