Draft:United States/Cycling
This page is a template and hopefully conversation stater focused on covering the best practices and opportunities of mapping cycling in the United States across multiple disciplines, including but not limited to: Road, Mountain (MTC), Cyclo-cross (CX), Cross Country (XC), Urban/Suburban Commuting, BMX, Pump Track, Gravel, Bike Packing (also known as touring), Adaptive Cycling, and more as area of conversation come up. As bikes cross the trail, road, pedestrian, and ironically building storage spaces (because of eBike bans in some places) this page is focused on aligning with those overlaps and expand as suitable.
This will also be a place for discussion about technical oddities like how switching between bike lanes and multi-use paths aren't clear either in physical or logical mapping layers and possible solutions/approaches to improve or this things like this. Also, this page is intended to complement not conflict with or contradict best practice on either the road, trail, or pedestrian sides of mapping cycling. Be aware that cycling sits in a bit of a cultural and mapping gray area as differing positions many times within the same community can argue bikes don't belong on sidewalks, but conversely don't belong on roads either. For soft surface trails, bikes also sit in a technologically developing market where things like eBikes, electric unicycles (EUCs), electric dirt bikes (like Surons), and electric adaptive biking all jockey for position. Off the roads and in urban applications, eBikes with cheap batteries have also caused concerns and bans about the storage and charging of eBikes which themselves have mapping consideration.
Background
Cycling is not one thing. To most people cycling is just something people do for exercise and if you’ve seen one bike you’ve seen them all. To someone that has become deeply embedded into the cycling community at a national level as my hometown area has become a cycling hub for every variety of biking there is, my view of biking has become quite diverse and how I’ve approached mapping cycling has matured and grown. I think a lot of people within the OSM community look at https://wiki.openstreetmap.org/wiki/Bicycle and scroll through pages and think, "man, it looks like you’ve got is all covered." However, I see this page, I almost entirely see one type of cycling covered: Urban/Suburban Commuting.
The mere fact that bike can be way fasted than pedestrians but not as fast as cars puts cycling in a bit of an uncanny valley where two towns only miles apart has one trying to ban bikes from roads while the other is trying to ban them from sidewalks. Thus bike mapping typically can involve mixing of on and off-road multi-use mapping and intermixing the two is a bit 'clunky' on OSM when a bike lane ends how do you physically map the multi-use path suddenly appearing out of know where to match the physical location before it veer away from the road and becomes its own right of-way? Or logically, how should a cycling router handle the hand off between bike lane and separated path? Do you need to join pedestrian traffic, use multiple cross walks, split the lane and use an advances stop line with bike box, cross traffic? What if your bike lane is on the right and the right turn lane cross so that the bike lane is now split between the right turn and forward progressing traffic? And that's just the issues with Urban and Suburban mapping.
Cycling is also in a bit of a technological renaissance where the space of things claiming and wanting to participate in cycling especially in soft surface areas is suddenly crowded of course you have eBikes which in the U.S. has its Class system of I, II, III but what about bikes that are outside those classes? Are electric unicycles (EUCs) eBikes? How about more powerful bikes like Surrons that would be more apply described as e-Dirt Bikes? Okay then let's put limits on power output? But at higher power EUCs don't peel out and damage trails (backed by U.S. Trail Service studies) but Surrons definitely do and how about Adaptive eBike that might need that extra power legitimately or larger eCargo Bikes used in delivery application? The point I'm getting out here is even defining what is and is not a cycle is difficult, heck I'm using the work cycle because bicycle is too specific to over unicycles like EUCs or trikes/quads used for trekking, cargo, and adaptive.
Types of Cycling
A good place to perhaps start is to understand the various forms that cycling takes. Here is a start, and this list is apt to grow as this page progresses in development.
.jpg) |
Road Biking
Think tradition asphalt, curved handle bars, Lycra, fully human powered, and fast. From a mapping perspective this requires a lot of similar things to road mapping like speed limits, but there is a particular interest in if roads have shoulders or if it's an established mountain road that people train then there can be little difference. |
 |
Mountain Biking (MTB)
Think soft surface trails with berms, jumps, and technical features or just really steep downhills. These typically will have IMBA ratings as the key metric but because many of these navigate natural terrain they will commonly have bridges, tunnels, street crossings, and so forth that many times mean they need routes similar to highways to keep the IMBA and naming consistent. You may even ideally have Route Masters to cover all the trails that are part of a park or trail system to keep them associated with the Park or Land Manager. Something MTBers probably would love to see more tracking of on OSM would be the ability to list of technical trail features (TTFs) Rock Gardens, Ladder Bridges, Wall Rides, Drops, Jumps, Skinnies, the list goes on that a particular trail contains. |
 |
Cross Country (XC)
Pretty much a sub-genre of Mountain Bikes, but they are purpose built for racing generally but not always with less travel, more efficient pedaling, and lighter weight. |
 |
