Erik Løvlie wrote: > Sure. It is probably a somewhat weird use of a gis toolkit, however, > since we need to have really fast random access to the data model > (DataStore). The application is a (soft) real-time monitoring and > decision support tool which monitors a large geographically > distributed network of processing nodes (in addition to moving > vehicles), each of which sends status updates "quite often". > > So unfortunately we will not be using any of the database > functionality of GeoTools, as that would be too slow. We had a > prototype using ArcSDE with Oracle, but it was way too slow for our > use. Actually the flexibility of the GeoTools DataStore API was the > main reason we switched to it, as that would allow us to implement a > custom DataStore for performance. So we have implemented a DataStore > which holds everything in memory, like the MemoryDataStore, but using > the JTS QuadTree for spatial indexing. Yes, I realize everyone else > who is using GIS for a serious product is storing the data in a > database :) We don't need the robustness and security of a database > though, since data loss is not a problem. No complaints here - GIS is what GIS does. The rest of us have to work for a living.
A FeatureCollection backed by a JTS QuadTree has been something I have wanted for years :-) I would love to talk to you about your implementation. Nice work ;-) > This being a GUI application we are using a lot of the components in > the render and swing modules of GeoTools. We are using the > StreamingRenderer for rendering, and ZoomPane is the base class of our > "map" component. That is great; any feedback you have for cleaning up these classes and their docs would be great. uDig has been making use of a "map graphic" idea in order to draw legends and scalebars onto the screen - if we had someone such as your self to collaborate with it would be a fun bit of work to bring back to GeoTools. My own plans for MapContext (which StreamingRenderer uses) is to drag in some of the hacks that people are using in the real world back into GeoTools. > To enable user-driven selection of features (e.g. selection by drawing > a rectangle or polygon), we have extended the MapContext and MapLayer > interfaces. Heh - just so. Everybody extends these classes. > Also, we need to have generalization of certain features to reduce > clutter and improve rendering performance. Exactly how to do this we > have not yet decided. Generalization without selection is quite easy, > as that is just to use the minimum and maximum scale denominators in > the style, but we need to have user-selectable generalized features > somehow. Not quite sure what you mean? Do you mean decimation of a Geometry into a more simple form? You may be interested to see in Andrea's recent Query Hints as it represents a good approach? > Anyways, if we can clean up our DataStore and GUI components, then > maybe this code would be interesting for other people who are using > GeoTools in strange and unusual ways. Sorry for not being able to work > on your database modules though :) Not to worry; the gui components and your JTS backed Feature stuff sounds great. 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
