On Wed, Jan 2, 2013 at 4:18 PM, Ákos Maróy <[email protected]> wrote:
> Andrea,
>
> Another issue came up with uoms, and this is also not specific to
> device-size uoms, but with any uom already defined earlier. This is the
> case of expressions, or rather, when using constants in expressions.
>
> Consider for example the following:
>
> <sld:PolygonSymbolizer uom="
> http://www.opengeospatial.org/se/units/metre";>
> <sld:Geometry>
> <ogc:Function name="buffer">
> <ogc:PropertyName>way</ogc:PropertyName>
> <ogc:Literal>300</ogc:Literal>
> </ogc:Function>
> </sld:Geometry>
> <sld:Fill>
> <sld:CssParameter name="fill">#FF0000</sld:CssParameter>
> <sld:CssParameter name="fill-opacity">0.4</sld:CssParameter>
> </sld:Fill>
> </sld:PolygonSymbolizer>
>
>
This one is a geometry transformation, which is a GeoTools specific
extension
allowing to call any expression in the Geometry tag, instead of being
restricted
to a ogc:PropertyName like the SLD standard demands.
In particular you can call functions. Functions are pretty opaque, there is
no
way to automatically tell what the function is meant to do, and what
a certain argument will do (is that 300 a distance, or a multiplier, or
the number of times an iterative algorithm has to be repeated, or the value
or a new attribute , or... you get the idea).
For this reason, and for the very meaning of the Geometry tag, functions are
operating onto the geometry in its native SRS, and their arguments are
unit-less
(the function does not get to know what the Geometry srs and unit of
measures
are, either), so your question just does not make sense.
Now, SE 1.1 supports a very limited number of well known transformations
that work
in the declared unit instead, they allow to do line offsets, polygon
buffers and the like.
GeoTools supports _none_ of them, but if you are content with what those
functions
offer you could implement them?
The reason why those work is that:
- they are well know, so it's also known the meaning of their arguments
- they are specified separately from the Geometry, so they are not bound to
work
in the geometry native SRS (they do work either on the rendering SRS, or
in pixel
space, instead, depending on the chosen unit)
Buffering should not be difficult to implement, doing offset the proper way
is a real bloodbath instead,
see here: http://jira.codehaus.org/browse/GEOT-3912
(there is a pull request for a implementation that's unfortunately broken,
as such it has
not been merged).
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
-------------------------------------------------------
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
