Will ever the website https://www.openstreetmap.org find places using plus codes.
or
Is the use of plus codes be considered (to find places) in any OSM umbrella apps and sites?
Thank you
RB
I believe that some OSM-based apps such as OSMAnd and Maps.Me support searching for plus codes.
The addition of this feature to the osm.org website is being discussed every now and then, and there even is a possible implementation by Tom Hughes. However, there is no consensus among the website developers yet on whether plus code support should be added.
Thank you.
There is a prototype app for OLC here:
You can read more about it here:
Thank you. Fantastic info.
RB
More than half a decade later: Why is this not yet implemented on the osm.org website for sharing a location (short link) instead of the cryptic hash that is used now? And why can’t Nominatim (or some alt search engine on the osm website) find OLC addresses?
It is used by
- Osmand
- OrganicMaps
- Mapy.cz
- Marble
and probably many more.
How do you think they should be used?
Keeping in mind that +Codes does not indicate a point that can be defined with a coordinate but rather an area.
Would you be willing to add a +Code for each OSM element size?
I mean using the +Codes API to roughly define an area, i.e. a building would be equal to a +Codes with a certain number of digits, a town would be equivalent to a +Codes with fewer digits than the building.
Or use a +Codes with a predetermined number of digits to identify any OSM element? Which, in my opinion, would be a bad idea to use +Codes, because this can be done with coordinates or with current OSM geocoding.
Should +Codes be added in full? I mean both encoding and decoding.
I suppose that in the future and to be more precise, we must define what we want to use: +Codes or OLC?; +Codes refers to a service directly related to Google Maps and that works without a Google ApiKey and with a Google ApiKey (The codes generated by OLC are called +Codes but it is also a web tool). Adding a Google ApiKey to the body of the query URL gives an extra in the returned information (Local Code).
Example of +Codes without Google ApiKey and with ApiKey Google.:
I think we should first define what use OLC would be given in OpenStreetMap:
- Point to any area
- Point to an OSM element.
- Or the previous two.
Some opinions about +Codes=
if you want to share using location, you can do this - not clicking “short link” will avoid link shortening
https://www.openstreetmap.org/?mlat=54.773275&mlon=31.788447#map=19/54.773275/31.788447
1 Like
Well, I don’t want to repeat everything that is already stated here Proposal:Open Location Code - OpenStreetMap Wiki
OLC or plus-codes algorithm is open source apache licensed (like bsd or mit). Code examples are totally open source. And in the non-rich world they are used as addresses for houses and places. We do not need OLC tags, but just the osm.org search (Nominatim?) to resolve the OLC/plus-codes to a place on earth. And at the same time show for a given point/area the OLC/plus-code which is an address that can easily be transmitted by voice (dictated) or by writing. Stop thinking only from your rich and pampered perspective where all places have street names, postcodes and house numbers. This is not the standard for a big part of the world/humans.
As said above, most map applications use them (because those map applications are used by people with smartphones all over the world, not only in big rich cities with street names). Why not osm.org?
It is stupid to add OLC as tags. You wouldn’t add other coordinates as tags into the osm database.
As said, other applications and websites use OLC and most of them use the osm as database and it works without tags that contain OLC. No need for that, really.
Examples:
-
Osmand shows as coordinate
-
OrganicMaps can search and shows coordinate
-
Osmand can search for them
-
Osmand website also finds if you search
-
Nominatim doesn’t support it
The great thing of OLC is that it only uses easy destinguishable letters and numbers.
No i I l L 1 for example.
And +codes are less cryptic?
Compare 8FWR6976+59R to osm.org/go/0JrJCXmDG and geo:48.213,16.3609
The geoURIs the website puts out are also still not usable as input because the PR adding the parsing for it is still being battered by how the most improbable edge cases are handled.
2 Likes
My guess is people interested could implement ANY location code with a local browser extension - Using firefox something like greasemonkey will help.
The OSM server part does not need to have support for all of the OLC, W3W or whatever we come up with tomorrow. As we have right now with some Mobile Apps which do support it, others dont.
When OSM generates permanent location URIs they are either to an OSM object, or to a lat/lon.
similarly, I would be interested in using w3f, but it seems offline. Has someone information what happened to them?
for reference, here’s their former web address: http://www.what3fucks.com/
and some more info:
https://knowwhereconsulting.co.uk/blog/what3fs/
2 Likes
It would be interesting for Nominatim and similar to support OLCs, just as a political statement against what3words.
Weird that Google is the more Open option here.
2 Likes
Well, they would not profit from w3w schema being popular so it is in their interest to promote substitute.
Strategy Letter V – Joel on Software looks applicable again
Small point of clarification, not to detract from the broader point: some parts of the world use a mix of both conventional street addresses and coordinate-based systems. It can be useful to indicate explicitly that a given residence or point of interest uses an OLC as their address, just as we sometimes need to affirm that a POI uses a street corner as their address (even though we obviously already have the intersection in the database).
Here in the U.S., Plus codes are used officially by the Navajo Nation but only when there isn’t already a street address. It’s probably difficult to tell from afar which houses there use conventional street addresses and which use Plus codes, but it would be worth the effort for more local mappers to try and gather this information.
I wonder if that might also be the case in Africa, where the Full_Plus_Code=* key has seen a steep rise in popularity over the past couple years. Maybe this would be redundant to something more universal on the software side, but at the very least, it’s good that people are able to work around the problem.
Hi,
There’s something real wrong here https://taginfo.openstreetmap.org/keys/Full_Plus_Code#values
6FWHW94V+P9PF 2349 47.96%
6FWHW9JV+PWV5 788 16.09%
https://overpass-turbo.eu/s/22Sf
Minh Nguyá»…n via OpenStreetMap Community Forum <community@noreply.openstreetmap.org> escreveu (quarta, 23/04/2025 Ă (s) 20:54):
3 Likes
The two values appear to be limited to a single mapper on buildings on the outskirts of Jalingo, Nigeria. This accounts for the rapid rise in December 2023 from about 1,800 to about 5,000. I haven’t checked the other values for accuracy, but they seem to be more or less unique to a given building. Anyways, it’s a good thing these mappers didn’t choose a reasonable key name. Those interested in affirmatively mapping OLC-based addressing practices still have the opportunity to choose something under the addr:* namespace. 
This is a clear example of what I already pointed out in another post, everything that can go wrong with +Code as an identifier in OpenStreetMap. If we take into account the screenshot I published above, related to the direct equivalence between the number of digits in the +Code and their correspondence to an area of x size.
- 12 digits (6FWHW94V+P9PF) are equivalent to an area of 56x87 cm. It could be used to identify the door of the building:
Way: 1225431312 | OpenStreetMap
But it points to the center of the building. - 10 digits (6FWHW94V+P9) are equivalent to an area of 13.9x13.9 mts. It could be used to indicate the entire building since the +Code area covers the entire building:
Way: 1225431312 | OpenStreetMap - 8 digits (6FWHW94V+) are equivalent to 278x278 mts, and yet it is not correct to encompass the OverPass query area as it points to a grid southwest of the center of the OverPass query.
- 6 digits (6FWHW9) are equivalent to 5666x5666 mts, area too large. The ideal would be 7 digits, but this amount is not contemplated in OLC.
The best way to provide context is to use the +Code grid. I don’t think there is currently any documentation on how to use +Code correctly in OSM. Except for one building, all the buildings shown in the OverPass query have incorrect information.