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
