Matthias Basler wrote: > 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. > Right; so now back to reality - GeoTools is in the same boat as you - and there is a mechanism you can use to go beyond the specifications. Quickly .... GeoAPI (the specification) has PropertyName .... GeoTools has PropertyName2 with some additional/optional/extra information that we want.
You can see this in action when looking at the Style APIs, we did this to put a graphic behind the text. I am not sure if the idea appeals to you or not - or is in alignment with what you did. > 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. > That is next on our list to update; we have not put it on a road map for lack of volunteers. I can help you put together a change proposal however :-) The plan involves stripping out the GeoTools interfaces and using the GeoAPI ones directly.... > 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). > yes. > 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. > We can fix it for GeoTools 2.4 if you want to help with a proposal and time. > 2. What is the roadmap to get the whole styling API use GeoAPI > expressions? > RIght. 1. collapse GeoAPI style interfaces into one (we can do that now since Expression works for object; they had one style for graphic and another for feature) 2. make our interfaces extend the GeoAPI ones; we can leave some extra methods there in deprecated form for a bit. 3. run through the code base and force GeoTools to only use the GeoAPI style interfaces 4. release > 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. > It should be mentioned in the GTSteering document; cory has had this as a "interest" for about a year. > 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). > You can use a FilterVisitor to traverse the tree structure of the expression; making note of any PropertyName elements you see. > 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. > If you are making a ui (for the user to choose the propertyName) you need to look at the metadata (FeatureType for a Feature etc...). If you just want to list what is used in a provided expression you can use the FilterVisitor as mentioned above. > - 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? > So this is the filter implementation (ie what the FilterFactory gives you) - in GeoTools the implementation that does the work (say propery access) may be provided by another extension point ... but the details are not interesting for client code like cbrewer. What you describe is the "trinity of data design" Data - your instnaces (of Feature or Objects) Metadata (or Description)- where you find out what propertyNames area available (FeatureTypes or Classes) Query - what Filter does Any time they get mixed up we have a problem. All the best; Jody ------------------------------------------------------------------------- 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
