Good timing; Justin just poked a hole in our Filter/Expression API :-( Matthias Basler wrote: > Anyway, I thought it a good idea to look at OGC/GeoAPI/Geotools for their > style and expression API ... and was hit by a lot of things that I simply > don't understand > Heh - let me start by saying that the OGC Filter specification *specifically* defines what an Expression is (and the set of constructs is defined, with <Function> as the *only* for expansion).
So the implementation you see should be identical to the OGC definition; and you will find lots of function implementations where people (usually David Blasby) wanted to do real work. > 1. What is an expression? > > My idea of an expression is more or less equal to what is defined on > Wikipedia: > http://en.wikipedia.org/wiki/Expression_%28programming%29 > and > http://en.wikipedia.org/wiki/Expression_%28mathematics%29 > That is, it is a generic object returning a result. (Can be a > constant(literal), a mathematical function, or the result might be depending > on another object or on its attributes. Note that there's nothing geospatial > about this definition at all! > That is close; for Expression it is often taken to be "evaulated" in the context of "something" (the thing being filtered). The "something" is where the <PropertyName> values come from. > Reading the OGC Symbology Encoding v1.1 (05-077r4) document I find this > mostly confirmed (e.g. page 17 for line stroke parameters). They use the > "ParameterValueType" which in turn uses "ogc:expression"s. > > On the other hand OGC Filter Encoding v1.1 (04-095) defines on page 15: > "An expression is a combination of one or more symbols that > evaluate to single boolean value of true or false." > I plainly don't understand this definition! :-( > That is because it seems out of whack; that definition should be for "Filter". We can send email to get this corrected. The reason for the confusion is that for the Filter specification they really *do* try and come up with true/false at the end (as the value for the "filter"). A normal OGC filter goes something like this: OGC Filter: PropertyName EQUALS Expression In GeoTools we like to be a little more forgiving (but we are *wrong*): GeoTools Filter: Expression EQUALS Expression > Still, from the text below, compared to the subinterfaces of > org.opengis.filter.expression.Expression, I gather that they are ment to > represent the same thing. > > Now I looked at the GeoAPI and GeoTools interfaces I found in my workspace: > - geoapi-2.1-M2.jar: org.opengis.filter.expression.Expression > - geoapi-2.0-tiger.jar: org.opengis.filter.expression.Expression > - gt2-api-2.3.0.jar: org.geotools.filter.Expression (Deprecated) > > The GeoTools Expression interface was obviously geared too much towards > Features: > Object getValue(Feature feature); > The very same applies to the old(?!) geoapi-2.0 interface. > This has been fixed ... as you noted ... in geoapi-2.1-M2 > This basically leaves me with the pending geoapi-2.1-M2, whose Expression > interface has following signature: > Object evaluate(Object object); > <T> T evaluate(Object object, Class<T> context) > Object accept(ExpressionVisitor visitor, Object extraData) > > I admit the visitor design patter is the only one I have never understood - > and I never understood why I would ever need something like that. And again, > why does an expression need visitors? > We can ignore visitor for now (that is only there to make your life easier - it has nothing to do with the idea of a Filter). A visitor is used to "traverse" the three formed by the Expressions: example: Expression1 ADD Expression2 tree: Expression1 > ADD Expression2 Because it is a *pain* to write code to navigate between the "nodes" Expression1, ADD and Expression2 the Design Pattern Police took the navigation code out and implemented it once. This idea of seperating out the "tree navigation code" from the "work" is the Visitor Pattern. > If I imagine a typical expression that takes a Feature as input and > calculates a number from, lets say, the feature attribute "population", then > I wouln't need to visit anything for this. > Yes; but the poor guy implementing "evaulate" really would like to see that visitor. Also people end up manipulating the Filters (search and replace style) using visitors. But you are correct visitor has nothing to do with what a Filter is. > 2. What is a function? > > There's also Function, extending this Expression interface with: > String getName() > void setName(String name) > List<Expression> getParameters() > void setParameters(List<Expression> parameters) > > Anyway, here my personal understanding is different from yours obviously. I > would't care in the interface about parameter setting/getting and leave this > to the implementations. Consider the OGC Filter spec here; or even just SQL: cosine( theta ) you have a name "cosine" and a parameter "theta". We just need to be able to store this information in the "Function" object. > But for me functions have something to do with math, hence I would expect a > signature like this one: > Number evaluate(Object object); > Obviously, I should apply the programming definition of a "function" ... yes > this fits better than the mathematical definition. It even explains why a > function could have a name (but not why an expression doesn't need one). > You lost me; we are talking the same thing here. The Function interface captures a "dynamic" system in which the available functions are defined by data structures (not java code). Indeed the Function interface is capturing what a user wants to say (there may not even be an implementation). > This leaves the question of the difference between an expression and a > function. Can someone explain this in an understandable way? To me it looks > like the only difference is that the expression just requires one object to > get the result, the function needs an object and one or several parameters. > A Function *is* an Expression. Please note that there is never an *Expression*; only a subclass of expression - and the specific subclasses are absolutely defined: - Literal - ADD - SUB - MUL - DIV - FUNCTION - PropertyName And that is it. No more. You can not implement your own Expression! Sure it is an interface but it is *closed* only the subclasses defined above are allowed. You can make up your own functions if you need more functionality. > Hmm ... beat me, but is the difference between the "input object" and > "parameters"??? I don't see one, except if you require that the input object > is to be a featue always. > Couldn't we just define expression like this: > Object evaluate(Object[] parameters); > int getNumParameters(); > > Oh, and I'd prefer it type save (Java5), so what about: > interface Expression<O extends Object>{ > Class<? extends O> getOutputClass(); > O evaluate(Object[] parameters); > int getNumParameters(); > } > Sorry you cannot do that (first of all you are never implementing one of these things) and secondly Expression is "non typed" "1" ADD "2" is 3 1.1 ADD "1" is 1.1 1 ADD 1.1 is 1.1 etc... For more information please see the Expression Improvements page (for the 2.4.x) as we started bringing our GeoTools implementation inline with the specification. > Beside this I do not see any relationship in interface signature between the > GeoAPI "Function" and the definition of "Symbology Encoding Functions" in OGC > Symbology Encoding v1.1 (05-077r4) pp. 37ff. Somehow this OGC spec makes > sense to me, but the (in my opinion corresponding) GeoAPI interfaces don't. > Guess I am mistaken in their meaning. > (I don't have time to follow the links right now) > 3. Binary expressions? > > Also confusing are the binary expressions: Obviously they combine two > expression's results to return a combined one. Things like "Add" or > "Multiply" just make sense with numbers, but I cannot see any type safety > preventing you from trying to multiply a String with a color. ;-) > Indeed you should not; this is not a type safe language (it is almost anti type). Think of this as a scripting language like Groovy or something in which you are allowed to do almost nothing. > 4. Status of GeoTools > > When I look at Classes such as f.e. > "org.geotools.filter.function.math.FilterFunction_cos" I find that they > theoretically implement the new GeoAPI interface, but more or less can only > cope with features. (Otherwise they always return a new empty object. See > class DefaultExpression.) > I doubt such implementations are suitable for building generic expressions > like I would like to do. > So my lask question is: Are the geotools expression implementations by > definition limited to taking a feature as input object for "evaluate" or is > this just a historical thing, and they will be updated later? > Are you working on trunk? Trunk has worked on POJOs in the past; and needs to work on GeoTools Feature, GeoAPI Feature, Metadata, and so on ... > Sigh. I will have a look at uDig tomorrow. They manage to build SLD styles in > the color brewer style page, so I hope to find some answers about expressions > there. I guess I should go to bed now and sleep things over. > > P.S. If you got confused by reading my mail, feel free to ignore it. :-) > Cheers, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
