Mapping separated footways or cycleways along central street as one tagged line versus mutiple lines

I’d like to first give an example of a living_street
There pedestrians can walk wherever they want, on its main section central is a tram line, two car lines, that are disallowed to cross the tram line and on sides there is 1 footway south and 2 lines of footways north. Additionally the fotways are connected in some arbitrary places through the street,
because routers would fail to route somewhat direct route to destination
There area=yes highway=pedestrian is quite nice to use, because it connects all shops/cafe/etc entrances so it’s possible to navigate to em, but still, not directly, because even though it’s a line, we never found out how to make advantage of it with technical limitations that we have got (I’d like to try elaborate on proposal on that later, but something else might take priority… )

Also, because it’s a living_street it was designed flat as a table and there are no kerbs sticking out anywhere more than ~5milimeters :wink:
So, why do we map 6 separate lines and connect its sidewalks arbitrary in a few perpendicular spots, while we can map just one line for the street and tag it.
So it looks that even though we have got tags for those sidewalks we rarely use em and map separate sidewalks instead and we add those perpendicular ones as well to solve our routing problem the best we can atm.

Ask yourself a question why do we map em separate even tho the kerb is levelled and you can ride with roller skates anywhere you want across the street and all vehicles has to yeld to you, so there is really no restriction.

I put that question, coz now I’d like to talk about modern cycleways,

that look virtually exactly like a street for cars, only it’s not that wide, but of course it has sidewalks for pedestrians and tagging them can be found in this post. But those sidewalks are not separated from cycleway by a big kerb, but it’s levelled instead to avoid crashing on the kerb or to allow smoothy roll over to grass in an emergency. Those cycleways as described in the S5 section od Bicycle wiki

If a road like this is straight, starts from nowhere and ends nowhere special as well, there really is no reason to use the controversial variant of two lines because the only information we are loosing is not being able to tell which side is the cycleway in relation to line direction (but that could be fixed with proposal of tags described roughly in forum post i linked earlier )

But in the cities, where we have got lots of intersections and footways intersecting cycleways in suggested spaces as well, the two line controversial variant is currently the only solution to map this complex system.

This is especially important for routers and two line mapping is perfectly understandable to any router without any additional specifications we have to develop.
I’d like to give examples from google street view, but don’t know if i’m allowed, so i will describe a few of em, though I’d love to attach screenshots or link (whichever is allowed)

  • Routers can calculate where there are collisions and how many of em.
    if a footway intersects with another footway, but without phisical connection to the cycleway, this is important information impossible to map by single line

  • Because we don’t know how to take advantage of area highways for routers, the best we can do is intersect footway with a cycleway in the actual suggested nodes and not anywhere on the single mapped line

  • When cycleway and footway crosses themselves, for pedestrians to walk to a bus platform next to a street, then it can do so in two ways

    • pedestrians have to yeld to cyclicts
    • cyclists have to yeld to pedestrians
      • While right now it might be a little unclear as to which tags to use there, basucally here in Poland, cycleway is apshalt and footway is paving_stones, so if footway takes the lead, it’s surface is uninterrupted and crossing kerbs is mapped for cycleway, but if it’s the cycleway, then asphalt maintain continuity and so kerbs are mapped for the footway
  • Kerbs. Those, can be flush with marked tactile_paving for footways and flush or none at all for cycleways when entering a crossing over a car street. Kerbs can be drawn as a line, but for routings those has to be tagged on node of a highway and i focus on those.

  • tactile_paving are rarely marked here over a crossing through a car street, but those can be added across a cycleway and it’s clear information for cyclist that in this spot they gotta yeld

  • tactile_paving are tagged for a footway, not just its nodes, so that’s also a reason why it need to a be a separate line from a cycleway

  • pedestrian and cycling crossings have different marking here in Poland and it’s disallowed by law to place em on the same space and they always have to be separate. While there are tags for that, that’s not the case with information about tactile_paving that it’s only for zebra location

  • Also, in favor of two line mapping, i have asked on a small cycling group where the’re very familiar with planning a route and navigating on the fly from a map. I have given 2 screnshots and without describing i asked to pick only one.
    9/10 people picked a rendering with two separate lines. and 1/10 picked one where it’s just one line, even tho it looked like a cycleway.
    I tell this, because:

    • maybe we want easy mapping and mapping 2 separate lines is harder - that’s just wrong to me
    • maybe we think that mapping one merged line is better for people, coz they know that its kerbs are lowered and it’s easy to switch sides anywhere over it easly, but we just assume this, even tho consumers of our mapping don’t even mention it as relevant, coz likely that’s not an information they see anywhere.
    • maybe end point users seeing one line simply assumes it’s always a mixed traffic, while two lines is segregated and that’s the trully valuable information.

