Hi Jody,
See my prior post, but I saw the notes on memory data store and was only using it for mock up purposes. I'm not sure where these tutorials are..somewhere in:
http://udig.refractions.net/confluence/display/DEV/1+Getting+Started. But in any case, what you're describing below sounds exactly like my basic use case but I'd like to go a lot further than that.
We have made a couple of the workbooks from the training course available to the community - and indeed that is the link you found above.
The tutorials are part of the commercial training course (talk to any of the PSC members if you need to arrange a course to be run; LISAsoft for example should announce one later this year).
The source code for the training materials are available in svn; and if you are determined you can go through with a debugger and see what is happening. They are not the best example code as often they are used to communicate a concept rather than be efficient; indeed making them efficient is the subject of some of the exercises.
The tutorials are listed here:
Finally if you are a member of an academic organisation we have an arrangement where a professor can email a PSC member and obtain access to these materials for a grad students. Our motivation on this one was to get some good questions and testing for the training materials; so far it has mixed success.
For agent-based modeling support we do need to provide that ability to move items around on the landscape. But I'd also like to be able to change any kind of map object in real time. For example, you might want to model the spread of an epidemic from region to region in which case you'd want to treat shp file polygons representing those regions as agents and update them dynamically. So really, I can't see any reason beyond performance perhaps to treat the modeled map components any differently than any other components. That would be a much more satisfying approach from the Model point of view but of course you'd also then have the ability for users to treat the VIew just as with any other Geo feature. While it would also be a real advantage -- and inherent in a decent integration -- for users to be able to treat the model objects as regular editable objects that isn't a key need. And in fact, the overhead associated with doing all of the edits through an framework (command stack, etc..) is likely to be too high.
One thing to do is to allow your data to adapt to a FeatureSource as needed (allowing for integration with the GIS tools); but still have your core object model with tools and fast renders as needed.
An example of this from the uDig code base is a WMSLayer; if it can tell that the layer comes from GeoServer it will allow the layer to adapt to a WFS FeatureSource - allowing you to select with the feature selection tool content from a WMS layer.
With the approach that I sent in my reply to Andrea I was seeing buffering issues unless I had a wait time of ~500ms for an update, and this was with ~50 polygons. That's actually not a killer assuming that there are some opportunities for improvement -- It would be lovely to have 60fps :) but actually the user experience can be fine with much less through managing when visualization changes are actually rendered.. But it will all depend on how well it scales to more polygons -- at this point its not clear to me how much that is i/o bound and how much rendering, but it does seem like I need to think a lot about performance issues. For example, I think that there might be update notifications happening at each set attribute, and that's something that would eventually need to be batched. I'm trying to avoid the mistake of premature optimization but at the pilot stage I do want to discover the development path most likely to lead to best performance without losing too much of all of the nice things that uDig supports.
[btw, *total* place holder for future discussions, but have you guys given any thought to supporting 3D vis as primary graphics? THe GEF3D guys are doing really cool things with support for 2 1/2 D graphics and everything I've played around with shows that you almost always get a significant speedup going from AWT/SWT to OpenGL.)
You ask about 3D; the viewport model is separate from the renderer; and 3D can be supported as a rendering engine without disrupting the rest of the application. So far a couple of teams have done it; the last one got into some license trouble and had to withdraw their work.
I would of course be happy todo do the work but:
- I would need a customer and contract as it is more effort then I intend to put in as a volunteer
- we would need to preserve the independence of the application from the rendering system (as some installations rely on citrix or other screen remoting technology that does not play well with 3D).
Anyway, the bottom line is that its always possible that for some things super-imposed images / glass pane approach is needed but I'd like to try for a real integration first. And I'll be dealing with the model data internally so on the other hand I don't care as much as most people would about coherency and consistency in the geo model itself.. I'll simply need to make sure that at the moment of any write-back persistence to the geo stores (shape files, etc..) that that is managed well.
The uDig system is however *great* for integrating your own renderer onto your own data model. Indeed if I was doing it that would be my choice for showing your agents at work. The combination of Spring/Hibernate remoting and a custom renderer overlaying "real objects" overtop of a normal GIS Map (features and rasters) is a common approach used several teams around the world.
So just because your data is not "spatial" do not feel that is requires "real integration" - the ability to mix it up is why uDig is a great integration platform.
probably too much information..
No worries; better to have some background so I am not giving you poor advice.
