(resending, first message got stuck in the mod queue thanks to large attachement)
Hi, As there was a general refusal of large data structure redesign with a proposal to do something along the lines of josm-ng, I tried implementing the data structures with a bit scalability in mind, just to test where can I get with what kind of effort. You can try a (completely cleanroom) prototype implementation of josm-like editor (lacking almost all the editor features) with the following aspects modelled: MVC patern: The model is clean data set. It contains only the primary data and their modification status. It uses as little memory as feasible (A node with no tags - or "created_by tag only" - needs just a single heap object). The model has all the data fully encapsulated and all the modification generate and post undoable edits. The view is a separate layer that does both view transformations - projection and zoom/pan. It uses, as an implementation detail a view cache that: 1. keeps the projected coordinates 2. keeps the current assigned style for painting 3. Does all the math in integers 4. Can quickly filter out elements not relevant for display (not a quad-tree currently, but it would fit in nicely) The controller (user actions, using view layer only for backward transformations) modify the model directly. View follows with real time updates. Download at: http://stoupa.sh.cvut.cz/~nenik/OSMProcessor.jar You can try this with: java -Xmx256m -jar OSMProcessor.jar preferably on czechia.osm (~500.000 nodes, ~50.000 ways) unpacked from: http://kubajz.kbx.cz/junk/osm/czechia-080131.osm.bz2 What works: File->Open (blocks UI for a while currently) Displaying the data set. Styles implementation parsing elemstyles.xml Zoom (mouse wheel), pan (right button), node movement. Basic change coalescing and undo of node moves. And most importantly, reasonable repaint/edit performance at all zoom levels. For comparison, you can try opening czechia.osm in current josm (with large heap) w/o mappaint, it will behave acceptably (slow, but still usable) when zoomed, worse when zoomed out. You can try it with mappaint too, but the full-view will be slower than slow. I'm not attaching the sources now (I have used few JOSM concepts and icons but no code, so everything but the style data is (c) by me), but have no problem providing the sources under reasonable license if there is a demand. (Current JOSM's GPL was already questioned here). While I would like to continue productizing the prototype, I have very little time for this effort (I actually wrote most of the code around Christmas) and consider it mostly exercising material. Moreover, current JOSM has some plugins and a lot of code that would need to be (with slight modifications) duplicated in josmng, so I would, obviously, like to see the code land in the trunk somehow. It could solve also other issues besides memory usage and performance. The architecture with UndoableEdits allow composing "commands" easily without fear of breaking data consistency. Derived data structures (like the node-way-usage) can easily be kept consistent without adding complexity to the data modification code and so on. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! _______________________________________________ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