Please give your feedback on this kind of micromapping and feel free to describe how much different it is in your country and give examples!
One of mine example is around this area, whiere in this certain spot cyclists have to yeld to pedestrians

Also i’m not implying that cycleways/footways should be now mapped always as twoliners. Mapping two lines is micromapping. We don’t always have time or sources for that, so any mapping is always better than no mapping at all.
But removing micromapped details and making it ambiguous for routers just for the rules sake is not useful.

1 Like

I agree that two lines is a perfectly valid and sometimes necessary way to map it.

I know there are people in Norway who feel strongly about using only one line, but I haven’t seen them removing two lines and replacing them with one.

Here’s an example that I’ve mapped where I’ve used two lines for the intersection because the crossings are different and one line for the rest: Way: 1081221932 | OpenStreetMap

For this nearby cycleway, the crossings are the same, so I used one line: Way: 1081221934 | OpenStreetMap

This is not necessary. *way:crossing:markings= are already ~5k, similar to *way:surface= by standard.

Kerbing is not the only criteria. The example for your comparison has many =tree , and what should be man_made=planter (instead of leisure=garden + barrier=retaining_wall ). They are physical separations. When there are many street furniture in between, certainly =footway and =cycleway can be separated out.
Functionally, sidewalks for roadways are still not the same. Vehicles aren’t supposed to drive onto them. But pedestrians or bikes can cross each other.
Let me try to organize them into different issues:

  1. Routers: Can you explain what’s “physical connection to the cycleway”?
  2. Intersecting points: I don’t understand the layout you are referring to.
  3. Bus stops: We can think about how to solve locations where they change sides. The need to draw them separately isn’t immediately justified.
  4. Crossings: As I replied to others above, there’s footway:*= and cycleway:*= that can be used

5,6,7. Tactiles: tactile_paving= could be assumed as for pedestrians. If still needed, I don’t see why footway:*= can’t be used for it.
8. Navigation: This is a rendering issue. Basically all renderers aren’t rendering in detail yet. Your poll doesn’t show the possibilities from rendering a single line.

The most sophisticated renderer supports at least footway:width= besides cycleway:*= , as demonstrated for Berlin Straßenraumkarte Neukölln | Projects | OpenStreetMap Taginfo

Good point. I didn’t know they are standardised.

As for mapping by one line, this intersection has no precise geometry as to how cyclists or pedestrians should cross it, so there is completly no reason to map it by two lines. There are also no kerbs at all, yet sidewalk=right is used, unlike to Poland where we don’t have those square street signs at all, but only those round ones from the S5 section of Bicycle wiki.
Your tagging allow for precise placement of the footway in relation to cycleway. The S5 section does not, @Kovoschiz which is a problem i pointed out and you did not adress.

As for your mapping of two lines on the linked intersection, right there i would map it one line like in this example but cycleway:crossing:markings=dots has to be different for your place, coz you have no markings for the cyclists there

@ Kovoschiz
As for your answer to my points.

  1. I have described collisions/collision-free of cycling with pedestrians traffic. By connecting a footway to a cycleway/footway you are impossible to tag it in a way that a router will know that in fact the segregated traffic is not mixing and collusion with a cyclist is not occuring.
  2. In Poland if you have segregated=yes cycleway clearly marked with a flush kerb boundary, you have to cross it perpendicularly, you are disallowed to do it differently. But if it’ designed like in this certain spot cyclists have to yeld to pedestrians, that i linked earlier, then on this area they can cross it any way they like and without yelding to cyclists. And this is another important information that you can’t map with a single line
  3. 4- Yes, but not for the precise spots when they do actually intersect and this is also not compatible with infomation about kerbs, which you do have to tag over a specific node, because otherwise the routing won’t be able to say where the kerb information should be given as a warning or different information

