Jody Garnett ha scritto:
>>> By my reading, the UomRescalingVisitor doesn't handle this
>>> option. (And it seems like fully supporting this via a visitor
>>> will be a problem; with weird enough filter functions in a
>>> parameter the "px" suffix might appear and disappear for
>>> different features in the same symbolizer.)
>>>
>>> In either case, I won't be able to faithfully represent styles
>>> like this one (hopefully pretty rare, but quite naturally encoded
>>> in CSS):
>>>
>>> * { stroke-width: 2m; stroke-dashoffset: 2ft; }
>>>
>>> but it would be nice to at least be able to mix in pixel values
>>> with real-world measures. Anyone care to point out how I misread
>>> the visitor code? I'm crossing my fingers.
>> You did not misread the code, it has been designed to support just
>> the uom at the symbolizer level. In GeoTools we lack the very
>> support for representing an uom attached to each stroke width, size
>> and whatnot, so adding support for what you're saying might require
>> major changes around in the code...
>
> Let me think about that.
>
> Could we actually use Measure<Distance> and define Converters for
> "1", 1, and "1px","1m",1km".
>
> We would rely on the Symbolizer data structure storing things as a
> literal expression; and try and evaluate as a Measure.class rather
> then just an Integer.class or Double.class as is done now.
Eh, it might get tricky as we have two sources of uom specification,
the literal itself, but also the symbolizer one. I guess the local
one would win.
Anyone interested in cooking up a patch?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
