First of all, there is the question, what qualifies as a crossing. It’s easy whenever there are markings or traffic lights. But all the crossings without markings are often difficult to spot: Lowered kerbs? Tactil paving? Island? Is one of that enough to qualify a place for a crossing. And what, if a lot of people cross at that place, but there is nothing visible on the ground? Does this still qualify as a crossing?

What’s next, is the problem with separately mapped sidewalks: In this case, for working pedestrian routing you need crossings at every place, where the street forks or cross. (And the other way round: In the case of attached sidewalks, people assume, that crossing is possible at every place, and there is no way to map if it is actually not possible.)

And: In my oppinion: If one maps a crossing, the main tag ‘highway=crossing’ should always be added. (Some people omit this, when they think, the crossing does not qualify enough for a full crossing, but do not want to map nothing there.)

@sosquqer: It’s a rather complex theme and I do not understand every aspect, too; probably no one does. That said, I’ll try to explain, what I do understand:

• Essentially, there are two ways of mapping sidewalks: as tags on the roads or as separate ways. Currently, there is no agreement on which is better. From my perception currently most mappers prefer separately mapped ways on larger streets and tagged sidewalks on smaller roads. (This is not my opinion, I prefer separate tagged sidewalks on all roads.)
• If you map a sidewalk separately and do not add a tag on the main road, users of StreetComplete will be asked, if the street has got sidewalks. They will answer yes and then you’ve got both: Tagged and separate sidewalks. Hence the value separate. StreetComplete now knows, there is a sidewalk, and will not ask. (Same is true for other applications.)
• Pedestrian routers need to use routing in the middle of the street, whenever separately mapped sidewalks are missing. They even have to do this, when there is no information at all, assuming, that it is just not mapped yet. Without such assumptions pedestrian routing is not possible. (It would be possible if most sidewalks had been mapped.) If the streets contain no information whether there is a sidewalk separately mapped, such routers might use the middle of the street routing on such streets despite a separately mapped sidewalk being there (for example, because it’s shorter).

@sosquqer: I actually prefer https://wiki.openstreetmap.org/wiki/Tag:highway=footway + https://wiki.openstreetmap.org/wiki/Tag:footway=sidewalk over any attached solution.

Why didn’t I count them then? Well, while it is possible to count the mapped sidewalks it is not possible to count the ones, which have not been mapped. But for knowing a percentage, I need this second value too. That’s all.

Additionally: The highway they belong to, should have one of the sidewalk-tags with value separate. So in a way, they are still counted.

@Niquarl: Thanks for pointing me to Sidewalker. I didn’t know about it. Good tool!

Thanks for pointing me to OpenStreetBrowser.org. I didn’t know about this tool.

Concerning “obvious” defaults: I think, in rural areas I would fall in this trap too. Roland goes even further in his speach: He ignores residential roads on purpose, because the sidewalks there are “unimportant”, which leaves more time to do the main roads. For me, this doesn’t feel right. I’d prefer to complete an area at once.

@InfosReseaux: Thanks for pointing me to your blog post and indirectly to data items. I didn’t know about them. On first sight, this sounds like a very good idea. :-)

In general, uncertainty is often a problem, which prevents changes. Fears are very strong. And too much disruption isn’t healthy anyway. But no change at all is probably even worse. That’s what I tried to express in my post: Always do some steps, probably small steps, but don’t stop.

@CRCulver: Apart from such bicycle routers being questionable, a good application should already consider the construction:highway tag. And: Software is never static - it always needs to adapt to its surroundings. For me, getting the tagging scheme right is more important than avoiding potential disruption to applications. (Of course, depending on the change, applications should be given time ahead to adapt.)

@SomeoneElse: Unfortunately I do not remember where I read this. I just picked such comments up from time to time. Probably it was on a user page or a wiki user page. I already tried to search it, but was not successful. In case I ran into one of these comments once again, I’ll tell you. :-)

Ich möchte mich nochmal für deinen Beitrag bedanken. Inzwischen habe ich das alles erfolgreich nachgemacht. :-) Besonders hilfreich war der Hinweis auf “Layer reprojizieren”. Das hätte ich gerne vor anderthalb Jahren schon gewusst. Mir war klar, dass irgendwas mit dem KBS nicht stimmt, aber alles, was ich versucht hatte, um das zu ändern funktionierte nicht. Ich bin dann dazu übergegangen, die Daten als geojson zu speichern, mit einem selbstgeschrieben (PHP-)Programm zu reprojizieren und die neuen Daten wieder einzulesen. Das kann ich mir in Zukunft sparen. :-)

@Crotaro: You do not need to know all these tags. I do not do too. Typically, one specializes in a certain area, for example crossings. Then you learn the basic tags which you need to map crossings (highway=crossing, crossing=…). Sooner or later you’ll run into some crossing, where you find something which you thing, should be mapped (traffic light buttons for example). And thus you look it up in the wiki and so your knowledge grows. After a while you are customed to these tags and you can add a new subject, like traffic signs or what ever.

