Re: [Geotools-devel] uom scale in target device size?

[Ákos M. <ak...@ma...>]

Andrea,

> 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.
it's a very needed extension indeed!
>
> 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).
yes, this is my point exactly. the value should be denoted in a way that
makes it clear how it's meant to be interpreted: is this a simple
scalar? is it a distance of some sort? all-in-all, the question that
needs to be answered: what is the interpretation of the value, and how
doest the (rendering) context affect this interpretation?
>
> 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
while the arguments might be unit-less within the function, their
interpretation is not / cannot be. for example, one cannot define a
'buffer' of a unit-less size, as one cannot generally define a size in a
unit-less manner.
> (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.
IMHO it does :) IMHO the context bounds the invariables in this case. if
I specify a buffer that should be 2mm wide on the target device, then
the parameters for the function call should be converted prior to the
function call, so that the result will be what is expected.

what happens now is not that the function parameters are unit-less, but
that they have the default unit of a pixel.

moreover, for simple expressions, they are actually multiplied by a uom
multiplicator. thus, for functions that return a number, they are
actually changed by this multiplication. but not for other functions.
>
> 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.
interesting. where would I fund the documentation for these? did I miss
something?

my target goal is now achieved with the following expression:

<sld:PolygonSymbolizer uom="http://www.opengeospatial.org/se/units/metre">
    <sld:Geometry>
        <ogc:Function name="difference">
            <ogc:PropertyName>way</ogc:PropertyName>
            <ogc:Function name="buffer">
                <ogc:PropertyName>way</ogc:PropertyName>
                 <ogc:Literal>-1500</ogc:Literal>
            </ogc:Function>
        </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>


which is in effect an area inside the polygon of a certain width. my
problem is that this width is currently always in pixels.

> GeoTools supports _none_ of them, but if you are content with what
> those functions
> offer you could implement them?
I have to admit I'm a bit confused now. the above buffer function is
implemented in org.geotools.filter.function.FilterFunction_buffer - I
figured this would be part of GeoTools
> 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)
I'm a bit confused here - is this statement regarding the functions I
referred to earlier, or the SLD 1.1 functions?
>
> Buffering should not be difficult to implement, doing offset the
> proper way is a real bloodbath instead,
sure - I don't aim to bring on new functionality, I just want to make
what's available to work for me as per my intentions :)


Akos