[Qgis-developer] WFS question in QGIS master

[Neumann, Andreas]

Hi Even, 

Thank you for your time to analyze the problem. 

Unfortunately, while we can try to influence Geomedia Web Map server to
become more standard compliant (which we probably should do), it means
that we have to wait at minimum 1.5-2 years until these fixes would
become available to us - if they even accept our demand for the fixes. 

If you are willing to work on making QGIS "more tolerant" to read such
WFS, we would probably be interested in funding this work. Probably
cheaper and faster for us than trying to fix Geomedia Web Map server. On
the other hand there is an internal effort at our organization to
establish a parallel open source web map server (most likely QGIS
server) next to Geomedia or potentially replace it over time. 

I will discuss offlist with you and my colleagues to see what makes
sense in our case. 

Thanks, 

Andreas 

On 2016-05-31 18:53, Even Rouault wrote:

> Hi Andreas,
> 
>> Is this a problem in the WFS server or in the client issueing an invalid
>> request? Can QGIS do something do be more tolerant and display this WFS
>> layer?
> 
> There are several issues :
> 
> - the server doesn't like srsname of the form urn:ogc:def:crs:EPSG::XXXXX, but 
> only EPSG:XXXXX. This is a bit a mix of the fault of the client & server here. 
> The client does some internal normalization of the srsname when parsing the 
> capabilities to store them in the form EPSG:XXXXX so that QGIS projection 
> selector like them. And when issuing WFS requests, for WFS 1.0, it keeps 
> EPSG:XXXXX and for later versions it uses  urn:ogc:def:crs:EPSG::XXXXX which 
> is supposed to be the "new" way of specifying them (one could expect the 
> server to return urn:ogc:def:crs:EPSG::XXXXX in WFS 2.0). Here it seems the 
> Intergraph server doesn't like at all the new way. Some robustness could be 
> added in the client to retry with the alternate way (and probably first try 
> with the variant that was given in the capabilities)
> 
> - the schema returned by 
> http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get?request=describefeaturetype&service=wfs&typename=gmgml:LW_Bewirtschaftungseinheiten&version=2.0.0 
> is a bit too complex for the QGIS client and so it doesn't understand that 
> "gmgml:Polygon_Surface_MultiSurface_CompositeSurfacePropertyType" is a 
> geometry field (hence a geometry less layer reported). That could potentially 
> be improved to hard code that this type is a polygon geometry (I see it is 
> done in OGR GML driver)
> 
> - the response to GetFeature returned by 
> http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=gmgml:LW_Bewirtschaftungseinheiten&SRSNAME=EPSG:21781&COUNT=1
> is not conformant with the WFS 2.0 spec. It should be a wfs:FeatureCollection 
> and not a GML feature collection as in WFS 1.1. The QGIS client is robust 
> enough to handle that however... But this is clearly a non conformance to the 
> spec
> 
> - in the geometries returned, there are constructs like gml:CompositeSurface 
> and gml:Arc that the QGIS GML importer will not handle. Falling back to the 
> OGR GML services to parse them could potentially be done as it is able to 
> handle them (just tried with 'ogrinfo 
> "WFS:http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get" 
> -ro --debug on gmgml:LW_Bewirtschaftungseinheiten -al -q' )
> 
> Even

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160601/bebcd818/attachment.html>