Dear Andrea,
Picking up this thread again, I've made a pre-parser for SLD, that in
effect translates all the various UOM sizes into pixels into an SLD.
While this demonstrates what I want to achieve, I don't consider this to
be a 'good' solution, as by now I'm actually generating SLDs, not
writing them.
To jump right in the middle, consider this source file:
http://code.google.com/p/openaviationmap/source/browse/trunk/oam-java-tools/var/proba.sldt
and consider this resulting file:
http://code.google.com/p/openaviationmap/source/browse/trunk/oam-java-tools/var/proba-125000_250000_500000_1000000.sld
as you can see, what the code does is that it parses the file looking
for numerics that are denoted in various units of measurement (in, 'mm',
'inch', 'nm', 'm' and 'ft'). the code then scales these sizes into
pixels against various map scaling values, DPI values, and even into
CRS-based distances (more on this later). the result is an SLD file
which has a number of segments with different scale denominators, where
all the values are properly scaled to pixels for each specific scale.
the code that does all this can be found here:
http://code.google.com/p/openaviationmap/source/browse/#svn%2Ftrunk%2Foam-java-tools%2Fsrc%2Fmain%2Fjava%2Fhu%2Ftyrell%2Fopenaviationmap%2Frendering
for more elaborate template / result pairs, see:
http://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam_airspaces.sldt
http://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam_airspaces.sld
http://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam_navaids.sldt
http://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam_navaids.sld
for a resulting rendering, see:
http://openaviationmap.tyrell.hu/oam_airspaces.html
http://openaviationmap.tyrell.hu/oam_airspaces_satellite.html
as you zoom in, you will notice that the width of the lines, the
buffers, etc. all have the same size on each zoom level.
my ideal solution would be to have the same functionality within
GeoServer. I wonder how the GeoServer community would accept such a
change in SLD parsing / processing.
this change would basically replicate the above pre-processing code, by:
* parsing each numeric value for values denoted in specific UOMs, that
is, values like:
o 4mm
o 3000m
o 500ft
o 10nm
o 0.5in
* taking context information into account, converting these into
pixels. context info would be like:
o actual map scale
o target device DPI
o CRS
o approximate position in the active CRS
most of this is quite trivial. the most challenging part is to convert
values within <ogc:Function> elements into pixels, like for buffers. you
pointed out that these values are 'unitless', whereas I've found that
they are in effect values interpreted within the active CRS. for
example, a 'buffer' defined with a value of 1000 is intepreted to be a
buffer of '1000 units in the current CRS'. to make sense of this, and
related this value to any meaningful length value, one has to do some
conversions taking the CRS value, and the appropriate location of the
constructs into account. see the distanceInCrs() function here:
http://code.google.com/p/openaviationmap/source/browse/trunk/oam-java-tools/src/main/java/hu/tyrell/openaviationmap/rendering/UOM.java#205
this approach also has the advantage that one can mix different unit of
measurement in a single rule, as he sees fit, whereas the current
approach of having an 'uom=...' attribute does not allow for this to be
done.
all in all, I seem to have achieved what I wanted with this
pre-processor utlity. my only issue really is that I'd rather have SLDs
as the primary source of rendering - whereas now I'm editing an SLD
template file that I have to send through a pre-processor to make it
work. thus, the SLD as a language cannot describe my intentions anymore.
Akos
------------------------------------------------------------------------------
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
