And this is why we like Bryce, cutting through layers of madness yet again. > some new class. Repeat--"FeatureCollection" is not part of a programming > specification. Data transport only. No mojo. :) > Add another point to your list Justin; removing FeatureCollection from GeoApi as a crazy invention. > 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. > Our recent experience is that using Java Collections for these kind of ideas is a bad move. It has lulled our user community into some really bad mistakes; hense the motivation for this proposal. > I totally agree that making something you have no need for is dumb. > .. > 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. > Okay if I understand you; if we ever care about finding a standard interface for these ideas we can go look up coverage stuff. Got it. Until then we are on our own and much happier for it.
Thanks Bryce. > Bryce "Repetitiveness is my job" Nordgren :) > It is more that you have to wait (sometimes years) for us to catch up. 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
