So, tagging the Larch grove, we have to decide, what’s the most important for map: to know it’s deciduous or to know the type of reproductive organs of the trees (“conifer” means “bearing cones”).
Actually, we are interested not in type of reproductive organs (cones/flowers) but in type of leaves: needleleaf or broadleaf.
These are much more correct terms, because “conifer” is not a synonym for “needleleaf” at all.
Finally, the opposite variant of “deciduous” is “evergreen” (and “evergreen” absolutely is not a synonym of “needleleaf”, because there are pretty much evergreen non-needleleaf trees).
So, what do you think about that?
Current scheme sounds like “warm or heavy” variants for me… Something wrong even from the point of common sense, not only from scientific point.
You are right that this mixes things that do not belong with each other. But if you want to start a cleanup, it would be nice to design it in such a way that we can use the same categories on tree rows and individual trees, too. Currently there is the type=broad_leaved/conifer/palm tag for trees. That tag makes (somewhat) more sense, but should be migrated away from the “type” key. I believe the only clean way to do such a change is introducing two new tags for the orthogonal properties.
I quite agree with Tordanik that some additional (ultimately) replacement tags are needed. I am writing a number of fairly long blog posts on the subject.
For now I would suggest using trees=broad-leaved (this was added to a lot of CORINE data) as well as wood=broad-leaved. Given the orthogonality of deciduous/evergreen, conifer/broad-leaved/etc, I have started using the tag deciduous=yes.
Managing rendering is another thing which will make it fairly long-winded to sort out.
I suppose, that right and simple enough scheme could consist of two keys:
vegetation:foliage
vegetation:leaf
The first key should represent the difference between evergreen and deciduous plants.
The second key is more optional (in common case) and it should represent the type of leaf, at least: needle-leaf or broad-leaf (for temperate and boreal vegetation).
Such keys will not be strictly connected with trees or natural woods, it could be used for bushes and even shrubs.
Any additional classes could be added. For example, there are evergreen broad-leaf trees like rhododendron and olives - they have special sclerophyllous type. Cypress trees have scale-type leaves being evergreen. So this scheme looks like easily extensible.
Speaking of rendering - while Mapnik is hopeless, maintainers of several other tile servers are much more responsive. So, if we will be able to find proper way to represent tree types, it’s possible to implement it in some of rendering styles.
And I should add, that CORINE data actually have classes, equal to broad-leaf/needle-leaf division, it’s clearly stated in the description on this product. It’s fair enough, because Larches, for example, are needle-leaf and deciduous, but they are in the same class of CORINE as evergreen conifers.
I think that would be a good solution. Do you plan to set up a proposal for this? I think replacing would require going to the full formalized process (and likely a lot of disucssions along the way).
Currently, I’m trying to gather feedback from people, not connected with OSM (ecologists as source of knowledge about classification, regular hikers as potential users of these data, forestry managers as “people in industry”) to make sure I’m not missing something or not messing things.
For example, I’m not yet sure about sclerophyllous plants (evergreen oaks, olive trees and many Australian trees) - do they need separate class of leaf type, or vegetation:foliage=evergreen vegetation:leaf=broad would be enough for common case.
Actually, the proposal procedure could be started (even keeping in mind I don’t really believe in it). Discussion may occur, of course, but I suppose, this scheme is pretty plain and clear, so it shouldn’t bring up any serious fundamental questions or arguments. The only barrier for approval could be the lack of understanding, why current scheme is almost meaningless. So I have to do some large homework to make it easily understandable by people with limited knowledge of even elementary botany. It means not only examples of different foliage (that’s easy, I can collect photos in a couple of days) but real “use cases” for these data.
Anyway, these tags are new, and not interfering with wood=* scheme physically. It means, anyone can add new tags to reflect the truth and keep the legacy ones (to keep people calm and avoid extra discussions).
I’m sure, it will be possible to support these tags at least by OpenMapSurfer and, maybe, by some converters.
But, there is some interesting question I’ve already faced: people are interested in proper way to use these tags for existing large woodland territories. They worrying about slicing them into smaller parts or adding a kind of sub-boundaries. That could be the only practical problem with usage.