Jody Garnett wrote: > 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? I meant a very domain specific generalization, where custom logic creates new features by combining several "real-world" features into something more general. I don't think what we need to do is possible to do in a general way, e.g. in the renderer, as it requires domain knowledge. But I will certainly have a look anyway. Maybe it could be possible using some schema relationship thing, like using "foreign key" attributes or something. But I think we will do some custom logic for this. >> 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 > Regards, Erik Loevlie
------------------------------------------------------------------------- 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
