-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QGIS Server getcapabilites response is not WMS compliant #18901
Comments
Author Name: aperi2007 - (aperi2007 -) I test with a version=1.1.0 request. !error_validation110.gif! Also it seem invalid. I put an image with the error message from xml-spy.
|
Author Name: aperi2007 - (aperi2007 -) lastly !error_validation111.gif! Again it is invalid, seem that the GetPrint command in unknow to xsd 1.1.1
|
Author Name: aperi2007 - (aperi2007 -) I send a wrong xml (the firefox transform it in an html file). SO I resend the right.
|
Author Name: aperi2007 - (aperi2007 -) Hi, I compare with a VALID getcapabilities response from MapServer. I attach an image to show where MapServer will put the GetLegendGraphics tag.
|
Author Name: aperi2007 - (aperi2007 -) NO !. Now I put the right image with the right position. sorry for noise.
|
Author Name: aperi2007 - (aperi2007 -) !img3.gif! will show the wrong position used by qgis-server. i hope to not wrong again to send the image. :) Regards.
|
Author Name: aperi2007 - (aperi2007 -) Hi, more informations. The question is not the positizion, but there is more oproblems. Firstly the GetCapabilities should be prefixed using a specific prefixname as example "sld" so the tag become
And add the used prefix in the namespace list:
This resolve the GetCapabilites problem, but after this there are more problems: Infact I study better. For the GetStyle: This link show the explanation from OGC: http://www.ogcnetwork.net/node/1333 Unfortunately the QGIS-server declare the response WMS 1.3.0. The GetPrint instead seem to be an invention of QGIS. So the only choice is remove it. I dont know why the need to insert in a getcapabilites a non standard tags. Why this ? It is pretty unuseful. More better to invent an extra request like for example: GetQGISCapabilities, I attach an image that show this problem. Andrea.
|
Author Name: aperi2007 - (aperi2007 -) Hi. I confirm that the action described resolve the validity problem. I modify the code of qgis-server adding the prefix and the namespace and schemaLocation missed. And voila' the response now is VALID. For me is ok . Now we have our "qgis-server" compliant with ogc and inspire. :)) Regards. |
Author Name: Jürgen Fischer (@jef-n) Is there any practical problem with this? |
Author Name: aperi2007 - (aperi2007 -) I dont know who really use the GetStyles and GetPrint in the GetCapabilities. Surely no one of the standard OGC client like Arcgis, QGIS, Autoca, Geotool-based and so on no one could use this two tags. I don't know if the two web client for qgis like the AFAIK the GetCapabilities is a standard OGC world used response. And some proprietary tags in it will break the compatibility. As example our client based on the GeoTools and based on a rigorous apply of OGC stadard will fail. If agree with this consideration. I tested the patch on my qgis-server (the same of the ticket). Now it is patched and is OGC compliant in the wms 1.3.0 getcapabilities response. Regards. |
Author Name: Jürgen Fischer (@jef-n) Fixed in changeset "b3a708fba6cbd7af8c28ca1e46e48a053aef5afe".
|
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
Of course, but they also don't have a problem with it.
Not sure about Lizmap, but QWC does. GetPrint was introduced for QWC.
Not really. I don't know any client that checks the validity of the GetCapabilities response.
Did you verify that that's actually true? ArcGIS 10.1 apparently doesn't have a problem with QGIS server. And invalid responses might do no harm at all as long as all the expected stuff is actually there - which is the case. Clients shouldn't be to picky as there are lots of servers out that have "alternative" interpretations of the spec.
I suppose that would break existing clients (that are not that picky on validity). Does QGIS Desktop still work (ie. does it show the legend)? I suppose b3a708f doesn't and still should make the response valid. Although letting the @schemaLocation@ point at an extended schema might be in a grey area of the spec. Maybe there is a cleaner way to extend the schema without introducing a different namespace. I didn't find any, but I'm not an XML expert. @xmlpatternsvalidator@ at least doesn't complain anymore.
Which clients did you use to test? |
Author Name: aperi2007 - (aperi2007 -) Hi, Unfortunately if is a license violation of License. Please read this and after this
AFAIK you cannot download the XSD of OGC and change it inserting in it the new tags. You should rewrite it from scratch. A.
|
Author Name: aperi2007 - (aperi2007 -) I rsponde between rows:
I know how work arcgis.
The GetCapabilities is a standard OGC. So it MUST BE used with a standard OGC xsd.
In Italy a public administration cannot say to an user "hey buy a arcgis 10 license " because your arcgi 9.3 don't work with my incompatible OGC server.
ok, I don' t well explain. The GetStyles and GetPrint tags ARE NOT present in Mapserver and Geoserver. IS qgus workng with Mapserver or GeoServer ? Surely yes. They are added to give a commercial advantege to some web portal solution. But a public administration cannot be the funder of a product not interoperable and not compliant with inspire specificitaio SO I Guess actually the clients of this product are or private subject or PA that don't understand well this question. But is ESRI and Autocad and so on Regards, Andrea. |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
I didn't. The schema references the original schema as include and uses the intended element for the extension - just like your approach. Only without requiring a separate namespace and a prefix for the operation. Not sure if there is a (more canonical?) way to do that.
|
Author Name: aperi2007 - (aperi2007 -) sorry. This is the code to set the change in the qgiswmsserver.cpp.
--> wmsCapabilitiesElement.setAttribute( "xmlns:sld", "http://www.opengis.net/sld" ); and also this: //wms:GetLegendGraphic This code correct the GetLegendGraphics problem. Obviously still remain to resolve the presence of GetStyle e GetPrint. |
Author Name: zicke - (zicke -) QGIS server has a GetProjectSettings request which has a lot more information for QGIS webclient (which the GetPrint tag is for). In earlier times there was no such request and the GetCapabilities request was "abused". Now, probably you can get rid of these vendor things in the GetCababilities response. Stefan |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
I know. But I don't know any client that actually validated the response.
I was just asking if you actually tried any clients and found any that actually fail. Any client that only accepts fully valid GetCapabilities responses will probably have problems with lots of available WMS servers and also be very slow as validating the schema takes much time. So I suppose in practice no client will actually do that and hence any client capable to work with any valid schema will be able to ignore elements that it doesn't support and in turn should also work with QGIS' response. That doesn't mean that QGIS' shouldn't be compliant - it just questions the actual relevance of it. To me it was unclear if you just suspect that ArcGIS doesn't work or if you actually verified that it has. That I found ArcGIS 10.1 working (and now verified that 9.2 also appears to work) suggested that it was just a hunch. |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
http://qgis.org/wms_1_3_0.xsd reads:
So the schema wasn't copied.
Right, but it might break existing clients and it's unclear to me if there are any clients that would benefit from it.
If we did that I'd propose a qgis namespace similiar to the above xsd listing all the available extensions (ie. like umn mapserver does). |
Author Name: aperi2007 - (aperi2007 -)
Hi Stefan, Put all not ogc compliant things in a not standard request/response couple. Thx, Andrea. |
Author Name: aperi2007 - (aperi2007 -)
The client actually don't do any type of validation otherwise they will fails. This mean also that QGIS is caged by some manual client that use a non standard and not wms compliant xml response ? This is the better think that may hope a commercial product like esri. |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
Not validating doesn't mean that you don't use a standard library and do manual parsing. You can use a standard library and still skip the validation - actually you probably always will for performance reason unless there is reasonable doubt that the response is correct (eg. for debugging while developing or if you use an unreliable transport path etc).
Extending the GetCapabilities response is covered by the spec - that's what the @_ExtendedOperation@ element is for. I think we're in a grey area now. AFAICT the spec doesn't clearly state where the schemeLocation should point, there is intended room for extension and validation tools are probably unable to spot any invalidity now, but we're probably still outside the intended interpretation of the spec as GetCapabilities "shall contain an XML Schema instance schemaLocation attribute that binds the “http://www.opengis.net/wms” namespace to the schema in E.1." - which it does - but indirectly ;) But the solution with the qgis namespace would be fine and valid - although it still might break clients. |
Author Name: aperi2007 - (aperi2007 -)
The important is to grant the compatibility with the OGC spec. So the solution with the extendedoperation is valid if it is compliant with the OGC xsd.
I tested the "qgis" prefix solution instead of "sld" with XMLSPy. And francly, to update the own client from "sld" or "none" to "qgis" is really easy. So the correct should be:
this is the "qgis" namspace definition: --> xmlns:qgis="http://www.opengis.net/sld" and the schemaLocation: Regards, A. |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
Isn't the current solution "valid" for xmlspy too? |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
And does it also make ArcGIS 9.2 work for you? |
Author Name: aperi2007 - (aperi2007 -)
I tested it using the official and valid xsd from OGC. The question is not only xmlspy. This xsd is not the official xsd. If yes why point it on your private site ?. if it is not equals to the official xsd , this mean you have chage something in the standard. And surely the xmlspy will validable it. So you have a valid xml but absolutely no grant to be interoperable because you valid on a different xsd rather than the official. A. |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
I think I fully understand your concerns. My question just is if there are any clients affected by this. I also don't know if there are actually clients (still) relying on the current behaviour. Maybe other can comment on that. For instance does ArcGIS 9.3 actually validate the schema, while 9.2 and 10.1 apparently don't? I suspect that 9.3 will still have problems even when the validity issue is fixed.
But the spec doesn't require that you use the xsd directly from OGC. It explicitly allows to use a copy:
It's explictly stated if extensions actually mean that "the normative content of the schema is changed" - as the spec explictly allows extensions and the scheme is the OGC xsd + those extensions. The extensions usually are in an separate xsd (which with my limited xml knowledge always come with a separate namespace), but "6.9.5 Extended capabilities and operations" also doesn't explictly requires that either. |
Author Name: aperi2007 - (aperi2007 -)
Yes but is a technical need by the parser. Of course this mean that you could download it and put it on your site. Must the spec explicitly DENY that you MODIFY IT and (perhaps) deny also the redistribute. But surely the ISO organization (just as another example of the distributor of the WMS SPecs) You can download but for your internal use only. The two organization seem apparently tohave different logics but instead both have the same goal (objective) in mind To have a GRANT that the user that download the xsd DON'T CHANGE something in it. One say "you cannot change anythin" the other say "you cannot redistribute". Onestly if one has the xsd in its site, when has any problem is more easy to change a little row in it rather then So to point forward the original in the original site is like say Instaed point to a different site , a private site is like see So I guess more better to point directly it. Otherwise the QGIS himself has any risk that someone And when was discovered that the validity is FALSE the qgis credibility was definitively compromise. Please notice: The response was surprisly for me. If you was using a xsd on your site that match fully the need of qgis. I guess this is a bad practice.I practice that I avoid because is dangerous and expose to future changing and waste of time to understand why that software don't work with qgis-server. A |
Author Name: Jürgen Fischer (@jef-n) aperi2007 - wrote:
Of course, that's what a spec is for. If you claim we are non-compliant back that up with a statement from the spec that we violate. We don't need to assess why a spec sets clear bounds in some areas and leaves room for interpretation in others - we just need to stay within the bounds it sets to be compliant. According to the spec extensions are ok and pointing at different schema locations is ok unless "the normative content of the schema is changed". I don't know if the there is an other part of the spec that elaborates what that quote actually supposed to mean and if aren't compliant to that, but I don't see something in that quoted paragraph that we clearly violate. I'm not saying that we are compliant, but I also don't say that we non-compliant. I don't know if we actually violate the spec. Sorry, but your general remarks about generic standards don't help with that. I'd also like do have direct answers to my questions about which clients you found being affected (you claimed ArcGIS 9.3 has problems, while I didn't find problems with 9.2 and 10.1) and whether they are still affected and if those problems arise just from the capabilities being invalid or if those clients actually can't cope with extensions, although they should when the schema includes any according to the spec. In the latter case we could - for the sake of interoperability with non-compliant clients - maybe have an optional setting to avoid exposing the extensions. But as said earlier to be affected by this, a client must validate the response (which most probably don't for performance reasons) and/or iterate the requests listing in capabilities and look for stuff that it doesn't support, although that might make an otherwise perfectly usable service unusable. What I want to know: which clients are affected by the current behaviour and which clients would be affected by a changes of the current behaviour (extended requests without a prefix). You seem to avoid answering direct questions to that, I don't know and those who do might not be available until after the pentecost weekend. So we probably just have to wait. |
Author Name: Even Rouault (@rouault) I agree with Jürgen that it is not completely clear what "The schema bound to the root attribute may be a copy of the schema in E.1 The way Inspire proceeds to extend WMS 1.3.0 can be a source of inspiration (pun intended ;-)) in that case. For example, here's the beginning of the response of UMN MapServer to a GetCapabilities request to a project configured with Inspire extensions:
and later in the doc :
The http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd schema is :
|
Author Name: Giovanni Manghi (@gioman)
|
Author Name: Jürgen Fischer (@jef-n)
|
Author Name: Paolo Cavallini (@pcav)
|
Author Name: Marco Hugentobler (@mhugent) Fixed in changeset "072c1e573179727f8d1092f3c9b37d0e99c855a2".
|
Author Name: aperi2007 - (aperi2007 -)
Original Redmine Issue: 10489
Affected QGIS version: 2.2.0
Redmine category:qgis_server
Assignee: Marco Hugentobler
Hi,
the response of the QGIS Server trunk version don't seem to be WMS Compliant.
I tested it using XML Spy Enterprise and it response the GetLegendGraphics is put in wrong place.
I try using this request:
http://www502.regione.toscana.it/geoscopio_qg/cgi-bin/qgis_mapserv?map=continuum_geologico_rt.qgs&SERVICE=WMS&request=GetCapabilities&version=1.3.0
Also I attach the image from my xmlspy with hard sentence.
Perhaps there some setting to set QGIS to response a valid xml for OGC clients ?
Thx.
The text was updated successfully, but these errors were encountered: