On Sep 22, 2020, at 12:33 PM, Elliott Plack <elliott.pl...@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.5798/-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.2022&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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Reply via email to