[josm-dev] Problem with referrers

Frederik Ramm frederik at remote.org
Mon Oct 5 08:43:55 BST 2009


Jiri,

Jiri Klement wrote:
> I'm working on support for referrers and I run into a problem which
> I'm not sure how to fix.

Can you explain (or point me to a previous post that explains) what 
referrers are good for?

> Currently JOSM quite often makes copies of
> primitive (using for example cloneFrom or special constructors). It's
> not obvious whether the copy is added to the dataset or is kept in
> case we need to get back to old version of primitive (for example
> Command.cloneMap). That's a bit problem because I don't want to have
> such copy in referrers list, I want only primitives that are really
> used in an dataset.

I'm trying to make sense of this (but might go off in the completely 
wrong direction here) - you're trying to keep a "breadcrumb" trail of 
what happened to an object, is that right? And you want referrer lists 
to model that "family tree"?

But why can the list not simply reside on the other side, i.e. in the 
descendant object pointing back in history? I have the feeling that 
you're duplicating information by distinguishing objects that are 
"really used in a dataset" from those that aren't - should not the 
dataset itself be the ultimate arbiter on what is "really used" and what 
not?

> To workaround this issues I'm thinking about introducing new classes -
> PrimitivePrototype, NodePrototype, WayPrototype and RelationPrototype.
> These classes will hold informations for one primitive, but it will
> not be possible to add these objects to the dataset. That will allow
> to clearly distinguish what's real primitive and whats just an backup
> copy for for example Command.cloneMap or Main.pasteBuffer. 

[...]

> This will also fix another issue - for some features (most notably
> reliable events when primitive is modified) I need for every primitive
> to be part of exactly one dataset.

Could one perhaps forgo the prototype objects you are suggesting and 
instead create a "backup copy dataset" (that is not associated with a 
visible layer); then postulate that every primitive always has to be a 
member of exactly one dataset - either a "proper" dataset or the "backup 
copy dataset" (or maybe others like it)?

I am not entirely happy with making primitive constructors protected. Is 
it so unthinkable that people, e.g. those writing plugins, would like to 
use primitives for purposes that are unexpected for us - purposes where 
they are not at all interested in things like "reliable events"? Just 
because we need that somewhere in JOSM doesn't mean we have to force it 
on everybody, or force them to write their own classes instead of 
re-using ours. I have a feeling that it would be nice if our Node class 
was primarily that - an OSM node - with perhaps some added JOSM bells 
and whistles. Maybe, in a way, you were aiming at making your "node 
prototype" represent a basic node, and the Node class would play the 
role of linking that basic node into the greater JOSM context? But if 
that is right, then I guess we should change the naming - i.e. instead 
of saying "datasets consist of primitives which are made from 
prototypes" we should say "datasets consist of adapter classes (or 
linkage classes, or instance classes, or context classes, or wrapper 
classes or something) which refer to a primtive". I.e. instead of 
further and further mangling the primitive and adding a prototype to its 
side, make the primitive into a real primitive (which you called a 
prototype) and but all the fancy stuff in the new PrimitiveContext class.

--

When would your prototype objects be created - only on demand or would 
they always be there? Say I load a data layer from a file - does that 
then create a set of primitives and an associated set of prototypes 
(memory issue?), or would the prototype only be generated when required? 
  How would you manage object identity - could you quickly sketch, for 
the following sequence of actions, at what time what prototypes and 
primitives would be generated and what OSM ID would be associated with them?

* start JOSM
* load data layer from API
* create new, empty layer
* copy node from data layer
* insert node into new layer
* upload new layer to API

Bye
Frederik





More information about the josm-dev mailing list