[Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[Kerry Irons]

Yes, for USBR 201 we essentially followed the ECGW.  This made for some less-than-direct segments, but that was what the locals wanted.  But that does not mean that the route shown on OSM Cycle is proposed USBR 201.  Only when you see the 201 tag on the map will this be the case.


Kerry

-----Original Message-----
From: stevea <steveaOSM at softworkers.com> 
Sent: Tuesday, September 22, 2020 3:57 PM
To: Elliott Plack <elliott.plack at gmail.com>
Cc: talk-us <talk-us at openstreetmap.org>
Subject: Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

On Sep 22, 2020, at 12:33 PM, Elliott Plack <elliott.plack at gmail.com> wrote:
> Great work getting these into the map already Steve! I work on the MDOT bike team (as a GIS consultant) so it is great to see this on the map so quickly.

Thank you, Elliott; nice to see your reply!  I agree about "so quickly:"  I posted a request here and just a couple/few days later, an intrepid OSM volunteer had finished USBR 201 in Maryland before I could brew a cup of coffee!  Then, when it was suggested that the route become fully bi-directional, he quickly refined it to be so (just yesterday).  Wow!  (OSM has some great mappers!)

> A note about the *proposed* routes, they do appear in the OSM Cyclemap already [1].
> [1] = 
> https://www.openstreetmap.org/?mlat=39.5798&mlon=-76.6054#map=15/39.57
> 98/-76.6054&layers=C

I believe what is going on here is that East Coast Greenway (ECG, a "quasi-national" bicycle route not part of the USBRS, but sometimes, like here, sharing segments with it as USBR 201) is that OpenCycleMap (OCM) is in the process of redrawing the combined / shared segments of ECG + USBR 201 (in Maryland).  OCM can (and often does) take several days or even a week or two to re-render.  And, Andy Allan (OCM's author/maintainer) recently upgraded OCM to vector tiles with some newer rules for how specific tags (including and especially routes tagged state=proposed) are differently-rendered than as before (before vector tiles).  If I'm mistaken and somebody wants to correct me here, I welcome that, as I'm speculating a bit at what/how OCM is "currently rendering."  It's a bit like watching paint dry:  the colors can change a bit as it does.

> Instead of using the `state=proposed` tagging [2], you might consider putting a lifecycle prefix [3] on the network tag so as to prevent data users from integrating it blindly.
> [2] = 
> https://www.openstreetmap.org/relation/11654314#map=11/39.5964/-76.202
> 2&layers=C [3] = https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

The usage of state=proposed on bicycle routes is long (in my experience, going back to about 2010) and somewhat complex history, I've exchanged quite a bit (though not TOO frequent!) emails with Andy on this, he has been most helpful, especially with the switch to vector tiles earlier this year.  It is also quite deliberate, as state=proposed DOES render (in OCM as dashed, not solid) but does NOT render in Lonvia's waymarkedtrails bicycle renderer, providing a contrast between seeing the routes as proposed (and dashed) or not as all, as they are "not quite yet approved nor signed (yet)."  This contrast is documented in our USBRS wiki.  Additionally, a newer bicycle renderer (cyclosm) has emerged which also renders state=proposed.

I very much like the idea of Lifecycle_prefix in addition to state=proposed (I don't think it must be a choice between one and the other).  Using both tags (state and a lifecycle prefix) somewhat "standardizes" the concept of "proposed" in a wider OSM context, while continuing use of state=proposed (as it is supported in OCM), allowing the "dashing" of routes so tagged to continue in those renderers where the tag is applied and is supported.  We (OSM, ACA, a sponsor of USBRS, even AASHTO itself) have all participated in rather carefully crafting and or supporting this process and set of tags, which emerged in 2013.  I gave a talk at SOTM-US / Washington, DC about this in April, 2014 and we've been using this carefully-hammered-out consensus since.  Your suggestion to consider Lifecycle_prefix in addition is both welcome and excellent, imo.  Thank you.

If anybody wishes to contribute a suggested strategy to include Lifecycle_prefix tagging in our USBRS wiki, I welcome that and also consider doing so myself.

What a great project (OSM) we have here, SteveA _______________________________________________
Talk-us mailing list
Talk-us at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us