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, a-b-street/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 https://github.com/dabreegster/abstreet/issues/114#issuecomment-751918520.

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

[dabreegster]

should be on the other side of the road

Indeed! This is almost certainly another bug in my OSM tag -> lane type mapping. I don't yet have consistent handling for left-handed driving. Looking into this.

it's presented visually rather wide

I'll think a bit more about how to use width from OSM and/or infer better defaults, and probably start a separate bug for this.

sidewalk:left = no

I was wondering why this wasn't being picked up -- it's because I'm using https://wiki.openstreetmap.org/wiki/Key:sidewalk#Values; I think this should be sidewalk = right. I can go make some fixes in OSM shortly. I might also make the importer a bit smarter here; I've seen this other style and made this mistake before too.

https://taginfo.openstreetmap.org/keys/sidewalk%3Aleft#overview Loads of uses. Yeah, I'll edit the importer and treat this as valid. Sometimes I wish mass automated cleanups did happen in OSM, when the community settles on something in the wiki.

Edit: https://wiki.openstreetmap.org/wiki/Key:sidewalk#Separately_mapped_sidewalks_on_only_one_side I completely missed this! Regardless, updating the importer.

[dabreegster]

@mvl22: Some questions about how to make reasonable assumptions for missing values. Take https://www.openstreetmap.org/way/898731283 as an example.

• sidewalk:left=no -- should that imply sidewalk:right=yes?
• lanes=3 on a two-way road; would you say lanes:forward=2 and lanes:backward=1 is the reasonable split?
• How should I interpret psv:lanes:right = no|no? I guess that kind of implies lanes:backward=2? And maybe the single forward lane is bus-only?
• I'm currently using bus:lanes:forward (or psv), not left/right. Is it typical around Cambridge to prefer one over the other?

One of my medium-term goals is to split out a dedicated library that takes in tags for a single way and emits the inferred lane types and directions in some canonical ordering. Part of that would handle missing/ambiguous values mentioned here. My hope is to get other OSM routing/editing/viz software to use it or at least contribute to the rules, so that there can be something closer to agreement about how to handle things like this.

CC @matkoniecz for any feedback about the library idea. I'm essentially talking about https://github.com/dabreegster/abstreet/blob/master/map_model/src/make/initial/lane_specs.rs, which has output like https://github.com/dabreegster/abstreet/blob/f69335edf052540ca23d8ccdc177474bb7be6e50/map_model/src/make/initial/lane_specs.rs#L396

[matkoniecz]

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

https://wiki.openstreetmap.org/wiki/Key:area:highway - it can be done directly within OSM

Loads of uses. Yeah, I'll edit the importer and treat this as valid. Sometimes I wish mass automated cleanups did happen in OSM, when the community settles on something in the wiki.

Some are happening ( https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account ), though for some reason OSM community often preferers to make such edits in distributed way via automatic fixes in a validators

[matkoniecz]

sidewalk:left=no -- should that imply sidewalk:right=yes?

No idea. I would just do not use it in assumptions, but with such missing data any version is OK (I assume that sidewalk tag has nothing tagged).

lanes=3 on a two-way road; would you say lanes:forward=2 and lanes:backward=1 is the reasonable split?

Yes, if it is not specified explicitly then it is a reasonable guess. Hopefully validators, StreetComplete and so on detects this...

I'm currently using bus:lanes:forward (or psv), not left/right. Is it typical around Cambridge to prefer one over the other?

:left :right suffix here is mistagging without justification

psv:lanes:left is not a thing

see http://taghistory.raifer.tech/#***/bus:lanes:forward/&***/bus:lanes:backward/&***/bus:lanes:right/&***/bus:lanes:left/&***/psv:lanes:left/&***/psv:lanes:right/&***/psv:lanes:backward/&***/psv:lanes:forward/

How should I interpret psv:lanes:right = no|no? I guess that kind of implies lanes:backward=2? And maybe the single forward lane is bus-only?

This tag should be ignored, maybe raise complaints in logs.

psv:lanes:forward=no|no is still bizarre, what kind of road forbids specifically psv? In addition, if all lanes are blocked then it should be psv:forward=no

[matkoniecz]

One of my medium-term goals is to split out a dedicated library that takes in tags for a single way and emits the inferred lane types and directions in some canonical ordering. Part of that would handle missing/ambiguous values mentioned here. My hope is to get other OSM routing/editing/viz software to use it or at least contribute to the rules, so that there can be something closer to agreement about how to handle things like this.

