Proposal:Admission
(Redirected from Proposed features/Admission)
Jump to navigation
Jump to search
| Admission | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Janko |
| Tagging: | type=admission, token=* |
| Applies to: |  type=admission, token=*,  admission, issuer
|
| Definition: | Creating a framework for mapping admission to places |
| Statistics: |
|
| Rendered as: | Only routers should use it |
| Draft started: | 2016-02-29 |
| RFC start: | 2020-11-26 |
Proposal
Create a set of tags to be used for mapping admission to different places or services.
Rationale
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 have a ticket to be somewhere is not described by any tag. Having this tag could be very useful for cases when the place for acquiring tickets is not close to the place you need the ticket for. That's when you need to route first to the place that issues the ticket, and then to the place/service itself.
Tagging
The place that needs admission to enter or use needs to be tagged with access=customer or access=permit, and fee=yes if it's not free. This would be the amenity and/or the entrance to the amenity that requires you to have an admission.
A relation would connect the amenity that needs an admission to enter or use, and the place that issues the admission. Both those places would be in the relation, each with its role. The place that requires admission would have the role admission, and the place that issues admission would have the role issuer. An admission relation would need the tag type=admission.
Additional relation tags
issuer:xxx=*
This tag documents all other ways to get the ticket or other admission token. The tag should be put in the admission relation. Some of them could be:
- issuer:website=* if getting a ticket is possible on a website, put the most relevant URL here
- issuer:phone=* phone number of an agent that can issue a ticket
- issuer:roaming=yes you can acquire a ticket on premises from a roaming ticket issuer, a ranger in a National park, or some other person that is not always in the same place.
token=*
This tag tells us what kind of a token you get when you acquire admission. Possible values can be: ticket, receipt, wristband, qrcode, and so on. The tag should be put in the admission relation.
description=*
This tag describes the type of admission. There could possibly be several types of admission to one place, so having a description would help. It would also help mappers that only download the relation and wonder what it's used for.
Examples
| Example use case | Tags of relation members with role admission |
Tags of relation members with role issuer |
Relation tags |
|---|---|---|---|
| Cinemas that have a displaced ticket shop | shop=ticket | type=admission
description=The Vintage Cinema | |
| 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 | shop=ticket | type=admission |
| Places that sell tickets for hiking and walking in nature, like National parks | shop=ticket | type=admission | |
| Ferries that you need to buy a ticket for on the coast somewhere | route=ferry | shop=ticket | type=admission |
| Tennis court that you can play on if you get a key from the restaurant nearby | leisure=pitch | amenity=restaurant | type=admission |
Excluded use cases
This tag scheme shouldn't be used on more complicated systems like train, tram or bus public transport systems, motorway systems, countrywide skipass, countrywide museum pass or any big system like that. More refined proposals for those systems should be made to cover all edge cases. If you think a big system could be implemented, discuss in the tagging mailing list.
Rendering
These tags can't be rendered, but on clicking a POI you could get a list of places where you can get admission to the place or service.
Routing
Routing apps first see that the POI they are routing to (or routing through in case of a ferry route) has the access=customer or access=permit tag. Then it looks for the type=admission relation on that POI. If it finds one, then it asks the user if they have the ticket, and if you answer "NO", you get routed to the ticket shop first.
Comments
Please comment on the discussion page.
External Discussions
On the Tagging mailing list: https://lists.openstreetmap.org/pipermail/tagging/2020-October/055901.html https://lists.openstreetmap.org/pipermail/tagging/2020-November/056445.html
Voting
Instructions for voting
- Log in to the wiki if you are not already logged in.
- Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
| To get this output | you type | Description |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~ automatically inserts your name and the current date.For full template documentation see Template:Vote. See also how vote outcome is processed.
I have comments but abstain from voting on this proposal. Recently i did see a Relation:enforcement with enforcement=access in the database (https://taginfo.openstreetmap.org/tags/enforcement=access). Is this the same/similar concept/idea as here?
--MalgiK (talk) 20:23, 12 November 2020 (UTC)
- I'm not sure what enforcement=access would be, it's not documented on the article about the tag. enforcement=* talks about enforcing traffic rules. --Janko (talk) 21:52, 12 November 2020 (UTC)
- Thanks for reply, yes enforcement=access seems to be something different.
- While checking your proposal a bit more in detail, it seems you what to add things/tags like access=admission for
/
and a type=admission as ), but the top template ({{Proposal Page}}) explains/tells only about the type=admission as . :-( Is there a second separate proposal for access=admission for / which i just missed to see? --MalgiK (talk) 08:26, 13 November 2020 (UTC) - Just looked again over it. Because the token=* is also new a could be also mentioned in the top Proposal_Page Template. Another thing is the usage of the term admission, this is currently used 3x (this could be also lead a bit to confusion, or is it intended?). For the moment it is used as relation name, as a role name (which should be a function description) and as the target object assignment access="admission". So starting to reduce this triple usage could be by renaming the role names a bit? E.g. from "admission" to "access_point" or "admission_point" or "target" and from "issue" to "issuing_place" or "issuing_authority" or "issuer". So it would be also a bit more descriptive? --MalgiK (talk) 16:31, 13 November 2020 (UTC)
- I added the access=admission in the top. The Template is not really made for proposals of tagging schemas, it's made for one tag. As for different keys for roles, I think it's better to keep it simple and short. --Janko (talk) 21:46, 13 November 2020 (UTC)
- Thanks, i did a minor modification to this, feel free to revert it, if it doesn't match or you don't like it. --MalgiK (talk) 23:14, 13 November 2020 (UTC)
- I added the access=admission in the top. The Template is not really made for proposals of tagging schemas, it's made for one tag. As for different keys for roles, I think it's better to keep it simple and short. --Janko (talk) 21:46, 13 November 2020 (UTC)
- I have comments but abstain from voting on this proposal. Network blocks prevented me commenting until now. I'd prefer issue:url to issue:website. Also, issue:phone should refer to the phone key for details on the format that should be used for the number. --Brian de Ford (talk) 15:17, 12 November 2020 (UTC)
- Page about the tag url=* advises not to use the tag if a more specific tag like website=* is possible. But you're right about phone=*, the finished page will link to the page with the appropriate number format if this proposal passes.
- I disagree with the wiki about the difference between website and URL. It is true that both keys have a URL as the value, but I expect a website to have either many pages about a topic or be a single page. I'd normally expect a website to have only a host component with no path component. An admissions page will be a single URL, probably one page on a much larger website about the entity to which one gains admission. --Brian de Ford (talk) 18:37, 12 November 2020 (UTC)
I oppose this proposal. I'm concerned about the suggestion to use "name=Tennis court key" for the final example. This is clearly not the "name" of a real-world thing, but rather a description of the thing you need to get for access. I don't think this taggin should be recommended, and I also don't think that this example is similar enough to the others, where you need to buy a ticket or pass to enter. Also, as mentioned on the talk page, this proposal seems to be ignoring the existince of the very common tag fee=* which is currently the way that we show if you need to pay to enter or use a feature. Because of this I am skeptical of using access=admission, while we have been using access=yes or access=customers + fee=yes for this situation for many years. --Jeisenbe (talk) 19:47, 12 November 2020 (UTC)
- As for name=*, ok, it might as well be description=*. And as for fee=*, as I said in the Talk page, admission doesn't have to be for money. Maybe a venue has limited spaces so admission is given to limit attendance. And if there is no money involved, access=customers also sounds wrong. --Janko (talk) 20:08, 12 November 2020 (UTC)
- Now I see "name=* This tag describes the type of admission". No. description=* is for description, name=* for name, not description Mateusz Konieczny (talk) 07:56, 13 November 2020 (UTC)
- Ok, I changed it to description=*. I wasn't sure what were the constraints on small changes during voting. --Janko (talk) 08:44, 13 November 2020 (UTC)
- I have comments but abstain from voting on this proposal. What is the difference between access=admission and fee=yes? If there is a difference - what is the difference between access=permit and access=admission? Mateusz Konieczny (talk) 21:26, 14 November 2020 (UTC)
- I oppose this proposal. (Update) I explored the possible conflict that access=customers might have with access=admission and concluded that access=admission is actually a more-specific and better way at tagging the process that customer needs to take in order to have access to a facility. However, After reading about comments regarding fee=yes, I've concluded that access=admission is practically the same thing. I commented earlier:
- As for Jeisenbe's concern about fee=*, I think that access=admission is actually a better tag because because of the subtags like issue:website=* and issue:phone=* that are available.
- And I hold true with my statement that it is a better tag. Admission's role and definition as a term itself is more explaining about the situation of access to a facility than fee=yes is. Fee is a pretty bland term and I think the subtags of website and phone fit much better under the term admission than say fee:website=* or fee:phone=*. Therefore, I think the fee=* should be deprecated and access=customers + fee=* should be replaced with customers=admission. The Relation benefits of admission=* also make it a better choice than fee=*. fee=* also only has two values, yes and no. My proposal would also address the concern of legality addressed by User:Kovposh as admission=* would be placed under access=customers. --Lectrician1 (talk) 14:47, 13 November 2020 (UTC)
- fee=* has nearly 800,000 usages. At this point, it does not seem reasonable that we would deprecate a tag with so much usage merely over a preference of naming convention. --ZeLonewolf (talk) 17:16, 14 November 2020 (UTC)
- And yet you would reject this proposal rather? The proposal, as I stated, has a lot more advantages than fee=*. The usage of a current tag that could easily be replaced should not be the limiting factor to this proposal moving forward. Of course, I would like to get the opinion of the proposal author User:Janko about my proposal before continuing. Lectrician1 (talk)
- As I stated in my vote, I support adding the new relation, however, it's not clear why a new value of access=* is needed. It is already serviced by the existing access=customers + fee=*. If the new access tag were dropped, it would be a strong proposal to relate admission points to attractions. Since I agree with one part of the proposal but disagree with the other part, I have no choice but to vote no for the whole thing. I want to make it clear that I would change to a "yes" if the vote were on the relation only, which I think is a good idea --ZeLonewolf (talk) 18:13, 14 November 2020 (UTC)
- fee=* has nearly 800,000 usages. At this point, it does not seem reasonable that we would deprecate a tag with so much usage merely over a preference of naming convention. --ZeLonewolf (talk) 17:16, 14 November 2020 (UTC)
- I oppose this proposal. Basically I disagree with adding another legal restriction value as access=admission, especially because it's a method of legal access. As a though experiment, something in the lines of access=reservation doesn't make much sense either, thus there's already reservation=*. access=permit is acceptable since it defines the legality. Instead, can use something slike admission=* directly. (as a secondary consequence, admission:description=* can be used in a more systematic manner, unlike an unreliably general description=* that could be modified for other purposes or hitting the value length limit; also possible to consider admission:*=* over issue=*) ---- Kovposch (talk) 00:14, 14 November 2020 (UTC)
- I oppose this proposal. I support the need to relate ticket issuing to an attraction/venue. However, I feel that the existing access=customers + fee=* should be used rather than the proposed access=admission. I would be in favor of a relation that relates a ticket issuing facility, an attraction, and parking for that attraction in a single relation with different roles. --ZeLonewolf (talk) 04:53, 14 November 2020 (UTC)
I approve this proposal. The use of a relation to link points of issuance and admission makes sense to me. I am slightly hesitant about adding an access-value in the form of admission, but agree with Lectrician1 that it is much clearer and more specific for this use case than customers. --JeroenHoek (talk) 10:52, 14 November 2020 (UTC)
- I oppose this proposal. I would remove the whole "you need to buy a ticket" thing because we already have the access=customers tag. A new tag saying "you need the admission of an official authority" / "you need the admission of the company" to enter an area, would be interesting. But maybe such tag would be in conflict with access=private? Something that needs to be discussed. However I like the idea to tag where you can buy a ticket. But is "issue" the right word? Maybe "ticket" or "voucher" is better/more intuitive? --Hauke-stieler (talk) 13:21, 22 November 2020 (UTC)
- I oppose this proposal. I like the idea of a relation for this type of thing, but I don't think the wording is that intuitive. "issue" doesn't really make sense. Adamant1 (talk) 02:13, 25 November 2020 (UTC)