openstreetmap-website
openstreetmap-website copied to clipboard
openstreetmap
Add OpenLocationCode to OSM website
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.
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 [email protected]:
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.
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.
[@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.
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 https://github.com/tomhughes/openstreetmap-website/commit/2e0a2c67caf64df732f1e14160d5ead96c73a656 I tested on osm.org and it did not work.
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. 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?
@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?
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.
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.
The tickets relating to CoC are #1299 and #1300 so I suggest we don't discuss that further here.
@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.
@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.
@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.
@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.
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.