Main barrier here is that different potential users use different languages (Rust vs Kotlin vs C++ vs JS vs whatever is used by lane renderer style in JOSM)

I suspect that easiest to reuse may be "tag -> standard data "format tests.

But I suspect that it is kind of thing where someone starts from simple cases without noticing full complexity (or without plans to support it), keeps adding feature by feature and ends with homegrown wheel duplicating other wheels.

[dabreegster]

Main barrier here is that different potential users use different languages

Definitely a problem. In practice, possibly just two implementations might suffice for most interested parties -- Rust can be callable from JS (via WASM) and C++, and Java (for Kotlin and Scala as well).

keeps adding feature by feature and ends with homegrown wheel duplicating other wheels.

Agreed, that's what I'd like to help prevent by making a standard library. In this case, I'd get agreement from everybody relevant first -- StreetComplete, https://github.com/BjornRasmussen (new JOSM lanes plugin), ID, probably missing some.

[matkoniecz]

BTW, I raised https://www.openstreetmap.org/note/2512468 for https://www.openstreetmap.org/way/898731283

And created https://wiki.openstreetmap.org/wiki/Key:psv:lanes:backward https://wiki.openstreetmap.org/wiki/Key:psv:lanes:forward https://wiki.openstreetmap.org/wiki/Key:bus:lanes:backward https://wiki.openstreetmap.org/wiki/Key:bus:lanes:forward

(so on next update of page list OSM Website will start linking this pages, and within 24h hours taginfo should start using their descriptions in tag listings)

[dabreegster]

The cycleway is on the proper side now, and sidewalk:left=no gets used. Bus lane still missing because of the issues Mateusz mentioned.

Next biggest map quality issues here are probably snapping some of the separate cycleways to the road, and trying to merge intersections.

[mvl22]

:left :right suffix here is mistagging without justification psv:lanes:left is not a thing

Sorry, these must have arisen from a copy and paste error when I was working through that commit, which took over an hour because there were so many bugs in the previous situation.

It should indeed have been psv:lanes:backward = yes|designated as fixed in https://www.openstreetmap.org/changeset/98166752#map=18/52.18138/0.11675&layers=CN

[mvl22]

sidewalk:left=no -- should that imply sidewalk:right=yes?

Our working assumption has always been that pavements ("sidewalk"s) are present unless stated otherwise. In other words, sidewalk:left=no is an exception to the norm. It would be an obvious annoyance for 99.9% of highways in OSM to have the clutter of sidewalk=yes.

lanes=3 on a two-way road; would you say lanes:forward=2 and lanes:backward=1 is the reasonable split?

Could be either way round; I would make no such assumption.

In this case it can be inferred as psv:lanes:backward = yes|designated provides a positive indication that the backward direction has two lanes. And therefore the forward direction has one.

How should I interpret psv:lanes:right = no|no? I'm currently using bus:lanes:forward (or psv), not left/right

You should throw it away :) Sorry, late night junk data; I'm normally far more careful!

[mvl22]

And created https://wiki.openstreetmap.org/wiki/Key:psv:lanes:backward https://wiki.openstreetmap.org/wiki/Key:psv:lanes:forward https://wiki.openstreetmap.org/wiki/Key:bus:lanes:backward https://wiki.openstreetmap.org/wiki/Key:bus:lanes:forward

I would delete the "possible synonym" sections - that was just a specific error probably from copy-paste from the cycleway lane tagging, and not based on something I saw elsewhere.

[mvl22]

One of my medium-term goals is to split out a dedicated library that takes in tags for a single way and emits the inferred lane types and directions in some canonical ordering. Part of that would handle missing/ambiguous values mentioned here. My hope is to get other OSM routing/editing/viz software to use it or at least contribute to the rules, so that there can be something closer to agreement about how to handle things like this.

Welcome to an enormous can of worms.

[matkoniecz]

I would delete the "possible synonym" sections - that was just a specific error probably from copy-paste from the cycleway lane tagging, and not based on something I saw elsewhere.

done, I initially thought that it is more popular

It would be an obvious annoyance for 99.9% of highways in OSM to have the clutter of sidewalk=yes.

It kind of depends on location, in some places people prefer to not tag sidewalk to avoid sidewalk=no clutter, in some prefer to not tag sidewalk to avoid sidewalk=yes clutter - and automatic processing will often guess badly...

