[Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

Sat Jun 7 16:20:38 PDT 2014

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 <tech_dev at wildintellect.com>:

> 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 <tech_dev at wildintellect.com>:
> >>
> >>> 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 <aperi2007 at gmail.com>:
> >>>>>
> >>>>>> 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 <tech_dev at wildintellect.com
> >:
> >>>>>>
> >>>>>> 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 from OGC wms 1.3.0.
> >>>>>>>> Please notice that the Inspire require the WMS 1.3.0 .
> >>>>>>>> To resolve this the QGIS groups has copied the XSD of OGC and
> >>> modifica
> >>>>>>> it
> >>>>>>>> to redirect to a different XSD not in the OGC site.
> >>>>>>>>
> >>>>>>>> 3) The presence of a Proprietary tag inserted without any
> reference
> >>> to
> >>>>>>> any
> >>>>>>>> standard.
> >>>>>>>> The GetPrint.
> >>>>>>>> This is not present in any other product.
> >>>>>>>>
> >>>>>>>> My question is for any person of a Public Administration that
> plan or
> >>>>>>> are
> >>>>>>>> funding QGIS.
> >>>>>>>>
> >>>>>>>> In Europe the Inspire directive will ask to promove the
> >>>>>>> Interoperability.
> >>>>>>>>
> >>>>>>>> The interoperability strategy ask that every produc that allow the
> >>>>>>> inspire
> >>>>>>>> directive will speak the same language using the same tags and
> >>>>>>>> functionality.
> >>>>>>>>
> >>>>>>>> The QGIS solution to add a proprietary tag and to write a own
> >>> different
> >>>>>>> xsd
> >>>>>>>> that overlap the standard OGC xsd will create the presuppost
> (AFAIK)
> >>> to
> >>>>>>>> vilate the Inspire directive.
> >>>>>>>>
> >>>>>>>> If this is true A Public Administration should not use the QGIS.
> >>>>>>>>
> >>>>>>>> This is a realproblem for us that invest many fund on qgis.
> >>>>>>>>
> >>>>>>>> So I like toknow the opinion of other public administration.
> >>>>>>>>
> >>>>>>>> Before still fund a product that seem to violate the Inspire
> >>> directive
> >>>>>>>> principles.
> >>>>>>>>
> >>>>>>>> Thx,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> To me the question is flipped. What needs to be funded, probably
> by EU
> >>>>>>> agencies to ensure INSPIRE compliance of QGIS Server?
> >>>>>>> It looks like you've put together the list of what needs to be
> fixed,
> >>> so
> >>>>>>> the target should be easier. I am little puzzled about not allowing
> >>> for
> >>>>>>> extra functions that are not in the standard. Unless the WMS has a
> >>> print
> >>>>>>> standard an extra print add-on doesn't break any expectations. Who
> >>>>>>> knows, maybe that should be submitted as an extension to WMS.
> >>>>>>>
> >>>>>>>
> >>>>>>> Note, this should have no effect on funding and usage of QGIS
> desktop.
> >>>>>>> Maybe Paolo has good numbers on if EU agencies are funding Server
> vs
> >>>>>>> Desktop features.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Alex
> >>>>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Qgis-user mailing list
> >> Qgis-user at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-user
> >>
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
>

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140608/2da644a4/attachment-0001.html>