I think there would be room for such POI specialization in Hungary as well (menza/cafeteria, kifőzde/étkezde, csárda, kisvendéglő, fogadó, kávéház/kávézó, bisztró, pince, romkocsma).
Although, I may not be catching the gist here, based on the concept of not including values in key names, should it be restaurant:type=it:ristorente;it:pizzeria instead? Or is this a translatable key, so we could add the equivalent restaurant:type:hu=étterem;pizzéria in there as well along all other translations? That sounds a bit redundant. But basically yes, that could work, *if* we could find something to specialize under. If we specialized sit-in "cukrászda" under "café/kávéház", should we also create a "virtual" category under café named "real kávéház"? That sounds like a bit involved. Specializing the takeaway "cukrászda" under something close to "pastry" may or may not work, depending on whether non-artisan pastry shops are common outside Hungary and if they could lead to confusion or not. We also have places whose names implicate "mixed" function around here, like "Étterem & pizzéria", "Étterem & cukrászda", "Cukrászda & fagyizó", "Kávéház & cukrászda", "Kávézó & pékség", but in most cases it is easy to determine the main function on a survey, most of the time even from their website (most often restaurant, cukrászda, cukrászda, cukrászda and café respectively, although the last one could actually turn out to be indeed both a café and a bakery at the same site). However, I'm not quite comfortable with someone adding a specific combination of top level tags to convey a new kind of function regardless of how similar the synthesis result might sound like unless the meaning of the independent tags can stand on their own on the given POI and be valid. For example I've seen something in Austria that looked like a cukrászda being tagged amenity=café + shop=bakery (probably based on the name). In general, if a data user that does not interpret this combination specially only wanted to search for cafés, returning this could be misleading as mentioned in the previous mail. If, on the other hand it wanted to find all bakeries (to purchase bread or kifli for example), the user would again be disappointed because such places most often only keep fancy bakery products, not staple ones. On Sun, Jun 28, 2020 at 4:09 PM Martin Koppenhoefer <[email protected]> wrote: > > > > sent from a phone > > On 28. Jun 2020, at 15:58, bkil <[email protected]> wrote: > > We are leaning towards being dissatisfied with tagging as either > shop=pastry or amenity=cafe. > > > > today I think I would prefer a generic descriptive term as the main tag (e.g. > shop=sweet_bakery) and have subtags for specilizations or product categories. > > Another (general) issue are “mixed” places like “Bäckerei Konditorei Cafe” or > “Bar Pasticceria Gelateria Tavola Calda”, as the individual classes often > tend to use the same key. > One way I am paying tribute to these is the > restaurant:type:it tag, which gets multiple (slightly “normalized”) values in > the local (here Italian) language: > https://taginfo.openstreetmap.org/keys/restaurant%3Atype%3Ait > > These can be quite useful for people speaking the language and familiar with > the local expectations, and might eventually be transformed to more specific > detail tags later (not holding my breath for it). > > > Cheers Martin _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
