Hi,
SE 1.1 has this interesting idea about supporting uom in
symbolizers,quoting verbatim from
the spec:
------------------------------------------------------------------------------------------------------------------------
All Symbolizers include an optional gml:uom-attribute as used by GML (this
is set
inside the abstract SymbolizerType and therefore inherited by all
Symbolizers). This
applies to all elements included inside a Symbolizer such as stroke-width,
Size, font-
size, Gap, InitialGap, Displacement and PerpendicularOffset. If no uom is
set inside
of Symbolizer, all units are measured in pixel, the behaviour used by SLD
1.0.0.
The following uom definitions are recommended to be used:
<PolygonSymbolizer uom="http://www.opengeospatial.org/se/units/metre"/>
<PolygonSymbolizer uom="http://www.opengeospatial.org/se/units/foot"/>
<PolygonSymbolizer uom="http://www.opengeospatial.org/se/units/pixel"/>
Pixel is interpreted as a paper unit, referring to the size of the map,
while metre, foot and
other similar units are “ground” units referring to the actual size of
real-world objects. All
values set inside this Symbolizer shall use this unit for drawing the
corresponding
elements. It is also possible to use pixel values inside a Symbolizer that
uses a uom: px
has to be appended to the corresponding values in this case (e.g. 5px
stands for 5 pixel)
-------------------------------------------------------------------------------------------------------------------------
That is, you can specify meters as the uom, and then you can add px to a
measure
to specify it's meant to be pixels. However the override is available only
for pixels,
which is a bit weird.
How about we implement this override support to be SE 1.1 compliant in this
respect,
but allow people to also add m and ft to override the unit to be meters and
feet respectively?
Of course, these would be vendor extensions, but given they are just more
relaxed
interpretation compared to the standard, I would not move them to
VendorOption tags
(also because, well, one would have a hard time specifying the uom for the
various
possible properties).
Some properties would be rather "fun", think of dasharray, it could end up
looking like:
2m 3px 10ft 1m
The possible alternatives could be to search the uom in the first or last
number, which
would help in the common case where the dasharray is all expressed in one
unit:
2m 3 10 1
or
2 3 10 1m
Opinions?
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
