Discussion:
[OSM-talk] Proliferation of path vs. footway
Tom Chance
2009-08-10 09:30:52 UTC
Permalink
Hi there,

I'm 100% unclear about the distinction between highway=path and
highway=footway.

Paths and footways, which seem to be used for the same sorts of ways by
different mappers, both show up differently on the main map. The Mapnik and
Tiles at Home stylesheets have quite enough different way styles already,
adding more just makes it even harder for your average user to interpret.
So I think it?s important that we define the difference more clearly and
apply it more consistently.

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

The wiki page above, and the voting page for the proposal, suggest that
highway=path should be used where you don?t really think footway,
cycleway, bridleway, track and others are suitable. But then it suggests
using highway=path with a subset of tags in place of highway=bridleway,
which contradicts the first explanation.

I can only think of a few circumstances where I wouldn?t just opt for
footway ? little unofficial paths here and there in parks, across small
bits of grass in towns and in the countryside. But I?ve seen path crop up
in lots of situations where the other highway tags would be good enough.

Which is it to be?

Regards,
Tom
Elena of Valhalla
2009-08-10 09:50:48 UTC
Permalink
Post by Tom Chance
I'm 100% unclear about the distinction between highway=path and
highway=footway.
Paths and footways, which seem to be used for the same sorts of ways by
different mappers, both show up differently on the main map. [..]
I can only think of a few circumstances where I wouldn?t just opt for
footway ? little unofficial paths here and there in parks, across small
bits of grass in towns and in the countryside. But I?ve seen path crop up
in lots of situations where the other highway tags would be good enough.
There has been some discussion lately on the italian mailing list,
with no consensus reached, but quite a few of us are using footway for
urban-style ways and path for outdoor/trekking style ways: the idea
would be that you can go in a footway with any kind of clothing and
footwear, while on a path foot=yes|designated you are expected to wear
at a minimum confortable clothes and footwear, unless the sac_scale
value suggests more tecnical equipment.
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla at gmail.com
Richard Mann
2009-08-11 10:56:47 UTC
Permalink
Path certainly seems to have fulfilled a need for less-good "paths" in
fields & forests. I would go so far as to say it should now be recommended
for that purpose (but noting that there's still quite a lot of use of other
tags for data users to be aware of, and this usage may persist).

However, I don't think we've got a consensus on how things should be tagged
at the border between footway and cycleway. There the documentation should
(for the moment) recognise that the matter is still evolving.

Yes it is messy, but the problem is that the "vote" isn't the end of the
process (that is merely the recording of the views of the people who are
still following, if not particpating in some part of the debate). There's
then a long process of documentation, usage, redocumentation, before finally
you get to consensus. If you recognise it as a process, and use appropriate
language, then I think we'll get there in the end.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/c9e10988/attachment.html>
Richard Mann
2009-08-10 09:52:56 UTC
Permalink
The German-language page is quite a bit clearer - it says use "path" in
forests and fields (I think).

