|Definition:||keep the information from which other object(s) the object is derived|
|Rendered as:||usually none|
For many kinds of edits, e.g. splitting a road or replacing a node with an area, the history gets lost for resulting objects. This is bad because:
- Information loss is a bad thing generally.
- You don't know who created the object initially and why.
- You don't know in which ways the object has been modified, by whom, and why.
- You don't know who holds the copyright on the object, and under which licence(s) he provided his contributions.
- You don't know who you can ask if you want to know something about the object.
The upcoming licence change makes some of those problems obvious. Objects created by a user who rejected the oDBL/CTs are to be deleted - but what if he just inserted a small bridge into a 100km road at km 1? Then 99km of the road will be deleted, athough that user didn't actually contribute to that part of the road.
origin=[<type> ]id where <type> is one of node, way, relation. In case of multiple origins, separate them with semicolons, and define the type for each of them separately. If an origin has the same type as the new object, the type may be omitted.
Values of this tag are not inherited from other objects.
- Splitting a way with id 1001:
Set origin=1001 on the new way.
- Joining two ways (id 1001, 1002) into one (id 1001):
Set origin=1001;1002 on the remaining way (1001).
- Combining two multipolygons (id 1001, 1002) into one (id 1001):
Set origin=1001;1002 on the remaining multipolygon (1001).
- Replacing a church node (id 1001) with a closed way:
Set origin=node 1001 on the new way.
- Tagging an object as its own origin is redundant and ugly. But otherwise it would seem that the object is wholly descendant of others
- When joins and splits are mixed, the origin chains are mixed too. It is no more possible to identify the one true origin.
Note on implemention
Editors should set origin=* automatically upon splits if the new object is of considerable absolute or relative size.
Not to be rendered on ordinary maps. Development tools may visualize related objects on a map, or display pedigrees for objects.