Hi, I've been thinking about that, yet I can't get a fully satisfying answer myself.
I mean, both the WMS SRS list and the WFS OtherSRS elements serve quite the same purpose, yet, one is global and the other per feature type... I'm not sure using the same list at both sides would fit all (users) needs, and moving the list of filtered crs's to GeoServer config seems odd to me. What I'm not sure about is if that list would have any role in the WCS capabilities too? Besides that, what I think would really make more sense is to: - Have a list of "favorite" crs's, but does not directly maps to the WMS SRS list nor all the WFS FeatureTypes - Have an option in WMS config to inherit its SRS list from the global favorite list. But also being able to add/remove more srs's - Have a per feature type (at the data FeatureType edit page) option to set the available CRS's for each feature type. This would be empty by default and have the possibility to either inherit the ones from the global favorite list and add/remove crs's. Or rather for the sake of simplicity, just the ability to select which ones from the favorite list to list for each specific ft, like in the case of additional styles. Still less than optimal, but doable. And we already have a mix of wms and wfs options in the featuretype editor page... opinions? Gabriel On Saturday 29 March 2008 10:34:07 am Andrea Aime wrote: > Justin Deoliveira ha scritto: > > Good idea, I believe at the moment all we do is set the "DefaultSRS", > > which i think is just hardcoded to EPSG:4326. It would be nice to > > provide the filtered list as "OtherSRS" elements. > > Quick check on geo: > http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabili >ties > http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabili >ties&version=1.0.0 > > Same layer, archsites, declares: > WFS 1.0: <SRS>EPSG:26713</SRS> > WFS 1.1: <DefaultSRS>urn:x-ogc:def:crs:EPSG:6.11.2:26713</DefaultSRS> > > Looking at the schema, WFS 1.0 does not have a place to declare extra > SRS, you can declare the BBOX in multiple SRS, but I guess it's not the > same (plus, bbox reprojection could cause transformation failures... > maybe it's better to stay away?) > > WFS 1.1 has indeed the OtherSRS element that could be used to declare > the extra SRS. > Pros: the client knows that we're capable of reprojecting the layer > in other srs > Cons: - we have to move the srs list up to GeoServer config > - the srs list may be short or long. If long and we have many many > layers (say, hundreds?) boom, the cap doc becomes quite long. > E.g., picture this baby: > http://giswebservices.massgis.state.ma.us/geoserver/wfs?request=GetCapabili >ties with 10 extra rows for each feature type (it's true that we already > have quite a bit of rows for the output formats). > > Opinions? > Cheers > Andrea > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac >e _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > !DSPAM:4045,47ee0d2b277821849620573! ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
