Re: [Tagging] airport check in counters

[Warin]

On 15/04/19 06:35, Martin Koppenhoefer wrote:


sent from a phone


On 13. Apr 2019, at 15:21, bkil  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.


The airline may change counters from time to time(not often) but the ref would 
not change .. well not here as they are labelled A, B, C etc... in sequence.


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

Re: [Tagging] airport check in counters

[Martin Koppenhoefer]

sent from a phone

> On 13. Apr 2019, at 15:21, bkil  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Michael Patrick]

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

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Paul Allen]

On Sat, 13 Apr 2019 at 14:44, bkil  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[bkil]

On Sat, Apr 13, 2019 at 3:25 PM Paul Allen  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[bkil]

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
 wrote:
>
>
> On Sat, 13 Apr 2019 at 09:26, Paul Allen  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
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] airport check in counters

[Paul Allen]

On Sat, 13 Apr 2019 at 00:55, Graeme Fitzpatrick 
wrote:

>
> On Sat, 13 Apr 2019 at 09:26, Paul Allen  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[bkil]

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
 wrote:
>
>
> On Sat, 13 Apr 2019 at 09:01, Warin <61sundow...@gmail.com> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] airport check in counters

[Graeme Fitzpatrick]

On Sat, 13 Apr 2019 at 09:26, Paul Allen  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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Graeme Fitzpatrick]

On Sat, 13 Apr 2019 at 09:01, Warin <61sundow...@gmail.com> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Joseph Eisenberg]

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 <61sundow...@gmail.com> 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  wrote:
>
>> On Fri, 12 Apr 2019 at 10:13, bkil  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 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> 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] airport check in counters

[Paul Allen]

On Fri, 12 Apr 2019 at 23:41, Graeme Fitzpatrick 
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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 > wrote:


On Fri, 12 Apr 2019 at 10:13, bkil http://bkil.hu>+a...@gmail.com > 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] airport check in counters

[Graeme Fitzpatrick]

On Fri, 12 Apr 2019 at 21:49, Paul Allen  wrote:

> On Fri, 12 Apr 2019 at 10:13, bkil  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Paul Allen]

On Fri, 12 Apr 2019 at 10:13, bkil  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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 <61sundow...@gmail.com> wrote:
>
> On 01/04/19 09:20, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 31. Mar 2019, at 06:50, Warin <61sundow...@gmail.com> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] airport check in counters

[Warin]

On 01/04/19 09:20, Martin Koppenhoefer wrote:



sent from a phone

On 31. Mar 2019, at 06:50, Warin <61sundow...@gmail.com 
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Warin]

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 <61sundow...@gmail.com>:

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

[Martin Koppenhoefer]

sent from a phone

> On 31. Mar 2019, at 06:50, Warin <61sundow...@gmail.com> 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


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

Re: [Tagging] 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 <61sundow...@gmail.com>:
> 
> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging