Mapping the position of the cycleway and footway relative to each other

[pavvv]

Hello,

recently there have been lots of discussions (especially in the polish community) regarding mapping segregated cycle- and footpaths as 1 vs 2 ways.

I, of course, stand by the rule of not dividing ways when there’s no physical separation and ‘less means more’.

I believe that no data is lost when mapping with one line instead of two as long as the respective tags are filled in. I even belive that there’s a lot of data lost when mapping with two lines but that’s not what this thread is about. There have already been threads dedicated to this topic.

In many countries, such as Poland, there are two ways of mapping such roads, as described in Ref S5.

The biggest issue with tagging one line, however, is that there’s no consensus on mapping on which side the cycleway and on which the footway are located when using the segregated=yes tagging scheme. This is quite a problem as this is one of the main arguments of the two-line scheme defenders.

There do exist alternate methods of tagging that don’t cause such issues. One of them, which is widely used in the Netherlands, is highway=cycleway + sidewalk=right.

I, however, don’t necessarily like it though as it sort of implies that the footway part is less important than the cycleway which isn’t true especially on paths with wide footway parts.
It’s also not really what the polish sign for these paths suggests.

So, I’d like to propose that segregated=yes will mean by default that the cycleway is to the left and the footway is to the right relative to the way’s direction
(see forward & backward, left & right)

My reasoning is that there already exist physical tags whose direction drastically impacts the data they convey e.g. barrier=kerb, barrier=retaining_wall.
There’s also defaults on important tags such as junction=roundabout.

Now, you may ask, why should the cycleway be on the left and not on the right? Well, in most countries traffic takes place on the right side of the road which will then make it more logical to have the sidewalk keep the same direction as the nearby road while having the cycleway be closer to the carriageway in case of cycle lanes switching from running along the carriageway to along the footway like in the example below.

Also I believe that generally cyclepaths are placed closer to the main way more often than footpaths though I have no data to back up that claim.

That’s also how CyclOSM currently renders it. Cycleway on the left.

Paths with more than two lanes already have their own creative ways of being tagged as discussed in the other thread. They’re also an edge case so I won’t write about them here.

Now for the consequences of such a change.

First of all there already exist hundreds of thousands of path segments tagged in such a way without any care for the way’s direction. We could just live with that, slowly adjusting existing objects to the new consistent scheme. Another solution is to use a different tag than segregated=yes like segregated=forward/backward, to distinguish carefully signified placements of the cycleway and footway from generic segregated paths. This also opens up the possibility of mapping segregated paths when unsure of cycle- and footpath’s positions along the path.

Secondly, oneway:bicycle=-1 will have a reason to be used. Hurray!
Going a bit offtopic, I think it’s really silly for such a value to exist. Numeric values should only be used when the tag is related to numbers like maxspeed or step_count but for oneway it doesn’t make any sense. It would if we used oneway=1 and oneway=0 but if we use alphabetical values then we should just use oneway=reverse or oneway=opposite instead. It might be even better to use oneway=forward/backward/no instead of yes/-1/no.

Anyways, what are your opinions on the matter? Would using such a default be acceptable? Should we use a new tag instead?

[DwarfNebula]

@pavvv

There do exist alternate methods of tagging that don’t cause such issues. One of them, which is widely used in the Netherlands, is highway=cycleway + sidewalk=right.
I, however, don’t necessarily like it though as it sort of implies that the footway part is less important than the cycleway which isn’t true especially on paths with wide footway parts. It’s also not really what the sign for these paths suggests.

In The Netherlands this sign doesn’t exist. So in the cases of highway=cycleway + sidewalk=right it literally is a cycleway with a sidewalk next to it.

Looking at the sign and from my experience from Germany it should be tagged as one road/way. Your proposed tags make any sense looking at this sign. However, I think this way should be mapped in the direction (cycle) traffic is flowing.

[pavvv]

@DwarfNebula

In The Netherlands this sign doesn’t exist. So in the cases of highway=cycleway + sidewalk=right it literally is a cycleway with a sidewalk next to it.

Yes, I may not have phrased it as well as I should have. This is a sign used in Poland and I used it as a partial reason as to why this tagging scheme doesn’t really fit in Poland.

[Jofban]

I think the biggest issue I have with making a default here is that it leaves no room for “I don’t know”. Sometimes, geometry is complicated and I just want to say that there is dedicated space for cyclists.

@pavvv

there’s no consensus on mapping on which side the cycleway and on which the footway are located when using the segregated=yes tagging scheme.

It might help if you summarised the different approaches (or linked to a relevant thread). In the absence of that, I’m going to give you my opinion of what I would do.

I’m speaking from the german perspective, but segregated=yes practically only means that the paths are divided, without regards to geometry.
To tag the geometry, other tags could be used like

