I must admit, when I first looked at the WFS spec, I saw you could make
filters like "(attribute_A + Attribute_B) < 25", I just assumed that
you could ask it to return "(attribute_A + Attribute_B)" as a column.
The spec says you're not allowed to do this - which is a real pain since
its *extreamly* powerful.
I'm, therefore, proposing three things:
1. a "virtual DataStore" that wraps around another DataStore and allows
you to run function to produce new columns (much like an SQL SELECT
statement)
2. a "virtual DataStore" that wraps around another DataStore and
provides aggregation ("summary") much like SQL GROUP BY clauses.
3. making the Filter Expression actually useful.
There's a summary here:
http://docs.codehaus.org/display/GEOS/DerivedFeatureType
More info on #1 and #3 here:
http://docs.codehaus.org/display/GEOS/selectDerivedFeatureType
More info on #2 here:
http://docs.codehaus.org/display/GEOS/aggregatederivedfeaturetype
I'm looking for feedback and someone to help me actually implement it,
dave
ps. please excuse me equivocating "DataStore" - I'm still trying to
figure out what all the DataStore-like words actually mean and how they
inter-relate.
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
Hi David,
I'm assuming you are across the complex_sco branch work (since Chris Holmes had a lot of input here)
*) fairly detailed discussion of requirements here (under RnD "Community schemas...)
*) implementation in Geoserver code base that needs migrating to Geotools
This used a sort of "stored procedure" configuration to achieve all this sort of stuff. Certainly it would handle this particular case.
Rob
dblasby@anonymised.com wrote:
I must admit, when I first looked at the WFS spec, I saw you could make
filters like "(attribute_A + Attribute_B) < 25", I just assumed that
you could ask it to return "(attribute_A + Attribute_B)" as a column.
The spec says you're not allowed to do this - which is a real pain since
its *extreamly* powerful.
I'm, therefore, proposing three things:
1. a "virtual DataStore" that wraps around another DataStore and allows
you to run function to produce new columns (much like an SQL SELECT
statement)
2. a "virtual DataStore" that wraps around another DataStore and
provides aggregation ("summary") much like SQL GROUP BY clauses.
3. making the Filter Expression actually useful.
There's a summary here:
http://docs.codehaus.org/display/GEOS/DerivedFeatureType
More info on #1 and #3 here:
http://docs.codehaus.org/display/GEOS/selectDerivedFeatureType
More info on #2 here:
http://docs.codehaus.org/display/GEOS/aggregatederivedfeaturetype
I'm looking for feedback and someone to help me actually implement it,
dave
ps. please excuse me equivocating "DataStore" - I'm still trying to
figure out what all the DataStore-like words actually mean and how they
inter-relate.
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Tue, 8 Mar 2005 18:03:39 -0500, dblasby@anonymised.com
<dblasby@anonymised.com> wrote:
I must admit, when I first looked at the WFS spec, I saw you could make
filters like "(attribute_A + Attribute_B) < 25", I just assumed that
you could ask it to return "(attribute_A + Attribute_B)" as a column.
The spec says you're not allowed to do this - which is a real pain since
its *extreamly* powerful.
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...
I'm, therefore, proposing three things:
1. a "virtual DataStore" that wraps around another DataStore and allows
you to run function to produce new columns (much like an SQL SELECT
statement)
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.)