Okay, it took a while, but I revised the wiki of the proposal. I removed
the possibility of tagging without relations, and added a table with
examples of tagging.
https://wiki.openstreetmap.org/wiki/Proposed_features/Admission#Additional_relation_tags
Send your opinions.
uto, 27. lis 2020. u
to avoid a lot of relations, I think we should have 2 functions (or pois
within the feature):
1.
place where you can buy the tickets, and
2.
place where the tickets are checked
this could also be the same place (e.g. ticket office where you have to
pass through in order to enter the POI).
Of
On 26-10-2020 17:52, Janko Mihelić wrote:
> I have a feeling the poi role is a bit vague. I would keep it optional,
> with only admission and issue being required for the admission relation
> to work.
Wouldn't issue be optional as well if any admission:issue:* tags are
used? For example, the
pon, 26. lis 2020. u 18:13 Justin Tracey napisao je:
>
> Another thing worth addressing in the proposal is how this relates to
> public transit systems. Things like a ferry that require a ticket for
> entry might translate pretty directly, but what about bus or light rail
> systems where you buy
On 2020-10-24 9:32 a.m., Janko Mihelić wrote:
> Here is my proposal on the wiki:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Admission
>
> In short, we don't have any way to connect places that need a ticket for
> entrance, with the place that sells those tickets. Usually those places
pon, 26. lis 2020. u 15:20 Jeroen Hoek napisao je:
> On 26-10-2020 13:44, Janko Mihelić wrote:
>
> I would use a separate role for the poi (point-of-interest) itself, so
> data consumers know what the subject of the relation is (the poi), where
> its places of admission (entrances) are, and
On 26-10-2020 13:44, Janko Mihelić wrote:
> Although, now that I think of it, you can add the whole theme park
> to the relation, and add role "admission", that doesn't hurt.
I would use a separate role for the poi (point-of-interest) itself, so
data consumers know what the subject of the
ned, 25. lis 2020. u 16:16 Martin Koppenhoefer
napisao je:
> as an additional datapoint
> shop=ticket is the only one with significant usage: (15000)
>
> https://taginfo.openstreetmap.org/search?q=ticket#values
>
> From its definition, it could also not be suitable (unclear), or maybe it
> is?
>
It's easy to see how we would tag simple cases, like a cinema and a ticket
shop. Just add a relation, type=admission, cinema gets the role
"admission", and the ticket shop gets the role "issue".
The question is, how do we tag edge cases.
For example, a big amusement park. In my opinion, there
as an additional datapoint
shop=ticket is the only one with significant usage: (15000)
https://taginfo.openstreetmap.org/search?q=ticket#values
From its definition, it could also not be suitable (unclear), or maybe it is?
https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dticket
On 25-10-2020 14:55, Janko Mihelić wrote:
> Relations are definitely safer, but I wanted to add a unique name
> version for new editors that are intimidated by relations.
> Also for cases when you would have a lot of admission issuers, so we
> don't get some humongous relations. Maybe there's a
On Sun, Oct 25, 2020, 12:59 Martin Koppenhoefer
wrote:
> An alternative idea could be to use the type=site relation, add the ticket
> office with an appropriate role to the relation (e.g. "sells_tickets").
> Maybe the term "sells" should be omitted, because sometimes you need a
> ticket, but it
I think it would be generally useful to add this kind of information, not
only when the ticket office is spatially distant from the feature, but in
every case where a ticket is needed. An alternative idea could be to use
the type=site relation, add the ticket office with an appropriate role to
the
Here is my proposal on the wiki:
https://wiki.openstreetmap.org/wiki/Proposed_features/Admission
In short, we don't have any way to connect places that need a ticket for
entrance, with the place that sells those tickets. Usually those places are
close together, but sometimes they are not.
In
14 matches
Mail list logo
