A proposal for uniform tagging of (theme park) queues.
Please discuss this proposal on its wiki talk page.
2 Likes
footway=queue would solve =footway which are physically separated or independent, but not markings-only queuing areas drawn on sidewalks or the same walkway. Need to emphasize highway=footway + footway=queue should not be drawn separately for the latter.
A question is whether what’s being queued for needs to be explicit: queuing_for:attraction=roller_coaster ?
is it possible for designated queue to be also footway=sidewalk ?
I haven’t thought about queues on sidewalks- never seen those myself.
Are those often permanent? Or just some poles with ropes in between that businesses put outside when they’re open? I’d argue, in that second case, they shouldn’t be mapped at all.
I thought about theoretical case in a theme park where sidewalk of service road is used as queue space for one of attractions.
I don’t think theme parks really have sidewalks- just paths. Sometimes the queues overflow onto the main paths, but those are temporary.
OpenStreetMap has case closeish to sidewalk
(and if I learned anything from OpenStreetMap - that would that “combination X is not present anywhere” turns out wrong more often than you would think)
I don’t think values such as regular should be used or introduced. It’s too subjective.
1 Like
queue=entrance, maybe?
What about highway=steps?
Would you add steps=queue or footway=queue?
1 Like
There are fenced queues for bus stops on sidewalks. I see =sidewalk as functional, so eg is_sidepath=yes for being physically sidewalks.
That doesn’t say anything. All other queue= , and the vast majority of queues in reality are for entry.
Usually I’m against them, but =regular / =standard in this case seems unavoidable for “regular tickets” or “standard class” visitors, if it needs to be explicit. Otherwise, either not have queue= , or maybe =all for having everyone.
queue=any?
This is a very good point - often queue lines at theme parks will combine footways and steps. Skipping the footway=queue tag and only using queue=* only allows much more flexibility and reduces the need for a unique tag for every highway= type.
We already have precedent with things like parking_space=normal. As long as there’s documentation, queue=normal (or similar) should be fairly unambiguous. Similarly, queue=single might be less clear than queue=single_rider (without documentation of the meaning), but a more explicit value of queue=single_rider may not apply to all use cases.
As written on the proposal page
" Queues are, by definition, one-way. oneway=yes is implied by footway=queue."
I would change the meaning to say that queue tags must be used in conjunction with oneway=yes tags. If a data consumer does not make use of queue tags, they still need to know that the footways are oneway.
1 Like
There are not only queues at theme parks. I’m thinking of airport security and immigration, security checks in general. Ticket counters,… and their “shape” is frequently adapted to the amount of people waiting. Even they are a permanent barrier, usually they offer such flexibility. I’m not sure it’s a good idea to map those as ways.
As well to me your queue=* is to limited. Like on airports you have normal priority lanes from the airline customers, something like TSA pre, in general business class passengers. I came across also special lanes for families and disabled passengers. At immigration usually the split is based on nationality, but also there I came a cross several different types of priority lanes and usually there are also special lanes for crews and diplomats.
1 Like
isn’t it the contrary? Nobody would be yelled at for going back in the queue? If it were oneway you could not go back.
2 Likes
Would you use queue= only for queuing people (footway/steps/sidewalk etc) or also for vehicles? For example at ferry terminals there are queues for cars and probably bicycles.
1 Like
The previous idea looked at them as areas. If there’s no permanent shape, it might have to be an area:highway=footway + queue= without highway=footway lines. Proposal:Queue paths - OpenStreetMap Wiki
I thought about it, but I assume =priority is supposed to be used for all. There are queues where multiple prioritized categories are mixed. The exact criteria will need to be further detailed in another attribute.
That’s a great question for =footway + oneway=yes in general. These might have to be eg foot:forward=designated + foot:backward=discouraged , oneway:foot:advisory=yes , or treating oneway:foot=yes (for oneway=yes usually being applied to vehicles only) as different meaning (because you are allowed to walk back slightly even at restricted zones as security and borders). restriction=no_exit is too much trouble.
Saying that queue lines shouldn’t be tagged as oneway=yes because it’s possible to leave them partway through is unhelpfully pedantic in my opinion. It should be common sense that oneways on footways are less restrictive than a oneway on a motorway, for example. We don’t need to use convoluted tags like oneway:foot:advisory=yes to represent a situation that is already commonly understood. Trying to redefine the usage of oneway=yes on highway=footway ways shouldn’t be in the scope of this proposal.
1 Like