Bike lanes adjacent to parking

[spencerrecneps]

Old BNA: Tertiary road with default parking (8 ft) + bike lane (5 ft) gets low stress because 13 ft reach is considered low stress. This is consistent with P Furth's tables.

pyBNA: Tertiary road with default parking (8 ft) + bike lane (5 ft) gets high stress. I'm not convinced 13 ft reach should be considered low stress on a busier street with adjacent parking. A lot depends on context. If parking usage is moderate this can be stressful since you have to be more concerned with door zone conflicts and turnover. If parking usage is low this is low stress. This is something we've introduced in some of our projects for clients. Our modified tables in this case require 14 ft (8 ft parking + 6 ft bike lane--effectively a buffered bike lane) in order to be low stress.

I think this comes down to what we want to assume. The pyBNA tables are likely to render most bike lanes in most cities high stress since we assume parking if there's no OSM data making it explicit. Based on my experience in Chicago, parking-adjacent bike lanes are high stress facilities. Based on my experience in Madison, parking-adjacent bike lanes in residential areas are low stress facilities since parking isn't as heavy and you just needed the bike lane to pass the occasional parked car.

We could also consider introducing a configuration parameter that lets the user set an assumption for parking usage. e.g. you could set city-wide parking usage to low and get one result or high to get another result in these locations.

[spencerrecneps]

@beckymasond would love your thoughts on this. I've had discussions with P Furth in the past and could also reach out to him if you'd like his thoughts.

[beckymasond]

Leaving in the pyBNA assumption as it is, I like the idea of the configuration parameter given the variation between cities as you mention. Tertiary streets occupy the most ambiguous space in the OSM functional class hierarchy and the config parameter could help narrow that down. A couple of follow up questions: If ADT is provided, would that data override the parking setting? Also, do you see reason to consider the impact of the parking setting on residential or unclassified streets?

[spencerrecneps]

We could definitely set up ADT to impact parking, but the changes I've described here would be separate from ADT.

No need to consider residential/unclassified. This is because the presence of a bike lane automatically kicks a residential/unclassified up to being treated as a tertiary. The thinking here is that you wouldn't put a bike lane on a street intended for low volumes. So if a bike lane is there, we're basically assuming it functions more like a tertiary street.

[spencerrecneps]

I've updated the LTS spreadsheet from the website to show how the parking change could be accommodated. See changes in red text.
Charts.for.LTS.Definitions.2020-0413.xlsx

[spencerrecneps]

Under the changes in the spreadsheet, we'd basically be keeping the analysis unmodified except in cases where the user specifically sets the assumption to low parking.

[beckymasond]

In the revised spreadsheet, a tertiary road with high parking utilization and 13 ft facility width is treated the same as the same road with low parking utilization. But wouldn't the change mean that under the high parking utilization scenario a 14 ft or greater minimum facility width would be required for the street to function like there is low parking utilization?

[spencerrecneps]

My mistake. I forgot to update the reach requirement. Here's a corrected version.
Charts.for.LTS.Definitions.2020-0414.xlsx