airport check in counters

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

airport check in counters

Warin
Hi

Airport check in counters don't seem to have any way of mapping these.

As there is usually a number of them it is handy to know there proximate location so your not dragging luggage from one end to the other.

Thoughts?

There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.

Thoughts?

I have used the tag indoor=area, OSMInspector complains that this is not a physical tag...


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Anton Klim
The check in counters are generally quite numerous, so you’d need a detailed indoor map which I’m yet to see for an airport in osm. The wiki aeroways page mentions the undocumented amenity=check_in and security control.

For arrival lounges, I think there were a number of “waiting area” proposals.
Indoor=area is documented in the SIT wiki, validators (and editors/renderers) are generally useless at indoor things.

Ant

> 31/03/2019, 5:50, Warin <[hidden email]>:
>
> Hi
>
> Airport check in counters don't seem to have any way of mapping these.
>
> As there is usually a number of them it is handy to know there proximate location so your not dragging luggage from one end to the other.
>
> Thoughts?
>
> There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.
>
> Thoughts?
>
> I have used the tag indoor=area, OSMInspector complains that this is not a physical tag...
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

dieterdreist
In reply to this post by Warin


sent from a phone

On 31. Mar 2019, at 06:50, Warin <[hidden email]> wrote:

There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.

Thoughts?


there is a proposal for these:


Cheers, Martin 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Warin
In reply to this post by Anton Klim
On 31/03/19 20:19, Anton Klim wrote:

> The check in counters are generally quite numerous, so you’d need a detailed indoor map which I’m yet to see for an airport in osm.

A reason why they are not detailed is there are no tags for them, and then they do not render.
I came across them in the Sydney International Airport (A to K) and in the Hobart Airport .. as named nodes without any other tags.

> The wiki aeroways page mentions the undocumented amenity=check_in and security control.

Thanks. amenity=check_in (in various forms) looks to be > 100 uses according to tag info.

I'll work up a proposal, with options for automated or non_automated check ins.

>
> For arrival lounges, I think there were a number of “waiting area” proposals.
> Indoor=area is documented in the SIT wiki, validators (and editors/renderers) are generally useless at indoor things.

Yep. amenity=waiting_room is used 22 times, but I'd rather have waiting area, sometimes it is not a single room.

>
> Ant
>
>> 31/03/2019, 5:50, Warin <[hidden email]>:
>>
>> Hi
>>
>> Airport check in counters don't seem to have any way of mapping these.
>>
>> As there is usually a number of them it is handy to know there proximate location so your not dragging luggage from one end to the other.
>>
>> Thoughts?
>>
>> There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.
>>
>> Thoughts?
>>
>> I have used the tag indoor=area, OSMInspector complains that this is not a physical tag...
>>
>>
>> _


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Warin
In reply to this post by dieterdreist
On 01/04/19 09:20, Martin Koppenhoefer wrote:


sent from a phone

On 31. Mar 2019, at 06:50, Warin <[hidden email]> wrote:

There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.

Thoughts?


there is a proposal for these:

Thanks!

There should be a way of coordinating these things with the indoor mapping...

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

bkil
When drafting your proposal, please consider that some map indoor
features as nodes, not areas. This is to minimize cost to benefit,
improve overview and enhance maintainability.

Also, I was just considering whether we could unite related features
like ticket booths/ticket check/vending/reception/information
desk/check-in for various places like camp_site, hotel, motel,
guest_house, school, office, mall, community_centre, sports_centre,
events_venue, cinema, theatre, music_venue, nightclub, public
transport, etc.


On Mon, Apr 1, 2019 at 12:47 AM Warin <[hidden email]> wrote:

>
> On 01/04/19 09:20, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 31. Mar 2019, at 06:50, Warin <[hidden email]> wrote:
>
> There are also 'arrival lounges' where people can wait for family/friends arriving. These are less of a problem, but still it would be good to have a method of tagging them.
>
> Thoughts?
>
>
>
> there is a proposal for these:
> https://wiki.openstreetmap.org/wiki/Proposed_features/waiting_area
>
>
> Thanks!
>
> There should be a way of coordinating these things with the indoor mapping...
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Paul Allen
On Fri, 12 Apr 2019 at 10:13, bkil <bkil.hu+[hidden email]> wrote:

Also, I was just considering whether we could unite related features
like ticket booths/ticket check/vending/reception/information
desk/check-in for various places like camp_site, hotel, motel,
guest_house, school, office, mall, community_centre, sports_centre,
events_venue, cinema, theatre, music_venue, nightclub, public
transport, etc.

Such merging may cause problems for (some) editors.  If you can guarantee that all
camp sites, hotels, motels, etc. can potentially have any of ticket booths, vending, check in,
etc. then that's fine.  E.g., if A could have any of X, Y or Z; B could have any of X,  Y or Z;
C can have any of X, Y or Z; etc. that isn't a problem.  The editor's code just handles it as
a list of X, Y and Z can apply to A, B and C

What would be a problem is if A can only have X or Y; B can only have Y or Z; and C can only have
X or Z.  That means special-casing bits of code.  Historically, authors of (some) editors refuse
to support such tagging schemes because it introduces code complexity.

Of course, we can define tags any way we wish.  But unless editors support them, they won't
get used as much as if the editors support them.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Graeme Fitzpatrick


On Fri, 12 Apr 2019 at 21:49, Paul Allen <[hidden email]> wrote:
On Fri, 12 Apr 2019 at 10:13, bkil <bkil.hu+[hidden email]> wrote:

Also, I was just considering whether we could unite related features
like ticket booths/ticket check/vending/reception/information
desk/check-in for various places like camp_site, hotel, motel,
guest_house, school, office, mall, community_centre, sports_centre,
events_venue, cinema, theatre, music_venue, nightclub, public
transport, etc.

You could probably get away with classifying almost all of those as check_in, or maybe reception? For most of those venues, though,"reception" would be immediately inside the front door, so there wouldn't really be a need to show where it is.

An exception to that would be airports, where your ticket desk/s can be located almost anywhere, & you'd then also have to specify that this is the check-in for Airline A, that one is Airline B & so on

Such merging may cause problems for (some) editors.  If you can guarantee that all
camp sites, hotels, motels, etc. can potentially have any of ticket booths, vending, check in,
etc. then that's fine.  E.g., if A could have any of X, Y or Z; B could have any of X,  Y or Z;
C can have any of X, Y or Z; etc. that isn't a problem.  The editor's code just handles it as
a list of X, Y and Z can apply to A, B and C

What would be a problem is if A can only have X or Y; B can only have Y or Z; and C can only have
X or Z.

Yes, we see this with some of the camping grounds we regularly go to. Some have offices / kiosks, where you check in on arrival; some have no check in requirements at all - you just arrive, pick a (unmarked) spot & set up; while others have to be booked online before you go.

These could probably all be covered by check_in=yes / no / online_only, possibly together with a bookings=(url)?

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Warin
There are 457 uses of booking=* in the data base. I have used it on camping sites that require seasonal booking.
https://wiki.openstreetmap.org/wiki/Key%3Abooking

Humm reception and checkin as the same?

I did propose amenity=reception .. failed as some did not want it as amenity ... I use it.

Should I use it for check in? Possibly.
So amenity=reception for airport check ins.. ??? Any other ideas?


On 13/04/19 08:40, Graeme Fitzpatrick wrote:


On Fri, 12 Apr 2019 at 21:49, Paul Allen <[hidden email]> wrote:
On Fri, 12 Apr 2019 at 10:13, bkil <bkil.hu+[hidden email]> wrote:

Also, I was just considering whether we could unite related features
like ticket booths/ticket check/vending/reception/information
desk/check-in for various places like camp_site, hotel, motel,
guest_house, school, office, mall, community_centre, sports_centre,
events_venue, cinema, theatre, music_venue, nightclub, public
transport, etc.

