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