<div dir="ltr">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Sorry Alex,<br>
    <br>As you certain know the <br>The QGIS server is really far from be a good WMS Server.<br>
    <br>
    It has not the multy style rendering.<br>
    It has not the "named groups" if don't allow to change the html
    response .<br>
    It don't allow to return a GML response to the user in a
    GetFeatureInfo if don't active the WFS ption.<br>
    This is obviously unacceptable.<br>
    Because there is some layer that a Public Administration cannot put
    in download as they are.<br>
    <br>
    The GeoServer and MapServer are real WMS Server and they allow all
    of this and more other thinks.<br>
    <br>I don't speak of velocity where the coparing is impossible.<br>But alsoin the rendering capable.<br>I guess the Mapserver (the one that I know very well), has monay point of advantage on qgisserver.<br><br>
    The ONLY question good of qgis is The project qgis is the the same
    in the server.<br>
    But this mean only that theĀ  qgis-server is good for fast prototyping, no more.<br><br>When go in production and the users grow the qgis-server will become rapidly a bottle of neck.<br><br>So the investiment need to enhance the qgisserver to have a good and fast , fully complaince and affordable wms server are massive.<br>
This could be ask to a public admiistration to fund.<br><br>But if it is notĀ  a compliant wms server it could not never choose to start.<br><br>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 ?<br>
    :))<br>
    <br>
    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.<br>
    <br>
    Because the laws deny to choose it.<br>
    <br>
    I guess you can also hope to sell your service to someone .<br>
    But if it ask you:<br>
    Hey your software is compliant with OGC WMS ? This is a mandatory
    need for inspire.<br>
    <br>
    You what say to your possible future client ?<br>
    <br>
    Yes (but you say that the real response is NO)<br>
    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.<br><br>As an exmaple:<br>
    We fund really many enhancement in qgis.<br>
    <br>And refund the same think when pass from 1.8 to 2.0.<br>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.<br><br>Now the qgis release every 3-4 month.<br>
These mean that a public administration should plan to refund all thei product on qgis every 3-4 months ?<br><br>
    I guess this is an example clear of what mena affordable and reliability.<br><br>I guess no one public administration could fund an incompatible piece of software to became compatible when there is other solution availables and compatibles.<br>
<br>Returning to the incompatible qustion:<br><br>
    Who put the GetPrint tags in the getcapabilities response ?<br>
    <br>
    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.<br>
    <br>
    I say :<br>
    ok you have your advantage, you have take your money, and now ?<br>
    You have destroyed the credibility of qgis as an WMS Server OGC.<br>
    You choose to eat the egg today instead of take the chicken
    tomorrow, and now ?<br>
    Are you happy of this ?<br>
    <br>
    I guess who break repair.<br>
    So I guess the solution should be put and fund by who involontary or
    volontary (i don't know) break the WMS specs compatibility.<br>
    <br>
    Or otherwise the qgis group say:<br>
    <br>
    we don't care about the wms compatibility so choose other software
    for this work.<br>
    <br>
    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.<br>
    <br>
    It is a really bad <br>
    "ok qgis is not usable for an OGC WMS infrastructure."<br>
    <br>
    If instead it is not happy of this it should repair what has break .<br>
    <br>
    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.<br>
    <br>
    Andrea.<br>
    <br>
    <br>
    <br>
    Il 08/06/2014 07:08, Alex Mandel ha scritto:<br>
    <blockquote type="cite">
      <pre>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:
</pre>
      <blockquote type="cite">
        <pre>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 <a href="mailto:tech_dev@wildintellect.com" target="_blank"><tech_dev@wildintellect.com></a>:
</pre>
        <blockquote type="cite">
          <pre>On 06/07/2014 01:06 PM, Andrea Peri wrote:
</pre>
          <blockquote type="cite">
            <pre>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).
</pre>
          </blockquote>
          <pre>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.


</pre>
          <blockquote type="cite">
            <pre>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.
:)
</pre>
          </blockquote>
          <pre>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.

</pre>
          <blockquote type="cite">
            <pre>I guess surely better and easy is put the new functions in in a distinct
and new kind of request.

</pre>
          </blockquote>
          <pre>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


</pre>
          <blockquote type="cite">
            <pre>Andrea.



