Re: [Tagging] Proposal for admission=* tag

2020-11-09 Thread Janko Mihelić
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 00:18 Martin Koppenhoefer 
napisao je:

> 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 places to get the ticket there are at least 3 kind: a machine issuing
> tickets, a person where you can buy tickets, or a place where you can get
> tickets which you already reserved or bought before.
>
> All the simpler cases (ticket office within or at the perimeter of the
> POI), we do not really need a relation, a specific tag would be sufficient.
> Sometimes it could be a property of "entrance=*" or barrier=gate objects
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Martin Koppenhoefer
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 places to get the ticket there are at least 3 kind: a machine issuing
tickets, a person where you can buy tickets, or a place where you can get
tickets which you already reserved or bought before.

All the simpler cases (ticket office within or at the perimeter of the
POI), we do not really need a relation, a specific tag would be sufficient.
Sometimes it could be a property of "entrance=*" or barrier=gate objects

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Jeroen Hoek
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 roaming ranger scenario where no ticket shop exists.

You could consider requiring having at least one of those (an
admission:issue:* tag or an admission role member) for a valid relation.

> 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.

That's understandable. How will you handle the theme park with
separately mapped entrances though?

If you omit the entrances from the relation, and these have something
like access=customers, routers won't know that there is an admission
relation with information on where to get tokens/tickets and what it
admits access to. Routers that try to use the admission relation, won't
know that they could offer navigation to the entrances, rather than to
the middle of the POI. Or am I over-thinking this?

If the entrances are role 'admission', and the ticket
office/shop/machine role 'issue', then where do you link the relation to
the park itself?

>>  admission:issue:*
> 
> 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.

Nice. :)

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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
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 your ticket at a shop=ticket (or similar) to ride
> anywhere on the system? Does this apply to those too? What about systems
> where you can buy a ticket on a bus, but the ticket is also good for
> transfers to the light rail or subway stations that require a ticket for
> entry? The answer could be "no, don't use this for entire transit
> systems", but either way, public transit is prominent enough in OSM that
> I think it's worth explicitly addressing it in the proposal (and
> discussing here, if need be).
>

I was thinking about public transit while I wrote this proposal, and I
think it's more or less compatible. I was also thinking about motorways and
vignettes you have to buy at a shop. But I decided to not include those
because it would open a can of worms, and the proposal would never see the
light of day. My plan is to roll out this proposal for simpler use cases,
and if that works, we can apply it to public transport and maybe motorways.

You're right, I'll add a line in the wiki that this shouldn't be used for
public transport or motorway payment for now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Justin Tracey
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
> are close together, but sometimes they are not.
> In those cases, it would be nice that a router could either show us this
> information, or route us to the ticket issuer first, and then to the
> original place we were going to.
> 
> The tags I proposed would be:
> access=admission for the place that needs a ticket
> admission=issue for the place that sells the ticket
> admission:to=* to tag both with the same name, so we can link them, or
> relation type=admission that connects the two places.
> 
> What do you think?
> 
> Janko
> 


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 your ticket at a shop=ticket (or similar) to ride
anywhere on the system? Does this apply to those too? What about systems
where you can buy a ticket on a bus, but the ticket is also good for
transfers to the light rail or subway stations that require a ticket for
entry? The answer could be "no, don't use this for entire transit
systems", but either way, public transit is prominent enough in OSM that
I think it's worth explicitly addressing it in the proposal (and
discussing here, if need be).

 - Justin

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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
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 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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Jeroen Hoek
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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
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?
>
> https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dticket
>
> vending=admission_tickets also has some usage: (189)
>
> https://taginfo.openstreetmap.org/search?q=admission#values
>
> and rarely
> ticket=admission (10 times)
>

I think these are prime candidates for this tag. I think any amenity can be
a place where you get issued a ticket. There could be a restaurant that
gives you keys for the tennis court it owns. I think that is also a case
where you can use this tag. You just add admission:token=keys. That way you
see a tennis court on OsmAnd, click it, and it directs you to the
restaurant, and says you need to get a key.

Although, ticket=admission sounds redundant.

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


Re: [Tagging] Proposal for admission=* tag

2020-10-26 Thread Janko Mihelić
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 should be a
relation with all the turnstiles with role "admission", and all the ticket
offices with role "issue". The amusement park in general doesn't even need
to be in the relation. All the other private entrances should be tagged
access=private or something like that. So the router can only route through
the turnstiles, and then, if it knows how to read the admission relation,
it sees that first you need a ticket.
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.

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?

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.

Does this sound good to you all? Are there more edge cases?

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


Re: [Tagging] Proposal for admission=* tag

2020-10-25 Thread Martin Koppenhoefer
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

vending=admission_tickets also has some usage: (189)

https://taginfo.openstreetmap.org/search?q=admission#values

and rarely
ticket=admission (10 times)


Cheers,
Martin

sent from a phone___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-10-25 Thread Jeroen Hoek
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 venue for which you
> can buy a ticket in any kiosk in town. I would rather tag something like
> that with a admission:name=* than add all kiosks to a relation.

Using relations for the first time is tricky, you are right about that.
But there are a lot of places in OSM where relations are necessary. I
wouldn't worry too much about novice mappers not being able to use them.
Any mapper who can use the wiki to look up keys for a scheme like this
will probably be able to use JOSM to create relations.

When the proposal is settled down on the relation type and roles a
prefix could be created for JOSM to help create such a relation, further
lowering the bar.

I wouldn't be too afraid of large relations, but you might want to add
that the ticket office and the poi should (ideally) be geographically
close-ish (like, within the same city or area). This is similar to what
the site-relation documentation states.

I mentioned this on the wiki as well: it might be nice to add an
optional role to your relation for the actual entrances (e.g.,
turnstiles), in addition to the ticket office and the poi, where tickets
are checked. For something like a theme park these are definitely
mapped, and a clever router could suggest a route going from the ticket
office to an entrance with that data available.

This looks like a useful proposal.

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


Re: [Tagging] Proposal for admission=* tag

2020-10-25 Thread Janko Mihelić
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 is free (e.g. to control the number of people you let in, or
> to get an idea how many people have entered, even if there aren't safety
> reasons).
>

Maybe admission_issuer. But you also need a role for the place you need an
admission for. You probably wanted to add it in a site relation so you
don't have two relations, but I think it would just generate problems.
Maybe I'm wrong. That could be a separate proposal.

If we do this, I would prefer a strong relation between the feature and the
> ticket office, not just by the name, but with explicit links (a relation).
>

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 venue for which you can buy a
ticket in any kiosk in town. I would rather tag something like that with a
admission:name=* than add all kiosks to a relation.

Thanks for your opinion!

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


Re: [Tagging] Proposal for admission=* tag

2020-10-25 Thread Martin Koppenhoefer
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 relation (e.g. "sells_tickets"). Maybe the term "sells" should be
omitted, because sometimes you need a ticket, but it is free (e.g. to
control the number of people you let in, or to get an idea how many people
have entered, even if there aren't safety reasons).

If we do this, I would prefer a strong relation between the feature and the
ticket office, not just by the name, but with explicit links (a relation).

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Proposal for admission=* tag

2020-10-24 Thread Janko Mihelić
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 those cases, it would be nice that a router could either show us this
information, or route us to the ticket issuer first, and then to the
original place we were going to.

The tags I proposed would be:
access=admission for the place that needs a ticket
admission=issue for the place that sells the ticket
admission:to=* to tag both with the same name, so we can link them, or
relation type=admission that connects the two places.

What do you think?

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