Plus for cycleways that are segregated by line (hmm - this looks like a
bodge; at least it's precise).

The English-language page suffered from enthusiastic editing by people who
thought path might lead to footway/cycleway ceasing to be required
(unlikely). And the result does need tidying up.

Richard
Post by Tom Chance
Hi there,
I'm 100% unclear about the distinction between highway=path and
highway=footway.
Paths and footways, which seem to be used for the same sorts of ways by
different mappers, both show up differently on the main map. The Mapnik and
Tiles at Home stylesheets have quite enough different way styles already,
adding more just makes it even harder for your average user to interpret.
So I think it?s important that we define the difference more clearly and
apply it more consistently.
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
The wiki page above, and the voting page for the proposal, suggest that
highway=path should be used where you don?t really think footway,
cycleway, bridleway, track and others are suitable. But then it suggests
using highway=path with a subset of tags in place of highway=bridleway,
which contradicts the first explanation.
I can only think of a few circumstances where I wouldn?t just opt for
footway ? little unofficial paths here and there in parks, across small
bits of grass in towns and in the countryside. But I?ve seen path crop up
in lots of situations where the other highway tags would be good enough.
Which is it to be?
Regards,
Tom
_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/e7089885/attachment.html>
Martin Simon
2009-08-10 10:13:39 UTC
Permalink
sorry, wrong address, forwarded again...


---------- Forwarded message ----------
From: Martin Simon <grenzdebil at gmail.com>
Date: 2009/8/10
Subject: Re: [OSM-talk] Proliferation of path vs. footway
To: Richard Mann <richard.mann.westoxford at googlemail.com>
Post by Richard Mann
The German-language page is quite a bit clearer - it says use "path" in
forests and fields (I think).
Plus for cycleways that are segregated by line (hmm - this looks like a
bodge; at least it's precise).
The English-language page suffered from enthusiastic editing by people who
thought path might lead to footway/cycleway ceasing to be required
(unlikely). And the result does need tidying up.
If this is what it says, the German page is wrong and needs some work,
while the english one is right.

"Path" was and is intended to provide an alternative tagging scheme
for things tagged with footway/bridleway/cycleway before that is not
biased mode-of-transport-wise.

With path, you can distinguish between e.g. officially designated
"footways" and those that have no designation at all.
Furthermore, it is possible to tag combined cycle/foot/whateverways
without discriminating one of the modes of transport. (like with
"highway=cycleway, foot=yes" before)

-Martin
Tom Chance
2009-08-10 10:32:24 UTC
Permalink
Post by Martin Simon
"Path" was and is intended to provide an alternative tagging scheme
for things tagged with footway/bridleway/cycleway before that is not
biased mode-of-transport-wise.
With path, you can distinguish between e.g. officially designated
"footways" and those that have no designation at all.
Furthermore, it is possible to tag combined cycle/foot/whateverways
without discriminating one of the modes of transport. (like with
"highway=cycleway, foot=yes" before)
If this is the proper conclusion of the voting then the tag is a complete,
hopeless mess!

Since the vote very clearly opposed deprecating footway, cycleway, and
bridleway we must now have two parallel tagging schemas that are marking
exactly the same features with more or less the same information in a
different way.

http://wiki.openstreetmap.org/wiki/Approved_features/Path

Germans use highway=path for paths of any description fields and forests,
Italians for paths in the countryside, English-speaking mappers either for
miscellaneous little footpaths or as a wholesale replacement of
footway/cycleway/bridleway, and in a few places people seem to just be
making random distinctions (like footpaths in cemeteries).

The result is a totally unclear fudge which leaves us either with
needlessly complicated maps, or stylesheets with a long string of "this or
that or that or that" definitions to describe near-identical features that
should be rendered in the same way.

It just makes me despair about the anarchic approach we have towards
tagging. It's almost as bad as the utterly pointless (and still unresolved)
distinctions around wood/forest. It's absolutely fine to create a new tag
for a new feature, do what you want! But it's crazy that we let random
unaccountable groups of wiki users change the rules for basic features like
footpaths without having any sufficient processes and tools to make sure
this then gets full agreement, clear documentation and proper enforcement.

Regards,
Tom
Dave Stubbs
2009-08-10 11:58:01 UTC
Permalink
Post by Tom Chance
Post by Martin Simon
"Path" was and is intended to provide an alternative tagging scheme
for things tagged with footway/bridleway/cycleway before that is not
biased mode-of-transport-wise.
With path, you can distinguish between e.g. officially designated
"footways" and those that have no designation at all.
Furthermore, it is possible to tag combined cycle/foot/whateverways
without discriminating one of the modes of transport. (like with
"highway=cycleway, foot=yes" before)
If this is the proper conclusion of the voting then the tag is a complete,
hopeless mess!
Since the vote very clearly opposed deprecating footway, cycleway, and
bridleway we must now have two parallel tagging schemas that are marking
exactly the same features with more or less the same information in a
different way.
http://wiki.openstreetmap.org/wiki/Approved_features/Path
Germans use highway=path for paths of any description fields and forests,
Italians for paths in the countryside, English-speaking mappers either for
miscellaneous little footpaths or as a wholesale replacement of
footway/cycleway/bridleway, and in a few places people seem to just be
making random distinctions (like footpaths in cemeteries).
The result is a totally unclear fudge which leaves us either with
needlessly complicated maps, or stylesheets with a long string of "this or
that or that or that" definitions to describe near-identical features that
should be rendered in the same way.
It just makes me despair about the anarchic approach we have towards
tagging. It's almost as bad as the utterly pointless (and still unresolved)
distinctions around wood/forest. It's absolutely fine to create a new tag
for a new feature, do what you want! But it's crazy that we let random
unaccountable groups of wiki users change the rules for basic features like
footpaths without having any sufficient processes and tools to make sure
this then gets full agreement, clear documentation and proper enforcement.
Anarchy in tagging died a bit back when some guys on the wiki decided
ochlocracy was the way to go.
Tagging used to be occasionally a confused mess.
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact (and to give them some more time to go and actually map
something), knowing full well that not being there won't make much
difference to the eventual stupid decision.

Gah... must... be... more... positive...

Dave
Martin Koppenhoefer
2009-08-10 12:37:18 UTC
Permalink
Post by Dave Stubbs
Anarchy in tagging died a bit back when some guys on the wiki decided
ochlocracy was the way to go.
Tagging used to be occasionally a confused mess.
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact
I was thinking exactly like this for quite a long time, but recently
changed my mind: I noticed that almost all new contributors rely on
the wiki (of course) and map according to what is defined there. I
therefore believe it is important to have at least some basics in a
way in the wiki, that it is there according to the actual usage of the
tags. Also I strongly believe that too much anarchy and contradiction
in the mapping guidelines and suggestions will make newbies turn away
(for the mentioned sanity-reasons).

cheers,
Martin
Tobias Knerr
2009-08-10 12:49:56 UTC
Permalink
Post by Dave Stubbs
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact [...] knowing full well that not being there won't make much
difference to the eventual stupid decision.
Do you have some examples for bad decisions that were produced by wiki
voting?

"path" isn't a good example because most of the chaos actually stems
from people using the pre-ochlocracy foot-/cycle-/bridleway without
having a common definition for what they actually mean.

Tobias Knerr
Martin Koppenhoefer
2009-08-10 13:04:06 UTC
Permalink
Post by Tobias Knerr
Post by Dave Stubbs
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact [...] knowing full well that not being there won't make much
difference to the eventual stupid decision.
Do you have some examples for bad decisions that were produced by wiki
voting?
"path" isn't a good example because most of the chaos actually stems
from people using the pre-ochlocracy foot-/cycle-/bridleway without
having a common definition for what they actually mean.
the same thing that people wanted to achieve with path (expressing the
official designation) can be achieved with those
foot-/cycle-/bridleway by adding supplementory tags like
xy=designated, xy=official. Therefore I would consider the introdution
of path a bad decision.

cheers,
Martin
Nop
2009-08-10 13:40:42 UTC
Permalink
Hi!
Post by Martin Koppenhoefer
the same thing that people wanted to achieve with path (expressing the
official designation) can be achieved with those
foot-/cycle-/bridleway by adding supplementory tags like
xy=designated, xy=official. Therefore I would consider the introdution
of path a bad decision.
Then you are still missing a tag for the general purpose path where you
don't know any more details except it is not a road.

bye
Nop
Liz
2009-08-10 22:31:12 UTC
Permalink
Post by Dave Stubbs
Anarchy in tagging died a bit back when some guys on the wiki decided
ochlocracy was the way to go.
Tagging used to be occasionally a confused mess.
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact (and to give them some more time to go and actually map
something), knowing full well that not being there won't make much
difference to the eventual stupid decision.
Gah... must... be... more... positive...
I would consider that if we have thousands of mappers, that we should set a
quorum for a vote
so that unless at least x hundred people vote the vote is not valid
Alex Mauer
2009-08-11 00:57:49 UTC
Permalink
Post by Liz
Post by Dave Stubbs
Anarchy in tagging died a bit back when some guys on the wiki decided
ochlocracy was the way to go.
Tagging used to be occasionally a confused mess.
Now it's an organised, and "approved" confused mess where anyone with
a clue automatically withdraws from discussions to keep their sanity
intact (and to give them some more time to go and actually map
something), knowing full well that not being there won't make much
difference to the eventual stupid decision.
Gah... must... be... more... positive...
I would consider that if we have thousands of mappers, that we should set a
quorum for a vote
so that unless at least x hundred people vote the vote is not valid
From
http://wiki.openstreetmap.org/wiki/Proposed_features#Proposal_Status_Process:
"8 unanimous approval votes or 15 total votes with a majority approval"

It seems to me that we have one.
-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/ae8517dd/attachment.pgp>
Tom Hughes
2009-08-11 07:31:10 UTC
Permalink
Post by Alex Mauer
Post by Liz
I would consider that if we have thousands of mappers, that we should set a
quorum for a vote
so that unless at least x hundred people vote the vote is not valid
From
"8 unanimous approval votes or 15 total votes with a majority approval"
It seems to me that we have one.
That's a completely ridiculous quorum when we have 10000 active mappers.
If the process says that eight people can get together and tell
thousands of people that they've been "doing it wrong" for the last five
years and should start retagging everything according to some new scheme
then the process is broken.

Tom
--
Tom Hughes (tom at compton.nu)
http://www.compton.nu/
Roy Wallace
2009-08-11 07:50:00 UTC
Permalink
Post by Tom Hughes
That's a completely ridiculous quorum when we have 10000 active mappers.
If the process says that eight people can get together and tell
thousands of people that they've been "doing it wrong" for the last five
years and should start retagging everything according to some new scheme
then the process is broken.
What would you suggest? It is quite possible that the effect of
increasing the number of necessary votes will only result in slowing
down progress. Do you instead expect that it would increase the
quality of the accepted proposals? Or are you saying that new ways of
tagging things are just bad in general??
Tom Hughes
2009-08-11 08:02:28 UTC
Permalink
Post by Roy Wallace
Post by Tom Hughes
That's a completely ridiculous quorum when we have 10000 active mappers.
If the process says that eight people can get together and tell
thousands of people that they've been "doing it wrong" for the last five
years and should start retagging everything according to some new scheme
then the process is broken.
What would you suggest? It is quite possible that the effect of
increasing the number of necessary votes will only result in slowing
down progress. Do you instead expect that it would increase the
quality of the accepted proposals? Or are you saying that new ways of
tagging things are just bad in general??
Well the hurdle to jump to change an existing tagging should certainly
be much higher than the hurdle to introduce a new tag for something that
hasn't been tagged before.

Tom
--
Tom Hughes (tom at compton.nu)
http://www.compton.nu/
Tom Chance
2009-08-11 08:17:37 UTC
Permalink
Post by Tom Hughes
Post by Roy Wallace
What would you suggest? It is quite possible that the effect of
increasing the number of necessary votes will only result in slowing
down progress. Do you instead expect that it would increase the
quality of the accepted proposals? Or are you saying that new ways of
tagging things are just bad in general??
Well the hurdle to jump to change an existing tagging should certainly
be much higher than the hurdle to introduce a new tag for something that
hasn't been tagged before.
Which is precisely why I made a simple proposal for a new process in these
situations.

It may not be the right process, but we have to admit that the case of
"highway=path" - notwithstanding the merit of that proposal - shows the
current process is quite broken.

Regards,
Tom
Frederik Ramm
2009-08-11 08:23:09 UTC
Permalink
Hi,
Post by Tom Chance
Post by Tom Hughes
Well the hurdle to jump to change an existing tagging should certainly
be much higher than the hurdle to introduce a new tag for something that
hasn't been tagged before.
Which is precisely why I made a simple proposal for a new process in these
situations.
But isn't what TomH writes above exactly what we have? If you introduce
something new that was never tagged before, you simply tag it any way
you think makes sense and it is *very* unlikely that you will run into
criticism; a few months down the road, when someone else asks how this
thing should be tagged, you could say that you've been using this and
that for a while now and he can just do the same.

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.

All this without any formal quorum or vote.

Bye
Frederik
Tom Chance
2009-08-11 08:48:23 UTC
Permalink
Post by Frederik Ramm
Post by Tom Chance
Post by Tom Hughes
Well the hurdle to jump to change an existing tagging should certainly
be much higher than the hurdle to introduce a new tag for something that
hasn't been tagged before.
Which is precisely why I made a simple proposal for a new process in these
situations.
But isn't what TomH writes above exactly what we have? If you introduce
something new that was never tagged before, you simply tag it any way
you think makes sense and it is *very* unlikely that you will run into
criticism; a few months down the road, when someone else asks how this
thing should be tagged, you could say that you've been using this and
that for a while now and he can just do the same.
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.
All this without any formal quorum or vote.
No, this isn't exactly the happy situation TomH writes about. The
highway=path example illustrates two dysfunctions with the current anarchic
approach:

1 ? Nobody can actually agree what highway=path means so it is being used
in different senses all over the world, which reduces its usefulness to
near zero

2 ? One of the senses in which it is used, which was a large part of its
original proposal, did in fact duplicate or deprecate existing tags (some
of the oldest and most commonly used tags, in fact). Now we have them both
operating in parallel, which is pointless and problematic for reasons
previously explained

We currently have no process for dealing with these problems, nor with (for
example) the evident shortcomings of natural world / countryside tagging,
as the hopeless disagreements around forest/wood illustrate. The OSM
community can either pretend that we live in a world of perfect information
and emergent consensus, or we can grow up and take a leaf out of every
other successful open source project and set-up some processes where
consensus is more difficult to reach.

Regards,
Tom
Frederik Ramm
2009-08-11 09:18:35 UTC
Permalink
Hi,
Post by Tom Chance
1 ? Nobody can actually agree what highway=path means so it is being used
in different senses all over the world, which reduces its usefulness to
near zero
Perhaps it really *is* useless and it was good that our process
demonstrated that?
Post by Tom Chance
We currently have no process for dealing with these problems, nor with (for
example) the evident shortcomings of natural world / countryside tagging,
as the hopeless disagreements around forest/wood illustrate. The OSM
community can either pretend that we live in a world of perfect information
and emergent consensus
In my eyes, it is not required that the same tagging rules are used all
over the world. It may be a pet peeve of mine but I think that the
majority of people take this as given without ever spending a second
thinking about whether this might not create more problems than it
solves. We solve loads of very complex problems all the time - are we
really sure that we are unable to cope with a database in which, say,
Canada uses a slightly different tagging scheme than does Scandinavia?
Do we really have to steamroll everyone in the whole world into
submission to some sort of consensus with people on the other side of
the planet?
Post by Tom Chance
or we can grow up and take a leaf out of every
other successful open source project and set-up some processes where
consensus is more difficult to reach.
I think that "consensus" is totally overrated. "Rough consensus" makes
sense, but we have that, and everything else will work itself out
eventually. All this talk about OSM being useless if consensus doesn't
exist for the smallest detail is just scaremongering by people who
cannot cope with complexity or diversity.

Bye
Frederik
Ulf Lamping
2009-08-11 10:09:22 UTC
Permalink
Post by Frederik Ramm
Hi,
Post by Tom Chance
1 ? Nobody can actually agree what highway=path means so it is being used
in different senses all over the world, which reduces its usefulness to
near zero
Perhaps it really *is* useless and it was good that our process
demonstrated that?
Post by Tom Chance
We currently have no process for dealing with these problems, nor with (for
example) the evident shortcomings of natural world / countryside tagging,
as the hopeless disagreements around forest/wood illustrate. The OSM
community can either pretend that we live in a world of perfect information
and emergent consensus
In my eyes, it is not required that the same tagging rules are used all
over the world. It may be a pet peeve of mine but I think that the
majority of people take this as given without ever spending a second
thinking about whether this might not create more problems than it
solves. We solve loads of very complex problems all the time - are we
really sure that we are unable to cope with a database in which, say,
Canada uses a slightly different tagging scheme than does Scandinavia?
Do we really have to steamroll everyone in the whole world into
submission to some sort of consensus with people on the other side of
the planet?
I don't like your suggestive argumentation. With your "pet peeve of
mind" and "ever spending a second thinking" you suggest that others
don't think about their positions and only you have thought long enough
to get the right idea.

I've spend a lot more than just a second about this, and I've come to a
different conclusion what will cause more problems in the long run than
you do.
Post by Frederik Ramm
Post by Tom Chance
or we can grow up and take a leaf out of every
other successful open source project and set-up some processes where
consensus is more difficult to reach.
I think that "consensus" is totally overrated. "Rough consensus" makes
sense, but we have that, and everything else will work itself out
eventually. All this talk about OSM being useless if consensus doesn't
exist for the smallest detail is just scaremongering by people who
cannot cope with complexity or diversity.
You've stated the same position already some time ago, but it turned out
that the situation didn't get any better since then.

People want to tag stuff and they just can't put the information in the
tags in a way that its meaning is clear to others going to use the data.
Not because they are too lazy to find out how, but because the same
tags are used in different ways.

If lot's of producers and consumer are both interested in specific
details, but the osm tags can't transfer the information (because it
get's "too blurred" on the way), I wouldn't call this "rough consensus",
I simply call it a mess.

Regards, ULFL
Tom Chance
2009-08-11 12:07:46 UTC
Permalink
Frederik,
Post by Frederik Ramm
Post by Tom Chance
1 ? Nobody can actually agree what highway=path means so it is being used
in different senses all over the world, which reduces its usefulness to
near zero
Perhaps it really *is* useless and it was good that our process
demonstrated that?
Hmm, the process has demonstrated that a useless tag is now widely being
used. The process - so-called - hasn't coped with something as complex as
saying "let's have a bit of a rethink about this group of existing tags and
some missing features". The process has left us with conflicting wiki pages
in different languages, and 100s of emails with anecdotes of contradictory
usage. The vast majority of OSM users won't have read this email thread,
and may be following the wiki pages, or something their mate told them, or
example tagging from a nearby area, further mixing up a useless tag.

Is that good?
Post by Frederik Ramm
Post by Tom Chance
We currently have no process for dealing with these problems, nor with (for
example) the evident shortcomings of natural world / countryside tagging,
as the hopeless disagreements around forest/wood illustrate. The OSM
community can either pretend that we live in a world of perfect information
and emergent consensus
In my eyes, it is not required that the same tagging rules are used all
over the world.
I agree, so that's a silly straw man argument. One caveat, though: for most
things, we can find standard international tags which also mean you can
produce a useful consistent map for all of those countries. Otherwise the
data becomes useless, or unecessarily complex, at an international scale,
and y'know some people might want to use it at that scale.
Post by Frederik Ramm
I think that "consensus" is totally overrated. "Rough consensus" makes
sense, but we have that, and everything else will work itself out
eventually. All this talk about OSM being useless if consensus doesn't
exist for the smallest detail is just scaremongering by people who
cannot cope with complexity or diversity.
You can exaggerate mine and others' arguments if you want. You can say
we're scaremongering, that we don't like diversity and that we have small
brains and yellow trousers, if that makes you happy.

But the fact remains that we *do not* have - even in the most generous
sense - rough consensus around the tagging of paths, nor various natural
world features.

Regards,
Tom
Emilie Laffray
2009-08-11 09:29:29 UTC
Permalink
2009/8/11 Frederik Ramm <frederik at remote.org>
Post by Frederik Ramm
Hi,
Post by Tom Chance
Post by Tom Hughes
Well the hurdle to jump to change an existing tagging should certainly
be much higher than the hurdle to introduce a new tag for something that
hasn't been tagged before.
Which is precisely why I made a simple proposal for a new process in
these
Post by Tom Chance
situations.
But isn't what TomH writes above exactly what we have? If you introduce
something new that was never tagged before, you simply tag it any way
you think makes sense and it is *very* unlikely that you will run into
criticism; a few months down the road, when someone else asks how this
thing should be tagged, you could say that you've been using this and
that for a while now and he can just do the same.
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.
All this without any formal quorum or vote.
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/cc173695/attachment.html>
David Earl
2009-08-11 09:45:16 UTC
Permalink
2009/8/11 Frederik Ramm <frederik at remote.org <mailto:frederik at remote.org>>
Post by Frederik Ramm
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.

David
Emilie Laffray
2009-08-11 10:05:23 UTC
Permalink
2009/8/11 David Earl <david at frankieandshadow.com>
Post by David Earl
2009/8/11 Frederik Ramm <frederik at remote.org <mailto:frederik at remote.org>>
Post by Frederik Ramm
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
Post by Frederik Ramm
if you want people to agree on a blanket automatic change of millions
of
Post by Frederik Ramm
existing objects, then you'll have a much harder time convincing
people
Post by Frederik Ramm
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/1fc5e22e/attachment.html>
Frederik Ramm
2009-08-11 12:02:43 UTC
Permalink
Hi,
Post by David Earl
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.
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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.

Bye
Frederik
Eugene Alvin Villar
2009-08-11 14:49:47 UTC
Permalink
Post by Frederik Ramm
Hi,
Post by David Earl
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.
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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>
Tom Chance
2009-08-11 15:10:33 UTC
Permalink
Post by Eugene Alvin Villar
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.
Nobody is saying this is a catastrophe. Maybe we should drop
highway=footway/cycleway and move to highway=path plus subsidiary tags, and
break backwards compatability for old stylesheets etc. The question is one
of process.

The API changes are actually a nice example where a set of changes are
discussed until there is enough agreement, consistently applied to the OSM
API and the core tools, properly documented, and then the change is
communicated through all available channels.

Users the world over benefit from this professionalism.

Users the world over would benefit from a similar depth of consideration in
complex matters, and clarity about decisions that are well implemented,
properly documented and widely communicated.

Regards,
Tom
Apollinaris Schoell
2009-08-11 15:16:46 UTC
Permalink
perfect, only one thing to add.
more emails to talk will not change anything.
active mappers, the ones writing tools and renderers will
over time the better scheme will win or both stay in peaceful
coexistence.
Post by Frederik Ramm
Hi,
Post by David Earl
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.
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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.)
Post by David Earl
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.
Bye
Frederik
_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Tobias Knerr
2009-08-11 11:22:05 UTC
Permalink
Post by Tom Hughes
That's a completely ridiculous quorum when we have 10000 active mappers.
If the process says that eight people can get together and tell
thousands of people that they've been "doing it wrong" for the last five
years and should start retagging everything according to some new scheme
then the process is broken.
Those eight people can only do this if not even 0.1% of the other 10000
care enough to oppose the proposal. If that's the case, then apparently
the proposal isn't so bad, is it? Why didn't all those people who
apparently hate "path" vote against it?

You seem to assume that people who use a tag actually implicitly "vote"
for it. In practice, most mappers simply use what's there and don't mind
using something else if that's what their editor presets / wiki
documentation / neighbors are using now. While path may have been
"approved" by a minority, it's also a minority who is complaining about
it now. If applications and editors consistently used path, then most of
your 10000 wouldn't spend a second thought on it.

Tobias Knerr
David Earl
2009-08-11 11:27:21 UTC
Permalink
Post by Tobias Knerr
Post by Tom Hughes
That's a completely ridiculous quorum when we have 10000 active mappers.
If the process says that eight people can get together and tell
thousands of people that they've been "doing it wrong" for the last five
years and should start retagging everything according to some new scheme
then the process is broken.
Those eight people can only do this if not even 0.1% of the other 10000
care enough to oppose the proposal. If that's the case, then apparently
the proposal isn't so bad, is it? Why didn't all those people who
apparently hate "path" vote against it?
(a) because not everyone has the luxury of following all this with the
hundreds of emails a day and all.

(b) because many people just ignore the voting system as it has no
official status, and do their own thing. The map renderers generally
have more influence on what tags are used IMO than any amount of voting.

David
Tobias Knerr
2009-08-11 11:45:46 UTC
Permalink
Post by David Earl
Post by Tobias Knerr
Why didn't all those people who
apparently hate "path" vote against it?
(a) because not everyone has the luxury of following all this with the
hundreds of emails a day and all.
(b) because many people just ignore the voting system as it has no
official status, and do their own thing. The map renderers generally
have more influence on what tags are used IMO than any amount of voting.
The people I'm talking about are those who complain about the result of
the voting on "path" on this very mailing list. Apparently, they

(a) follow this mailing list with the hundreds of emails a day

(b) care about the voting result in a way (they don't complain about the
fact that highway=path is being rendered, do they?)

The proposal concept requires that people who find problems with a
proposal voice their opinion. It's everybody's right to refuse
participation. But I don't think it's good style to use the problems
resulting from that refusal as a proof that that process cannot work.

Tobias Knerr
Gustav Foseid
2009-08-11 11:35:29 UTC
Permalink
Post by Tobias Knerr
Those eight people can only do this if not even 0.1% of the other 10000
care enough to oppose the proposal. If that's the case, then apparently
the proposal isn't so bad, is it? Why didn't all those people who
apparently hate "path" vote against it?
If you look at the voting results, you will see that it was rather disputed
from the start:
http://wiki.openstreetmap.org/wiki/Approved_features/Path#Voting

- Gustav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/9d9d1ba1/attachment.html>
Martin Koppenhoefer
2009-08-11 13:51:20 UTC
Permalink
Post by Alex Mauer
Post by Liz
I would consider that if we have thousands of mappers, that we should set a
quorum for a vote
so that unless at least x hundred people vote the vote is not valid
From
"8 unanimous approval votes or 15 total votes with a majority approval"
It seems to me that we have one.
Yes, there is one, but 15 votes in a 135000-users comunity (10000
frequent contributors a month) is not the voter participation that you
could generally agree on as democratic.
It corresponds to 0,01 % (for all users) or 0,15 % (contributors) of
voter participation. ;-)
Besides that we hope to all play fair, one could easily create
multiple accounts and turn the voting process to whatever result you
like ;-), and still everybody has the right to map whatever he likes
using whatever tags he prefers. So voting seems a little bit
pointless. (I don't know why I'm nonetheless participating) ;-)

