<div dir="ltr"><div dir="ltr">On Sat, 13 Apr 2019 at 00:55, Graeme Fitzpatrick <<a href="mailto:graemefitz1@gmail.com">graemefitz1@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail-m_-9079846561259199126gmail_signature"><div dir="ltr"><div dir="ltr">On Sat, 13 Apr 2019 at 09:26, Paul Allen <<a href="mailto:pla16021@gmail.com" target="_blank">pla16021@gmail.com</a>> wrote:<br></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div><div class="gmail_attr">Thanks, Paul - sort of understand where you're coming from, but it's complicated, & as I mentioned ^, probably unsolvable?</div></div></div></blockquote><div><br></div><div>Namespacing is guaranteed to fix it.  The only thing is that in some (not all) cases namespacing</div><div>might be overkill.  Not wrong, just unnecessary.  So check_in=* might be suitable for all the</div><div>cases we have now and will have in the future, but camp_site:check_in=* (and airport:check_in</div><div>and all the rest) will never be wrong whereas at some future date check_in=* could be a problem.<br></div><div><br></div><div>It's not just editors but also overpass-turbo queries.  You want to search for airport checkins but</div><div>with check_in=* you'll get camp site and hotel checkins too.  I don't think overpass-turbo has</div><div>a mechanism for requesting check_in=* within the boundary of some other object (I could be</div><div>wrong) but if it did then it would be computationally expensive.  Possibly very expensive if</div><div>there's a naked check_in=* and it ends up expanding the search for the enclosing feature until</div><div>it covers the whole world (or hits whatever bounding box you chose).  You could solve that</div><div>with a relation, but that's asking a lot of many mappers who don't understand or use</div><div>relations for anything.  Namespacing solves that problem (transparently if the editors</div><div>support the tag).<br></div><div><br></div><div>We don't define tags, we just advise people thinking about proposing a tag what might get</div><div>enough votes to be approved.  We tend to concentrate on syntax, semantics and existing</div><div>usage, but we also need to consider both the editor authors and the carto authors.  No matter</div><div>how good our ideas, no matter how massive the vote, if the editor authors refuse to implement</div><div>it or the carto guys refuse to render it then it's not going to be used.  The carto guys may change</div><div>their minds if it gets used often enough, but the editor guys tend to be harder to persuade</div><div>because the code required gets messy.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">At least that's what I understood the reasoning to be the last time the lead programmer of iD<br></div><div class="gmail_quote"><div>had things to say about covered=* and phone booths.</div></div></div></blockquote><div><br></div><div>Yes, I remember that discussion, & gave up on it because I just kept getting more & more confused :-)</div></div></div></blockquote><div><br></div><div>It boiled down to the fact that  covered=* was originally conceived for things like colonnades and</div><div>arcades.  So iD presents a choice of "yes", "arcade" and "colonnade."  Then somebody decided</div><div>to use covered=* for phone booths - it seemed sensible to re-use the tag in that way.  But that</div><div>meant, in iD, that when you added a public telephone, the options included colonnade and arcade</div><div>(because it's extra, fiddly code to make it handle phones differently from other objects).<br></div><div><br></div><div>Without considering editors, semantic re-use of tags seems sensible (it doesn't require more</div><div>fields in a database table).  But when editors are involved, doing that means that buildings</div><div>and phones get choices for covered that are "yes", "arcade", "colonnade".  And</div><div>then people choose the wrong value on the basis of "If it's not an appropriate value for this</div><div>object then it wouldn't be in the list." <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>& I still don't know whether a phone in a booth, which is outside, is covered or not!</div></div></div></blockquote><div><br></div><div>In the options presented by iD, it's not covered.  You can manually add covered=whatever to a</div><div>phone booth, but it's not something iD offers you.  In plain English semantics a phone booth</div><div>is covered, but in OSM tagging (as envisaged by iD) the fact that it is in a booth implies it is</div><div>covered (I've never seen an open-topped booth) and covered=* is unnecessary.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> (nor what a K6 or KX100 booth is, & regardless of what it is, it's meaningless to me marking public phones here in Oz!) :-)</div></div></div></blockquote><div><br></div><div>K6, KX1000, et al. are models of UK phone booth.  <a href="https://en.wikipedia.org/wiki/Red_telephone_box">https://en.wikipedia.org/wiki/Red_telephone_box</a></div><div>Only phone booth fetishists can identify many of the models accurately. :)  It would be feasible to</div><div>add models for other countries, with the problem of overlaps (if there's an Oz K6 that's different</div><div>from a UK K6).  Maybe we should namespace model values, so UK:K6 and AU:K6, but it's</div><div>probably sufficient to rely on the fact that you'll only see UK K6s in the UK and not Belgian K6s,</div><div>so the geographic position on the map resolves any ambiguities.</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div><div><br></div></div></div>