On 10.03.2015 21:41, Bryce Nesbitt wrote: > I'm seeking comments on adding "palm" to the leaf types > at http://wiki.openstreetmap.org/wiki/Key:leaf_type > > A rendering engine can equate palm and "broadleaved". Mappers are mapping > palms > very frequently, and having this key name I think would reduce confusion.
I am glad you added a palm symbol to http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree#Possible_Rendering. When I created the conversion table in that section, I wondered why there is no palm symbol. I believed that I had already seen a palm symbol somewhere in the wiki, but I didn't manage to retrieve it. Then I searched google for palm symbols, but did not find anything either. So I was finally in doubt whether palm symbols are in use in carthography at all, although I still believe that palm symbols add value to maps. If broad and needle leaved trees get different symbols, palms should get their symbol as well because of their distinctive look. And - but that's just my subjective opinion - palm symbols look so cute that a map becomes more appealing when it incorporates them. Concerning tagging, there has been an approved and widely used key for a long time with exactly the values we need to distinguish palms, needle leaved and broad leaved trees. This key is type=*. This key worked quite well. However, there were two aesthetic issues with that key: That it is also used for relation types, and that there's a different key wood=* used for areas (natural=wood, landuse=forest). These issues evaporate when you look at them from an analytical perspective. type=* of trees never collides with type=* of relations, because trees are not relations. And wood=* has just another purpose. While type=broad_leaved/coniferous/palm defines the *habitus* of a single plant, wood=* describes a *behaviour* of an area. wood=evergreen means that assimilation (photosynthesis) does not change much with the seasons, and that the tree crowns remain continuously opaque. wood=coniferous means that the crowns are constantly semi-opaque, and that assimilation remains also at an intermediate level. wood=deciduous means that both assimilation and opaqueness have big seasonal amplitudes. This tag has enourmous ecological and econimical implications, and it may also be used to determine good times for documention (photographing, creating arial images) and recreational use. It is absolutely useless to use tags the other way round, i.e. plant habitus for forests or assimilation amplitudes for single trees. Therefore, no serious efforts were made to unify these tags, for many years. Then came Rudolf's surprise attack. He created a flawed proposal that missed all of the above points, and pushed it to voting just 3 weeks later. This was a much too short disussion period for a change affecting tremendous amounts of existing data. Many people, including me, did not have enough spare time in that time frame to participate in the discussion and to single out all of the flaws which include: - The wrong interpretation of the rule that "type=* for non-relation elements should be avoided". - The mistaken reduction of wood=* "to describe the type of leaves". - The wrong assumption that all of these tags mean the same. - The wrong assumption that new keys make things easier. Obviously, the opposite is true, because mappers and applications now need to know the new tags *in addition* to the conventional tags. - An ugly key name leaf_type=* although the more sound foliage=* key had been suggested on Talk:Key:wood as early as in 2012 by Alv. - broadleaved and needleleaved with no underscores - information loss due to the missing equivalent to type=palm - and worst of all, the "deprecating established keys" thing. There were more than 1 million of uses for wood=* and type=*. How can a proposal deprecate tags used a million times? Do 27 votes on a wiki page legitimate for the deprecation of tags used by >10000 distinct mappers on >1000000 objects? Well, you could think that a proposal is one thing, and actual usage is another thing. Let's see how real mappers will accept it in real life. But in this very case, real world mappers got no chance. Immediately after voting has ended, Rudolf marked type=* and wood=* as deprecated on the natural=tree and wood=* wiki pages. I guess that some JOSM developers wanted to keep their editor cutting-edge by changing templates or suchlike to the "new" tagging scheme. And some validators spit out warnings when they come across the "decprecated" tags. As we all now, some sofa mappers spend all day searching for things to correct, using validators. These people do not care about how map features represent the real world, or who mapped them or why, or who will ever use the data. They only care about what the validator says. If a validator blinks red, there's a need to change something, and if it does not blink red, everything is fine. This results in mass edits that violate the mechanical edits policy. But those people do dot consider their edits mechanical, because they are using JOSM. They believe that JOSM is an interactive editor, and that interactive editing is the opposite of mechanical editing. But in fact, they use their interactive editors merely as a frontend to do mechanical edits. I already noticed some mechanical edits changing type=* to leaf_type=* in my home town, and these edits will continue, because there will be validators and sofa mappers for all times to come. Note that no real mapper is involved in the whole process. It's all driven by technocrats who have no clue about what a tree or forest looks like in the real world. Nevertheless, there are still 474693 natural=wood, and I guess that a big portion of the 462169 nodes with a type=* tag are natural=tree. So they are still ahead of leaf_type=*. Therefore, I suggest deleting all deprecation notices concerning wood=* and type=*. Now is it possible to "repair" the new tags to make them more usable, e.g. by adding a leaf_type=palm tag as you suggested? No, because there are 533 643 existing leaf_type=broad_leaved, some of which are palms and some are not. We cannot determine which of them are palms, because that information got lost. So there's already a mess in the data. If you add a dedicated leaf_type=palm key, some palms will be tagged leaf_type=broadleaved and some will be tagged leaf_type=palm. This makes the mess even worse, because data consumers can neither use the leaf_type=palm to get all palms, and the meaning of leaf_type=broadleaved will become unclear. Furthermore, as leaf_type=* is used not only for trees, but also for whole forests - a consequence of the mixup of the type=* and wood=* keys -, the leaf_type=palm tag would also stand for palm forests. So what about a forest with palms and other evergreen trees or shrubs? Will this require leaf_type=mixed? How can we distinguish that from a broadleaved/needleleaved mix? Thus, the leaf_type=* key is irreparable, it's a dead horse, and we all know what to do when riding a dead horse. We should drop that key, return to the proven type=* and wood=* keys, revert all mass edits, remove all references to leaf_type in the wiki, and forget that it ever existed. It's like awaking from a horrible nightmare. We will rub our eyes, the sun will be shining, and the birds will be tweeting. -- 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