cheers,
Martin
Nop
2009-08-10 12:10:32 UTC
Permalink
Hi!
Post by Tom Chance
The result is a totally unclear fudge which leaves us either with
needlessly complicated maps, or stylesheets with a long string of "this or
that or that or that" definitions to describe near-identical features that
should be rendered in the same way.
It is even worse, as different groups of mappers use exactly the same
tags with different meanings. This cannot be resolved by rendering rules
or any other technicyl means.

bye
Nop
John Smith
2009-08-10 10:05:54 UTC
Permalink
Post by Richard Mann
The English-language page suffered from enthusiastic
editing by people who thought path might lead to
footway/cycleway ceasing to be required (unlikely). And the
result does need tidying up.
This came up on talk-au list, also with no definite agreement.

Although that was mostly about path v cycleway, but there are signs depicting bicycles on cycleways. :)
Andy Allan
2009-08-10 10:13:52 UTC
Permalink
Post by Tom Chance
Hi there,
I'm 100% unclear about the distinction between highway=path and
highway=footway.
Paths and footways, which seem to be used for the same sorts of ways by
different mappers, both show up differently on the main map.
That's because these maps are turning into colourful symbolisations of
the tags, rather than being actual maps. A large constituency of
people think that every tag should be rendered differently, whereas in
fact the "cartographers" should be deciding how to communicate
real-world features to the users of the maps. Especially in the case
of paths, since we have multiple ways of tagging exactly the same
thing, or where the differences are so small (c.f. my previous
comments regarding minor/tertiary/unclassified) that they are the same
thing to most people.
Post by Tom Chance
The Mapnik and
Tiles at Home stylesheets have quite enough different way styles already,
Too true. My attempts to reconcile highway=path into the rendering
scheme for OCM continues.

Cheers,
Andy
John Smith
2009-08-10 10:26:35 UTC
Permalink
Post by Martin Simon
With path, you can distinguish between e.g. officially
designated
"footways" and those that have no designation at all.
Furthermore, it is possible to tag combined
cycle/foot/whateverways
without discriminating one of the modes of transport. (like
with
"highway=cycleway, foot=yes" before)
How do you propose to highlight the primary purpose?

Cyclists want to know the best cycle path, the fact that cycling is allowed doesn't give enough information, and in fact by reducing these ways to a simple path + allowed uses information would be lost.
Martin Simon
2009-08-10 10:52:44 UTC
Permalink
Post by John Smith
Post by Martin Simon
With path, you can distinguish between e.g. officially
designated
"footways" and those that have no designation at all.
Furthermore, it is possible to tag combined
cycle/foot/whateverways
without discriminating one of the modes of transport. (like
with
"highway=cycleway, foot=yes" before)
How do you propose to highlight the primary purpose?
In the case of a combinet cycle and footway in germany, there is no
primary purpose, pedestrians and cyclists have equal rights on these
ways. So I tag "highway=path,bicycle=designated,foot=designated".
Post by John Smith
Cyclists want to know the best cycle path, the fact that cycling is allowed doesn't give enough information, and in fact by reducing these ways to a simple path + allowed uses information would be lost.
It's not about allowing cycling(like official fooways that _also_
allow bicycles as "guests"), it's about official designation. This
makes, at least in Germany, a big (legal) difference...
So you could tag a footway which also allows bicycles as
highway=footway,bicycle=yes(assuming "footway" implies
foot=designated) or as highway=path,foot=designated,bicycle=yes. No
Information loss, no difference, no problem. :-)

-Martin
&quot;Marc Schütz&quot;
2009-08-10 11:37:25 UTC
Permalink
Post by Martin Simon
It's not about allowing cycling(like official fooways that _also_
allow bicycles as "guests"), it's about official designation. This
makes, at least in Germany, a big (legal) difference...
So you could tag a footway which also allows bicycles as
highway=footway,bicycle=yes(assuming "footway" implies
foot=designated) or as highway=path,foot=designated,bicycle=yes. No
Information loss, no difference, no problem. :-)
... except that many people don't like your assumption and interpret it as foot=yes instead.

Regards, Marc
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Martin Simon
2009-08-10 11:45:29 UTC
Permalink
---------- Forwarded message ----------
From: Martin Simon <grenzdebil at gmail.com>
Date: 2009/8/10
Subject: Re: [OSM-talk] Proliferation of path vs. footway
To: Marc Sch?tz <schuetzm at gmx.net>
Post by &quot;Marc Schütz&quot;
... except that many people don't like your assumption and interpret it as foot=yes instead.
Well, you're right here, we can not assume a designation for footways
because in ancient OSM times nearly everything was tagged as a
footway... "don't change the meaning of existing tags" is nearly as
important as "don't tag for the renderer" ;-)

So just add an explicit foot=designated to my example.

-Martin
Martin Koppenhoefer
2009-08-10 12:28:39 UTC
Permalink
Post by Martin Simon
In the case of a combinet cycle and footway in germany, there is no
primary purpose, pedestrians and cyclists have equal rights on these
ways. So I tag "highway=path,bicycle=designated,foot=designated".
but it could be equally tagged as
highway=cycleway
foot=designated

OR:
highway=cycleway
foot=official

that latter was introduced (probably by the same people that already
forced path) to express designated (which was allegedly not used in a
proper way). In the end it seems, that every few month a new tag with
the same meaning of an already existing is introduced to solve the
problem of previously partly uncorrect associated tags. IMHO this
nonsense will not help getting more interpretable / reliable data.

cheers,
Martin
Alex Mauer
2009-08-11 00:55:12 UTC
Permalink
Post by Martin Simon
highway=cycleway
foot=official
that latter was introduced (probably by the same people that already
forced path)
Nope. Cbm and I were the ones behind highway=path, as you can see from
the wiki. Access=official has nothing to do with me. I agree that it's
redundant -- it seems like it's just a combination of
travelmode=designated and access=no.

Not sure how you think path was "forced" though. It had 34 votes, 22
for and 9 against (3 abstain). Nobody forced anything, we just used the
standard procedure.

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/286b1162/attachment.pgp>
Liz
2009-08-11 01:53:27 UTC
Permalink
Post by Alex Mauer
Not sure how you think path was "forced" though. It had 34 votes, 22
for and 9 against (3 abstain). Nobody forced anything, we just used the
standard procedure.
while this was the sort of number of votes that appear on the wiki, for a
project with tens of thousands of contributors, this doesn't make a mandate
(not even for the most determined politician)
Alex L. Mauer
2009-08-11 02:59:04 UTC
Permalink
Post by Liz
Post by Alex Mauer
Not sure how you think path was "forced" though. It had 34 votes, 22
for and 9 against (3 abstain). Nobody forced anything, we just used the
standard procedure.
while this was the sort of number of votes that appear on the wiki, for a
project with tens of thousands of contributors, this doesn't make a mandate
(not even for the most determined politician)
OK, but how does that mean it was "forced"? No one was (or is) held at
gunpoint and ordered to use highway=path. We followed the standard,
documented procedure for adding a tag to the wiki. We did nothing
nefarious to stuff the votes (at least I didn't, and I am not aware of
any sock-puppets or anything like that)

