Add OpenLocationCode to OSM website

[bjohas]

Mobile OSM apps (e.g. OSMAnd) already support OpenLocationCode, as does Google maps, and it would be great if the OSM website did too. There's a Ruby implementation, https://github.com/google/open-location-code/blob/master/ruby/lib/plus_codes/open_location_code.rb.

I.e. a search for 6PH57VP3+PQ, https://www.openstreetmap.org/search?query=6PH57VP3%2BPQ should return the area indicated by the OLC.

[mmd-osm]

There seems to be quite some confusion as to what's in scope for tomhughes@2e0a2c6 and what not. Besides lots of marketing noise, a good part of the wiki page is a about new requirements, that haven't been mentioned here before.

@tomhughes : I wonder if your branch could be deployed on the dev instance for people to try out and give them a better idea about what they could expect by having some OLC support.

[tomhughes]

I don't think any of the OLC proponents here are listening to a word we say anyway...

[tomhughes]

I've put my branch up at https://tomh.apis.dev.openstreetmap.org/ for people to try - it only supports global codes though.

[bjohas]

@tomhughes Thank you for putting this up, this is excellent and I'll have a look.

If you feel that there is stuff that is not listened to, please add it to the wiki page, and myself or others will respond. Please also look at https://wiki.openstreetmap.org/wiki/Talk:Proposal_Open_Location_Code where I have tried to answer questions fairly. I did try to reflect some of the discussion on this thread, but you can see the response to that attempt here: https://wiki.openstreetmap.org/wiki/Talk:Proposal_Open_Location_Code/archive. So - it's impossible to please everybody, but please assume good intentions on my part, including listening to concerns.

[tomhughes]

The creation of the wiki page after I said that a self selecting poll is of no use to anybody is kind of my point...

[LaPingvino]

I don't think any of the OLC proponents here are listening to a word we say anyway...

If you look at the wiki page, the questions we answer there are exactly what you say, so I would say that is a bit harsh. But then, as e.g. an Esperantist and some other minority movements I might be biased about the value of critics to a "self-selected group". I don't think we can put much value to your critique until your answers show you actually understand what OLC is.

Also, just to show my perspective on this: my investment in OLC is basically that I have been looking for ages and thinking about developing a system like what OLC provides (in my case just a global postal code system, because I lived in Belgium just across the border and I couldn't feasibly order pizza from the Netherlands because the postal code system didn't match up...).

[bjohas]

@tomhughes I acknowledge that, thank you - maybe we can discuss this in person at some stage, which I guess would be more productive! Thanks for publishing the branch - it works very nicely, and as advertised. I'll leave other people to explore it too.

[woodpeck]

Great, let's just keep @tomhughes' branch live at https://tomh.apis.dev.openstreetmap.org/ where everyone who wants/needs OLC can use it and we're done. Anyone who has an actual use case for wanting/needing OLC will be happy. Those still not happy would be only those who are not primarily interested in being able to use OLC, but interested in the OSMF providing OLC advocacy. That, in turn, is off-topic on this issue tracker and should be taken the the OSMF board.

[bjohas]