StreetComplete is somewhat norming. If SC uses a certain tagging scheme, it’s high likely that you cannot deviate much from it, because sooner or later some SC user will come by and add the SC tags. That’s OK in most cases though. What you do not learn, when you use SC, is the tagging scheme, because you do not use it.

@sef43: Your idea is probably better than having no geometry for crossings at all. Anyway, I think that the geometry of sidewalks matters too, although I did not give an example in this post. Maybe I’ll do so in an upcomming post.

Hey klasse! Ich arbeite ja immer mal wieder mit QGIS und vieles scheitert daran, dass ich die vielen Tools nicht verstehe oder nicht richtig anwenden kann. Ich werde streng nach deiner Vorgabe hier mal eine Hydranten-Erreichbarkeits-Analyse durchführen. Ich glaube, danach kann ich mal wieder ein paar Tools zu meinem Arsenal hinzufügen. :-) (Wo hier die Hydranten noch nicht gemappt wurden, weiß ich allerdings auch so…)

Just want to tell you that I liked reading this article. :-)

E.g. everytime when you start at one point of the street at a certain address (like a house or a shop) and need to cross the street before the next crossing, because you have to turn into another street (e.g. on T-formed junctions whithout marked crossings).

Yes, for the separate sidewalks to work, there need to be crossings at junctions, if it is possible to cross there. Even if the crossings are not visible. It’s like bus lines. They are not visible on the ground either, but they are still mapped. I always add https://wiki.openstreetmap.org/wiki/Tag:informal=yes to such crossings.

I map for visually impaired persons

Just out of curiosity, what sort of application are you targeting? Visually impaired persons usually can’t use an ordinary map. So I guess it’s about a router giving spoken directions? Or are there means to create a Braille-like map, which can be read with fingers? Or something completely different?

One unsolved problem with separate sidewalk mappings: In countries where it’s legal to cross a street anywhere, separate sidewalks create the impression that crossing the street is not allowed between crossings.

I’m familiar with this argument (Germany is one of these countries…) In practice, however, I don’t think it makes much difference:

Routers then create detours which are not necessary […]

Up until now, I have never seen a real life example of this. The only examples I have seen are artificial ones where the starting point is on one side of the street and the goal is directly opposite on the other side. In such a situation, you hardly need a router to cross the street, do you?

Moreover: The tagged version still doesn’t indicate whether you can cross the street at a certain point. There are lots of places where crossing is almost impossible, for example because there is too much car traffic or the sight is blocked. (In Germany, it’s even forbidden to cross at such places.)

All in all, I think this problem is just a theoretical problem. But I might be wrong.

I think, there is a third category: Issues where our mapping scheme does not work well. The mapping scheme with all it’s tags has evolved over time, but it is far from perfect. For example the question of what a https://wiki.openstreetmap.org/wiki/Tag:highway=path should be pops up over and over again and the answers aren’t satisfying. This should be changed, but of course it’s a lot of work to do so, especially, because every “solution” will have a lot of opposition from other mappers.

Thanks for pointing out those two things. I wasn’t aware of the concept of Caesium, so I didn’t consider it. As far as I understand it, it’s something like a k-d-tree approach.

Regarding the Z-curve: If anything, this could be used within slices to sort the data once more. It would be nice, but you need to have indexed access to the elements, which is not the case: The data is compressed and must be retrieved linearly. And even, if it were not compressed, the size of the elements is not fixed, so indexing still does not work. So I’m not sure if such a technique could be used. Anyway, it would be nice, to be able to read only part of the slices if only part is needed.

@SomeoneElse Yes, there is certainly room for improvement in the type file. In your case, you can add pedestrian after highway - EXCEPTION. In this case, closed paths with https://wiki.openstreetmap.org/wiki/Tag:highway=pedestrian will be treated as areas.

@SomeoneElse: Here’s what the algorithm does:

1. Multipolygons are always areas.
2. If the sequence of nodes is not closed, it’s a way.
3. If the area tag exists and it’s value is yes or no, this value is used.
4. The information from the type file is used (if a key could be determined).

So a https://wiki.openstreetmap.org/wiki/Tag:man_made=pier will always be treated as a linear feature, except if it has https://wiki.openstreetmap.org/wiki/Tag:area=yes (or it’s a multipolygon).

Neither https://wiki.openstreetmap.org/wiki/Tag:leisure=track nor https://wiki.openstreetmap.org/wiki/Tag:highway=raceway are listed in the type file. leisures are always areas, highways are always linear features. Again, this can be overridden by the area tag.

Unfortunately, OSM does not provide a clear way to distinguish between ways and areas. It’s always some guesswork - that cannot be helped.