[OSM-talk] Proliferation of path vs. footway

[Eugene Alvin Villar]

On Tue, Aug 11, 2009 at 8:02 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> David Earl wrote:
> > 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.
>
> My view is that we should aim to make the best data set we can. We may
> have to compromise in many ways, e.g. we cannot make things to difficult
> or we lose mappers; we cannot be more precise than GPS allows; and so
> on. But I am very reluctant to let our work - at this early stage at
> least - be influenced by what we think the "users" might want. Because
> all this "backward compatibility" for the sake of some guy somewhere who
> has written a program that he's unwilling to adapt really really hurts.
>
> Next thing you tell me is that in the future we won't be able to make an
> API change without providing lots of unnecessary and slow code for
> "backwards compatibility".
>
> I think that OSM should concentrate on their core competency and that it
> collecting data. If we ever find we have to change everything and do
> things in another way because that gives us better data, then by all
> means let's do that and not be encumbered by some users down the line.
> If they want our cool & free data they will have to take it in the form
> it comes, or employ/pay someone to make them something that does not
> change. But I am absolutely unwilling to take our flexibility away for
> the sake of "customer service" - because I think that what we first and
> foremost deliver to our "customers" is good map data, and we must not
> choose any inferior way of collecting that data just because we believe
> that the current "customers" like that better.
>
> > 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.
>
> We should always take into account what changes for us and our mappers,
> but anything on the "user side" I think the users can take care of
> themselves. (In the end they will benefit from better data as well, it
> would only be short-term interests that would make anyone demand that we
> remain backwards compatible.)
>
> > 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.
>
> I'm all for making such changes, in this case I think it was mainly an
> improvement for mappers (because USERS don't see the tags usually). If a
> router cannot be bothered to change then the software is probably not
> suitable for OSM. OSM is not an ISO standard ;-)
>
> (But of course we could think about having some kind of announce list
> which those only using our data could subscirbe to to be alerted to
> changes they perhaps need to follow.)
>
> > Changing the common tags like footway/path or the main highway
> > designations would be a disaster for these reasons.
>
> I don't currently support any idea of changing these and honestly I
> doubt I ever will. But if there were a proposal for changing them, I
> maintain that it must be evaluated without regard to downstream users -
> just for us "makers", and if it is deemed to bring improvements for us
> but alienate the users, then by all means implement it. (Someone will
> undoubtedly be quick to offer some kind of backwards-compatible
> synthesized planet dump for those that cannot adapt. Nothing that we
> need to worry about.)
>
> > Consumers (people and software) want to have confidence in what we
> > provide.
>
> If you want a rigid structure and reliability then get your data from
> someone who's been doing it for 20 years, not 5. Because if we attempt
> to "freeze" now we'll be miserable for the rest of our lives.
>

+1

API 0.6 broke backwards compatibility for editors (with the addition of
changesets)
API 0.5 broke backwards compatibility for editors AND renderers/routers
(with the removal of segments)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/85614a67/attachment.html>