I don't even know where the idea of needing a mandate[1] comes in. No
one's being elected to represent someone else. There are no policies
that some hypothetical person who would have been elected could have
made public. And no goverment(!?) is trying to implement a policy here.
So, uh... what?

-Alex Mauer "hawke"

1. http://en.wikipedia.org/wiki/Mandate_(politics)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/1ef5090f/attachment.pgp>
Liz
2009-08-11 05:37:42 UTC
Permalink
Post by Alex L. Mauer
OK, but how does that mean it was "forced"? No one was (or is) held at
gunpoint and ordered to use highway=path. We followed the standard,
documented procedure for adding a tag to the wiki. We did nothing
nefarious to stuff the votes (at least I didn't, and I am not aware of
any sock-puppets or anything like that)
I don't even know where the idea of needing a mandate[1] comes in. No
one's being elected to represent someone else. There are no policies
that some hypothetical person who would have been elected could have
made public. And no goverment(!?) is trying to implement a policy here.
So, uh... what?
-Alex Mauer "hawke"
I was not making a personal attack. I am looking at the "rules" and I find
that neither justice nor good decision making is necessary with the rules as
they stand.
I am talking about making sure that changes are deliberated by a broader
church than current procedure demands.

As far as you are concerned you followed the rules.
However, by following those rules to the letter, you have actually been party
to a fairly big split.
Here it's winter, the nights are long and I have time to read the wiki and
mailing lists.
When its summer I won't be, I'll be out mapping and having a lot more fun.
So the next contentious issue you wish to get through, do it in my summer, so
I don't notice until late in winter.
Roy Wallace
2009-08-10 22:29:45 UTC
Permalink
Post by Martin Simon
So you could tag a footway which also allows bicycles as
highway=footway,bicycle=yes(assuming "footway" implies
foot=designated) or as highway=path,foot=designated,bicycle=yes. No
Information loss, no difference, no problem. :-)
Agreed.
Frank Sautter
2009-08-10 10:27:59 UTC
Permalink
Post by Tom Chance
I'm 100% unclear about the distinction between highway=path and
highway=footway.
the whole "highway=path"-thingy was victim of a "hostile takeover" ;-)

at the beginning highway=path was proposed as a something like a NARROW
highway=track for use by bike, foot, horse, hiking, deer (mainly in
non-urban areas).

highway=track is typically used in farmland or forest (non-residential)
areas and usable for 4-wheeled vehicles.
highway=footway is a footway in urban areas (beneath road, in parks,
between buildings, etc.)

we discussed about that following the last geofabrik workshop and came
to the conclusion to use highway=path in non-urban areas where the way
has only one groove and use highway=footway/bicycle in rural/residential
areas or when accompanying bigger roads.

cheers,
frank
Alex Mauer
2009-08-11 01:01:58 UTC
Permalink
Post by Frank Sautter
Post by Tom Chance
I'm 100% unclear about the distinction between highway=path and
highway=footway.
the whole "highway=path"-thingy was victim of a "hostile takeover" ;-)
It was? when did that happen? can you point to it in the wiki?
Post by Frank Sautter
at the beginning highway=path was proposed as a something like a NARROW
highway=track for use by bike, foot, horse, hiking, deer (mainly in
non-urban areas).
No it wasn't. Read the history at
http://wiki.openstreetmap.org/index.php?title=Approved_features/Path&dir=prev&action=history

Prior to that, I created the proposal "Trail" which was also not like
you describe. http://wiki.openstreetmap.org/wiki/Proposed_features/Trail

From the very beginning, it did not mean what you say it did. Maybe
you're thinking of something else?

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/eb38a5cb/attachment.pgp>
John Smith
2009-08-10 10:42:55 UTC
Permalink
Post by Tom Chance
for a new feature, do what you want! But it's crazy that we
let random
unaccountable groups of wiki users change the rules for
Maybe some pages on the wiki should be locked, and translations of mapping features shouldn't change the original meaning/intent of them.
sergio sevillano
2009-08-10 10:55:12 UTC
Permalink
Post by John Smith
Post by Tom Chance
for a new feature, do what you want! But it's crazy that we
let random
unaccountable groups of wiki users change the rules for
Maybe some pages on the wiki should be locked, and translations of mapping features shouldn't change the original meaning/intent of them.
i was going to suggest just that
Post by John Smith
_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Ulf Möller
2009-08-10 11:32:54 UTC
Permalink
Post by John Smith
Post by Tom Chance
for a new feature, do what you want! But it's crazy that we
let random
unaccountable groups of wiki users change the rules for
Maybe some pages on the wiki should be locked, and translations of mapping features shouldn't change the original meaning/intent of them.
That however doesn't solve the problem of random unaccountable groups of
wiki users voting on tagging proposals. Many "accepted features" have
had less than 20 votes, and some of the tags even are in broken English.

If you're saying translations can't change the meaning you need to make
sure that the original descriptions work for any place in the world. How
would you do that?
Nop
2009-08-10 10:49:47 UTC
Permalink
Hi!
Post by Tom Chance
I'm 100% unclear about the distinction between highway=path and
highway=footway.
The same discussion erupts regularly on the German mailing list, also
without results.

There is no agreement on whether to primarily use footway/cycleway (as
suggested by tag explanation) or whether to primarily use path (as
suggested in several German tagging guidlines).

The situation in Germany is rather tricky. The rules of traffic for
dedicated foot-ways and cycle-ways are very strict. A sign indicating
one type of use also implies that this use is compulsory and that all
other types of use are prohibited. Everything is mutually exlusive, but
multiple signs may be combined and there may be signs for exceptions.

- Some mappers want to depict this situation as precisely as e.g. oneway
regulations for cars and are using path and access=desigated/official to
to this.
- Some mappers believe that footway and cycleway should be used for this
purpose, but that either contradicts the much more lenient English
definition or does not depict the legal situation adequately, depending
on personal interpretation
- Some mappers are applying footway and cycleway rather indiscriminately
to all sorts of ways so it basically only means "not for cars" in some areas

In short: It's a mess. :-)

bye
Nop
Liz
2009-08-10 11:03:30 UTC
Permalink
Post by Nop
- Some mappers are applying footway and cycleway rather indiscriminately
to all sorts of ways so it basically only means "not for cars" in some areas
In short: It's a mess. :-)
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
path=cycleway
path=footway
path=shared
be logically consistent with the German legal status of cycleways and
footways?
Martin Simon
2009-08-10 11:17:19 UTC
Permalink
Post by Liz
Post by Nop
- Some mappers are applying footway and cycleway rather indiscriminately
to all sorts of ways so it basically only means "not for cars" in some areas
In short: It's a mess. :-)
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
path=cycleway
path=footway
path=shared
be logically consistent with the German legal status of cycleways and
footways?
What does path=shared stand for? Shared between cyclists and
pedestrians, pedestrians and horse riders or all three(as seen in
Belgium, for example)?

As highway=path was introduced to seperate the highway tag from the
access tags and allow tagging of the legal status more clearly(not
just in Germany), why not just use it as intended? This doesn't mean
we have to throw awy everything tagged with
footway/cycleway/bridleway...

-Martin
Elizabeth Dodd
2009-08-10 11:27:28 UTC
Permalink
Post by Martin Simon
Post by Liz
Post by Nop
- Some mappers are applying footway and cycleway rather indiscriminately
to all sorts of ways so it basically only means "not for cars" in some areas
In short: It's a mess. :-)
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
path=cycleway
path=footway
path=shared
be logically consistent with the German legal status of cycleways and
footways?
What does path=shared stand for? Shared between cyclists and
pedestrians, pedestrians and horse riders or all three(as seen in
Belgium, for example)?
As highway=path was introduced to seperate the highway tag from the
access tags and allow tagging of the legal status more clearly(not
just in Germany), why not just use it as intended? This doesn't mean
we have to throw awy everything tagged with
footway/cycleway/bridleway...
-Martin
The question is exploring the logic.
From your answer you want to know more about shared
It is hard to explore the logic with people vigorously defending a position
and not answering the question.
The underlying point is should highway be used at all where motorised vehicles
are not wanted?
At this stage we are just exploring the question, and asking if this different
system would fit in another place.
Lester Caine
2009-08-10 13:13:16 UTC
Permalink
Post by Liz
Post by Nop
- Some mappers are applying footway and cycleway rather indiscriminately
to all sorts of ways so it basically only means "not for cars" in some areas
In short: It's a mess. :-)
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
path=cycleway
path=footway
path=shared
be logically consistent with the German legal status of cycleways and
footways?
Following on from the 'discussion' on this list ...
drop highway=cycleway and highway=foot?

Add separate tracks for the footpaths associated with a highway
footway=side
footway=in_verge

I currently HAVE a highway=secondary, and now I need to add the detail such as
which side there is a 'sidewalk' or path isolated from the main way by a grass
verge. We ONLY need the one highway= as that provides the vehicle routing, but
that is not suitable for pedestrian use ( although it can be ). There are
sections of footpath running alongside the road, or in the verge, and the
pedestrian has to cross the road at some points to follow the safe footway ...
along with footpaths isolated from the main road, but which are the pedestrian
route associated with the 'highway'.

Separate cycleways get their own tags as well, which may also be the prefered
foot route, but I think that what is now adding to the confusion is creating
additional 'highway' routes, which are not really part of the 'highway' grid?
We separate waterway and indicate their tow-paths, but these really form part
of the footpath grid rather than the canal network.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lauris Bukšis-Haberkorns
2009-08-10 13:44:27 UTC
Permalink
Post by Lester Caine
Following on from the 'discussion' on this list ...
drop highway=cycleway and highway=foot?
That would be bad idea
Post by Lester Caine
Add separate tracks for the footpaths associated with a highway
footway=side
footway=in_verge
but this something that would be really great as most, but not all of
the roads have footways in one or both sides and that would make
tagging such thing easily.

