I stumbled upon full_id - https://taginfo.openstreetmap.org/keys/full_id doesn’t say much: 18245 instances with 16080 distinct values, by 388 users in locations on all continents. Most instances are combined with the equally obscure keys osm_id and osm_type. All three appeared in 2015 and have had roughly stable populations since then. https://wiki.openstreetmap.org/wiki/Key%3Aosm_type says osm_type is deprecated.
What is this ?
from looking at full_id | Keys | OpenStreetMap Taginfo - looks like an import debris
you can try using overpass turbo to find objects with this tag, look at history and track down edits that added it (remember to check is there a way split/revert - or actual adding tag)
Likely these keys is results of import(s), looks like internal properties of conversion or conflation script, normally such keys are stripped before upload, but not always.
Initial analysis of a single node and a single way with the full_id key.
Node: 13526561116 created: 2026-02-05 15:35
Substituting the osm_id in the URL for a node gives Node: Monument Vroonerplas (5827141976) | OpenStreetMap created: 2018-08-13 08:53
OSM History Viewer:
Way: 1455144436 created: 2025-12-01 14:12
Substituting the digits from the full_id in the URL for a way gives Way: 176509515 | OpenStreetMap created: 2025-01-18 18:33, deleted: 2025-09-16 08:15
OSM History Viewer:
The nodes (both existing) are of the same object and the ways also appear to be of the same object. Looks like something fishy is going on here
Had a look at another one.
Overpass: nwr[“full_id”=“w1311562989”].
This result looks like a closed way but is actually 3 connecting ways all with the same full_id. And that leads to 1311562989
I did a little bit of cleanup of those tags a while back. If I remember correctly, they are an artifact from QGIS (or some other similar non-OSM-specific GIS software) - the result of loading OSM data into external programs, modifying it, then uploading back to OSM.
I don’t recall running into a case where they couldn’t be treated as discardable tags.
Have to disagree here. Actually the node id in my previous post is one where you had deleted the osm_type key. But that is a minor part of the problem I see. All the full_id/osm_ids I tested lead to “older” versions of the same object. That in itself would not be a problem, well at least not a big one, if they where all deleted versions unfortunately that is not the case. Several of then are duplicates.
In what way is osm_id, osm_type, or full_id ever useful?
It is not that the tags are useful. I think they are not. But they are a symptom of another problem.
I have been doing testing for some time now and as long as the number is positive there is an older version of that object, sometimes deleted but often not, leading to duplicates. What I do have noticed is that all objects created with those tags I have looked at are created with JOSM, So it looks like there is a problem with JOSM As Lumikeiju says in their post JOSM is probably used to upload data from external programs.
Yes, that problem being:
Naturally, JOSM is being used to upload back, but it is a red herring. That I could tell, there is no “fault” on the part of JOSM (JOSM receives object with an osm_type=node tag from the user and is told to pass it along to the OSM API, which it does faithfully).
Neither is it malicious on the part of the user, though I guess it does show a lack of due diligence in post-upload QA. An easy enough mistake to make.
I mostly saw these tags from “hit-and-run” editors or imports, so I judged that the time was best spent just sweeping up, rather than chasing them down for a lesson about littering they likely would never hear.
Lots of ways to address this - raise issue with QGIS, campaign to have OSM editors treat these tags as discardable, make OSM Wiki pages so others running across these tags have some idea of what they are, reach out to users via changeset comments or direct messages, etc. - you are more than welcome to spend the time doing any/all!
One more for tonight.
Here Way: Murara (1041137250) | OpenStreetMap it looks like a relation is “replaced” by a way. Unfortunately the relation (Relation: Murara (12761061) | OpenStreetMap) also still exists.
I agree, that this is probably the case. The real problem is that quit often the “old” object where the full_id/osm_id is from, is also still active. Effectively leaving 2 OSM objects for the same feature. And that I think is an undesired effect and should probably be handled when the osm_type, osm_id and full_id keys are removed.
Talk of duplicates is ringing some bells… I first encountered these tags a few years ago while dealing with a considerable number of duplicate POI around Pointe Noire, Congo. For example, a bunch of them originate in Changeset 75576096 - whose source=#Immergis might be a clue. Immergis is a French GIS consultancy. This smells like import.
Exactly. I don’t know which workflow it is that creates these tags and duplicates, but there is the similar case of @id: People download data from Overpass, save it in a geoJSON file, open it in the editor and upload the result, ignoring the warnings by the validator. This always leads to duplicates and a huge bunch of new objects.
What are the full_id, osm_id and osm_type tag keys?
Silly.