"It's all driven by technocrats who have no clue about what a tree or forest looks like in the real world."
Small note, phrases like this are unlikely to be a good idea. 2015-03-11 17:36 GMT+01:00 Friedrich Volkmann <b...@volki.at>: > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging