Add OpenLocationCode to OSM website #1807
Comments
|
No, just no. We've refused many such codes in the past and I don't see how this is any different. |
|
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. |
|
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? |
|
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 <notifications@github.com>:
…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:
#1807 (comment)
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.
|
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. |
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. |
|
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. |
|
Is this implemented yet? Seems so according to tomhughes@2e0a2c6 |
|
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. |
|
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. 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? |
|
@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. |
|
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. |
|
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. |
|
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? |
|
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. |
|
@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! |
|
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? |
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. |
|
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. |
|
So in principle OSM is a participatory space, right? So how can we make a participatory decision about this? |
|
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? |
|
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. |
|
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. |
|
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. |
|
@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. |
|
I'd still be very much in favour of this proposal. Cabo Verde has also adopted OLC as the official addressing system. |
|
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? |
|
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... |
|
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. |
|
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 The file in the zip has no permissions. Anyway here is the contents: |
|
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 |
|
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. |
|
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](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=r09pz) [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](#1807 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAACQNVLEZVB6P5WHHYBJYLSNHY6DANCNFSM4EYPE4ZA).
|
|
I think devs are paranoid JUST BECAUSE Google made this feature and they are opposing it. 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. |
|
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. |
|
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. 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. |
|
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. |
|
I'm currently on holiday in Nepal, and plus codes are used everywhere |
|
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) |
|
@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. |
|
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? |
|
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". |
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.
|
|
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. |
That is exactly how I use it and why the lack of support hurts me
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. |
"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. |
|
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. |
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.
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:
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. |
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). |
and others
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.
The text was updated successfully, but these errors were encountered: