Openstreetmap-website: 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.

[tomhughes]

No, just no.

We've refused many such codes in the past and I don't see how this is any different.

[bjohas]

I agree that OSM cannot support every single code under the sun. However, I'd say it's different, because OLC is already supported by OSMAnd, on the roadmap for Maps.Me (AFAIK), and supported by Google Maps (website and app). So users may come to expect it. Plus it's really simple to implement, and (unlike many other codes) fully open.

[Firefishy]

I think OpenStreetMap.org search should support PlusCodes. To be more blunt, we should actively try support these Open schemes to reduce the value of the closed/commercial alternatives.

@tomhughes OK if we re-open this ticket?

[openstreetmap-website]

That is all fine and dandy, but not the OSMFs remit. And even if it was, then why start with a not really important service? Obviously we should start with putting all commercial map tile services out of business.

Am 30. September 2018 23:03:19 MESZ schrieb Grant [e-mail]:

I think OpenStreetMap.org search should support PlusCodes. To be more
blunt, we should actively try support these Open schemes to reduce the
value of the close commercial alternatives.

@tomhughes OK if we re-open this ticket?

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/1807#issuecomment-425751867

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.

[Firefishy]

Obviously we should start with putting all commercial map tile services out of business.

I should have been clearer, I believe that location data (address, coordinates) should fundamentally be open and it is morally objectionable for a company to try close them up for commercial advantage.

[systemed]

[@simonpoole] That is all fine and dandy, but not the OSMFs remit.

It is absolutely OSM's remit (remember, OSMF supports but doesn't control ;) ). OSM's mission statement since about day three has been that "most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways". Smashing legal and technical restrictions on geodata is what we're here for.

[simonpoole]

Well that's why I explicitly wrote "OSMF", obviously individual projects can do whatever they want.

And yes there's a Vespucci feature branch that has some plus code support and actually using them would tend to indicate that they are the pits to enter and to memorize.

[pangoSE]

Is this implemented yet? Seems so according to https://github.com/tomhughes/openstreetmap-website/commit/2e0a2c67caf64df732f1e14160d5ead96c73a656
I tested on osm.org and it did not work.

[tomhughes]

If it was implemented then this would be closed, not open.

I have not merged it because there is no community consensus on whether it is a good idea.

[pangoSE]

Anyone besides Simon Poole still against?

@simonpoole I honestly do not understand all this "holding back culture" that seems to surround the government of openstreetmap.org both when it comes to integrate useful mapper-tools and as in this issue useful geocoders.
The arguments from you in this issue seem to stem from fear. Is this correct? Can you help me understand this?

I have yet to hear any reports of openstreetmap.org affecting anyone negatively. Actually the lack of integration with the rest of the OSM-tooling ecosystem is as I see it the biggest hurdle to succesful evolution of OSM and the main website. This seems to lead to fragmentation, duplication of effort, confusion for newcomers, lack of good Quality Assurance, etc.

I would be surprised if nobody has raised this as an issue before. Maybe someone can point me in a direction of serious discussion of this somewhere?

[simonpoole]

@pangoSE I don't quite see what all those points have to do with the issue at hand.

Essentially the question is solely if plus codes are something that is useful in real life outside of google pushing for their adoption for competitive reasons. Pointing out that other projects have succumbed to the same pressure doesn't really help in objectively determining that.

[vincentdephily]

Small usecase and wishful thinking here, but looking back a few years ago Ireland introduced "Eircode" as a postcode system. It has a scandal-level amount of issues but the citizen campaign for better solutions didn't succeed. If one of the Free geocoding schemes was more established at the time, it would have helped the campaign. OLC isn't my technical favorite, but AFAICT it's the one that has the most support. The more support it gets, the more I'll be able to use it as an Eircode alternative.

[lgommans]

Coordinates are digits with a decimal separator, something everyone works with on a daily basis, even if only on supermarket's price tags. Everyone understands it, some can even estimate locations with them. It's supported by everything that has anything remotely to do with geographic locations. Basically, Google Plus Codes is asking to change digits into a base64-like format, with limited added value. The size decrease (the most obvious advantage) is almost negligible. The keyboard size you need on a touchscreen (numpad vs full keyboard with number row) adds as many typos as it reduces the length, and pronouncing numbers is unambiguous in all languages that I'm aware of. For letters, on the other hand, we made wordlists to be able to transmit them correctly (like the NATO alphabet). There is really limited advantage other than tying into Google's kingdom.

