[Tagging] Data redundancy with "ref" tag on ways vs relations
frederik at remote.org
Thu Aug 2 11:27:08 BST 2012
On 08/01/12 19:41, "Petr Morávek [Xificurk]" wrote:
> 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.
> I mean, what's the point of producing the data, if they are unusable or
> really hard to use?
The current usability of OSM for consumers is already sufficient, as
proven by millions of consumers. The data *is* usable, and claiming that
if we don't change our data model then our data would be comparable to
what monkeys with typewriters produce is ridiculous.
You have omitted my sentence that followed the "totally unimportant". My
point is that data consumers are unimportant *for us* because given the
high value that OSM represents to them they will invest their own time
to make OSM usable for their purpose (rather than us investing our time
to make things easier for them).
There are certainly ways to improve OSM and some issues are more
pressing than others - for example, if we continue to use relations like
we do now, then OSM will likely become *less* usable with time - and
these issues will have to be solved. The main focus in all we do must be
the mappers however - anything that makes OSM more attractive for
consumers but more complicated for mappers (or coders who are also a
scarce resource) is not acceptable.
Therefore, if anyone proposes any improvement to OSM, I expect the
argument to say clearly where the advantages for the mappers are - in
how far is the suggested change beneficial to the mapper's work, will
things become easier for them, will they be able to produce better
results in less time, will even less "educated" mappers be able to
Even if you want mappers to change their behaviour and invest more work
to map something the way you want it, that's still ok as long as it's
the free decision of those mappers.
For example, when Nop set up his hiking map he introduced a new schema
for symbols for hiking routes. More work for mappers to record - but
many happily did it because they liked the resulting map. Nop did not
show up on the tagging list and say: "I think we should really make it a
policy to add symbols to hiking routes because that makes the map so
much more usable" or so. That's the spirit that works in OSM.
If you want mappers to do something then
* give them the tools to do it and
* make it attractive for them to do it.
The thing that doesn't work is "lobby for whatever you want to be made
official policy so that mappers are then forced to do it".
In initial posting of this thread, Paweł explained how he had written a
tool that checks way "ref" tags against relation "ref" tags and suggested:
> Of course there is no hard rules in OSM concerning tagging but
> http://wiki.openstreetmap.org/wiki/Key:ref does not say too much about
> the problem above. I think it should describe why relations should be
> used instead of "ref" tag on ways if possible.
But that is exactly the opposite of how things work round here. Paweł
*thinks* that ref tags on relations would be better, and instead of (a)
giving mappers the tools to do it and (b) making it attractive to do
that (i.e. appealing to the free will of the mappers), Paweł wants to go
the (perceived) authoritarian route by changing the "rules", by saying
that "relations SHOULD be used...".
There is no authority in OSM that could tell mappers what they "should"
do - OSMF can't, this list can't, the Wiki can't. The proper approach is
to make something that people want to use and where people then see: Oh,
if we tag this differently then it works better.
If you cannot make such a thing that demonstrates to mappers how your
ideas work better, then, obviously, the issue isn't that big after all.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the Tagging