Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 23:12, Volker Schmidt  wrote:
> 
> The proposed highway=toll_gantry is one possibility.
> It woud prefer something like
> highway=gantry
> gantry=traffic_signals | speed_camera | automatic_toll_collection | ...


then I would go for man_made (tagging the naked structure and adding functions 
with other tags), but we already have different tagging established for those 
you mention, only the automatic toll collection is missing.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Volker Schmidt]

In OSM at present there are some twenty gantries for toll collection tagged
as highway=toll_bridge. They should be retagged as gantries with equipment
for toll collection or whatever their purpose is. The proposed
highway=toll_gantry is one possibility.
It woud prefer something like
highway=gantry
gantry=traffic_signals | speed_camera | automatic_toll_collection | ...

On 22 September 2018 at 23:01, Colin Smale  wrote:

> On 2018-09-22 22:50, Volker Schmidt wrote:
>
> A toll_bridge [1] is a bridge for which you have to pay to pass,
> highway=toll_bridge should be a highway that is a toll-bridge, not a
> mechanical structure that is installed above a road to check the passing
> traffic. This would be a gantry [2] https://en.wikipedia.org/wiki/
> Gantry_(road_sign)
>
>
> Exactly. A toll bridge should be highway=motorway (or whatever) +
> bridge=yes + toll=yes in OSM.
>
> A gantry is only the structure; it might carry all manner of devices in
> any combination, and even if it had no devices on it, it would still be a
> gantry...
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 22:50, Volker Schmidt  wrote:
> 
> A toll_bridge [1] is a bridge for which you have to pay to pass, 
> highway=toll_bridge should be a highway that is a toll-bridge, not a 
> mechanical structure that is installed above a road to check the passing 
> traffic.


I see, thank you for this remark. For highways that are toll bridges we already 
have a tag: toll=yes on the highway. It will have the highway class the road 
has, so we won’t be able to use highway=toll_bridge for toll bridges (but I 
agree that “toll bridge” apparently in English has not  the same meaning as is 
the German term Mautbrücke (meaning both, toll bridge and gantry)).

The 64 instances of highway=toll_bridge are all tagged on nodes: 
https://taginfo.openstreetmap.org/tags/highway=toll_bridge

what about 
highway=gantry or toll_gantry or man_made=gantry?
The latter has most usage, 2127:
https://taginfo.openstreetmap.org/tags/man_made=gantry

Cheers,
Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Colin Smale]

On 2018-09-22 22:50, Volker Schmidt wrote:

> A toll_bridge [1] is a bridge for which you have to pay to pass, 
> highway=toll_bridge should be a highway that is a toll-bridge, not a 
> mechanical structure that is installed above a road to check the passing 
> traffic. This would be a gantry [2] 
> https://en.wikipedia.org/wiki/Gantry_(road_sign)

Exactly. A toll bridge should be highway=motorway (or whatever) +
bridge=yes + toll=yes in OSM. 

A gantry is only the structure; it might carry all manner of devices in
any combination, and even if it had no devices on it, it would still be
a gantry...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Volker Schmidt]

A toll_bridge [1] is a bridge for which you have to pay to pass,
highway=toll_bridge should be a highway that is a toll-bridge, not a
mechanical structure that is installed above a road to check the passing
traffic. This would be a gantry [2]
https://en.wikipedia.org/wiki/Gantry_(road_sign)

[1] https://en.wikipedia.org/wiki/Toll_bridge
[2] https://en.wikipedia.org/wiki/Gantry_(road_sign)




On 22 September 2018 at 16:13, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Sep 2018, at 23:23, Jonathon McClung 
> wrote:
> >
> > The tag barrier=toll_booth is currently not specific. In fact, when it
> is used in the case of a non-barrier electronic toll gantry, it is
> misleading.
>
>
>
> maybe it is even mistagged? Looking at taginfo I see 64
> highway=toll_bridge. According to the longstanding definition for
> barrier=toll_booth it is „A place where a road usage toll or fee is
> collected.“
>
> Now „collected“ is not actually true for systems that wirelessly check
> whether you have paid or not (a subscription), it is only intended for
> places where you actually pay (or spend your prepaid, even wirelessly).
>
> the barrier key somehow implies either you pay or you don’t pass
>
>
>
> > In its relation to routing software there is currently no standard way
> to tell the routing software that this “toll booth” is not a barrier.
>
>
> and maybe no booth either? To me highway=toll_bridge seems a good tag, as
> it is self explanatory and combinable with barrier tags.
>
> cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 19. Sep 2018, at 23:23, Jonathon McClung  wrote:
> 
> The tag barrier=toll_booth is currently not specific. In fact, when it is 
> used in the case of a non-barrier electronic toll gantry, it is misleading.



