internal ids are changing

[dieterdreist]

I don't know whether this is expected, but I didn't, somehow I experience the ids in saved files changing. It doesn't happen always, and I am not sure which operation makes them shift, but I can see it in the files (it is the same file, saved consecutively):

 % head local_005.osm
<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='false' generator='JOSM'>
  <node id='-1587743' lat='45.80836512471' lon='7.27175232872' />
  <node id='-1587744' lat='45.80846685784' lon='7.2716349593' />
  <node id='-1587745' lat='45.8085647' lon='7.27155792816' />
  <node id='-1587746' lat='45.80856694459' lon='7.27170626972' />
  <node id='-1587747' lat='45.8086692203' lon='7.27241995035' />
  <node id='-1587748' lat='45.80877815765' lon='7.27173320596' />
  <node id='-1587749' lat='45.80899113177' lon='7.27155602427' />
  <node id='-1587750' lat='45.80924687428' lon='7.27166994302' />

 % head local_006.osm
<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='false' generator='JOSM'>
  <node id='-1756958' lat='45.80836512471' lon='7.27175232872' />
  <node id='-1756959' lat='45.80846685784' lon='7.2716349593' />
  <node id='-1756960' lat='45.8085647' lon='7.27155792816' />
  <node id='-1756961' lat='45.80856694459' lon='7.27170626972' />
  <node id='-1756962' lat='45.8086692203' lon='7.27241995035' />
  <node id='-1756963' lat='45.80877815765' lon='7.27173320596' />
  <node id='-1756964' lat='45.80899113177' lon='7.27155602427' />
  <node id='-1756965' lat='45.80924687428' lon='7.27166994302' />

 % head local_007.osm
<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='false' generator='JOSM'>
  <node id='-1933515' lat='45.80836512471' lon='7.27175232872' />
  <node id='-1933516' lat='45.80846685784' lon='7.2716349593' />
  <node id='-1933517' lat='45.8085647' lon='7.27155792816' />
  <node id='-1933518' lat='45.80856694459' lon='7.27170626972' />
  <node id='-1933519' lat='45.8086692203' lon='7.27241995035' />
  <node id='-1933520' lat='45.80877815765' lon='7.27173320596' />
  <node id='-1933521' lat='45.80899113177' lon='7.27155602427' />
  <node id='-1933522' lat='45.80924687428' lon='7.27166994302' />

I would like to track changes (create changefiles) in these files, are there operations I can avoid in order to not have the numbers changing?

[skyper]

This is intended with the currently used system without internal ids per layer. You could try to restart JOSM to reset the internal ids.
Thought there is a ticket about individual command stacks per layer but I do not find it.

[stoecker]

JOSM has no internal ID's. All new elements have ID zero. The negative ID's are only generated on export to file as they are needed for referencing the elements.

Either use something else for tracking changes or use non-negative IDs (but don't upload these to the server then).

[GerdP]

JOSM has no internal ID's. All new elements have ID zero. The negative ID's are only generated on export to file as they are needed for referencing the elements.

I think the negative ids are stored, but the current code uses a global object to generate the negative ids and the OSM readers ignore the negative ids in input files. I don't fully understand why it is done this way and I would prefer to always use the ids given in the input file.

[stoecker]

There is no variable to store negative IDs: trunk/src/org/openstreetmap/josm/data/osm/AbstractPrimitive.java​.

[GerdP]

The field id is used to keep the ids, it allows negative values. I often use this fact while debugging.

protected long id;

[stoecker]

Read the description:

 /**
  * Unique identifier in OSM. This is used to identify objects on the server.
  * An id of 0 means an unknown id. The object has not been uploaded yet to
  * know what id it will get.
  */

It can hold a negative ID, but that's simply not supported. A negative ID would still be a server ID in this case and thus simply wrong.

[GerdP]

Still, the code in JOSM typically sets a negative id which is - as far as I know - only changed on upload and JOSM also displays it when the corresponding preferences are set, I think these are

  <tag key='osm-primitives.showid' value='true'/>
  <tag key='osm-primitives.showid.new-primitives' value='true'/>

Method getUniqueId() is used for this. It is also needed to display error messages like "JOSM expected to find primitive ...."

[Klumbumbus]

Vincent once changed something to keep the negative ids stable for the special case of our boundaries file. There is an additional entry "Edit boundaries" at the More button in the Advanced Preferences if JOSM is started in debug mode. See ticket:14833#comment:2 and #16854.

[mdk]

Replying to GerdP:

JOSM has no internal ID's. All new elements have ID zero. The negative ID's are only generated on export to file as they are needed for referencing the elements.

I think the negative ids are stored, but the current code uses a global object to generate the negative ids and the OSM readers ignore the negative ids in input files. I don't fully understand why it is done this way and I would prefer to always use the ids given in the input file.

As far as I understood, JOSM chooses negative IDs from an internal "ID generator". If you store a file, the negative IDs will be stored there. After restarting the ID generator will be reseted. If you load such a file later, you could not use the old negative IDs, because they could collide with newly generated negative IDs. So on import you must use a translation map. Whenever a new negative IDs is imported from a file, a new negative ID must be generated and the pair is stored in the map. When an old negative ID is referenced in the import, the new negative ID is used from this map.

[GerdP]

I see no need for a remapping. JOSM has no problems to keep several instances of objects with the same positive id, so it should be able to keep equal negative ids as well. The "ID generator" and the remapping seem to be used to force unique negative ids, but I don't see why this is done. Maybe it was needed long ago?
Edit: Ah, One reason would be if one merges two datasets with negative ids. That would cause more trouble when ids are not unique.

[stoecker]

IDs must be unique otherwise they can't fulfill their purpose.

For JOSM the IDs have no meaning as internally JOSM uses data structures for data references, but as soon as import or export of data is done the IDs get a meaning again. And in these cases you need a consistent set of unique IDs.

It's seems what Vincent did was to keep the imported IDs in a list, so they can be reused on export. But that works only in a few specific scenarios.

[anonymous]

I certainly didn’t expect that when I save a file with josm, then open it and save it again, all IDs would change. I also means that if you merge 2 layers with almost identical versions of your data, you will end up with everything duplicated?

[GerdP]

No, the merger "looks" at the attributes of new objects to find out if they might describe the same real thing.