[josm-dev] JOSMng prototype [resend]

[Petr Nejedly]

(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!