trivisonno / cycleway-stats Goto Github PK

Right now the list of OSM tags and input boxes feel random. Maybe put them into dropdown/accordion groups... Like General (oneway/lanes/maxspeed/turns/width), Cycleway (lanes/separation/oneway/width), Parking (lanes/width), Bus (lanes/access), Misc. (motor_vehicle access)

The default color for any street without any bike facilities is red, and the assumption is that it lacks safe space for people using cycles.

At certain speeds and traffic volumes, however, such as a 20mph street with very low AADT, does it still make sense to illustrate it with red? This might factor into the LTS use case, which is somewhat different than what this map is trying to illustrate (strictly the presence of constructed bike facilities).

Some cities have 20mph maxspeed limits city-wide. Do the metrics fairly represent the cycling infrastructure of these low-speed areas?

Without some sort of error break, the timer just keeps running

Overpass queries of the OSM road networks often take 30-60 seconds, or more. This long loading time diminishes the user experience, and sometimes makes users think that the tool is broken.

Maybe there's a way to save to S3 and preload some of the data, and let the query run in background and update when it's ready? Also possible that there's someway to more quickly query from the AWS planet.osm database?

When using the centerline shifter input box positioned below the map, you don't intuitively know if selecting larger or smaller numbers shifts the lanes left or right. We will add a red bar above and a blue bar below to hint that selecting numbers in the respective directions shifts the lanes towards the red or blue edges.

With the issues fixed in #20 and #30, need to check and correct any lane length formulas. For example, cycleway=shared_lane and oneway=yes, also cycleway:right=track and cycleway:right:oneway=no and oneway=yes, etc.

A four-lane bridge is marked with sharrows, but also has a separated and physically protected multi-use trail. Technically, the tags could be cycleway=shared_lane and cycleway=separate. Can an OSM item have multiple cycleway tags? Should the map visualize the street as a sharrow or as a separated lane? (yellow or dark blue?)

research what OSM wiki says about this tag

