PlusCode als Tag

Voor het gebruik van unieke geolocatie gegevens maak ik veelvuldig gebruik van het zgn. Plus Codes systeem. Het betreft een opensource toepassing om een handzamer alternatief te bieden t.a.v. het meer ingeburgerde WGS84 model. Kijk voor meer details even op de site waar ik naar toe heb verwezen.

Bij de reeds gemaakte objecten, die gemaakt zijn mbv de welbekende punten, lijnen en vlakken, zou ik de unieke Plus Code-tag willen plaatsen zonder opnieuw nieuwe elementen te moeten maken. Mijns inziens zou de Plus Code bij uitstek geschikt zijn om dit als tag bij een op zich staande node te voegen. Bij een ā€˜wayā€™ zou dit kunnen worden gerealiseerd bij Ć©Ć©n van de points/nodeā€™s die deel uit maken van dit object.

Ik zou graag de zienswijze willen vernemen van de community in hoeverre de PlusCode als valide tag binnen OSM gehanteerd kan worden en waar deze binnen OSM (niet) gebruikt mag worden.

Indenpendent of your question: it has massive privacy issues to use that system. All queries go to Google, same as their ā€œsearchā€

Consider you, searching multiple times for the position of a cancer clinik using Plus-Code-System: Google knows, Google takes notice of that.

Plus Codes are calculated from coordinates. I see no reason to store them in OpenStreetMap.

6 Likes

PlusCodes zijn rechtstreeks afgeleid van de geolokatie, begrijp ik dat goed? Als dat klopt is het dubbelop om aan objekten in OSM ook nog een PlusCode toe te voegen, want de lokatie is in OSM immers al precies bekend. Als een toepassing de geolokatie in een PlusCode wil omzetten kan die dat altijd doen. Of is de methode afhankelijk van de organisatie Plus Codes?

Iets anders is als een huis een bordje heeft met daarop een PlusCode (of welke andere aanduiding dan ook) die als adres dient. Verifieerbaar dus. Dan kan dat ergens in de adresvelden opgenomen worden.

Er zijn meer van die systemen. Ik vond what3words erg leuk, maar ik geloof niet dat het erg aangeslagen is.

We had a presentation on plus codes at State of the Map 2017. As I understand it, the algorithm is freely available so you donā€™t need to send your search term to Google for then to return a result. We (OSM) could set up an instance so searches could come to us for better privacy.

2 Likes

No, they do not. My understanding is that plus codes can be converted to and from coordinates using an open and standardized algorithm. That is, they are specifically designed not to have this downside.

As such, Plus Codes are sometimes suggested as an open, privacy friendly alternative to user-hostile proprietary systems such as What3Words.

Of course, precisely because they are easily calculated from coordinates, there is no reason to add them to OpenStreetMap unless they are signposted/used as an address somewhere.

5 Likes

It would still be cool if the site had the ability to generate them if someone wanted to use PlusCodes for some reason. I can kind of see their use case as an easy way to do QA or something. Thereā€™s been several times where someone said a POI had moved but just gave vague directions to wherever it moved to. Although I guess they could have just provided a full URL to the location, but no is going to argue that a PlusCode wouldnā€™t be a lot easier to deal with. Probably more precise also. At least compared to ā€œ5 blocks south east from hereā€ or whatever, if not x/y coordinates.

1 Like

Plus codes (Open Location Codes) are just an abbreviated way of stating GPS coordinates. If the coordinates are stored another way then then storing plus codes as well is completely redundant.

This isnā€™t to say that we couldnā€™t support the coordinate format for searching or as an export format on the site, but they should not be stored separately in the database.

3 Likes

They are not an abbreviated way of stating GPS coordinates, they are references to a WGS84 based grid, that is not the same thing.

That said, the problem with these discussions is they are mainly fueled by people that have never actually used the codes as an address replacement (at least without being paid to do so for promotion purposes), because if they had they would know just how badly they suck and that a discussion is a waste of energy that would far better be invested elsewhere.

5 Likes

