| Re: [udig-devel] Pattern for updating features based on attribute change |
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. 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. 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.) 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. probably too much information.. Miles On Aug 13, 2010, at 7:36 PM, Jody Garnett wrote:
|