Jody Garnett ha scritto: > Andrea Aime wrote: >>>> 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. > Perhaps I am mis understanding; would you not just refer to the the > above as "name" ? Are you getting conflicts between gml:name and > something else?
Conflicts are quite common since a "name" column is not forbidden in many dbs, as well as "location" (another gml:Feature attribute). I guess we could map those directly into the Feature ones, but users already complained about that... alternatively, we would just write over them, or have this as a configurable item. Justin, opinions? >>> 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... > I think I need to see a code example on this one. What I mean is: ComplexAttribute.getValue() -> Collection<Property> then similarly it should be Association.getValue() -> Attribute The equivalent of Association.getValue() == Association.getRelated().getValue() would be ComplexAttribute.getValue() -> Collection<Object> (where Object is the Property value). Does this make sense? :) 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
