[Tagging] Tools and mass-retagging

Peter Elderson pelderson at gmail.com
Fri Jun 8 23:33:24 UTC 2018

I would not support "blind" mass retagging. There is too much specific use
of landuse and natural which should remain as it is, until mappers judge
differently because of what's on the ground.

In my neighbourhood, a lot of landuse=forest is actual maintained and
managed forest. No need to specify landcover=trees there, because it is a
(most of the time small, but hey, everything here is small) .

If the landcover thing pulls through, I would retag only patches marked as
landuse forest which are on larger areas with an actual landuse like
residential or industrial. Even then, I would rather have a tool allowing
me to check/uncheck candidates, then retag only the ones I checked, as one
changeset that can be reverted if need be.

2018-06-09 0:26 GMT+02:00 Warin <61sundowner at gmail.com>:

> On 08/06/18 23:51, Leo Gaspard wrote:
> On 06/08/2018 02:37 PM, Jeroen Hoek wrote:
>>> On 08-06-18 13:37, Leo Gaspard wrote:
>>>>    * for all objects with natural=wood, add landcover=trees
>>>>    * for all objects with landuse=forest, add landcover=trees
> The problem here is that I have use the tag landuse=forest to mark areas
> that are used to produce lumber that is used to make hoses etc.
> As such it is not always covered with trees ..as they have been harvested.
> New trees will be planted and appear over time for the cycle to repeat.
> But these areas that I have tagged landuse=forest would be incorrect to
> have the tag landcover=trees all the time.
> Why not consider documenting that natural=wood and landuse=forest imply
>>> landcover=trees instead? It seems like a sensible default (similar to
>>> how access=yes is the default for access to generic highways such as
>>> highway=unclassified). Any exceptions can be explicitly mapped.
>>> This is similar to how landuse=grass (when used to indicate an area that
>>> is used to grow grass) would imply landcover=grass.
>> That's a possibility indeed, but then all tools that make use of the OSM
>> database must add this implication.
>> With ~70500 keys currently on taginfo, I don't think it's reasonable to
>> say all tools should support all implications, and keeping implications
>> to a minimum sounds like a worthy goal. Having implications for eg.
>> access=* makes sense, because there is no other usable logical use of
>> them.
>> On the other hand, once a mass-retag would have been made that adds
>> landcover=trees to landuse=forest, the landuse=forest use could be
>> deprecated and would naturally slowly phase-out, thus simplifying the
>> database.
> natural=wood can be phased out to landcover=trees.
> But landuse=forest phased out ... where then is the landuse for the areas
> that produce the lumber that goes to make houses? Furniture?
> Will landuse=foretry be the new landuse=forest .. and that then be misused
> as landuse=forest is?
>> Basically, having an open tagging scheme makes sense for quick
>> development or tagging new things. I'm not saying it should be removed.
>> But once something becomes a “recognized” use case (as “this place is
>> covered with trees” is, currently handled by natural=wood or
>> landuse=forest), I think it would make sense to at least attempt to
>> “normalize” them. Potentially including mass-retags to map
>> previously-used tags to the standardized version.
> And there lies the problem. The missing understanding that landuse is to
> signify the human use of that area,
> not what covers the land, not what buildings are there or not there .. but
> the use of it.
> Thus landuse=military can be a dockyard, an area of trees and/or a group
> of buildings... the use of the land is by and for the military.
> Use.
>> Then again, I'm so new to OSM that you can consider this an outsider's
>> opinion who just thinks that the database is way more scattered than it
>> needs to be, and this makes tool development harder to make complete,
>> thus weakening the ecosystem when each tool supports a slightly
>> different set of tags.
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

Vr gr Peter Elderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180609/fc472cea/attachment-0001.html>

More information about the Tagging mailing list