You could probably get away with classifying almost all of those as check_in, or maybe reception? For most of those venues, though,"reception" would be immediately inside the front door, so there wouldn't really be a need to show where it is.

An exception to that would be airports, where your ticket desk/s can be located almost anywhere, & you'd then also have to specify that this is the check-in for Airline A, that one is Airline B & so on

Such merging may cause problems for (some) editors.  If you can guarantee that all
camp sites, hotels, motels, etc. can potentially have any of ticket booths, vending, check in,
etc. then that's fine.  E.g., if A could have any of X, Y or Z; B could have any of X,  Y or Z;
C can have any of X, Y or Z; etc. that isn't a problem.  The editor's code just handles it as
a list of X, Y and Z can apply to A, B and C

What would be a problem is if A can only have X or Y; B can only have Y or Z; and C can only have
X or Z.

Yes, we see this with some of the camping grounds we regularly go to. Some have offices / kiosks, where you check in on arrival; some have no check in requirements at all - you just arrive, pick a (unmarked) spot & set up; while others have to be booked online before you go.

These could probably all be covered by check_in=yes / no / online_only, possibly together with a bookings=(url)?

Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Paul Allen
In reply to this post by Graeme Fitzpatrick
On Fri, 12 Apr 2019 at 23:41, Graeme Fitzpatrick <[hidden email]> wrote:
Yes, we see this with some of the camping grounds we regularly go to. Some have offices / kiosks, where you check in on arrival; some have no check in requirements at all - you just arrive, pick a (unmarked) spot & set up; while others have to be booked online before you go.

These could probably all be covered by check_in=yes / no / online_only, possibly together with a bookings=(url)?

I expressed myself badly.  iD can come up with some multi-choice mechanism for check_in, just
as it does with car servicing types.  Not a problem.  The problem is when airport checkins can
be any (or all) of A, B, C and D but camping ground checkins can be any (or all) of D, E and F.

The easy fix is to offer A, B, C, D, E and F for check_in=*,  But that means people could (and
inevitably will) choose E and F for airport checkins where they don't apply and chose A, B and
C for camping ground checkins where those don't apply.  Because the list they're offered has
all of the options (and therefore, they think, all are applicable).  Nobody wants that.  But extra
code (harder to maintain) is involved in only offering the right values for check_in=* depending
on the main key (or, far harder still, on the main key of the enclosing area).

Hence namespacing.  Then the list of offered values for camp_site:check_in (or whatever it
gets called) is D, E and F; the list of offered values for airport:check_in (or whatever) is
A, B, C and D.  If you really insist, you can type anything you want into the value, but you'll
be offered the appropriate preferred values, and are less likely to get it wrong.

Only if you can guarantee that the same set of values for check_in=* will be appropriate for
all circumstances (and for all time) where it will be used can you avoid having to namespace.
With check_in=* you can probably do that.  With some of the others you probably can't.

At least that's what I understood the reasoning to be the last time the lead programmer of iD
had things to say about covered=* and phone booths.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Joseph Eisenberg
In reply to this post by Warin
For campgrounds, campsites and tourism=caravan_site the most commonly used tag is camp_site=reception, over 1000 uses but it was only part of an old proposal.

On Sat, Apr 13, 2019 at 8:01 AM Warin <[hidden email]> wrote:
There are 457 uses of booking=* in the data base. I have used it on camping sites that require seasonal booking.
https://wiki.openstreetmap.org/wiki/Key%3Abooking

Humm reception and checkin as the same?

I did propose amenity=reception .. failed as some did not want it as amenity ... I use it.

Should I use it for check in? Possibly.
So amenity=reception for airport check ins.. ??? Any other ideas?


On 13/04/19 08:40, Graeme Fitzpatrick wrote:


On Fri, 12 Apr 2019 at 21:49, Paul Allen <[hidden email]> wrote:
On Fri, 12 Apr 2019 at 10:13, bkil <bkil.hu+[hidden email]> wrote:

