[Tagging] Data redundancy with "ref" tag on ways vs relations

Peter Wendorff wendorff at uni-paderborn.de
Wed Aug 1 19:51:57 BST 2012

Am 01.08.2012 19:41, schrieb "Petr Morávek [Xificurk]":
> Frederik Ramm wrote:
>> Tools must serve mappers. Everything in OSM must be geared towards
>> making contribution easy for mappers. Anything else is secondary;
>> consumers are totally unimportant.
> I think, this is the point on which we fundamentally disagree.
> Consumers and data usability is important as well. It's not always easy
> to walk the thin line between the needs and preferences of contributors
> and consumers, but we should try to.
Consumers and data usability is important if and only if we want to sell 
the data, if we benefit from more and more people using our data.
It's great to see more and more parties to consume osm data, but there 
are different types of data consumers.

The group that most benefits from your suggestion of better - or even 
perfect - data usability is the group of people who don't want to work 
with the data, but use it.
These aren't willing to put effort into osm to make it better, and often 
come to us (through every possible channel) and ask questions, but don't 
provide results back to the project.

To be able to provide results back one has to understand how it works, 
so I have to deal with OSM as a whole, not only with the data to do that.

If you have a company and ask "I want to do this and that, who can do me 
that, I pay X for it", I think somebody is there who would do the job - 
if it's a reasonable amount of money for the task.
If you don't want to pay, then do it yourself or go away.

Mappers are so to say part time egoists: Most of them want to provide 
data to everybody, but not for every price.
If it's too hard fiddling around with bad editors or a too complex data 
model, some may go away and leave osm, because it's the fun of mapping 
and creating a big whole why I and most others are mappers.

If you rise a flag for the consumers side and decrease the mapping 
useability with that, these mappers will go away - and afterwards most 
probably the data consumers will follow, because there's no (updated) 
data any more in a reasonable quality and quantity.

Feel free to provide the supporting middleware to make osm data useable 
for your customers, and if you want, let them pay for this service.
Feel free to make a better data model, that serves consumers needs 
better, as long as it serves mappers needs at least equally than before 
- without adding strict rules for that.
> I mean, what's the point of producing the data, if they are unusable or
> really hard to use? If we go down this road, we should employ a bunch of
> monkeys that will bang into the keyboards and produce more data for OSM.
> Who cares those data are unusable? The consumers are totally unimportant
> as long as the monkeys contribute to the project.
It's not unuseable.
There are working routing engines,
There are working renderings - 2D, 2.5D, 3D.
There is at least one working search engine.

There are several routing apps, online, offline, mobile, saas, even in 
There are exports even to closed data formats like garmin, that there 
are restrictions sometimes is not the fault of osm data.

Yes, that's not easy to achieve, but the software is free, code 
inclusive (with very very few restrictions).
You don't have to invent the wheel again, but if you want, you have to 
deal even with the less easy to consume data model.
> Having the data in more or less usable state is important makes it
> easier to build new amazing tools and projects upon them. And these
> projects are vital for OSM - just ask yourself, what was the initial
> reason for starting to contribute to OSM?
I don't know any project that has not been build because of the complex 
or unuseable data model.
There are some small projects that reject(ed) to use osm because we 
don't provide ready to use tiles, and they drive better using google, 
because there they don't need their own tile servers; something that has 
changed since then.

Do you have examples for "amazing tools" that have been stopped in 
development due to the data model?
If so, I'm pretty sure the inventors didn't talk to the osm community, 
as usually there's help from different sides. Hints where pieces of 
software are done already, that can be reused, help with even simple 
coding problems sometimes.

If one doesn't communicate with the community, of course there cannot be 
anyone to help, but that's not the fault of the data model.
> Was it something like "Hey, we're crunching a bunch of geo data into
> this big database called OSM, wanna join us?"
> Or was it something like "Hey, look at this map/navigation SW/..., isn't
> it great? What? Your house's not there? But look, you can add it simply
> like this."
It was the map, yes, but your data don't make maps better.
Show us the code where map renderers prefer to use relations for streets.
The public transport and hiking maps are the only ones I know of that 
render relations, but as far as I know these most often drop the 
attributes of the relations down to the ways to do that (maybe I'm 
wrong, didn't check that).
> Data consumers and their projects are crucial in attracting new
> contributors, that's why we shouldn't make it unnecessarily complicated
> for them and say that they are "totally unimportant".
Are they?
Some are, yes.
The open source projects that use osm data "generate" new users, but 
these projects are most often out of the community.
Bing I think provided the imagery, but I don't think we really got much 
mappers through bing. Apart from the news we got due to that in the 
press, I don't even believe many bing users REALIZE that they use an 
open project where they could contribute.
Some others are better, sure, some are even worse by not following the 
rules like some applications did before and make more work and damage 
than use to osm.

And a very few really give new mappers, but I'm not even sure this is a 
reasonable amount of people, that become mappers (and contribute, see 
e.g. the last paper by Neis and Zipf).


More information about the Tagging mailing list