The problem
Some users of our services ask whether we provide a permanent and unique
identifier (id) for a location. We do NOT. This document explains why not.
Background
There are
many
different location encoding schemes, some national, some international.
Some covering regions, some down to individual buildings.
Some open source, some proprietary.
Some of these systems are essentially just algorithmic permutations of
latitude, longitude, while others are centrally assigned numbers or words.
Some of these systems are widely used, others not.
Each of these systems has different goals or design objectives and
makes assumptions about what "permanent" means.
What does permanent mean?
The fundamental challenge with permanent ids is that the world is in a state
of continual change. Nothing is actually permanent.
Here are some examples of very common real world situations that might necessitate new "permanent" identifiers for a building.
- An old building is torn down, a new building is built on the same location and uses the existing address. Should the new building have a new id or use the old one?
- A building has a new use (a new store for example). Should it have a new id?
- The boundaries of a property change. Should it have a new id?
- A road is renamed, thus changing the addresses of the buildings on that road. Should these buildings now have new ids?
- A building is subdivided. The subdivisons each receive a new address. Should they have new ids? What happens to the old id?
Rational people can disagree about how to treat all of these situations, and of course there are many other such edge cases.
Likewise, local (and occasionally national) administrative hierarchies are in a continual state of flux.
The end result is that assigning "permanent" ids is not an intuitive process. There is no single, clear, universally agreed process.
What about OpenStreetMap?
OpenStreetMap assigns an id to each "object" (node/way/relation) in
its database, and we are sometimes asked if we can simply return
the "OpenStreetMap id" for a place.
This is not possible because we aggregate many different open datasources,
much more than just OpenStreetMap.
But secondly, OpenStreetMap ids are not permanent across time.
Just because some place has id X today, does not mean it will have that same
id tomorrow. Likewise, even if it has the same id that does not mean
the attributes of that object have not changed.
In OpenStreetMap things can and are re-mapped at any time.
So what should software developers do?
The first thing is you should understand the challenge of permanent, unique
identifiers.
Fundamentally where you need some form of permanent identifier will
depend on the nature of your project and what you are hoping to build
and maintain.
In the
annotations
portion of each API result we return numerous types of identifiers
for that specific location. Depending on the needs of your
project, one of these location codes may be a good match for your needs, and
if so you should use it, of course understanding the pros and cons of
that system and how it handles changes and how frequently those changes
are likely to occur.
If your project is limited to a specific country there may be
a national place id scheme that meets your needs.
Because there is no single, obvious solution to permanent ids, and
because users of our geocoding API are building such a diverse set
of services, with different needs and requirements,
we do NOT
attempt to set a permanent id in our geocoding API response.
Further reading
Happy geocoding!
2,500 geocoding API requests/day - No credit card required