Include separate cyclepaths and trails

[dabreegster]

Splitting from a-b-street/abstreet#139. The goals here are just:

1. connectivity -- can bikes successfully route over things like the Burke Gilman as expected
2. geometry + rendering -- does it look reasonable
3. bike-only -- just model as one or two bike lanes, ignore foot access for the moment. (Once this bug is solved, Support shared pedestrian/cycling paths using an accordian queue abstreet#139 can add a special lane type that has mixed access)

[dabreegster]

Solid start! Going better than the last attempt because of the lane unit tests, not attempting sidewalks yet, squishing the width down.

First milestone is to get the udistrict map working well. Already I spot lots of data issues (missing oneway tags, some need for cycleway=separate on roads). I'll make a round of fixes in OSM and then see what the next issues are.

[dabreegster]

An update on why this is still hard:

1. OSM almost never has road width tagged, so A/B Street makes guesses based on the number and type of lanes. Separate cycletracks next to a road often overlap, because the road center in OSM isn't perfect, or the inference is wrong.
2. A/B Street lets you edit lane types for a particular road, but if there's a parallel cycletrack to a road way, then this sort of editing isn't possible. You couldn't turn a cycletrack into parking or a bus lane or whatever else. Less of an issue, but the representation is still messy.
3. To simulate "modality transfers" like walking up to a parked car or ending a biking trip by moving onto a sidewalk, A/B Street needs to know the lanes are adjacent to each other and traversable in this way. Separate cycletracks have no association with the parallel footpaths; we have to make geometric guesses and assume there isn't a barrier.
4. Inferring good geometry when OSM has many short ways and "intersections" next to each is hard. Separate cycletracks aggravate this.

[mvl22]

My talk about this whole area of mapping styles, giving context on this general issue, is at:

https://www.cyclestreets.org/news/2019/09/22/sotm2019/

(Video and slides).

[dabreegster]

It's been a while since I've watched that talk -- it's spot-on in identifying the problems. Since some sort of large-scale shift to the OSM schema isn't likely, I've been trying to workaround these problems as reasonably as possible. One recent trick that may help mitigate a problem here is inferring the entire junction shape either by explicitly tagging some short inner segments with junction=intersection or using heuristics, then feeding into a-b-street/abstreet#114 (comment).

Another approach I've attempted to solve this problem is to automatically infer the street relation and snap the separate cyclepaths to the main road geometrically: https://github.com/dabreegster/abstreet/blob/ddc49e14b4bdb2cb730ea753cb6a8e495a9e1801/convert_osm/src/snappy.rs#L106
This preserves the extra attributes on the separate way, but uses A/B Street's regular lane geometry (projected from the road center) instead of the more detailed OSM geometry that's usually missing width.

For the possible ActDev integration, I can focus my efforts in this issue on the specific areas we're studying.

Oh yeah, and I'd love to someday whiteboard ideas for a new OSM schema to handle this. Your talk mentions tessellating/partitioning 2D space. I've had a similar idea that I've never fleshed out, where an interval along the ring of adjacent polygons could be tagged with data, representing curb regulations or things like curb ramp slope. I'd be interested in hashing out how this sort of schema might work -- although the effort to actually shift OSM to it might be intractable, having an ideal model in mind could be quite valuable.

[dabreegster]

Reviving this effort, enabling only in Cambridge for a-b-street/abstreet#449. Regenerating all maps before pushing a commit, but initial results are looking promising:

Although in some places, the inferred width does overlap the road:

(This is https://www.openstreetmap.org/way/221410673 -- I haven't checked imagery yet, but maybe things like this are mistagged and are really one-way?)

[mvl22]

Oh yeah, and I'd love to someday whiteboard ideas for a new OSM schema to handle this. Your talk mentions tessellating/partitioning 2D space. I've had a similar idea that I've never fleshed out, where an interval along the ring of adjacent polygons could be tagged with data, representing curb regulations or things like curb ramp slope. I'd be interested in hashing out how this sort of schema might work -- although the effort to actually shift OSM to it might be intractable, having an ideal model in mind could be quite valuable.

The discussions held outside the conference room after the talk essentially filled in the missing piece of what my talk was proposing.

Essentially the idea of making a container for street objects and junction objections can be done using the existing schema and OSM geometry types, with one addition: essentially area=street and area=junction.

In the absence of these at OSM level, you could solve this architecturally in the short term by maintaining a separate set of polygons, drawn over an OSM but saved as a distinct dataset, and then superimpose that into the raw OSM data you have and apply ST_Contains -type queries to determine what is in the polygon and pre-process those to get the overall angles between streets and the entry/exit to/from a junction. Clearly this doesn't really scale, hence the need for an official OSM tag, but I think it will be hard to algorithmetrically for all the reasons given in my talk.

[dabreegster]

In the absence of these at OSM level, you could solve this architecturally in the short term by maintaining a separate set of polygons

This is an interesting medium-term workaround. I've tried maintaining some derivative data not in OSM and found that it gets out-of-date pretty quickly and painfully. But that data references OSM IDs and was sensitive to somebody splitting an existing way. Maintaining hand-tuned polygons would be much easier. I've been approximating the definition of "short mergable roads" with junction=intersection, but applying this tag to many places has its own issues.

[mvl22]

Yes, referencing OSM IDs is rarely a sustainable solution, and hand-tuned polygons can obviously dynamically generate that list by doing an intersection.

[dabreegster]

@mvl22 The latest import of Trumpington now has shoulders along almost every cycleway, allowing foot traffic too. Works fine from a routing and simulation perspective, and I'm working on improving geometry. Biggest problem I see is duplicate infrastructure. Here are two cases -- any ideas you have would be appreciated.

https://www.openstreetmap.org/way/49207928

A/B Street is interpreting the separate cycleways on both sides of the road as bidirectional (because there's no oneway=no, and it also puts a shoulder for walking on both sides of both. On the main road, there's no tagging about sidewalks at all, and because I'm still using configuration to infer sidewalks, it's placing a sidewalk on both sides. From looking at street imagery, I'm actually a bit confused what's going on here (likely different paint conventions between the UK and US). From west-to-east, I see a two-way separate cycletrack, a regular road with one lane each direction, a terrifyingly narrow red shoulder whose use I hope isn't a bike lane, and a sidewalk that doesn't look designed for bikes. The main road has cycleway:oneside=lane in OSM, a tag I can't find in the wiki. So IIUC, there's at least one tagging issue here -- the cycleway on the east should be a footpath.

https://www.openstreetmap.org/way/93536212

From squinting at ground imagery, I think everything here is actually fine. The main issue is either that the separate cycleway linked isn't actually bidirectional, or the width I'm inferring in abst is way too large.

[moo]

I'm just poking around, so lmk if this is tackled elsewhere. Per:

1. OSM almost never has road width tagged, so A/B Street makes guesses based on the number and type of lanes...

Would it be useful to correctly tag OSM road widths - at least for roads we'd like to simulate here?

[dabreegster]

Would it be useful to correctly tag OSM road widths - at least for roads we'd like to simulate here?

It's probably quite tough to measure the width for many roads, but just focusing on some that cause problems in A/B Street could be a reasonable start. Defining the width takes a little care: https://wiki.openstreetmap.org/wiki/Key:width#Width_of_streets

One complication with using a more accurate road width from OSM is figuring out what kind of lane edits are valid. Currently in A/B Street, you could turn any bike lane into a bus lane, but in reality, this is unlikely to work. I haven't yet thought through how to make this work. This would maybe be a non-issue for separate shared-use bike/walking paths; I can't think of any edits that'd be useful to make to those within A/B Street.

[Robinlovelace]

Briefly discussed this today with @mvl22. Looks like great progress from my perspective in any case but I'm not the expert on OSM representation of cycleways, will defer to Martin's judgement on that. Context (I think the video is available somewhere also): https://pretalx.com/sotm2019/talk/DW7WW8/

[mvl22]

The latest import of Trumpington now has shoulders along almost every cycleway, allowing foot traffic too. Works fine from a routing and simulation perspective, and I'm working on improving geometry. Biggest problem I see is duplicate infrastructure.

There were very many areas along that whole stretch, so I'm not surprised you were getting anomalies. I've spent an hour tidying up that whole corridor:
https://www.openstreetmap.org/changeset/97999161#map=15/52.1821/0.1130&layers=C

The cycleway on the east side was bogus so is now removed. However there is bus lane and cycle lane provision along various sections. These are now correctly marked on the east side (explicitly) of that road.
https://www.openstreetmap.org/way/49207928#map=19/52.17743/0.11391

The cycleway on the west side is two-way shared-use. I've explicitly noted it as oneway=no, as that was missing.

Sidewalk tagging has also been added along the road itself, to switch off the west side, where the cycleway is:
https://www.openstreetmap.org/changeset/97999483

[mvl22]

https://www.openstreetmap.org/way/93536212
From squinting at ground imagery, I think everything here is actually fine. The main issue is either that the separate cycleway linked isn't actually bidirectional, or the width I'm inferring in abst is way too large.

It's basically correct, though it's not that wide; I've set the width and two-way explicity now.

https://www.openstreetmap.org/changeset/97999698

[mvl22]

It's probably quite tough to measure the width for many roads, but just focusing on some that cause problems in A/B Street could be a reasonable start. Defining the width takes a little care:
https://wiki.openstreetmap.org/wiki/Key:width#Width_of_streets

One complication with using a more accurate road width from OSM is figuring out what kind of lane edits are valid. Currently in A/B Street, you could turn any bike lane into a bus lane, but in reality, this is unlikely to work. I haven't yet thought through how to make this work. This would maybe be a non-issue for separate shared-use bike/walking paths; I can't think of any edits that'd be useful to make to those within A/B Street.

In the case of the UK, width of main roads within towns/cities is so rarely done I wouldn't personally worry about the detail about subtractions for parking lanes, etc.

[dabreegster]

@mvl22: Thank you for making all of these fixes! Much easier to adjust code when the data is more correct. Trumpington Road looks much better now:

The challenge on my end is handling cyclepaths that're directly next to the road, like https://www.openstreetmap.org/way/4040874. A separate way here is great, because of extra details like est_width = 1.5. I have some old code that tries to find cases of separate cyclepaths that're parallel to the road, and internally merges them together for a simpler representation. I'll try applying that here.

[mvl22]

Trumpington Road looks much better now

Yes, that's definitely getting better - well done. (I was surprised when editing how bad the data actually was.)

However, the on-road cycle lane in the south-west of that picture is incorrect - it should be on the other side of the road (and it's presented visually rather wide, given that the main road lanes will generally be at least 3m each in the UK):

cycleway:right = lane
cycleway:right:width = 1.25

The internal line directionality is going from bottom to top, so right in this case refers to the east side.

I took care also to add sidewalk tagging along Trumpington Road, which you might like to pull in:

sidewalk:left = no

For Long Road, you can see plenty of photos of Long Road (and elsewhere), at:
https://bikedata.cyclestreets.net/photomap/#16.79/52.180026/0.123372

[Robinlovelace]

First thing to say: amazing work getting this working, seeing people in Cambridge going North from Great Kneighton on dedicated infra was a sight to behold!

First thought: could be a good motivation to engage with the wider OSM community as I know @mvl22 has done in various lists/events. Where's the best forum to talk about these things, or is it worth emphasising it on the wiki page https://wiki.openstreetmap.org/wiki/Key:cycleway

Thinking that this may be one to encourage people to fix 'upstream' upon data entry/edits to avoid dozens of work arounds in the code to fix edge cases.

One thought on dealing with poorly tagged/wrong cycleways: assess whether each link is potentially 'useful' for example by being more than a minimum threshold length or connecting to previously unconnected ways, plus of course actually being navigable. But that may add even more complexity, just ideas and look forward to hearing what people who know more about OSM cycleways actually think. Suggestion on that: point Martin to the latest A/B Street build for Cambridge (is this it? https://actdev.cyipt.bike/abstreet/?--actdev=great_kneighton ) and use that as a basis for evidence-based (rather than in my case speculative) discussion!

[dabreegster]

Many duplicates in Seattle fixed. Still a messy representation, but closer:

Where's the best forum to talk about these things

I split out https://a-b-street.github.io/docs/side_projects/osm_viewer.html specifically for the OSM community to have an easier way to visually audit their work. There are many steps to make this workflow easier, like importing a map just by selecting a region and pulling down fresh OSM updates without my intervention. I already advertise this tooling on the OSM mailing lists, osmus Slack, Twitter, etc. Organic growth is fine for now; I need more help improving the software and automation before I'd want a worldwide audience requesting imports. :) But getting there is a goal.

being more than a minimum threshold length or connecting to previously unconnected ways

There are some debug tools in the game that help me find problems, like finding all reachable lanes from a start lane. (Ctrl+D for debug mode, click a lane, f to floodfill.) I could also find all of the separate bike paths that terminate at a dead-end intersection -- it almost always means I'm missing some combination of tags to treat as a cycleable path. I'm still working through a few of those obvious cases; ground knowledge is still faster than a tool right now.

point Martin to the latest A/B Street build for Cambridge

I haven't rebuilt the actdev release yet; http://abstreet.s3-website.us-east-2.amazonaws.com/dev/game/?--dev&system/gb/great_kneighton/maps/center.bin&--cam=14.90/52.19323/0.13427 is the most recent. Feel free to take a look and see if any paths are missing or coming out particularly weird, and leave a list of places I should check. If you click an intersection with dev mode (Ctrl+S) activated, there's a button to open the OSM node. That's the easiest way to point me to somewhere I should check.

[mvl22]

First thought: could be a good motivation to engage with the wider OSM community as I know @mvl22 has done in various lists/events. Where's the best forum to talk about these things, or is it worth emphasising it on the wiki page https://wiki.openstreetmap.org/wiki/Key:cycleway

On the mailing lists, e.g. talk-gb.

However, I'm sceptical that A/B Street is ready to be an ideal tool for people spotting things. Firstly it covers only a few areas, not the whole world. Secondly, there is clearly more support needed within the tool before people can rely on it picking up infrastructure every time (e.g. bicycle on footways only just added, and there are bound to be many other edge-cases for unsupported cases that mean people can't really be sure if it's the renderer or the data). And thirdly, the standard cartographic maps render these issues anyway, and are very heavily debugged with over a decade's work on them. A slippy map will inevitably be quicker to browse around anyway. E.g.:

https://www.openstreetmap.org/#map=19/47.73185/-122.34795&layers=C
is already abundantly clear that the data was wrong there.

It may be better for turn-ban -related matters, which are rarely visualised on a slippy map.

For connectivity-related issues, KeepRight remains the tool of choice and is unlikely to be beaten, as it does a lot of spatial analysis of really nasty problems.
https://wiki.openstreetmap.org/wiki/Keep_Right

[matkoniecz]

However, I'm sceptical that A/B Street is ready to be an ideal tool for people spotting things.

Depends on type of issue. For me it was useful for spotting missing bus lanes (I am still mapping them slowly as setup in my city is quite irritating to map) and some badly mapped lanes.

[dabreegster]

Momentum on fixing particular problems around Seattle has slowed down. Recording where I left off:

• UW trails cut off here: https://www.openstreetmap.org/node/4702479614
• Connectivity on the Burke breaks around here: https://www.openstreetmap.org/node/31251900

[dabreegster]

Not picking this back up anytime soon, but hints on the Burke Gilman connectivity: https://www.openstreetmap.org/changeset/101924345

[dabreegster]

Moved to the osm2streets repo, where I'm renewing efforts on this. No promises, but State of the Map next week is the much-needed deadline...

[dabreegster]

The default in osm2streets is now using separate cycletracks and footpaths as they are in OSM. Still have ongoing efforts to improve the geometry and optionally zip/snap things together