Hi GeoTools community, hi Jody.
Thanks a lot for your clarification, Jody. I wasn't happy with all answers got,
but this is another story and shall be told another time. But I think I got the
idea of what the GeoAPI/GeoTools expressions APIs are up to.
I should note that I started my own, more generic, expression API to overcome
what are (in my personal opinion) the limitations of the OGC/GeoAPI expression
design. (The OGC/GeoAPI expressions are a subset within it.) I needed to do
this in order to get my widget working the way I wanted, which was my #1
priority.
Now I started creating the interface to GeoTools in order to pass symbolizers
back and forth with GT, but got bogged down discovering that symbolizers in
GeoTools 2.3 reference the deprecated expression API. I'm not sure how to
proceed.
To cut a long story short:
As far as I can see the only existing styling implementation in GeoTools 2.3
uses deprecated Expressions (org.geotools.filter.Expressions).
1. Does this means I have to adapt to a deprecated API in order
to create GeoTools styles. Not nice for an official release
like GeoTools 2.3.
2. What is the roadmap to get the whole styling API use GeoAPI
expressions?
3. I had a look at the GeoTools RnD page but couln't find a hint
about GeoTools intending to switch to the GeoAPI SLD interfaces
altogether. What's the roadmap for this? I'm not pressing on
this, I am just curious.
My second question is this: As Jody more or less confirmed to me, the
GeoAPI/GeoTools expressions work on features or other objects that have
properties. They might take none (in case of iterals), one or several of the
input object's properties into account to calculate their output. Lets say, a
"Stroke" object returns such expression when asked for the "line width". What
is the standard way to find out on which attribute(s) this line width
expression depends on (in order to show this information in the styling
widget's GUI).
The point is that I need to "split up" this expression into two parts:
- Step 1: the logic that knows the attributes of the input object
from which to derive the input values for the calculation /
classification / whatever.
- Step 2: the logic to calculate the output value from the inputs
derived by step 1.
... because this is the way my widget will work and the way the user usually
thinks (The UDig ColorBrewer UI is a fine example.) Now, does or could GeoTools
support this design?
--
Matthias Basler
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