maybe it is even mistagged? Looking at taginfo I see 64 highway=toll_bridge. 
According to the longstanding definition for barrier=toll_booth it is „A place 
where a road usage toll or fee is collected.“

Now „collected“ is not actually true for systems that wirelessly check whether 
you have paid or not (a subscription), it is only intended for places where you 
actually pay (or spend your prepaid, even wirelessly). 

the barrier key somehow implies either you pay or you don’t pass 



> In its relation to routing software there is currently no standard way to 
> tell the routing software that this “toll booth” is not a barrier.


and maybe no booth either? To me highway=toll_bridge seems a good tag, as it is 
self explanatory and combinable with barrier tags.

cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Zack LaVergne]

Tom, I’ll try to address most of your points below


Zack LaVergne  |  Kaart   | Software Developer |  
501.690.0584  |  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  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 
, 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 
> 

Zack

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Paul Johnson]

For the ones you have to stop at, try adding highway=traffic_signals or
highway=stop, it's pretty rare to find toll barriers that expect you to
stop to not have one or both.  For at speed ones, just don't add the stop
or signals that don't exist.

As for toll gantries not requiring you to slow down, Kansas Turnpike would
like you to hold its beer

On Thu, Sep 20, 2018, 00:30 Warin <61sundow...@gmail.com> wrote:

> On 20/09/18 09:26, Tom Pfeifer wrote:
> > On 19.09.2018 19:31, Jonathon McClung wrote:
> >> The issue is mostly with how the current standard (as stated here
> >> https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth
> >> ) impacts
> >> routing. This is said on the proposal page here "Many current routing
> >> softwares add a delay to trip time when encountering the tag barrier
> >> =toll_booth
> >> .
> >> However, the delay on these more modern toll collection systems is
> >> significantly less; not requiring the driver to stop in most cases.
> >> In effect, this means that many drivers will be routed onto a slower
> >> route.” This is the major difference. Of course the way itself should
> >> be tagged toll=yes. This is a clean way to a) show where the toll
> >> begins and b) give the routing software something to account for on
> >> the way.
> >
> > 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.
>
> >
> > 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.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Andrew Harvey]

>In light of the fact that some roads will be missing the tag toll=yes, routing 
>software will have to be updated to avoid highway=toll_gantry if the user is 
>trying to avoid tolls entirely.

Just a note about this point, there can be barrier=toll_booth's or
highway=toll_gantry's which only toll based on mode of transport or
based on destination, so it would be wrong to avoid one of those when
the user requests to avoid tolls unless there is a
toll=yes/toll:mode:yes on the way.
On Thu, 20 Sep 2018 at 01:55, Jonathon McClung  wrote:
>
> Hello OSM Tagging List!
>
> Two weeks have come and gone and now the proposal for highway=toll_gantry is 
> up for vote!
>
> Please visit 
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry and cast 
> your vote. If you missed this proposal the first time, still have concerns, 
> or still have questions, please join the discussion. Otherwise, we look 
> forward to seeing your votes!
>
> Thanks!
>
> --
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Tom Pfeifer]

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.


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.


tom

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Warin]

On 20/09/18 09:26, Tom Pfeifer wrote:

On 19.09.2018 19:31, Jonathon McClung wrote:
The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts 
routing. This is said on the proposal page here "Many current routing 
softwares add a delay to trip time when encountering the tag barrier 
=toll_booth 
. 
However, the delay on these more modern toll collection systems is 
significantly less; not requiring the driver to stop in most cases. 
In effect, this means that many drivers will be routed onto a slower 
route.” This is the major difference. Of course the way itself should 
be tagged toll=yes. This is a clean way to a) show where the toll 
begins and b) give the routing software something to account for on 
the way.


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.




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.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Tom Pfeifer]

