>> This diversity of tagging is often quoted as a problem for data
>> consumers. Oddly, this is often by people who don't actually use the
>> data but feel it must be awkward. Actually it's not. All OSM data has
>> to processed before use. This processing can be fairly
>> straightforward or really complex, but that's not much to do with
>> tagging diversity. Whatever the processing is (LUA code, SQL code or
>> any other coding) it only has to written once and can be used over
>> and over again.
>
> "but that's not much to do with tagging diversity" - I would dispute
> it, from my personal experience. Tagging diversity IS one of real
> problems in using OSM data.
Could you please give an example?
I would like to the contrary to give you two examples where free-form
tagging helps:
Once you start to do routing for various variants wheel devices for
people (wheelchairs, walking frames, stroller, trolleys and probably
more, let's say roller skates) you realize that there are wild
differences how sensitive they react to various kinds of obstacles. It's
not only low or high curbs. It's also about width, incline, steps with
or without ramps, surface, and again probably more. The precise limit
may depend on wheel size, capabilities of the user to lift, tilt, rotate
or carry the device, physical strength.
When you start to use the data then the places where your model fails
are precisely the places where you learn most how to improve your data
model. The used tags and even more the expected but missing tags will
tell a lot about the story what you safely can assume, can reasonably
guess or where you better ought err on the safe side.
If you ask people to misrepresent the reality to fit a fixed tagging
scheme then you have to find those places in a haystack of bent or not
bent data. Precisely: your end users will find those places the hard way.
The second example is even more clear-cut:
In most countries, a bus stop is legally defined by the corresponding
traffic sign. If there is no sign then there is no bus stop. If and only
if you wait at the sign then the bus driver will stop to let you board,
hand waving may be required. A straightforward model would be to set a
node where to sign stands.
However, the wiki got distracted over bikeshedding around the relatively
unimportant question whether to call it "highway=bus_stop" or something
with "public_transport". That's a single line of code to for a data
consumer to handle both. Nobody cared about the various places where
information about public transport is stored. The result is that the
wiki suggests on various pages all mixtures of using a platform, using a
sometimes fictional node on the way, using the traffic sign or any
combination of it. I've even found bus stops where a well-meaning mapper
has replaced the traffic sign node by a fictional node on the street,
i.e. converted precise on-the-ground verifiable information to an
imprecise, non verifiable information.
There is a clear-cut legal definition and the vocal amongst the wiki
users got it wrong. Hence, now every mapper has to decide with his tool
of choice how to least misrepresent the local reality.
However, if one tries to get through the various wiki pages to clean up
things then one still finds a lot of partisan resistance against turning
it to the legal definition - it's not worth the time to fight through.
The mechanism at work is: To get a wiki majority, you need a lot of time
and a dedication to write personal messages. To map properly or to make
a faithful data consumer you must be able to make precise observations
and to know enough similar places and acknowledge their slight
differences. There are few or no people that can and appreciate both.
Hence, it doesn't make much sense to take the wiki too serious. Looking
at taginfo will tell you which and how many tags have to be considered
to get 80%, 95% or sometimes even 99.9% of all cases right, and looking
at the remaining places will make obvious what to do next to get even
further - fixing data or fixing the assumed model.
Cheers,
Roland
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
