Re: [Tagging] Juice restaurants
I'd not choose amenity=cafe if they don't sell besides the juice also coffee. Look how quite specific the other tags are for places where you can drink, eg biergarten, pub, cafe, bar, kiosk, nightclub ... I'm wondering if the way we are coding different places where we can drink or eat is not too specific. May be, we should think about a more general model like: amenity=drink_place/eat_place seat=yes/no indoor/outdoor fast_food=yes/no beverage cuisine operator ... So renderer can easily handle a lot of cases. We can then add a tag to specify local cultural items: drink_place:type=biergarten, pub, cafe, bar, kiosk... but renderer can work without this last tag. My 0,02 Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Juice restaurants
Am 09.05.2013 um 15:20 schrieb Eric Sibert courr...@eric.sibert.fr: I'd not choose amenity=cafe if they don't sell besides the juice also coffee. Look how quite specific the other tags are for places where you can drink, eg biergarten, pub, cafe, bar, kiosk, nightclub ... I'm wondering if the way we are coding different places where we can drink or eat is not too specific. May be, we should think about a more general model like: amenity=drink_place/eat_place seat=yes/no indoor/outdoor fast_food=yes/no beverage cuisine operator … you can argue like this, but then I'd suggest to propose an alternative tagging scheme that is compatible with what we currently do (i.e. you use different keys for the new scheme so the 2 can coexist, don't use amenity). E.g. drinking_in-place=yes, eating_in-place=yes etc. I doubt that we are still that open for fundamental changes in a field that is so widely tagged on a global level (implemented in editors, various maps, etc.). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
This is generally good. One comment: Christopher Hoess wrote: [...] we might also consider whether movable should be under bridge or bridge:type. Placing it in the former would mean patching current renderers (e.g., Mapnik), but placing it in the latter makes specific movable bridge types (e.g., bascule, swing) rather wordy to tag, with three separate keys. It makes more sense to replace: bridge=movable; bridge:movable=swing bridge=movable; bridge:movable=lift bridge=movable; bridge:movable=bascule bridge=movable; bridge:movable=drawbridge bridge=movable; bridge:movable=transporter with simply bridge=swing bridge=lift bridge=bascule bridge=drawbridge bridge=transporter This removes unnecessary duplication, is more memorable (is it 'moveable' or 'movable'...?) and accords with current usage (e.g. 577 occurrences of bridge=swing). cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Bridges-redux-tp5760227p5760348.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
Richard, I included the types of movable bridge in the bridge key in the previous round of my proposal in January, for similar reasons (compatibility, brevity). I made the change based on LM_1's comments ( http://lists.openstreetmap.org/pipermail/tagging/2012-January/009163.html and reiterated on the wiki). Specifically, what made me switch was thinking about renderers, routers, and other consumers of the data. The list of movable bridge types is rather volatile: it's easy to imagine someone coming up with additional types besides the ones I've listed for movable bridges. If all the movable bridge types are filed under bridge, adding a new type will not work with downstream consumers until they've been patched (which seems to be a fairly serious obstacle). Using bridge=movable with bridge:movable is a little more wordy, but it allows renderers to render it as a bridge and routers to recognize that it might open in the middle of the commute, even if it's some exotic type of movable bridge not provided for here. 577 instances isn't that big an installed base, all things considered (and they don't even render properly, right now). movable vs moveable is annoying, but they shouldn't build up too badly as long as someone is regularly sweeping taginfo for the misspelling. I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well. Yours, -- Chris Hoess On Thu, May 9, 2013 at 10:35 AM, Richard Fairhurst rich...@systemed.netwrote: This is generally good. One comment: Christopher Hoess wrote: [...] we might also consider whether movable should be under bridge or bridge:type. Placing it in the former would mean patching current renderers (e.g., Mapnik), but placing it in the latter makes specific movable bridge types (e.g., bascule, swing) rather wordy to tag, with three separate keys. It makes more sense to replace: bridge=movable; bridge:movable=swing bridge=movable; bridge:movable=lift bridge=movable; bridge:movable=bascule bridge=movable; bridge:movable=drawbridge bridge=movable; bridge:movable=transporter with simply bridge=swing bridge=lift bridge=bascule bridge=drawbridge bridge=transporter This removes unnecessary duplication, is more memorable (is it 'moveable' or 'movable'...?) and accords with current usage (e.g. 577 occurrences of bridge=swing). cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Bridges-redux-tp5760227p5760348.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
On 09/05/2013 21:41, Christopher Hoess wrote: I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well. As a renderer developer, I see no problems with Richard's simplification. Renderers should always have a default for unrecognized types, since these are frequent, owing to typos and mappers inventing their own. My view is that the simpler the tagging scheme is, the better. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bridges redux
There are advantages and disadvantages to this. The advantage is, as you point out, you reduce information duplication; there is also the designation of a limited controlled vocabulary which is used as a primary facet. The disadvantage is that the classification of these values as movable is lost from the primary data, meaning that the information relate to all being movable must be sourced from elsewhere. --ceyockey It makes more sense to replace: bridge=movable; bridge:movable=swing bridge=movable; bridge:movable=lift bridge=movable; bridge:movable=bascule bridge=movable; bridge:movable=drawbridge bridge=movable; bridge:movable=transporter with simply bridge=swing bridge=lift bridge=bascule bridge=drawbridge bridge=transporter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
