On Mon, Jul 25, 2016 at 10:41 AM, Andrea Aime <[email protected]> wrote:
> On Mon, Jul 25, 2016 at 10:04 AM, René-Luc Dhont <[email protected]> > 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
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
