[Qgis-developer] WFS question in QGIS master

[Richard Duivenvoorde]

Off course I do not want to be to harsh for your users, but this is one
ot the troubles of closed source servers/software: it takes time to get
something fixed (well that is not new...) but also it is impossible to
fix/find stuff yourself too, making you totally dependent on the
company, selling you stuff.

And in name of the 'standards', I would not encourage a client (like
QGIS) to be too tolerant about the standards. Even less if it makes
our/QGIS code more complex to maintain because of all the ifs and
options to handle this.

The plan to ditch Geomedia Web Mapserver in favour of QGIS-server is off
course the preferred solution, I don't like the parallel plan too much
either. :-)

Regards,

Richard


On 01-06-16 11:10, Neumann, Andreas wrote:
> 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
> 
>  
> 
>  
> 
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>