James, thanks for your replies;
That is true and it is a major limitation, though it is worth noting
that SLD allows you to use expressions so you can style features based
on expressions but there are many times when the ability to do the
calculation in advance or even to just rename an attribute, would be
handy. And, of course, there are all the analysis tasks that have
nothing to do with styling...
Unfortunately, the SLD does not allow you to run functions on Geometries
(the <geometry> tag only allows an <ogc:PropertyName>).
I'm just trying to buffer and union my polygons (see the pictures on the
first page of the wiki I sent) so I can do nice WMS (or WFS) in
Geoserver. And its neigh impossible under the OGC spec. You'd have
thought that this type of thing would be easy, but...
I think the expression stuff should be easy to add to Filter (if you
allow the <geometry> property to be an <expression> instead of a
<PropertyName>).
No one's made any comments on the Aggregation ("summary/group by")
virtual datastore.
I've used spatial databases a lot - perhaps I'm asking too much. I'd
love to be able to treat any of the datastores as a spatial database -
being able to send more complex queries to the store than just a dumbed
down row Filter. Unfortunately, thats much too much work.
I wanted to just change the JDBC datastore so it can point to views (its
already done, just not fully tested because it has FID issues) - then I
can just use Spatial DB in a Box (or whatever) to run "real" queries
against a dataset. But, I wanted to extend the functionality to people
who didnt have a spatial database (ie. people with shapefiles) - hence
the two types of virtual datastores.
Alternatively (jody likes this evil plan), I was considering just
providing functionality to "move" a shapefile (or whatever datastore)
to an imbedded spatial database (HSQLDB - which I've already
spatialized).
http://docs.codehaus.org/display/GEOS/Hsql+Bindings
How hard would it be to extend this so that he virtual DataStore
wrapped multiple DataStores? One of the other major limitations - to
my mind at least - with the current filter spec is that there is no
way to perform filters or expressions on multiple datasets. i.e. I
can do a dwithin operation on a specific hard coded point but I can't
to things like... all the points in DataStore A that are within
<expression> distance of lines in DataStore B. (Actualy, to my
knowledge thers is no way to do that even within a single GML file
that contains both the lines and the points but I could be wrong.)
The OGC Filter is pretty weak in terms of raw expressive power - but it
does allow you to do quite a bit.
I do mention, at the bottom of the summary page, a few thoughts on
joining two datasets together. Jody's done more thinking on this than
I.
The filter spec allows for user functions to be added. This can be
used as a mechanism for supporting simple classification.
Code to support this has already been writen for GeoVISTA studio, this
task will port that code to GeoTools.
How does GeoVISTA implement this and how does it compare to my
suggestion in the "OGC/Geotools Filter and Functions" section of
http://docs.codehaus.org/display/GEOS/selectDerivedFeatureType ?
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/