Cyclo-cross (CX)
Light skinny but 'nobby' wheels great for uphills, but the typical lack of suspension make it a little worse for downhills with even small drops. These races tend to shorter and faster, so there are tradeoffs to focus on speed but slighter risk of flat. Ironically, CX might actually include bike dismount required stair sections which seems to not have anything to do with biking, but these types of scrambles are build into CX courses. |
.jpg) |
Urban/Suburban Active Transit
This where you switch from not caring if you are sharing the road with cars (road biking) to that being the least ideal option, and you want to know the route with the most separated multi-use, bike lane, and low speed mixed use routes you can find. Ideally, the types you'd feel safe for your 7-8 year old riding along. As covered above, a lot of what is cover on the bicycle page. |
.jpg) |
BMX
These either will be areas with lots of ride-able features something like skate park or these can be purpose built closed course with high jumps huge wall climbs. These would be OSM Track, but they would care about and have some cross over with the Technical Trail Features (TTFs) as MTBers, but theirs would have some features dropped and different ones added. |
.jpg) |
Pump Track
This is distinct in that you start with a short burst of peddling and then pump the bike to maintain speed with really tight turns, many of these are built to even be ridden slalom for competitive side by side racing. No Features here. Some of these will look more like a small closed loop trails, but some are better off as just areas. |
 |
Gravel
This is one of the fastest growing but hardest to map types of cycling on OSM because it focuses on back country gravel/dirt roads that most people consider to be for driving and moving around farm equipment only. If anything, this is the one that I've had the most people on OSM come back behind and revert of overwrite changes made because mostly when I've asked because the through was if it's not exclusively marked or signed in some ways then it should be left alone and people can just figure it out. Luckily our area has actually grown such a community and faced this type of push back in real like that, they've actually start signing common routes in mass. That combine MUTCD Recreational and Caution symbology with Farming, Bike, and even hiking symbology as in addition to vehicle we have a lot of these in our area. See [Respect Rural Road](https://www.arkansasr3.com/safety/). These routes focus and prioritize gravel and then a bit of dirt over anything paved, but then care about highway shoulders when rural routes don't precisely align. They also look for bike=yes and grade. |
.JPG) |
Bike Packing
This is like long distance Gravel with more emphasis on resupplying, camping/lodging, and for ebikes perhaps charging. Think of may rails-to-trails project that could take multiple days to complete. Like the Katy Trail from Kansas City, MO to St.Louis, MO pretty much an entire U.S. State's width. |
 |
