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

[Alessandro Pasotti]

On Mon, Jul 25, 2016 at 10:41 AM, Andrea Aime <andrea.aime at geo-solutions.it>
wrote:

> 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.
>


I'd add that in a web context pixels are now treated as Device Independent
Pixels, i.e. if you set a px value in a CSS you won't get it mapped to the
real pixel size but to a device dependent physical value, that makes
perfectly sense in the HiDPI screens age.

I agree that  the best option would be to convert the mm to px by using the
OGC recommended DPI conversion factor.


>
>>
>> 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?
>


This would be an option. But I still miss the point why that is needed:
René will probably have an answer to this question.



>
>
>>
>>
>> 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
>
>

-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160726/cdcb031d/attachment-0001.html>