Re: [Tagging] RFD tag:shop=camera?
On 6 June 2015 at 02:56, Warin 61sundow...@gmail.com wrote: On 6/06/2015 11:13 AM, pmailkeey . wrote: On 5 June 2015 at 06:01, Marc Gemis marc.ge...@gmail.com wrote: On Thu, Jun 4, 2015 at 4:14 AM, John Willis jo...@mac.com wrote: Don't confuse searching for an object with how they are sorted/labeled/and represented - nor forget about the inflexibility in OSM/-carto to get them represented differently. (Take-out bag?) Or support regional renderings (buddhist shrines do not use the buddhist wheel in Japan, but thats what they get) You might know the French made their own rendering of OpenStreetMap data. They have a baguette for a bakery instead of the bagel icon. They also have decicated icons for their railway stations, mail offices, etc. It would be a good thing when e.g. the Japanese community would set up their own server, with focus on what they find important and with typical icons for their culture. When it would appear on osm.org as an alternative layer that would even be greater. regards I have absolutely no objection to locals using their own language names for things but having different icons is surely not a benefit ? It is to the locals. e.g. They may not see 'fast food' as a hamburger! I don't recognise 'fast food' in any case ! Perhaps an image of a cheetah or peregrine falcon would be more appropriate ? I'm not sure all 'fast food' outlets produce food particularly quickly - but that's beside the point. I suspect a cup of coffee symbol is pretty universal globally for a café / coffee shop - and OSM should be aiming for as globally acceptable icons as possible. I can just see then the icon globally agreed and a colour debate going on into the next century ! -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD tag:shop=camera?
On 6 June 2015 at 03:33, John Willis jo...@mac.com wrote: All the double Ls are disappearing. Traveling is a common spelling now. Google traveling vs travelling. My spell checker marks the double L version as misspelled. surely you mean misspeled ??? The one that really gets me is 'Americanization' - the use of ZED rather than 'S' which is fair comment as the s is pronounced more like a z. A good example being 'prezident'. I have come across the 'simplified speling society' which had hopes of standardizing speling in a gud way. l8rz ! -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
On Fri, 2015-06-05 at 21:01 -0500, John Eldredge wrote: Also, there are a lot of so-called hobby shops that carry supplies for decorative crafts such as beading, embroidery, and jewelry making. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. -- Martin Luther King, Jr. In the UK, there is a chain of shops called Hobby Craft, I have never been inside one but mapped on as shop=craft, probably wrong as looking at the web site it sells art and craft supplies. www.openstreetmap.org/way/165220958 Phil (trigpoint) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
Am 06.06.2015 um 00:32 schrieb John Willis jo...@mac.com: Shop=hobby Shop=model trains Shop=table_gaming Shop=scale_models The better choice (I think) is to create a subkey for hobby and define out the different shops that way. There can be a lot of hobbies, I wouldn't have put games shops (table gaming, adventures, Cosplay, ...) in hobby, but in toys. I agree for subtags. Cosplay could be a sub category of costumes. I would have thought of hobby stores selling stuff for creative work, like scissors, glue, paper and cardboard, wooden pieces, paint, plastics etc. I see that rc vehicle models could be seen as a kind of hobby shop too, but they could also be a kind of toy shop or a category of its own (with still space for more detailed subtags, eg trains, aircraft, watercraft, machinery, landbased. Scales (can make sense for trains with fix scale classes)), I'd rather prefer not to use a very broad reading of hobby as this would reduce the information significantly requiring to look at subtags for most real applications. Maybe we can live without it completely, using unambiguous synonyms for the different meanings. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
Try to understand that there is a serious point being made here. Multi-valued keys always cause arguments on these lists. Unfortunately the forces of nature have decided that some shops fit in multiple categories at the same time, and some roads have multiple ref's and there are plenty of other examples where mappers have felt that the k=v1;v2 model best fits their perception of reality. The strongest voices seem to prefer avoiding this construction. There are occasional discussions about how to do it better, but it always fizzles out to nothing. In the big metamodel, we have 0-dimensional information, whereby the mere existence of the key is enough; we have 1-dimensional information, where a key has a single value (such as is represented in OSM with highway=*), we have 2-dimensional information, where the value is a list of atomic values, like what a shop sells. We could also look at more complex information, where the value is a list of data items of varying types. This often gets mapped to the so-called namespace syntax with a colon separating the main key from the individual information component, so we can distinguish between the name of different classes of object and interpret them differently if we require. OSM provides only a metamodel with nodes, ways, and relations, all of which can have key-value pairs. That's it, apart from changesets and versions. Anything at a higher semantic level needs to come from the community. All these primeval objects are rattling around in space waiting for the earth to form after the big bang. Time to work towards an updated metamodel, with: * Multiple values (lists of values - sorting out the semicolon business?) * Complex values (data structures - formalising the namespace syntax?) * Simple Polygon as a basic type (under construction without any tangible progress for years) These are all real-life things that cause a lot of energy to be expended in OSM, simply because we don't have a way of representing them in the metamodel. Time to take things to the next level! //colin On 2015-06-06 04:09, Andreas Goss wrote: On 6/6/15 02:51 , pmailkeey . wrote: shop=photon - where n is a number on a scale to indicate the range of products e.g. : photo1 - basic point n shoot cameras photo5 - cameras, lenses, film, printing/developing service, knowledgeable advice photo9 - would include dark-room equipment, enlargers, range of photo-quality digital printers (to buy) digital photo suite - inc. computer and also illegal batteries for obsolete cameras ! Honestly I don't even know what to say about 99% of your tagging suggestions... __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
Am 06.06.2015 um 02:09 schrieb pmailkeey . pmailk...@googlemail.com: When will the multi values problem be fixed ? What if the value is a range ? Is that a problem too ? 1;2;3;4;5 or is 1-5 preferred in a contiguous case ? what if the signed housenumber is 63-67, but you won't see any 63, 65 or 67 signs, and on the opposite side of the road there are the numbers 64 and 66? 63-67 is the number they use on their letters, on the internet etc., if you tag this it can easily be interpreted as including 64 and 66, if you tag 63;65;67 it is your own interpretation because these numbers aren't there. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Localities (was: Re: RFD tag:shop=camera?)
W dniu 06.06.2015 3:56, Warin napisał(a): I have absolutely no objection to locals using their own language names for things but having different icons is surely not a benefit ? It is to the locals. e.g. They may not see 'fast food' as a hamburger! This is a much bigger issu than just icons. Tagging should be involved if we really look at the problem. In Poland we could not only see some food amenities different than fast food or restaurants, they are also called in a different way. Many eating places are called bar, unlike the drinking bar as we use this name in OSM (and some of them are commonly known subtype bar mleczny - milky bar). They are rather cheaper kind of restaurant and you won't see any typical fast-food menu like a hamburger there. But we also have also typical fast food places (like burgers or kebab), so it would be sane to tag them different and maybe show in a different way. I guess there's much more subtle localities like this - for example we were discussing bakery/confectionery/pastry/swets/candy issue lately. That's one of the reason I would like more flexible categories, so we can easily add new sub-types and treat them as one class when needed - instead of pushing everything into just a few kind of objects just to have a standard. However the icon thing is also not that easy. They are highly symbolic and can differ from one map style to another, and they are even harder to properly reflect generalities than categories system (like that used in Wikipedia), because it has to be just one sign. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Data metamodels (was: Re: Changes + additions: shop= photo, hobby, model)
W dniu 06.06.2015 11:29, Colin Smale napisał(a): Time to work towards an updated metamodel, with: * Multiple values (lists of values - sorting out the semicolon business?) Sure! * Complex values (data structures - formalising the namespace syntax?) Any example? I don't know what are you talking about. * Simple Polygon as a basic type (under construction without any tangible progress for years) What do you mean? This issue maybe?: http://wiki.openstreetmap.org/wiki/The_Future_of_Areas These are all real-life things that cause a lot of energy to be expended in OSM, simply because we don't have a way of representing them in the metamodel. You're right. I also argue we need better category system, exactly because we loose a lot of energy for trying to put some real-life objects into too narrow and fixed categorization model. Time to take things to the next level! Any practical hints how to do it? -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFD tag:shop=camera?
Am 06.06.2015 um 04:33 schrieb John Willis jo...@mac.com: All the double Ls are disappearing. Traveling is a common spelling now. Google traveling vs travelling. My spell checker marks the double L version as misspelled. double L is British English, one is AE Your spellchecker is likely set to American English. Besides the tags we allow all kinds of English and simple English in OSM ;-) cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data metamodels
On 2015-06-06 15:55, Daniel Koć wrote: W dniu 06.06.2015 11:29, Colin Smale napisał(a): Time to work towards an updated metamodel, with: * Multiple values (lists of values - sorting out the semicolon business?) Sure! * Complex values (data structures - formalising the namespace syntax?) Any example? I don't know what are you talking about. Take addresses as an example. An address is composed of a set of fields, like house number, postcode etc. These are mapped into the OSM tags addr:street, addr:postcode and so on. You can consider an address to be a reusable definition, which can be used in many contexts. The current OSM syntax using the colon says that *this* use of street is in the role of a part of an addr, and is semantically distinct from a street used as part of some other collection of values. All the data fields which are part of an addr are grouped together by the common prefix addr:. But this usage of the colon to separate the namespace ID from the field is not actually part of the data metamodel. The key addr:housenumber is just a string and the colon is nothing special at the moment. It all hangs together with a sort of unwritten gentleman's agreement. * Simple Polygon as a basic type (under construction without any tangible progress for years) What do you mean? This issue maybe?: http://wiki.openstreetmap.org/wiki/The_Future_of_Areas [1] That is exactly what I mean. That article was created in 2011 and has essentially gone nowhere since then. These are all real-life things that cause a lot of energy to be expended in OSM, simply because we don't have a way of representing them in the metamodel. You're right. I also argue we need better category system, exactly because we loose a lot of energy for trying to put some real-life objects into too narrow and fixed categorization model. Time to take things to the next level! Any practical hints how to do it? This is where it gets problematic. Any attempt in this direction will necessarily restrict the freedom of mappers, by saying there is a right way and a wrong way to do something. The theoretical side of creating an information metamodel is the easy bit. Getting the community to buy in to something that will need support from every stakeholder in the OSM ecosystem is a challenge that is better picked up by someone else with more diplomacy and patience than me... It's part of what I do for a living, and I try to pick my battles carefully. //colin Links: -- [1] http://wiki.openstreetmap.org/wiki/The_Future_of_Areas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
And how to distinguish a range like 63-67 from a flat number written as 63-67? I.e. flat 67, in a building/complex whose address is 63. Regarding the question whether the range is continuous, or only odd numbers (in this case), I have seen this solved by using a short interpolation way within the building outlines, so the addr:interpolation=odd can be made explicit. //colin On 2015-06-06 15:42, Martin Koppenhoefer wrote: Am 06.06.2015 um 02:09 schrieb pmailkeey . pmailk...@googlemail.com: When will the multi values problem be fixed ? What if the value is a range ? Is that a problem too ? 1;2;3;4;5 or is 1-5 preferred in a contiguous case ? what if the signed housenumber is 63-67, but you won't see any 63, 65 or 67 signs, and on the opposite side of the road there are the numbers 64 and 66? 63-67 is the number they use on their letters, on the internet etc., if you tag this it can easily be interpreted as including 64 and 66, if you tag 63;65;67 it is your own interpretation because these numbers aren't there. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
On 5 June 2015 at 12:36, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 05.06.2015 um 11:33 schrieb David Fisher djfishe...@gmail.com: As for landuse=residential -- I agree that we could probably do without it. But it does add to the readability of the map, especially at low zoom levels, as it enables you to see at a glance where places are and how big they are. residential landuse is often seen as default, it is often used to mark the built up area rather than just the residential areas (especially in villages). We should encourage place polygons for this and restrict the use of residential landuse to residential areas. It would help a LOT if they were rendered on the standard map ! WHY do we have this agony of stuff not being rendered ? Here's a map of the world. We've not marked on any places as we feel it would be too confusing. What's the flipping point. Flog the renderers I say. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
You are fond of proposing keys with arbitrary numbers as the value, or part of the value. This would be fine if we were using a relational database, where a mapper could select one of a list of human-language descriptions, which would then get translated to the magic number for storage. However, we do not have such tables, and presenting a mapper with a list of choices such as photo1, photo2, and photo3 is likely to result in corrupted data, due to a mapper picking one at random, or misremembering what means what. As long as the descriptions of the values aren't shown at the time the value is being selected, we need to stick close to natural language, not magic numbers. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. -- Martin Luther King, Jr. On June 6, 2015 5:31:48 PM pmailkeey . pmailk...@googlemail.com wrote: On 5 June 2015 at 10:33, David Fisher djfishe...@gmail.com wrote: On Fri, Jun 5, 2015 at 12:33 AM, pmailkeey . pmailk...@googlemail.com wrote: The issue with the 'oneway' key is that the key itself contains 'data' relating to the value. Oneway without a value would imply =yes whereas building without a value (or =yes) would give data independent of the value, IYSWIM building= hospital= The latter describes the building without the need for a value. I note your TIAL v CE above. Why do we need to know what the landuse is in any case ? I do see what you mean. I think the difference is that building = x in some sense defines the presence of the object, as does highway = x on a way. So, if building = x is not set (presumably on a circular way), or if highway = x is not set (presumably on a linear way), then those ways are just collections of nodes, nothing more. But oneway = x defines a *characteristic* of a way. A way must fundamentally *be* something (e.g. a building or a highway), but it may nor may not have any number of characteristics which don't alter that fundamental *being*. The only sensible way to deal with *characteristics* (other than insisting that every way has hundreds of tags) is to assume defaults. The problem with oneway is the key name - it's 3 letters too long: way=1 way=2 - maybe ways=1, ways=2. As for landuse=residential -- I agree that we could probably do without it. But it does add to the readability of the map, especially at low zoom levels, as it enables you to see at a glance where places are and how big they are. Again, the issue is the letters in the tag. landuse=place or landuse=settlement - landuse=town rather than landuse=residential, place=town - combine the two. Personally I'm an advocate of covering the majority of the map (not necessarily 100%) with some form of landuse area, e.g. residential, industrial, grass/meadow/parkland, farmland, etc. -- though I appreciate that not everyone shares that view. Anyone that doesn't share that view should be nowhere near OSM ! Sounds like a military cover-up to me ;) I do feel the default map not covered should be black though - to make the unmapped areas stand out :) -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail -- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
On 6 June 2015 at 03:09, Andreas Goss andi...@t-online.de wrote: On 6/6/15 02:51 , pmailkeey . wrote: shop=photon - where n is a number on a scale to indicate the range of products e.g. : photo1 - basic point n shoot cameras photo5 - cameras, lenses, film, printing/developing service, knowledgeable advice photo9 - would include dark-room equipment, enlargers, range of photo-quality digital printers (to buy) digital photo suite - inc. computer and also illegal batteries for obsolete cameras ! Honestly I don't even know what to say about 99% of your tagging suggestions... Please don't let that worry you. shop=cake1 may have a much smaller range of cakes than shop=cake7 but the quality might be a lot better. The only thing I can say about that is adding another number: shop=cake19 - which has a very poor choice of really excellent cakes or shop=cake73 which sells a much greater variety of mediocre quality cakes. However, do avoid shop=cake80 which has an excellent selection of toxic cakes and shop=cake09 which was an excellent shop when it used to be open. ;) -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] residential granularity / was Re: OSM is ... right ...
On 5 June 2015 at 13:20, Tom Pfeifer t.pfei...@computer.org wrote: Martin Koppenhoefer wrote on 2015-06-05 13:36: Am 05.06.2015 um 11:33 schrieb David Fisher djfishe...@gmail.com: As for landuse=residential -- I agree that we could probably do without it. But it does add to the readability of the map, especially at low zoom levels, as it enables you to see at a glance where places are and how big they are. residential landuse is often seen as default, it is often used to mark the built up area rather than just the residential areas (especially in villages). We should encourage place polygons for this and restrict the use of residential landuse to residential areas. +1. Drawing a residential around a village was the early attempt with low-res aerial images. With the level of detail you get from both 20cm imagery and open-data property boundaries, my preferred level of granularity is up to a block, i.e. the landuse surrounded by residential roads (but not glued to them). This easily allows to draw complementary landuse, such as retail/commercial/religious/green areas without the need for multipolygons. As a first approach when splitting larger landuse, I typically split at secondary/tertiary roads. tom I'm doing it - using =residential for settlement. Of course, =settlement (or =place) would be better for this than =residential. Residential in any case is somewhat vague. People do reside at work as well as home. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
The problem with oneway is the key name - it's 3 letters too long: How is this NOT trolling? -- View this message in context: http://gis.19327.n5.nabble.com/OSM-is-a-right-mess-was-Craigslist-OpenStreetMap-Rendering-Issue-tp5846860p5847385.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
In the same vein: way=0: no way! Better not to lose sleep over 3 letters. Jo ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
On Jun 6, 2015, at 10:34 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: (table gaming, adventures, Cosplay, ...) in hobby, but in toys. I agree for subtags. All of those are hobbies. They have dedicated stores for each. They are filled with adults, spending unglodly amounts of money. DnD books and figure painting, and complicated board games sold to adults are not for kids. Cosplay stores are for adult cosplay hobbyists - 50 bucks for a small accessory - 3 or 400 bucks for an (adult sized) outfit is not a kids hobby. Ive sold a few of those accessories. Yes, at the game store, there are a few kids trading pokemon cards. But it is not the main focus of the store. Toys are for kids. Collectables are for adults (with rare exceptions, like legos). Saying a person who paints and poses resin models is playing with dolls is equally wrong. I have spent 3 times more on anime goods back when I was an otaku than Camera lenses - and i have $10k in gear now. None of the anime stuff was catering to kids - neither the store nor subject matter. Hobbies are hobbies. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
On 6/06/2015 11:34 PM, Martin Koppenhoefer wrote: Am 06.06.2015 um 00:32 schrieb John Willis jo...@mac.com: Shop=hobby Shop=model trains Shop=table_gaming Shop=scale_models The better choice (I think) is to create a subkey for hobby and define out the different shops that way. There can be a lot of hobbies, I wouldn't have put games shops (table gaming, adventures, Cosplay, ...) in hobby, but in toys. I agree for subtags. Cosplay could be a sub category of costumes. I would have thought of hobby stores selling stuff for creative work, like scissors, glue, paper and cardboard, wooden pieces, paint, plastics etc. I see that rc vehicle models could be seen as a kind of hobby shop too, but they could also be a kind of toy shop or a category of its own (with still space for more detailed subtags, eg trains, aircraft, watercraft, machinery, landbased. Scales (can make sense for trains with fix scale classes)), I'd rather prefer not to use a very broad reading of hobby as this would reduce the information significantly requiring to look at subtags for most real applications. Maybe we can live without it completely, using unambiguous synonyms for the different meanings. The present structure of the shop= main page would suggest that shop=hobby would not be used as it is a main type of shop, along with Art and Music. If shop=hobby and sub keys used than the same method should be used for other shop types .. Art, Music etc.. Hopefully the use of subkeys would enable combinations .. such as tea and coffee in the one shop. So ... a complete reorganisation for the shop= key so that sub keys can be used? Some consider Golf, Fishing, Stamp and Coin collecting as hobbies. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Changes + additions: shop= photo, hobby, model
I'm Sent from my iPhone On Jun 7, 2015, at 8:27 AM, Warin 61sundow...@gmail.com wrote: Some consider Golf, Fishing, Stamp and Coin collecting as hobbies. Any activity that you don't do for a job can be considered a hobby. But some activities fall into broader groups, usually based on what the activity itself is. Sometimes those shops catering to a professional serve both the pro worker and the pro hobbyist (or are a common part of life) - so we dont make a hobby distinction - Such as shop=camera. Used by everyday people, hobbyists, and professionals for their job. Also - Usually activities that are athletic, require a pitch, or performed in the wilderness usually fall under sports - sporting goods stores. Hiking/trekking, fishing, and other outdoor activites fall under this. Maybe outdoor falls under sports, as many many stores are a mix of sports and outdoor gear. Activities that are usually never a profession, and require construction or take place at a desk or workbench usually end up being called hobbies - hence hobby shops. There are millions of RC car hobbyists or model makers, but a fraction of a fraction of a percent would make money through racing or making models. A coin collecting shop would be Shop=hobby Hobby=coin (or the fancier numismatic) ...If we start pitting stuff into subcategories. Javbw. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data metamodels
On 6 June 2015 at 15:36, Colin Smale colin.sm...@xs4all.nl wrote: On 2015-06-06 15:55, Daniel Koć wrote: W dniu 06.06.2015 11:29, Colin Smale napisał(a): Time to work towards an updated metamodel, with: * Multiple values (lists of values - sorting out the semicolon business?) Sure! * Complex values (data structures - formalising the namespace syntax?) Any example? I don't know what are you talking about. Take addresses as an example. An address is composed of a set of fields, like house number, postcode etc. These are mapped into the OSM tags addr:street, addr:postcode and so on. You can consider an address to be a reusable definition, which can be used in many contexts. The current OSM syntax using the colon says that *this* use of street is in the role of a part of an addr, and is semantically distinct from a street used as part of some other collection of values. All the data fields which are part of an addr are grouped together by the common prefix addr:. But this usage of the colon to separate the namespace ID from the field is not actually part of the data metamodel. The key addr:housenumber is just a string and the colon is nothing special at the moment. It all hangs together with a sort of unwritten gentleman's agreement. My thoughts on address is that it is 'one value' composed of several components. Whether any component is numerical or alphanumerical is probably insignificant - an address is a name (string) not a number. I see little need for splitting 'address' into separate tags (addr:number etc. ) and would prefer to see a value for address having its components separated by commas. The number of components should not be limited although it's unlikely to come across any more than ten. It is probably logical to treat the components as we do with numbers (and hopefully dates) by listing the components in order of significance with the most significant first: address=usa,20500,DC,Washington,Pennsylvania Avenue NW,1600,The White House. As addresses are mostly connected with routing, they should be on the routing map rather than the topographical map - i.e. that addresses should be complete and not rely on being in any defined area (state, county, zip,settlement,street) so there is no reliance on reference to other data - unless address data can be reliably generated from the physical location of an address by topo map reading - which actually would be a better way of holding data in the db. Current address components are too few - forcing components to share keys. The above suggestion would eliminate this and allow for standardisation. It would appear that allowing keys to have componented values would solve many problems such as currently being discussed shop=camera,video,frames Semicolons are a peculiar choice of delimiter; commas are much more common (CSV) and basing the component values being 'floating' (ideally most important first), there will never be a double comma (,,) which allows such to be used to generate a comma in a string. You're right. I also argue we need better category system, exactly because we loose a lot of energy for trying to put some real-life objects into too narrow and fixed categorization model. Time to take things to the next level! Any practical hints how to do it? This is where it gets problematic. Any attempt in this direction will necessarily restrict the freedom of mappers, by saying there is a right way and a wrong way to do something. If that is true, is it a good thing or a bad thing ? It appears we're already creating restrictions - and I don't think that can be helped if there's going to be any hope of consistency at all. To the mapper, is the category important ? It's a pub and I don't care what category it is in as to me and many, it's not important. Even factual stuff is not important - whether the pub is a building or a beer tent - what matters is the fact a member of the public can expect to be able to purchase the typical things found in pubs. The theoretical side of creating an information metamodel is the easy bit. Getting the community to buy in to something that will need support from every stakeholder in the OSM ecosystem is a challenge that is better picked up by someone else with more diplomacy and patience than me... It's part of what I do for a living, and I try to pick my battles carefully. In fact, Colin, that is not the problem. The problem is OSM needs a MUCH better decision-making engine. There is a lack of decisions - that is clear from apparently dead proposals and it is clear that past decisions have been made on incomplete data available at the time - such that things would work better if they were changed. The other problem with OSM is getting to the heart of it to progress anything - as surely, OSM must be the biggest organisation based on the number of premises it uses taking into account all the ad-hoc mappers! There are times when 'tweaks' are great and
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
On 5 June 2015 at 10:33, David Fisher djfishe...@gmail.com wrote: On Fri, Jun 5, 2015 at 12:33 AM, pmailkeey . pmailk...@googlemail.com wrote: The issue with the 'oneway' key is that the key itself contains 'data' relating to the value. Oneway without a value would imply =yes whereas building without a value (or =yes) would give data independent of the value, IYSWIM building= hospital= The latter describes the building without the need for a value. I note your TIAL v CE above. Why do we need to know what the landuse is in any case ? I do see what you mean. I think the difference is that building = x in some sense defines the presence of the object, as does highway = x on a way. So, if building = x is not set (presumably on a circular way), or if highway = x is not set (presumably on a linear way), then those ways are just collections of nodes, nothing more. But oneway = x defines a *characteristic* of a way. A way must fundamentally *be* something (e.g. a building or a highway), but it may nor may not have any number of characteristics which don't alter that fundamental *being*. The only sensible way to deal with *characteristics* (other than insisting that every way has hundreds of tags) is to assume defaults. The problem with oneway is the key name - it's 3 letters too long: way=1 way=2 - maybe ways=1, ways=2. As for landuse=residential -- I agree that we could probably do without it. But it does add to the readability of the map, especially at low zoom levels, as it enables you to see at a glance where places are and how big they are. Again, the issue is the letters in the tag. landuse=place or landuse=settlement - landuse=town rather than landuse=residential, place=town - combine the two. Personally I'm an advocate of covering the majority of the map (not necessarily 100%) with some form of landuse area, e.g. residential, industrial, grass/meadow/parkland, farmland, etc. -- though I appreciate that not everyone shares that view. Anyone that doesn't share that view should be nowhere near OSM ! Sounds like a military cover-up to me ;) I do feel the default map not covered should be black though - to make the unmapped areas stand out :) -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to the country's ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
Sent from my iPhone On Jun 7, 2015, at 9:26 AM, John Eldredge j...@jfeldredge.com wrote: presenting a mapper with a list of choices such as photo1, photo2, and photo3 is likely to result in corrupted data, due to a mapper picking one at random, Remember the epic discussion on track type? Even with pictures, the discussion went on and on Next we'll be grading train stations on platform size and presence of a shoeshiner... Jacbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)
On 6/7/15 00:39 , jgpacker wrote: The problem with oneway is the key name - it's 3 letters too long: How is this NOT trolling? Honestly at this point I'm not sure either anymore. I just know it's getting annyoing as fuck... __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