I'm not necessarily against converting them back into coordinates when a Google Maps user puts them into a search box, but if lots of people go "oh yeah, good idea, they claim to be easier for X" then the next step is to also start producing the codes in the share menu, and that's dangerous: we'd be compatible with google and some other, recently updated applications that might have implemented it. In contrast, the coordinate system is equally compatible with everything.

So I'll repeat that I am not necessarily against this little thing of converting plus codes back into coordinates when someone puts it in a search box. What I'm worried about is what the next step will be, and if we'd be promoting a proprietary platform by doing so. Yes, the codes themselves are open, but if the biggest promoter is Google... it's like Apple publishing specs for a new connector of theirs: sure, the connector is "open", but if a manufacturer starts making devices which use that connector, they are implicitly helping Apple. We should probably strive to be compatible with the 'connector' (accept such plugs) without manufacturing them ourselves.

[jguthrie100]

I was always under the impression that the entire open source ethos was to be as open and helpful to as many people as possible, be they farmers in Eritrea, salesmen in Singapore or archeologists in Texas.

Not including various systems that are (or may in future be) in common use seems to be driven more out of spite than in trying to be a tool that everyone can freely use.

After all, the login screen includes loads of OAuth 'partners', including Facebook etc, so couldn't it be argued that by including those login systems, we're encouraging the use of proprietary systems too?

[vgeorge]

If you need a use case for OpenLocationCode, the Brazilian community is trying to help municipalities to create rural addresses databases and using an open geocode format seems the way to go.

It was already tried to create local geocoding systems (see GPS Caipira, in Portuguese) but they lack integration with different software platforms.

It would be really helpful if OpenStreetMap site supported URLs with OpenLocationCodes so we could direct OLC users to OSM instead of a proprietary map.

[baerbock]

@jguthrie100 Your argument is a red herring. If everybody could enforce that his private tags gets rendered, that the webpage must include his private tool OSM would be unusable for the 99 %.

Maintainers, stay strong and keep out any private codes!

[bjohas]

I’d still love to see OLC-enabled search. I understand people’s concerns. However, in our projects we are usng OLC to make a difference to people of all ages in otherwise disadvantaged regions; it’s painful for me to see the resistance to a technology that’s open and helpful. While it’s originated from an employee at google (after careful review of existing systems, see OLC docs), it doesn’t seem to be something that’s google branded. If it were proprietary or hard to implement or likely to change over and over, sure, that’s a different matter. This is simple, open and helpful; it offers an additional way to access OSM and doesn’t take anything away from how others may want to use OSM.

Given that a brach with OLC already exists, could the case for OLC inclusion be revisited?

[LaPingvino]

Maintainers, stay strong and keep out any private codes!

I fully agree. That's why OLC support is such a big thing: it's solving real issues right now and is more free than many CC projects. Also, it's THE addressing system used for the 90% in Cabo Verde that don't have a street address, so to accurately implement addresses there you would at least have to implement OLC for Cabo Verde. I spoke lately with people on a Dutch train station that come from Cabo Verde and it's a huge thing there to have OLC for their shipments. It's a short stretch from there to implement it for the world.

[woodpeck]

This whole discussion is getting out of hand. Setting up a web site that lets you enter an Open Location Code and then shows the OSM map of the place is an exercise of half an hour of coding, if that. Nobody needs a change in the OSM web site to do that. Any of the arguments above based on "OLC is good for humanity" or "it would be great to be able to point people to non-proprietary web sites" is moot. Apparently this discussion has attracted people who don't know or care about OpenStreetMap, or the purpose and target audience of the OpenStreetMap web site. I don't see how anything useful can come of this discussion any more.

[bjohas]

So in principle OSM is a participatory space, right? So how can we make a participatory decision about this?

[vgeorge]

