HI Jody, Just a remark first: I did not write any of the code we are writing about, I am only reporting what I find. I don't feel one way or the other about it, so if you reckon it needs to be changed it is fine for me, as long as you specify exactly what you want to change about it. I'm just the messenger, basically.
On 28/05/14 00:36, Jody Garnett wrote: > > > Can you confirm that version negotiation is being handled correctly. > > > 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. Well like I explained in last email, I can confirm for sure that the mechanism works the way the programmers intended it to be. It finds the first match between server and client side supported formats, looping over the server side supported formats first. This is not faulty or buggy, I can again confirm that. If you think there should be a different mechanism behind it, that is fine to me, but then please specify what the mechanism should be. > > 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? > > 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. > As Andrea explained in the other email, the namespace parameter is necessary for geoserver. The way I understand it, the namespace on the client is not necessarily the same as on the server. This seems to work the same way as the old wfs module. The way I see it works is this: if the layer is called nurc:layer in the server, the name is changed on the client to nurc_layer with the client side specified namespace. So there is a clear difference between the name on the client side and the name on the server side of the layer. But there is no problem with typename of the same name but different namespace. I assumed this is because we don't know if the client even knows the server side namespace, which is important in for example geoserver. Would it be enough if the native ones were returned if none was specified as Andrea suggested? Despite this, Jody, I still think it would be better if udig did a null check, just in case. (I believe I read somewhere in the javadoc that namespace *may* be null, but perhaps that doesn't count in this case.) Either way, I don't think you can say it is good that *all* info (crs, bounds, etc...) is lost as a consequence of one missing piece of information. That does not seem quite robust to me. Kind Regards Niels ------------------------------------------------------------------------------ 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
