Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Hi, just for completation (have I apologize before for my trmendous english ?) The specs OGC WMS 1.3.0 final approval is dated year 2006. http://portal.opengeospatial.org/files/?artifact_id=14416 >Open Geospatial Consortium Inc. >Date: 2006-03-15 >Reference number of this document: OGC® 06-042 >Version: 1.3.0 >Category: OpenGIS® Implementation Specification >Editor: Jeff de la Beaujardiere >OpenGIS® Web Map Server Implementation Specification >Copyright © 2006 Open Geospatial Consortium, Inc. All Rights Reserved. Regards, Andrea. Il 08/06/2014 20:56, aperi2007 ha scritto: Il 08/06/2014 15:42, Andreas Neumann ha scritto: You can help to make QGIS server more standards compliant, but you have to properly document this (with links to specifications) and find a developer willing to work on this. I am quite confident that these issues can be resolved. Sorry Andras thx for your attention to this question, but I'm not able to do what you say. The specs: What specs are you say ? I have the iso specs of WMS 1.3.0 but they are payable. Not availables to no one for free. Instead on internet there are the OGC specs that are pretty equals. They are free and available to everyone. I sufficient to goto OGC download and read. developer willing to work on this. Also this is not clear to me. :) I have just patched my server. Why I should pay another to do the same think ? Probably the problem is that the solution I apply is not so graceful to others :) We don't need the GetStle and GetPrint command.So for us is absolutely not imortant to preserve them. The GetStyles is not available on GGeoserver and on MApServer , and we plan to create a federation of WMS servers where every users use the wms server it like better. But surely not plan to use a not standard wms server. So no interest for GetStyle and GetPrint command. So why I should pay to preserve them ? We pay many really many money in these year for QGIS. And just now start to pay again because after three month qgis 2.4 start with another break that break some plugin we realize some time ago. And more probably at the next 2.6 release should be again to pay for another break. And just now we have payed to our actual QGIS partner to resolve some serious bg on SVG managing and also to support better the SVG on qgis-server. These are all ok for us. We are happy to fund the resolution of these bugs. And I suppose other public administration do as us. Also we plan some other enhancement to QGIS. (francly I guess it will be the last) But I don't like to pay for something that is not interested for us. I'm capable now to transform my server qgis in a compliant wms server. I simpli remove the GetStyle and GetPrint from the getcapabilities response. Is easy and cheap. I guess the problem to move the GetStyle and GetPrint in an enhancement section of getcapabilites should be fund by who has interest to have a compliant qgis-server but also interest to have and use a proprietary solution like GetPrint. We are not interested to save the GetStyle and GetPrint. Why I should pay someone else? To do what I have just do ? For who interest in my change to code it is easy. in a unique file .c change three or four row of code and comment other 7-8 row. However I put the code sample in the ticket I opened yesterday . So who interested find all on it. regards, Andrea. Il 08/06/2014 15:42, Andreas Neumann ha scritto: You can help to make QGIS server more standards compliant, but you have to properly document this (with links to specifications) and find a developer willing to work on this. I am quite confident that these issues can be resolved. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Il 08/06/2014 15:42, Andreas Neumann ha scritto: You can help to make QGIS server more standards compliant, but you have to properly document this (with links to specifications) and find a developer willing to work on this. I am quite confident that these issues can be resolved. Sorry Andras thx for your attention to this question, but I'm not able to do what you say. The specs: What specs are you say ? I have the iso specs of WMS 1.3.0 but they are payable. Not availables to no one for free. Instead on internet there are the OGC specs that are pretty equals. They are free and available to everyone. I sufficient to goto OGC download and read. developer willing to work on this. Also this is not clear to me. :) I have just patched my server. Why I should pay another to do the same think ? Probably the problem is that the solution I apply is not so graceful to others :) We don't need the GetStle and GetPrint command.So for us is absolutely not imortant to preserve them. The GetStyles is not available on GGeoserver and on MApServer , and we plan to create a federation of WMS servers where every users use the wms server it like better. But surely not plan to use a not standard wms server. So no interest for GetStyle and GetPrint command. So why I should pay to preserve them ? We pay many really many money in these year for QGIS. And just now start to pay again because after three month qgis 2.4 start with another break that break some plugin we realize some time ago. And more probably at the next 2.6 release should be again to pay for another break. And just now we have payed to our actual QGIS partner to resolve some serious bg on SVG managing and also to support better the SVG on qgis-server. These are all ok for us. We are happy to fund the resolution of these bugs. And I suppose other public administration do as us. Also we plan some other enhancement to QGIS. (francly I guess it will be the last) But I don't like to pay for something that is not interested for us. I'm capable now to transform my server qgis in a compliant wms server. I simpli remove the GetStyle and GetPrint from the getcapabilities response. Is easy and cheap. I guess the problem to move the GetStyle and GetPrint in an enhancement section of getcapabilites should be fund by who has interest to have a compliant qgis-server but also interest to have and use a proprietary solution like GetPrint. We are not interested to save the GetStyle and GetPrint. Why I should pay someone else? To do what I have just do ? For who interest in my change to code it is easy. in a unique file .c change three or four row of code and comment other 7-8 row. However I put the code sample in the ticket I opened yesterday . So who interested find all on it. regards, Andrea. Il 08/06/2014 15:42, Andreas Neumann ha scritto: You can help to make QGIS server more standards compliant, but you have to properly document this (with links to specifications) and find a developer willing to work on this. I am quite confident that these issues can be resolved. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Hi Andrea, You bring up some valid points that should be fixed/addressed. Obviously this can be fixed. However, I would advise to not make a big fuss about this issue and stay pragmatic and focused. Open individual bug reports for each of the non-compliance behavior and back it up with references to the WMS spec. Don't put more than one issues in the bug report but create several reports for each issue. This way it is easier to address and discuss. I can maybe help to understand how the GetPrint command ended up in the GetCapabilities response. When QGIS Web Client was developed there was a print command lacking. Since WMS did not provide a way to point to certain pre-defined layout and specify the necessary parameters we decided to extend the WMS capabilities of QGIS server. The spec (at least in the days of WMS 1.1 when this was added) was not very clear about these extensions. Later, we introduced a request called "GetProjectSettings", which actually is an extended "GetCapabilities" request - here we can now extend according to our requirements without having to violate other standard requests. The GetProjectSettings response contains a lot of "non-standard" information that is used between QGIS server and QGIS web client - things like layout information, widget information, data types, etc. Now that the GetProjectSettings command exists we could actually remove the GetPrint from the GetCapabilities response or we could try to be standard-compliant by using an extension mechanism. It is not true that QGIS people do not care about standards - but it is a lot of effort to make sure everything really complies properly and works interoperable. Even if QGIS would be fully standards compliant it does not necessarily means it is fully interoperable as the specification does not answer everything. You can help to make QGIS server more standards compliant, but you have to properly document this (with links to specifications) and find a developer willing to work on this. I am quite confident that these issues can be resolved. Andreas Am 08.06.2014 12:55, schrieb Jürgen E. Fischer: > Hi Andrea, > > On Sun, 08. Jun 2014 at 13:15:51 +0200, Andrea Peri wrote: >> The last response of Jef in the ticket explain clearly what it the strateguy >> of qgis.The important is tobe compatible with other software GS. Thie mean >> the QGIS-server don't metter for real wms compatibility and interoperability. > > I not the strateguy of qgis. I just speak for myself. So don't mistake > anything I say with what the "qgis group" is up to. > > BTW the other ignorant guy you have apparently been talking to doesn't speak > for the group either. But it would still be nice if you wouldn't attribute his > statements to me. ;) > > Sorry for the noise. I'm not constructive enough to get a fruitful discussion > going, so I'll move on to other tickets. > > > JÃrgen > > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Hi Andrea, On Sun, 08. Jun 2014 at 13:15:51 +0200, Andrea Peri wrote: > The last response of Jef in the ticket explain clearly what it the strateguy > of qgis.The important is tobe compatible with other software GS. Thie mean > the QGIS-server don't metter for real wms compatibility and interoperability. I not the strateguy of qgis. I just speak for myself. So don't mistake anything I say with what the "qgis group" is up to. BTW the other ignorant guy you have apparently been talking to doesn't speak for the group either. But it would still be nice if you wouldn't attribute his statements to me. ;) Sorry for the noise. I'm not constructive enough to get a fruitful discussion going, so I'll move on to other tickets. JÃrgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Hi, The last response of Jef in the ticket explain clearly what it the strateguy of qgis.The important is tobe compatible with other software GS. Thie mean the QGIS-server don't metter for real wms compatibility and interoperability. I guess is not really clear that the XML response to GetCapabilities is a protocol tocommunication between system. It is not only for other gis softwar. It is for every system can need to ask to the server wms. The response need to be aboslutely compatible tobe really interoperable. As example: this simplest case: http://www502.regione.toscana.it/geoscopio/servizi/wms/OFC.htm Tis html page is product autocatically from an our system Not gis that call the mapserver and with an xslt that parse the XML response produce this html page periodically. also thi http://www502.regione.toscana.it/geoscopio/servizi/wms/INFRASTRUTTURE_E_PRESIDI.htm and this http://www502.regione.toscana.it/geoscopio/servizi/wms/CTR.htm and so on Also we could use the same mechanism to implement a B2B colloquial betwen a metadato system and other systems or to the wms server. This mean to be interoprability. Mean grant to work with every other system that work with the same specs (WMS spacs in this case), not only with other GIS software. The server wms is not only a "maps-dispenser". This page http://www502.regione.toscana.it/geoscopio/servizi/wfs/html/comuni.html is product from another xslt proc that again parse a WFS response from a TinyOWS system (please notice also the wfs of qgis-server is not complaint to specs) This is an automatically parse of a wfs request to a tinyows that return the list of cadastral parcels and propose this page. http://www502.regione.toscana.it/geoscopio/servizi/wfs/html/elenco_foglicat.html?com=047001 This is the list of street of a single comunity http://www502.regione.toscana.it/geoscopio/servizi/wfs/html/elenco_strade.html?com=047001 And clicking on one of them you can jump to the system webgis to see them. Or you can have the civic number of every street. http://www502.regione.toscana.it/geoscopio/servizi/wfs/html/elenco_civici.html?com=047001&codtop=RT04700110007TO or jump to a webgis to see them. http://www502.regione.toscana.it/geoscopio/fototeca.html?codtpn=-91175&idtpn=21203 All of this mean to be interoperability. It mean to use many system differents but all understanding the same single set of informations and capable to exchange to each other the same information. Is not only a question betwen three or four software GIS. When I say arcgis or autoca try to explain that could be more other system that could be n difficult to operate with a qgis-server that resonse a non standard XML response at getcapability request. But if the response of qgis group is we see the main GIS software work and this is sufficient for us. This mean the QGIS-Server is not planning to be WMS compliant. I test the response with XMLSpy and see it is not compliant WMS because it fail when use the official xsd from OGC. Instead other product (mapserver and geoserver) will pass the test. If I report this issue and the response is: "is all okay for us". This response is more clearly of every other. Bye. Andrea. Il 08/giu/2014 09:07 "Mats Elfström" ha scritto: > Hi! > I have read this thread and I am puzzled. In my mind, standards and > interoperability are good, and should be respected. > Now tell me, is it a deliberate design choice not to make Qgis server OGC > compliant, and if so, why? > > Hälsning / Regards > Mats.E > > Skickat från min / Sent from my iPhone, Ursäkta att jag är kortfattad / > Excuse my brevity. > > 8 jun 2014 kl. 08:51 skrev Andrea Peri : > > Sorry Alex, > > As you certain know the > The QGIS server is really far from be a good WMS Server. > > It has not the multy style rendering. > It has not the "named groups" if don't allow to change the html response . > It don't allow to return a GML response to the user in a GetFeatureInfo if > don't active the WFS ption. > This is obviously unacceptable. > Because there is some layer that a Public Administration cannot put in > download as they are. > > The GeoServer and MapServer are real WMS Server and they allow all of this > and more other thinks. > > I don't speak of velocity where the coparing is impossible. > But alsoin the rendering capable. > I guess the Mapserver (the one that I know very well), has monay point of > advantage on qgisserver. > > The ONLY question good of qgis is The project qgis is the the same in the > server. > But this mean only that the qgis-server is good for fast prototyping, no > more. > > When go in production and the users grow the qgis-server will become > rapidly a bottle of neck. > > So the investiment need to enhance the qgisserver to have a good and fast > , fully complaince and affordable wms server are massive. > This could be ask to a public admiistration to fund. > > But if it is not a compliant wms server it could not never choose to > start. > > You think
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
[most of this is already in the ticket - I recapture here] Hi Mats, On Sun, 08. Jun 2014 at 09:07:33 +0200, Mats Elfström wrote: > Now tell me, is it a deliberate design choice not to make Qgis server OGC > compliant, and if so, why? QGIS server wasn't intentionally made incompliant. It was just extended. I don't know if any clients actually have problems with the service it offers, but those extensions actually make the validation of the GetCapabilities response fail. But the validation is a expensive process anyway and therefore most clients skip to validate and just use the response as is. That should work fine and so the invalidity of the response is probably a non-issue for most applications - and therefore went unnoticed (by wms clients and us) for quite a while. But extending the GetCapabilities response it also covered by the spec, so that itself isn't a problem either. It's just that the response needs to include another pointer to a document that describes the extensions and make validating the response document possible again. Only that part was missing in QGIS. Currently QGIS server offers GetLegendGraphic, GetStyles and GetPrint as extended requests. I'm not an XML expert (the GetCapabilities response is in XML), but including such an reference document seems to always introduce a new namespace and therefore extended requests always need to have a (namespace) prefix. So eg. GetPrint should be qgis:GetPrint instead. That's currently also not the case. So to fix this, we need to add prefixes, but that in turn might break clients that currently rely on the prefixless version. I don't know if there are any - but it makes me hesitant to change it. Anyway, the spec apparently allows to have the OGC schema at a different spot and doesn't clearly state that the copy needs to be identical - just probibits that "the normative content of the schema is changed". The current solution (which admittly has a smell) is that there is a document on qgis.org, that the qgis server response references instead of the OGC original and that document includes the original schema (by reference) and adds the extended requests the usual way, but in the process avoiding the prefix. If that complies with the quote above, we're fine now, although we might be bending the spec a little - but we're not breaking any existing clients and have validity now. We can come up with something better once we more about affected clients. I suppose the actual players in the qgis server field will join next week. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Sorry Alex, As you certain know the The QGIS server is really far from be a good WMS Server. It has not the multy style rendering. It has not the "named groups" if don't allow to change the html response . It don't allow to return a GML response to the user in a GetFeatureInfo if don't active the WFS ption. This is obviously unacceptable. Because there is some layer that a Public Administration cannot put in download as they are. The GeoServer and MapServer are real WMS Server and they allow all of this and more other thinks. I don't speak of velocity where the coparing is impossible. But alsoin the rendering capable. I guess the Mapserver (the one that I know very well), has monay point of advantage on qgisserver. The ONLY question good of qgis is The project qgis is the the same in the server. But this mean only that the qgis-server is good for fast prototyping, no more. When go in production and the users grow the qgis-server will become rapidly a bottle of neck. So the investiment need to enhance the qgisserver to have a good and fast , fully complaince and affordable wms server are massive. This could be ask to a public admiistration to fund. But if it is not a compliant wms server it could not never choose to start. You think really that ths is a killer advantage that could put an administration to choose an incopmaptible with the WMS specs piece of software instead of a fully compliant with the WMS specs ? :)) Is really ore easy to invest on an author for GeoServer of for Mapserver rather than waste public fund in a Incompatible piece of software. Because the laws deny to choose it. I guess you can also hope to sell your service to someone . But if it ask you: Hey your software is compliant with OGC WMS ? This is a mandatory need for inspire. You what say to your possible future client ? Yes (but you say that the real response is NO) or say No hoping that it say no problemI fund it to became, using the public money and rejecting other more compliance and also opensource soltion as mapserver or geoserver. As an exmaple: We fund really many enhancement in qgis. And refund the same think when pass from 1.8 to 2.0. After the our product was break in the pass from 2.0 to2.2 and now go to refund again to have them work in the 2.4. Now the qgis release every 3-4 month. These mean that a public administration should plan to refund all thei product on qgis every 3-4 months ? I guess this is an example clear of what mena affordable and reliability. I guess no one public administration could fund an incompatible piece of software to became compatible when there is other solution availables and compatibles. Returning to the incompatible qustion: Who put the GetPrint tags in the getcapabilities response ? It was the only to have a direct and immediate advantage. I dont know why do this, but can expected that it sell its product to someone. I say : ok you have your advantage, you have take your money, and now ? You have destroyed the credibility of qgis as an WMS Server OGC. You choose to eat the egg today instead of take the chicken tomorrow, and now ? Are you happy of this ? I guess who break repair. So I guess the solution should be put and fund by who involontary or volontary (i don't know) break the WMS specs compatibility. Or otherwise the qgis group say: we don't care about the wms compatibility so choose other software for this work. But I guess there many service seller that go around to sell service on qgis and say that it is a server wms compiant with WMS specs. It is a really bad "ok qgis is not usable for an OGC WMS infrastructure." If instead it is not happy of this it should repair what has break . I guess an public administration should not fund this reparation, otherwise every commite could think to have no proble to do what it like to do and after ask to the PA to fund for the repair from its break commit. Andrea. Il 08/06/2014 07:08, Alex Mandel ha scritto: You are assuming a new deployment and one where QGIS is not used on the desktop, where some groups may decide to use it for both in order to cut down on IT staffing requirements. You are also assuming the choice is as simple as picking a new one, there is plenty of people time involved in deploying a different strategy and redo-ing all the styling to fit the new way. Sure QGIS can push to geoserver now but running geosever means running a JAVA stack. Switching to Mapserver would be more similar with an apache setup but the QGIS export to Mapserver has long since fallen into disrepair so now you'd need to make separate style rules for 2 programs. I completely agree, QGIS should maintain compliance. My argument is that organizations that are shifting money from proprietary licenses should invest in ensuring an open source product meets their needs. To not do so means at any time there be no options that fit their requirements. I think I've also provided the links that show QGIS can be WMS compliant and s
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Sorry Alx, perhapsyou don't know well the WMS specs ? The QGIS server is really far from be a good WMS sErver. It has not the multy style rendering. It has not the "named groups" if don't allow to change the html response . It don't allow to return a GML response to the user in a GetFeatureInfo if don't active the WFS ption. This is obviously unacceptable. Because there is some layer that a Public Administration cannot put in download as they are. The GeoServer and MapServer are real WMS Server and they allow all of this and more other thinks. The ONLY question good of qgis is The project qgis is the the same in the server. You think really that ths is a killer advantage that could put an administration to choose an incopmaptible with the WMS specs piece of software instead of a fully compliant with the WMS specs ? :)) Is really ore easy to invest on an author for GeoServer of for Mapserver rather than waste public fund in a Incompatible piece of software. Because the laws deny to choose it. I guess you can also hope to sell your service to someone . But if it ask you: Hey your software is compliant with OGC WMS ? This is a mandatory need for inspire. You what say to your possible future client ? Yes or No but I hope you fund it to become. We fund really many enhancement in qgis. And fund also the repair when there was the break-api from 1.8 to 2.0 After funding the repair for 2.0 the compatibility was lost from 2.0 to 2.2. And now we need to refund the repair of compatibility from 2.2 to 2.4 What credibility could have a fnd that point to grnt a compatibilit of qgis 2.4 on WMS specs. Who put the GetPrint tags in the getprint ? It has do this to have an advantage and probably to sell its product to someone. I say : ok you have your advantage, you have take your money, and now ? You have destroyed the credibility of qgis as an WMS Server OGC. You choose to eat the egg today instead of take the chicken tomorrow, and now ? Are you happy of this ? I guess who break repair. So I guess the solution should be put and fund by who involontary or volontary (i don't know) break the WMS specs compatibility. Or otherwise the qgis group say: we don't care about the wms compatibility so choose other software for this work. But I guess there many service seller that go around to sell service on qgis and say that it is a server wms compiant with WMS specs. It is a really bad practice. And is necessary to make understand to the reader of this miling list that they actualy are funding for a good desktop software, but absolutely an incompatible server side component. This is necessary to know ewhen a public administration choose a software instead of another. Andrea. Il 08/06/2014 07:08, Alex Mandel ha scritto: You are assuming a new deployment and one where QGIS is not used on the desktop, where some groups may decide to use it for both in order to cut down on IT staffing requirements. You are also assuming the choice is as simple as picking a new one, there is plenty of people time involved in deploying a different strategy and redo-ing all the styling to fit the new way. Sure QGIS can push to geoserver now but running geosever means running a JAVA stack. Switching to Mapserver would be more similar with an apache setup but the QGIS export to Mapserver has long since fallen into disrepair so now you'd need to make separate style rules for 2 programs. I completely agree, QGIS should maintain compliance. My argument is that organizations that are shifting money from proprietary licenses should invest in ensuring an open source product meets their needs. To not do so means at any time there be no options that fit their requirements. I think I've also provided the links that show QGIS can be WMS compliant and still have extra options, the spec provides for how to do it, we just need to make the modifications and test it. Thanks, Alex On 06/07/2014 02:40 PM, Maurizio Trevisani wrote: Hello, you say "As to why fund it? If QGIS provides other value to your organization in some other way, total cost of operation may be lower to simply ensure it's compliant rather than to switch software or have to use multiple software." but as long you, Public Administration, can choose among several GFLOSS to implement your OGC services (that must be completely interoperable with all the potential clients and other PA), why should you choose a product that has choosen not to be interoperable? The problem is not the product, but the people who doesn't mind to write interoperable code: they are not reliable - so why a PA should fund them and their products? Qgis is an important product in the GFLOSS reality, but now more than ever should take care to complethely adhere to all the international standards, especially those which are at the basis for interoperability. Bye. 2014-06-07 22:17 GMT+02:00, Alex Mandel : On 06/07/2014 01:06 PM, Andrea Peri wrote: Yes also this is possib
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
You are assuming a new deployment and one where QGIS is not used on the desktop, where some groups may decide to use it for both in order to cut down on IT staffing requirements. You are also assuming the choice is as simple as picking a new one, there is plenty of people time involved in deploying a different strategy and redo-ing all the styling to fit the new way. Sure QGIS can push to geoserver now but running geosever means running a JAVA stack. Switching to Mapserver would be more similar with an apache setup but the QGIS export to Mapserver has long since fallen into disrepair so now you'd need to make separate style rules for 2 programs. I completely agree, QGIS should maintain compliance. My argument is that organizations that are shifting money from proprietary licenses should invest in ensuring an open source product meets their needs. To not do so means at any time there be no options that fit their requirements. I think I've also provided the links that show QGIS can be WMS compliant and still have extra options, the spec provides for how to do it, we just need to make the modifications and test it. Thanks, Alex On 06/07/2014 02:40 PM, Maurizio Trevisani wrote: > Hello, > you say > > "As to why fund it? If QGIS provides other value to your organization in > some other way, total cost of operation may be lower to simply ensure > it's compliant rather than to switch software or have to use multiple > software." > > but as long you, Public Administration, can choose among several > GFLOSS to implement your OGC services (that must be completely > interoperable with all the potential clients and other PA), why should > you choose a product that has choosen not to be interoperable? > > The problem is not the product, but the people who doesn't mind to > write interoperable code: they are not reliable - so why a PA should > fund them and their products? > > Qgis is an important product in the GFLOSS reality, but now more than > ever should take care to complethely adhere to all the international > standards, especially those which are at the basis for > interoperability. > > Bye. > > 2014-06-07 22:17 GMT+02:00, Alex Mandel : >> On 06/07/2014 01:06 PM, Andrea Peri wrote: >>> Yes also this is possible, >>> but pay attention to use it correctly. >>> I guess it is no really simple to use (ie to define the extension). >> >> It looks really simple to use according to the docs. If it works and >> cascading WMS works with other WMS servers, and it passes the schema >> check I see no issue. >> >> >>> In the SLD world this was allowed and a unfortunately and worst >>> understanding of it will born a lot of incompatible dialects. >>> Also in the metadata world (iso19115) the possibility to extend the specs >>> will produce incompatibility monster. >>> :) >> This exists in the html world, over time there are winners. If you don't >> care to use the extra features you are always welcome to use the base >> which is 100% compliant. The winners or some compromise variant end up >> in the next version of the spec. >> >>> I guess surely better and easy is put the new functions in in a distinct >>> and new kind of request. >>> >> >> After reading the WMS doc I believe using the tags I mention is the >> correct way to do it. Technically the result is WMS 1.3.0 compliant. >> Clients are free to ignore the extra functions as not using them does >> not remove any required features. >> >> As to why fund it? If QGIS provides other value to your organization in >> some other way, total cost of operation may be lower to simply ensure >> it's compliant rather than to switch software or have to use multiple >> software. >> >> Thanks, >> Alex >> >> >>> Andrea. >>> >>> >>> >>> 2014-06-07 21:56 GMT+02:00 Alex Mandel : >>> I just checked the WMS 1.3.0 specification document http://portal.opengeospatial.org/files/?artifact_id=14416 Extended optional features are allowed. There is a specific way to include them. See section 6.9.5 "Extended capabilities and operations" <_ExtendedCapabilities> or <_ExtendedOperations> So perhaps we just need to wrap those extra options in a specific tag for them to pass schema testing. Thanks, Alex On 06/07/2014 12:35 PM, Alex Mandel wrote: > I understand the issue now. In order to be WMS 1.3 complaint you can > only use what's in the spec. > > Looking at an analogy with html specs I find this limitation appalling > short-sighted. It means there can be no innovation testing new features > with the spec unless you manage to get it into the future spec. I find > it hard to comprehend that clients don't just skip tags that fail to > match a known tag. In html land its very common for some browsers to > know some non-standard tags, which are new features in testing to be > proposed or reworked into future standards. IE's policy of only > adhering > to the spec and including no expe
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
This is not only a inspire need. This more important because is an WMS invalidity. I try to explain better. The mapserver was not inpire compliant because it miss of something metadata elements. OK, but almost it was OGC WMS compliant. The inspire specs say "take an OGC WMS compliant and on it add something that I say to you". The QGIS IS not WMS Compliant . This is worst than inspire non compliant. Also inspire say "the interoperability" is the base to start all together. The invalidity of qgis-server is due to the add of a proprietary tag that fail the xsd tests OGC WMS. So it is not interoperability with other products. This is worst than : To be more inspire compliant. The question here is: qgis-erver is not OGC WMS compliant. However I say what is the problem: The ticket is here: http://hub.qgis.org/issues/10489 The problem are a worst definition of the Tag GetLegendGraphics, but as report in the ticket the solution is described in the ticket. The other two probles are the presence of a GetStyle in the wms 1.3.0 response. The GetStyle was dismissed from OGC in the 1.3.0 response. And the presence of the proprietary tag "GetPrint". My simplesolution was change the GetLegendGraphics. This is a simply change in the code. I have patched my server using "sld" prefix because is the standard. But also the solution of Jef to use the "qgis" prefix is ok because is valid for a good validator (xmlspy I use). So If the qgis groups decide to adopt the "qgis" prefix namespace for GetLegendGraphics, I have no problem to change my patch. Otherwise I leave the standard name "sld". The other two problems. GetStyles and GetPrint. They are not tags of the WMS 1.3.0 specs. So they should not be present in the response. The solution is remove them or put them in the specific dedicated section. But obviously they are put correctly in that section. Thx, Andrea. 2014-06-07 22:19 GMT+02:00 Alex Mandel : > Please add your specific list of current non-compliant issue to: > http://hub.qgis.org/issues/6520 > > I'll add in a note about the WMS 1.3 tags specifically created for > non-standard features. > > I think this issue can be resolved. > > Thanks, > Alex > > On 06/07/2014 01:17 PM, Alex Mandel wrote: > > On 06/07/2014 01:06 PM, Andrea Peri wrote: > >> Yes also this is possible, > >> but pay attention to use it correctly. > >> I guess it is no really simple to use (ie to define the extension). > > > > It looks really simple to use according to the docs. If it works and > > cascading WMS works with other WMS servers, and it passes the schema > > check I see no issue. > > > > > >> In the SLD world this was allowed and a unfortunately and worst > >> understanding of it will born a lot of incompatible dialects. > >> Also in the metadata world (iso19115) the possibility to extend the > specs > >> will produce incompatibility monster. > >> :) > > This exists in the html world, over time there are winners. If you don't > > care to use the extra features you are always welcome to use the base > > which is 100% compliant. The winners or some compromise variant end up > > in the next version of the spec. > > > >> I guess surely better and easy is put the new functions in in a distinct > >> and new kind of request. > >> > > > > After reading the WMS doc I believe using the tags I mention is the > > correct way to do it. Technically the result is WMS 1.3.0 compliant. > > Clients are free to ignore the extra functions as not using them does > > not remove any required features. > > > > As to why fund it? If QGIS provides other value to your organization in > > some other way, total cost of operation may be lower to simply ensure > > it's compliant rather than to switch software or have to use multiple > > software. > > > > Thanks, > > Alex > > > > > >> Andrea. > >> > >> > >> > >> 2014-06-07 21:56 GMT+02:00 Alex Mandel : > >> > >>> I just checked the WMS 1.3.0 specification document > >>> http://portal.opengeospatial.org/files/?artifact_id=14416 > >>> > >>> Extended optional features are allowed. There is a specific way to > >>> include them. See section 6.9.5 "Extended capabilities and operations" > >>> <_ExtendedCapabilities> or <_ExtendedOperations> > >>> > >>> So perhaps we just need to wrap those extra options in a specific tag > >>> for them to pass schema testing. > >>> > >>> Thanks, > >>> Alex > >>> > >>> On 06/07/2014 12:35 PM, Alex Mandel wrote: > I understand the issue now. In order to be WMS 1.3 complaint you can > only use what's in the spec. > > Looking at an analogy with html specs I find this limitation appalling > short-sighted. It means there can be no innovation testing new > features > with the spec unless you manage to get it into the future spec. I find > it hard to comprehend that clients don't just skip tags that fail to > match a known tag. In html land its very common for some browsers to > know some non-standard tags, which are new features in test
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Please add your specific list of current non-compliant issue to: http://hub.qgis.org/issues/6520 I'll add in a note about the WMS 1.3 tags specifically created for non-standard features. I think this issue can be resolved. Thanks, Alex On 06/07/2014 01:17 PM, Alex Mandel wrote: > On 06/07/2014 01:06 PM, Andrea Peri wrote: >> Yes also this is possible, >> but pay attention to use it correctly. >> I guess it is no really simple to use (ie to define the extension). > > It looks really simple to use according to the docs. If it works and > cascading WMS works with other WMS servers, and it passes the schema > check I see no issue. > > >> In the SLD world this was allowed and a unfortunately and worst >> understanding of it will born a lot of incompatible dialects. >> Also in the metadata world (iso19115) the possibility to extend the specs >> will produce incompatibility monster. >> :) > This exists in the html world, over time there are winners. If you don't > care to use the extra features you are always welcome to use the base > which is 100% compliant. The winners or some compromise variant end up > in the next version of the spec. > >> I guess surely better and easy is put the new functions in in a distinct >> and new kind of request. >> > > After reading the WMS doc I believe using the tags I mention is the > correct way to do it. Technically the result is WMS 1.3.0 compliant. > Clients are free to ignore the extra functions as not using them does > not remove any required features. > > As to why fund it? If QGIS provides other value to your organization in > some other way, total cost of operation may be lower to simply ensure > it's compliant rather than to switch software or have to use multiple > software. > > Thanks, > Alex > > >> Andrea. >> >> >> >> 2014-06-07 21:56 GMT+02:00 Alex Mandel : >> >>> I just checked the WMS 1.3.0 specification document >>> http://portal.opengeospatial.org/files/?artifact_id=14416 >>> >>> Extended optional features are allowed. There is a specific way to >>> include them. See section 6.9.5 "Extended capabilities and operations" >>> <_ExtendedCapabilities> or <_ExtendedOperations> >>> >>> So perhaps we just need to wrap those extra options in a specific tag >>> for them to pass schema testing. >>> >>> Thanks, >>> Alex >>> >>> On 06/07/2014 12:35 PM, Alex Mandel wrote: I understand the issue now. In order to be WMS 1.3 complaint you can only use what's in the spec. Looking at an analogy with html specs I find this limitation appalling short-sighted. It means there can be no innovation testing new features with the spec unless you manage to get it into the future spec. I find it hard to comprehend that clients don't just skip tags that fail to match a known tag. In html land its very common for some browsers to know some non-standard tags, which are new features in testing to be proposed or reworked into future standards. IE's policy of only adhering to the spec and including no experimental tag support has been seen be web designers as discouraging to any change. Why, because their is no way to publicly test new ideas. So from the QGIS side, in order to comply we would need to reply with only allowed tags if a user requests WMS=1.3.0, we can reply with more stuff like GetPrint if they don't specify that version. Or perhaps we have to invent a 1.3.0+ variant specifically for when a user knows it's QGIS server. Anyone more familiar with WMS that can shed more light on the best way to work around this issue and have both compliance and the ability to add extra features that have no standard equivalent yet. My point still stands, that EU agencies with this concern should be funding compliance efforts, not removing funding for lack of compliance. Thanks, Alex On 06/07/2014 12:23 PM, Andrea Peri wrote: > Hi, > I need to be more clear. > My english is tremendous. > :) > > The Interoperability mean to have a small set of operation euals on >>> EVERY > Server WMS. > > Equals mena same reqeust , same response. > > So when a Cleit WMS send a Request of GetCapabilities, The response >>> should > be the same from QGIS-server or from GeoServer or From Mapserver. > > The same response mean that every product use the same dialect the same > tags and so on. > > > The XSD OGC is the dictionary that every wms client and server should >>> use > to know the right language and tags. > > When the QGIS_Server response to a request GetCapbility with an XML that > contains the GetPrint tags. > The client wms say "hey what is this ? It is not in the XSD OGC. This >>> mean > your response is wrong." > > Of course there are some client wms that don0t do a validation of >>> response, > they HOPE that the response will be exactly as
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
On 06/07/2014 01:06 PM, Andrea Peri wrote: > Yes also this is possible, > but pay attention to use it correctly. > I guess it is no really simple to use (ie to define the extension). It looks really simple to use according to the docs. If it works and cascading WMS works with other WMS servers, and it passes the schema check I see no issue. > In the SLD world this was allowed and a unfortunately and worst > understanding of it will born a lot of incompatible dialects. > Also in the metadata world (iso19115) the possibility to extend the specs > will produce incompatibility monster. > :) This exists in the html world, over time there are winners. If you don't care to use the extra features you are always welcome to use the base which is 100% compliant. The winners or some compromise variant end up in the next version of the spec. > I guess surely better and easy is put the new functions in in a distinct > and new kind of request. > After reading the WMS doc I believe using the tags I mention is the correct way to do it. Technically the result is WMS 1.3.0 compliant. Clients are free to ignore the extra functions as not using them does not remove any required features. As to why fund it? If QGIS provides other value to your organization in some other way, total cost of operation may be lower to simply ensure it's compliant rather than to switch software or have to use multiple software. Thanks, Alex > Andrea. > > > > 2014-06-07 21:56 GMT+02:00 Alex Mandel : > >> I just checked the WMS 1.3.0 specification document >> http://portal.opengeospatial.org/files/?artifact_id=14416 >> >> Extended optional features are allowed. There is a specific way to >> include them. See section 6.9.5 "Extended capabilities and operations" >> <_ExtendedCapabilities> or <_ExtendedOperations> >> >> So perhaps we just need to wrap those extra options in a specific tag >> for them to pass schema testing. >> >> Thanks, >> Alex >> >> On 06/07/2014 12:35 PM, Alex Mandel wrote: >>> I understand the issue now. In order to be WMS 1.3 complaint you can >>> only use what's in the spec. >>> >>> Looking at an analogy with html specs I find this limitation appalling >>> short-sighted. It means there can be no innovation testing new features >>> with the spec unless you manage to get it into the future spec. I find >>> it hard to comprehend that clients don't just skip tags that fail to >>> match a known tag. In html land its very common for some browsers to >>> know some non-standard tags, which are new features in testing to be >>> proposed or reworked into future standards. IE's policy of only adhering >>> to the spec and including no experimental tag support has been seen be >>> web designers as discouraging to any change. Why, because their is no >>> way to publicly test new ideas. >>> >>> So from the QGIS side, in order to comply we would need to reply with >>> only allowed tags if a user requests WMS=1.3.0, we can reply with more >>> stuff like GetPrint if they don't specify that version. Or perhaps we >>> have to invent a 1.3.0+ variant specifically for when a user knows it's >>> QGIS server. >>> >>> Anyone more familiar with WMS that can shed more light on the best way >>> to work around this issue and have both compliance and the ability to >>> add extra features that have no standard equivalent yet. >>> >>> My point still stands, that EU agencies with this concern should be >>> funding compliance efforts, not removing funding for lack of compliance. >>> >>> Thanks, >>> Alex >>> >>> On 06/07/2014 12:23 PM, Andrea Peri wrote: Hi, I need to be more clear. My english is tremendous. :) The Interoperability mean to have a small set of operation euals on >> EVERY Server WMS. Equals mena same reqeust , same response. So when a Cleit WMS send a Request of GetCapabilities, The response >> should be the same from QGIS-server or from GeoServer or From Mapserver. The same response mean that every product use the same dialect the same tags and so on. The XSD OGC is the dictionary that every wms client and server should >> use to know the right language and tags. When the QGIS_Server response to a request GetCapbility with an XML that contains the GetPrint tags. The client wms say "hey what is this ? It is not in the XSD OGC. This >> mean your response is wrong." Of course there are some client wms that don0t do a validation of >> response, they HOPE that the response will be exactly as they exected. If this is not true. They go in crash or other bad situation. Again the resence of a Tag not compliant with XSD OGC will create incompatibility. Think to a client that will parse the xml response and say: ok the GetLegendGraphics tag is passed now there is "this well know >> tag". Instead arrive a GetPrint tags. The client wms become crazy. >>>
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
Yes also this is possible, but pay attention to use it correctly. I guess it is no really simple to use (ie to define the extension). In the SLD world this was allowed and a unfortunately and worst understanding of it will born a lot of incompatible dialects. Also in the metadata world (iso19115) the possibility to extend the specs will produce incompatibility monster. :) I guess surely better and easy is put the new functions in in a distinct and new kind of request. Andrea. 2014-06-07 21:56 GMT+02:00 Alex Mandel : > I just checked the WMS 1.3.0 specification document > http://portal.opengeospatial.org/files/?artifact_id=14416 > > Extended optional features are allowed. There is a specific way to > include them. See section 6.9.5 "Extended capabilities and operations" > <_ExtendedCapabilities> or <_ExtendedOperations> > > So perhaps we just need to wrap those extra options in a specific tag > for them to pass schema testing. > > Thanks, > Alex > > On 06/07/2014 12:35 PM, Alex Mandel wrote: > > I understand the issue now. In order to be WMS 1.3 complaint you can > > only use what's in the spec. > > > > Looking at an analogy with html specs I find this limitation appalling > > short-sighted. It means there can be no innovation testing new features > > with the spec unless you manage to get it into the future spec. I find > > it hard to comprehend that clients don't just skip tags that fail to > > match a known tag. In html land its very common for some browsers to > > know some non-standard tags, which are new features in testing to be > > proposed or reworked into future standards. IE's policy of only adhering > > to the spec and including no experimental tag support has been seen be > > web designers as discouraging to any change. Why, because their is no > > way to publicly test new ideas. > > > > So from the QGIS side, in order to comply we would need to reply with > > only allowed tags if a user requests WMS=1.3.0, we can reply with more > > stuff like GetPrint if they don't specify that version. Or perhaps we > > have to invent a 1.3.0+ variant specifically for when a user knows it's > > QGIS server. > > > > Anyone more familiar with WMS that can shed more light on the best way > > to work around this issue and have both compliance and the ability to > > add extra features that have no standard equivalent yet. > > > > My point still stands, that EU agencies with this concern should be > > funding compliance efforts, not removing funding for lack of compliance. > > > > Thanks, > > Alex > > > > On 06/07/2014 12:23 PM, Andrea Peri wrote: > >> Hi, > >> I need to be more clear. > >> My english is tremendous. > >> :) > >> > >> The Interoperability mean to have a small set of operation euals on > EVERY > >> Server WMS. > >> > >> Equals mena same reqeust , same response. > >> > >> So when a Cleit WMS send a Request of GetCapabilities, The response > should > >> be the same from QGIS-server or from GeoServer or From Mapserver. > >> > >> The same response mean that every product use the same dialect the same > >> tags and so on. > >> > >> > >> The XSD OGC is the dictionary that every wms client and server should > use > >> to know the right language and tags. > >> > >> When the QGIS_Server response to a request GetCapbility with an XML that > >> contains the GetPrint tags. > >> The client wms say "hey what is this ? It is not in the XSD OGC. This > mean > >> your response is wrong." > >> > >> Of course there are some client wms that don0t do a validation of > response, > >> they HOPE that the response will be exactly as they exected. > >> If this is not true. They go in crash or other bad situation. > >> > >> Again the resence of a Tag not compliant with XSD OGC will create > >> incompatibility. > >> > >> Think to a client that will parse the xml response and say: > >> > >> ok the GetLegendGraphics tag is passed now there is "this well know > tag". > >> > >> Instead arrive a GetPrint tags. > >> > >> The client wms become crazy. > >> > >> Of course QGIS will understand it. > >> But this is because you (qgis group) manage it to work. > >> > >> But other clients don't know that tag and so they are not able to > extract > >> all the information from Capabilities response. > >> This is a bad practice also because create artiiciosally an > incopatibility > >> with other products. > >> Instead Inspire ask for INteroperability from every product. > >> > >> Interoperability don't mean use all the same unique product. (This is > the > >> microsoft philosophy) > >> Interoperability mean All the product must use the same little set of > >> command and the response at these command should be compatible > >> (interoperable) between all of them > >> > >> Actulally this is not true for the response xml of qgis-server at a > >> getcapability request. > >> > >> Hope to be better explain, now. > >> > >> Andrea. > >> > >> > >> 2014-06-07 20:49 GMT+02:00 Andrea Peri : > >> > >>> Hi Alex, > >>> > >>> The question is not the p
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
I just checked the WMS 1.3.0 specification document http://portal.opengeospatial.org/files/?artifact_id=14416 Extended optional features are allowed. There is a specific way to include them. See section 6.9.5 "Extended capabilities and operations" <_ExtendedCapabilities> or <_ExtendedOperations> So perhaps we just need to wrap those extra options in a specific tag for them to pass schema testing. Thanks, Alex On 06/07/2014 12:35 PM, Alex Mandel wrote: > I understand the issue now. In order to be WMS 1.3 complaint you can > only use what's in the spec. > > Looking at an analogy with html specs I find this limitation appalling > short-sighted. It means there can be no innovation testing new features > with the spec unless you manage to get it into the future spec. I find > it hard to comprehend that clients don't just skip tags that fail to > match a known tag. In html land its very common for some browsers to > know some non-standard tags, which are new features in testing to be > proposed or reworked into future standards. IE's policy of only adhering > to the spec and including no experimental tag support has been seen be > web designers as discouraging to any change. Why, because their is no > way to publicly test new ideas. > > So from the QGIS side, in order to comply we would need to reply with > only allowed tags if a user requests WMS=1.3.0, we can reply with more > stuff like GetPrint if they don't specify that version. Or perhaps we > have to invent a 1.3.0+ variant specifically for when a user knows it's > QGIS server. > > Anyone more familiar with WMS that can shed more light on the best way > to work around this issue and have both compliance and the ability to > add extra features that have no standard equivalent yet. > > My point still stands, that EU agencies with this concern should be > funding compliance efforts, not removing funding for lack of compliance. > > Thanks, > Alex > > On 06/07/2014 12:23 PM, Andrea Peri wrote: >> Hi, >> I need to be more clear. >> My english is tremendous. >> :) >> >> The Interoperability mean to have a small set of operation euals on EVERY >> Server WMS. >> >> Equals mena same reqeust , same response. >> >> So when a Cleit WMS send a Request of GetCapabilities, The response should >> be the same from QGIS-server or from GeoServer or From Mapserver. >> >> The same response mean that every product use the same dialect the same >> tags and so on. >> >> >> The XSD OGC is the dictionary that every wms client and server should use >> to know the right language and tags. >> >> When the QGIS_Server response to a request GetCapbility with an XML that >> contains the GetPrint tags. >> The client wms say "hey what is this ? It is not in the XSD OGC. This mean >> your response is wrong." >> >> Of course there are some client wms that don0t do a validation of response, >> they HOPE that the response will be exactly as they exected. >> If this is not true. They go in crash or other bad situation. >> >> Again the resence of a Tag not compliant with XSD OGC will create >> incompatibility. >> >> Think to a client that will parse the xml response and say: >> >> ok the GetLegendGraphics tag is passed now there is "this well know tag". >> >> Instead arrive a GetPrint tags. >> >> The client wms become crazy. >> >> Of course QGIS will understand it. >> But this is because you (qgis group) manage it to work. >> >> But other clients don't know that tag and so they are not able to extract >> all the information from Capabilities response. >> This is a bad practice also because create artiiciosally an incopatibility >> with other products. >> Instead Inspire ask for INteroperability from every product. >> >> Interoperability don't mean use all the same unique product. (This is the >> microsoft philosophy) >> Interoperability mean All the product must use the same little set of >> command and the response at these command should be compatible >> (interoperable) between all of them >> >> Actulally this is not true for the response xml of qgis-server at a >> getcapability request. >> >> Hope to be better explain, now. >> >> Andrea. >> >> >> 2014-06-07 20:49 GMT+02:00 Andrea Peri : >> >>> Hi Alex, >>> >>> The question is not the print capability. >>> >>> The question is to LOST THE INTEROPERABILITY >>> >>> If qgis response an xml that is not OGC complaint it is not interoperable >>> with other product. >>> >>> As example: >>> >>> if an public Administration will eed to do a cascading wms with the server >>> wms of another public administration. >>> The server before of all call for a GetCapability. >>> >>> If the response has a tag proprietary. If fail. >>> This need Not Interoperable. >>> >>> I dont say do not do a getprint. >>> >>> I say remove tha tag GetPrint from the GetCapabilities response. >>> It is not a OGC tag and so that response is not interoperable as requested >>> from Inspire specification. >>> >>> Regards, >>> >>> >>> >>> 2014-06-07 20:36 GMT+02:00 Alex Mandel :
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
No, you can esperiment new functionality . Simply you cannot put them in a standard response. The right solution is what say Steafn in ticket. QGIS has a request QGISPropterySettings. The new powerful but incompatible features put them in it. Don't abuse of standard responses. . Also: You don't undestand. I don't spaek the agency EU. The inspire directive say: that the europan menbers italy, france, deutch, and so on... must recepit the directive them and all their sub agency national and local. The directive don't say fund to put a qgis to be compiant. The drective say use only compliant and interoperability wms product . The EU put no money for this. Every menber can use it want . Commercial or Open product is indifferent. The imprtant is that it is interoperability. The Geoserver is interoperabilyt The Mapserver is interoperability. Why A public administration should choose QGIS-server ? It mean lost fund when there is some one more and more copliant with Inspire. What is the motivation to spend public resource to have a a QGIS-server comliant. I guess this should be interest of who sell service on QGIS to have a qgis compliant otherwise it has not a market in the public administrations. Or better again. Why there is a GetPrint and GetStyle s tags ? In the response: the more easy solution is remove these two tags. I do it in few minutes and can give the patch at we ask me. So why there is this two tags ? They are put from someone. This someone has break the qgis wms compatibility. SO AFAIK should be it to fund for repair what it break. Regards, Andrea. 2014-06-07 21:35 GMT+02:00 Alex Mandel : > I understand the issue now. In order to be WMS 1.3 complaint you can > only use what's in the spec. > > Looking at an analogy with html specs I find this limitation appalling > short-sighted. It means there can be no innovation testing new features > with the spec unless you manage to get it into the future spec. I find > it hard to comprehend that clients don't just skip tags that fail to > match a known tag. In html land its very common for some browsers to > know some non-standard tags, which are new features in testing to be > proposed or reworked into future standards. IE's policy of only adhering > to the spec and including no experimental tag support has been seen be > web designers as discouraging to any change. Why, because their is no > way to publicly test new ideas. > > So from the QGIS side, in order to comply we would need to reply with > only allowed tags if a user requests WMS=1.3.0, we can reply with more > stuff like GetPrint if they don't specify that version. Or perhaps we > have to invent a 1.3.0+ variant specifically for when a user knows it's > QGIS server. > > Anyone more familiar with WMS that can shed more light on the best way > to work around this issue and have both compliance and the ability to > add extra features that have no standard equivalent yet. > > My point still stands, that EU agencies with this concern should be > funding compliance efforts, not removing funding for lack of compliance. > > Thanks, > Alex > > On 06/07/2014 12:23 PM, Andrea Peri wrote: > > Hi, > > I need to be more clear. > > My english is tremendous. > > :) > > > > The Interoperability mean to have a small set of operation euals on EVERY > > Server WMS. > > > > Equals mena same reqeust , same response. > > > > So when a Cleit WMS send a Request of GetCapabilities, The response > should > > be the same from QGIS-server or from GeoServer or From Mapserver. > > > > The same response mean that every product use the same dialect the same > > tags and so on. > > > > > > The XSD OGC is the dictionary that every wms client and server should use > > to know the right language and tags. > > > > When the QGIS_Server response to a request GetCapbility with an XML that > > contains the GetPrint tags. > > The client wms say "hey what is this ? It is not in the XSD OGC. This > mean > > your response is wrong." > > > > Of course there are some client wms that don0t do a validation of > response, > > they HOPE that the response will be exactly as they exected. > > If this is not true. They go in crash or other bad situation. > > > > Again the resence of a Tag not compliant with XSD OGC will create > > incompatibility. > > > > Think to a client that will parse the xml response and say: > > > > ok the GetLegendGraphics tag is passed now there is "this well know tag". > > > > Instead arrive a GetPrint tags. > > > > The client wms become crazy. > > > > Of course QGIS will understand it. > > But this is because you (qgis group) manage it to work. > > > > But other clients don't know that tag and so they are not able to extract > > all the information from Capabilities response. > > This is a bad practice also because create artiiciosally an > incopatibility > > with other products. > > Instead Inspire ask for INteroperability from every product. > > > > Interoperability don't mean use all the same unique
Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?
I understand the issue now. In order to be WMS 1.3 complaint you can only use what's in the spec. Looking at an analogy with html specs I find this limitation appalling short-sighted. It means there can be no innovation testing new features with the spec unless you manage to get it into the future spec. I find it hard to comprehend that clients don't just skip tags that fail to match a known tag. In html land its very common for some browsers to know some non-standard tags, which are new features in testing to be proposed or reworked into future standards. IE's policy of only adhering to the spec and including no experimental tag support has been seen be web designers as discouraging to any change. Why, because their is no way to publicly test new ideas. So from the QGIS side, in order to comply we would need to reply with only allowed tags if a user requests WMS=1.3.0, we can reply with more stuff like GetPrint if they don't specify that version. Or perhaps we have to invent a 1.3.0+ variant specifically for when a user knows it's QGIS server. Anyone more familiar with WMS that can shed more light on the best way to work around this issue and have both compliance and the ability to add extra features that have no standard equivalent yet. My point still stands, that EU agencies with this concern should be funding compliance efforts, not removing funding for lack of compliance. Thanks, Alex On 06/07/2014 12:23 PM, Andrea Peri wrote: > Hi, > I need to be more clear. > My english is tremendous. > :) > > The Interoperability mean to have a small set of operation euals on EVERY > Server WMS. > > Equals mena same reqeust , same response. > > So when a Cleit WMS send a Request of GetCapabilities, The response should > be the same from QGIS-server or from GeoServer or From Mapserver. > > The same response mean that every product use the same dialect the same > tags and so on. > > > The XSD OGC is the dictionary that every wms client and server should use > to know the right language and tags. > > When the QGIS_Server response to a request GetCapbility with an XML that > contains the GetPrint tags. > The client wms say "hey what is this ? It is not in the XSD OGC. This mean > your response is wrong." > > Of course there are some client wms that don0t do a validation of response, > they HOPE that the response will be exactly as they exected. > If this is not true. They go in crash or other bad situation. > > Again the resence of a Tag not compliant with XSD OGC will create > incompatibility. > > Think to a client that will parse the xml response and say: > > ok the GetLegendGraphics tag is passed now there is "this well know tag". > > Instead arrive a GetPrint tags. > > The client wms become crazy. > > Of course QGIS will understand it. > But this is because you (qgis group) manage it to work. > > But other clients don't know that tag and so they are not able to extract > all the information from Capabilities response. > This is a bad practice also because create artiiciosally an incopatibility > with other products. > Instead Inspire ask for INteroperability from every product. > > Interoperability don't mean use all the same unique product. (This is the > microsoft philosophy) > Interoperability mean All the product must use the same little set of > command and the response at these command should be compatible > (interoperable) between all of them > > Actulally this is not true for the response xml of qgis-server at a > getcapability request. > > Hope to be better explain, now. > > Andrea. > > > 2014-06-07 20:49 GMT+02:00 Andrea Peri : > >> Hi Alex, >> >> The question is not the print capability. >> >> The question is to LOST THE INTEROPERABILITY >> >> If qgis response an xml that is not OGC complaint it is not interoperable >> with other product. >> >> As example: >> >> if an public Administration will eed to do a cascading wms with the server >> wms of another public administration. >> The server before of all call for a GetCapability. >> >> If the response has a tag proprietary. If fail. >> This need Not Interoperable. >> >> I dont say do not do a getprint. >> >> I say remove tha tag GetPrint from the GetCapabilities response. >> It is not a OGC tag and so that response is not interoperable as requested >> from Inspire specification. >> >> Regards, >> >> >> >> 2014-06-07 20:36 GMT+02:00 Alex Mandel : >> >> On 06/07/2014 11:19 AM, Andrea Peri wrote: Hi, AFAIK the qgis server is not complaint with Inspire. This beacausethe Response to GetCapabilities is not responding to the requisite that the OGC will require for it. Originally the qgis was simply generate an incompatible response for the XSD of OGC. The response is ncompatible for thre thinks: 1) the GetCapabilities is in the wrong namespace. This is a silly question anc could be easily resolved. 2) The presence of the GetStyle that is dismissed fro
