Permanent location identifiers

  1. Guides
  2. Geocoding
  3. Concepts
  4. Permanent location identifiers

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 schemes 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 the 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 scheme 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!

Start your free trial

2,500 geocoding API requests per day.

No credit card required.