lanes=2
bicycle:lanes=designated|no
foot:lanes=no|designated

In a sense that would even render segregated meaningless, as it’s implied by the different lanes.

segregated=yes is a simplification that is usually precise enough. If we want to add extra detail, we should probably use the tags that were designed for that.

[Minh_Nguyen (Minh Nguyễn)]

This is reminiscent of the rule of the road, but for an individual path and dependent on the mode of transportation. driving_side=left/right is well-established for indicating the rule of the road that applies to a given road or all the roads in a region. This key affects some aspects of routing in OSRM and rendering in OSM2World. Despite the key’s name, it applies to any traffic that uses the main carriageway in the normal fashion – not necessarily traffic that has to hug the shoulder, as pedestrians do. The sides are relative to the centerline and have nothing to do with the position of the steering wheel.

Given that the segregated=yes line is essentially a centerline, what if we extend this tagging scheme with walking_side=left/right and cycling_side=left/right? This would make it possible to assign each mode of transportation to one side or the other without getting into lane-level detail, which is complementary. I realize the analogy has its limits: if you’re allowed to bike on the left, then you can bike in either direction. But I’d appreciate the simplicity of saying just a side and not having to fuss over any notion of priority or hierarchy among the modes of transportation.

[Mateusz_Konieczny]

@DwarfNebula

However, I think this way should be mapped in the direction (cycle) traffic is flowing.

note that in Poland basically all of them are two-way (unlike in for example Germany where nearly all are oneway)

[Kovoschiz]

The meaning of driving_side= is wrong here. Driving on the right doesn’t mean vehicles only use the right half of roads. They still use both sides, for different directions.
You need to consider potential use of walking_side= for side of walking by different directions in high pedestrian flow eg stations. This would apply on =steps as well.

[Mateusz_Konieczny]

@pavvv

So, I’d like to propose that segregated=yes will mean by default that the cycleway is to the left and the footway is to the right relative to the way’s direction

that is not really viable, as massive amount of already mapped ways does not follow this

having an extra tag would be more viable

see also: idea that direction of way for highway=steps implies which side is higher vs explicit incline tag

[Kovoschiz]

The walking or cycling side can be suggested for segregated=no where there are not really *:lanes=
Also it means there needs to be eg *:advisory= (TBD) / *:left*=discouraged + *:right*=designated (foot:*= / footway:*= / footway:*:foot= )

[Tolstoi21]

This is an interesting question, and there are lots of interesting points already!

@pavvv

I, of course, stand by the rule of not dividing ways when there’s no physical separation and ‘less means more’.

I believe that no data is lost when mapping with one line instead of two as long as the respective tags are filled in. I even belive that there’s a lot of data lost when mapping with two lines but that’s not what this thread is about.

Regarding this distinction, I’ve always mapped the cycleway and the footway as separate lines whenever there is a physical barrier (in Finland, usually a slightly raised kerb) between the cycleway and the footway, and a single cycleway-line (with segregated=yes) if the cycleway and footway are segregated only with a centerline marking.

This decision has ramifications for routing. Consider a pathway that connects to the footway side of the cycleway. If the cycleway and footway are separated with a raised kerb, a bicycle cannot easily cross over to the pathway (assuming that it is legal to drive on the pathway). A bicycle would have to come to a full stop, the cyclist would have to carry the bicycle over the kerb, walk the bicycle on the footway and only then continue on the pathway. So separate ways in OSM is a perfect way to denote this (i.e., the lack of a reasonably routable way for a bicycle).

However, if the cycleway and footway are separated with only a centerline, it it very easy (and at least in Finalnd, also legal) for a bicycle to cross the footway and continue straight to the pathway (again, assuming that it is legal for bicycles). So tagging those with a single line shows this for the routers too.

For this very reason, I’ve never seen any particular reason to tag which side the cycleway is on. But perhaps there are countries in which it is not legal to cross the footway even in these cases?

Incidentally, in Finland there are two traffic signs denoting a segregated cycleway: D7.1 and D7.2. One has the cycleway on the left side and the other has it on the right side. Also, in Finland it is the traffic sign that legally determines which side the bicyclist has to stay on (e.g. in case the markings on the ground are contradictory to the traffic sign, the markings have faded or are covered by ice and snow as they are in Finland for about three to four monts of the year).

[Yunkers]

@Tolstoi21

For this very reason, I’ve never seen any particular reason to tag which side the cycleway is on. But perhaps there are countries in which it is not legal to cross the footway even in these cases?

In Poland there is a huge issue with people drawing such cases with two lines, as apparently some navigation for blind people is being build and that information is needed. I don’t have aby more information about that but @Asteliks may provide some more info.

[pavvv]

@Jofban

