> > > 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. > > that's true, the tagging schema is open, but guidelines might be welcome to extend it.
> >> Also look at the reception_desk "classification" problem. Some want to >> classify it as amenity, others as a tourism feature. That just depends >> on your needs. There isn't always a classification that works for >> everyone. >> > > 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. > >> >> I'll agree that introducing the reception_desk key was/is problematic >> because of the choice of the top level tag. >> > > The need to choose top-level tag for it is the problem itself. 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 ? > > On the other hand I do not see why we couldn't tag some of them as >> amenity and others as tourism and have both documented. It's pretty >> easy for data consumers to support both. >> > > And what about presets? Will there be two of them? > 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. 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. > > 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. > > 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". > 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 ? 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). 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 ? regards m
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