5,6,7 Yeah, could be assumed somewhat, but this is not specified at all, routing programmer has to gues how to programm it, while if we map separate lines, there is no guessing at all, hence it is a superior micromapping.

  1. In the pool, two screenshot of the same area from osm.org were given and people picked what they wanted without any influence.
    That is the mainstream map and it doesn’t show the “possibilities from rendering a single line” no mainstream map does show it. All they show is one colored line or dwo separate. This is what people recognize and not what you’re describing. But i understand your argument, though only 1/10 people think it might be relevant.

Finally, you’re giving an example where *:width and *:surface are specified and this is properly recognizable mapping, but one issue with it:
on this node you’re impossible to say if pedestrians can collide with a cycling traffic, because it is not clearly specified and routing has to gues, like for those people with impaired sight who take a real advantage of tactile_pavement if it is present and actually mapped properly

There are kerbs along the entire cycleway, except for that last meter into the intersection, which is painted. The kerbs are slanted, not straight, so they may appear to not be kerbs on the photos.

We don’t have the round horisontally oriented cycle|foot signs, but I understand they signify legally separated ways, as opposed to the vertically oriented cycle/foot signs, which mean one combined way. We do have some instances of the the footway sign being posted alongside cycleway sign, so that one refers to the pavement and the other to the cycleway. That is very similar to your situation.

I would tag such signed and legally separated ways using sidewalk=right|left, or use two lines. The tagging proposed for S5 makes less sense to me.

yeah boundary of every road is usually a kerb,
but in the example where cycleways with tagged sidewalk=right|left intersect each other, you have got no kerbs at all to cross there. sidewalk is separated by paint and on intersection the paint is gone,

There are kerbs to cross when a cycleway goes through a car street in the linked example
And it’s exactly the same kerb for cyclists and pedestrians who want to cross. Also no zebra markings there, so that is why I’m saying a one lined cycleway with a sidewalk tagging is completely sufficent there.
We have got something alike in Poland as well, only marked with round signs and tagged without sidewalk=right|left that you use and which is IMO a superior solution, coz it tells where the sidewalk is, so cycleway position is clear as well.

Take a look at different example from Poland:
Here cycleway is separated by kerb from a footway, but more importantly, when crossing a car street, there is no kerb at all, only painted square crossing markings, while sidewalk crossing has a lowered kerb along with tactile_paving information for those with impaired sight.
In this certain situation sidewalk=right|left tagging would not suffice and 2 separate ways are necessary, especially that within close distance sidewalk/cycleway crosses themselves and divide independently.

That’s basically the only modern bike infrastructure i need to two-line map
and i would like the wiki page to clearly mention this

Do see the discussion at:

in particular slides 7-15.

A separate cycleway alongside a road should be marked as a separate line, because it has distinct attributes like width, surface, oneway, etc., which a proper cycle routing engine needs in order to model quality of service accurately.

2 Likes

The topic here is about =footway next to =cycleway , not your presentation entirely. Ie east side of your HIlls Rd example, shown to be not split either. Or imagine if the west side doesn’t have a “contra-flow” shared part. So it’s closer to the Cuyperspassage illustration, which wasn’t discussed heavily.
There was another post before about sidewalk= but not =footway or footway=sidewalk , aside from the one linked at start Tagging of adjacent cycleway + footway (sidewalk)

1 Like

For ref S5, I’m always a fan of two line version (two separate ways). I dont undestand what is controversial in better or more exact mapping of cycleway. I thought that one line variant is a lazy one, where there is no changes in footway and cycleway geometry. As a trip planner I fully agree with Yog_Sot, and I would like to see changes in wiki descripton about two separate lines. It should be accepted equaly as one line variant.

