Christian Müller ha scritto: > Andrea, I am not sure what you are meaning > "same data source can provide different geometries properties" > 1a) > I assume you mean that within one feature type we can have more than one > geometry property.
Indeed. > Since a feature has a default geometry, this is the one we should use. Wrong: - if it's WMS, each Symbolizer has a Geometry element that can be used to choose which geometry will be used for rendering - if it's WFS, all geometries will be dumped into GML unless otherwise specified The "default geometry" is a WMS only concept, it's the geometry being used if the Symbolizer element does not contain a Geometry sub-element specifying explicitly the geometry property to be used. > If I have a feature with more > geometry properties with different CRSs, it is my responsibility to > generalize all geometries in a proper way in advance. If you have no > distance for the default geometry --> no hint If you have different CRS the generalization distance, expressed in the native data CRS (as you said, you don't want to deal with transformations), is different for every CRS due to the different linear deformation each projection has. The query is one, the generalization is one for each SRS queried. I know this case is not common nor practical, but I cannot behave as if it did not exist, one behaviour for such case has to be specified. > 1b) > If you mean you have to render layers with different CRSs, I see no > problem. The generalization difference is individual for each feature > source. No, one source may have different geometry columns. Basically only shapefiles are l geometry property only, spatial databases and GML files may have many (I believe one of the OGC conformance tests mandates one feature type that has 5 separate geometry columns, one of which has generic geometries, each of them in different CRS). > 2) Having different CRSs within the geometries of one geometry property, > forget it. No hint. I dont want to make a master thesis about CRS > calculations. > Btw, which names should I use > package: org.geotools.data.gen > FeatureSource org.geotools.data.GenFeatureSource Package is ok, we try not to use abbreviated names thought. MultiResolutionFeatureSource, GeneralizingFeatureSource could be acceptable names, thought I agree they are long. Anyways, if you say you have native support, wont' that be part of the DB2 package or something? Also remember to have anything work in GeoServer you have to start with a DataStore, it's the only pluggable thing. Or else, explain how you want to proceed and let's see if you need more extension points out of GeoServer. Sorry to pester, but if you want to put this into GeoServer it has to try and play well with the existing use cases. Probably the quickest approach is to pass down the resolution hint only if there is only one geometry column in use and only one CRS. In this case, and assuming the linear deformation does not vary wildly, it makes sense to talk about a single generalization distance expressed in the datastore native CRS. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
