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

[Dave Hansen]

On Sat, 2009-09-12 at 21:36 +0200, Karl Guggisberg wrote:
> > Just recently, Node/Way/Relation require access to be via accessor
> functions.  That should help out quite a bit.  
> > The one thing that we do need is for a list of PrimitiveChangeListeners or
> something to call when primitives do change.
> This is the very motivation Jiri and myself have been working on replacing
> direct field access with accessors. Now we can start to work on features
> which will really improve JOSM, a spatial index for instance.

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.

* 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.

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.

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.

-- Dave