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
hardware.
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).
regards
Peter
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
