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 _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev