>
> 1) version negotiation how?
>
>
I would like to confirm the client is correctly handling version
negotiation. The unexpected use of GML3 (with a WFS 1.0 service) is
slightly different.
Can you confirm that version negotiation is being handled correctly.
Okay, so I have been looking at this GML3 issue, and I found where it
> happens is in the method getDefaultOutputFormat in AbstractWFSStrategy.
>
> What this method does is look at the client formats and server formats and
> takes the first match.
>
> The client formats are defined in the class
> GmlGetFeatureResponseParserFactory in the gt-data module. They are:
>
> "text/xml; subtype=gml/3.1.1",//
> "text/xml;subtype=gml/3.1.1",//
> "text/xml; subtype=gml/3.1.1/profiles/gmlsf/0",//
> "text/xml;subtype=gml/3.1.1/profiles/gmlsf/0",//
> "application/gml+xml; subtype=gml/3.1.1",//
> "application/gml+xml;subtype=gml/3.1.1",//
> "application/gml+xml;
> subtype=gml/3.1.1/profiles/gmlsf/0",//
>
> "application/gml+xml;subtype=gml/3.1.1/profiles/gmlsf/0",//
> "GML3", //
> "GML3L0", //
> "text/xml", // oddly, GeoServer returns plain
> 'text/xml' instead of the propper
> // subtype when resultType=hits. Guess we
> should make this something
> // the specific strategy can hanlde?
> "text/gml; subtype=gml/3.1.1",// the incorrectly
> advertised GeoServer format
> "GML2",//
> "text/xml; subtype=gml/2.1.2"//
>
> Then the server formats are taken from the parsed getcapabilities document.
>
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.
For the geoserver WFS 1.0 server this is:
> GML3, GML2, CSV, JSON, SHAPE-ZIP, KML
>
>
> So... since GML3 is *first* in the list, that is the chosen format.
> Question is: is this wrong? If Geoserver puts it in that order in its wfs
> 1.0 getcapabilities document, doesn't it make sense to pick it first? If
> the server didn't support GML3 it wouldn't occur.
>
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.
Perhaps check what OL2 and OL3 do? And test with other implementations of
WFS.
> 2) Replacement for WFSSchema.NAMESPACE
>
> public static URI NAMESPACE = makeURI("http://www.opengis.net/wfs";);
>
> Is there is good place to reference this value? I don't want to have to
> create it in multiple locations?
>
>
> What about WFS.NAMESPACE in the xsd-wfs module? It is a string though.
>
That could work, it is hard to parse String into URI constantly (as you
have to do try/catch).
3) GetBounds / CRS not working -> getInfo problem?
>
> I have found that all my problems disappeared as soon as I filled in the
> *namespace* parameter when creating the store.
> a) CRS and bounds were received properly;
> b) Map was rendered successfully;
> c) Features were editable and transactions were sent to server
> successfully.
>
Why would you need to fill in the namespace parameter when creating the
store? You cannot even see what namespace parameters are available until
you try the get capabilities document right?
> So I found the bug is not in wfs-ng getInfo but in uDig.
> More specifically: you can find the bug on line 79 of the class
> WFSGeoResourceInfo in the module org.locationtech.udig.catalog.wfs. The
> namespace is here used without a null check. Because of that, the whole
> method crashes (which is actually a constructor) and therefore *none* of
> the metadata of the resource is being received. According to the geotools
> API I see no reason why the namespace can't be null. udig shouldn't crash
> on that... so in my opinion it is udig that needs to change and not wfs-ng!
> Correct me if I'm wrong...
>
Lets say we are both wrong :) I am wrong in that I need to tighten up the
GeoTools API javadoc about namespace, and the WFS client implementation is
wrong to consider namespace as a parameter.
The WFS client cannot have namespace as a parameter - as namespace is
something that comes out of the WFS Server configuration. Specifically a
WFS Server can publishing content where each feature type comes from a
different namespace, we see this in GeoServer as part of our workspace
configuration. Each feature type published from a workspace belongs to that
namespace. That way we can have the same feature type name published in two
different workspaces - allowing a client to work against two layers of the
same "type name" without getting confused.
For this to work the client needs to respect the namespace description
provided by GetCapabilities and DescribeFeatureType. This is especially
required when making requests, and when editing using WFS-T Transaction.
By providing a namespace parameter you are "overriding" this server
configuration, and I am not quite sure what you do as a result? Do you
reverse map your override to the specific namespace provided by the server?
How do you handle the reverse map when the same feature type is published
out of two different workspaces? etc...
So yeah kill the namespace parameter, and grab namespace from the WFS
server.
4) Visual representation of parameters names, formatting sources, ...
>
> Will be sorted.
>
Nifty.
Thanks for responding Niels, and glad you are getting to the bottom of the
debugging and it is wonderful to see the wfs client being invested in.
--
Jody
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