On 19.09.2018 19:31, Jonathon McClung wrote:
The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts routing. This is said on the 
proposal page here "Many current routing softwares add a delay to trip time when encountering the 
tag barrier =toll_booth 
. However, the delay on these more 
modern toll collection systems is significantly less; not requiring the driver to stop in most 
cases. In effect, this means that many drivers will be routed onto a slower route.” This is the 
major difference. Of course the way itself should be tagged toll=yes. This is a clean way to a) show 
where the toll begins and b) give the routing software something to account for on the way.


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.


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,


tom

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Graeme Fitzpatrick]

On Thu, 20 Sep 2018 at 09:04, Daniel McCormick 
wrote:

>
> That is an interesting case of a toll gantry being on the bridge. I fear
> though that adding that to the bridge that goes over the tolled highway
> might cause there to be some confusion concerning which road is actually
> tolled. This is easily worked around though by just adding a node to the
> tolled road very close to the bridge. This solution would be much cleaner
> then previous version of polygon toll gantries and is minimally invasive to
> the data.
>

Makes sense, thanks Daniel!

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Daniel McCormick]

That is an interesting case of a toll gantry being on the bridge. I fear though 
that adding that to the bridge that goes over the tolled highway might cause 
there to be some confusion concerning which road is actually tolled. This is 
easily worked around though by just adding a node to the tolled road very close 
to the bridge. This solution would be much cleaner then previous version of 
polygon toll gantries and is minimally invasive to the data.


> On Sep 19, 2018, at 4:40 PM, tagging-requ...@openstreetmap.org wrote:
> 
> Re: [Tagging] Feature Proposal - Voting - Toll Gantry

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Graeme Fitzpatrick]

On Thu, 20 Sep 2018 at 07:24, Jonathon McClung 
wrote:

Jonathon

Good idea!

One question though

>  We are talking about the increasingly common worldwide appearance of the
> toll gantries on their own. Example pictures can be found here
> 
> .
>

We have a couple of spots where, in one case toll "readers" & in the other
speed cameras are mounted on a bridge crossing the highway eg
https://www.google.com/maps/@-27.95082,153.3420894,3a,75y,164.49h,101.6t/data=!3m5!1e1!3m3!1setsoRfXvi_MJ52Ao30hKMA!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3DetsoRfXvi_MJ52Ao30hKMA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D100.4385%26pitch%3D0%26thumbfov%3D100

Could you gantry concept also be included on the existing bridge tags?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jonathon McClung]

Jérôme,

That email seems to be covering a lot of issues that the proposal is 
not trying solve, nor could it solve without first laying the foundation that 
it attempts to set. I’ll narrow in on the thoughts that are most pertinent. You 
stated; “In fact, this is a problem with software solution not a tag.” This is 
most definitely an issue with the tag and not a software issue. The tag 
barrier=toll_booth is currently not specific. In fact, when it is used in the 
case of a non-barrier electronic toll gantry, it is misleading. In its relation 
to routing software there is currently no standard way to tell the routing 
software that this “toll booth” is not a barrier. The advantage of using the 
key highway is that it is clear that there is no barrier. 
“My 2 cents comment is in relation with toll because i have an rfid 
badge and I don't wait a minute. I just slow down to 30km/h to cross the toll 
booth.” A gantry like this is exactly what we are talking about. The most 
modern ones do not require the driver to slow down at all. We are not trying to 
solve every type of problem, we are trying to establish a base and build off of 
it. 
“For information barrier 
=lift_gate 
 and fee 
=yes 
 can be set on paint and 
barrier=toll_booth <> can be a polygon with intersection on your highway.” It 
is a common, but incorrect process to draw polygons over ways. Most validators 
will alert you to let you know that you should not do this. This solution stays 
within the bounds of best practice.
Another thought you mentioned, "I think it's better solution to set 
toll_booth in highway because it's specific.”  We also examined this option, 
but the difference is that this is not a booth.
The picture you provided helpfully showed us what you are referring to. 
However, it is not what we are referring to. We are talking about the 
increasingly common worldwide appearance of the toll gantries on their own. 
Example pictures can be found here 
. 
The last six sentences of the email seem to be advocating for making 
the process more complicated. I am well aware that the tag gantry was proposed, 
though the page does not indicate whether or not it was ever approved or not.


-- 
Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 