Also, I was just considering whether we could unite related features
like ticket booths/ticket check/vending/reception/information
desk/check-in for various places like camp_site, hotel, motel,
guest_house, school, office, mall, community_centre, sports_centre,
events_venue, cinema, theatre, music_venue, nightclub, public
transport, etc.

You could probably get away with classifying almost all of those as check_in, or maybe reception? For most of those venues, though,"reception" would be immediately inside the front door, so there wouldn't really be a need to show where it is.

An exception to that would be airports, where your ticket desk/s can be located almost anywhere, & you'd then also have to specify that this is the check-in for Airline A, that one is Airline B & so on

Such merging may cause problems for (some) editors.  If you can guarantee that all
camp sites, hotels, motels, etc. can potentially have any of ticket booths, vending, check in,
etc. then that's fine.  E.g., if A could have any of X, Y or Z; B could have any of X,  Y or Z;
C can have any of X, Y or Z; etc. that isn't a problem.  The editor's code just handles it as
a list of X, Y and Z can apply to A, B and C

What would be a problem is if A can only have X or Y; B can only have Y or Z; and C can only have
X or Z.

Yes, we see this with some of the camping grounds we regularly go to. Some have offices / kiosks, where you check in on arrival; some have no check in requirements at all - you just arrive, pick a (unmarked) spot & set up; while others have to be booked online before you go.

These could probably all be covered by check_in=yes / no / online_only, possibly together with a bookings=(url)?

Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Graeme Fitzpatrick
In reply to this post by Warin

On Sat, 13 Apr 2019 at 09:01, Warin <[hidden email]> wrote:
There are 457 uses of booking=* in the data base. I have used it on camping sites that require seasonal booking.
https://wiki.openstreetmap.org/wiki/Key%3Abooking

& the discussion page there suggests using reservation=, which has 2800 uses!
 
Humm reception and checkin as the same?

Could be?

Let's face it - there are half a dozen (more?) words that all mean much the same thing for "the spot you have to go to when you arrive at this place", as well as another handful for "how do I make sure I can visit here when I want to" & we're never going to get everyone using the same word!

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Graeme Fitzpatrick
In reply to this post by Paul Allen

On Sat, 13 Apr 2019 at 09:26, Paul Allen <[hidden email]> wrote:

Thanks, Paul - sort of understand where you're coming from, but it's complicated, & as I mentioned ^, probably unsolvable?

At least that's what I understood the reasoning to be the last time the lead programmer of iD
had things to say about covered=* and phone booths.

Yes, I remember that discussion, & gave up on it because I just kept getting more & more confused :-)

& I still don't know whether a phone in a booth, which is outside, is covered or not! (nor what a K6 or KX100 booth is, & regardless of what it is, it's meaningless to me marking public phones here in Oz!) :-)

Thanks

Graeme


--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

bkil
In reply to this post by Graeme Fitzpatrick
First, excuse me for side tracking this topic so much. What inspired
me was a recent discussion we had here:

https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_camp_site#Why_not_use_amenity.3Dreception_desk_instead_of_camp_site.3Dreception.3F

I'll try to gather my thoughts someday soon and maybe we could come up
with a proposal for all of these, I'd not want to block $SUBJECT until
we come to a resolution, as we can rename tags later on.

Let me answer the original airport question at hand. Let me reiterate
that I recommend naming tags so that they make sense for both nodes
and areas. Most of the world is using non-area based indoor mapping as
of now.

* Check-in counters: yes! Also include their count and whether there
are any restrictions between the different counters (with/without
bags, online only, etc).

* Arrival lounge (arrivals door): definitely! I'd probably map benches
as a separate feature, because they can be used for multiple purposes,
but knowing where someone will arrive that you are waiting for is a
big plus, so you can stay nearby.

Let me add some requests of my own:

* Luggage size measurement racks/weighing that let's you double check
your luggage before check-in so you don't get turned back after
staying in line for half an hour. Probably two separate features, or
just attributes on a general verification instrument (you can see such
in supermarkets as well for weight and price verification).