This must be discussed, completed and accepted asap so more people
could start using it without fear that it would change..
http://wiki.openstreetmap.org/wiki/Proposed_features/Footway
Post by Lester Caine
I currently HAVE a highway=secondary, and now I need to add the detail such as
which side there is a 'sidewalk' or path isolated from the main way by a grass
verge. We ONLY need the one highway= as that provides the vehicle routing, but
that is not suitable for pedestrian use ( although it can be ). There are
sections of footpath running alongside the road, or in the verge, and the
pedestrian has to cross the road at some points to follow the safe footway ...
along with footpaths isolated from the main road, but which are the pedestrian
route associated with the 'highway'.
Separate cycleways get their own tags as well, which may also be the prefered
foot route, but I think that what is now adding to the confusion is creating
additional 'highway' routes, which are not really part of the 'highway' grid?
We separate waterway and indicate their tow-paths, but these really form part
of the footpath grid rather than the canal network.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Lester Caine
2009-08-10 14:16:56 UTC
Permalink
Post by Lauris Bukšis-Haberkorns
Post by Lester Caine
Add separate tracks for the footpaths associated with a highway
footway=side
footway=in_verge
but this something that would be really great as most, but not all of
the roads have footways in one or both sides and that would make
tagging such thing easily.
This must be discussed, completed and accepted asap so more people
could start using it without fear that it would change..
http://wiki.openstreetmap.org/wiki/Proposed_features/Footway
This is missing the point completely :(
Micro mapping needs to have a SEPARATE way for this. Just the short distance
between my own road and the next village has several changes of side and
position for the footpath, which simply adding tags to the existing ways does
not properly address!

This is a case of the distinct difference between 'highway' defines
everything, and mapping the actual features rather than guessing where they
are relative to some vaguely connected highway. If we are never going to
provide high resolution maps, then the guestimate method works, at some point,
actual road widths become important, as does additional features either side
of those roads?

Once you start adding this sort of fine detail it has to be done as a separate
object. Breaking up a simply way every time the footpath detail changes, and
then trying to combine that with additional ways where they fall a bit further
way from the road is what needs to be avoided?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Martin Koppenhoefer
2009-08-10 15:11:30 UTC
Permalink
Post by Lester Caine
Post by Lauris Bukšis-Haberkorns
This must be discussed, completed and accepted asap so more people
could start using it without fear that it would change..
http://wiki.openstreetmap.org/wiki/Proposed_features/Footway
This is missing the point completely :(
Micro mapping needs to have a SEPARATE way for this.
+1

cheers,
Martin
Pieren
2009-08-10 15:41:50 UTC
Permalink
On Mon, Aug 10, 2009 at 5:11 PM, Martin
Koppenhoefer<dieterdreist at gmail.com> wrote:

I can give the French interpretation of this, and it is quite closed
to the Italian and German's.
We use highway=footway when it is clearly designated for pedestrians
(indicated with
Loading Image...)
or when bikes are not allowed like in parks or around buildings. Most
of them are in urban zones. Same for cycleway which are designated for
bikers (pedestrians are just tolerated but there is a traffic sign
saying it is a cycleway).
We use highway=path when it is not designated for a particular type of
user and is narrower than a track (one vs two parallel dips). And most
of the time, we find them in rural zones.

Pieren
Martin Koppenhoefer
2009-08-10 23:56:00 UTC
Permalink
Post by Lester Caine
Post by Lauris Bukšis-Haberkorns
This must be discussed, completed and accepted asap so more people
could start using it without fear that it would change..
http://wiki.openstreetmap.org/wiki/Proposed_features/Footway
This is missing the point completely :(
Micro mapping needs to have a SEPARATE way for this.
+1
- - Separate way mean physical separation, not only a sidewalk
in the example he gave they were separated. Also there is at least the
kerb that is separating them (sometimes also grass, parking cars,
metal-barriers, ...). It depends on the kind of vehicle you use what
you consider a separation (think of wheelchairs). If the pavement is
not physically separated at all, but just by a line on the surface I
agree with you though. In these cases it is better to map just one way
and add tags.
- - There is th tame kind of feature for cycle
http://wiki.openstreetmap.org/wiki/Key:cycleway
I map cycleways separately if they are not just lanes on the street
but own ways.

cheers,
Martin
Jukka Rahkonen
2009-08-11 07:50:49 UTC
Permalink
Hi,

For my mind this starts to be far too complicated for most of the mappers and
users as well. Let's assume there is a smallish way/path/track or whatever it is
called. Anyway, something that is not meant for car traffic. I would believe
that majority of people would be satisfied if they just knew if they are allowed
to walk or cycle along that way/track/path. This need could be satisfied with
two toggle switches and four resulting combinations:
walking=yes/cycling=yes, walking=yes/cycling=no, walking=no/cycling=yes,
walking=no/cycling=no.

This information would be enough for me at least when walking or cycling in a
city. Other information that would be useful for more advanced and sophisticated
use could be given with additional tags. I can imagine myself feeding
information about paved/unpaved surface sometimes.
Lester Caine
2009-08-11 10:54:16 UTC
Permalink
Post by Jukka Rahkonen
Hi,
For my mind this starts to be far too complicated for most of the mappers and
users as well. Let's assume there is a smallish way/path/track or whatever it is
called. Anyway, something that is not meant for car traffic. I would believe
that majority of people would be satisfied if they just knew if they are allowed
to walk or cycle along that way/track/path. This need could be satisfied with
walking=yes/cycling=yes, walking=yes/cycling=no, walking=no/cycling=yes,
walking=no/cycling=no.
If one is just looking at the 'macro' level, then highway=footway/path for
those routes that have no connection to a vehicle way does make perfect sense,
but in many areas now, the basic grid structure of roads is now well
established, and we are looking to add finer detail. I have no problem with
highway=? for pedestrian only sections of that grid, but using the same for
micromapping the complex pavement/path structure AROUND a highway=? simply
does not make sense. One needs a simple filter like 'only display highway'
that removes the micromapping level of detail? MOVING existing highway=footway
to their own footway=path makes sense logically, but does introduce the
problem of how do you indicate these footpaths on lower scale maps.
Post by Jukka Rahkonen
This information would be enough for me at least when walking or cycling in a
city. Other information that would be useful for more advanced and sophisticated
use could be given with additional tags. I can imagine myself feeding
information about paved/unpaved surface sometimes.
I've already given the example in London where the VEHICLE routes have no
relevance to the pedestrian route, and it was looking at this that first
prompted me to suggest that 'footway=?' although exactly what goes in the ? is
a little vague. 'pavement' could probably be defined as a sidewalk linked to
the highway by a kerb, 'path' for something having grass verges either side,
perhaps with the highway=? having a sub tag of side:left=grass indicating that
the two are separated by grass, side:left=fence would then make sense where a
vehicle or pedestrian safety barrier exists. (Although left and right are
ambiguous to my way of thinking - on highway elements that can be going either
way, and reversing direction of a way may affect tags). A little aside here is
the indication of the high hedges that form the sides of many roads in - for
example - Cornwall. Some indication that in addition to 'no passing places'
there are actually no PEDESTRIAN safety areas comes into this micro mapping
detail?

I think that there needs to be a 'committee' to discuss the macro/micro
mapping differences required, but at the end of the day, the sub tagging
relating to 'pedestrian' details should be consistent. cycleway details should
then naturally layer into what ever structure is agreed?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lauris Bukšis-Haberkorns
2009-08-10 15:48:53 UTC
Permalink
Post by Lester Caine
This is missing the point completely :(
Micro mapping needs to have a SEPARATE way for this. Just the short distance
between my own road and the next village has several changes of side and
position for the footpath, which simply adding tags to the existing ways does
not properly address!
This is a case of the distinct difference between 'highway' defines
everything, and mapping the actual features rather than guessing where they
are relative to some vaguely connected highway. If we are never going to
provide high resolution maps, then the guestimate method works, at some point,
actual road widths become important, as does additional features either side
of those roads?
Once you start adding this sort of fine detail it has to be done as a separate
?object. Breaking up a simply way every time the footpath detail changes, and
then trying to combine that with additional ways where they fall a bit further
way from the road is what needs to be avoided?
I think that both ways should coexist. In city most of the roads have
footway just next to it and in these cases just adding footway=both
and footway.width=x (or what ever syntax is decided) will make things
a lot easier. In this case if adding separate ways for footway there
will be three times more ways and it will be really hard to maintain
such map if something changes. Also it will be easier to specify rules
to renderer as I think that not everyone will need to render footways
near ways while footways in parks are still important.
Of course footway proposal is not complete enough as I would like it
to see but that could be discussed.
I completely agree with you that it wont work in all situations so
both schemes should coexist. If we want later to move to one scheme
footway tag could be easily converted from footway=both + width (or
default width if not specified) to separate way.

Lauris
John Smith
2009-08-10 10:56:59 UTC
Permalink
Post by Martin Simon
makes, at least in Germany, a big (legal) difference...
That isn't the case in other places, in some states of Australia you are allowed to cycle on foot paths, but the primary purpose is for pedestrians and they have right of way over cyclists.

In other areas there are cycle paths and pedestrians are allowed but they aren't the primary users intended to use the way and cyclists mostly use them. So yes there would be information lost by simplifying things in the way you describe.
Post by Martin Simon
Information loss, no difference, no problem. :-)
That might be true for Germany, but it isn't for other parts of the world.
Ulf Möller
2009-08-10 11:14:59 UTC
Permalink
Post by John Smith
That isn't the case in other places, in some states of Australia you are allowed to cycle on foot paths, but the primary purpose is for pedestrians and they have right of way over cyclists.
foot=designated, bicycle=yes
Post by John Smith
In other areas there are cycle paths and pedestrians are allowed but they aren't the primary users intended to use the way and cyclists mostly use them. So yes there would be information lost by simplifying things in the way you describe.
bicycle=designated, foot=yes

No information lost there...
Roy Wallace
2009-08-10 22:33:01 UTC
Permalink
Post by John Smith
In other areas there are cycle paths and pedestrians are allowed but they aren't the primary users intended to use the way and cyclists mostly use them. So yes there would be information lost by simplifying things in the way you describe.
Is tagging the "primary users intended to use the way" verifiable? If
not, it shouldn't be tagged. If it is, then is footway/cycleway
necessarily the best way to tag it? (I'm unsure). How about a
compromise, e.g. for a "cyclists mostly use" path:

highway=path
bicycle=designated (or yes, if not signed)
foot=yes (or designated, if signed)
primary_use=bicycle

Just a suggestion. It does seem to be more explicit than inferring a
"primary use" from the highway=* value.
Martin Simon
2009-08-10 11:09:20 UTC
Permalink
Post by John Smith
Post by Martin Simon
makes, at least in Germany, a big (legal) difference...
That isn't the case in other places, in some states of Australia you are allowed to cycle on foot paths, but the primary purpose is for pedestrians and they have right of way over cyclists.
In other areas there are cycle paths and pedestrians are allowed but they aren't the primary users intended to use the way and cyclists mostly use them. So yes there would be information lost by simplifying things in the way you describe.
Well, I don't see why highway=path + proper access/designation tags
can be a simplification compared to a simple "cycleway" or "footway".
For your footway example, I would suggest either highway=footway,
bicycle=yes or highway=path, foot=designated("this is intended for
pedestrians by law"), bicycle=yes("bicycles are also allowed to use
this way, but only as guests").

We have this kind of footway (among other variants) here, too.
Post by John Smith
Post by Martin Simon
Information loss, no difference, no problem. :-)
That might be true for Germany, but it isn't for other parts of the world.
No, this can be used everywhere. :-)

-Martin
Tom Chance
2009-08-10 11:32:54 UTC
Permalink
Post by Martin Simon
Well, I don't see why highway=path + proper access/designation tags
can be a simplification compared to a simple "cycleway" or "footway".
For your footway example, I would suggest either highway=footway,
bicycle=yes or highway=path, foot=designated("this is intended for
pedestrians by law"), bicycle=yes("bicycles are also allowed to use
this way, but only as guests").
This is all very nice, but doesn't solve the problem - actually it
illustrates it.

You've just explained that there are two different ways of tagging the same
thing, and suggested that both are equally valid. That's pointless and
confusing.

Either we really do deprecate footway/cycleway/etc. and force people to
more fully describe these ways; tools like Potlatch and JOSM could offer
bundles of tags for common defaults like "this is a footpath, ergo
highway=path + foot=designated + bicycle=yes + motorbike=no".

Or we find a way to consistently qualify footway, cycleway, bridleway and
perhaps a new "highway=path" for miscellaneous little paths, to suit the
legal complications of 195 countries. But we don't start using highway=path
as a catch-all for footways, cycleways, bridleways and others just because
we can capture the same meaning using access, surface, width and other
tags.

Which do we go for? We can't have this stupid, unclear fudge.

Regards,
Tom
Martin Simon
2009-08-10 12:00:06 UTC
Permalink
Post by Tom Chance
This is all very nice, but doesn't solve the problem - actually it
illustrates it.
If you think having path and keep footway/cycleway/bridleway is a
problem: no, this "problem" can hardly ever be solved within OSM.
But it solves the problem of tagging these "minor ways" clearly.
Post by Tom Chance
You've just explained that there are two different ways of tagging the same
thing, and suggested that both are equally valid. That's pointless and
confusing.
What would you like to do? Force Mappers to use path? Automated
mass-retagging of existing footways/cycleways/bridleways?
Or just keep the "old" system because "there must not be another way
to do it, even if its more flexible"?
Post by Tom Chance
But we don't start using highway=path
as a catch-all for footways, cycleways, bridleways and others just because
we can capture the same meaning using access, surface, width and other
tags.
Why not? we can express the same, more flexible. And you know as well
as I do that this not about width and surface, so don't try to make
the "path" system look more complicated than it really is.
Post by Tom Chance
Which do we go for? We can't have this stupid, unclear fudge.
We can. We had this multiple times before. Think of address tagging
before the Karlsruhe Workshop breaktrough or different public
transport tagging(?).

This "problem" will get solved automatically by time if people don't
try to re-define long documented tags because they don't see thier
use...

-Martin
Tom Chance
2009-08-10 13:31:00 UTC
Permalink
Post by Martin Simon
Post by Tom Chance
You've just explained that there are two different ways of tagging the
same thing, and suggested that both are equally valid. That's pointless
and
Post by Martin Simon
Post by Tom Chance
confusing.
What would you like to do? Force Mappers to use path? Automated
mass-retagging of existing footways/cycleways/bridleways?
Or just keep the "old" system because "there must not be another way
to do it, even if its more flexible"?
It's important for OpenStreetMap to have some coherence.

It's quite important that you and I both agree that "chair" refers to a
piece of furniture on which we sit. Imagine if you used the word "chair" to
refer to a small furry pet that meows and likes fish! We can't have a
situation where - as others have pointed out - we have people using a
particular tag in many different ways.

It also helps if we stick to one way of describing any particular thing.
It's lovely that in England we have "cow shed" and "byre" and many other
phrases for the same object. But when you're writing a stylesheet for
Mapnik, or trying to download an extract, or writing a routing algorithm,
your task is made ten times more difficult if you have to keep adding lots
of alternative ways of describing the same thing.

We don't need to force anybody to do anything, but here are some basic ways
in we can encourage a more coherent approach:

- discussions at SOTM or regional meetings
- a well managed wiki (hah!)
- stylesheets for Mapnik and Tiles at Home (both a bit out of hand, as Andy
Allan says)
- presets in Potlatch and JOSM
- error checking tools
- even bots that try to correct very minor errors like s/cahtolic/catholic/

I would support removing highway=path from Potlatch and JOSM and the Mapnik
stylesheet until a wiki page is drawn up which unambiguously describes how
it should be used. If it duplicates or replaces existing tags, that should
be properly resolved.
Post by Martin Simon
Post by Tom Chance
Which do we go for? We can't have this stupid, unclear fudge.
We can. We had this multiple times before. Think of address tagging
before the Karlsruhe Workshop breaktrough
There's a big difference, Simon. Nobody had yet accepted any addressing
schema, none of the community mechanisms I listed above properly supported
any one approach, until the breakthrough. Now that approach is gradually
being properly supported. It's a case of the anarchic approach working
quite well, partly by luck.

In this case, you have a tag which duplicates and possibly replaces
existing tags; which nobody can agree on the definition for; and which is
interpreted by different tools in different ways. That's a big step
backwards.

Cheers,
Tom
Martin Simon
2009-08-10 15:04:38 UTC
Permalink
Post by Tom Chance
It's important for OpenStreetMap to have some coherence.
It's quite important that you and I both agree that "chair" refers to a
piece of furniture on which we sit. Imagine if you used the word "chair" to
refer to a small furry pet that meows and likes fish! We can't have a
situation where - as others have pointed out - we have people using a
particular tag in many different ways.
Agreed. The problem with path (the one I call a problem, too) is IMHO
that there are people who don't like this tagging scheme or think it's
unneccessary (which is not a problem for me), but instead of just not
using it and staying with footway/cycleway/bridleway, they think
"well, but its there and gets rendered, lets use it for something else
(e.g. "very narrow way in the forest") and change the wiki page".
*zap* - a small furry pet that meows and likes fish. ;-)
Post by Tom Chance
It also helps if we stick to one way of describing any particular thing.
It's lovely that in England we have "cow shed" and "byre" and many other
phrases for the same object. But when you're writing a stylesheet for
Mapnik, or trying to download an extract, or writing a routing algorithm,
your task is made ten times more difficult if you have to keep adding lots
of alternative ways of describing the same thing.
Yes, it helps, but it's IMHO better to come up with a new way to
describe something rather than changing the meaning of long-existing,
widely used and important tags...
Post by Tom Chance
We don't need to force anybody to do anything, but here are some basic ways
- discussions at SOTM or regional meetings
- a well managed wiki (hah!)
- stylesheets for Mapnik and Tiles at Home (both a bit out of hand, as Andy
Allan says)
- presets in Potlatch and JOSM
- error checking tools
- even bots that try to correct very minor errors like s/cahtolic/catholic/
Okay, no problem with that, as long as alternative ways of tagging
like highway=path are not treated as errors.
Post by Tom Chance
I would support removing highway=path from Potlatch and JOSM and the Mapnik
stylesheet until a wiki page is drawn up which unambiguously describes how
it should be used. If it duplicates or replaces existing tags, that should
be properly resolved.
That would be at least one step too far in my eyes. But a better wiki
page would be great.
Post by Tom Chance
There's a big difference, Simon. Nobody had yet accepted any addressing
schema, none of the community mechanisms I listed above properly supported
any one approach, until the breakthrough. Now that approach is gradually
being properly supported. It's a case of the anarchic approach working
quite well, partly by luck.
In this case, you have a tag which duplicates and possibly replaces
existing tags; which nobody can agree on the definition for; and which is
interpreted by different tools in different ways. That's a big step
backwards.
Simon is actually the last name ;)
Yes, this is a bigger move than the breaktrough of the Karlsruhe
Schema, but for example post_code=12345 was already quite popular, so
the Karlsruhe guys used addr:post_code=12345. In my opinion a good
decision, because it clearly showed that objects tagged this way refer
to the Karlsruhe Schema, which is well documented in the wiki.

We had a similar situation when highway=path started, before different
groups made up thier own definitions, differing from the original
proposal...

-Martin
Apollinaris Schoell
2009-08-10 14:42:36 UTC
Permalink
Post by Tom Chance
Which do we go for? We can't have this stupid, unclear fudge.
Yes we can it's OSM it's anarchy :)
Post by Tom Chance
Regards,
Tom
Nick Whitelegg
2009-08-10 13:51:24 UTC
Permalink
I'll say what I always say these days whenever this subject comes up :-)

That is, I believe the "highway" tag should represent the physical
surface, not the rights. My current views on this are:

highway=track - a dirt/stone track, theoretically usable for off road
vehicles (though not necessarily any legal right)
highway=path - a narrow path, typically with mud/stone surface
highway=path; surface=paved - a concrete path typically used in urban
areas, what most people are using "footway" for

Then, the actual rights should be defines using foot, horse, etc. foot=yes
has more or less become unusable, as different people mean different
things, so therefore foot should be no, private, permissive (use granted
by landowner) or designated (a legal right, such as a UK public footpath,
or - though my knowledge of German or Swiss law on rights of way is not
good - waymarked paths in Germany or Switzerland such as the "yellow
diamond" routes in the Schwarzwald or the red/white waymarked mountain
paths in Switzerland).

As an alternative to foot/horse etc one could use the "designation" tag
such as designation=public_footpath or public_bridleway,
designation=cycleway for an official cycleway, or (at a guess for
Switzerland, I may be wrong) "gelb", "rot/weiss" and "blau/weiss" for the
different types of path with different difficulties.

Things like highway=bridleway or cycleway I would prefer to see
deprecated, and replaced by path/track with surface/bicycle/horse tags,
though I still tag with them as that is the generally-accepted way of
tagging bridleways and cycleways.

Nick
Apollinaris Schoell
2009-08-10 14:57:14 UTC
Permalink
+1
Post by Nick Whitelegg
I'll say what I always say these days whenever this subject comes up :-)
That is, I believe the "highway" tag should represent the physical
highway=track - a dirt/stone track, theoretically usable for off road
vehicles (though not necessarily any legal right)
highway=path - a narrow path, typically with mud/stone surface
highway=path; surface=paved - a concrete path typically used in urban
areas, what most people are using "footway" for
Then, the actual rights should be defines using foot, horse, etc. foot=yes
has more or less become unusable, as different people mean different
things, so therefore foot should be no, private, permissive (use granted
by landowner) or designated (a legal right, such as a UK public footpath,
or - though my knowledge of German or Swiss law on rights of way is not
good - waymarked paths in Germany or Switzerland such as the "yellow
diamond" routes in the Schwarzwald or the red/white waymarked mountain
paths in Switzerland).
As an alternative to foot/horse etc one could use the "designation" tag
such as designation=public_footpath or public_bridleway,
designation=cycleway for an official cycleway, or (at a guess for
Switzerland, I may be wrong) "gelb", "rot/weiss" and "blau/weiss" for the
different types of path with different difficulties.
Things like highway=bridleway or cycleway I would prefer to see
deprecated, and replaced by path/track with surface/bicycle/horse tags,
though I still tag with them as that is the generally-accepted way of
tagging bridleways and cycleways.
Nick
_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Nop
2009-08-10 14:06:12 UTC
Permalink
Hi!
Post by Liz
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
I think we should step back one step.

The discussion here seems about to fall victim to the same mechanisms
that produced the present chaos. Different people/groups think they have
solved the problem for their (local) use cases and are arguing in favor
of their solution, which usually involves interpreting existing tags in
a specific way. I am glad that this topic has come up - and of course I
have my own ready-made suggestion for a solution - but I suggest we look
at the problems and goals again before we go for a specific solution
attempt.


I think the main questions are:

- Can we agree on a common interpretation of what foot/cycleway are
supposed to mean?
- Do we want a general meaning for every country, delegating local
specifics to other tags, or a local meaning dependent on a countries
specific conditions?

- Can we use the existing access-Tags to describe the exact rules of
traffic e.g. in Germany (which seems to have the highest requirements so
far) and agree on the meaning there, too, or do we need to invent a
whole new scheme for local specifics?

- Do we tag generic trails as highway=path or does this tag have a more
complex meaning?

Can we try to discuss the problem at this level before proposing
detailed tagging schemes?


There is also the questions which is important but should not be mixed in:

- how can we get a coherent tagging model for OSM?


bye
Nop
Emilie Laffray
2009-08-10 14:14:29 UTC
Permalink
2009/8/10 Nop <ekkehart at gmx.de>
Post by Nop
Hi!
Post by Liz
would a suggestion made on the talk-au list in which highway=footway and
highway=cycleway be deprecated and be replaced by
I think we should step back one step.
The discussion here seems about to fall victim to the same mechanisms
that produced the present chaos. Different people/groups think they have
solved the problem for their (local) use cases and are arguing in favor
of their solution, which usually involves interpreting existing tags in
a specific way. I am glad that this topic has come up - and of course I
have my own ready-made suggestion for a solution - but I suggest we look
at the problems and goals again before we go for a specific solution
attempt.
- Can we agree on a common interpretation of what foot/cycleway are
supposed to mean?
- Do we want a general meaning for every country, delegating local
specifics to other tags, or a local meaning dependent on a countries
specific conditions?
- Can we use the existing access-Tags to describe the exact rules of
traffic e.g. in Germany (which seems to have the highest requirements so
far) and agree on the meaning there, too, or do we need to invent a
whole new scheme for local specifics?
- Do we tag generic trails as highway=path or does this tag have a more
complex meaning?
Can we try to discuss the problem at this level before proposing
detailed tagging schemes?
- how can we get a coherent tagging model for OSM?
+1 For the general email.
Agreeing on the definition first is always a good first step to construct
something.

Emilie Laffray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/e8146f0b/attachment.html>
Tom Chance
2009-08-10 14:37:21 UTC
Permalink
Post by Nop
- Can we agree on a common interpretation of what foot/cycleway are
supposed to mean?
- Do we want a general meaning for every country, delegating local
specifics to other tags, or a local meaning dependent on a countries
specific conditions?
- Can we use the existing access-Tags to describe the exact rules of
traffic e.g. in Germany (which seems to have the highest requirements so
far) and agree on the meaning there, too, or do we need to invent a
whole new scheme for local specifics?
- Do we tag generic trails as highway=path or does this tag have a more
complex meaning?
Can we try to discuss the problem at this level before proposing
detailed tagging schemes?
- how can we get a coherent tagging model for OSM?
+1 to the above.

Incidentally, I personally think that Nick Whitelegg's reasoning is sound,
and that ideally something like the path proposal *should* replace and
deprecate footway, cycleway, etc.

But we really need to change the way we develop our tags, so that a more
sensible procedure along the lines Nop proposed can actually be
implemented. I'm going to start a new thread with a thought on that.

Regards,
Tom
Roy Wallace
2009-08-10 23:12:10 UTC
Permalink
Post by Nop
- Can we agree on a common interpretation of what foot/cycleway are
supposed to mean?
I highly doubt it, because highway=footway and highway=cycleway are
quite vague, and infer different things to different people. And while
a clear definition on the wiki is all that would theoretically be
required to make them work, it seems this won't be easy to agree on.

I therefore prefer deprecation of these tags in favour of highway=path
with tags to *explicitly* state what the situation is for that
particular way - "tag as simply as possible, but no simpler".
Post by Nop
- Do we want a general meaning for every country, delegating local
specifics to other tags, or a local meaning dependent on a countries
specific conditions?
If you *explicitly* state the situation on the ground, worldwide
consensus is possible.
Post by Nop
- Do we tag generic trails as highway=path or does this tag have a more
complex meaning?
I don't think there is any such thing as a "generic trail". I think
highway=path should simply imply that the way is a physical route used
for travel but not suitable for cars. Additional tags seem to be
necessary to describe details, if available.
Post by Nop
- how can we get a coherent tagging model for OSM?
I think some more guidelines as to "what makes a good tag/tagging
scheme" could be helpful to guide us. There seems to be no shortage of
ideas but rather the problem is when we try to judge one idea against
another. I'm constantly referring to "verifiability", but I'm sure
there are other important criteria.

I'm also looking forward to Google Wave as a means of collaboration.
The current approach of wiki and email lists clearly isn't optimal for
nutting out these issues.
Jacek Konieczny
2009-08-11 07:05:44 UTC
Permalink
Post by Roy Wallace
Post by Nop
- Do we tag generic trails as highway=path or does this tag have a more
complex meaning?
I don't think there is any such thing as a "generic trail". I think
highway=path should simply imply that the way is a physical route used
for travel but not suitable for cars. Additional tags seem to be
necessary to describe details, if available.
Then why don't we use just 'highway=road' for any physical route that is
suitable for cars? With your reasoning highway=motorway, highway=trunk,
highway=residental, etc. are unnecessary, as the properties can be
described with other tags? But we have the another layer of abstraction
and I think it proved useful. We could define motorway by its surface,
width, number of lanes, vehicles which are allowed and which are not,
but this does not make things simple and would make interpretation of
the map very hard. Classifying ways into
motorways/primary/secondary/residental makes things simpler.

The same should be true for ways useful or dedicated for pedestrians and
cyclists.

IMHO path should be the same thing for foot/cycleways what a 'track' is
for 4-wheel vehicles. Higher-level ways should be tagged as
footway/cycleway/pedestrian.


Greets,
Jacek
Roy Wallace
2009-08-11 07:17:00 UTC
Permalink
Post by Jacek Konieczny
Post by Roy Wallace
I don't think there is any such thing as a "generic trail". I think
highway=path should simply imply that the way is a physical route used
for travel but not suitable for cars. Additional tags seem to be
necessary to describe details, if available.
Then why don't we use just 'highway=road' for any physical route that is
suitable for cars? With your reasoning highway=motorway, highway=trunk,
highway=residental, etc. are unnecessary, as the properties can be
described with other tags? ?But we have the another layer of abstraction
and I think it proved useful. We could define motorway by its surface,
width, number of lanes, vehicles which are allowed and which are not,
but this does not make things simple ?and would make interpretation of
the map very hard. Classifying ways into
motorways/primary/secondary/residental makes things simpler.
Yes, I agree, we need to find a balance. But regardless of whether you
think motorways/trunk/primary/secondary/tertiary/residential/unclassified/track
is a "simple" system, it doesn't mean it doesn't have its flaws, not
does it mean that footway/cycleway/path doesn't have its flaws.

The ONLY thing I demand is a clear, verifiable description of each tag
on the wiki, which I would argue we are still lacking. Anything beyond
that is a bonus.
Lauri Kytömaa
2009-08-10 16:29:22 UTC
Permalink
Post by Nop
I think we should step back one step.
The discussion here seems about to fall victim to the same mechanisms
Trying to keep my comment general at first to find what are the needs:
what should be in the highway tag and what are "local factors". This
turned into a stream of thoughts but hopefully coherent enough to
breed some more refined thoughts.


Things that all agree on:

highway=footway:
Something, where walking is allowed and possible for someone.
(walking might be and is allowed and possible elsewhere, too)

highway=cycleway:
something, where cycling is allowed and possible
(even a German dedicated/signposted cycleway fits that description,
i.e. it's not a oneway dependency - not all things tagged
highway=cycleway are german signposted cycleways). Pedestrian access
undefined - might be country dependent but not supported (yet), so
there has about always been a suggestion in the wiki to always tag it
with foot=no/yes/designated.

highway=path:
something not wide enough for four wheeled vehicles OR where
motorvehicles are forbidden (unless otherwise indicated by
snowmobile/agricultural=designated or similar).

Anything with
wheelchair=no: unsuitable for wheelchair users or other mobility
impaired

Anything with
highway=footway + foot=no (+ snowmobile=yes) would be silly

highway=track
implies that it's wide enough for a small motorcar to drive on,
even if it's illegal.



Things that people don't agree on:

1) Is a highway=cycleway + foot=yes any different from a
highway=footway + bicycle=yes
2) Is it significant if there signs read "footway + bicycle allowed"
or "combined foot and cycleway" (presumably a difference in the legal
"maxspeed" at least in Germany)
3a) is a forest trail any different from a paved sidewalk
3b) is a forest trail any different from an unpaved but built footpath
4) is a constructed way with the traffic sign "no motorvehicles" any
different from a constructed way with the traffic sign "combined foot
and cycleway" (or with a cycleway-signpost in the UK)



