On the Xpath front...
fully implementing xpath seems an unecessary burden, but partial
implementation has its issues.
The OGC allows xpath in the Filter specification, stating
"In order to handle property references in a consistent manner, a filter
expression processor must use the subset of XPath [10] expressions
defined in this document for referencing simple properties and the
properties and sub-properties of objects with complex or aggregate
non-geometric properties or properties encoded as XML attributes."
It seems reasonable IMHO to implement this subset.
The other thing is whether there are optimisations possible to minimise
the repeated run-time dereferencing - if you invoke an xpath expression
once, its likely you are going to do if for every feature. If you knew
the xpath before feature instantiation (as per responding to a filter
request) you could possibly promote the accessor rather than traverse
the model each time. Maybe traversing the xpath isnt so expensive - but
if we're worried about the difference between getting a descriptor and
getting a value we might need to explore this.
Rob A
Jody Garnett wrote:
Andrea Aime wrote:
Hum, in fact some datastores are creating JTS geometries and putting
the CRS in the userData field. Sort of a hacky convention, I agree.
Unless we get out an start using a ReferencedGeometry that makes it
explicit (same as we did for Geometry).
I always thought of GeometryAttribute as the same kind of thing as
ReferencedGeometry, it is a wrapper that provides
the "extra" information JTS is not interested in keeping for us.
Oh, since we established that we cannot use List<xxx> in the API,
why is it get(Name) returning a List<Property>? Is there any magic
xml rule stating that if you access by name order becomes
suddendly important?
As with you I am unhappy with List vs Collection, you are correct it
should be Collection<Property>.
Name is fixed (it would be LocalName/GenericName if that interface
was useful); the xpath stuff wrecked everyones happy last time -
xpath can be done by a static utility method treating Feature as a
nice data structure. Only way to see
it happen IMHO.
Hem, I really lost you here. From one side it seems GeoTools code
implies, in various part, that xpath should be used to access properties
(I kind of remember something in the filter API does).
Yes the GeoTools api actually documents that as behaviour (because we
thought it would be nice for end users).
Problem was nobody managed to implemented this (because xpath is so hard
to implement propertly). Putting
xpath in the Feature.getAttribute( xpath ) was viewed as a mistake (just
like with FeatureCollection if we ask for
too much we do not end up successful - and clients do not know what they
can actually do).
And the you tell me this feature model does not really allow the usage
of xpath, but it's limited to something simpler. Why so?
For GeoAPI feature we changed our approach - by focusing only on
providing a complete data model we are
sure to capture the applicaiton information as needed. Support for
things like xpath can be provided externally
(as long as the data model is complete).
Review for others: In GeoTools we never managed to support getAttribute(
xpath ), we only later made a PropertyName
expression that was smart enough to handle xpath and the implementation
made a series of calls to Feature.getAttribute( name ).
If we error on the "super powerful, super flexibile" side, why not
follow this fully? The only performance sensitive part of the api
is simple feature anyways, so why not be as "powerful" as xml in
property access too?
Because I want to be successful; xpath support is hard - and it can be
done external to this data model. If you see
anything else "hard" let me know.
Other things that were *cut* in the same manner are:
- figuring out what attributes are needed for a feature (ie wandering
through all the super types and building a list, applying override logic
and so on)
- figuring out what constraints are on a value (ie wanding through all
the super types and gathering up a filter)
The reasoning is the same; limit ourselves to the data model and leave
it up to utility methods) to cope with the
complexity.
It is worth pointing out that the EMF EClass construct has a split in
this regard; they have one method to access the
data model (ie the properties defined for THIS EClass) and another
method to access *all* of the properties (THIS EClass and all its parenets).
Of all the concessions to usability this is the only one I still want us
to think about. I find it more important than any amount of xpath support.
Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
