[Tagging] Leaf type of "palm" for leaf_type

Mateusz Konieczny matkoniecz at gmail.com
Wed Mar 11 16:58:13 UTC 2015

"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 <bsd at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150311/6d71f81b/attachment-0001.html>

More information about the Tagging mailing list