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