* Gates where you queue up after check-in, but before departure where
they are screening you. Only checked-in passengers may attend this
queue, so this is the point of saying goodbye.

* A gathering point outside on restricted grounds where you have to
wait before entering the plane (for low cost carriers).

* A spotter terrace (viewpoint) where you can watch incoming or
departing planes, can also be annotated with fee=*,
covered=*/shelter=*, level=*, capacity=*, direction=*, bench=*,
whether tables are present, etc.

On Sat, Apr 13, 2019 at 1:39 AM Graeme Fitzpatrick
<[hidden email]> wrote:

>
>
> On Sat, 13 Apr 2019 at 09:01, Warin <[hidden email]> wrote:
>>
>> There are 457 uses of booking=* in the data base. I have used it on camping sites that require seasonal booking.
>> https://wiki.openstreetmap.org/wiki/Key%3Abooking
>
>
> & the discussion page there suggests using reservation=, which has 2800 uses!
>
>>
>> Humm reception and checkin as the same?
>
>
> Could be?
>
> Let's face it - there are half a dozen (more?) words that all mean much the same thing for "the spot you have to go to when you arrive at this place", as well as another handful for "how do I make sure I can visit here when I want to" & we're never going to get everyone using the same word!
>
> Thanks
>
> Graeme
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Paul Allen
In reply to this post by Graeme Fitzpatrick
On Sat, 13 Apr 2019 at 00:55, Graeme Fitzpatrick <[hidden email]> wrote:

On Sat, 13 Apr 2019 at 09:26, Paul Allen <[hidden email]> wrote:

Thanks, Paul - sort of understand where you're coming from, but it's complicated, & as I mentioned ^, probably unsolvable?

Namespacing is guaranteed to fix it.  The only thing is that in some (not all) cases namespacing
might be overkill.  Not wrong, just unnecessary.  So check_in=* might be suitable for all the
cases we have now and will have in the future, but camp_site:check_in=* (and airport:check_in
and all the rest) will never be wrong whereas at some future date check_in=* could be a problem.

It's not just editors but also overpass-turbo queries.  You want to search for airport checkins but
with check_in=* you'll get camp site and hotel checkins too.  I don't think overpass-turbo has
a mechanism for requesting check_in=* within the boundary of some other object (I could be
wrong) but if it did then it would be computationally expensive.  Possibly very expensive if
there's a naked check_in=* and it ends up expanding the search for the enclosing feature until
it covers the whole world (or hits whatever bounding box you chose).  You could solve that
with a relation, but that's asking a lot of many mappers who don't understand or use
relations for anything.  Namespacing solves that problem (transparently if the editors
support the tag).

We don't define tags, we just advise people thinking about proposing a tag what might get
enough votes to be approved.  We tend to concentrate on syntax, semantics and existing
usage, but we also need to consider both the editor authors and the carto authors.  No matter
how good our ideas, no matter how massive the vote, if the editor authors refuse to implement
it or the carto guys refuse to render it then it's not going to be used.  The carto guys may change
their minds if it gets used often enough, but the editor guys tend to be harder to persuade
because the code required gets messy.

At least that's what I understood the reasoning to be the last time the lead programmer of iD
had things to say about covered=* and phone booths.

Yes, I remember that discussion, & gave up on it because I just kept getting more & more confused :-)

