[gdal-dev] Re: Read WFS Features

[Jukka Rahkonen]

vickarasu <victor.aparicio <at> hotmail.com> writes:

> 
> I did the test of the URL sending requests by a web browser. I got well
> formed XML documents with the getCapabilities and the describeFeatureType
> too.
> 
> This request yesterday worked in a webbrowser (not in my C# app), but not
> today. Perhaps there is some problem with the server
>
http://www.idee.es/IDEE-WFS/ogcwebservice?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&NAMESPACE=xmlns%28ideewfs=http://www.idee.es/wfs%29&TypeName=ideewfs:BDLL200Municipio
> 
> In any case, I tried another server
> (http://www.sigua.ua.es/cgi-bin/siguawms?SERVICE=WFS&VERSION=1.0.0), because
> the target of the app is learn how to use GDAL, and I have the same error.

Hi, 

I have been playing with various WFS servers and clients lately and I think I
have learned something. First is that there are very many ways to fail in the
WFS client-server discussion. Only after running all the traffic through a web
debugger I managed to gather enough information so that I could make a fruitful
discussion with the client and server developers. The tool I use now is called
Fiddler 2 but there are for sure other equivalent tools around. What you need to
be able to log is the whole content of requests and responces, including the
headers. Depending on the client, both the http GET and POST requests should be
logged. POST is much more problematic because of schema validation that the
server is possible doing. You are testing against deegree server which is
strict. TinyOWS is strich also if not specially to non-validating mode.
Geoservers are not so strict if not configured to run in the validating CITE
test mode. Mapserver does not do schema validation at all, I believe. 
Another thing is to add always &maxfeatures=10 or something into your
GetFeatures when doing the first tests. You do not really need all the thousands
of features for seeing if the service is up.

So if something fails with WFS you should capture the whole raw message that
your client was sending. GET messages are easy to resend with browser and
sometimes the returning error message can give a hint about what is happening.
POSTs are not so easy to handle, but with Fiddler it is possible to copy the
failing request into Request Builder, edit it by hand and retry. It is possible
that you will need to collect the requests and results and send them to server
administrators or software developers and ask why do they fail. They will love
you more if you have installed the server yourself so you can collect
information also from the server side.  Geoserver is super easy to install, and
so is TinyOWS if you are on Linux, and they both come with demo feature types.

-Jukka Rahkonen-

-Jukka Rahkonen-