Re: [Tagging] Feature proposal - RFC - Location transitions
On Fri, 14 Aug 2015 00:09:53 +0200 François Lacombe wrote: > There are no specific values to keep it simple to use. > Nevertheless it can be completed to match specific needs. I am not convinced that it is a good idea, it will probably result in a complete mess off unusable data. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
> On Aug 14, 2015, at 9:47 AM, Warin <61sundow...@gmail.com> wrote: > > shop=scale_model > vending:scale_model:kits=yes > vending:scale_model:parts=yes (as in selling parts/materials to make a scale > model) accessories, tools, consumables, supplies… supplies might be a good word that can be used in other things. If we do this, we should have an open call on the tagging board to have people submit the values for shops that are not standard car parts, DIY shops, and fruit stands. I was mentioning a “wooden home goods shop” in Japan. Similar to a knife shop, they have “edge tool” shops - anything that needs sharpening, from knives, to chisels, axes, and gardent tools. Pocket knives to saws. That way we can have a good list of sub-values for taggers to build on. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
On 14/08/2015 10:02 AM, Ruben Maes wrote: On Friday 14 August 2015 09:46:00 Warin wrote: Hi, This follows from the shop=model discussion I raised a while ago. Marczoutendijk diary https://www.openstreetmap.org/user/marczoutendijk/diary/35584 demonstrates the issue that occurs with shop= ... I think one way to 'solve' this is to have a free text entry sub key for shops... say a key of shop_products. In this way shop= values don't have to carry all the detail leading to possibly millions of values. Rather shop= values can be a collective value without the specific detail, making them easier to distinguish by separate rendering icons. If detail is required then the free text entry can be interrogated. Examples shop=food shop_products=cheese, bread, fruit, vegetables shop=scale_model shop_products=kits, ready made, materials shop=bicycle shop_products=new, second hand, service Thoughts?? vending comes to mind, it is defined as being for vending machines. In any case, you should use semi-colons to separate multiple values. And semi-colon separated lists (here we go again) should be avoided (especially in new tagging schemes) in favour of namespaced tags. I vaguely remember an argument for things like vending:food:bread=yes. So, in combination with duck tagging, a shop selling mainly fruit and vegs would become something like shop=grocery vending:bread=yes vending:cheese=yes vending:fruit=yes vending:vegetables=yes And the scale model shop shop=model vending:scale_model_kits=yes service:scale_model:repair=yes (following the bicycle scheme) second_hand=yes (that is an approved tag: https://wiki.openstreetmap.org/wiki/Key:second_hand) Errr I'm using scale_model to distinguish it from models used to display/demonstrate clothing (or the lack of clothing). So; shop=scale_model vending:scale_model:kits=yes vending:scale_model:parts=yes (as in selling parts/materials to make a scale model) shop=scale_model vending:scale_model:railway:kits=yes vending:scale_model:train:ready_made=yes vending:scale_model:railway:parts=yes Something like that? For bicycle shops, there are already tags to describe this, see https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle. It does not really follow your idea .. e.g. service:bicycle:retail=yes service:bicycle:second_hand=yes to follow your idea .. should be vending:bicycle=yes vending:bicycle:second_hand=yes ?? Ruben - thanks for trying to get some consistency across OSM. It would be nice to have it. The shop bicycle tags demonstrate the lack of consistency. That could be a simple time line generated thing, bicycle came first then vending. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
On Friday 14 August 2015 09:46:00 Warin wrote: > Hi, > > This follows from the shop=model discussion I raised a while ago. > > > Marczoutendijk diary > https://www.openstreetmap.org/user/marczoutendijk/diary/35584 > > demonstrates the issue that occurs with shop= ... > > I think one way to 'solve' this is to have a free text entry sub key for > shops... > > say a key of shop_products. > > In this way shop= values don't have to carry all the detail leading to > possibly millions of values. > Rather shop= values can be a collective value without the specific > detail, making them easier to distinguish by separate rendering icons. > If detail is required then the free text entry can be interrogated. > > Examples > shop=food > shop_products=cheese, bread, fruit, vegetables > > shop=scale_model > shop_products=kits, ready made, materials > > > shop=bicycle > shop_products=new, second hand, service > > Thoughts?? vending comes to mind, it is defined as being for vending machines. In any case, you should use semi-colons to separate multiple values. And semi-colon separated lists (here we go again) should be avoided (especially in new tagging schemes) in favour of namespaced tags. I vaguely remember an argument for things like vending:food:bread=yes. So, in combination with duck tagging, a shop selling mainly fruit and vegs would become something like shop=grocery vending:bread=yes vending:cheese=yes vending:fruit=yes vending:vegetables=yes And the scale model shop shop=model vending:scale_model_kits=yes service:scale_model:repair=yes (following the bicycle scheme) second_hand=yes (that is an approved tag: https://wiki.openstreetmap.org/wiki/Key:second_hand) For bicycle shops, there are already tags to describe this, see https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Shop= values and a sub key for detail?
Hi, This follows from the shop=model discussion I raised a while ago. Marczoutendijk diary https://www.openstreetmap.org/user/marczoutendijk/diary/35584 demonstrates the issue that occurs with shop= ... I think one way to 'solve' this is to have a free text entry sub key for shops... say a key of shop_products. In this way shop= values don't have to carry all the detail leading to possibly millions of values. Rather shop= values can be a collective value without the specific detail, making them easier to distinguish by separate rendering icons. If detail is required then the free text entry can be interrogated. Examples shop=food shop_products=cheese, bread, fruit, vegetables shop=scale_model shop_products=kits, ready made, materials shop=bicycle shop_products=new, second hand, service Thoughts?? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature proposal - RFC - Location transitions
Hi, I just wanted to introduce a new key to map location transitions, when something goes underground or undersea for instance. http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions This is intended for power lines and pipelines first but can be used on any other feature also as a global placement indication. Currently, a location transition can be seen by comparing location=* values on two or more connected map features (often ways). But sometimes, underground part can't be mapped due to lack of information (or verifiability principle violation) and the transition isn't complete. This key is intended for such cases. Location=* can be missing too. It's all brand new and doesn't overlap with other keys. Some previous keys and values like tower=air_to_ground and tower=location_transition may be replaced by this more global key. There are no specific values to keep it simple to use. Nevertheless it can be completed to match specific needs. All the best François ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