User needs:
Pedestrian / Cyclist / Horse rider / Urban planner / Statistician /
Safety engineer / Accessibility analyst / Crime investigator ...

A pedestrian considers mostly the surface and the build quality of the
ways _allowed_ to him. A trail in an urban forest (picture 1), formed
by repeated use only, is not usable for an average pedestrian, even if
a normally fit person in sneakers would go for a walk there sometimes,
even if only to walk the dog. A mountain trail is effectively the same,
even if more difficult to use. Just about every person, even in (very)
high heels would walk down (picture 2) if the way hasn't turned into a
puddle of mud. And a western world way constructed for walking usually
doesn't deteriorate that much. Then there's the third variant
in-between (3), which some would use and other's wouldn't.

1) Loading Image...
2) Loading Image...
3) Loading Image...

Some cyclist disregard access rights and consider the surface and hills
only, while others would want to drive on dedicated cycleways only; on
those where only cyclists are allowed. Most common cyclist probably
don't care if there are pedestrians involved, they just wan't to use
legal and properly built ways and avoid driving amongst the cars.


Horse riding is something to think about, too.

For signposted bridleways it's quite unambiguous, even if a British
bridleway allows pedestrians and cyclists, too, whereas the German
(and Finnish) legally signposted bridleways allow neither.

