Christian Müller ha scritto: > Looking at the the hint "Hints.PRESERVE_TOPOLOGY" indicates you mean the > generalization should take place in the FeatureSource ?. Would be > consistent with the handling of image pyramids.
Well, in the feature source, yes, where else? You're asking the feature source to return pre-generalized geometries, where that does happen internally is an implementation detail. What I tried to say is that some generalization techniques do not preserve topology, they are usually faster than the topology preserving case: - for the rendering case we care more about performance and streaming renderer does not need topologically correct data anyways - for the wfs case we do want topology preservation instead, so it's ok to do more work I know that for your specific use case it does not make a difference, as you pre-generalize with a topology preserving algorithm, but what if tomorrow PostGIS comes out with a generalizing procedure that is geared towards rendering and performance and does not preserve topology, and we want to use it "on the fly" to get a speedup without the hassle of pre-generalizing, configuring and so on? I'm actually discussing this option with the PostGIS devs, I know for a fact people that would reject the complex setup of a pyramid but would be very happy to have a speedup in WMS rendering without the need to move a finger (as users). That's why I want to have around a topology preserving case, and a non topology preserving one, to support the on the fly, database side, generalization case. 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
