Proposal talk:Admission

Relations

The goal of the proposal seems clear and makes sense.

Is there a strong reason not to focus exclusively on relations to map this? This seems like a good candidate for a relation. Using only relations could have the benefit of not needing a new access=* value (which would be hard to get people to agree on, and routers will probably do the wrong thing until it is finally added to their list of no-ish values); you could just recommend access=customers and have having an admission-relation on the same object mean “access for customers with a valid ticket”.

In terms of role names, admission might be confusing in that it could also be thought to point to the exact place (gate, turnstile, entrance) where you are to submit your ticket to gain entrance. A more generic term might be venue, but that does sound weird for something like a ferry route. Even more generic would be poi or subject.

With a relation you might also consider adding a role for these places (gate, turnstile, entrance, etc.) where the tickets are checked and access is granted. For a large point-of-interest like a theme park, it is not uncommon to have the access location mapped separately, and your admission-relation could add these (along with the POI itself and the ticket office) with a role of entrance (or even admission which does sound natural for this). For routing purposes that makes sense too: if there are entrances mapped and part of the relation, offer directions to these, otherwise, offer directions to the point-of-interest entity itself. JeroenHoek (talk) 16:44, 24 October 2020 (UTC)

I removed non-relations from the proposal, I think it looks much clearer now. I also added several examples of how I envisioned it would be tagged. Janko (talk) 09:41, 12 November 2020 (UTC)

I would develop further on these 2 points:

1. On relations, this may seem to be more fit for incorporating into type=site, and public_transport=stop_area (or public_transport=stop_area_group), as a new or formally defined role; unless you are down to the detail of different ticketing counters for different entrances (eg fast pass?)? However, this further highlights a geographical relevance problem for relations, where the ticketing location may be very remote or numerous apart from the ticket entrance; brand=*, and network=* (may be able to handle national parks from your example) should be better solutions mostly, as implied from your thought experiment of admission:to=*. This may also be mixed up with the issue of fees and payment, where you must pay off-site, regardless of the need for an admission certification (maybe the concept of authentication=* in proofing your payment or identity could be applicable?).

2. "admission" would be a method or procedure of "access", not legal validity which access=* is for. This aspect reminds me of Proposed features/reception point or amenity=reception_desk, and questions about getting through security booths.

---- Kovposch (talk) 20:38, 24 October 2020 (UTC)

I think If we start merging the admission concept into other schemes (like site, stop_area), we are going to make it much more difficult for the data consumers. There are a lot of different classes of objects the admission concept can be applied to, and they can all have their own tagging scheme. For example, you have a tennis court for which you have to get a key in a restaurant. Should that be a site relation? Mappers are going to struggle to find a way to put the admission in a case like that. Or dozens of use cases I can't imagine now. Data consumers would have to change their code each time a new way of applying admission=* is conceived. I think having a generic admission relation type makes it easy to use and have it work instantly on all apps that incorporated it.

As for using admission:to=* instead of relations, I agree that is something that can be used in bigger schemes where having a relation with hundreds of members doesn't make sense. For example public transport, country wide museum passes, or things like that. I wanted to introduce them right away, but I got feedback that relations are better, so I tried to simplify the first proposal, and hope we could get this in in the next one.Janko (talk) 09:58, 12 November 2020 (UTC)

I haven't followed the discussion before the vote, but I consider it a major downside that this proposal (now?) requires a relation because some tags that one might normally expect on the feature itself (issue, token, etc.) are supposed to be added to a relation. --Tordanik 22:07, 14 November 2020 (UTC)

Supposedly, admission is going to be a Key that can be placed on any point/way/area, irregardless of relation or not (see proposal heading). The relation is just there if there's multiple parts to the admission concept. You should probably look through the voting comments as well since there are a variety of other conflicts address and a proposal I made. --Lectrician1 (talk) 22:17, 14 November 2020 (UTC)

Rendering

You could suggest that map viewers can use this feature to show a link to the ticket office when you look at the details of the poi, and vice versa. They may also offer to show directions from one to the other. JeroenHoek (talk) 16:47, 24 October 2020 (UTC)

You're right, I'll add that. Janko (talk) 09:31, 12 November 2020 (UTC)

Why admission:issue:xxx?

(Updated) Why do the tags have to have the issue subkey? Like why admission:issue:website=* and not just website=*, phone=*, and admission:roaming=yes? --Lectrician1 (talk) 17:38, 9 November 2020 (UTC)

Proposed_features/Admission#admission:issue:xxx.3D.2A

Because that way you could add new ways of getting admission, and data consumers will know that the new tag is just another way to get the ticket. Also, I thought we could have admission:reservation:website=* if you can only reserve an admission online. Janko (talk) 09:30, 12 November 2020 (UTC)

Fee is used when you need to pay for admission

The proposal says: Right now, if we want to tag a place that needs admission, we only have the tag access=*. This only says if you can go to/through there or not. The case when you need to buy a ticket to be somewhere is not described by any tag. , but actually there is fee=* —Dieterdreist (talk) 15:49, 12 November 2020 (UTC)

That's true, but access=admission isn't always the same as fee=*, because sometimes you have to have a free ticket. The wording in the proposal could be tweaked there to say The case when you need to have a ticket to be somewhere is not described by any tag. --Janko (talk) 16:04, 12 November 2020 (UTC)

Table formationg

The example table readability might be a bit improved by writing the tags in blocks (without "+"), like this:

Example use case	Tags of relation members with role admission	Tags of relation members with role issue	Relation tags
Cinemas that have a displaced ticket shop	amenity=cinema access=admission	shop=ticket	type=admission description=The Vintage Cinema issue:website=https://vintagecinema.org/tickets token=ticket;qrcode
Shops that sell skipass tickets for ski resorts. Warning, this tagging system shouldn't be used on tickets that can be used on several ski resorts, see Excluded use cases	aerialway=chair_lift access=admission aerialway=cable_car access=admission	shop=ticket	type=admission description=Skipass Jahorina token=contactless_ticket
Places that sell tickets for hiking and walking in nature, like National parks	boundary=protected_area access=admission barrier=turnstile access=admission	shop=ticket	type=admission description=Paklenica National park issue:roaming=yes token=receipt
Ferries that you need to buy a ticket for on the coast somewhere	route=ferry access=admission	shop=ticket	type=admission description=Lokrum boat rides token=receipt
Tennis court that you can play on if you get a key from the restaurant nearby	leisure=pitch sport=tennis access=admission	amenity=restaurant	type=admission description=Tennis court key token=key

--MalgiK (talk) 16:42, 13 November 2020 (UTC)

Parking

To be truly complete, this proposed admission relation should also have an optional parking role, to indicate parking areas that are associated with a particular attraction. That way, one relation can have to location of the attraction, the ticket booth, and the parking -- all things that visitors need to visit an attraction. --ZeLonewolf (talk) 04:44, 14 November 2020 (UTC)

This could be revisited in a future proposal to widen the scope of the admission relation. Right now, I'm trying to keep it as narrow as possible to have a chance at passing it. --Janko (talk) 14:45, 13 December 2020 (UTC)

Venue

Since it's open season on good ideas, why not "venue" instead of "admission"? --ZeLonewolf (talk) 14:31, 13 December 2020 (UTC)

Because that can't be used with, for example, ferry lines, sports pitches, and probably lot more things. I don't want to close the proposal to only the cases where you want to go to a venue. --Janko (talk) 14:42, 13 December 2020 (UTC)