But on a built way signposted as "no motor vehicles" horse riding might
be legal, but if it's signposted as a footway, cycleway or the
"combined foot and cycleway" (picture 4), horse riding is not allowed.
4) Loading Image...

On the forest trails (picture 1 again) horse riding might again be
legal or private/permissive. If the picture 2 didn't have the "no
horses" sign, I'd think around here that it's legal to ride a horse
there.

City planners possibly need to consider if the way is signposted for
combined use or with a "no motor vehicles" - first ones the city might
have to keep in good walking condition to avoid expenses when someone
breaks his bike because of the unfixed potholes but the latter ways
don't possibly carry such limitations. On the other hand that doesn't
usually interest the cyclists at all even if it is so.

This can and does have implications when dedicing where to build the
light traffic ways in the next suburb to be built - or where to add new
cycleways to improve the percentage of cycling commuters.

Statisticians and safety engineers could want to know whether
(un)segregated shared use paths have more fatalities or broken legs
(or wild angry goose or ice cream eaters) than some other ways allowed
to cyclists and/or pedestrians. They're interested in all the details:
surface, lit, hills, signs, segregation line, potholes etc. so that
they can calculate the significance factor for each variable.

For accessibility analysis the various signs (the shared use/only
cyclists) and such matter because of the implied allowed speeds
(they don't have specific numeric limits, but a shared use way
requires the cyclists to "drive carefully" (or something to that
effect) whereas the dedicated cycleways have no limits. Yet other
factors affect speeds, too.

Crime investigation could consider the legal status of the way after a
crash, what is or was the access restriction, as in was the pedestrian
allowed to be there or could he have been expected to be there - but
they'd use the city planning authorities data anyway or check the place
themselves. Analysis of potential escape routes could consider physical
obstructions only - where could the thieves have gone - but is unlikely
done on osm data (yet).

Conclusion:

Some users care most about whether it's a built way or not, others want
to know what the sign was (are there likely users of other transport
methods) and some care only "Am I allowed or not?"

Alv
John Smith
2009-08-11 03:10:52 UTC
Permalink
OK, but how does that mean it was "forced"?? No one
was (or is) held at
gunpoint and ordered to use highway=path.? We followed
the standard,
documented procedure for adding a tag to the wiki.? We
did nothing
nefarious to stuff the votes (at least I didn't, and I am
not aware of
any sock-puppets or anything like that)
Forced is probably the wrong word, gamed the system is what I would have said.

If there is over 100,000 accounts and at least 1% of them actively map and have actively mapped for over 1 year 30 or 40 votes compared to a possible 1000 participants isn't a very indicative outcome.

The current system is flawed when it comes to making decisions on complex issues, this is why democracies aren't democracies, nothing would ever be decided if everyone had a vote on everything. Instead we have republics where a few are elected or nominated to make the decisions.
Alex L. Mauer
2009-08-11 04:23:07 UTC
Permalink
Post by John Smith
Forced is probably the wrong word, gamed the system is what I would have said.
The system was used exactly as it was intended. It's not my fault if
few people choose to participate.
Post by John Smith
If there is over 100,000 accounts and at least 1% of them actively map and have actively mapped for over 1 year 30 or 40 votes compared to a possible 1000 participants isn't a very indicative outcome.
We only reached 100,000 accounts this year. When the final vote was
registered on highway=path (May 2008) we were at 35000 users. Not all
of those who map also use the wiki regularly. Your "possible 1000
participants" is a very high estimate, I would say. Regardless...
Post by John Smith
The current system is flawed when it comes to making decisions on complex issues, this is why democracies aren't democracies, nothing would ever be decided if everyone had a vote on everything. Instead we have republics where a few are elected or nominated to make the decisions.
No arguments with this, but would would you have had us do? I'm pretty
sure there'd be even more screaming if we'd just unilaterally changed
the wiki. Do nothing? Despite some peoples' objections, it certainly
does fill a need. If you have a proposal for a better system (and I'm
pretty sure that doesn't include any kind of wiki masters who get to
decide what's useful and what's not), I'm sure we'd be happy to hear it.

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090810/b9485650/attachment.pgp>
John Smith
2009-08-11 04:39:24 UTC
Permalink
Post by Alex L. Mauer
If you have a proposal for a better
system (and I'm
pretty sure that doesn't include any kind of wiki masters
who get to
decide what's useful and what's not), I'm sure we'd be
happy to hear it.
I'm in agreement with Tom's suggestion of a working group, however they should have the ability to make decisions they come to stick, true democracies fail from everyone having their own agendas.

I don't think anything should be voted on in person at a SOTM, this discriminates against those that can't be there. I also don't think a prerequisite of OSMF membership to be on a working group as this also discriminates against those that can't afford the membership fee.

Outline the responsibilities and such of the working group, ask for people to nominate themselves, have a limited number of positions on the working group and they act to filter all future proposals, anything that seems reasonable should be discussed, properly worked out.

Once there is a formal proposal it should be put out for a comment period in which anyone can discuss their thoughts on the matter, and from this either the proposal is refined or moves to become official.
Roy Wallace
2009-08-11 05:03:37 UTC
Permalink
Post by John Smith
I'm in agreement with Tom's suggestion of a working group, however they should have the ability to make decisions they come to stick, true democracies fail from everyone having their own agendas.
Define "stick" i.e. no one can force people to tag in a certain way,
so what are you referring to? Just the wiki or something else? This
worries me a bit...
Post by John Smith
Outline the responsibilities and such of the working group, ask for people to nominate themselves, have a limited number of positions on the working group and they act to filter all future proposals, anything that seems reasonable should be discussed, properly worked out.
This sounds fine. Basically what seems to be going on here is that,
firstly, if someone is given a "role", there is an assumption they
will provide a more valuable contribution. And secondly, that this
structure will provide more useful discussion than the completely
unstructured solution at the moment - the emailing list. Seems
reasonable.
Post by John Smith
Once there is a formal proposal it should be put out for a comment period in which anyone can discuss their thoughts on the matter, and from this either the proposal is refined or moves to become official.
Doesn't seem to be any different to the current situation. I guess it
comes down to what you mean by the ability of a working group to "make
decisions stick".
John Smith
2009-08-11 05:11:30 UTC
Permalink
Post by Roy Wallace
Define "stick" i.e. no one can force people to tag in a
certain way,
so what are you referring to? Just the wiki or something
else? This
worries me a bit...
I'm talking about a basic subset of tags that are commonly used, such as normally found on the mapping features wiki page. I'm not talking about forcing anyone to do anything, but simply have a way to facilitate a common consistent set of basic tags that describe 80 to 90% of the things people tag.
Roy Wallace
2009-08-11 05:21:46 UTC
Permalink
Post by John Smith
I'm talking about a basic subset of tags that are commonly used, such as normally found on the mapping features wiki page. I'm not talking about forcing anyone to do anything, but simply have a way to facilitate a common consistent set of basic tags that describe 80 to 90% of the things people tag.
Ah, so you're proposing basically a one-off overhall of the set of
basic tags, after which everything returns to normal (i.e. relative
chaos)?
John Smith
2009-08-11 05:35:11 UTC
Permalink
Post by Roy Wallace
Ah, so you're proposing basically a one-off overhall of the
set of
basic tags, after which everything returns to normal (i.e.
relative
chaos)?
No, I'm proposing that a working group be setup and work through existing and new proposals. The idea is they will vet ideas before they become available for public comment, this will fix the problem with broken english proposals and problems in translating them later.

If the working group thinks an idea is a valid one for the "common set of tags" then things will progress from there.

It should be discouraged that editors and other software show non-vetted tags to maintain a consistency.
Liz
2009-08-11 05:46:38 UTC
Permalink
Post by John Smith
No, I'm proposing that a working group be setup and work through existing
and new proposals. The idea is they will vet ideas before they become
available for public comment, this will fix the problem with broken english
proposals and problems in translating them later.
If the working group thinks an idea is a valid one for the "common set of
tags" then things will progress from there.
It should be discouraged that editors and other software show non-vetted
tags to maintain a consistency.
and a working group should contain members from all over the globe, as
possible, because of the differences in legal issues in different places
and yes, it needs members who are native speakers of major world languages to
help with translation into Spanish, German, French and so on
Martin Koppenhoefer
2009-08-11 14:08:51 UTC
Permalink
Post by Liz
and a working group should contain members from all over the globe, as
possible, because of the differences in legal issues in different places
and yes, it needs members who are native speakers of major world languages to
help with translation into Spanish, German, French and so on
thanks for considering German a "major world language" ;-).
Fortunately there are so many Germans in the "OSM-world", that this is
not an issue for them. In Italy it is a problem though, to translate
all the pages that appear in the wiki into Italian, not to mention the
effort to keep them up-to-date (which is an even more timeconsuming
job). Nonetheless also the italian community is trying their best to
have at least the most important stuff translated, and I completely
agree that local translations are one of the keys of getting the
system work in a country.

