[EMAIL PROTECTED] wrote on 07/31/2007 11:34:02 AM:
> >> I do happen to think ISO19107 FeatureColletion will be valuable - but > >> if we do not have resources/mandate/will to implement this right now > >> (or ever) then I would like us to do exactly that ... not implement > >> geoapi FeatureCollection. This may be moot, but 19107 doesn't mention a FeatureCollection. If it did, we might have some idea what the function of this mystery class should be. :) It was specified in OGC's GML spec as a container for a bunch of features. Because it's really a convenience for carriers of XML data, it doesn't have any behavior. Whereas most of GML is just an encoding of something which is defined in one of the other standards, this is an "invention" of GML. The entire definition consumes almost 1/2 a page if I recall correctly. It should perish from the surface of the earth. Do not, repeat, DO NOT add random functionality to this class. Let featurecollection continue to serve whatever purpose it currently serves, and put new functionality in some new class. Repeat--"FeatureCollection" is not part of a programming specification. Data transport only. No mojo. :) When I thot about this last, I pontificated at length in one of my infamous "papers" about the similarities and differences between "discrete coverages", a java.util.Map with a geospatial Key, and this ambiguous/functionless "FeatureCollection". Long story short, it may be extremely beneficial to implement the Java collections interface with "spatial indices" for rapid access to spatial data. In addition to the obvious utility, it's a stepping stone to implementing "discrete coverages", which effectively models the table-based data sources (shapefiles, database tables, etc.) But we wouldn't code against the FeatureCollection interface, we'd implement java collections. I totally agree that making something you have no need for is dumb. However, so is reinventing the wheel on your own when there's a previously architected solution. :) The coverage abstraction is designed to make it so that clients can interact identically with table-based vector data, continuous geospatial equations, and gridded data. Without doubt, before anyone sets out to propose a "ground-breaking" spatially organized collection, they should know where their proposal fits in the bigger picture and how their solution will be leveraged to build bigger and better things. On the other hand, to the best of my knowledge, there is nothing in the current or proposed stack of standards which specifies anything which could be considered a spatially-optimized implementation of Java Collections. Knock yourself out. Sift through the geotools-devel archives from early 12/2006 for msgs from me if you're interested. I believe the above mentioned comparison was included as a chapter or section in the 19123 primer, but I may be mistaken. If not able to locate it quickly, let me know and I'll dig it up for any interested parties. Bryce "Repetitiveness is my job" Nordgren :) ------------------------------------------------------------------------- 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
