Hi,
so, I'd like to push a little further on geometry transformations
by adding one that can work against the geometry expressed in
pixels. Pixels, not meters. Let me explain why, and then try to
offers ways to dodge the problem.
When we apply a transformation against a geometry we blindly
make the geometry go though a filter function.
The function takes a geometry as a paramter, and then some
other params. The other params could be anything, they could
be strings, dates, or numbers. And those numbers could
mean anything, could be a distance, but also a way to encode
an enumeration, or a reference to the n-th point or ring
in the geometry.
So in the end we can control in what unit of measure the geometry
getting in is, but we have no control over the params of the
function.
If we depict la/lon as is, we have a choice of the geometry
in lat/lon (used in the existing transformation) and in pixels
(ready to be rendered).
If we reproject, we have a choice of lat/lon, meters, and pixels.
But there is no guarantee we can have the meters version, the
only ones that are guaranteed to be there are the original unit,
and pixels.
To perform the transformation in pixels I was thinking of introducing
a new element in the symbolizers:
<renderedGeometry>
<ogc:Function name="offset">
<ogc:PropertyName>renderedGeometry</ogc:PropertyName>
<ogc:Literal>2</ogc:Literal>
</ogc:Function>
</renderedGeometry>
Where "renderedGeometry" is a fake property we allow the function
to use and that would contain the geometry expressed in pixel space.
The above would offset the geometry by 2 pixels.
In the end no UOM setting would affect these transformation,
as the one we have now works against the original geometry, and this
new one would work against pixels.
As a workaround we could have the new one work against the uom.
But at that point we need to identify which parameters of the
function are distances.
That is possible only if the function helps us and implements
some interface telling us which arguments are measures, once
we have that we can transform the arguments before passing them
(uom rescaling them).
I guess we could extent GeometryTransformation and add a
boolean isDistance(int index)
method that would tell us if a certain argument is a distance
to be transformed (this would be an API break, yes, at the same
time I'd be quite surprised if anyone actually implemented
a geometry transformation up to date).
Opinions?
Cheers
Andrea (who is about to turn back into a pumpkin...)
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
