Hi Matthias - this email has now made it to the top of my "revisit"
stack :-D
> Question 1:
> Do I have the same goals/requirements as the GeoTools team in respect to
> expressions?
>
> A tough question. Yes, and no. With respect to its use for GIS purposes and
> looked at it "from some distance", we have the same goals:
> - allow to specify constant or feature/graphics depending values (e.g. in
> symbolizers)
> - allow feature/geometry/object filtering
>
The I expect to see and did not was:
- interoperability
We want a standard contract between client code (ie style) and server
code (data provider), we cannot do something open ended here as data
providers have different abilities.
> But looking closer, there are considerable differences:
> 1. GeoAPI tries to model the Filter Encoding OGC specs as close as possible
> and GeoTools "just" extends it where necessary to provide some more features.
>
It is true; I must be clear that we did not intend to extend the Filter
specification (we screwed up); as an example all the Filter constructs
really want a PropertyName element followed by an Expression.
Our accident may give you room to play; however that play will not
extend as far as GeoAPI.
> On the other hand, I need an intuitive expression API for my personal work.
> (See point two for more on this.) I am not bound to any spec for my personal
> work, although I take specs as inspiration and try to follow them "whenever
> possible without sacrificing features/ease of use".
>
I am not sure it is your hand we need to worry about; instead you need
to look to data providers (in the form of SFSQL and WFS and shapefile).
I do not think we are looking for an object oriented solution here -
instead we want a declarative solution - am I wrong in this?
> 2. The "old" GeoTools expression APIs were restricted towards use in GIS
> applications. The "new" GeoAPI/GeoTools expression have relaxed this, but
> still I find that their concepts are somewhat geared towards GIS use. (Would
> be interesting if people have experiences with (mis)using them for purposes
> not related to GIS. Looking at the current implementations I find this hard
> to imagine. But I may be wrong.)
> I need an expression API that is generic enough to clearly extend over the
> GIS scope - an API that can be used in projects that might not even have
> something to do with GIS at all. Expressions are everywhere where there are
> searches, selections, filters, mathematical functions and the like! GUIs for
> searches in bibliographic databases are a very neat example.
>
You should look to the catalog specification for an example ...
they define a double hit combo team of Query and QueryLanguage; they
also ship with a CQL as an example (ie. common query lanaguage text
format). The point is they left the door open for additional query
languages such as SFSQL and for "searches", "selections", "filters",
"mathematical functions"...
As long as you know query language is something you want client and
server to negotiate then you can place that into your API. This
"insight" has not made it into the GeoAPI style interface ... and I am
not sure if it is needed/wanted? Yours is the first request.
> 3. Jody described the GeoTools API to be like a scripting language. While
> this is clearly a feature in some places and for some people, my personal
> preference is clearly for a clearly typed API. .... snip ... The GeoAPI
> expressions API cannot currently deliver this.
>
Mattias can we explore an ExpressionBuilder offline ... I think it will
meet both our needs.
> Clearly, the CURRENT GeoAPI expression API can not deliver what I need.
>
I think this is by design; not all data sources have a good concept of
type. Also metadata system and query system is usually a poor trade so
one needs to be careful here.
> Question 2:
> Can the GeoAPI fulfil my requirements after some changes?
>
> To 1. above (Following the spec):
> I tend to have the opinion that implementing a specification in Java language
> does NOT necessary mean to copy classes, names and (important in this
> respect) hierarchies exactly 1:1. I share the opinion, that a specification
> is fulfilled if its requirements are fulfilled by a subset of the
> corresponding Java API and implementations and if these provide the required
> functionality.
+1 Agreed
> People wanting a "strictly conformal" use could simple restrict themselves to
> a subset of the interfaces and implementations. (We could use use tags to
> mark interfaces that exactly follow the specification in order to distinguish
> them from our extensions.)
>
My approach has been to provide a Factory that is exactly limited in the
same way as the specification. I hope you find it is sufficient.
> To 2. above (Generic API for usage outside GIS scope):
> This is a bit tricky to do, but ihmo possible. Specifically:
>
> a) The OGC spec clearly defines some interfaces, some of which should/might
> be extended, others where this does not make much sense. I believe GeoTools
> is free to relax this and allow free implementations and extensions like for
> nearly every "normal" API. If creating a new subinterface makes sense or not
> should be left to the programmer's opinion and to the question if the
> expression, when exported to XML, can be OGC conformal. ("Extend at own
> risk." ;-) )
>
I am not worried about the XML use; I am worried about your contract
with other programmers. They are *only* going to know about the
published GeoAPI interfaces...
Yes GeoTools can publish some extensions (and force their programmers to
make use of those extensions).
But we cannot really leave this door open for you the client programmer
(the API contract does not work in that direction).
We can leave it open for the developer; as a data provider you can
advertise the list of functions that you support.
> b) The OGC doesn't define that org.opengis.filter.expression.Expression
> might not actually be a special case of a more broader expression API. (That
> is:
> org.opengis.filter.expression.Expression
> extends some.other.package.GenericExpression (or whatever...)
>
No it defines it to be an explicit list of Expressions all of which have
been provided. PropertyName, Literal, Function, Add, and so on ...
> In my concept of expressions the "typical" OGC expression - taking a
> feature/graphics or any other bean-like input object - is actually a special
> case of a generic expression that may take any object as input, maybe
> something as simple as an Integer. Note that in GeoTools there is a big
> difference between what you CAN input and what you SHOULD input in order to
> get a reasonable result for. (Example: GeoAPI "PropertyName" theoretically
> allows you to give pass in any Object as input, but nobody would expect it to
> work when passing in a Number, or Color.)
>
> I'd like to make this more explicit, by making, f.e. the OGC "PropertyName" a
> subinterface (within this generic API) that clearly states implementations
> need only cope with objects having attributes. In this context you will
> hopefully understand my ideas about typing in the expression API (See point 3
> below).
>
PropertyName is a little bit of evil. It supports XPath which means that
the PropertyName actually has a query language of its own - all about
taking appart things with attributes. Including colors if that is what
you need to do.
> d) In my concept of expressions they can be classified by what I'd call
> dimensionality analogous to one- and twodimensional functions in math. With
> this I refer to the number of their input arguments. And I do not make any
> distinctions between "input" and "parameters" as the GeoAPI "Function"
> interface does. (There isn't any difference, is there?) This means that the
> OGC "Literal" actally is a zero dimensional expression whereas the OGC
> "PropertyName" is a one dimensional one.
>
There is supposed to be a difference - a difference of "degree of
freedom". You are only using the expression (or filter) against a single
context (object,feature,etc...) at a time in order to produce something
(a value or a set membership test). So your expression is more like a
closure with one binding left ....
You captured the idea well:
- zero - literal
- one - data access or set membership (ie filter )
- two - joins!
We do have some borderline cases with environmental variables (but those
are generally held to be constant for the duration of one filter "run").
Recently joins were taken out of the WFS 1.1 specification just because
these issues were not thought out? What is the "type" of a "join" after all?
> To cut long stories short:
> I believe it would be possible to design a generic expression
> API in which the OGC expression API is merely a subset and has
> a structure that differs slightly from the current one WITHOUT
> losing any of its functionality or OGC conformity!
> (I almost have a proof of concept.)
>
And I am not sure that meets the goals of the GeoAPI project ...
inventing our own thing is not
of interest. Allowing you to invent something; and negotiate a common
query language with a data
provider is of interest. Then we can figure out what query langauges are
actually good; and possible
standardize some ideas for broader use ...
To cut a long story short ... if you make something will Postgres
support it? How about Oracle?
> To 3. above (Typed API):
> GeoTools is still 1.4, but GeoAPI is not! They have shown with the
> Referencing API that typing can be useful to avoid unnecessary casts and
> runtime class cast exceptions. Also, the OGC specifications are not in the
> way either. I cannot remember having read that an expression must be able to
> return a result as any class.
>
> Last but not least I believe that every implementation in GeoTools actually
> knows exactly what it will return. UniqueIntervalFunction always returns an
> Integer (slot number) for example.
> Anything speaking against a typed expression API which I have overlooked?
>
Reality:
- in that you can run a string function on an Integer
- You cannot know the value of a PropertyName expression
Note I am with you on this one - when I made my Expr prototype I defined
Expr.geometry( propertyName ) as a helper method that did a
Expr.property( name ) lookup and assumed the result was a geometry.
> So, specifically what I'd like to see is
> - Every expression has an output type (Expression<O>)
>
See above you are binding your expression lookup with something you
cannot possibly know until runtime. Features by definition are a dynamic
type system.
Even for our FeatureModel work we are probably going to throw out half
the generic use.
> - Every expression can provide this output type and the required input types
> as classes for any non-typed environments (pre Java5)
> e.g. Class<O> getOutputClass();
> Class[] getInputClasses();
>
> Why should I need this? I have an example in my styling widget: There is an
> "expression registry" where all implementations are stored. Lets say, the
> user must create an expression for the line color. I ask the expression
> registry for all expressions that return colors. (E.g. constant color, color
> by mapping from values, color gradients derived from numerical values as in
> elevation maps) and then fetch corresponding UI elements for them.
> This certainly can be done without typing and even without an expression
> knowing its output class, but doing it above way it is cleaner, imho.
>
> ---
> Last but not least...
>
> - Could you please consider renaming the "Add", "Subtract", "Multiply" and
> "Divide" interfaces to something that tells everybody on the first look that
> these things have something to do with expressions. (Sorry, I really dislike
> these names.)
> What about "AddCombinedExpression"? Even "AddExpression" is still better than
> "Add". (This wouldn't influence the XML representation and therefore would
> not influence conformity to OGC, would it?)
>
I like it can you make a Jira?
Jody
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
