On Sep 22, 2020, at 8:38 PM, Elliott Plack <elliott.pl...@gmail.com> wrote: > Excellent! I see no problem keeping state=proposed with the lifecycle.
With both of us in agreement about tag "proposed:route=bicycle" (especially as it co-exists with "state=proposed") can we gain some more consensus (here, soon?) allowing us to move closer towards recommending in our wiki that we tag proposed USBRs with "proposed:route=bicycle"? I'd love to see wider agreement that these tags together are a good way to move forward, as "state" continues the legacy rendering support by OCM and cyclosm and "proposed:route" is harmonious with tagging schemes that are more modern as they grow into sensible namespaces like Lifecycle. > Another tag in that realm that I like to use is the `start_date` or in this > case the `opening_date`. The latter is for some future date, if known, when > the route would change to regular active status. Then you can add the > start_date. I find those useful when another mapper might not see something, > either on imagery or out in the world. If they see a recent start date, it > might help explain the discrepancy. I do put start_date and end_date on objects in OSM (I just did on a fire=perimeter that covers a huge portion of my county and which burned for over five weeks). But for proposed USBRs, predicting what to use as "start_date" requires predicting when AASHTO will complete the voting on its ballot for state's USBR applications during that AASHTO "round" (twice a year), and we simply can't do that. It's easier to wait until "after the fact" (OSM receives news that the AASHTO ballot has completed and published results) and then simply remove the "state=proposed" tag: that's how we've been doing it, it's well-understood, it's quite simple / straightforward and it "works" (causing OCM to render solid route lines from initially dashed route lines), but more importantly, as accurate route data in OSM as a database. So while I agree with you it would be useful to do this, we don't have a crystal ball that allows it to predictably happen in this case. I think the "state=proposed" and "proposed:route=bicycle" tags convey enough, especially as source=* tags and/or changeset comments often denote a pending USBR being part of a particular AASHTO ballot — "AASHTO Autumn 2020 round," for example. The whole idea of these entering OSM is to have enough time to enter them (sometimes they are hundreds or even thousands of kilometers of route to enter) by the time they become approved. Sometimes we "beat the clock" and end up with some dashed lines and we wait for approval, sometimes we lag a bit and they get approved first, THEN we complete our entry of them into OSM. > Annotation geekery aside, it brings me great joy that OSM holds such a vast > repository of bicycle/pedestrian related data that are virtually unparalleled > by other commercial mapping products. Keep up the good work adding and > maintaining these networks. Very kind of you to say. There ARE other (often commercial) such "repositories" (e.g. RideWithGPS) but these tend towards the ephemeral, transitory-natured "I think this a good bike ride" GPX data, rather than "these are official or quasi-official (signed on the ground)" bicycle route data contained in OSM. Happily. the Internet has room for both. Is OSM "unparalleled" when it comes to "official" bicycle/pedestrian related data? Well, that's a great goal to shoot for, I'm delighted to receive the feedback you believe we're "getting there!" SteveA Simply "one more volunteer" doing this, there are many! _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
