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 relation is (the poi), where
its places of admission (entrances) are, and where tickets are issued.

> With ski resorts, you would need to put all the aerialways in the
> relation as "admission", and ticket shops as "issue". You don't put
> the ski slopes or the whole ski resort with admission, because you
> can still hike through there, you just can't use the ski lifts.

If you have a ticket that grants access to several ski-lifts, you could
just create a relation with those ski-lifts as poi members.

> Another example is a big nature park. There is one or two official
> entrances, but you can just hike to that park without seeing any
> entrances or boards that say "You have to have a ticket". There is a
> possibility you buy a ticket from a ranger you accidentally meet. So
> do we put all the paths in that park in the relation? Or is putting
> the whole park boundary, and the oficial entrances enough?

Perhaps you can omit the admission role completely in that case. If the
poi (the park) is part of the relation, you would already know that a
valid ticket is needed. Additional tags on the relation could indicate
that you may be checked randomly at the poi.

You also document that omitting the issue role means that you have to
use other methods to acquire a ticket. You already propose
admission:website, so I would document that if that exists, data
consumers and users know that tickets can be bought online.

You might consider adding another addmission:* tag to indicate that
tickets may be bought from a roaming agent.

For neatness and extensibility, perhaps admission:issue:* can be used as
namespace for these? Data consumers then know that any admission:issue:*
key means tickets can be got there, and you can document the common
types (e.g., admission:issue:website, admission:issue:phone,
admission:issue:roaming=yes (or something like that, for the roaming
ranger edge case)).


So for the park example:

type=admission
name=Mihelić Park
admission:roaming_checks=yes
admission:issue:roaming=yes
admission:issue:website=https://example.com/tickets
admission:token=ticket;qr_code

poi -> (park outline)


For the ski-resort:

type=admission
name=Awesome Ski Resort Aerialways and Bar
admission:token=lanyard

poi -> (ski lift 1)
admission -> (ski lift 1)
poi -> (ski lift 2)
admission -> (ski lift 2)
poi -> (guest only après-ski bar)
admission -> (entrance of that bar)
issue -> (ticket shop in the village)
issue -> (ticket machine at summit of mountain)


Would that work?

_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to