[OSM-talk] Path rendering in the cycleway

Dave Stubbs osm.list at randomjunk.co.uk
Tue Sep 2 14:44:43 BST 2008


On Tue, Sep 2, 2008 at 1:56 PM, Robin Paulson <robin.paulson at gmail.com> wrote:
> 2008/9/1 Frederik Ramm <frederik at remote.org>:
>> ... which can be fixed at a later time, if desired. Trying to create rules
>
> why fix it later, that creates extra work? and what do you mean
> 'fixed'? i thought having them mapped with one of 3 different tagging
> schemes was a good thing?

that's the "if desired" part.


>
>> upfront runs a high risk of being impractical. And frankly, if our mappers'
>
> in what sense is it impractical? please be more specific

Because the chance that you know what the issues are likely to be are
going to be smaller. Once people have tried and tested a few different
methods and got them all ironed out and sorted the schemes tend to be
a lot more practical to deal with, mostly because they already have
been.


>
>> creativity leads to two or three different ways of tagging the same thing
>> (but at least it gets mapped well), what's the big deal? The alternative is
>
> by definition (well, mine anyway), 'mapping well' and 'two or three
> different ways of tagging' are not congruent, so to blithely say the
> two can happen together, without explaining how, is missing a rather
> large and important point. and how many different ways exactly? two or
> three sounds vague. what happens when someone wants to use the data to
> do something useful? if there are two or three (or four, or five, or
> six....) ways of modelling the same thing, at what point do they stop
> looking up data structures, to find out how to extract data on, say
> rivers, because someone's been 'creative' and made up a new way of
> tagging something?

Certainly an interesting question. And not one you can ignore with osm
in the current state either. There are already two ways of doing many
things in the current map features list. Not least because the world
out there is complicated and most of the time when using the data I'm
happy to simplify it. There are several different ways to say some
land is covered by trees: landuse=forest or natural=wood. They might
mean different things, but if I'm looking for trees then I need to
account for both.

The same goes for most "duplicates"... mostly they're not really
duplicates at all, they just appear to be at some level of
abstraction. Mostly people are addressing a perceived flaw in another
scheme, and this is why people become unhappy when they are told
they're doin it wrong. Unfortunately people interpret things
differently so figuring out when a duplicate really is a duplicate is
Hard, as is knowing when telling someone that "no, we do it like this"
isn't actually valid.


>
>> trying to force them to agree on one way of doing it, which (worst case) can
>
> no-one's forcing anybody. lots of people use map_features for a
> reason. they clearly don't want to spend time coming up with new tags,
> cos it's boring and tedious - they want to map, cos it's fun and
> interesting and involves being outside. if people wanted to come up
> with new (duplicate) tags, they would be. thankfully, there are very
> few duplicate tags
>
> i used to spend a lot of time on the wiki, working on tag proposals.
> occasionally, i would spot what i thought was a duplicate tag. i would
> put a note, and get one of two responses: "this isn't a duplicate,
> it's similar, but different enough" (e.g. cemetery vs. graveyard), or
> "thanks, i hadn't realised that, i'll remove it" never once did anyone
> say "i'll carry on thanks, i'm being creative and want to develop a
> new way of tagging this"
>
>> make 49% of them unhappy and/or unwilling to map the item in question.
>
> hold on, what do you mean unhappy? says who? 49% might well be the
> worst case, but what's the actual case? it could be 10%. or 0.1%

Actually I suspect given current voting trends, the worst case could
well be closer to 99.999% unhappy :-P
And more realistically I suspect it varies wildly depending on the tag
concerned, with a significant "don't care" section.

Dave




More information about the talk mailing list