Hi,
in order to get a full picture how Geoserver handles GetFeature-requests for
feature types which are identified or not by full namespace
I have analyzed Geoserver's current stable version 2.3.3 by sending several
alternative GetFeature-requests for WFS version 1.0.0 and 1.1.0.
For a few constellations Geoserver reacts differently from what I think a
user/client would expect which
I like to illustrate here (using the default geoserver tasmania dataset):
The request scenarios and their particular HTTP-GET requests (here for
version 1.1.0) are the following:
1. request with a typeName without xml-prefix/ without namespace declaration
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=tasmania_roads
expectation: should return a GML result
2. typeName with known xml-prefix but without namespace
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=topp:tasmania_roads
expectation: GML result
3. typeName with unknown xml-prefix
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=tipp:tasmania_roads
expectation: should throw a service exception
4. typeName with known xml-prefix and corresponding valid/registered
namespace
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=topp:tasmania_roads&namespace=xmlns(tipp=http://www.openplans.or
g/topp)
expectation: GML result
5. typeName with unknown xml-prefix but prefix/namespace mapping to a valid
namespace
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=tipp:tasmania_roads&namespace=xmlns(tipp=http://www.openplans.or
g/topp)
expectation: GML result
6. typeName with xml-prefix which is mapped to an unknown namespace
http://localhost:8090/geoserver/ows?request=GetFeature&service=WFS&version=1.
1.0&typeName=tipp:tasmania_roads&namespace=xmlns(tipp=http://www.tippTopp)
My issues/questions:
a) all HTTP-GET responses are correct but one. In scenario 5 for WFS
interface version 1.0.0 I get an "unknown Namespace"-error.
I am aware of the fact that the "namespace"-parameter is
classified as a common parameter not before WFS-spec 1.1.0, so handling this
parameter in Geoserver WFS 1.0.0 code is not
obligatory and would only be a backward-compatibility matter and
a user feature
b) sending an HTTP POST request for scenario 1 to WFS-interface 1.0.0 results
in
an error message: "Could not locate
{http://www.opengis.net/wfs}tasmania_roads in catalog."
The request is:
<wfs:GetFeature service="WFS" version="1.0.0" outputFormat="GML2"
xmlns:wfs="http://www.opengis.net/wfs"; xmlns:ogc="http://www.opengis.net/ogc";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd";>
<wfs:Query typeName="tasmania_roads">
</wfs:Query>
</wfs:GetFeature>
It looks like Geoserver takes the first namespace, namely the
WFS-namespace? Or is it the default namespace according to the spec?
c) sending an HTTP POST request for scenario 3 both to WFS-interface 1.0.0
and 1.1.0
I surpringly get the GML-results, no error message
<wfs:GetFeature service="WFS" version="1.0.0" outputFormat="GML2"
xmlns:wfs="http://www.opengis.net/wfs"; xmlns:ogc="http://www.opengis.net/ogc";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd";>
<wfs:Query typeName="tip:tasmania_roads">
</wfs:Query>
</wfs:GetFeature>
Here, Geoserver resolves only the local part of the requested
feature type and does not care about the unknown xml-prefix.
I would appreciate any feedback.
Sven
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
