<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Once you're out of a comfort zone, you're lost - there are no easy hints or rules how to tag some similar or more general things. You just have to create completely fresh tags and hope other will agree. That is true for seasoned mappers, but even more true for casual ones.<span class=""><br>
<br></span></blockquote><div><br></div><div>that's true, the tagging schema is open, but guidelines might be welcome to extend it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></span><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also look at the reception_desk "classification" problem. Some want to<br>
classify it as amenity, others as a tourism feature. That just depends<br>
on your needs. There isn't always a classification that works for<br>
everyone.<br>
</blockquote>
<br></span>
But we're just mentally caged in a "*=reception_desk schema", so you still have to be sure what class is this object. In my view you could tag it only "reception_desk=yes" if you don't know or care for classification, but you're still able to make it "reception_desk=tourism" for example, if that's what you're sure about. I envision classification as a metadata level - we can still have default one, but outside the GIS database, which would make it easier to extend it if needed (the more objects, the stronger need to have something extendable and with more layers). Others can still use our classification or make their own. Taking the categories outside the database and letting mappers tag only what they are sure is a win-win situation IMO.<span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></span><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll agree that introducing the reception_desk key was/is problematic<br>
because of the choice of the top level tag.<br>
</blockquote>
<br></span>
The need to choose top-level tag for it is the problem itself.</blockquote><div><br></div><div>What's a top level key ? Suppose you drop "shop". Then you get bakery=yes. Is bakery now a top level key ? Is everything acceptable as top level in this new schema ? Won't we have discussions on what is acceptable as top level then ? </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the other hand I do not see why we couldn't tag some of them as<br>
amenity and others as tourism and have both documented. It's pretty<br>
easy for data consumers to support both.<br>
</blockquote>
<br></span>
And what about presets? Will there be two of them?<br></blockquote><div><br></div><div>Why not ? OTOH when there is only 1 preset, people are still free to use a different top level key (and document it), or even make their own preset.</div><div>Maybe we should "demand" that each tagging proposal includes a preset for JOSM and iD, it might also increase acceptance and usage of new tags.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And what about another kind of reception desk we haven't heard of yet? It's easy to believe we already have all the tools for mapping the world just because we know our city/town/village/country in general (or even some other countries to some extent), but this may not be enough in the future.<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree, but you see only the half of the issue. Of course we know just a "compact" version sometimes (like amenity=reception_desk or tourism=reception_desk), but we have no tools to chop it to say it's really "reception_desk=yes + amenity=yes" or "reception_desk=yes + tourism=yes".<br></blockquote><div><br></div><div>Why do you need to specify amenity = yes or tourism = yes  ? What do I learn from that ? Is this for the case that there are 2 reception desks on a property (thinking about a campsite here), where one is used by the tourist and the other for deliveries ?</div><div> </div><div>I still haven't figured out for myself whether top level keys bring a lot of benefits. I suppose they do for building or shop (see e.g. SK53 latest diary entry on shop statistics, which won't be possible with a top-level shop tag).</div><div>But does it help for things "amenity", leisure or tourism, which are really collections of totally different things ? Would they be better off without those top level tags ?</div><div><br></div><div>regards</div><div><br></div><div>m</div></div><br></div></div>