update:
the latest OSM wiki discussion is 10yrs old (https://wiki.openstreetmap.org/wiki/Talk:Key:cycleway:buffer). These tags should probably be changed to cycleway:left=track (if vertical separation) or cycleway:left=lane (if no vertical sep) and then add cycleway:left:separation:?=? to describe the buffer type

example: https://trivisonno.github.io/cycleway-stats/crosssection.html?id=531689530

If the cycleway:lanes tag is used (i.e., a bike lane is between a through lane and a turn lane), then the osmtostreetmix code doesn't put the separation elements in the correct location. This might be a rare edge case.

Now, the app queries two different overpass servers-- the overpass-api.de (German server) and overpass.kumi.systems (kumi server). It's mostly set up to query the kumi server for all the main map street data because it is anecdotally faster and 404s less often than the German server. However, the kumi server is often several hours out of date, so edits to the street don't show up on the map instantly. The German server is only a few minutes out of date, so edits often show up immediately. It may be helpful to allow users to switch between the servers.

this page started from just a blank .html file, and hacked together over time with only a vague sense of how the layout should look.

This may be an easy fix, but I came across a way that threw a JS error.

https://cyclestreetstats.s3.amazonaws.com/crosssection.html?id=522063561

Uncaught ReferenceError: lanesBackward is not defined - osmtostreetmix.js:325

cycleway:left=shared_lane doesn't make sense when oneway=yes (in Portland). it's also a light blue line, but i'm not sure way it gets a blue color and not a yellow color

update:
looks like the sharrow marking is in the left turn lane, which isn't common in the US context

Example is Cuyahoga County, Ohio provides up-to-date aerials. Maybe some sort of select box that pulls from a db of saved additional tile layer sources?

L.esri.tiledMapLayer({
  url: 'https://gis.cuyahogacounty.us/server/rest/services/IMAGERY/2021_Fall_Aerial/MapServer/',
  zoomOffset: -10,
  maxZoom: 21,
}).addTo(map);

Also need some way for the map to preserve the tile layer choice. Cookies?

Revise the color legend to distinguish between light/dark blue, to represent unseparated/separated bike facilities.

Something like a red and blue vertical bars with sky blue in between?

The cross-section tool provides the list of k=v pairs so a user can more simply update a way in iD. However, in practice, with iD this isn't very straightforward and the process is clunky-- you have to go back and forth between the main map.html, then the cross-section.html tool, then iD, and it's just annoying to do if you need to change many streets at once. One option could adding some sort of editing capability directly into the cross-section tool. osm-auth could be useful, but i'll need to learn about the OSM api system first.

Separation buffers between bike lanes and other lanes or other vertical elements may be any width. Default is currently 2 foot wide.

E.g., "https://trivisonno.github.io/cycleway-stats/crosssection.html?id=4570326"

render issue with https://www.openstreetmap.org/way/102189493

turn:lanes need to plan for a "none" value

oneway issue with bike lanes

Feature request to allow visual filtering by facility type. I.e., only show sharrows/lanes/tracks/etc.

Multiple users suggest focus on using the map to generate rough LTS visuals. Most state DOTs have traffic count data in a GIS form. We either need some way to integrate this data in browser, or develop an OSM proposal to include recent traffic counts within the OSM data. I would initially propose something similar to population and census data, that's applied to administrative nodes.

Clicking the increment button to shift the centerline would repeatedly redraw the cross section graphic

maybe use a leaflet bbox to query the osm api, then osmtogeojson module, etc.

There are edge cases where the lane widths in the forward and backward directions are very clearly different. For instance, a roadway where one direction of lanes is 12' and the other direction is 11'. This isn't very common, but it happens. Time-of-day-dependent parking lanes is also another example case.

This also sometimes happens for bike lanes and parking lanes. E.g., one bike lane is 6' and the other is 5'.

Solution will probably be to add additional inputs for the width:lanes:forward and width:lanes backward. Although I feel like "lanes:forward:width=12" or "lanes:forward:width=12'|11'" is more intuitive, since it matches how we define widths for other lane times.

parking:lane:left:width, parking:lane:right:width (instead of parking:lane:both:width)
cycleway:left:width, cycleway:right:width (instead of cycleway:lane:width)

Other info:
https://wiki.openstreetmap.org/wiki/Key:width#Width_of_streets
https://wiki.openstreetmap.org/wiki/Key:cycleway#Supplementary_details (refers to "cycleway:right:width")
https://taginfo.openstreetmap.org/keys/width%3Alanes%3Aforward#overview

Also connected to #36

sometimes a sharrow and a turn marking are used together in a lane. maybe include the markings side-by-side?

Idea:
Add “proposed:cycleway”=”lane” (etc) tags to ways where localities are already proposing/planning new cycleways, and possibly mark these in the data tables in popup? “proposed:cycleway:source:ref”=”https://*.pdf” (link to city planning website or PDF?)

https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

Similar to #4. Better distinguish between separated and unseparated bike facilities (dark/light blue) within the metric modal.

The lanes only show basic inbound/outbound direction lane marking arrows. Add support for turn markings.

Colored lines will only appear if the highway is a cycleway/primary/secondary/tertiary (or _links of these). Residential streets with shared_lane, lane, etc are not shown by default, unless you mouseover them. This ignores the presence of intentional bike routes that may be designed through residential areas, for example.

However, there may exist edge cases where large portions of the residential street network include bike facilities, and it may create some amount of visual "clutter". A toggle option may also be useful for this feature.

A user may wish to view the data from a particular past date--i.e., what did an area's bike infra look like five years ago?

We can prepend a date filter tag with the overpass query, ala [date:"2020-10-28T19:20:00Z"][out:json]...

Merge 784f740 fixed an issue where the lane labels in the cross-section tool sometimes would override the cell width when the text label was too long. The text css was changed to force overflow, but this creates another issue. Sometimes the text overflow is fine when there is enough room, but sometimes it can cause text to overlap other text.

The current default is that the bike lane is always positioned to the right of all motor vehicle lanes.

This is sometimes not the case, especially with bike lanes near intersections with right-turn lanes. (Example: https://trivisonno.github.io/cycleway-stats/crosssection.html?id=34570287)

osm just has a single width tag for lanes, i.e., all lanes are assumed to have equal widths.

FYI, the current javascript code is not elegant, but it works (mostly). I'm sure it can be cleaned up now that's its generally stable. Most of the time a user waits is for the overpass query, and generally only a second or two for the JS to run thru the returned geojson and map rendering.

Right now a cycle track is assumed to be two-directional, which is not necessarily always the case. Cycle tracks only mean, generally, that there is a physical/vertical separation element between the bicycle lane and the motor vehicle lanes.

See slides 12/13: https://raw.githubusercontent.com/OSM-DCT-Lyft/US/master/osmtrainingmaterialsfeatures/Bike%20Lanes.pdf and other OSM cycleway definitions. See also: https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/separated_bikelane_pdg/page01.cfm#chapter1

Also need to update the length metric calculations, I think a cycle track is assumed bi-directional.

Some road ways include points that position them very left/right of the true curb-to-curb center. Some sort of tool that allows a user to more precisely center the way geometry to the center of the street.

Maybe just generate the donut charts with pure svg?