pon, 26. lis 2020. u 15:20 Jeroen Hoek <m...@jeroenhoek.nl> 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 where tickets are issued. > 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. For example, your restaurant example, if the restaurant is poi, and one entrance is admission, what if someone adds a second entrance and forgets to add it to the admission relation? Then the system breaks down, and the router routes you through the second entrance. I would keep it simple, and add the whole restaurant as admission. But I'm sure there are examples where a third role would be necessary. I'd like to keep this for a different proposal, and keep it simple for now. 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)). > I like this one. So in addition to relation members with the "issue" role, you can also get the ticket through all the admission:issue:xxx=* ways. I'll add it to the wiki. Janko
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