2 Likes

Every beginner editor loves creating two lines until he reaches the stage where it is more trouble than benefit. And he finds out about it when he/she wants to add or edit relations with trails to these lines or when he/she comes across two lines on a very narrow road with segregated traffic, where the lines have to overlap.

I also went through this stage, but I am already at this next stage and I know that a single line is a better solution.

The old rule of separating lines in OSM only when physically dividing roads should apply here. Segregated pedestrian and bicycle paths, where you can change lanes at any time (it may not even be against the law) are still one carriageway.

  1. Please consider how a cyclist may need to travel/walk to that intersecting =footway . Not connecting to the =cycleway would break routing. Why should routers immediately assume connecting a =footway means there’s a conflict point? If you want this detail, you should be interpreting the side of travel for bikes and pedestrians. How to tag the side of the cycleway/footway on a segregated path?
  2. Your example still only shows the physical layout. It lacks a functional feature as highway=crossing to show the priority explicitly for routers. Drawing separate lines doesn’t necessarily solve it.

3,4. This really belongs to area:highway= polygons, and barrier=kerb lines complexity. =flush and =lowered are 2 different matters, even if having =lowered is accepted for drawing them separately. What if there’s no flat kerbstone, or different surfacing, only a painted line? Would you still draw them separately?
5,6,7. You didn’t explain why it’s not solved with eg footway:tactile_paving= / footway:crossing:tactile_paving=
8. What you yourself should recognize is those renderers have limitations. Deciding how to draw solely based on some existing rendering is basically the technical form of Mapping For Renderer, while it’s not Lying to them falsely.

Just to add one thing - it’d be great to see more links to examples here (perhaps created from scratch on the dev server) to show what some of these descriptions mean.

2 Likes

Precisely! Also where I live, there are cases where there’s a bus stop (public_transport=platform in OSM-speak) between a road and a cycleway. Without having a separate line for the cycleway the fact that the bus stop exists between the road and the cycleway would be ambiguous at best, and would thus incur a loss of information (comparable to the loss of the other direct attributes you mentioned).

yeah, very good points there
no solution is better than the other in every aspect, that’s why i don’t want to favor any of em.
This is exactly why i mentioned a problem of mapping sidewalks next to a (living_)street, because that even tho we can additionally introduce highway=pedestrian, which is an area, that doesn’t really solve the primary issue.

And hence using routable highway area to a very similiar scenario, when we want to separate a sidewalk from a cycleway, to make a two-liner could be solution to the problems.
But yeah, we’d need first to have it properly routable, not just by a line of its circumference.

Not being able to turn around via a sidewalk on the other side of the street to enter a building entrace there, or turn around from a sidewalk to a cycleway that is next to it, is the main issue that the two-lines don’t solve cleanly and so require arbitrary connection just for a routing sake,
but i do believe that focusing on those links usable just by routings could prove usefull solution to the issue

@Kovoschiz that presentation faces exactly those issues, but show the need of multi-liners as well
– basically, tagging a central line works only so long when nothing within it intersects each other, with traffic signals different distances and everything i described earlier

also answering you more

  1. you can’t plan in advance where someone is going to cross, jump through a barrier or a grass patch, but if the street was designed on purpose with places to do it, you can map that clearly and then it’s a very useful information for routings to detect those traffic collision points and like i pointed out multiple times now, tagging location of footway side, soves only one of the many issues that a two-liner solves right now to a routing without any extra specifications.
  2. by drawing two separate lines with a highway=crossing for the one that is actually crossing the other, you solve exactly that issue and for finding out which traffic type yelds to the other.
  3. .4 like i said, kerbs are actually usefull only for nodes right on a =highway node and you are right that flush and lowered are different values, but yeah, both can occure near, one for footway and the other for a cycleway that are very close to each other. If there are different kerb styles, the only way to map that information is to map a two-liner

5,6,7. those tags are not specified right now and unclear how should be used exactly and so it’s a gues-work for a router programming, while a two-liner is clearly recognizable and was even in the last century :wink:
8. people choose what they see, maybe if osm.org renderer started taking advantage of area mapping or the complex tagging, other mainstream renderers would follow and people choose differently, but just describing situation of the present end-user preference.