> On Sep 19, 2018, at 1:30 PM, Jérôme Seigneuret  
> wrote:
> 
> In fact, this is a problem with software solution not a tag. the 
> interpretation is a toll access need to wait a part of time. But if you have 
> badge access you don't wait... and if there is lot of traffic you are 
> depandent of traffic... waiting time is not for me an argument and a 
> limitation caused by existing key value but just the interpretation. My 2 
> cents comment is in relation with toll because i have an rfid badge and I 
> don't wait a minute. I just slow down to 30km/h to cross the toll booth.
> 
> problem is on micro-mapping schema and specifing object with speed crossing 
> badge, crossing with credit card, crossing with money...
> 
> That same problem with traffic transport. If you pocess an abonment you can 
> save time, more than else if it payed with CD and more than other if it payed 
> with money.
> 
> An other work is the number of rapid access because if there only one speed 
> toll an lot of traffic you need wait a time anyway.
> 
> In my opinion, the best solution is on number of rapid access toll vs classic 
> access in same solution of parking numbers of places for specific condition.
> 
> for information barrier 
> =lift_gate 
>  and fee 
> =yes 
>  can be set on paint and 
> barrier=toll_booth <> can be a polygon with intersection on your highway.
> 
> In fact the problem is only an parent key of toll because it's assimilate to 
> a barrier but this is just an obligatory access point for users
> I think it's better solution to set toll_booth in highway because it's 
> specific
> In railway you payed with resevation on railway track between to point A to B 
> on time. Did you learn about toll_booth <> on railway???
> historically  there is also barrier=entrance but you can understand in this 
> case there is no physical object. so barrier or not??? That same with 
> barrier=no Isn't it?
> 
> Other problem are using lift_gate and toll_booth with same point... that 
> schema is problematic.
> 
> Can you proposed solution with twice type access
> 
> exemple for french access to A709 in France
> 

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jérôme Seigneuret]

In fact, this is a problem with software solution not a tag. the
interpretation is a toll access need to wait a part of time. But if you
have badge access you don't wait... and if there is lot of traffic you are
depandent of traffic... waiting time is not for me an argument and a
limitation caused by existing key value but just the interpretation. My 2
cents comment is in relation with toll because i have an rfid badge and I
don't wait a minute. I just slow down to 30km/h to cross the toll booth.

problem is on micro-mapping schema and specifing object with speed crossing
badge, crossing with credit card, crossing with money...

That same problem with traffic transport. If you pocess an abonment you can
save time, more than else if it payed with CD and more than other if it
payed with money.

An other work is the number of rapid access because if there only one speed
toll an lot of traffic you need wait a time anyway.

In my opinion, the best solution is on number of rapid access toll vs
classic access in same solution of parking numbers of places for specific
condition.

for information barrier =
lift_gate  and
fee =yes
 can be set on paint and
barrier=toll_booth can be a polygon with intersection on your highway.

In fact the problem is only an parent key of toll because it's assimilate
to a barrier but this is just an obligatory access point for users
I think it's better solution to set toll_booth in highway because it's
specific
In railway you payed with resevation on railway track between to point A to
B on time. Did you learn about toll_booth on railway???
historically  there is also barrier=entrance but you can understand in this
case there is no physical object. so barrier or not??? That same with
barrier=no Isn't it?

Other problem are using lift_gate and toll_booth with same point... that
schema is problematic.

Can you proposed solution with twice type access

exemple for french access to A709 in France
http://montrajet.deplacement-a9.fr/uploads/images//point-44/picto-7-barriere-de-peage-baillargues.jpg
you can see 1 rapid access right and left
in opposite direction there is 3 speed access left (for vehicule with
specifi maxheight) and 2 speed access on right (for increase traffic speed
for hgv)

that is just my reflection on toll_booth.

For you proposed key, I think you can cut element in twice

highway=grantry+toll=yes and add you speed conditon or stop conditon and it
respond to your case.
grantry is also a proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/Gantry

you can set all you need on point in intersection with gantry

*gantry *can be also use for direction information or message with
electronic information

The problem, and I think you understand where I want go, would be on
combination of information on object in same position.




Le mer. 19 sept. 2018 à 19:33, Jonathon McClung  a
écrit :