think the biggest issue I have with making a default here is that it leaves no room for “I don’t know”. Sometimes, geometry is complicated and I just want to say that there is dedicated space for cyclists.

I don’t think it’s such a problem. It’s not to any use really to have a designated cycle- and footpath without knowing where the cycleway is located. In my opinion it’s no different from a non-segregated path. I’d just set the way’s direction so that it’s on the right of the main way.
CyclOSM already sets a default for those paths.
Alternatively you could not add the segregated tag at all. It’s also a solution that in my opinion doesn’t take away too much data. Someone that might later search for foot and bicycle designated paths without this tag would then set the segregated tag and direction.

But that might not be the best idea. What about segregated=default? We would have like a sort of ‘preset’ where default would be cycleway|footway and reverse would be footway|cycleway.

@Jofban

It might help if you summarised the different approaches (or linked to a relevant thread).

You’re right. The main thread I’m referring to is Mapping separated footways or cycleways along central street as one tagged line versus mutiple lines and I guess there’s also Sidewalk tagging on cycleways among others also linked in the first thread.

@Jofban

To tag the geometry, other tags could be used like

lanes=2
bicycle:lanes=designated|no
foot:lanes=no|designated

I always disliked this approach because it required such complex tagging for the simplest objects. However now that I think of it, it might not be so bad since we already add bicycle=designated + foot=designated tags.
I’d just remove lanes=* since they’re already implied by the *:lanes=* tags and on typical roads, cycleways are included in *:lanes=* tags but don’t count towards the lanes=* tag. That’s up for debate though.

@Tolstoi21

Regarding this distinction, I’ve always mapped the cycleway and the footway as separate lines whenever there is a physical barrier (in Finland, usually a slightly raised kerb)

That’s not the best approach. A slight kerb isn’t physical separation IMO. It should be something like a field of grass, a hedge or a kerb of the same height as the one separating the carriageway from the sidewalk but I’ve never seen an example of the last one. A 2-centimeter kerb is definitely not physical separation as it’s very easy to cross on a bicycle.

[Tolstoi21]

@pavvv

@Tolstoi21

Regarding this distinction, I’ve always mapped the cycleway and the footway as separate lines whenever there is a physical barrier (in Finland, usually a slightly raised kerb)

That’s not the best approach. A slight kerb isn’t physical separation IMO. It should be something like a field of grass, a hedge or a kerb of the same height as the one separating the carriageway from the sidewalk but I’ve never seen an example of the last one. A 2-centimeter kerb is definitely not physical separation as it’s very easy to cross on a bicycle.

I dunno. Like everything, this very much depends on circumstances & one’s mileage varies. The Finnish Transport Infrastructure Agency has published a Design Guide (PDF, in Finnish) for cycleways, where the recommended physical separation of a cycleway and a footway is a 5 centimeter high kerb. IMHO, that’s not something that a normal commuter bicycle would be able to just cross without carrying the bike over it.

Perhaps more importantly, the kerb is there to specifically separate foot traffic from cycle traffic, and (at least in the Finnish case) to denote that a pathway beyond such a kerb is not meant for bicycles (as there’s a slight ambiguity about the precise legal definition of a cycle/footway in certain cases, which I won’t go into here.) Here, the kerb really makes all the (legal) difference.

[Jofban]

@pavvv

I’d just remove lanes=* since they’re already implied by the *:lanes=* tags and on typical roads, cycleways are included in *:lanes=* tags but don’t count towards the lanes=* tag.

That’s right, I agree.

@pavvv

It’s not to any use really to have a designated cycle- and footpath without knowing where the cycleway is located.

I’d question this statement, since I assume most people are able to navigate their environment without OSM. So if you are physically there, you are probably able to tell which side the cycleway and the footway are.
In addition, for usecases like routing for example, it can affect the speed calculation. You don’t need to know the location of the cycleway for that.
Someone already mentioned accessibility, and sometimes the situation is not so straightforward, then we can add that detail.

@pavvv

CyclOSM already sets a default for those paths.

Yes, it’s an educated guess. They can’t know what is OTG, but they can choose a sensible default. Yet having a renderer do whatever is different from the underlying OSM data.

@pavvv

@Jofban

To tag the geometry, other tags could be used like

bicycle:lanes=designated|no
foot:lanes=no|designated

I always disliked this approach because it required such complex tagging for the simplest objects. However now that I think of it, it might not be so bad since we already add bicycle=designated + foot=designated tags.

Yes, I think it could replace them even, so there would be no additional tags. I believe that’s the simplest and easiest solution for this issue.

[pavvv]

@Tolstoi21

The Finnish Transport Infrastructure Agency has published a Design Guide (PDF, in Finnish) for cycleways, where the recommended physical separation of a cycleway and a footway is a 5 centimeter high kerb.