Hi @woodpeck. Thank you for your contribution. I do see that you are on the board. Could you possibly add your views to the wiki page, so that it can be discussed (I agree it's not for your issue tracker.) May I also say that I love your contributions to OSM and your engagement.

May I make a request? When you say "Those still not happy would be only those who are not primarily interested in being able to use OLC, but interested in the OSMF providing OLC advocacy." I feel misrepresented. I have tried to explain the reasons for implementing OLC (on the main site) on the wiki page, I would request that you take those statements at face value, and that you do not interpret these negatively or ascribe some kind of ulterior motive. The OSMF code says "OSM is powered by its Community. Engage positively with the Community, be a good and respectful neighbour and assume good intent. " I would also ask you to assume good intent regarding my actions and contributions. If you feel there is something here to be discussed with the board, please do message me, and I will be happy to do so.

[sfkeller]

Great, let's just keep @tomhughes' branch live at https://tomh.apis.dev.openstreetmap.org/

The https://tomh.apis.dev.openstreetmap.org/ gives 500 "Internal Server Error".

[tomhughes]

Well that site has likely been changed multiple times since then anyway - it's a test site which regularly changes when I have something for people to test.

[LaPingvino]

Okay, by now real actively used addresses are not supported by OSM because of lack of OLC support: https://www.addressingtheunaddressed.org/ uses OLC (full code with 4 digit precision after the +) for slum addressing in India (according to their website they moved from their own Go Code system inspired by Irish geocodes to OLC in the very year this issue was opened). As they use only long form codes, they are extremely easy to implement and don't need any Nominatim support. Short codes is harder to implement but could be deferred especially for this case.

Suggestion for supporting short codes would be using the current location on the map as reference point, and if a specifier is given after it, ignore the short code in Nominatim parsing at first, then go to the short code from the place the user picked.

[bjohas]

I'd still be very much in favour of this proposal. Cabo Verde has also adopted OLC as the official addressing system.

[tomhughes]

Sure, and what.three.words has persuaded various places to adopt them. How many of these systems are we going to be expect to adopt exactly?

[tomhughes]

Also I'm not sure setting up a promotional website proves "active use" in any way - if I went there and asked somebody on the ground their address what are the chances that would give me an OLC in answer? If wrote the OLC on a letter would it reach them? That would be real active use...

[LaPingvino]

The postal service there seems to support it, as their video in collaboration with Google shows. I can try getting a letter to them using their address, which is a Plus Code as well, and have them take a picture and add it here to have proof of that? Also probably a good idea to test with some people from the slums as well, to avoid bias by being a well-known organization.

The what.three.words use cases are definitely interesting, but I'm pretty sure you cannot legally adopt that in OSM because of licensing issues. Otherwise I think that when it's actively in use, it would make sense to implement it. OLC is already supported by a fair share of systems, most of them actually using OSM maps.

The one other system that would probably make sense to implement is Eirecode because they actually use it for addressing there. My rule would be: if people actually use it for addressing, OSM should support it. Google actually recently added support for plus codes to their address autofill system, so many websites will support them for addressing now by default.

[LaPingvino]

I sent a letter, should be there in 4 to 10 days according to pingen.com from where I sent it, using the normal India postal service.

[LaPingvino]

Letter received OLC.zip

[dpriskorn]

@LaPingvino The file in the zip has no permissions.

Anyway here is the contents: From: Alex Pigot To: Joop CC: ATU Ireland Subject: Letter received Date: Mon, 17 Aug 2020 14:25:23 +0000 Dear Joop, We have received your letter below at our office in Kolkata, thank you. To answer your query, as far as we know the codes are never used by postal = authorities as the 'only option' to deliver the mail. However they are used= to identify the correct dwelling in an area. For logistics companies and those who wish to find a dwelling the code can = be used with Google Maps satnav systems to provide turn by turn directions = through slum lanes If you wish to open up a discussion further please to make contact. And of course we will provide you with names of slum dwellers who would lik= e to receive your letter as proof the system exists - please can you tell m= e how many names you would like us to get for you. Thank you for your interest. With kind regards, Alex. PS I am copying our project manager Subhashis Nath in this email also. Alex Pigot CEO, Addressing the Unaddressed +353 87 2486665<tel:087%20248%206665> | +91 98743 97770<tel:+91%2098743%209= 7770> | | www.addressingtheunaddressed.orghttp://www.addressi= ngtheunaddressed.org/ Addressing the Unaddressed, T8 Maple Avenue Stillorgan Industrial Park Blac= krock Co Dublin A94 RT20 Ireland Addressing the Unaddressed (India), 7MJCG9C5+QVFFhttps://goo.gl/maps/UqVkF= gBLsys, Ground Floor, 14 Panditiya Terrace, Kolkata, 700029, West Bengal, = India

[dpriskorn]

Is it not possible for anyone to set up a website similar to openstreetmap.org that supports OLC? I'm thinking something like the very nice https://findvej.dk/Nybrogade2,1203 by Peter Brodersen where you can type the OLC directly like e.g. osmolc.xx/6PH57VP3+PR6 A well working website like that would suit the need, but alleviate having your community support it before it (perhaps) reaches a critical mass.

[LaPingvino]

OsmAND, mapy.cz etc already support it -- it's definitely something that is being used with OSM already.

[simonpoole]

OsmAND, mapy.cz etc already support it -- it's definitely something that is being used with OSM already.

Well Vespucci supports it too, but that doesn't actually mean anybody uses it. If you have ever actually tried to use one, you know why.

[LaPingvino]

I created a tool https://whenwhere.cf to use them as a prototype / proof of concept for a simple hardware device for navigating with plus codes, and this is the exact tool used with a friend in Africa to map his village. Easy access to plus codes can make a huge difference. I also used plus codes recently with a pick up in Kiev. When I suggested a guy to use it with the taxi he waited for he said "I know, I already use that". They are way more used than you would suspect. I am now working on making it easier to use short codes too without overusing Nominatim, will probably add that to my olc-tools repository when done.

Joop Kiefte - Chat @ Spike [r09pz]

On October 29, 2020 at 23:10 GMT, Simon Poole notifications@github.com wrote:

OsmAND, mapy.cz etc already support it -- it's definitely something that is being used with OSM already.

Well Vespucci supports it too, but that doesn't actually mean anybody uses it. If you have ever actually tried to use one, you know why.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[sinanisler]

I think devs are paranoid JUST BECAUSE Google made this feature and they are opposing it. Even it is Apache-licensed...

TBH I don't like google either they killed hundreds of useful projects just because it is not making money.

But Open Location Data will help people WHY to PUNISH people for Google's unrelated mistakes.

[jpds]

I received a plus code from a friend the other day, and I was surprised when nothing was returned on osm.org for it...

Fortunately, Organic Maps found it within seconds.

[wmbr]

Since OLC codes are easily recognized by the + character, this feature seems unlikely to have any (negative) effects on people who do not search for OLC codes. And obviously it is a big improvement for people who do search for OLC codes.

Also the plus_codes ruby gem is pretty minimal, self-contained, and stable, so the technical debt incurred is rather small.

Given these these two points I don't really understand the resistance this proposal apparently still faces.

[LaPingvino]

https://risingsunlenasia.co.za/82542/thembelihle-informal-settlement-gets-digital-addresses/

The last years, the number of locations officially using Plus Codes as addresses is rising steadily, and rightfully so. At this point not supporting OLC on osm.org while osmand etc already support it is willingly denying people to pinpoint their official addresses in a project that aims exactly the contrary.

At this point also the original question "how is this different" is definitely answered: others are codes, these are addresses. For real. In wide use.

[jguthrie100]

I'm currently on holiday in Nepal, and plus codes are used everywhere

[gjvnq]

So... How are things going? Like, what we need to do/vote/discuss before it OLCs/pluscodes can be put into production?

Also, I feel like plus+codes in OSM could be really useful for college students in Brazil as many times we schedule meetings or hangouts in open areas without official names. So having a way to specify them without having to add lots of place nicknames to OSM would be really useful. (as for why not just using google maps the answer is simple: OSM has far far more detail and data about brazilian unis than google maps)

[LaPingvino]

@gjvnq Coming month Geoapify should be handling plus codes to their geolocation API, which means that Mapcarta, an OSM powered web app should support it too. This means basically every OSM usage around except osm.org will be on board. OpenStreetMaps by now is massively used with Plus Codes, just not this frontend. I think the biggest reason for that is a lack of support by Nominatim. I would recommend people in this thread to focus on whatever we can do to add support to Nominatim instead, because for short codes some self-reference is kinda necessary. Native support in Nominatim basically automatically would add support for osm.org too.

I thank @tomhughes wholeheartedly for his positive contributions to Open Source and Open Standards and the purpose of this project. This thread is a testament to his values.

[LaPingvino]

Ah, reading back it seems like in the end @simonpoole was blocking this. Maybe give this a 👍 and we can all move on, @simonpoole ? Are there any counter-arguments left?

[woodpeck]

I remain concerned about the fact that there seems to be a small group of people here who are not otherwise interested in OSM-website development but who argue fervently in favour of OLC support. Their aim doesn't seem to be making OSM better but enhancing OLC adoption. From where I stand, OLC is very far away from being so commonplace that supporting it would make sense from a usability point of view; the only reason why we would want to support it is if we as a project wanted to throw our weight behind it and say "yes, that's a cool thing and we support it". Reaching that decision as a project, however, is not something that will happen in a GitHub thread. I disagree with @LaPingvino's framing this as a single person "blocking" us all from "moving on".

[simonpoole]

Ah, reading back it seems like in the end @simonpoole was blocking this. Maybe give this a 👍 and we can all move on, @simonpoole ? Are there any counter-arguments left?

Outside of pointing out that plus codes suck big time from a usability pov I don't believe I've really made any comment. matter of fact I pointed out that I have added support in the mobile app I maintain. From my POV the proponents of supporting plus codes on osm.org just haven't made a very good case up to now.

• What is the actual use case for providing "support" (I hope everybody realises that you don't "search" for the codes) outside of product marketing? A lot of things have been mentioned but none of them seem to have anything to do with the website.
• How do the proponents propose to handle the potential inconsistencies between short form plus codes resolved with google geocoding and those resolved with OSM based geocoding?

[LaPingvino]

I am an OSM contributor and it actively hurts my work with my African friends in the field that this support is not there. I beg to differ and request you to retract your accusations @woodpeck . Also my practical experience is that much more people use it every day than is visible from a western perspective where good addressing is commonplace. As an Esperanto speaker, a language which wide usage is also mostly invisible, I usually refer to the example of Chinese, literally the largest language around but in many places you might barely if ever see it, because it's not relevant to an English speaker. @bjohas requested this because of work from the field where this is the case and this is a long standing pain point for our work with people with sub-par addressing.

This is an ignorance issue that actively hurts people. Also I have actively added places to OSM using workarounds to make it work (I have a toolkit on my GitHub). This is not a cool thing issue, this is a filling the gaps issue. OLC works for when nothing else is available and at the moment the only thing we do have for that is literally typing in GPS coordinates with all their complications, e.g. lack of inclusion of precision.

I can accept your point of view that you think this is an issue in the way you describe it, but I respectfully disagree with it and I state my opinion here to make it clear that this is far from the majority opinion, so that this may be known and taken into account.

Also I made a tool myself for offline mapless navigation which I can use to document things in the field for OSM editing (and this is how Tchankada in Benin has been documented, and my friends use this daily there). For OSM.org it makes a lot of sense even from the simple perspective of having a more reliable shorthand for GPS coordinates to aid editing, and even without support I am already using that.

[LaPingvino]

@simonpoole

(I hope everybody realises that you don't "search" for the codes)

That is exactly how I use it and why the lack of support hurts me

*How do the proponents propose to handle the potential inconsistencies between short form plus codes resolved with google geocoding and those resolved with OSM based geocoding?

Plus Codes work with a reference point and do NOT rely on black box resolving of any exact point. If you are in the area of the precision of the short code, it always resolves to exactly the same place even if it resolves way off. This is part of the design of the system. Happy to explain this over and over again to more people, because this misunderstanding has been creeping in for ages. Taking any nominatim reference location (you could list the reference locations the same way as is done now in case of ambiguity) is perfectly fine and doesn't create discrepancies by design.

[simonpoole]

Plus Codes work with a reference point and do NOT rely on black box resolving of any exact point. If you are in the area of the precision of the short code, it always resolves to exactly the same place even if it resolves way off.

"Way off" is < 40 km which will essentially always be OK if whatever is being used as the context geocodes to the same entity in google and OSM, But I'm talking about the cases in which it doesn't (think about all the Londons out there) and yes providing a selection of the geocoding results could partially address that.

[LaPingvino]

Google already has this specific issue against its own geocoder, I have seen cases where the proposed Plus Code actually didn't resolve correctly (I think this has since been solved, I sent in a bug report). Which doubly confirms it's not a black box at all, it's mostly a garbage in, garbage out thing for reference points. Google doesn't have any specific systems in place to maintain consistentcy, it literally uses the same open source algorithm, and I think in some cases they improved their geocoder based on Plus Code issues. Too big reference locations are likely to be wrong always. Also I think this might be helpful to figure out issues with geocoding on the OSM.org site as well, just an added bonus.

Sorry for the big words thrown around and thanks for the meaningful discourse.

[sommerluk]

I remain concerned about the fact that there seems to be a small group of people here who are not otherwise interested in OSM-website development but who argue fervently in favour of OLC support.

If only those involved in actual code development for the website were allowed to participate in discussions, a public issue tracker wouldn't be necessary. Personally, I have a genuine interest in OSM, even though I don't specifically engage in website coding.

From where I stand, OLC is very far away from being so commonplace that supporting it would make sense from a usability point of view

As @LaPingvino has aptly explained, this greatly depends on one's geographical location. In regions like Europe or North America, it is common to have addresses that people use for searching places. In contrast, in other continents like Africa, the situation is different. With the absence of widespread address systems, alternative methods are needed to search for locations. OpenLocationCode, despite its flaws, offers significant advantages over pure coordinates:

• No concerns about the order of latitude and longitude.
• No need to worry about which decimal separator (comma or full stop) to use.

These two points are in day-to-day practice very important advantages. In Africa, in the past often places where describes like "in this suburb, search this quarter, search the big Pharmacy with this or this name, go down the road, take the second road at the left, …". Currently, more formal organizations start to use coordinates instead of these descriptions, and OpenLocationCode is in practice a way to communicate coordinates much easier and less error-prone than writing them down as pure coordinates. It is being increasingly adopted.

I believe that the website should not be exclusively tailored to the needs of residents in Western countries. Instead, it should take into account the Global South on an equal level of consideration.

[bjohas]

I believe that the website should not be exclusively tailored to the needs of residents in Western countries. Instead, it should take into account the Global South on an equal level of consideration.

We're using OpenLocationCodes, e.g., to collect locations for rural health centres in central/northern Zambia. We're using OpenLocationCodes because of the higher usability, e.g., being easy to read out and write down when there's no connectivity. Many location tools were hard to use because of the circumstances, and we developed an application that supports users with limited digital skills to collect accurate locations (https://github.com/OpenDevEd/SharePlusCode). Yes, we can translate those to lat/lon, but in difficult circumstances, such small factors make or break progress. Similar to what others have described, it would make the lives of the people involved easier if OpenStreetMap supported OpenLocationCodes (even if that was only full-length codes). In a small way, this would support people where we work with better access to healthcare.

I understand that different people have different priorities and perceptions.

I'm a long-term contributor and user of OpenStreetMap, contributing both in the North and South. OLC would make OpenStreetMap more accessible to those people where OpenLocationCodes are used for addressing, particularly in the Global South. For where I stand, it's a shame that this perspective is not shared by the people that are empowered to make that change, and I deeply regret that seems to be such fervent opposition to including what is quite a simple open algorithm (for full length codes).

[LaPingvino]

https://www.yesmagazine.org/social-justice/2023/08/25/navajo-nation-addresses