If a WFS server advertises that it supports GML3 outputFormat, then a client is entitled to expect that is can request this outputFormat. For example, it is very common for app-schema layers to be accessed using service=WFS&version=1.1.0&outputFormat=gml32 . There is only the default format and an unordered list of other formats. I do not see this as unusual, and it need not be for performance reasons.
A bigger problem is that supported output formats cannot be specified by feature type. This is a defect in the WFS specification. This is a huge problem for app-schema layers as application schemas define types for a single version of GML. Current GeoServer behaviour is to respond with broken garbage if a WFS 1.1 request is made for feature type defined in GML 3.2 without outputFormat=gml32. Note also that the namespace URI is different for WFS 2.0. On 28/05/14 06:36, Jody Garnett wrote: > Like I guess it is "okay" for a client to recognise what supported > formats a server provides and choose GML3 over GML2. But it is very unusual. [...] > It is is very odd - My immediate assumption on seeing the use of GML3 > was that the client was broken. [...] > I would expect the WFS 1.0 server to default to GML2 communication (i.e. > follow the specification as written) and only choose an alternative for > performance reasons. All Requests going to the WFS 1.0 service would be > using GML2, so this would be a case of input and output matching. -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
