[Tagging] Feature Proposal - RFC - Sidewalks as separate ways

David Paleino dapal at debian.org
Fri Mar 25 08:37:17 GMT 2011

No need to CC me, thanks.

On Thu, 24 Mar 2011 20:00:34 -0400, Serge Wroclawski wrote:

> On Thu, Mar 24, 2011 at 4:15 PM, David Paleino
> <dapal at debian.org> wrote:
> > Hello everybody,
> > as promised, I came back with an "official" proposal.
> >
> >  http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way
> "In particular, for blind people, it's important to have precise
> information when walking: to understand on which side of the street
> they are, for example. This is not possible when just adding tags to
> the main way -- a separate way ought to be mapped."
> My general frustration with your RFC is that it reads more as a stance
> than a proposal. I think that this issue of the blind, for example, is
> a bit of a false dichotomy, because the issue of sidewalk direction is
> handled in both methods"
> One can take exactly the opposite stance, which is that in order to
> help the blind, we should make it as easy as possible to map things
> that they care about. Therefore a sidewalk=yes tag would be the
> fastest way to get the maximum data into the map.

That's not the "maximum data", you know?

Ok, since you say for bling people it's the same. Suppose you're blind, and
walking on a sidewalk. How would your GPS unit understand on which side of the
street you are? How would directions about crossings be given?

You know, when I wanted to map sidewalks, I came with a proposal similar to


The "blind-argument" was the one that made me re-think the whole scheme.

> This is especially important when talking about rendering and routing,
> which I think are the main use cases of this tag.

Routing, not rendering. We don't care about rendering, do you?

> Your proposal only casually mentions relations, but they're extremely
> important without the main road data (see later in this mail where I go into
> detail about this).

..and I will reply later.

> But even so, I don't really care what method is used, but I think the
> proposal should be more factual and less ideological, even (and
> including) removing emphasized words such as "However" and removing
> emoticons.

Come on. We're a community, we should try to gain consensus, rather than
imposing law. Some emphasis and some emoticon makes the text more "human". But,
it's a wiki, feel free to edit where you believe it's inappropriate.

> > I tried to summarize what my ideas are, and why I don't believe that tagging
> > the main road is any good.
> >
> > To summarize here: to tag a sidewalk:
> >
> >  * highway=footway
> >  * footway=sidewalk
> Later in this thread, David, you asked for a clarification of the term
> "real world" by another mapper.

Erm, not. I asked for a real-world definition of "sidewalk".

> Humor of that question not withstanding, I believe the other mapper was
> reacting to the fact that we already have a great deal of difficulty getting
> casual mappers to work with our system. We've mitigated some of these issues
> with helpers like preset menus.

And there are plugins drawing parallel ways, you know?

> With sidewalks as a separate way, you are now stuck with two unoptimal
> situations:
> a) The sidewalks have no road-associated data
> The sidewalks not having street data is, IMHO, a significant problem.
> It means that while it might be possible to get highly accurate
> routing directions in the sense of "turn right in 30 meters", you will
> lack information such as "Walk up Main Street".
> This is bad for everyone.

This is solvable with:

1) add name=... to the sidewalk, but it's redundant, even if simpler;
2) use a relation.

It's your choice, really. Even streets split in different pieces are not
always grouped together, depending on the ability/will of the mapper.

> b) There is a relation
> Relations are a powerful tool, but they're hard to work with.

This is really a myth IMHO.
They're hard to work with in Potlatch, maybe, but I see it as a bug of the
editor. In JOSM, for example, they're correctly handled, and are rather easy to
work with IMVHO.

> They're hard for renderers to work with (say those who render), they're hard
> to make work correctly in the editors (say the editor authors) and
> they're hard to work with, and even harder to teach others how to use.
> I know, I've done it.

I've also taught others to work with relations, and I don't see all this
Do you have links pointing to the difficulty claimed by developers of renderers
and editors?

> In this specific instance, your proposal lacks a relation example, or
> even the recommended relation type that should be used. Looking at the
> relation page: http://wiki.openstreetmap.org/wiki/Relation
> I don't see a relation that fits. Can you provide an example which
> answers these basic questions?

You didn't read it all, did you? :)


The proposed relation is associatedStreet -- or, my favourite, the proposed
"street" (which should IMHO replace associatedStreet, but that's another story)

If you want some examples:


Do you want me to link these from the proposal page?

> Generally, I think this proposal seems to be more of a reaction.

Come on, please don't take that route.
My first original sidewalk-thing dates back at Aug 28, 2010; my "new proposal"
at mid-October. Long before you started the sidewalk-mapping thread.

> Personally, if people want to map sidewalks, I don't care about the
> method. This way may be more technically correct, but after having run
> mapping parties and taught mappers, I think we need to encourage
> simplicity.

I agree, but "sidewalk={yes|left|both|right|none}" is just not enough. It
could be used as a first-pass mapping, yes. But, as written in the proposal
page, I'd regard it as "highway=road" for streets. Yes, there's a sidewalk
somewhere, but that's it.


 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20110325/533c0f2e/attachment-0001.pgp>

More information about the Tagging mailing list