Tom, I’ll try to address most of your points below
Zack LaVergne | Kaart <https://kaartgroup.com/> | Software Developer | 501.690.0584 | z...@kaartgroup.com <mailto:z...@kaartgroup.com> KAART CONFIDENTIAL This message (including attachments if any) is for the private use of the addressee only and may contain confidential or privileged information. If you have received this message by mistake please notify the sender by return e-mail and delete this message and any attachments from your system. Any unauthorized use or dissemination of this message, and any attachments in whole or in part is strictly prohibited. > On Sep 20, 2018, at 5:29 AM, Tom Pfeifer <t.pfei...@computer.org> wrote: > > On 20.09.2018 07:28, Warin wrote: >> On 20/09/18 09:26, Tom Pfeifer wrote: >>> >>> First, how much of a delay is added by the routing engines, have you >>> investigated this? If so, this would be a few seconds once-per trip, not >>> every 500m like a traffic light. Thus the difference on the calculated >>> overall travel time would be insignificant. >> An old toll both was where I'd have to stop, dig out some money, hand it >> over, wait for any change, then I could go on. 30 seconds to 1 minute unless >> I drop the money. >> I think these are all gone now on highways and bridges. They still exist and >> are in use for some National Park entries, possibly some parking places. I have done the research and for example, OSRM (the most prominent routing engine for OSM data) adds a minimum 15 second penalty per toll booth and in my research I recall (but can’t remember which one) adds a similar penalty for any `barrier=*` tag. Driving in Johannesburg, ZA with their new system <https://en.wikipedia.org/wiki/E-toll_(South_Africa)>, there is a toll gantry between every exit on all of the motorways around the city. If all of them are tagged as `barrier=toll_booth` and therefore incurred a 15 second penalty each, the routing engine could potentially pick a longer route depending on the router setup (shortest time vs shortest distance). > > It's a while since I have seen them in the US for bridge toll, you would > through a couple of quarters in a funnel-shaped basket, thus a bit faster. > But yes, there is a delay, but not so often on your trip that it has > significant impact on your travel time. > > The main advantage of free-flow systems is that you have no breaking that > causes a congestion behind you. > >>> Second, the problems described would be more easily and more elegantly >>> solved with subtagging the existing barrier=toll_booth, instead of >>> inventing a new first level tag. Subtagging preserves backward >>> compatibility, while a new tag has to be implemented everywhere, >> But a toll gantry has no stopping, nor slowing down. A very different beast, >> with the ones around here the vehicle is meant to have an electronic device >> that the toll thing responds with and the payment is deducted automatically. >> If you don't have one of these electronic do dads then you get a letter .. >> with a higher fee. Don't know that "toll both" is how they should be tagged >> from a human conceptual view point rather than the practical computing one. > > All fine, just we don't need a new high-level tag for that. You can add all > free-flow properties, payment methods, average delay times, etc to the > existing one. I'm always in favour of some level of structure instead of > blatant duck tagging. I would normally agree that sub-tagging is a better way to go but that wouldn’t suffice in this case. I do think that there should be some structured, documented sub-tags for `barrier=toll_booth` specifically that describe the different options at at toll both structure; but that’s a discussion for a later time. This is a different beast. The first big issue is that there is physically no barrier in regards to a `toll_gantry` where there is in the case of a `toll_booth`. Not tagging for the renderer or even software, a `barrier=*` tag doesn’t accurately describe this feature. The big problem with adding sub-tags is that there would have to be a major software addition for almost all routing engines to be able to accommodate the sub tags of a `barrier=toll_booth`. The benefits of this tag are that it more accurately represents what is physically on the road and (as a side effect of changing the tag) no software change needs to happen to allow accurate time estimates. I hope this helps clear things up. Thanks! > > tom > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > <https://lists.openstreetmap.org/listinfo/tagging> Zack
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