cheers,
Martin
Lauri Kytömaa
2009-08-11 08:20:00 UTC
Permalink
Post by Roy Wallace
Is tagging the "primary users intended to use the way" verifiable? If
not, it shouldn't be tagged. If it is, then is footway/cycleway
As fine as it as a guideline, verifiability as a topic and was
introduced into the wiki only in 2009, while footway and cycleway have
been successfully used since ... the beginning.

But anyway, primary intended users are those for whom the way is signed
as being for (cycleway, footway) - convention was to choose the most
demanding mode of transport when it's equally for both, for example
for the combined cycleway and footway. This just wasn't written properly
in the tag documentation until sometime in winter 2007/2008 or
thereabouts.

_When not signed for anyone_ but where local legislation allows cyclists
on such routes, people used local judgement to decide whether the way
was built as being suitable for the common cyclist. Some claim that one
couldn't know what others consider suitable, but I hold the view that
most people can relate to what others think, if they have ever ridden a
bicycle after childhood. The best example I've come up with so far is
that if your mother asked "should I cycle on it" you'd instantly know
the answer (most of the time anyway):
"definitively" (cycleway) or
"you could" (footway + bicycle=yes) or
"no, you shouldn't" (footway)

Sometimes this did lead to ways being later changed to the other
classification, but likewise some (very few but anyway) roads are changed
between unclassified/tertiary depending on each user's view of the
interconnecting function of that road - or of width or of legal
classification.

Alv
Shaun McDonald
2009-08-11 09:13:46 UTC
Permalink
Post by Lauri Kytömaa
Post by Roy Wallace
Is tagging the "primary users intended to use the way" verifiable? If
not, it shouldn't be tagged. If it is, then is footway/cycleway
As fine as it as a guideline, verifiability as a topic and was
introduced into the wiki only in 2009, while footway and cycleway have
been successfully used since ... the beginning.
Even so the on the ground rule and verifiability have not been on the
wiki for long. They have been the unwritten norms of the community
since the beginning. With various topics being brought up on the
mailing list, these unwritten community norms are being written down
so that everyone can see them. It is also part of the process of the
community maturing.

Shaun

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090811/2c9b34f5/attachment.bin>
Lauri Kytömaa
2009-08-11 10:00:14 UTC
Permalink
Post by Lauri Kytömaa
As fine as it as a guideline, verifiability as a topic and was
Even so the on the ground rule and verifiability have not been on the wiki
for long. They have been the unwritten norms of the community since the
I'm all for referring to that verifiability where it comes to legal and
physical attributes (e.g. access=yes/designated/no or building:levels or
width), yet trying to squeeze by force the old tags to comply - to the
letter - to that norm seems counter productive. As with car access on
very rough tracks: there could be tens of tags to describe the ground
clearance, wheel size and suspension travel etc. required to get through,
but instisting people start measuring them is too much work that anyone
else would start doing so - users require something simplified from that -
even if there's no widely accepted solution yet.

The description of a way for other users than cars varies on multiple axes
and fitting all that into one tag seems impossible; yet it's most of the
time reasonable and simple to divide the decision space into two sets:
cycleway and footway and use additional tags from there on. Some ways then
are borderline cases or sufficiently outside of those two sets that they
necessitate some other solution.

Most of the time the intended use is unambiguous, either signedposted or
evident from the location or structure. Where it's not, I trust people can
classify things on a closed scale, even if with some personal judgement
And to make those cases easier, there is a need for something in addition
to the footway/cycleway pair.

(Where does a coniferous forest turn into a mixed forest? One birch? One
birch for every ten pinetrees? 25:75 distribution?)

Much of the discussion would have been avoided if the documentation of
footway and cycleway had been more exact already in the fall 2007 - it
took me then quite a lot of reading to get to the logic and implications
behind them, and many don't read that much of the scattered documentation
which has lead to some of the pages having been changed around and
misconceptions.

The big question is just how can that be fixed?

Alv
Nick Whitelegg
2009-08-11 10:08:21 UTC
Permalink
Roy Wallace <waldo000000 at gmail.com>
Sent by: talk-bounces at openstreetmap.org
10/08/2009 23:2

To
Martin Simon <grenzdebil at gmail.com>
cc
talk <talk at openstreetmap.org>
Subject
Re: [OSM-talk] Proliferation of path vs. footway
Post by Martin Simon
So you could tag a footway which also allows bicycles as
highway=footway,bicycle=yes(assuming "footway" implies
foot=designated)
The thing is though it doesn't necessary imply this. There are examples of
highway=footway which are *private* paths not accessible legally to the
public (or only through payment of an entrance fee) e.g. the paths within
a paid-for tourist attraction (Marwell Zoo is a local example for me) or
the paths on a private housing estate.
Post by Martin Simon
or as highway=path,foot=designated,bicycle=yes. No
Information loss, no difference, no problem. :-)
TBH I'd deprecate "yes" because it's got too much ambiguity. Ask yourself:
is there a *legal right* for that mode of transit to use that path, or is
it at the discretion of the landowner (who could be a private landowner,
or a council or government). If the former, use "designated". If the
latter, use "permissive".

So a paved (concrete) cycle path where cyclists have a legal right and
pedestrians don't, could be

highway=path; surface=paved; bicycle=designated; foot=no

or if both have a legal right

highway=path; surface=paved; bicycle=designated; foot=designated

or if cyclists are allowed by an informal (and often retractable)
permission of the landowner, whereas pedestrians have a legal right:

highway=path; surface=paved; bicycle=permissive; foot=designated

I believe that this would work anywhere in the world, as I would imagine
that all modes of transit have either a right, an informal/retractable
right, or no right to use a given way. Please correct me if I'm wrong
though.

Nick
Pieren
2009-08-11 10:38:46 UTC
Permalink
On Tue, Aug 11, 2009 at 12:08 PM, Nick
Whitelegg<Nick.Whitelegg at solent.ac.uk> wrote:
keep things simple : use footway, cycleway, bridleway for designated
foot, bicycle, horse and use path for everything else.
Post by Nick Whitelegg
So a paved (concrete) cycle path where cyclists have a legal right and
pedestrians don't, could be
highway=path; surface=paved; bicycle=designated; foot=no
or highway=cycleway
+ http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
Post by Nick Whitelegg
or if both have a legal right
highway=path; surface=paved; bicycle=designated; foot=designated
or highway=path; surface=paved
Post by Nick Whitelegg
or if cyclists are allowed by an informal (and often retractable)
highway=path; surface=paved; bicycle=permissive; foot=designated
or highway=footway; surface=paved
+ http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

Pieren
Morten Kjeldgaard
2009-08-11 11:41:56 UTC
Permalink
Hi,

It seems to me that tags have proliferated because as time has gone
by, people have invented more-and-more uses for OSM -- and that is good!

However, it is a problem because mappers are trying to accomplish very
different things from the same set of tags. Here is a set of distinct
problems I can think of off the top of my head:

* Classical map features. Cities, roads, forests, ferrylines. Where
does a road/path lead? How do I get from A to B? Bridges, railway
crossings, etc.
* Legal rights. Is this road accessible to the public? Am I allowed
to drive a car here? Bicycle? Horse?
* Administrative: Who owns this road/area and who takes care of it?
* Terrain. Is this road suited for bike-racing? Mountain bikes?
4WDs? Is it steep? How steep?
* Surface: paved, gravel, grass sand?
* Environmental: Chemical/Radioactive pollution?
* Security: where is there a phone, hospital, mountain shelter? Wild
animals?

So it appears there is also an evolutiont in tags to encompass more
and more of these distinct (and useful!) pieces of information, but
unfortunately tags are being added in a ad-hoc manner to solve
particular problems without concerns of maintaining a reasonable
namespace. The addr: namespace is a good example of how a set of
complicated tags can be grouped so they don't interfere with other
requirements.

As time goes by, who knows what OSM will be used for? Perhaps the
public works of some city decides to put their water and electricity
lines on the map? Perhaps some agricultural agency wants to use OSM
for soil characteristics?

The highway=footway is IMHO an alias for the more complex highway=path
foot=yes surface=paved etc. construction. I think aliases are
perfectly legitimate constructs when dealing with very common
situations, and furthermore, much easier for newbies to remember and
deal with.

Perhaps it would be constructive to discuss the tagging structure
considering the various purposes tags have, and in line with the good
example set by the addr: namespace. For example, national OSM teams
might have access to their own name spaces, for example fr: (France)
de: (Germany) etc.; this would eliminate discussions of the differing
interpretations of certain tags that now occupy a lot of the bandwith
of this ML.


Cheers,
Morten
John Smith
2009-08-11 10:16:47 UTC
Permalink
Post by Nick Whitelegg
The thing is though it doesn't necessary imply this. There
are examples of
highway=footway which are *private* paths not accessible
legally to the
public (or only through payment of an entrance fee) e.g.
the paths within
a paid-for tourist attraction (Marwell Zoo is a local
example for me) or
the paths on a private housing estate.
You don't need a new set of tags, just use.

access=private
Lauri Kytömaa
2009-08-11 11:29:56 UTC
Permalink
Quote Key:highway:
"It is a very general and sometimes vague description of the importance
of the highway."
(Was until last week:)
" ... of the physical structure of the highway".

Either way, the highway tag itself should (IMO) convey they primary
description of the highway - the distinction between two highway tags
should be significant, not just a different sign if the allowed foot/cycle
users are the same.

For a cycling user (prove me wrong!) it's not important if the light
traffic way where he may cycle is signed as "no motor vehicles" or
"cycleway" or "combined cycle and footway". A router (yeah, it's not the
only use for map data) may choose to prefer some type of those over others
if they think there's some reasonable difference in expected travel speeds
- but it's not the main attribute of the way. Given other tags are the
same (at least surface, width, lit) they're all alike; for pedestrians
too.

If that user is on foot, it's even more so, if there's a foot=yes on
the cycleways or if it is assumed default. There's a much bigger
difference between ways planned and constructed for pedestrian and
cycle traffic vs. the ways that have emerged from erosion caused by
people walking that way.

My point: I don't see a point in _not_ tagging ways such as these:
Loading Image...
and
http://wiki.openstreetmap.org/wiki/Image:Path-lighttraffic.jpg
as cycleways with either foot=yes or foot=designated, respectively.
--
Alv
Loading...