<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 25, 2016 at 10:41 AM, Andrea Aime <span dir="ltr"><<a href="mailto:andrea.aime@geo-solutions.it" target="_blank">andrea.aime@geo-solutions.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jul 25, 2016 at 10:04 AM, René-Luc Dhont <span dir="ltr"><<a href="mailto:rldhont@gmail.com" target="_blank">rldhont@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Andrea,<br>
<br>
I'm the author of the commits that add a 'units' attribute to
StyleLayerDescriptor element.<br>
<a href="https://github.com/qgis/QGIS/commit/b54b1598a6ba145a51aa266cde9282ae4d0378ad" target="_blank">https://github.com/qgis/QGIS/commit/b54b1598a6ba145a51aa266cde9282ae4d0378ad</a><br>
<a href="https://github.com/qgis/QGIS/commit/f7ce8b94344e7a7dd12fac2a90bd84df30b7e82f" target="_blank">https://github.com/qgis/QGIS/commit/f7ce8b94344e7a7dd12fac2a90bd84df30b7e82f</a><br>
<br>
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.<br>
But I didn't add this 'units' attribute for QGIS and QGIS Server SLD
interpretation, I add these 'units' for GeoServer.<br></div></blockquote><div><br></div></span><div>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 </div><div>we get tickets on either qgis or geoserver side :-)</div><div>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</div><div>understand (more on this later, read below).</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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.<br></div></blockquote><div><br></div></span><div>This has often no meaning in a server side application, where the imagery is built without knowing about the user</div><div>screen DPI, sometimes in advance of actual usage on a screen (tile caching).</div><div>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</div><div>QGis server has the same, but as a vendor option, it cannot be relied upon in general.</div><div>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)</div><div>allows more software to understand the style file, and then if DPI is part of the request, qgis/geoserver can adjust the pixel</div><div>values on the fly accounting for the difference between standard and actual DPI.</div></div></div></div></blockquote><div><br><br></div><div>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.<br><br></div><div>I agree that the best option would be to convert the mm to px by using the OGC recommended DPI conversion factor.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Can QGIS extend SLD by added it's own schema for defining units
attribute ?<br></div></blockquote><div><br></div></span><div>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</div><div>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.</div><div>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.<br></div><div>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</div><div>to it), but it would still not know what to do with the units attribute anyways.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Can we used a VendorOption, to specify mm on the screen like in
GeoServer ?<br>
<a href="http://docs.geoserver.org/latest/en/user/styling/sld-extensions/label-obstacles.html" target="_blank">http://docs.geoserver.org/latest/en/user/styling/sld-extensions/label-obstacles.html</a></div></blockquote><div><br></div></span><div>VendorOption is one of GeoServer extra tags that are not part of the SLD/SE schemas (so they are not compliant either).</div><div>Check the schemas:</div><div><a href="http://schemas.opengis.net/se/1.1.0/Symbolizer.xsd" target="_blank">http://schemas.opengis.net/se/1.1.0/Symbolizer.xsd</a></div><div>We normally warn people that the moment they start using vendor extensions, the SLD cannot be exported out to other software anymore</div><div>(some clients will fail to parse, others will just ignore the extra elements/attributes).</div><div><br></div><div>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</div><div>compliant mark names, and the like... it should be a best effort export that ensures compatibility with whatever other software.</div><div><br></div><div>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.</div><div>I see that QGis is already using VendorOption in some places, but with values GeoServer does not understand... wondering, what would be the software</div><div>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</div><div>a "export to QGis SLD" option?</div></div></div></div></blockquote><div><br><br></div><div>This would be an option. But I still miss the point why that is needed: René will probably have an answer to this question.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
About uom in Symbolizer, I think QGIS has to add it like GeoServer
<a href="http://docs.geoserver.org/latest/en/user/styling/sld-extensions/uom.html#example" target="_blank">http://docs.geoserver.org/latest/en/user/styling/sld-extensions/uom.html#example</a></div></blockquote><div><br></div></span><div>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.</div><div>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</div><div>extend that list to include on screen mm within the context of a GeoServer targeted SLD export).</div><div><br></div><div>Cheers</div><span class="HOEnZb"><font color="#888888"><div>Andrea</div><div><br></div></font></span></div><span class="">-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><div>==</div><div>GeoServer Professional Services from the experts! Visit</div><div><a href="http://goo.gl/it488V" target="_blank">http://goo.gl/it488V</a> for more information.</div><div><span style="font-size:12.8px">==</span><br></div></div><div><br></div></div><div>Ing. Andrea Aime <br></div><div>@geowolf</div><div>Technical Lead</div><br></div></div></div></div></div></div></div></div></div></div></span></div></div></blockquote></div><br><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></div>