Yeah, I suppose that’s a high enough. Though in some rare cases it might be better to use something like separation=kerb for the sake of not ruining geometry.

[SekeRob]

Where’s that cycleway …
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Down the middle

(Actually this bridge (re) named the Bridge of Liberty, was originally constructed as simple 2 lanes. Then they added 2 lanes bridge next to it southbound., why the high double kerb is. Then when they took 1 lane southbound and converted it into a bi-directional cycleway and added doublesided high kerbs at left. The result, quite safe to ride, but to get onto it is takes several Hail Mary’s… painted cycleways on both bridge end’s roundabouts that cross the motorcar traffic blowing down the bridge, motorcar drivers just forgetting the cyclist are coming from the left instead of passing on the right.

Yes, oogle has not managed to get the new name since circa 2012 when the doubled bridge reopened, still says Ponte Villa Fabio… can’t trust that source ;p)

[Minh_Nguyen (Minh Nguyễn)]

@Jofban

To tag the geometry, other tags could be used like

lanes=2
bicycle:lanes=designated|no
foot:lanes=no|designated

On a two-way street or path, does something like bicycle:lanes=* without :forward or :backward apply to the whole street or path, or does it apply to both sides individually? In other words, in this example, does bicycle:lanes=designated|no imply that there are two or four lanes total? Some routers such as OSRM discard any lane-suffixed tag that disagrees with the implicit or explicit lane count. If I’m reading this unit test correctly, OSRM considers the directionless tag to apply to both sides individually.

[pavvv]

As much as I like this idea and how well it fits in terms of replacing current tagging, I don’t think it can work. Tagging lanes usually implies that they’re one-directional.
In Poland there are also many cycleways which also have lane-dividing markings that I wouldn’t like to tag as seperate lanes, at least not in the same sense as dividing the cycleway from the footway.

[Jofban]

@Minh_Nguyen

On a two-way street or path, does something like bicycle:lanes=* without :forward or :backward apply to the whole street or path, or does it apply to both sides individually?

I mean it to apply to the whole street or path, i.e. it covers both directions; the lanes are considered bidirectional* unless oneway:<mode> is specified.

*in the case of a single lane for the mode; if multiple lanes are available, they are symmetrically split in both directions. It’s usually still legal to use them for overtaking.

@Minh_Nguyen

In other words, in this example, does bicycle:lanes=designated|no imply that there are two or four lanes total?

It should be considered as two lanes. As to your examples:

@Minh_Nguyen

Some routers such as OSRM discard any lane-suffixed tag that disagrees with the implicit or explicit lane count. If I’m reading this unit test correctly, OSRM considers the directionless tag to apply to both sides individually.

I only read that this concerns turn:lanes without suffix, which certainly needs special handling as it is most likely a mapping mistake on two-way streets and very much ambiguous.

@pavvv

Tagging lanes usually implies that they’re one-directional.

The closest I would get to that is if they were tagged with :forward or :backward. But even then, usually it’s allowed to use them for overtaking. If you want to make that explicit, you may want to use the change:lanes tagging.

@pavvv

In Poland there are also many cycleways which also have lane-dividing markings that I wouldn’t like to tag as seperate lanes, at least not in the same sense as dividing the cycleway from the footway.

Strictly speaking, I see 3 lanes in your example:

bicycle:lanes=designated|designated|no
foot:lanes=no|no|designated

As usual, the two bicycle lanes are symmetrically divided into one primarily forward lane and one primarily backward lane.

[Minh_Nguyen (Minh Nguyễn)]

@Jofban

@Minh_Nguyen

Some routers such as OSRM discard any lane-suffixed tag that disagrees with the implicit or explicit lane count. If I’m reading this unit test correctly, OSRM considers the directionless tag to apply to both sides individually.

I only read that this concerns turn:lanes without suffix, which certainly needs special handling as it is most likely a mapping mistake on two-way streets and very much ambiguous.

The particular test I linked to concerns turn:lanes=*, but I don’t see any evidence that OSRM has made an exception for that key. The lanes documentation all but states that you must add directional suffixes if the way is two-way, leaving the meaning of an unsuffixed key undefined. (This contrasts with the non-lane-related keys that take :left and :right suffixes, such as sidewalk=* and parking=*.)

I think it would be problematic for :lanes to mean something different on access keys than it means on other lane-level keys like turn=*, change=*, and destination=*, especially since we usually use them together on the same ways and generally expect them to have parallel lists of values. It would also be highly problematic if access keys behave differently on segregated paths than on unsegregated paths or two-way streets, because routers would have to special-case so much behavior.

As keys that pertain to the centerline, placement=* and overtaking=* do apply to the whole way as viewed in the forward direction. If we coin brand-new keys for the travel-side restrictions, then these new keys can naturally have similar semantics.