[Qgis-developer] SLD export not compliant due to unit attribute in the root element

[Andrea Aime]

On Mon, Jul 25, 2016 at 10:04 AM, René-Luc Dhont <rldhont at gmail.com> wrote:

> Hi Andrea,
>
> I'm the author of the commits that add a 'units' attribute to
> StyleLayerDescriptor element.
>
> https://github.com/qgis/QGIS/commit/b54b1598a6ba145a51aa266cde9282ae4d0378ad
>
> https://github.com/qgis/QGIS/commit/f7ce8b94344e7a7dd12fac2a90bd84df30b7e82f
>
> If you look at the code of these 2 commits, I didn't change anything about
> QGIS SLD interpretation. In the QGIS core, a 'units' attribute is used to
> defined the SLD default units for distance.
> But I didn't add this 'units' attribute for QGIS and QGIS Server SLD
> interpretation, I add these 'units' for GeoServer.
>

GeoServer cannot make any use of that attribute, it's not part of the spec,
nor part of the GeoServer own extensions to SLD. It just makes people
wonder why the validation fails, and then
we get tickets on either qgis or geoserver side :-)
Also, unit management is already available, but at the symbolizer level, if
anything, it would make more sense to add a custom uom value in screen mm
that GeoServer would
understand (more on this later, read below).


>
> I didn't used uomScale because of SLD has to be used for any DPI screen.
> So if a QGIS user made style in pixels, he has made the choice to have
> different rendering in different DPI screen. But if the user made style in
> mm on the screen, the stroke or line has to have the same size in different
> DPI screen.
>

This has often no meaning in a server side application, where the imagery
is built without knowing about the user
screen DPI, sometimes in advance of actual usage on a screen (tile caching).
GeoServer has a vendor option in GetMap to specify the DPI, but only custom
built clients use it (strictly standard clients won't), I see
QGis server has the same, but as a vendor option, it cannot be relied upon
in general.
The option to transform to pixels using OGC own standard DPI recommendation
(a value close to 91, in particular, 25.4 / 0.28, see the SLD/SE spec)
allows more software to understand the style file, and then if DPI is part
of the request, qgis/geoserver can adjust the pixel
values on the fly accounting for the difference between standard and actual
DPI.


>
> Can QGIS extend SLD by added it's own schema for defining units attribute ?
>

Errr... in theory yes, but in practice it will likely not work. The
compliant way to do it would be to create your own schema, roll your own
custom element, e.g. QGisStyledLayerDescriptor, put
it in a substitution group with StyledLayerDescriptor, link to it from the
exported styles, and then in such element you can add your own attributes.
However, I don't know if clients would be able to figure this out, I
believe many would just break because they do not recognize it.
GeoServer own parser might even parse it anyways (it's schema driven, so it
might inspect your extended schema before starting the parse if you linked
to it), but it would still not know what to do with the units attribute
anyways.


>
> Can we used a VendorOption, to specify mm on the screen like in GeoServer ?
>
> http://docs.geoserver.org/latest/en/user/styling/sld-extensions/label-obstacles.html
>

VendorOption is one of GeoServer extra tags that are not part of the SLD/SE
schemas (so they are not compliant either).
Check the schemas:
http://schemas.opengis.net/se/1.1.0/Symbolizer.xsd
We normally warn people that the moment they start using vendor extensions,
the SLD cannot be exported out to other software anymore
(some clients will fail to parse, others will just ignore the extra
elements/attributes).

This brings me to a different topic... when you say in the UI "export to
SLD" the export should, imho, strictly be compliant, thus don't use the
VendorOption tag, or other extensions, or non
compliant mark names, and the like... it should be a best effort export
that ensures compatibility with whatever other software.

I would instead favor adding another export option, "export to GeoServer
SLD", in which the code would add VendorOption and know what specific
options GeoServer supports.
I see that QGis is already using VendorOption in some places, but with
values GeoServer does not understand... wondering, what would be the
software
that understands those extras? I am thinking maybe they have been added to
allow a "export and re-import in QGis" round trip, making them
a "export to QGis SLD" option?


>
>
> About uom in Symbolizer, I think QGIS has to add it like GeoServer
> http://docs.geoserver.org/latest/en/user/styling/sld-extensions/uom.html#example
>

uom is a standard attribute in SE 1.1, but GeoServer also allows its usage
in SLD 1.0, making it a vendor extension in that context.
When used in SE 1.1 GeoServer should understand it normally (within the
limits of the standard units, pixel, meter, feet, I'm open to
extend that list to include on screen mm within the context of a GeoServer
targeted SLD export).

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160725/640b3257/attachment.html>