Application: gvSIG desktop

The same behavior happens in gvSIG 1.11 (build 1305) and gvSIG 1.12 (build 1206) with the following service (WFS v. 1.1.0):
http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wfs/Autorita_bacino.map
The alphanumeric data are loaded, while geometries not.

I have tested it with build 2049 and it works.
Why is it not closed?

This seems to happen because the connection URL contains the request=getcapabilities part
http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getcapabilities
gvSIG creates the following request

service=wfs&version=1.1.0&request=getcapabilities&REQUEST=GetFeature&SERVICE=WFS&TYPENAME=lv:municipalities&PROPERTYNAME=lv:suuralue,lv:avi,lv:maakunta,lv:seutukunta,lv:kunta,lv:suural_ni1,lv:suural_ni2,lv:avi_ni1,lv:avi_ni2,lv:maaku_ni1,lv:maaku_ni2,lv:seutuk_ni1,lv:seutuk_ni2,lv:kunta_ni1,lv:kunta_ni2,lv:kieli_ni1,lv:kieli_ni2,lv:kaupunki,lv:shape_leng,lv:shape_area,lv:the_geom&VERSION=1.1.0&EXCEPTIONS=XML&MAXFEATURES=1000&NAMESPACE=xmlns(lv=http://latuviitta.fi/)&RESULTTYPE=hits

There are both request=getcapabilities and REQUEST=GetFeature. TinyOWS server is sending back answer to getcapabilities while gvSIG is awaiting answer for GetFeature&RESULTTYPE=hits.

Without request=getcapabilities in the connection string everything seems to work OK. I do not know what server should do in this case. It would be most safe if gvSIG would not send the unnecessary request=getcapabilities.

More information: If I try to read a layer from WFS with the URL which contains that unnecessary "getcapabilities" then gvSIG starts to behave very badly. If I click on the table of contains for removing the layer the CPU load is reaching 100% for a long time. The whole computer gets jammed and the only way to continue seems to be to kill the gvsig-desktop.exe process from task manager.
I tested this with Windows XP and gvSIG 2.0.0 2051 win-x86-standard-withjre.

Thanks Jukka for those tests.

Note for myself: A.Falciano's issue is probably caused by an error in: org.gvsig.gpe.prov.gml.parser.v2.geometries.MultiPolygonTypeBinding, parseTag

I don't think this is really a bug because the URL used is not right and the server is not behaving properly (I think it should not accept two occurrences of "request"). I have added a warning to the user if a suspicious string is found in the URL.

Nevertheless, there is still a problem described by Antonio Falciano which I will address soon.

Hi,

It is perhaps not so straight forward. It is true that the URL used for making connection is odd. However, it does return a valid GetCapabilities response and if you see inside the document http://188.64.1.61/cgi-bin/tinyows?service=WFS&version=1.1.0&request=GetCapabilities there are these entries:

<ows:Operation name="GetFeature">
<ows:DCP>
<ows:HTTP><ows:Get xlink:href="http://188.64.1.61/cgi-bin/tinyows?"/>
</ows:HTTP>
</ows:DCP>
<ows:DCP><ows:HTTP>
<ows:Post xlink:href="http://188.64.1.61/cgi-bin/tinyows"/>
</ows:HTTP>
</ows:DCP>

If WFS standard is followed strictly the client should use those URLs which are advertised in the GetCapabilities and not just simply use the same base URL that was used for GetCapabilities.
It is known that GetCapabilities can advertise wrong URLs for GetFeature (and same with GetMaps in WMS services). Some WMS clients are asking user to select between the same base URL used for GetCapabilities of the URL that comes with the GetCapabilities response. Perhaps WFS client could behave in a similar way too.