Jody Garnett ha scritto: ... >> I don't think you can do anything but an interactive pixel query >> with such a method thought, it's too inefficient for anything else. >> Access to big amounts of raster data must be optimized to the bone >> if you want it to perform decently, I think coverage people may >> just say "ok" for this kind of support, but then stay 1000km away >> from it in whatever real world implementation they do. > Not sure I understand your example very well; I mostly view this as a > way to "out" methods to the dynmaic type system that is the general > feature model. > > For the operation used by coverages for sampling they get a single value > (a Record actually) and the operation describes this result as a > RecordType). There is supposed to be some intergration here (both Record > and FeatureType are supposed to have MemberType - all these things > extended Name and were really horrible. > > GeoTools includes a RecordType and I have never seen a use of it I > respect from an interoptibility point of view - everyone stubs and/or > returns null.
Ok. Well, let's see what the coverage guys think of this. >> Got it, but there were two questions here. The first one is still >> unanswered: >> "attributes are non qualified". Hum, what do we do with GML Feature >> attributes like gml:name? > I would guess that SimpleFeature would not be applicable then? Um > "gml:name" is an odd case because "gml" is a prefix; the formal > unambigous name would be bit longer and represented as a formal Name > object right? Well, if simple feature cannot be used there, then it's useless from the GeoServer point of view... I was hoping for something we can actually use in GeoServer too, there is no way we switch to complex features right away. >>>> * Association >>> I think we are trying to set it up so people can smoothly use things >>> from the property interfaces >>> (so they can access the binding and value of a property regardless of >>> if it is an attribute or association). >> I see nothing changed in the api thought. At the moment a user >> accessing an association can still call both getValue() and getRelated(). > I was explaining the API not changing it: > - Association.getRelated() follows your association > - Association.getValue() is the same as getRelated().getValue(). I was thinking that getValue() would return Attribute. I mean, it would be consistent with ComplexAttribute.getValue() returning List<Property> no? The only thing that returns the actual value directly is Attribute. Yet, it may work the way you suggest too... Cheers Andrea ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