I suggest we open for voting somewhere to get a real sense of approval/disapproval of this feature. I fell more people like than dislike, but I don't think we can tell for sure just reading this thread. Do the maintainers agree with a wiki page for voting on this feature? Or suggest something else?

[tomhughes]

As I think I've already said whether or not we do something is not really a question of whether you can scare up enough sock puppets to vote "yes" on a feature.

Aside from the fact that designing any sort of software that way is a recipe for a disaster as everybody fights to get their favourite oddball feature in with no way that anybody can say "no" if they can win a vote how exactly do you propose to determine who is eligible to vote? and then to notify them that a vote is in progress?

A vote only makes sense if there is a defined electorate and a way of notifying them when a vote is in progress - otherwise it becomes a self selecting poll where the person who can persuade enough people to come and vote will win.

Normally in a software project that "electorate" is the set of maintainers/committers or similar. In this case that is quite a small set - basically @gravitystorm and me currently.

[Adamant36]

Sounds similar to the refusals to make the website more mobile friendly to me. Just like in that case, there's no reason why you can't walk and chew bubble by implementing OLC for people who want it. While at the same time having the site still appeal to users who "care about OpenStreetMap" are know about its "purpose" or are its "target audience" (whatever those things mean).

The same arguments could have made for implementing the ability to search for addresses on the same site. The maintainers are just choosing to be stubborn about it, just because they don't see anything "useful" about it isn't an excuse to not implement it and it doesn't mean its not useful. Otherwise, Google and OsmAnd must have implemented it because they had nothing better to do with their time and didn't know jack about their audiences.

@woodpeck, ff you don't think something should be implemented, fine. Don't put it on other people for requesting a feature though. Especially with the useless attacks. Its unnecessarily hostile. You don't know jack about their motivations and the only "target audience" for OSM is whoever wants to contribute.

@tomhughes, I see you don't have a code of conduct in your main directory. You really should. So unproductive, judgmental comments like @woodpeck's either won't occur in the first place or be called out when spotted by people with authority. However you want to run your Github, its still ultimately a community project. So there should still be a basic level of acceptable discourse everyone should follow here, which should be made explicit. It is everywhere else that's related to OSM and it should be here also.

[tomhughes]

There is a ticket somewhere about a code of conduct - there was once again no agreement on what exactly it should be as I recall. That and it's not clear who would deal with complaints as the set of maintainers is so small.

Not sure what you mean about searching for addresses - all our searches are passed through our nominatim instance which is able to search for addresses. Sure it's a bit picky about the format but that requires somebody to improve it - nobody is stopping it being improved to my knowledge.

[tomhughes]

The tickets relating to CoC are #1299 and #1300 so I suggest we don't discuss that further here.

[systemed]

@Adamant36, I’m pretty sure one of the first things any half-decent CoC would do is stop repeated hostile accusations like “You don’t know jack”.

Unsubscribing because I can do without more muppets in my mailbox.

[woodpeck]

@Adamant36, most people who are skeptical of any sort of code of conduct fear that besides being used to call out racism, sexism and other obviously bigoted behaviour, it would also be used to stifle discussion by attempting to clad everything in cotton balls of politeness, which is exactly what you're trying to do with me here. Of course my statements express (my personal) judgement about this discussion, how would they not - namely that this discussion has attracted a large number of people who haven't ever appeared in any discussion about any feature in OSM, and suddenly they clamour for a right to "participate" in what feature are added to the OSM web site. OSM is participatory in that everyone can add data to the map, but not in that everyone can add their favourite code snippets to the web site.

The part of my message that you chose to ignore is that it is trivial to create a web site that supports OLC and uses an OSM map, and that therefore anyone who claims that adding OLC to the OSM web site was necessary in order to be able to (more easily) use OLC in their aid project of choice obviously has misunderstood what this is about. But hey, that's the nice thing about codes of conduct, right, once you find an opportunity to brand someone as "judgemental and unproductive" and making "useless attacks" you don't have to deal with their argument any more.

The audiences of OsmAnd and the Google web site are different from that of the OpenStreetMap web site. OpenStreetMap is not primarily an end-user facing web site.

[bjohas]

@woodpeck "OpenStreetMap is not primarily an end-user facing web site." - could you say where that comes from?

https://wiki.osmfoundation.org/wiki/Mission_Statement states these two things:

• We want OSM data to be used as widely as possible.
• OSM wants you to map the things you care about and will ensure that you have the freedom to do so. This safeguards the accessibility of our map to diverse users with differing needs.

Wouldn't the first of these not also include making data available via the website? Or does 'as widely as possible' mean only to other developers?

These are genuine questions - not trying to be annoying or argumentative.

[vgeorge]

@tomhughes You said above you wanted to confirm if there was consensus about the idea, my suggestion was to find a way better to achieve this than to read this thread, which I don't think give a good picture about it. I'm fine with anything you find useful.

[tomhughes]

Well that's the problem - we would like consensus but we don't have a way to get it. Inviting people to vote on a wiki is no different to inviting them to comment here though and neither really works because both are self selecting.

[bjohas]

@tomhughes - though that's similar for proposing tagging schemes? The people that care about it will comment, and those that don't care do not comment (and can be assumed to be ok with it, as long as it doesn't break a fundamental aspect of OSM, such as open licensing). We could email the relevant OSM lists, so people have fair notice?

_(By way of a signature to this message "OSM is powered by its Community. Engage positively with the Community, be a good and respectful neighbour and assume good intent." https://wiki.osmfoundation.org/wiki/Mission_Statement)_

[gravitystorm]

there's no reason why you can't walk and chew bubble

The maintainers are just choosing to be stubborn about it

@Adamant36 I don't appreciate snarky comments like this, and they have no place in this community. Please consider this as a warning to change the tone of your comments.

[bjohas]

@tomhughes, @gravitystorm - as the maintainers for this, I assume that you're not happy to implement the proposal, given the degree of discussion. What would you need to be comfortable to implement the change? For example, I could follow the https://wiki.openstreetmap.org/wiki/Proposal_process. This would allow people to offer (rational) arguments as to why OLC in the OSM search may be good or may be bad. The 'community' could be then notified (via mailing list) that this proposal is active, allowing a wider range of people to voice opinions?

(Edit: Just to reiterate, I don't have a specific mission to push OLC or not. OLC solves a practical problem in my work, and from my perspective - including my perspective as a contributor to OSM - I think the feature is worth having. I'd be happy to make that case, so that other people can agree or disagree.)

_("OSM is powered by its Community. Engage positively with the Community, be a good and respectful neighbour and assume good intent." https://wiki.osmfoundation.org/wiki/Mission_Statement)_

[gravitystorm]

Normally in a software project that "electorate" is the set of maintainers/committers or similar. In this case that is quite a small set - basically @gravitystorm and me currently.

I just want to re-iterate this point. In common with most software development projects, final decisions are made by the maintainers, since we are responsible for this project. In most cases we're happy to make the decisions ourselves, but in other cases we ask for additional input from other people to help us make better decisions. And usually there is then consensus about the best way forward, but the final decision always rests with the maintainers. In some circumstances a vote could be useful information to help us make a decision, but any voting would always be advisory (and I don't think that's what some people expect).

My preference, however, would be to listen to peoples discussions, and make a decision based on the reasoning. With a vote, I have no idea why people vote one way or another, and how much understanding of the pros and cons each person has and whether they've weighed it up in the same way that I would. (Or whether they ignore things like code maintenance, ongoing support and refactoring etc, since that's the kind of thing maintainers worry about more than people who are not actually developing).

I feel more people like than dislike, but I don't think we can tell for sure just reading this thread.

Or suggest something else?

Yes, unfortunately threads like this drift off topic, and don't help with coming to a conclusion.

My suggestion would be either:

• Create a document of some kind (whether that's a blog post, or a few paragraphs of a gist, or whatever) that can be worked on to summarise both sides of the discussion. I don't want to spend time reading just one sided stuff though, there's plenty of that already.

or

• We can park this for a period of time, and see whether the context has changed in the future.

or

• Anything else that you think will push the discussion forward, and help us make a decision.

[gravitystorm]

@tomhughes, @gravitystorm - as the maintainers for this, I assume that you're not happy to implement the proposal, given the degree of discussion.

From my point of view:

• I don't like arguments and this has already become one, so I've been avoiding it.
• I only have a limited amount of time to spend working on openstreetmap-website, and most of that goes into other tasks. Between my own goals for the project, 300+ other issues and 40+ pull requests, it's easy to de-prioritise this one.

But I haven't made any decisions on this proposal - it's not like I secretly disapprove and am hoping it goes away, I just have been working on other things.

[bjohas]

Many thanks all. I've started a page here: https://wiki.openstreetmap.org/wiki/Proposal_Open_Location_Code. Please contribute!

[mmd-osm]

By the way, the upcoming FOSSGIS conference in March 2019 has a talk on this topic: https://pretalx.com/fossgis2019/talk/DRPBMB/ - "What are all those funny addressing schemes? Who is using them, and does the world need them at all?"

Besides OpenLocationCode there's even more out there, like Mapcode, created by a non-profit in the Netherlands. I guess they will be the next asking to be included on OSM.

I don't know the speaker, but @woodpeck probably does so. Might be interesting to get further feedback from someone with a bigger picture of the topic.

[ppKrauss]

Hi, seems the problem is not about latitude/longitude encoding technology only... There are a lot of good ones: OpenLocationCode (not the better), Geohash (why OSM never used?), S2geometry (the better!), ...

The problem is the shortening-codes techonology that is a black-box maintained by Google:

• how to decide that some city name is limited or not to rectangular area that is not a complete cover? Example: a building in the municipality of Altamira (PA) in Brazil is at location QQVJ+6F, a short code of six digits... But other location of Altamira are not, 6889CW6G+6X, 68588VMH+W2, ... And have no naming schema to shortening 90% of Altamira's big area, because there are no Google interest in the region... Is a sovereignty question.

• how to fix an "official cover" or "official prefix" for a location? The main "technology" is to replace prefixes by coverings, changing the original grid codes... There are a group here discussing coverings?

Seems that if OSM community whant to maintain a good technology, need to maintain a governance schema to (legitimes/sovereign local) decisions.

[bjohas]

Hi @ppKrauss,

"The problem is the shortening-codes technology that is a black-box maintained by Google".

My interpretation of the link https://github.com/google/open-location-code/wiki/Guidance-for-shortening-codes is different. I interpret it as follows:

Anybody is free to pick a reference point and shorten the code accordingly. There isn't just one "right reference point" for shortening the code. So instead of 6889CW6G+6X I could use "Quatro Bocas sandwich shop, Altamira, Brazil, CW6G+6X ". That's how we use the code: We pick a village as reference, and buildings then acquire short codes accordingly. The precise location of the village doesn't matter: as long as you don't stray too far, you can find the village (and the short code is the same, irrespective of reference point). To use shortcodes with google maps, sure I need to use points that google maps knows about. To use shortcodes with OSM, I can enter the POI that I care about (as long as that POI is genuine and map-worth of course), and then shorten the code accordingly.

This is not advice or a correction to your post: It's a different interpretation of https://github.com/google/open-location-code/wiki/Guidance-for-shortening-codes. If you post your comment to https://wiki.openstreetmap.org/wiki/Proposal_Open_Location_Code, then I can post my view as well!

[simonpoole]

@bjohas that would seem to be a (at this late date) surprise requirement for any implementation in an OSM context. Essentially you are requiring one way or the other that you always get the same geocoding result for whatever you are using for shortening (in your case assume that you had shortened with Altamira, Brazil that gives at least 5 more or less valid, but different, results when geo-coded with Nominatim).

[sommerluk]

The problem is the shortening-codes techonology that is a black-box maintained by Google:

The shortening-code isn’t a black-box. It’s something that’s documentated. It’s however something that relies on some sort of geocoding. In the OSM context, a natural choise for geocoding would be Nominatim.

It might be useful to focus on support only for non-shorted codes at the moment.

[bjohas]

@simonpoole - I'm not sure I fully understand. I'm adding a clarification to the wiki page, as to how I interpret short codes. (Edit: See here https://wiki.openstreetmap.org/wiki/Talk:Proposal_Open_Location_Code).

But - I wasn't advocating for short codes. Like @sommerluk also proposes, my original proposal was for long codes to be implemented. That would be really helpful.

[ppKrauss]

Hi!   Hum... There are interpretation problems... And I am new here... before to answer, some review:

Terminology

code or geocode or "location code" ... or "latitude/longitude hash"?

I am using the term "geocode" to designate the hashes and "geocode algorithm" to designate the hash functions: the recipes that converts latitude/longitude into a specific code convention... geocode is ok?

Sometimes a geocode can be used as postcode, see Correios de Cabo Verde using PlusCode and Ireland’s system using Eircode: they are good and modern because is not "only a postcode" (area code) but can be used as geocode of the point-of-interest... A big and long discussion make sense if we are imagining a far future where OSM can help to resolve free geocodes, replacing non-free-postcodes.

any good and free geocode to OSM website

Ideal is to prepare the shorter OSM.ORG domain as "name resolver", like Nominatim, but with simpler interface, only for pointing in the map or for JSON responses...

... This discussion started about an specific technology, the OpenLocationCode, but OSM can adopt any other one:

• http://osm.org/geo:{geoUriValue} ideal is to offer a resolver for the RFC 5870's strings, the free geo URI protocol.

• http://osm.org/olc/{olcCode} for original OpenLocationCode 8+N digits geocodes, without context.

• http://osm.org/ghs/{geohashCode} for original Geohash, without context. PostGIS, at OSM server, offers ST_PointFromGeoHash().

• ...

• http://osm.org/pluscode/{context}/{olcShortCode} for PlusCode-like short-OpenLocationCode, with 6+N digits geocodes. The context can be resolved by Nominatim... Ideal to use ISO_3166-2 standard instead free-text. Example: city of Altamira in Brazil is BR-PA-Altamira. There are an hierarchy names, and each name is the official jurisdiction for the next name. (e.g. BR is the jurisdiction for AM, etc. and PA). The supposed "good context" of PlusCode is not valid for some jurisdictions like BR, here we have two cities of "São Carlos", but "BR-SP-SaoCarlos" is unique in the hierarchy.
  Unlike Google, the OSM community can support the sovereign decisions of the jurisdictions.

• ....

So, for my personal vision, it makes sense (and is technically simple!), to implement not only (monopoly) OpenLocationCode, but also some other free and good solution to test other possibilities and compare efficiences (Geohash is base32, so is shoter tham OLC that is base20).

---

PS: there are a lot of other technologies, perhaps we need to select 2 or 3 to really test the OSM behaviour and the community demands... Example: what3words is proprietary, but is not impossible to create good alternatives.

[bjohas]

Hi @ppKrauss. Thanks - have added some more notes here https://wiki.openstreetmap.org/wiki/Talk:Proposal_Open_Location_Code# - happy to continue the discussion there!

[tomhughes]

People - this ticket is about one thing and one thing only... That is whether to support OLC in the search box.

It's not about other geohash systems.

It's not about generating OLCs, so shortening algorithms are not relevant as search can handle an OLC of any length without any confusion.

[Adamant36]

@gravitystorm, it seems a little wierd to reprimand someone for "snark" in a "community" that doesn't have a code of conduct. Plus, it seemed like that was how he was being. Its totally my bad though. I shouldn't have said it. I stand by my comments about Woodpeck dismissing people though and if I'm going to get a warning, he should get one also. Although, its your decision who gets warnings for their behavior or not and I still apologize for my side of it either way.

[ppKrauss]

Hi, answering each one by user and all by topic:

• @bjohas , thanks, as you investing time at Wiki, I will answer details and help at there.

• @sommerluk, thanks. About your assertion "shortening-code isn’t a black-box (...) that’s documentated", is a logic contradiction of your other assertion "relies on some sort of geocoding". Seems that you say "is a black-box". Is important a technical consensus here because (by my technical opinion) will be impossible Nomintatim to reproduce the Google's PlusCode behaviour... There are no algorithm to copy/paste (as OLC for global pluscodes) when resolving context for local pluscodes.
  PS: (re-@simonpoole) "wasn't advocating for short codes"... If there are a consensus about only global codes proposal here, is ok (and I change what seems my desagree to an explicit "YES I AGREE with this proposal!").

• @bjohas, thanks and ok, I am talking at wiki's talking page.

• @tomhughes, thanks, I upvoted. Sorry by all pollution here, was a "first contact" to check status of all details. Your summarization is important to all us here, to check consensus:
  "That is whether to support OLC in the search box".

• about "consensus of the issue", seems that whe must to review positions of each one after wiki page "Proposal Open Location Code" completed. So, seems that the main discussion is taking place at the wiki's talk page... After completed perhaps will be fine to vote/check positions about the well-defined proposal.

• about the perspective (big picture) of this proposal: "Why is relevant for openstreetmap?", seems that there no consensus about "how much important", but we need to reduce expectations. I not see any formal "relevance checking" at issues, so seems that we can agree and "play the boat" as little group, after some consensus.
  My personal view is that the OSM search engine need some "contextualizer tags", so PlusCodes (its code syntax) are only one of these, only the first to be implemented to check usage statistics in the OSM's search-box. The other candidates (other good code syntax standards) are
  geo:{approximateCoordinates} of RFC 5870 and iso:{countryAbbreviation} of ISO 3166-2... To discuss later in other issue.

[sommerluk]

@ppKrauss As far as I see, the official definition for OLC short codes

• works with a “nearest-reference-point” approach
• is intrinsic ambiguous to the same degree as the mentioned reference point is ambiguous (imagine you take “Springfield” as reference – there are quite a few of them on our planet).
• the official OLC definition is quite, well, vague. So you can use any geo-coder you like. And it’s on your own how this geo-coder interpretates city or country names. Particularly, to be in line with the OLC definition, it is not required to return the same results for geo-coded short codes as Google does for their own services. Results based on Nominatium would be as valid as results based on Googles geo-coding are.

OLC long codes however are unambigous.

[ppKrauss]

Hi @sommerluk , lets focus here on the search box as @tomhughes's post... More precisally, after some consensus, focus in the "search box with global pluscodes"
(see correct terminology and not be confuse with local pluscodes).

Lets use some concrete scenario on this focus.

searching Pronto Socorro Maria

All cities in Brasil have that first-words of name for an hospital with emergency department.

Plus.codes (after searching Pronto Socorro Maria) returns for me a map with center in geo:-23.51755,-46.64692 (=588MFCJC+XX), and Osm.org/search?query=Pronto+Socorro+Maria returns geo:-19.39847,-40.06149. In your computer perhaps return other thing... So,
why we need a pointer like PlusCode in a search box, if we use the box because we not have a pointer?

The main answer is: because, as you see, there are many possible responses for the same search string ("Pronto Socorro Maria" key-words this case), so when we add any reasonable pluscode into the search string (now will be something as "Pronto Socorro Maria 588MFCMC+68"), the result will be better, for all people, me and you, in all search-enginies (OSM or not), will return a map with center in geo:-23.51755,-46.64692.

---

PS: the focos is not to search "only the pluscode" in the box, with no other human-key-word. The OSM engine can response with an error "please add a query to find something near there".

---

@sommerluk , all your other comments are important for the discussion that we are transfered to the wiki talk-page... As you see, we need a precise definition about what we want in the search. The Wiki page is to define with precision what we want (or what is invalid for OSM).

[bjohas]

Hello all. As a proponent of OLC, but in the interest of fairness: There hasn't been much discussion on the disadvantages on the OSM wiki page https://wiki.openstreetmap.org/wiki/Proposal_Open_Location_Code or the corresponding talk pages. In the interest of balance, would those that feel strongly about not implementing OLC as described be able to contribute to the page? Many thanks.

[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

[egils-consulting]

@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
[phone] | [phone] 7770> | | www.addressingtheunaddressed.org ngtheunaddressed.org/>
Addressing the Unaddressed, T8 Maple Avenue Stillorgan Industrial Park Blac=
krock Co Dublin A94 RT20 Ireland
Addressing the Unaddressed (India), 7MJCG9C5+QVFF gBLsys>, Ground Floor, 14 Panditiya Terrace, Kolkata, 700029, West Bengal, =
India

[egils-consulting]

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 [e-mail] 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.