[Tagging] airport check in counters
pla16021 at gmail.com
Sat Apr 13 13:24:21 UTC 2019
On Sat, 13 Apr 2019 at 00:55, Graeme Fitzpatrick <graemefitz1 at gmail.com>
> On Sat, 13 Apr 2019 at 09:26, Paul Allen <pla16021 at gmail.com> 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 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
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
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
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
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
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".
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.
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,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging