2009/8/11 David Earl <da...@frankieandshadow.com>

> 2009/8/11 Frederik Ramm <frede...@remote.org <mailto:frede...@remote.org>>
> >     On the other hand, if your desire is to change something that already
> >     exists and ask people to tag it differently from now on, or even
> worse
> >     if you want people to agree on a blanket automatic change of millions
> of
> >     existing objects, then you'll have a much harder time convincing
> people
> >     that this is required.
>
>
> I think we are at a turning point now.
>
> Up to now, we could get away with changing existing tags, but as people
> start to use OSM for real world tasks and base software on it that is
> outside the OSM community, like other file formats, we really have to be
> more controlled about upward compatibility and support. People won't use
> OSM if we keep changing it in unexpected ways under their feet.
>
> We may realise we made a mistake doing something on way and not another,
> but we have to take into account the impact and cost of changes against
> the perceived problem something causes.
>
> For example, changing highway=gate to barrier=gate. That allowed for a
> consistent way of presenting barriers, but at the expense of anyone
> relying on gates to block routing through them for example not working
> (and if they weren't aware of the change - why should they be? - theior
> programs stopped being effective). This was a largely cosmetic change, a
> change for tidiness sake, not because it was necessary.
>
> Changing the common tags like footway/path or the main highway
> designations would be a disaster for these reasons.
>
> Consumers (people and software) want to have confidence in what we
> provide. They are worried about that from the point of view of people
> adding incorrect map data or not having complete map data, and breaking
> their software because of an arbitrary incompatible change adds to this.
> We need to live with our quirks, poor choices and so on more as time
> moves on.
>
>
I agree. We are starting to see people using OpenStreetMap data and they are
now expecting some relatively well defined tags (minus the fuzzy definition
for some). I am myself in that position. I am not sure I want to spend hours
and hours to rewrite programs that are using some already defined scheme. We
have to live with it, and to agree on the basic definition.
There were some talks on agreeing on a definition, and I strongly believe
that we should start here. While the current system may seem simple, I think
it solves most, if not all problems. We are starting to split hairs in an
impressive number of ways (and I won't even talk about the number nodes
underpinning those ways). I understand that we want to reach some kind of
perfection but as we say in France (in a very rough translation), "the
better is the enemy of good".
In addition, there is a time where we have to decide to go with a system
even if we know it is partially flawed. If it was an IT project, we would
have gone over budget so many times that I would be scared to show my face
to my bosses. I am not saying that we should compare OSM to an IT project,
but we have to consider that there is currently an ecosystem out there using
OSM with its current assumption and that if we keep changing things, we will
lose people as it is a mess. After all, one of the rule of the Linux kernel
is not to change any ABI. Once it is there, it stays there as it may break
applications depending on that interface.
As Frederik clearly stated and very rightfully, if your new tag is solving a
new problem that nobody got before, no one will be complaining about it. We
should stop reinventing the wheel.
Let's work on those definitions first to make sure that everyone and every
languages are on the same wavelength.
In addition, I strongly believe that committees in a semi chaotic project
are useless. I don't think the foundation should be involved in any of the
tags decision. The foundation is not here to decide on the content.

Emilie Laffray
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to