Adaptive Cycling
This actually can span aspects of all of the above with their adaptive road, MTB, Gravel, even BMX cycling the only real difference is that some sort of adaptation has been made to off set some form of physical disability. |
Urban/Suburban Active Transit
Dedicated Paths
These go by a variety of names 'bike highways', 'mixed-use', 'shared-use', 'greenways', and the list goes on. These are paved paths, or occsionally fine gravel, for cycling and similar or slower active transportation use unless designated otherwide that are typically 10' or more in width being sufficient for two cyclists or similarly sizes active transit to pass in opposing directions side-by-side. A noted exception to this is if a path is split into distinct one way directions and more explicitly indicated for cycling as to not overlap with sidewalk. Regardless of what you locally call them in OSM tags them as highway=cycleway
Presumed statuses, alternative tags, and best practices
The debate over which tag to use when has been going on for a couple decades and counting, this section will not give a definative answer but will used the 'assumed state' of alternate tagging to help inform on where NOT to use highway=cycleway explicitely.
- highway=cycleway
- bicycle=designated
- foot=designated
- motor_vehicle=no
- Not Specified... horse
- highway=path - Generally used when unpaved paths hence why horses are presumed.
- bicycle=yes
- foot=yes
- motor_vehicle=no
- horse=yes
- highway=footway - Generally used for paved pathes less than 10' in width or in location with regular dense predominate foot traffic, with footway=sidewalk being the most common.
- foot=designated
- motor_vehicle=no
- Not Specified... horse & bicycle
- highway=pedestrian - Pedestrian Steet, typically streets that have been closed off to cars.
- foot=yes
- motor_vehicle=no
- Not Specified... horse & bicycle
The most common modifications for biking with respect to the alternatives highway=path/footway/pedestrian are bicycle=yes/no/dismount. Before adding an explicite bicycle=* or reviewing them added by others remember "as far as is reasonably possible, be verifiable", "don't map local legislation if not bound to specific objects", and "don't map for the router".
Common tagging practice for dedicated paths
Here are a few common tags and how they are helpful:
- surface=* - asphalt, concrete, fine_gravel, but trying and avoid the generic 'paved' if you can.
- segregated=* - are cyclist and predestrian separated by something like paint or a mountable curb (kerb)
- lit=yes - it's assumed without this tag that it's not lit, this is especially important for dedicated paths where there isn't some carry over street lighting.
- smoothness=* - useful mainly for non-cycling use cases like skating, accessibility, but also to warn if a path is really warn down or in need of repair
- dog=leashed - if signed and verifiable
- width=* - in meters!!! Here is a useful chart for reference
| Feet | Meters |
|---|---|
| 8' | 2.4 |
| 10' | 3 |
| 12' | 3.6 |
| 14' | 4.2 |
Cycling Sidepaths
.jpg)
Within the context of roads there is the street (roadway) which is the paved or surfaces section of a road between two curbs (kerbs), painted lane markings, or just where the paving stops. However, for purposes of this conversation a street (roadway) is one part of a larger area known as a 'right-of-way' which includes all the sidewalks, sidepaths, buffer zones, medians, parking, and bus stops. I call this out because there oftern are times where sidepaths will divert from or come along side a road and the question about the status and treatment of the cycleway can change to account for this.
The somewhat blurry line between seperately tagged sidepaths and bike lanes
The simplist rule of thumb is that sidepaths should be mapped separately from the road they share a right-of-way with when there is either a) grade separation like a curb (kerb) or drain gutter b) a signifiant buffer this would be a vegitative buffer zone of 6' or more with trees or guard rails. If a sidepath shares the same grade as the road then it will typically fall into the following section.
Additional handling for sidepaths
This is where concensus is still not technically reach, but the level of adoption by some areas rise enough to the level of 'de facto' that I'm compfortable posting this here (100k+ uses at time of writing). Cycling digital wayfinding/routing/navigation are benfited when the software can tell what roadway a sidepath is associated with. At present Proposal:Key:is_sidepath has seen wide adoption in Europe to the tune of tens of thousand and breaking 100k depending on how you count it, this is in an unofficial 'de facto' for now. The tags you need to know are:
- is_sidepath=yes - this just gets added for any portion of a highway=cycleway that share a right-of-way of a road for a significant amount of time
- is_sidepath:of=primary/secondary/tertiary/residential/unclassified/service - basically whatever type of highway=* the sidepath is parallel to.
- is_sidepath:of:name=* - the name of the road the sidepath is parallel to.
Is the side path mandatory?
Remembering that this should be base on verifiable detail like signing and not based on policy alone. There are places where cyclist 'must use' a sidepath. This, typically, should pair two things. First, where the sidepaths use become required, there should be a highway=cycleway + cycleway=link. (This tag functions a bit like highway on/off ramps but for cycling and may have some future benefit/use for transitions such as these.) Second, the road portion of the prohibited area should have a bicycle=use_sidepath tag added to it for the length of the restriction. (Important note: Do not add the bicycle=use_sidepath unless there is an explicit requirement to use the sidepath there is a cycleway=separate that can be used if you want to indicate a road has a sidepath that can optionally be used.
Bike Lanes
The main distinguishing factor between sidepaths and bike lanes is that in most of the US once you share the same grade as roads and are separated from pedestrians, which still typically used sidewalks, then for the purposes of road crossings bikes are with limited exception (like "Idaho Stop" where applicable) expected to exercise the same rights and responsibilities as the driver of a motor vehicle would and function more or less like a lane of traffic on the road.
However, as traffic lanes where well established within OSM for a great amount of time prior bike lanes where initially not added to streets in the same way a bus or turn lane would be. Instead cycleway=track became the predominant convention used and recognized by rendering and routing across OSM. This conventions works for most but not all use cases and thus there is some credence to using the lanes=* + *:lanes=* convention for roads where bike lanes are crossed by traffic lanes. Both conventions will be covered in this section.
Using cycleway=lane and/or cycleway=track convention
I don't want to redo here fantastic work that has been done elsewhere, so I will way for this section in particular use Bicycle#Cycle features as a good visual guide for with practical examples.
Are cycleway=lane and cycleway=track different?
Yes, and also a bit no. (It's complicated.) The reality is that because OSM tags for consistency "using British English if possible," and British and Europeans more so than Americans don't think of an Olympic racing track for bikes like we in the Americas tend to, they typically just think of a separated bike lane. While in America, we don't think of bike lanes as 'tracks' at all. So the same things started being tagged two different ways because of language and meaning difference between two nations that speak the same language only separated by an ocean we both for some reason have decided to call 'the pond' in this situation.
However, most European cycle 'tracks' are by default separated by curb or barrier, while the majority of U.S. bike 'lanes' are by default just paint. Thus, over times a cycleway=track has come to mean a cycle lane with a curb (kerb) or physical barrier between it and road traffic while cycleway=lane has come to mean a lane only delineated by paint at least within the OSM definitions of each and to some degree bike routing sometimes prefers cycleway=track over cycleway=lane for this implied reasoning. I thus would recommend that this distinction is followed where possible.
But does your cycleway=lane have a buffer?
Now that the extinguishment between 'track' and 'lane' are clearer. If a cycleway=lane has a painted buffer zone giving a couple feet between cyclist and traffic, then add the tag cycleway:buffer=yes. A buffer doen't physically prefent vehicles from encroaching into a bike lane but it does give a little room so truck mirror aren't going right by your head. This is sometimes rendered or preferred slightly in routing. This however is outside the stress margine for the majority of cyclists still.
(Note: The *:right=* and *:left=* namespaces may need to be added if the buffer isn't present for all cycleway=lanes.)
But does your cycleway=lane or cycleway=track have a physical separation?
For cycleway=track this is assumed to be yes, but doesn't go as far as specifying they type and since Americans then to use cycleway=lane for everything regardless of physical separation the cycleway:separation=* tag can be added to either to indicate a physical separation exists between the bike lane and traffic. Possible values are cycleway:separation=bollard/flex_post/vertical_panel/bump/planter/kerb/greenery/etc..
(Note: The *:right=* and *:left=* namespaces may need to be added if the separation isn't present for all cycleway=tracks or cycleway=lanes.)
Best practices
Broadly speaking, the following should be applied:
- Make sure the directionality of all ways are consistent, if a way changes directionality a *:right=* all the way along could appear like a bike lane just flips sides of the road.
- Think about the directionality of each side of a bike lane, for bi-directionality on any side the *:oneway=no will need to be added as bike lanes are assumed to be directional in each direction matching the normal direction of traffic for the country/region on each side.
- Consider if physical separation of some kind is present, if there is tag it! Physical separation is a huge factor in cyclist stress and thus ride-ability considerations for routing all but the road cyclist.
Recognizing the present limitations of cycleway=lane and cycleway=track
Because of how cycleway=* really three states: no added namespace, *:right=* namespace, and *:left=* namespace this tagging convention isn't truly capable of handling newer and more modern scenarios like middle of the road bike lanes (see Valencia Bikeway in San Francisco) or numerous places in Florida where right turn lanes and even on and off ramps for roads cross over bike lanes. This might seem odd but having right turning traffic cross a cycle lane in advance of an intersection is far safer than having the cyclist on the right-hand side of right turning traffic that commonly forget to check for bike/ped/disability traffic before turning. If a roadway sees the scenario commonly then move to the next section which covers 'bike lanes as lanes'.
Bike Lanes as 'Lanes' convention
More modern bike lane designs run against the original tagging design the tagged on bike lanes to the edges of roads as sort of an after thought. More and more as bike lanes are becoming part of 'Complete Street' road designs the bike lane is being treated like... well a lane, what else!?
OSM Wiki doesn't seem sure if Bicycle Lanes count as lanes
The foundation for this matter as unsettled comes from the lanes=*} page that at the time of writing leads starts out with three statements that indicate and exclusion for bicycles namely:
- Use the lanes=* key to tag how many traffic lanes there are on a highway
- Count excludes cycle lanes and motorcycle lanes that do not permit a motor vehicle.
- In the 'The following lanes should be included:' section - General purpose traffic lanes suitable for vehicles wider than a motorbike.
But then you move to the 'The following lanes should be excluded:' section and it switches tone saying the following:
- Bicycle Lanes. Use the tag cycleway=lane for those. NOTE: Not settled; orthogonal with other vehicle lanes would be that all vehicle lanes including bicycle lanes count, and per-lane tagging (e.g., access:lanes=|no bicycle:lanes=|designated) applies for all on-street lanes.
A defense that OSM Bike Lanes need to be counted and numbered given examples that will not work without this being true
Unlike prior matters of some disagreement over 'which way is best' I'm prepared to argue and provide clear examples of why OSM lanes need to be inclusive of bicycle lanes. Why? The reasons are two fold. First, the cycleway=lane as discussed above is limited and cannot meet the needs in all use cases requiring something more robust and matured. Second, many of the things bike lanes need to leverage to meet their most unique use cases are already provided via relationships like Relation:connectivity that by their nature number lanes left to right in order to explain how they connect to one another. Lastly, examples provided on how to tag bicycle lanes commonly have vehicle:lanes=|no on bike lanes but if we look at the definition of vehicle=* as 'Legal access restriction for all types of land-based vehicles not operated upon rails.' and look down this included motor_vehicle=*, motorcycle=*, bicycle=*, & carriage=* which means bikes as a subset of vehicles are not allowed. This also causes issues when 'motor vehicle' traffic lanes cross bicycle lanes but are also not seen as allowed even for a time to cross the bicycle lane as a lane. Likewise a 'bicycle lane' that crosses an intersection via diagonal crossing or split cycling traffic into two directional flows of traffic also break if lane transitioning isn't permitted because 'bicycle lanes' are excluded from the umbrella of lanes. These issues will cause just as much if not more issues as holding on to past assumptions about how lane number counts can be treated absent additional details, but these are the additional details that OSM needs to be able to adapt to.
Example #1 - diagonal crossing lane
| Way/Relation | Tags | Tags (table for visibility) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Way #1 (Closest) |
lanes=4 motor_vehicle:lanes:forward=no|yes|no|no motor_vehicle:lanes:backward=yes|no|no|no bicycle:lanes:forward=no|yes|no|designated bicycle:lanes:backward=yes|no|designated|no |
| |||||||||||||||||||||||||
| Way #2 (Furthest) |
lanes=4 motor_vehicle:lanes:forward=no|no|yes|no motor_vehicle:lanes:backward=no|yes|no|no bicycle:lanes:forward=no|no|yes|designated bicycle:lanes:backward=designated|yes|no|no |
| |||||||||||||||||||||||||
| Relation (via intersection node) |
type=connectivity connectivity=1:2|2:3|3:(1),2|4:4 |
Notes: Lanes are number left to right from #1 and this indicates the alignment of lanes from Way #1 to Way # 2 via the intersection node. |
Important Note: Without all lanes inclusive of bike lanes being identified as lanes the above schema.
Expanding on this example Because there is a "bike box" (advance stop line) on the far side where the cycle lane comes over before crossing that cycleway=asl node could also have the following:
type=connectivity connectivity=1:2|2:2|3:3|4:4
Basically just saying that the far bike lane need to merge into the "bike box" of lane 2 from lane 1.
Example #2 - intersection approach with vehicle cross over of bike lane
| Way/Relation | Tags | Tags (table for visibility) | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Way #1 (Closest) |
lanes=3 motor_vehicle:lanes=yes|yes|no bicycle:lanes=yes|yes|designated cycleway:lane=no|no|exclusive |
| |||||||||||||||||||||||||||||||||||
| Way #2 (Next Furthest) |
lanes=6 motor_vehicle:lanes=yes|yes|yes|yes|yes|yes bicycle:lanes=no|no|yes|yes|designated|no cycleway:lane=no|no|no|no|advisory|no turn:lanes=left|left|through|through|through|right |
| |||||||||||||||||||||||||||||||||||
| Way #3 (Furthest) |
lanes=6 motor_vehicle:lanes=yes|yes|yes|yes|yes|yes bicycle:lanes=no|no|yes|yes|designated|no cycleway:lane=no|no|no|no|advisory|no |
| |||||||||||||||||||||||||||||||||||
| Relation (via Way #1-to-Way #2 node) |
type=connectivity connectivity=1:1,2,3|2:4,6|3:5 |
Notes: The through motor vehicles lanes can technically be navigated by bicycle, but turning lanes are on ramps to highways where cycling it typically prohibited. The first lane can continue or join one of two left turn lanes, the second can continue or cross the bike lane to use the right turn lane, and the bicycle lane in through only but jumps position from third (furthest right) to 5th second furthest right. |
Possible future clarity
This is a lot more complete that anything cycleway=lane or cycleway=track could have done but expectially in this second example it's not clear that the bicycle lane is not a motor vehicle lane but is a bicycle lane that motor vehicles can cross and need to do so much earlier prior to the bicycle lane become exclusive again.
The "Sharrow"
The first and most common "Shared Lane" in the US is what many cycling communities refer to as a "Sharrow" short for 'Share the Road Arrow' or something along that lines. It's many times a low effort and low cast way for cities to claim to have provided bike infrastructure. These, however, can be used effectively to indicate a primary route through neighborhood streets where the speeds are already low, and the roads are already narrow. These are represented by a bicycle pictogram with an arrow and are supposed to be places where cyclist are advised to ride within the lane. However, I'd advise common sense over "sharrow" placement as in the example above you'd be at clear risk of being "doored" (running into some's car door that opens right in front of you.
In OSM there are two techniques that capture this type of shared lane marking which are typically combined as one covers concept and one covers physical marking type and these are largely handled based on bi-directionality cycleway=shared_lane + cycleway:both:lane=pictogram or only being marked in one direction based on the direction of the roadway's way in OSM either cycleway:right=shared_lane + cycleway:right:lane=pictogram or cycleway:left=shared_lane + cycleway:left:lane=pictogram.
(Note: Do not confuse cycleway:lane, which marks cycle lane markings, for cycleway:lanes, which marks which lanes of a roadway are 'bike lanes'. The one letter difference between these can make things confusing, even if they shouldn't overlap.)
The second type of 'shared lane' is less common in the U.S. but it's a two lane road with dashed line narrow lanes on either side and a single full width lane in the middle. See the photo for an example being dashed in the US a car can drive over and through these, meaning technically the whole road is usable, but the intent is to drive where you need to avoid traffic in either direction while staying to the right if you can. As these are lanes but not exclusive to bikes, the typical tagging is cycleway=shared_lane possibly with directions but instead use cycleway:both:lane=advisory
Road Crossings
This is a topic that does not have one singular explicit right way of doing things but is more of a progression which is typically a balance between getting 'just enough' detail for low priority crossings like curb/kerb cut business entrance/exists and progressively greater and greater details as dedicated and shared use cycling infrastructure crosses roads become more complex. This section will progress the level of detail from simple to complex, and leave it to the mapper to gauge what level of detail maximizes efficiency. (This is similar in concept to the Pedestrian Working Groups 'Tiered' Schema for pedestrian mapping.)
Node based side-road crossings
These are oriented for mainly for dedicated sidepaths with lots of business entrances/exits. Namely, places where more time can be spent mapping other places and then if time permits these are things that can be returned to later.
The bare minimum for node based crossing mapping is highway=cycleway + cycleway=crossing. Ideally, it would be best to throw in a crossing=unmarked or crossing=marked tag as this is a built-in selection type for both iD editor and JSOM as the biggest to editing tools for OSM.
Node Enrichments
- kerb=* - Especially if the curb is not flush with the road's surface grade, this should be rare on cycling routes, but still possible.
- tactile_paving=* - If there are tactile plates for Blind and Low Vision Users. This is not a cycling item but helps support the rest of the bike, pedestrian, and disability space especially for mixed use.
- crossing:markings=* - If the crossing is marked, go ahead and say how.
Node based intersection and mid-block road crossings
This should ideally be limited to tertiary, residential, and service roads or equivalent, typically when narrow and limited to two lanes roads that are narrow and close together.
For this you will start with the same based node as the side road but potentially expand this with a few more enrichment tags:
- crossing:signals=* - if the crossing is signalized, this is most typical for this application as a HAWK mid-block crossing and is preferred over the US centric crossing_ref=hawk.
- flashing_lights=*=no/button/sensor/always - This would align to the US Rectangular Rapid Flashing Beacons (RRFB) or older always on yellow cautions at pedestrian corssings.
- surface=* - what is the road surfacing used for the crossing?
- crossing:island=yes - (see section on traffic islands section below)
Intersection as Collectors or Arterials
This is where we tend, to what degree is reasonable, start to breaking away from mapping based on 
node and move to mapping based on 
way for crossings. This though itself has tiers of detail.
Base Level using way for crossing highway=cycleway - because we are cycleway focused here. Legal alignment note: the 'cycleway=crossing' tag should only be used if your state gives a cyclist the same right of way as a pedestrian or provides the cycle lane its own independent traffic light. If neither apply, then use 'footway=crossing' with 'bicycle=yes' instead. cycleway=crossing - Assuming the above qualifies. crossing=*=traffic_signals/marked/unmarked - Once we are to this level, this will almost always be 'traffic_signal'; rarely will be 'marked'; and will almost never be 'unmarked'.
From here all the previous tagging from the nodes also come into effect in the same progression as before.
Stress
Stress is a huge factor on if people will use and ride on bike-ped infrastructure when a right-of-way is shared with vehicles. There are a number of factors that can effect 'stress that this section aims to address.
Traffic Islands, & Crossings
When evaluating cycling infrastructure a key factor in use especially around vehicle traffic is 'stress' and road crossings are one of the highest points of 'stress' and that increases the longer (wider) a crossing is because that is more time exposed to traffic. Traffic islands can mitigate this stress some by breaking up crossings into smaller manageable chunks. However, a narrow traffic island between two major high speed roads can ironically be just as stressful as a crossing if you have vehicle with mirrors flying by you at high speeds mere inches from your head and this width minimum increase with cyclists because, well you have to fit you and your bike in that space. This is why mapping crossings and traffic islands as ways provides a lot more useful information over just nodes and thus why over a certain threshold this is preferred.
What is a traffic island?
This is one of those ones where most people just respond, "I'll know a traffic island when I see a traffic island," then they start mapping and run into something like this. If you look at the intersection provided which of the crossings get marked as having a traffic island? The ones with a traffic island on: One side? Both side? Only the intersection crossings? Only the slip lane? You probably have an idea what you think it should be but the next persons thoughts might vary. Even if you mark the island as a node you don't necessarily gain information on if the crossing is split or if the traffic island is long enough to fit a cyclist and be low stress. There as also those that try and define based on length with arbitrary large islands being switched back to sidewalk/footway/cycleway which isn't very helpful either.
The solution let's define what a traffic island is and then we know and anything else is something else:
A Traffic island is a section between two crossings of a common intersections or mid-block crossings that provides a cyclist, pedestrians, and disabled user refuge from traffic. These are either grade separation or have physical separation at grade on both sides of traffic island.
From this we know the following are not traffic islands:
- Crossings
- A Median along a crosswalk on one side, for instance a neighborhood entrance. Vehicles can cut the corner so there is a lake of refuge.
- Areas between two intersections. For instance a diverging diamond interchange consists of two intersections the are between them and on either side of the intersections are not traffic islands.
A cycleway that crosses a through a traffic island thus for the distance covered by a traffic islands protections should be marked as a way of type cycleway=traffic_island. If you feel the need to mark something on the crossings that are adjacent or between traffic islands then crossing:island=separate is an option. However, by marking a crossings where possible as ways the the length of these can be used to factor in relative stress associated with specific crossings in a very objective way. Nodes do not provide this and run into the 'does this crossing have a traffic island?' ambiguity far too often.
Low stress crossings?
There are ways to mark stress reduction for specific crossings. Here are a couple of ways this can be done:
- crossing:continuous=yes - this indicated that the cycle-pedestrian path remains at a common grade and vehicles are the ones that have to go over the off-grade crossing forcing them to slow down and alerting them to look for those crossing more.
- traffic_calming=table when a crossing is combined with a traffic table this works in a similar manner to the above tag and if the grades are even enough it's possible to have both together.
A common opportunity for mapping cycling is the grey area that bikes have between being treated as road users or treated as non-road pedestrian-like users. This causes a decent amount of 'bouncing' between roadways and multi-use or dedicated cycling sidepaths. At times there is a clearly intended transition and other times paths just abruptly end. The opportunity that this raises is that the centerline of a dedicated highway=cycleway and a 'bike lane' or shared lane' highway=* + cycleway=lane/cycleway=track/cycleway=shared_lane are over half a roadway or intersection removed from one another. To connect these with a highway=cycleway coming off of a road 'works' but the weird and non-natural 90° angle for roadside transitions or 45° angle for intersection transitions doesn'y accurately reflect the physical reality and yet some sort of logical 'link' is necessary for routing reasons.
Enter highway=cycleway + cycleway=link which is a good 'gap' filler for mapping routable transitions between two nearby but offset cycling infrastructure ways aligned to physical center-lines in the real world. (Bonus: This tagging also is useful for linking 'desire paths' for where ideal exits or entrances are prior to when cycling infrastructure suddenly ends or hits a noexit=yes like at driveways, sidewalks, or access aisles.)
The OSM cycling transition gap
The above is a good starting point, but in a number of situations the connection of two cycling infrastructures even using the highway=cycleway + cycleway=link tagging can be worked out by routing applications that if you are heading a specific direction that starting at a specific intersection there is a separate bike path that is preferable. However, there are commonly situations where the routing tells an incomplete story. For instance an east-west sidepath ends on one corner side of an intersection on the other side of the intersection the infrastructure changes to be bike lanes but one lane per side moving in the same direction as traffic. In one direction you could probably just cross the intersection and keep going on the new cycleway=lane or cycleway=track, but the other direction the cyclist might need to join with the pedestrian traffic cross north-south then again east-west to get to the opposite corner cross from the ending bike lane back and over to the sidepath.
The following is a discussion/thoughts about how to address the gap explained above, no proposal or formal action has been taken.
At present there is not a solution for this but there has been an option discussed that would borrow from relationships in sort of an inverse-restriction it would keep the to way, from way, and via node layout, but instead of saying what you can't do this would communicated to cyclists (and potentially pedestrians) how to navigate the transitions. Maybe something like a relationship of type=bikeped_link with a transition=* that likes steps to navigate the infrastructure transition. A few basic examples of this would be:
- A bike lane becomes a multi-use sidepath at an intersection crossing:
- In one direction: transition=slight_left;merge_multiuse_path
- In the other direction: transition=slight_left;merge_bike_lane
- If a bike lane ended at an intersection but the road it runs along become a cycleway=shared_lane this could look like:
- In one direction: transition=slight_right;signal_exit_intent;merge_bike_lane
- In the other direction:: transition=merge_side_vehicle_lane;left_turn
Road Cycling
In a large part road cycling doesn't have a lot of tagging specific to them. The most common tagging used involves space for cycling within roadways namely bikeable shoulder.
Tagging
- shoulder=yes/left/right/both - list that shoulders exist and specify which side(s).
In addition, good portions of National Bike Routes commonly contain good portions of road routes.
Gravel Cycling
Rising in popularity and becoming a more distinct from other types of cycling. The focus is riding on unpaved roads ideally gravel, but also dirt or ground. Typically, this would be country, farm, or rural roads, but also gravel routes like many U.S. Rails-to-Trails projects.
Tagging
The obvious important tagging for gravel is surface=* namely:
The next key tagging tends to involve ridability:
- tracktype=* - preferred method for rating gravel as it's a road based rating and let subjective
- tracktype=grade2 - Indicates unpaved good rideability - road
- tracktype=grade3 - Indicates unpaved good ridabbility - dual track
- tracktype=grade4 - Indicates unpaved but soft surface can quickly turn poor with moisture - dual track
- tracktype=grade5 - Indicates unpaved and unimporved soft surface tracks that have sand, grass, and other traction interfereing elements.
- smoothness=* - most subjective but still useful
- smoothness=intermediate - this is kind of the "sweet spot" for gravel it's unpaved but still a nice smooth well maintained road.
- smoothness=bad - This is for roads that have some maintenance needs potholes, ruts, some muddy sections, that sort of stuff
- smoothness=very_bad - When the road has some really "chonky" stuff and where you start into some occasional ground clearance issues at spot, more than this you start getting into off-road territory.
What about paved connectors between gravel sections
- Still include a form of grade or smoothness
- tracktype=grade1 - Paved, add to roads that connect between gravel routes
- smoothness=good or smoothness=excellent - paved roads based on maintenance
- Also for road crossings highways can make for good crossings if they have wide enough ridable shoulders, see Road Bike tagging above.
Gravel Features worth tagging
Water ways
Especially in the non-competative gravel scene many sought out routes run along brooks, creeks, rivers, and lakes. If a gravel route has any of these be sure to mark them.
The cons of waterways… the more you stick to rural routes that parallel water the more likely you are to run into crossings many of these end up being bridges but occasionally you'll end up needing to cross water and knowning what water crossings there are along a route is good both from a resting stop stand point but also from a passible stand point as recent rain can make some routes impassible. Here are some water crossing tags that are helpful:
- For typically dry water beds that may only matter if there has been decent recent rain:
- For water crossings that are typically water covered consider the follow
- If there are areas that are not water beds but capture water enough to regularly flood, if you see a depth guage side along the road it's probably a good indicator.
- flood_prone=* - this will apply to the ways that are typically with the flood prone area.
A quick conversation about gravel routes and the 'OSM verifiablility' question
Gravel tagging of bicycle=yes on common and safe rural/gravel routes is one of the most commonly rolled back changes in the OSM cycling tagging. The most common reasoning however is that bikes don't belong on rural roads. This goes to the question of OSM verifiability and starts with pretty much every state in the U.S. having some variation of cyclists having the same 'rights' and either 'responsibilities' or 'duties' as the driver of a vehicle. Which means by default pretty much every road is typically bikeable with the exceptions typically being closed access highways not rural roads. Thus is it verifiable that bicycle=yes is the law of the land and not being bikeable is more the exception than the rule so marking the ideal and safest rural bike routes as bicycle=yes is just an effort to make safe roads easier to find and is a matter of safety.
The main valid exception I've seen is when a road through someones property is no open to the public on OSM this is rarely tagged wrong but if it occurs then it's easy to correct and update.
In NW Arkansas, SW Missouri, and NE Oklahoma a sign has been designed to communicate that rural roads are used for work and recreation as farmers in the area found to have the same issues that cyclist and even hikers with impatient drivers not understanding that the rural roads aren't speedways. So now there are verifiable signs posted along most mapped and used rural routes just to reenforce the ridability and use aspects. The only other place in the US that has something similar is Texas with their recreational roads designation which are more centered around access to state parks but many also double as gravel routes.
Mapping Access for Bikes and Multiuse Devices
bicycle=*
Values:
- designated - ways designed for bicycles (e.g. Bike Lanes, Multi-use paths)
- yes - explicit call out that biking is permitted typically added not to all roads but to roads or paths that are commonly used typically designated but "sharrow" or community designated bike routes on low speed roads.
- no - where biking is explicitly prohibited
- dismount - (cycling only) where signed, not legislated, that dismounting is required
- use_sidepath - (bike-ped only) for roads only where use of sidepath is signed as compulsory
- permissive - premitted but revokeable access
Electric Bikes (eBikes) and U.S. Classes
In the U.S. access has become commonly determined by eBike Class which are Federally defined as follows but implemented at State, Municiple, and Facility basis:
- Class I - max 750 watt with assisted speed capped at 20 mph pedal assist only. Use electric_bicycle=* for access tagging
- Class II - max 750 watt with assisted speed capped at 20 mph pedal or triggered assistance. (Discussion about how to tag this is ongoing but electric_mofa=* has been floated as a possible equivelant, noting that mofa=* includes both motor and electric but is a sub-category of moped=*. There might need to be a US derivation of this tag thought as mofa's German root is not understood directly in English.)
- Class III - max 750 watt with assisted speed capped at 28mph (45km/h) pedal or triggered assistance. By Federal regulation must use roads. Use speed_pedelec=* for access tagging.
- Unclassed - more and more states are realizing that there is a gap between eBike classifications and things like motorcycle or moped this are defined by cubic centimeters (or 'cc') but not by equivalent in watts which leave things like electric dirt bikes (like name brand Sur-ron) in a place of legal a legal grey area. (PeopleForBikes the main policy and advocacy organization in the U.S. has drafted language that has started to be adopted and we likely need matching OSM tagging for this.)
The above classes are defined in US Code - Title 23 Chapter 2 Section 217(j)(2)(A-B)
'Uncanny Valley' of Cycles
In looking across a majority of U.S. State laws a Bicycle is generally defined as two or more, not to exceed four tandem wheels that are human powered, and the electric bicycle laws extend off of these definitions. What this does not predict is the rise in prevalence of Unicycles mainly Electric Unicycles or EUCs. These exist under the 'cycling' umbrella but legislatively tend to work very differently or fall in an 'unregulated' grey space while legislation catches up with technology.
There is a European centric tag small_electric_vehicle=* that encompasses eScooters & self-balancing electric vehicles at least according to this tags text. Based on research though eBikes, eScooter, eSkateboards (or eBoards), and Hoverboards are all distinctly regulated by country so there appears to be room for some distinction.
In summary, EUCs are cycles that are growing as an industry and more and more places are finding needs to regulate but OSM tagging like with the laws haven't entirely caught up yet.
Other Active Transit vehicles that overlap cycling
Neghborhood Electric Vehicles (NEVs) - These are commonly directed to use bike paths in places like California and should use nev=* for access. (See MUTCD/California/R#NEV-R:_Neighborhood_Electric_Vehicle)
eBikes, eMotorcycles, electric unicycles (EUCs), and future tech
More coming soon-ish™
Taking a Break
Even more to come as I slowly add in different types mapping for different types of biking as well as tools, routes, and edge cases.