I kind of think that explicit tagging is OK in such case.

[belt-drive]

Not sure if this is the right place to post about this, but I was looking through OSM and I noticed that the Chief Sealth bike/multi-use trail is in OSM but it is not currently represented on the South Seattle map in AB Streets. Just pointing out another example of a trail that would be nice to include, along with the Burke Gilman in Seattle that @dabreegster mentioned above. Including the I-90 multi-use trail would be interesting, too, but seems like a UI nightmare because a portion of the trail is on a lid over the highway.

[dabreegster]

@belt-drive, these trails are currently configured to not be imported. See the first few comments in this issue for some pictures showing why. I've been making progress cleaning up the issues by experimenting in Cambridge, and my hope is to also enable them for Seattle soon. But getting full scenarios to complete without gridlock is currently a higher priority in Seattle, and the separate cyclepaths make that harder.

[dabreegster]

I'm going to attempt to import all the cyclepaths for Seattle again. Only blocking criteria for success will be not introducing new gridlock on the few maps that're running today. After it's done, I'll focus on deduping bike lanes marked on roads next to separate cycleways, and make sure the entirety of trails are getting imported and are working from a connectivity perspective. Rendering/geometry will suffer, but I think it's time to get these consistently imported, so I'm more motivated to work on it.

The plan's in 3 steps: 1) Enable in Seattle, do the minimal sanity check there 2) Remove the experiment flag and enable for all maps 3) Less urgently, improve the paths around Seattle (likely a mix of code and OSM fixes)

A quick list of places I want to hand-audit, based on personal familiarity:

• [ ] the Burke
• [ ] the Roosevelt PBL
• [ ] University bridge
• [ ] Fremont bridge
• [ ] Ship canal trail
• [ ] Elliot bay trail
• [ ] Westlake cycletrack (and see how the parking lots there get snapped)
• [ ] Interurban north
• [ ] West Seattle low bridge & Alki trail
• [ ] Broadway cycletrack
• [ ] 520
• [ ] I90

[dabreegster]

No gridlock, so Seattle is now cutover! I'll switch the rest of the maps and cleanup the flag next.

There are lots of problems with the imported cyclepaths around Seattle, but the good news is that many of them can be fixed by OSM edits, it's very easy to spot the problems, and I have knowledge of what's on the ground. I'll post some examples and get started cleaning them up after finishing step 2.

[matkoniecz]

Yet another case of "I made tool for making something out of OSM data - and I made QA tool monitoring OSM quality as a side effect" :)

[dabreegster]

Alright, rebuilding all maps now.

I wanted to thank @matkoniecz, @Robinlovelace, and @mvl22 for pushing on this issue. It's something I wanted to do from the very beginning, but I kept punting because it's such a hard problem to properly fix. Mateusz found smaller sets of OSM tags to start bringing in, which got the ball rolling. Then the actdev work forced me to do the import for UK maps, and after hashing out some of the issues there, I realized there's no excuse not to do it for Seattle too.

A very short list of problems to work on around Seattle below. I'll split out separate issues if any of it seems focused/hard, but keep lumping everything here otherwise.

Many parts of the Burke (and others) get randomly chopped out, because the trail is tagged as a footway for some sections. https://www.openstreetmap.org/node/4707186038 is one. We can just treat highway=footway, bicycle=yes the same as these cyclepaths (a skinny bike lane each direction and a shoulder for walking on both sides). I thought we were doing that before, but that's the problem with experiment flags -- I forgot what things were just enabled in some branch.

Duplicates, where the main road has the bike lane tagged, and there's also a separate way. I'm responsible for tagging the main road in some of these cases, way back when I was still not sure how to handle all of this. https://www.openstreetmap.org/way/39877378 is one example of many. I'll just go through OSM and fix.

Road width and cycletracks overlapping. https://www.openstreetmap.org/node/60004951 is one example. Besides auditing number of lanes and street parking, not sure what to do about these yet. They're cases where from abst's perspective, it'd be better if the cycletrack was treated as a lane of the main road. I have experimental code to snap to roads that I can eventually revive.

[mvl22]

Duplicates, where the main road has the bike lane tagged, and there's also a separate way.

Yes, an annoyingly common problem in OSM. People forget to make that final deletion having upgraded things to a separate Way.

[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