[josm-dev] [PATCH 1/2] QuadBuckets (using quad tiling) for node storage in JOSM

[Karl Guggisberg]

Hi Dave

> Any idea how you want this to look?  I'm starting to code some primitive
things, and it would be nice if I could get whatever I do merged eventually.
AFAIK, nothing has been done so far. 

> * Object updates are rare, and it is OK if the notification process is
relatively slow

> * Rather than storing a list of all listeners that should be consulted
>  on each object, store a (relatively) global list of listeners.  Each
>  listener would get all object updates for a particular type.  That
>  keeps us from having to store anything in *each* primitive.
Currently, JOSM manages a list of data change listeners on *application*
level.
We'd need data change listeners per data set or per layer. Events should be
emitted automatically, no call to fire... necessary by clients which update
objects.
Efficent batch processes are more and more important (see validator plugin,
see upcoming changeset revert tools, see conflict resolution tasks), though,
and it would
be nice if data change event propagation could be used in two modes:
immediate
event propagation after an individual upate, event propagation after some
kind of 
batch job has finished.

> I also want to have a ReverseLookup (node -> ways) cache.  I've had it
sitting in the validator, but it's hard to 
> keep it coherent and I end up throwing it away too often to make it
useful.
I recently hacked a basic revere lookup table for child/parent relationships
(node -> way, node -> relation, way -> relation,
relation -> relation), but it has to be build from a dataset on request, for
instance before you start to fix 1000
duplicate nodes in validator. That's what the lookup table is currently used
for (mainly in the new merge node 
action). 

> Thinking about it, though...  If we had ways in QuadBuckets, I probably
wouldn't need the ReverseLookup cache.  I'd just do a 
> search for ways around a node and I'd just get the ways that are using the
node back.
Yes, but consider relation members too. That's where we often need reverse
lookups.

Regards
Karl