It boiled down to the fact that  covered=* was originally conceived for things like colonnades and
arcades.  So iD presents a choice of "yes", "arcade" and "colonnade."  Then somebody decided
to use covered=* for phone booths - it seemed sensible to re-use the tag in that way.  But that
meant, in iD, that when you added a public telephone, the options included colonnade and arcade
(because it's extra, fiddly code to make it handle phones differently from other objects).

Without considering editors, semantic re-use of tags seems sensible (it doesn't require more
fields in a database table).  But when editors are involved, doing that means that buildings
and phones get choices for covered that are "yes", "arcade", "colonnade".  And
then people choose the wrong value on the basis of "If it's not an appropriate value for this
object then it wouldn't be in the list."

& I still don't know whether a phone in a booth, which is outside, is covered or not!

In the options presented by iD, it's not covered.  You can manually add covered=whatever to a
phone booth, but it's not something iD offers you.  In plain English semantics a phone booth
is covered, but in OSM tagging (as envisaged by iD) the fact that it is in a booth implies it is
covered (I've never seen an open-topped booth) and covered=* is unnecessary.

(nor what a K6 or KX100 booth is, & regardless of what it is, it's meaningless to me marking public phones here in Oz!) :-)

K6, KX1000, et al. are models of UK phone booth.  https://en.wikipedia.org/wiki/Red_telephone_box
Only phone booth fetishists can identify many of the models accurately. :)  It would be feasible to
add models for other countries, with the problem of overlaps (if there's an Oz K6 that's different
from a UK K6).  Maybe we should namespace model values, so UK:K6 and AU:K6, but it's
probably sufficient to rely on the fact that you'll only see UK K6s in the UK and not Belgian K6s,
so the geographic position on the map resolves any ambiguities.

--
Paul



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

bkil
In reply to this post by Graeme Fitzpatrick
I haven't followed the said discussion, but I can see how some may see
covered=* as an indication whether certain circumstances result in the
said feature being protected from the elements. So I guess shelter=*
should be used for telephone=* instead of covered, or a new
telephone:construction=open/covered/booth/... should be introduced.

Also, I don't quite like the semantics of covered=booth at all, as
covered=* is used in other meaning with other possible values with
other POI.

On Sat, Apr 13, 2019 at 1:55 AM Graeme Fitzpatrick
<[hidden email]> wrote:

>
>
> On Sat, 13 Apr 2019 at 09:26, Paul Allen <[hidden email]> wrote:
>
> Thanks, Paul - sort of understand where you're coming from, but it's complicated, & as I mentioned ^, probably unsolvable?
>
>> At least that's what I understood the reasoning to be the last time the lead programmer of iD
>> had things to say about covered=* and phone booths.
>
>
> Yes, I remember that discussion, & gave up on it because I just kept getting more & more confused :-)
>
> & I still don't know whether a phone in a booth, which is outside, is covered or not! (nor what a K6 or KX100 booth is, & regardless of what it is, it's meaningless to me marking public phones here in Oz!) :-)
>
> Thanks
>
> Graeme
>
>>
>> --
>> Paul
>>
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

bkil
In reply to this post by Paul Allen
On Sat, Apr 13, 2019 at 3:25 PM Paul Allen <[hidden email]> wrote:

> Namespacing is guaranteed to fix it.  The only thing is that in some (not all) cases namespacing
> might be overkill.  Not wrong, just unnecessary.  So check_in=* might be suitable for all the
> cases we have now and will have in the future, but camp_site:check_in=* (and airport:check_in
> and all the rest) will never be wrong whereas at some future date check_in=* could be a problem.
>
> It's not just editors but also overpass-turbo queries.  You want to search for airport checkins but
> with check_in=* you'll get camp site and hotel checkins too.  I don't think overpass-turbo has
> a mechanism for requesting check_in=* within the boundary of some other object (I could be
> wrong) but if it did then it would be computationally expensive.  Possibly very expensive if
> there's a naked check_in=* and it ends up expanding the search for the enclosing feature until
> it covers the whole world (or hits whatever bounding box you chose).  You could solve that
> with a relation, but that's asking a lot of many mappers who don't understand or use
> relations for anything.  Namespacing solves that problem (transparently if the editors
> support the tag).
>

check_in=airport/camp_site/hotel/hospital/seaport/event_venue/...
would work around this issue as well, wouldn't it?

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Paul Allen

On Sat, 13 Apr 2019 at 14:44, bkil <bkil.hu+[hidden email]> wrote:

check_in=airport/camp_site/hotel/hospital/seaport/event_venue/...
would work around this issue as well, wouldn't it?
 
To some extent.  It's possible to conceive of situations where it wouldn't.  Maybe not for
check_in itself but some of the other tags where people said namespacing was unnecessary.