1 Like

One-lining is less trouble, but less detail as well.
If you want to map this detail, you take your time :wink:

This arbitrary rule is useful primarly for cars, while pedestrians/cyclists and everyone in between don’t see a barrier, tree line or whatever as real obstruction, hence i have give the living_street example, where YOU do map sidewalks separately and then you do add another arbitrary sidewalks across a street in multiple places to connect these

I have elaborated earlier why drawing a two-liner is an issue, see why it’s a smaller issue and mapping the actually suggested intersections to cross is an advantage.

Good summary quote ;}

But in my opinion, it’s the other way around. It’s similiar to spliting car roads - usually when someone split every lane this is the result of the lack of knowledge. They just don’t know how to do it correctly and don’t bother to check.

While I know @Yog_Sot’s mapping is very detailed, most of cases I stumble upon are not. It’s very rare to actually see the information about kerbs or paving on those splitted cycleways.

I’m sure that some people would not agree with me, but yes, I do think that drawing a parallel line every time You see “something” to split is more lazy.

1 Like
  1. These are not what I’m talking about. Please read again. The origin or destination of a trip with bike use can pass through such an intersecting =footway , or it may be for riding on transit, an intermediate stop, etc. Not connecting it to the =cycleway prevents direct routing.
  2. I don’t see how you can do that. Neither highway=crossing nor *way=crossing indicates priority, especially when it’s between =footway and =cycleway . Can you explain how that would work?

3,4,5,6,7. You are raising a new requirement. That can require somehow “new” tags and methods. By your logic, we shouldn’t start cycleway:*=lane or *:lanes= in the past, because you can simply draw =cycleway and highway= road lines everywhere you like, and they will be rendered or routed.
8. There is no “osm,org renderer” , but 3 of them relevant to bikes. Carto doesn’t render the basics in cycleway:*=lane either. You are only describing how users want it to look, not some “preference” of how the data should be drawn.

  1. yeah, this is the issue @CycleStreets showed in the blog and which i talk about as well. Examine the example of living_street i have given at the very top.
    Say you have got this node and it connects via a way to a sidewalk near, but you can cross the street anywhere you like to reach a shop next to this sidewalk, so how will the routing let you ge there, to entrance node to this shop?
    Yeah, not the shortest straight line possible.
    Even if you one-lined the entire street, you’d still have to draw a separate sidewalk to every single shop entrance at it.
    …Back to a one-lined cycle/footway say you have got a trash bin next to it. Do you connect it with a separate way or assume that because it’s near the way you’re at, you can reach the bin?
    Would it make any big difference if it was two-lined? Still, not really. Would in some cases routing have a sligh problem, yeah, but it’s only a small nuisance compared to not being able to map details you’re able to only by two-lined design.
    But yeah, you gotta map those details, because otherwise a single-liner does better
    @balchen town is a great example perfectly suitable for one-lining, which i have explained in detail that i hope you have understood?

  2. basically, at least in Poland if you have unmarked crossing via a street, you yeld, so this logic can be used for a cycleway via a footway, as a line. If you use it as a node, this is a problem, coz node crossing are specified to be used only for crossing car streets. And similiarly if we got a driveway crossing a cycleway, we don’t have specifications for a line within this driveway, that it’s actually the motor_vehicle that has to yeld.
    But one-lining does not solve the issue. It only partially ommits it and so doesn’t provide the information to routings.

3,4,5,6,7. Yeah, i have proposed a few tags already, so one-lined ways are better. But tagging doesn’t solve all niuanses everytime

  1. Again, users didn’t describe how they want to, but what they want to see in mainstream rendering. CyclOSM rendering shows somewhat better one-lined separation, but it can only gues crossings and position of sidewalk in relation of cycleway, because we never specified tags for that, which we could, but again, won’t solve all issues of complicated intersections, so can’t say one-lining is preffered, while multi-lining is controversial(unwanted)