2014-06-07 21:56 GMT+02:00 Alex Mandel <a href="mailto:tech_dev@wildintellect.com" target="_blank"><tech_dev@wildintellect.com></a>:

</pre>
            <blockquote type="cite">
              <pre>I just checked the WMS 1.3.0 specification document
<a href="http://portal.opengeospatial.org/files/?artifact_id=14416" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=14416</a>

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:
</pre>
              <blockquote type="cite">
                <pre>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:
</pre>
                <blockquote type="cite">
                  <pre>Hi,
I need to be more clear.
My english is tremendous.
:)

The Interoperability mean to have a small set of operation euals on
</pre>
                </blockquote>
              </blockquote>
              <pre>EVERY
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>Server WMS.

Equals mena same reqeust , same response.

So when a Cleit WMS send a Request of GetCapabilities, The response
</pre>
                </blockquote>
              </blockquote>
              <pre>should
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>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
</pre>
                </blockquote>
              </blockquote>
              <pre>use
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>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
</pre>
                </blockquote>
              </blockquote>
              <pre>mean
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>your response is wrong."

Of course there are some client wms that don0t do a validation of
</pre>
                </blockquote>
              </blockquote>
              <pre>response,
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>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
</pre>
                </blockquote>
              </blockquote>
              <pre>tag".
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>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
</pre>
                </blockquote>
              </blockquote>
              <pre>extract
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>all the information from Capabilities response.
This is a bad practice also because create artiiciosally an
</pre>
                </blockquote>
              </blockquote>
              <pre>incopatibility
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>with other products.
Instead Inspire ask for INteroperability from every product.

Interoperability don't mean use all the same unique product. (This is
</pre>
                </blockquote>
              </blockquote>
              <pre>the
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre>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 <a href="mailto:aperi2007@gmail.com" target="_blank"><aperi2007@gmail.com></a>:

</pre>
                  <blockquote type="cite">
                    <pre>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
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>interoperable
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre>with other product.

As example:

if an public Administration will eed to do a cascading wms with the
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>server
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre>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
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>requested
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre>from Inspire specification.

Regards,



2014-06-07 20:36 GMT+02:00 Alex Mandel <a href="mailto:tech_dev@wildintellect.com" target="_blank"><tech_dev@wildintellect.com></a>:

On 06/07/2014 11:19 AM, Andrea Peri wrote:
</pre>
                    <blockquote type="cite">
                      <blockquote type="cite">
                        <pre>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
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>the
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <blockquote type="cite">
                        <pre>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
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>modifica
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>it
</pre>
                      <blockquote type="cite">
                        <pre>to redirect to a different XSD not in the OGC site.

3) The presence of a Proprietary tag inserted without any reference
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>to
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>any
</pre>
                      <blockquote type="cite">
                        <pre>standard.
The GetPrint.
This is not present in any other product.

My question is for any person of a Public Administration that plan
or
</pre>
                      </blockquote>
                      <pre>are
</pre>
                      <blockquote type="cite">
                        <pre>funding QGIS.

In Europe the Inspire directive will ask to promove the
</pre>
                      </blockquote>
                      <pre>Interoperability.
</pre>
                      <blockquote type="cite">
                        <pre>The interoperability strategy ask that every produc that allow the
</pre>
                      </blockquote>
                      <pre>inspire
</pre>
                      <blockquote type="cite">
                        <pre>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
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>different
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>xsd
</pre>
                      <blockquote type="cite">
                        <pre>that overlap the standard OGC xsd will create the presuppost
(AFAIK)
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>to
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <blockquote type="cite">
                        <pre>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
</pre>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>directive
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <blockquote type="cite">
                        <pre>principles.

Thx,


</pre>
                      </blockquote>
                      <pre>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,
</pre>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>so
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>the target should be easier. I am little puzzled about not allowing
</pre>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>for
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>extra functions that are not in the standard. Unless the WMS has a
</pre>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre>print
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre>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

</pre>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              <pre></pre>
            </blockquote>
            <pre>_______________________________________________
Qgis-user mailing list
<a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>

</pre>
          </blockquote>
          <pre>_______________________________________________
Qgis-user mailing list
<a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>

</pre>
        </blockquote>
      </blockquote>
      <pre></pre>
    </blockquote>
    <br>
  </div>

</div>