Ben you are correct that a client can request any supported format. However
what should the default be for the GeoTools client if the user has not
specified a version? I was guessing that it should follow the version of
GML marked as the default for the spec. Like they probably have it in
there right? If not specified the server will return GML2 or something?
I am concerned any further discussion just distracts Neils from the few
remaining issues with the client (i.e. namespace).
Discussion about how a client should act may best be done on the
standa...@osgeo.org list, where we have access to other WFS implementors.
Perhaps I am alone in being surprised :) I seriously assumed version
negotiation had failed because of the use of GML3.
One thing I cannot answer is *how*, at the GeoTools level, a java developer
can choose what format is used?
*Niels please take the following as "discussion" to ensure I understand the
design of both GeoTools and the WFS Client. It is not intended as a
request/distraction from your list of issues:*
The obvious solution would be to allow Java developers to select a
different (i.e. non default) exchange format as a Query Hints parameter.
The hard part is communicating what options are supported for a given WFS.
I am not sure if the DataStore API has a way to advertise both support for
a query hunt, and what the valid options are.
A "workaround" would be to use the FeatureType schema "user map" to
advertise a list of formats. That is kind of opaque, and would prefer if
Java developers have access to the WFS Client (and resulting
GetCapabilities) to look up the list of formats directly in the parsed
GetCapabilities data structure.
Jody Garnett
On Wed, May 28, 2014 at 12:25 PM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:
> 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
