search

openstreetmap / openstreetmap-website

The Rails application that powers OpenStreetMap
https://www.openstreetmap.org/
GNU General Public License v2.0
2.16k stars 908 forks source link

Add OpenLocationCode to OSM website #1807

Open bjohas opened 6 years ago

bjohas commented 6 years ago

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 commented 6 years ago

No, just no.

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

bjohas commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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: https://github.com/openstreetmap/openstreetmap-website/issues/1807#issuecomment-425751867

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

Firefishy commented 5 years ago

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 commented 5 years ago

[@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

vgeorge commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

systemed commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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:

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:

or

or

gravitystorm commented 5 years ago

@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:

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 commented 5 years ago

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

mmd-osm commented 5 years ago

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 commented 5 years ago

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:

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

bjohas commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

sommerluk commented 5 years ago

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

OLC long codes however are unambigous.

ppKrauss commented 5 years ago

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 commented 5 years ago

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.