Andrea Aime wrote: > Jody Garnett ha scritto: >> Andrea Aime wrote: >>> I understand. Yet I feel we lack a middle ground allowing to represent >>> associations in an efficient way, the same way deegree did. >> (In my benefit/complexity table this whole multiplicity thing is a >> good tipping point) >> >> I still don't see why it could not just be an implementation options; >> if an implementation wants >> to keep several values as an array and dish them out one at a time >> for the getValues() method >> that is cool. The fact that they would be able to answer a Collection >> getAttribute( name ) question >> very quickly and efficiently would be fine as well. > Nope, this would be memory efficient, but not time efficient. > Memory allocation in java is fast, but not free... think the whole > optimization process related to substituting Coordinate[] to double[]. > > Anyways, one thing, does ComplexAttribute.get(Name name) need to return > a List<Property>? Or we can have a fast path returning List<Object> (the > property values) here? Good question; we focused on the "raw needs" of the data model here and did not add many helper methods - leaving those for SimpleFeature. I would like to say that List<Property> is the answer; but my reason is pretty weak ... if you have several Geometry objects in your Feature they each may have a different CRS .... List<Object> getAttribute( nameDescriptor ) would only let you see the JTS objects List<GeometryAttribute> getAttribute( geomDescriptor ) would let you see GeometryAttribute with access to the id, crs, bounds and JTS object
This is a straight trade off; if people are throwing xpath at us wanting values out it would make sense to return the JTS objects; if they really want the Property they can go through the getProperties(): List<Property> like real men? Because the interface is "known" we can also make static final utility methods for some of this stuff right? No reason to dump extra methods into the interfaces (they only get in the way for interoperability) Bleck; back to work for me - looks like I am into Geometry transformation bugs today. > I guess the question boils down to wheter Name is a full xpath > representation (with wildcards and whatnot) or is just able to represent > the path to a nested attribute? The javadoc does not tell (or at > least, I don't see it). 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. Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
