On Sat, 13 Apr 2019 at 00:55, Graeme Fitzpatrick <graemefi...@gmail.com> wrote:
> > On Sat, 13 Apr 2019 at 09:26, Paul Allen <pla16...@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 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
