Proposal talk:Open Location Code

Older content here: Proposal talk:Open Location Code/archive.

Why is any of this relevant for openstreetmap.org?

Why would any of this be relevant for openstreetmap.org, given its target audience and the restrictions on use?

I propose to break this question up into the sub-questions Bjohas (talk) 16:50, 7 January 2019 (UTC)

Why is this relevant given the target audience of OSM?

@SimonPoole: - could you clarify who you see as the target audience of OSM?

Bjohas (talk) 17:00, 7 January 2019 (UTC): 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.

In light of this, I would say that:

• For our projects, OSM data will be used more if users can locate OSM data via plus codes.
• We care about education and school infrastructure in low-income countries (which are usually poorly mapped by commercial maps). We care about people having 'postcodes' that describes such infrastructure in contexts where road names and addresses often are not generally available. So we would like OSM to allow us to map those (which OSM already does), but recognising us as "diverse users with diverse needs", one of which includes the need to use (an open source algorithm, i.e. OLC) to locate objects in OSM, and to do so with a scheme that people find easy to use (e.g. shortcodes).

"We" here is some of the people I work and with, e.g. educators in Ghana http://bjohas.de/go/atlas2017 or the HOTOSM community.

Restriction of use: other

@SimonPoole: - could you add other restrictions of use that you consider relevant here?

Restriction of use: emergency services

Attempted summary of outcomes

The discussion below (in the opinion of Bjohas (talk)) has the following two outcomes

• It contravenes the OSM terms of use to promote OSM for emergency services.
• Therefore, the OSM lookup must not be used for emergency services (either by name, by lat/lon, postcode, plus code or another other means).
• However, the fact that certain search terms (name, by lat/lon, postcode, plus codes) could be used in contravention of the OSM terms to look up emergency services does not mean that specific search terms (or indeed search at all) cannot be implemented.
  • The technology affords the lookup of emergency services, i.e. there is no technological restriction on looking up emergency services. This makes sense, as it may be necessary to look up emergency service locations for non-emergency purposes (e.g. to map all trees in the vicinity of an emergency service location).
  • Instead, the restriction is at the "terms of use" level: The terms of use prohibit the lookup of emergency service locations for emergency purposes.
• As plus codes (just like lat/lon) are not used specifically to refer to emergency services, but are a general geocoding system, the terms of use do not bear on whether plus codes should be implemented or not.

Text added by Bjohas (talk). Please edit as needed, maintaining or improving the logical flow of arguments. Bjohas (talk) 14:44, 12 January 2019 (UTC)

Discussion

For example you list "for example for aid and emergency services" as a reason to support OLC on openstreetmap.org But not only is that clearly not the target audience, such use is explicitly not allowed https://wiki.osmfoundation.org/wiki/Terms_of_Use#III._Unlawful_and_other_unauthorized_uses

SimonPoole (talk) 11:14, 5 January 2019 (UTC)

Hi @SimonPoole: I see that Google Maps "monopoly" is a problem, and offering any OLC resolution service is a kind of contribution for Google PlusCode marketing, but I not see any juridic barrier... Can you list the all specific items of the link that you see as "explicitly not allowed"? --Krauss (talk) 08:34, 6 January 2019 (UTC)

About the item "Operate dangerous businesses such as emergency services (...) where the use or failure of the Services could lead to (...) personal injury or significant property damage", not make sense. A code detection in a search string service would never cause "personal injury or significant property damage". --Krauss (talk) 08:45, 6 January 2019 (UTC)

I hope you realize that your statement doesn't make any sense at all. Why would you be using OLC codes on OSM " for example for aid and emergency services. " for anything else than finding out where a location is (or is it the A&E equivalent of twiddling ones thumbs to enter random OLC codes?) and as a consequence a failure in the service of any kind would potentially lead to "personal injury ....". SimonPoole (talk) 23:29, 6 January 2019 (UTC)

@SimonPoole:, we have a communication problem... Perhaps English is the problem... Lets restart with illustrative concrete examples...
Scenary and example: suppose I am using the Service of OSM.ORG, the search box of the site (search box API search?query=x is a instance of The Service?)...
I am looking for the location of an emmergence service, and write in the box the string "Pronto Socorro Maria": of course the OSM.ORG site shows a location... Them I go there imagining that it is the Pronto Sorcorro Maria nearst my home — but is not, so cause me the lost of time, so cause the lost of my life with a heart attack.
Same as http://OSM.ORG/search?query=Pronto+Socorro+Maria
--Krauss (talk) 16:32, 7 January 2019 (UTC)

@Krauss: I think your example shows exactly the point that SimonPoole is making, and anyway it obviously contravenes the T&Cs provided by OSMF, so there is not room for discussion. SK53 (talk) 22:06, 11 January 2019 (UTC)

Hi @SK53: and @SimonPoole:, where is your suggestion for "room for discussion"?   And please, explain (there or here) why OSMF is offering a "contravening service" today at search box API? Test by yourself openstreetmap.org/search?query=pronto+socorro+-23.5,-46.65
... It is an Openstreetmap's search using indirectally a pluscode (588MG82X+2X after converted to LatLong -23.5,-46.65).

I think @SimonPoole meant that there is "no room for discussion", i.e. this is not a matter for discussion. Bjohas (talk) 14:32, 12 January 2019 (UTC)

Let me try to rephrase the 2nd question: What is the difference for searching for an emergency location by name, lat/lon or searching for it by plus code? I think @Krauss is right (if I understand correctly): None are not permitted. However, that's not to do with lat/lon vs. plus code. If plus code only pertained to emergency services (as a sort of "Global emergency services location code") then yes, it would contravene the rules. But as it's just a general location code, it's just the same as lat/lon: The user may use neither to search for emergency services. However, it's not an argument to not offer OLC, as lat/lon can be misused in just the same way. Bjohas (talk) 14:32, 12 January 2019 (UTC)

Also note that I have removed the misleading reference to emergency services from the main page of the proposal. Bjohas (talk) 14:32, 12 January 2019 (UTC)

Hi @Bjohas:, thanks, you translated (in bolds) my question with better English. But be careful, there is no consensus on the answer, I do not say "none are not permitted", my interpretation is that "all are permitted" because OSMF is not responsible for user actions.
The "contractual interpretation problem" is near to be solved, please check this thread on Github... My suggestion is open a votation-pull here to confirm our interpretation, avoiding risks to lost our time with a Stillbirth proposal --Krauss (talk) 12:03, 13 January 2019 (UTC)

The OSM Terms of Use specifically say that one cannot "Operate dangerous businesses such as emergency services or air traffic control". It does not forbid someone doing a search to find the location of a facility offering emergency services. It does not forbid someone using an encoding technique to identify a location that may or may not be a location where emergency services are provided. What is forbidden is 'operating a dangerous business' so OSM cannot be used by ambulance services to route and locate their paramedics, and some ATC facilities cannot start using OSM as a layer in their air traffic control systems and so on. To take that restriction that forbids direct employment of OSM by an organisation providing emergency services or any other hazardous activity, and extrapolate that to say that a character encoding scheme to assist with identifying locations readily because someone one day might use it to refer to the site of a hospital is... an extraordinary reach.

Suggesting edits

Two structural edits:

1. A Wiki page in general starts with an introduction before any section, the "lead section", so suggest to transform "Proposal in brief" in the lead section deleting its title. --> The issue is the placement of the TOC (which is different on wikipedia). I've amended the title. Bjohas (talk) 12:00, 8 January 2019 (UTC)
2. Add a section "Proposal in details" or "Technical details" to explain what it really is. It is not "name resolver" for something as www.osm.org/{PlusCode}, it is an internal complement for searching with codes, so a piece of sofware that detects pluscodes by its regular expressions, as formally defined at github/google/open-location-code/wiki/Supporting-OLC-in-your-app. added the last bit the main page. See other text there, and copy more as needed. Bjohas (talk) 12:00, 8 January 2019 (UTC)

The regular expression detection is based on the pluscode alphabet, "23456789CFGHJMPQRVWX", and the plus sign, "+", in some patterns that produce global codes, such as "796RWF8Q+WF", and local codes, such as "WF8Q+WF". So, we must also to talk about global and local: if local codes will be also detected and accepted (engine can detect only to warning "local codes are ignored"), there are a need for specify how to interpret pluscode-context and how to "plug" Nominatim to this task. Added to main page. Bjohas (talk) 11:41, 8 January 2019 (UTC)

Make sense? can I edit or you edit? --Krauss (talk) 08:22, 6 January 2019 (UTC)

Yes, please - do edit! The wiki is a public good, owned by you as much as me :) Bjohas (talk) 14:18, 7 January 2019 (UTC)

Advantages

Hi @Svensson: - I've reinstated the advantages. They are not generic to all codes, but OLC has been designed to meet all of these. Other codes only meet that list partially. I'll add those notes. Bjohas (talk) 11:41, 8 January 2019 (UTC)

Hi @Constantino: - thank you for the comment on the "Advantages" text (These must be advantages for OSM, not generic requirements for any location code.) I have clarified the headings now. I had intended to first state the advantages of OLC as such, while the advantages to OSM / users of OSM / maintaners come in the next section.

Could you and @Svensson: have a look as to whether you are happy for the text below to go back up? (Note that the text has been edited as requested by @Svensson: to read as full sentences). I would like to transfer the text again, as it has been raised (e.g. on github) why I'm promoting OLC (e.g. rather than other open codes or W3W etc). So I do feel it's important to state these advantages. Bjohas (talk) 18:42, 8 January 2019 (UTC)

Hello @Constantino: and @Svensson:! I'm now moving the text below back to the main page. I can't see that you've commented further, so I assume this is ok with you now? Bjohas (talk) 20:42, 11 January 2019 (UTC)

Implementing OLC as subtype of geo

There are a new proposal to implement pluscodes as (the most urgent and consensual) subtype of "any geocode", see git/openstreetmap-website/issues/2104. To avoid dilemas and gain community consensus, the suggestion is to implement it in 3 steps --Krauss (talk) 11:09, 9 January 2019 (UTC)

Thanks for suggesting this. It seems that the proposal has already been close. I think my preference would be to stay focussed on OLC for now, and get this implemented as a user-facing feature. Hope that's ok. Bjohas (talk) 11:21, 9 January 2019 (UTC)

@Bjohas: Hum... Yes, if you (and any other here) see that it make sense (for non-dictatorial decisions), please a upvote (thumb-up) at https://github.com/openstreetmap/openstreetmap-website/issues/2104#issuecomment-452670798

If you can't read latin characters, plus codes are obviously a poor choice.

@Mmd: raised this point: If you can't read latin characters, plus codes are obviously a poor choice.

There isn't a single universal character set, even numbers have different scripts. So there's simply no universal character set that could be used for a global system of codes. On [1], [2] says this in response to a similar question from [3]:

@simonpoole makes the good point that plus codes are based on latin characters. We were worried about this, so did some surveys with people in different script countries, and most of them made the point that @RobJN made - basically "umm, how do you think we type www.google.com?" We launched the codes in Maps on Android a year ago, and we see high usage in non-latin script countries (arabic, cyrillic, japanese etc). At the moment, our thoughts are that there is more to be gained by having a single, consistent script for the code part, but at least we can reconsider this in the future.

From my own experience, I would support this view. Bjohas (talk) 11:49, 12 January 2019 (UTC)

Makeshift solution for who needs it: a bookmarklet

I created a bookmarklet that can be found at https://github.com/LaPingvino/olc-tools/tree/master/osm-bookmarklet --LaPingvino (talk) 14:31, 30 March 2019 (UTC)

Replacement for "Shortlink"?

I see that this proposal (and the heated discussions on it) primarily stem from the discussions on GitHub issue to add Open Location Codes (now formally renamed as "Plus Codes", yes?) to the capabilities of the search bar. A separate use-case I was wondering about is for it to replace the Shortlink proprietary system, to make sharing links to specific map locations still able to be done in a concise format, but allow removing custom code and replacing it with standard; slimming down the codebase to focus on just the OSM logic and not need to also implement a custom geohashing/location-shortening function. Has that been considered at any point in this process? --Midnightlightning (talk) 05:55, 26 August 2023 (UTC)