<br><br><div class="gmail_quote">On Tue, Aug 11, 2009 at 8:02 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
David Earl wrote:<br>
> Up to now, we could get away with changing existing tags, but as people<br>
> start to use OSM for real world tasks and base software on it that is<br>
> outside the OSM community, like other file formats, we really have to be<br>
> more controlled about upward compatibility and support. People won't use<br>
> OSM if we keep changing it in unexpected ways under their feet.<br>
<br>
</div>My view is that we should aim to make the best data set we can. We may<br>
have to compromise in many ways, e.g. we cannot make things to difficult<br>
or we lose mappers; we cannot be more precise than GPS allows; and so<br>
on. But I am very reluctant to let our work - at this early stage at<br>
least - be influenced by what we think the "users" might want. Because<br>
all this "backward compatibility" for the sake of some guy somewhere who<br>
has written a program that he's unwilling to adapt really really hurts.<br>
<br>
Next thing you tell me is that in the future we won't be able to make an<br>
API change without providing lots of unnecessary and slow code for<br>
"backwards compatibility".<br>
<br>
I think that OSM should concentrate on their core competency and that it<br>
collecting data. If we ever find we have to change everything and do<br>
things in another way because that gives us better data, then by all<br>
means let's do that and not be encumbered by some users down the line.<br>
If they want our cool & free data they will have to take it in the form<br>
it comes, or employ/pay someone to make them something that does not<br>
change. But I am absolutely unwilling to take our flexibility away for<br>
the sake of "customer service" - because I think that what we first and<br>
foremost deliver to our "customers" is good map data, and we must not<br>
choose any inferior way of collecting that data just because we believe<br>
that the current "customers" like that better.<br>
<div class="im"><br>
> We may realise we made a mistake doing something on way and not another,<br>
> but we have to take into account the impact and cost of changes against<br>
> the perceived problem something causes.<br>
<br>
</div>We should always take into account what changes for us and our mappers,<br>
but anything on the "user side" I think the users can take care of<br>
themselves. (In the end they will benefit from better data as well, it<br>
would only be short-term interests that would make anyone demand that we<br>
remain backwards compatible.)<br>
<div class="im"><br>
> For example, changing highway=gate to barrier=gate. That allowed for a<br>
> consistent way of presenting barriers, but at the expense of anyone<br>
> relying on gates to block routing through them for example not working<br>
> (and if they weren't aware of the change - why should they be? - theior<br>
> programs stopped being effective). This was a largely cosmetic change, a<br>
> change for tidiness sake, not because it was necessary.<br>
<br>
</div>I'm all for making such changes, in this case I think it was mainly an<br>
improvement for mappers (because USERS don't see the tags usually). If a<br>
router cannot be bothered to change then the software is probably not<br>
suitable for OSM. OSM is not an ISO standard ;-)<br>
<br>
(But of course we could think about having some kind of announce list<br>
which those only using our data could subscirbe to to be alerted to<br>
changes they perhaps need to follow.)<br>
<div class="im"><br>
> Changing the common tags like footway/path or the main highway<br>
> designations would be a disaster for these reasons.<br>
<br>
</div>I don't currently support any idea of changing these and honestly I<br>
doubt I ever will. But if there were a proposal for changing them, I<br>
maintain that it must be evaluated without regard to downstream users -<br>
just for us "makers", and if it is deemed to bring improvements for us<br>
but alienate the users, then by all means implement it. (Someone will<br>
undoubtedly be quick to offer some kind of backwards-compatible<br>
synthesized planet dump for those that cannot adapt. Nothing that we<br>
need to worry about.)<br>
<div class="im"><br>
> Consumers (people and software) want to have confidence in what we<br>
> provide.<br>
<br>
</div>If you want a rigid structure and reliability then get your data from<br>
someone who's been doing it for 20 years, not 5. Because if we attempt<br>
to "freeze" now we'll be miserable for the rest of our lives.<br>
</blockquote></div><br>+1<br><br>API 0.6 broke backwards compatibility for editors (with the addition of changesets)<br>API 0.5 broke backwards compatibility for editors AND renderers/routers (with the removal of segments)<br>
<br>So, any discussion about improving the tagging schema must not place backwards-compatibility as a priority. We've been breaking compatibility with our API updates and I don't think breaking backwards compatibility with respect to tagging is a catastrophe especially if the tagging schema turns out to be more consistent and less ambiguous as a result.<br>
<br>