Eerlijk gezegd vind ik deze pluscodes ook niet erg handzaam.

Thatā€™s a bit unfair Simon. They work fine for me. Also going on how often I see W3W being used in the UK now (i.e regularly) companies and people clearly see value in these location systems even if you donā€™t. Iā€™d rather see Plus Codes than W3W hence I feel that OSM should be doing more* here.

*More: Allowing users to search for plus code locations. I agree 100% that there is no need to add them as tags into the OSM database.

2 Likes

Sure technically they work fine, they are just extremely painful to memorize and type, which is kind of contrary to the whole point of using something like them.

If google had been sincere about the whole matter they could have used one of the existing systems (which BTW all suffer from the same issues in the end), but as is, it was just an anti-competitive move against w3w (not that w3w should have succeed, but we need to call a spade a spade).

1 Like

When paired with a place name (i.e. the short version) then they are no longer then UK or Canadian postcodes.

Anyway our opinions are irrelevant - itā€™s what people do that matters. And I see location services actively being used. Too often thatā€™s a closed service. OSM stands for open alternatives so itā€™s my view we should do something here. Plus codes seems to be the open alternative with the most potential.

I draw parallels to Overture Maps here. As in, when we leave gaps others exploit them and might do it in a way that is bad (e.g. closed proprietary). Feel free to continue with the pesimism but donā€™t complain if proprietary solutions continue to grow and end up dominating in some use cases.

3 Likes

That however is more or less proprietary, that is the results of it depend on the geocoding engine you are using, or put differently you are only guaranteed consistent results if you use googles geocoding.

PS: UK and CDN postcodes are not really a high bar btw.

That said, the problem with these discussions is they are mainly fueled by people that have never actually used the codes as an address replacement (at least without being paid to do so for promotion purposes), because if they had they would know just how badly they suck and that a discussion is a waste of energy that would far better be invested elsewhere.

It wrong to state that Plus Codes ā€œsuckā€ without some comparative evidence. And regarding your suggestion that people are being paid to promote, Iā€™d argue that it more likely that people are being paid to attack Plus Codes so that the propriety what3words ends up being to default global geocode.

1 Like

As I pointed out all of them have issues, w3w in different ways than plus codes and mapcodes. But all have the property that they are totally unnecessary.

Hi All,
Thank you all for the replies on my initial question.
It seems to me a more ā€˜politicalā€™ OSM-issue aswel as a pragmatic thing. The arguments about privacy is for me a subject to agree or to disagree. May I give you in consideration to realize that you do supply many times a day a big part of your privacy already, have a look on the backside of your phone and you can read the company-name to whom you are giving all day long your private information. Do checkout your SIM-card / provider with whom and from what place you are calling.
Have you ever read the information how a mail message will arrive on its final destination? The privacy-issue is not only a problem of the big-tech industry but mostly it starts behind your own computer keyboard. How simple it is for 70% of the worldpopulation to do their communication via Meta or TicTocā€¦ privacy?

My idea to make use of the PlusCode is to give myself an option to give objects a unique ID in OSM and at the same time I can retrieve the location itself because of notation of this code. How simple it can be to have a Tag with a unique locationvalue. The more simple it is to make a query with this PlusCode as a selection-instrument. Keep in mind that this value can be used but there is no obligation at all to make use of it.

In my opinion, as someone who constantly uses PlusCode outside of the OSM environment, the proposal of the author of this post has 2 contradictory elements.
PlusCode is not a coordinate system itself, it is an encoding of an already established coordinate system.
It does not represent a point, it represents areas; the location precision of these areas is directly proportional to the number of digits present in the PlusCode.
While a decimal coordinate, ex: 5Ā°,-75Ā° accurately represents a point on the planet, a PlusCode (67Q70000+, 67Q72200+, 67Q72222+, 67Q72222+22, 67Q72222+2222,ā€¦) represents any point (within a area) near 5Ā°,-75Ā°.
More digits = more precision, Less digits = less precision.
I think that the approach to discourage the use of PlusCodes is not the correct one since it has drifted towards privacy.
Precision must be taken into account and whether an OSM mapper is willing to use the PlusCode API or a tool (app, web, software,ā€¦) to convert decimal coordinates to a PlusCode.
Under the assumption that a mapper is willing to use such tools and OSM implements PlusCode, it must be decided what is the minimum number of digits that the PlusCode must have to represent a coordinate with the minimum margin of error.
Regarding the polygon of a building, there would be no serious problems to link it to a PlusCode.
What happens if they are linked to the node of a way? (example proposed by the author of the post) and in later editions changes are made to that path (changes in the position of the nodes).
Who would correct the PlusCode to reflect the new position of that node?
Would OSM be willing to bind the PlusCode API so that it automatically reflects the position change?
If OSM does not implement the PlusCode API, would the new mapper editing the way have the necessary knowledge to make the changes to the PlusCode?
If a new PlusCode associated to the new node position is not created, OSM would be reflecting wrong or biased information.

I would like to invite those present to do the exercise of converting decimal coordinates to PlusCode and then from PlusCode to decimal coordinates, you will see that they do not reflect the same initial coordinates from which the exercise starts.
Ex= Viktoria

https://plus.codes/api?address=52.5145076,13.3501100
The result is a 10-digit PlusCode (9F4MG972+R2) that shows a margin of error if the exercise is done in reverse.
https://plus.codes/api?address=9F4MG972%2BR2
In order for it to reflect the coordinate from which the exercise starts with the minimum possible margin of error, the maximum number of digits (15) PlusCode must be used.
https://plus.codes/api?address=9F4MG972%2BR258CM3
The margin of error is larger as the digits of the PlusCode are reduced.
As a complement to the address of a building, it could be quite useful and should carry its corresponding note or warning derived from the number of digits that the PlusCode has (this code represents an area of 278x278mts, 14x14mts, 2.8x3.5mts, 56x87cm,ā€¦ .); but as a location element, even if the maximum number of digits is used to reduce the margin of error, it is inaccurate and would not represent the coordinates of the node.
Taking into account the above, my opinion would be =

  1. Use of PlusCode as an alternative to decimal coordinates in OSM nodes = No, due to PlusCodeā€™s imprecision of representing an exact coordinate.
  2. Use of PlusCode as a search element in the OpenStreetMap URL (issue raised at Add OpenLocationCode to OSM website Ā· Issue #1807 Ā· openstreetmap/openstreetmap-website Ā· GitHub) = No, due to the imprecision of PlusCode to represent an exact coordinate.
  3. Use of PlusCode as unique identification element for OSM elements = No, because a PlusCode reflects an area (small, medium or large depending on the number of digits that compose it) which can contain multiple OSM elements and could cause conflicts.
  4. Use of PlusCode as a complement to addr:=
    This is another topic and should be properly supported as the current tag=value proposals are supported. The objective of addr:* is not to reflect a coordinate, its objective is to provide address information about a building, this information is defined by multiple factors associated with the address system of each country; There are countries that do not have numbering or official names for many of their roads and much less numbering for the buildings along those roads and a tag=value ā€œaddr:plus_code=*ā€ could be useful in buildings that do not have a system of addresses.
    P.S. My native language is Spanish and I use GBoard to translate into English, I apologize in advance if the translation does not correctly reflect my writing.
3 Likes

@afgb1977 Despite this reaction does not meet my wishes to make use of the Pluscode anyway I am very happy with this way of explanation why it is better not to make use of the PlusCode in OSM at this moment.
Felipe gives some good suggestion(s) to consider e.g. the use / integration of the PlusCode API .
Suggestion from my side (now)

  • Lijstitem

do never use the PlusCode on semi-permanent objects.

  • Lijstitem

do not use the privacy argument in this discussion. In my view OSM is not the (technical)instrument for judging if something is acceptable in an ethic way. People must decide for themselves what is responsible and ethical. At most, OSM-community can formulate a guideline what to do with the integration of PlusCodes.