> The issue is mostly with how the current standard (as stated here
> https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth
> ) impacts
> routing. This is said on the proposal page here "Many current routing
> softwares add a delay to trip time when encountering the tag barrier
> =toll_booth
> . However,
> the delay on these more modern toll collection systems is significantly
> less; not requiring the driver to stop in most cases. In effect, this means
> that many drivers will be routed onto a slower route.” This is the major
> difference. Of course the way itself should be tagged toll=yes. This is a
> clean way to a) show where the toll begins and b) give the routing software
> something to account for on the way.
>
> At the end of your email you talk about alternate names. We discussed many
> names, but ultimately landed on toll_gantry because the meaning of the word
> toll is immediately apparent. The term gantry was chosen because it’s
> meaning is specific and less ambiguous than “toll bridge" the other common
> name for these fixtures. Much of this is discussed on the proposal’s page
>  and 
> discussion
> page
> 
> .
>
>
> --
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com
>
>
> On Sep 19, 2018, at 10:59 AM, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> wrote:
>
> I don't really understand the difference
>
> toll_both is a vending machine (or human) with lift gate barrier.  It is
> just an other type of object because in other case you can set really the
> gantry as line and set on point type camera 

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jonathon McClung]

The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts routing. 
This is said on the proposal page here "Many current routing softwares add a 
delay to trip time when encountering the tagbarrier 
=toll_booth 
. However, the 
delay on these more modern toll collection systems is significantly less; not 
requiring the driver to stop in most cases. In effect, this means that many 
drivers will be routed onto a slower route.” This is the major difference. Of 
course the way itself should be tagged toll=yes. This is a clean way to a) show 
where the toll begins and b) give the routing software something to account for 
on the way. 

At the end of your email you talk about alternate names. We discussed 
many names, but ultimately landed on toll_gantry because the meaning of the 
word toll is immediately apparent. The term gantry was chosen because it’s 
meaning is specific and less ambiguous than “toll bridge" the other common name 
for these fixtures. Much of this is discussed on the proposal’s page 
 and 
discussion page 
.
 


-- 
Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 


> On Sep 19, 2018, at 10:59 AM, Jérôme Seigneuret  
> wrote:
> 
> I don't really understand the difference
> 
> toll_both is a vending machine (or human) with lift gate barrier.  It is just 
> an other type of object because in other case you can set really the gantry 
> as line and set on point type camera or other information object.
> 
> camera as set in relation there is an other subject in France "Ecotaxe 
> gantry" 
> 
> highway can be set with fee=yes if this is just that you wan't
> 
> there is also speed tall access with RFID toll badge  ("Télépéage" for 
> frenchies) 
> 
> in other way if it's a camera you can set camera type 
> there is speed_camera why not  simply highway=atc_camera
> 
> I think this is only in relation with highway. Isn't It?
> 
> 
> 
> 
> Le mer. 19 sept. 2018 à 17:55, Jonathon McClung  > a écrit :
>   Hello OSM Tagging List!
> 
>   Two weeks have come and gone and now the proposal for 
> highway=toll_gantry is up for vote!
>  
>   Please visit 
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry 
>  and cast 
> your vote. If you missed this proposal the first time, still have concerns, 
> or still have questions, please join the discussion. Otherwise, we look 
> forward to seeing your votes!
> 
>   Thanks!
> 
> -- 
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 
>  
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jérôme Seigneuret]

I don't really understand the difference

toll_both is a vending machine (or human) with lift gate barrier.  It is
just an other type of object because in other case you can set really the
gantry as line and set on point type camera or other information object.

camera as set in relation there is an other subject in France "Ecotaxe
gantry"

highway can be set with fee=yes if this is just that you wan't

there is also speed tall access with RFID toll badge  ("Télépéage" for
frenchies)

in other way if it's a camera you can set camera type
there is speed_camera why not  simply highway=atc_camera

I think this is only in relation with highway. Isn't It?




Le mer. 19 sept. 2018 à 17:55, Jonathon McClung  a
écrit :

> Hello OSM Tagging List!
>
> Two weeks have come and gone and now the proposal for highway=toll_gantry
> is up for vote!
>
> Please visit
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry and
> cast your vote. If you missed this proposal the first time, still have
> concerns, or still have questions, please join the discussion. Otherwise,
> we look forward to seeing your votes!
>
> Thanks!
>
> --
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging