Hi, I am very surprised that this discussion is not dead yet. To me, this is like one person saying 1+1 is 2 and the other person saying 1+1 is 3. This is something that should not be a matter of opinion; this is a matter of logic.
Vao, when you write: > My objective is to give addresses to people who will never have one. that's totally ok, and can be done with OSM and plus codes, no question! The issue is just: Should the algorithm that converts lat/lon into plus codes be applied "centrally" and the result of the computation stored in OSM (which seems to be your approach), or should the computation instead happen at the point where a human being interfaces with OSM. To take the example of OSMAnd and make it very clear, step by step. Let's assume we have two people, each using OSMAnd, and one person (A) wants to communicate to the other person (B) where they live. Your approach goes like this: 1. A zooms to their house on OSMAnd. 2. A clicks on the house to somehow bring up all tags the house has. 3. One of these tags is the plus code, because it has been added at another time by a third party. 4. A tells B the plus code. 5. B invokes a search function on their OSMAnd, and OSMAnd searches for an object that has the given plus code. 6. B knows where to go. This approach requires extra functionality in OSMAnd (namely: evaluating the plus code tags), and it requires a third party to have added the plus code for the location in question beforehand. It also requires OSM to store the plus codes. The approach that I - and everyone else who applies the same logic - propose, is: 1. A zooms to their house on OSMAnd. 2. A clicks on the house to invoke the plus code computation function in OSMAnd. 3. OSMAnd displays the plus code. 4. A tells B the plus code. 5. B enters the plus code into OSMAnd, and OSMAnd applies the reverse computation function. 6. B knows where to go. This approach requires extra functionality in OSMAnd to apply the plus code computation, but libraries and code for that exist. This approach does NOT require that someone else has added the particular location to OSM before - it works everywhere on the planet. Also, this approach does not require OSM to store all the plus codes. The only thing that approach A has going for it is that if someone has the means to access OSM, but has no means to invoke the plus code computation, they can still read the plus code from the tag. But I struggle to think of a scenario like that. I think that approach B is not only better, it is the only sane approach. Approach A makes users dependent on the goodwill of someone who uploads all the tags to OSM. Approach B makes this "someone" unnecessary. When used in a humanitarian/development context, approach A represents the old style of making people dependent on aid (dependent on a third party running a plus code import project), whereas approach B is making users independent. Approach A is the wrong approach for everyone. > It is interesting that this effort for > addressing is being trashed because it is savvy technology. You are misreading me and many others here. Plus codes may be savvy technology (albeit I can see how the dependency on latin alphabet may be putting some people off). Plus codes themselves are not under attack here; what is being criticized is using plus codes to do "approach A", and *that* is very certainly not savvy! I and many others have said this a few times in this thread, and I have the impression that it has not really become clear. I hope that this lengthy post has managed to explain it, and I am sure that once you have thought this through you will see that - *especially* from a development aid perspective - approach A is the last thing you want! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
