Re: [Tagging] landcover=trees definition
On 16.08.2015 09:06, Martin Koppenhoefer wrote: I'm not very good at refraining from replying to trolls, but I think this time I have to do it... This is not the first time you refrain from replying when it comes to a definition of your landcover=* key. You simply have not managed to make up a definition for years, so whenever I ask you for a definition, you hide out, waiting for another opportunity to advocate your key, then playing the same game again and again. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landcover=trees definition
sent from a phone Am 16.08.2015 um 01:41 schrieb Friedrich Volkmann b...@volki.at: That depends on observation time. E.g. much of Europe is covered by fog in Autumn. So this will be landcover=fog. I'm not very good at refraining from replying to trolls, but I think this time I have to do it... cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landcover=trees definition
On 16.08.2015 04:00, Daniel Koć wrote: http://wiki.openstreetmap.org/wiki/Landcover There is no definition of the landcover=* key. The page features a wide range of keys including amenity=* and tourism=*. Even if there were a definition, it would be the wrong place. The definition belongs to the proposal (Proposed_features/landcover) and/or feature page (Key:landcover). Somebody has just suggested that one should tag the lawns as landuse because everything is use, so this key can be stretched too. Not everything is use. E.h. hazard=* is rather the opposite of use. Most natural=* features denote what's there, not how it is used. Well, you *can* use a swamp, but if you don't use it, it is a swamp anyway, so this is really independent of use. Of course this is not a substitute for the forest and I try to be clear that I don't like it to be used as a general type. If you know it's a forest, you should tag it accordingly (once we have definition again). But if all you know is there are some trees, you don't know if there are all these things, so you can safely tell only about what you know, hence landcover=trees is what you really know. I have a feeling that this landcover=* thing aims mainly at armchair mappers who map from arial images but don't know how to interpret them because they have never been outside. So they cannot distinguish urban lawns from rural meadows, or meadows from heaths, or orchards from parks or gardens. But they can distinguish trees from no trees. So they use landcover=trees where they see trees, and landcover=grass where they see no trees. I came across areas which were tagged landcover=grass although they were mostly covered by buildings. If you cannot decide between landuse=forest and natural=wood, take either one. Just like picking a tracktype. Last resort in case of doubts should be something more general, even partially, not rolling the dice! Of course that's what people do now, but we're discussing here to help them avoid such wicked games with database. When picking a tracktype you have to roll a dice as well. There's no clear line between grade4 and grade5 definitions. When in doubt, you have to choose one randomly. It's still better than omitting the tracktype, because grade4 and grade5 are on the same end of the scale, so this bears useful information. Same for forest/wood. There's no clear line between their definitions, it's a pity that we have two first-level tags for them in the first place. Anyway, they are also very similar to each other, and very different from other tree-covered areas (such as avenue trees). So it's fine to pick one of forest/wood, even if it turns out later that the other would be more correct. The tags in the database are not graved in stone, we can correct mistakes at any time. After all, we have not a single faultless object in the entire OSM database. All of the coordinates are inaccurate to some degree. Mapping is not an act of collecting faultless data, it's a process to continuously improve the data. Your questions about what lancover really is made me read the wiki and it seems it's just a twin for surface, which is meanwhile also used to indicate the surface type of larger areas, like for a Landuse but is generally used as a secondary tag. This means more or less that maybe surface=trees would be good, however people use it very infrequently and I don't know if it is primary or secondary tag then: I agree that landcover=* strongly sounds like surface=*, but we can hardly compare them as long as there's no definition for the landcover=* key. There's nothing wrong to use surface=* for areas, but due to its original use it still describes the surface at ground level. Surface=trees would be strange, because a barely visible path in the forest typically has the same surface as its surrounding area, which would imply surface=trees on the path. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
sent from a phone Am 14.08.2015 um 01:46 schrieb Warin 61sundow...@gmail.com: 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. I agree that every tag has to find the balance between sufficiently detailed and not too specific in order to keep the possible different values below the millions you have cited. But I believe in your examples you tend to have the first level classification too generic: Examples shop=food shop_products=cheese, bread, fruit, vegetables too generic and not similar to what people know. You can buy cheese in the supermarket, specialized cheese (or deli) stores, department stores, fresh food market, convenience stores, organic food stores, at the producer etc., and they will not sell you the same cheese (similarly for bread and fruit). The typology of shop also gives you context about the quality (at least a hint). If you are looking for a shop to buy cheese, you might have different requirements (easy parking, convenience of buying all kinds of stuff at the same place, eventually cheaper or high quality, sustainable production and packaging, local producers, better taste, different kind of product etc.) These criteria are likely not interchangeable, someone interested in buying bread from a bakery with wood fired oven, natural sourdough and local production will not be interested in a place to buy some industrial product sold as bread. Also, the first level tag shop=food would be way too generic in that it never would supply sufficient information for anyone looking for something to eat - besides someone starving or completely indifferent maybe. The current tags (e.g. shop=bakery) do solve this way better, and still leave room for subtags to further refine tagging (e.g. organic, industrial vs. small scale local production etc.). shop=scale_model shop_products=kits, ready made, materials similarly also this is too generic as it doesn't tell you at the first level what it is about (a shop for buying stuff to build models? What kind of models (architecture, railway, flying stuff, ships, cars, ...) IMHO this could on the first level already tell you if its about vehicle models (or maybe flying stuff) and the subtag could tell if it's about helicopters, rockets, airplanes or maybe all of these, and another subtag if it's kits, preassembled, materials, all or some of these etc). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
sent from a phone Am 14.08.2015 um 02:02 schrieb Ruben Maes ruben.mae...@gmail.com: vending comes to mind, it is defined as being for vending machines. In any case, you should use semi-colons to separate multiple values. I've in rare occasions used: sells http://taginfo.openstreetmap.org/search?q=sells either like this sells:ice_cream=yes or some people use sells=a;b;foobar cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Cycle route relations, networks and refs
I've encountered two fairly widespread issues with bike route tagging and would appreciate help sorting them out. In parts of Germany and elsewhere, networks of local/regional cycle routes are grouped into regions. The Nordrhein-Westfalen network is a good example. The master relation http://www.openstreetmap.org/relation/33216#map=10/50.5815/6.7992layers=C is tagged with type=network, which is perhaps appropriate (insert usual 'Relations are not categories' citation here). However, its child relations are tagged with type=route: http://www.openstreetmap.org/relation/222572 which is not appropriate. As the osm.org geometry shows, this isn't a route, it's a collection or network of routes. A second issue is the misuse of the ref= tag in these relations. The ref= tag is intended for a number that appears on a sign or other on-the-ground evidence. It is not some arbitrary bunch of letters I made up to get it to render. However, it's being used as the latter in this (ref=NRW) and many similar cases. The most correct way forward would seem to be: - break the child relations up into individual routes - group these together within a parent type=network relation - remove the ref tags The first step would, of course, be Hard Work. Thoughts and suggestions welcome. cheers Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycle route relations, networks and refs
A few years ago I spent a lot of time breaking up these kinds of relations in The Netherlands, after fixing the ones in Belgium. I can assure you it's indeed a lot of work. When numbered walking route relations came in vogue, I made sure they were mapped properly right from the start. I tackled a few in Germany near the border too, but since then my interests have shifted somewhat, not to say entirely to PT. I had hoped the Germans would follow the example... The use of a network relation to group the route relations is entirely appropriate. they are networks of routes. It's not a category. Polyglot 2015-08-16 12:21 GMT+02:00 Richard Fairhurst rich...@systemed.net: I've encountered two fairly widespread issues with bike route tagging and would appreciate help sorting them out. In parts of Germany and elsewhere, networks of local/regional cycle routes are grouped into regions. The Nordrhein-Westfalen network is a good example. The master relation http://www.openstreetmap.org/relation/33216#map=10/50.5815/6.7992layers=C is tagged with type=network, which is perhaps appropriate (insert usual 'Relations are not categories' citation here). However, its child relations are tagged with type=route: http://www.openstreetmap.org/relation/222572 which is not appropriate. As the osm.org geometry shows, this isn't a route, it's a collection or network of routes. A second issue is the misuse of the ref= tag in these relations. The ref= tag is intended for a number that appears on a sign or other on-the-ground evidence. It is not some arbitrary bunch of letters I made up to get it to render. However, it's being used as the latter in this (ref=NRW) and many similar cases. The most correct way forward would seem to be: - break the child relations up into individual routes - group these together within a parent type=network relation - remove the ref tags The first step would, of course, be Hard Work. Thoughts and suggestions welcome. cheers Richard ___ 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] Cycle route relations, networks and refs
The definition of the cycle network you to complain about can be found in http://www.radverkehrsnetz.nrw.de/RVN_home01.html. http://www.radverkehrsnetz.nrw.de/RVN_home01.html You can't break it into routes, it is a network. And ref=NRW is not so bad, the complete name would be ref=Radverkehrsnetz NRW. If you think that is better ... The new, junction-node based system is based on routes, for an example you may check http://www.openstreetmap.org/relation/4257206 best regards, Kurt On 16-Aug-15 12:21, Richard Fairhurst wrote: I've encountered two fairly widespread issues with bike route tagging and would appreciate help sorting them out. In parts of Germany and elsewhere, networks of local/regional cycle routes are grouped into regions. The Nordrhein-Westfalen network is a good example. The master relation http://www.openstreetmap.org/relation/33216#map=10/50.5815/6.7992layers=C is tagged with type=network, which is perhaps appropriate (insert usual 'Relations are not categories' citation here). However, its child relations are tagged with type=route: http://www.openstreetmap.org/relation/222572 which is not appropriate. As the osm.org geometry shows, this isn't a route, it's a collection or network of routes. A second issue is the misuse of the ref= tag in these relations. The ref= tag is intended for a number that appears on a sign or other on-the-ground evidence. It is not some arbitrary bunch of letters I made up to get it to render. However, it's being used as the latter in this (ref=NRW) and many similar cases. The most correct way forward would seem to be: - break the child relations up into individual routes - group these together within a parent type=network relation - remove the ref tags The first step would, of course, be Hard Work. Thoughts and suggestions welcome. cheers Richard ___ 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] landcover=trees definition
On Aug 16, 2015, at 7:00 PM, Friedrich Volkmann b...@volki.at wrote: Not everything is use. E.h. hazard=* is rather the opposite of use. Most natural=* features denote what's there, not how it is used. Well, you *can* use a swamp, but if you don't use it, it is a swamp anyway, so this is really independent of use. This is the crux of the landcover argument. Because landuse=* implies what the land is used for - therefore man-altered and decided usefulness. natural=* was then interpreted by taggers to be the opposite - the natural state of the land which was heavily influenced by the landuse=forest /natural=wood debacle. Landcover=* just says this is here , without adding implications as to its use or origin. People have commented about natural not implying the pristine natural state (i have used natural=sand to map the sand pits for long-jumpers at a sports stadium), but many definitions have had this implication added into them with bad tagging. This also would allow for some man-made landcovers; as several times i am dealing with a place where concrete or asphalt is covering the ground, but not as road or path or building. This is a weaker use case, but it would be nice to say here is 2000sqm of concrete. It is the remnant of an old airport. The airport is gone, it is not a road, a building or a structure. It is now a (currently) purposeless expanse of concrete. Currently I have to map it as the negative space surrounded by other things (meadow) to leave the impression something is there (NAS Alameda in San Francisco is a perfect example: https://www.google.com/maps/@37.7813303,-122.3170894,16z/data=!3m1!1e3 part of it is now roads, tracks, or other facilities, but it is an abandoned airport where most of the feature has no use nor is natural). Grass along the sides of manicured roads (like on a cutting or separation for safety or noise control), which are part of the roadway's land, but not part of the road - nearby residential houses, but not part of a residence nor used as a park - its there just to be grass. Landcover=iceplant would be brilliant for southern California freeway mapping. Its not used for anything other than being iceplant- occasionally a car will go in it, but it's job os just to be there so the ground isn't dirt or dead meadow grass. Sounds like a landcover to me. Again, i understand that was the intent of natural=*, but because of a bad choice of key name (natural has huge connotations ), mappers followed the connotation of the name and muddied it. If I had landcover=trees with a boundary line like nature reserve, I wouldn't have to decide between wood and forest, when it is a bit of both. I can say this mountain is covered with trees. Then with a boundary or other area: this is a preserve, this is a military trainging ground, this is a logging area, this is the fenced off area around a quarry, a ski resort, housing, and this is a national park for hiking. That's just for Mt Fuji! Wanting landcover over natrual or landuse is not because the mapper is lazy nor is blind mapping from aerial images - it is easy to make assumptions for aerial imagery, especially when you are cleaning up a 5 year old import of badly aligned mis-tagged road ways. Mapping gridded residential is straightforward. Landuse=residential. It becomes hard when you really know an area and are micro-mapping it - and you know that the connotation of the tag doesn't fit the mapped area well, and it makes you feel uneasy using it - so there is a strong desire for a connotation-free tag. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tagging National Forests
Hi, The new rendering of forests broke cases where a lake is inside a forest and the lake is not mapped as an inner section of the surrounding forest polygon. I posted this issue in the carto issue tracker: https://github.com/gravitystorm/openstreetmap-carto/issues/1754 But after some discussion I realized that this may be a side effect of a different problem, namely how we tag national forests. In the US, these seem to be tagged as landuse=forest which is only partly true: within a National Forest, many different land uses can occur, only one of them being forest. So should we just not tag National Forests as landuse=forest? Martijn van Exel skype: mvexel ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
