The underlying problem is that for complex features, the target GML version is determined by the target schema, which is chosen by the data provider and not the client. For example, a GeoSciML 2.0 feature type *must* be delivered in GML 3.1.1, while a GeoSciML 3.0 feature type *must* be delivered in GML 3.2.1. The client cannot request a different format.
GeoServer currently assumes that output format is orthogonal to data source. This does not hold for complex features. It seems to me that it would be rather useful if a DataAccess could notify the catalog (FeatureTypeInfo) of the preferred/supported/required output format. I know WFS 1.1.1 is required to default to GML 3.1.1, but WFS 2.0 lists this restriction and opens the door to better communication between the DataAccess and the dispatcher in selecting an OutputFormat. A similar approach may be useful for WMS GetFeatureInfo. On 17/11/10 23:25, Justin Deoliveira wrote: > Ideally choosing the output format would follow the way other output formats > do it and just use a different mime type. "text/xml; subtype=gml/2.1.2" vs > "text/xml; subtype=gml/3.1.1", etc... Choosing output format based on backend > data source could work... albeit a bit tricky. And I think it is nicer to be > explicit. -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
