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