What if the airport checkin handles both the hotel and the flights?  What if the place is a nexus
of airport and seaport sharing a common checkin?  Semicolons can be used but they are
thought by some to be problematic in the way some data consumers handle them.

Also the user interface would be more error-prone.  In iD with namespacing you'd type "check in"
into the search box and be shown a list of large(ish) icons labelled "airport checkin", "hospital
checkin" etc.  But with a list of values for a checkin=* tag  you get just text and it's a lot easier to
click on the wrong one by mistake.

But yes, it's an alternative to namespacing.  And preferable to having check_in=yes for all types
of checkin.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

Michael Patrick
In reply to this post by Warin
> check_in=airport/camp_site/hotel/hospital/seaport/event_venue/...
> would work around this issue as well, wouldn't it?

The interface where interaction between the business and public customers occur is generically labeled as 'customer service' points. There are some common activities for all like taking money and others that are common to a specific domain ( hospitality / merchandising / entertainment ) and a few that are perhaps very specific to a particular business.

For hospitality,  hotel's customer service point(s) would handle activities like inquiry, reservations, shuttle pickup, then luggage, registration, room assignment, issuing keys, then transport, currency, guest services, food, and then, payment, checkout, and shuttle again, etc. A very small establishment would have one person doing all these, a resort might have entire departments dedicated to each function.

The most adaptable scheme that would work across multiple domains would, at the top level in minimal form, would be a customer service point, and at the most detailed bottom level would be the groups of atomic activities ( accounts: refunds, payment, credit, rewards, currency exchange ). Hospitality has five groups: reservations, reception, guest services, accounts, and communications ( like the switchboard ). Note that going forward, many of these service will be 'online only' - our state campgrounds are online reservations, and AirB&B and their ilk subsume many of the atomic activities. Flexibility is needed because of scale, the atomic customer services activities may be spread across square miles at the larger resorts, not confined to a lobby.

You can find the upper level domains at https://www.bls.gov/iag/tgs/iag_index_naics.htm   Leisure and Hospitality/Accommodation and Food Services (NAICS 72) / Accommodation (NAICS 721) has three domains which will probably share the same general terminology around customer service points within that category:

  • Traveler Accommodation: NAICS 7211
  • RV (Recreational Vehicle) Parks and Recreational Camps: NAICS 7212
  • Rooming and Boarding Houses: NAICS 7213
If you look at the Occupations for these categories ( Hotel, motel, and resort desk clerks ) which support customer service points on Onet, you will find the 'Tasks' ( atomic activities)  they perform at those points: https://www.onetonline.org/link/summary/43-4081.00
( note the " 5 of 20 displayed" and expand the list ):
  • Greet, register, and assign rooms to guests of hotels or motels. 
  • Issue room keys and escort instructions to bellhops. 
  • Make and confirm reservations. 
  • Verify customers' credit, and establish how the customer will pay for the accommodation. 
  • Compute bills, collect payments, and make change for guests.
Most of these can be conflated with others, or considerably shortened and simplified. It does give you the superset of activities that occur for that category of establishment ( domain ) for a tagging scheme, rather than incrementally ad hoc adding new tags over the years as folks decide they need more or less detail. Internationally, there are crosswalks between the USA references and the coding schemes used in the rest of the world, if one wants to localize, but the differences are mostly at the level of distinguishing 'leaf tea' from 'bubble tea'.

Michael Patrick
Data Ferret
 



Michael Patrick



Virus-free. www.avast.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: airport check in counters

dieterdreist
In reply to this post by bkil


sent from a phone

> On 13. Apr 2019, at 15:21, bkil <[hidden email]> wrote:
>
> * Check-in counters: yes! Also include their count and whether there
> are any restrictions between the different counters (with/without
> bags, online only, etc).


I am also supporting the idea of specific proposed tags for airport checkin counters, ref would probably be an important property. Not sure how often the airlines change counters, but probably not that often.
(operator?)


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12