On Sat, Aug 11, 2018 at 5:49 AM, Frederik Ramm <frede...@remote.org> wrote:
> Hi,
> On 11.08.2018 11:21, mmd wrote:
>> With all due respect, I think we've long crossed that point:
> All these have been added by accident, as a side effect of undiscussed
> imports.
> This is bad, but not as bad as adding them on purpose in the course of
> an ill-conceived aid project with the promise of lifting poor people out
> of their not-having-an-address misery.
> Adding coordinates, or plus codes, as tags to OSM makes no sense.
> Building an aid project around it and doing it on purpose is at best
> negligent and at worst cynical. It is a waste of the money of whoever
> funds the aid project, a waste of resources in OSM, and a waste of time
> for those who do it. For OSM to allow this to happen would make us
> complicit in that cynicism.
> Bye
> Frederik

Ok, lets us get back to reality please.

All this huffing and puffing, dumbest idea ever in history, etc etc is
typical and typically not helping.

The situation is:

A ngo on the ground in Tanzania does first responded type work, they
see how helpful addresses are in other contexts, but the area they
work does not have any.

This OLC thing seems like it would be interesting to explore, it might
solve some of their use cases.

All of their tools and workflows can use osm tags, especially like the
addr: tags.

What if we had something like that, an osm tag that had basically an
addr: value, just from OLC instead of however one normally gets an
address. How would that work? Where could we display it? How could we
look them up? etc etc

So by doing a small test using a regular old osm tag, they can explore
if it is useful, how it might help, etc etc. and every single OSM tool
in existence at this moment knows how to deal with osm addr: tags or
osm tags more generally. What a great starting point to see if this
solves any of their use cases, some of which we probably could not
really describe well anyway.

Ya, I am going to try some tagging options so they can get a look at
what is possible if the tools they used supported this in code as they
should, of course.

I was not involved with this at all before, but I am now and I am
going to do what I do, which is do what I can to help people use OSM,
in full accordance with OSM guidelines, which this totally is.

OSM will not break, everything will be ok, but OSM is a folksonomy and
this is folksonomy 101 here.

So take some deep breaths.

Some local OSM'ers are going to experiment very locally and carefully
with how OLCs or an OLC-like thing might fit into their use cases and
we are going to do it by using tags because that is what every OSM
tool in existence right now understands and can use to various

We'll make a wiki page, revert the import, we'll detail it in the wiki
page and re do it on a better defined area, described in the wiki
project page.

Also: No one is getting paid for anything related to this at this
point. I personally would like to see Google donate to the OSMF and
let the OSMF grant it out to help OSM core and eco system tools
implement OLC native in code as it should be. Let the OSMF decide how
to best help get the functionality everyone says should "just exist"
in the vast ecosphere of OSM tools. I also plan on following up on
that idea regardless of this tag / no tag issue, which is a minor
issue at best.


talk mailing list

Reply via email to