Proposal talk:Ticket validator

Ticket scanner types for the thing be scanned and mixture types for ticket scanners

Should we use a new tag for what ticket scanner scans? As QC code, IC card, face, paper ticket? Or if ticket scanners have mixture types (gate and turnstile in a row), what shuold I tag it?--Herman Lee Zh (talk) 06:36, 25 April 2022 (UTC)

1. This should be in payment:*=*.
2. That's about barrier=*.

--- Kovposch (talk) 10:43, 25 April 2022 (UTC)

I would suggest that payment:*=yes is used on amenity=ticket_validator to indicate all ticket types that can be validated and any payment methods that can be used directly at the validator instead of a ticket. It would be good to clarify this in the proposal. --JeroenvanderGun (talk) 20:11, 25 April 2022 (UTC)

To clearify, if all all tickets are allowed (paper, card, QR etc), you suggest to use the tag payment:*=yes without any value at the * place? While I understand your reasoning, it feels strange to use that tag in that way as according to tagInfo, it has never been used before in that way --Cartographer10 (talk) 19:52, 26 April 2022 (UTC)

No I meant payment:insertmethodhere=yes for every directly accepted method or ticket (if the ticket is sufficiently common/universal for a tag to exist, i.e. something like payment:kaartjevoorduinrell=yes at the entrance of Duinrell would not be useful to tag). A literal asterisk should not be used. --JeroenvanderGun (talk) 20:03, 26 April 2022 (UTC)

But the proposal already says something about payment:*=yes in the tagging section. Is there something you want me to elaborate on? --Cartographer10 (talk) 07:38, 27 April 2022 (UTC)

Need for a linear representation of a series of ticket validators

The proposal mentions nodes only. There is however a need for a linear representation of the series of gates or turnstiles, that define a barrier. This is needed for rendering, and also for area routing. Each gate/turnstile must then be shared with the way that defines the barrier, and can also be shared with a way highway=footway for instance – thus defining a crossing point through the barrier. This way is not the ticket validator, it is not an amenity. It should hold the tag barrier, not sure what the value should be though: barrier=gate does the job but is not fully satisfactory. (User:Carto'Cité) 07:33, 11 May 2022 (UTC)

Thanks for the comment. Combining the tag amenity=ticket_validator with a barrier tag means that the gate/turnstile has a ticket validator built-in. The problem you describe sounds to me a discussion about how to map barriers (or more precisely, a row of similar barriers) and make it also routable. If it is a row of gates/turnstiles that are ticket validators then either map them all seperately or as a row + amenity=ticket_validator because that is what it is. --Cartographer10 (talk) 17:48, 11 May 2022 (UTC)

I second both comments. Carto'Cité got a relevant need to map barriers as ways and the proposal doesn't prevent it actually by using amenity=ticket_validator on nodes members of that way. It could be added to documentation once adopted, at cleanup Fanfouer (talk) 19:41, 13 May 2022 (UTC)

Alright, I will mention it in the final documentation once accepted --Cartographer10 (talk) 11:55, 15 May 2022 (UTC)

Apologies for coming back to this after the vote. There is one further aspect that could be clarified. I need to represent a series of validators both as a way (that shows the barrier as a linear element) and as a node for routing. That node is shared by 2 ways: the barrier and a highway. Should both the node and the way hold the same tags, i.e. both amenity=ticket_validator and barrier=* ? This could be considered as redundant, in particular if we add the capacity=* tag. Perhaps in that situation amenity=ticket_validator should only be put on the node ? (User:Carto'Cité) 07:25, 21 October 2022 (UTC)

This is a problem on barrier=*. Eg barrier=bollard is used for everything from a routing obstacle, the individual structures, and a functional linear representation.
You need the barrier=* on the point. It's an unsatisfactory situation.
--- Kovposch (talk) 11:35, 21 October 2022 (UTC)

I would give them both the same tags indeed. The node is for routing and the way is object oriented mapping. You can however use the tag capacity=* on the way only. The node is technically 1 ticket validator --Cartographer10 (talk) 17:08, 21 October 2022 (UTC)

Thanks for the answer, sounds good to me. BTW I updated the french version amenity=ticket_validator to match the english one. (User:Carto'Cité) 07:13, 21 October 2022 (UTC)

Diffrent kind of ticket validator

In Italy you have to make your ticket valid before embarking a train, i.e. you hold it into the machine whichs stamps the time and date (and possibly some other codes) on the ticket. It is not required to gain access to the platform, but if you enter the train without having stamped your ticket it is as if you didn’t have a ticket at all. These are like the machines you can find in buses for similar purposes, but they are placed in the access areas of platforms (not connected to a turnstile or gate, in case of trains).—Dieterdreist (talk) 10:46, 12 May 2022 (UTC)

@Dieterdreist: The case you describe is the third example. You can use amenity=ticket_validator together with a barrier tag or not. If you dont combine it with a barrier tag, it means that the ticket validator is a sepeeate pole. You can tag amenity=ticket_validator on a highway node for routing but that is not required. It can also be a standalone node (like it is used now) Cartographer10 (talk) 13:50, 12 May 2022 (UTC)

all right, a separate node makes most sense then, they are either on poles or wall mounted, and they are often not associable to a highway, similar to a ticket machine they are “furniture” in the stations (we also have the turn stile ones in the subway, these are different) —-Dieterdreist (talk) 14:54, 12 May 2022 (UTC)

I wouldn't make the "type" of a ticket validator dependent on another tag (barrier=*). For me these are honestly two types of ticket validators, so I'd suggest something like ticket_validator:type=ticket_puncher or something for ticket punchers. --Elefant aus Wuppertal (talk) 20:39, 4 October 2023 (UTC)