[OSM-talk] You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”
roland.olbricht at gmx.de
Tue Mar 16 16:24:12 UTC 2021
first of all, I welcome that you speak up because only then
misunderstandings can be addressed.
> OSM is a database
OpenStreetMap is a community of mappers, not a database.
In particular, when there is a trade-off whether we make the life of
mappers or developers easier, then we usually prefer the mappers.
The rationale for this is that mappers are scarce almost everywhere.
In particular, if you develop a larger software relying on OpenStreetMap
then there are some thing that are rather two to three orders more
complex and demanding than conflating two tags.
I try to start with the "phone" thing as an example: what you should do
as a first step is to state a data model independend of OpenStreetMap
and map OpenStreetMap features onto that. There is little to no purpose
to phone a building, and coordinates for phone numbers are also of
special interest at best.
Thus, a software that uses phone numbers is likely be related to some
list of POIs. That makes sense: you need some knowledge about your POI
even to successfully make a phone connection. A pub is unlikely to pck
up the phone at 8:00 in the morning, and a kindergarten is unlikely to
pick up at 20:00 in the evening.
So you should
- come up with a list of types of POIs
- list which tagging you expect for each of them
- declare what shall happen in all the corner cases
It is good practice of meaningful open source to publish this in a brief
yet comphrensive and easy-to-understandable form.
To be more specific, if your subject were restaurants then you likely
would declare that you are interested in
- a name
- a coordinate
- the kind of cuisine if available
- the website if available
- the phone number if available
- an address if available
Then you start to sort out:
Do I consider "amenity=fast_food" also as a POI? What about pubs and bars?
What if I have multiple semicolon seaprated values in the "cusine"
value? Do I want to consider multiple values or is this its own genre?
People likely will disagree about that.
Again, we expect a written statement how the tagging is mapped to the
data model you have presented before.
Extra points if you come up with the corner cases and motivate mappers
to review them. Dubious values for the cusine, non-reachable websites
are on that list, and contradicting phone number for "phone" and
"contact:phone" as well. Motivating mappers is mostly a question of
communication skills, but tools from Osmose over Maproulette to Overpass
and many more are here to help you with that.
- the "phone" - "contact:phone" redundancy is quite a tiny part of the task
- the Wiki has not been involved so far at all
It may happen that in a sincere attempt to improve OSM you run into
other people as well sincerely attempting to improve OSM, but the other
way round. Like one person advocating for "contact:phone" instead of
"phone" and another person advocating the other way round. Only then it
makes sense to survey for the opinion at large then settle the issues in
the direction of the lesser effort. The Wiki Proposal Process may or may
not help, but surely not outside this special situation. It is still
then a communication tool, not an enforcement device.
In this particular case Mattheusz has already pointed out that the
emotions on both sides are large enough that we risk to discourage many
mappers if we side with either one fraction.
And you are still not done here: it is highly likely that unrecognized
cultural bias is going in here. We had, during a three-week-trip through
Ireland, most dinners in what is called by local measures a pub, and it
walked and quacked like what we expected to be typical Irish and
balanced food. You cannot expect to get even remotely healthy or
sophisticated food in a German pub, the next supermarket will already
have a better choice of options.
Thus, different tagging implementations for the same purpose are a quite
commonplace situation, and in many other cases, it is much more
difficult to solve:
You may be tempted to have an each-place-belongs-to-one-country rule,
but there are places where actually the neighbouring countries have
agreed to share the place, not to claim it at all, or agree to ignore
When I sneaked into the discord channel after the other thread
yesterday, I found people utterly mourning about their BRT (bus rapid
transit), and I'm sympathetic with them:
99% of all mappers will never see a BRT but rather only ordinary bus
services and railways. They should be encouraged to map bus services and
railways each in their intrinsic way of tagging, and it does not make
sense to bother them with corner cases.
Nonetheless, mapping a BRT like a rural school bus service utterly
misrepresents it. It can be like a subway in virtually any regard except
not having rails, and mappers from cities with BRTs are often proud of
it. We would discourage mappers if we force them to map it like a school
bus. Thus, the topic should be sorted out with other stakeholders in
public transit mapping. To offer acknoledgement in as many tools as
possible, and preventing the people from falsely upgrading the BRT to a
> I study these things btw.
We all are sympathetic towards newbies, and it is no problem that you
have not even finished your studies. There are many people with decades
of professional experience and even some lecturers on this list, and
they all remeber that they have started as students a long time ago.
A thing that might help you is the CAP theorem you will learn about
later on: you cannot have consistency, availability, and partition
tolerance all at once, but only two of them. This is basically what
We know and cannot change that different people to have contradicting
taxonomies of the world in their mind - thats bascially partition tolerance.
We still want all of them to contribute to OpenStreetMap (because
mappers are scarce, and the irregularities of the world can only be
reported by those with local knowledge) - that is requiring availability.
Thus, we cannot expect the data to adhere to a single uniform taxonomy -
that is the consistency we sacrify here.
There is also good news in the end: writing a tool like the restaurant
tool mentioned before, surveying the actually existing data, writing the
requested documentation and tooling to care for corner cases is well the
size of a bachelor thesis. Thus, with enough engagement, you might be
able to something somewhat meaningful as thesis.
More information about the talk