<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div>I personally also feel more for using and extending the landcover tag. It already exists so why introduce a new one. The question will be what "master" tag should be used or introduced in combination with the landcover tag.<br></div><div><div><br></div></div><div>I think barrier=hedge + landcover=scrub would be fine. <br></div><div><div><br></div><div>For the other, would landuse=greenery + landcover=* be sufficient? If it would be introduced as value for natural=*, a more specific value like urban_greenery (or with a proper alternative for the word urban) would be needed. This to avoid confusing with the other values of natural</div></div><div><br></div><div><br></div><div>4 feb. 2021 08:47 van mail@jeroenhoek.nl:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>On 04-02-2021 06:23, Brian M. Sperlongano wrote:<br></div><blockquote><div>Yup, I think you've hit the nail on the head.<br></div><div><br></div><div>IMO, the only way this could be solved is with a technical solution. <br></div><div>There would need to be a system of backwards compatibility in which<br></div><div>existing clients can continue to access the data using legacy tagging<br></div><div>schemes, with a stated end of life date, and clients could choose to<br></div><div>upgrade on their own timeline to the newer scheme. This implies a layer<br></div><div>of translation that would need to exist between the underlying data and<br></div><div>what is actually presented to the user. Now obviously this is glossing<br></div><div>over A LOT of technical details about all of the tools in the ecosystem<br></div><div>and how users interact with the data. But I don't see any other way we<br></div><div>could have a systematic mechanism for tagging standardization (if indeed<br></div><div>the community even desires it) without some kind of backwards<br></div><div>compatibility translation layer.<br></div></blockquote><div><br></div><div>I don't think it needs to be that complex. We know that landuse=grass,<br></div><div>natural=scrub, and landuse=forest will remain abused for a long while.<br></div><div>But a better alternative for the use case of mapping landscaping can<br></div><div>gradually become the default if a few concerns are met:<br></div><div><br></div><div>* Solid proposal with community backing<br></div><div>* Good documentation<br></div><div>* Rendering support in Carto, JOSM, and iD<br></div><div>* Presets in JOSM and iD<br></div><div><br></div><div>Mappers will follow soon enough if that foundation is there.<br></div><div><br></div><div>The landcover-tag has a good head start already in terms of use, and<br></div><div>should be at the heart of such a proposal:<br></div><div><br></div><div>landcover=grass<br></div><div>landcover=trees<br></div><div>landcover=scrub<br></div><div>landcover=flowerbed<br></div><div><br></div><div>And perhaps landcover=scrub + barrier=hedge may then be acceptable for<br></div><div>hedges mapped as areas?<br></div><div><br></div><div>At nearly 30.000 uses for landcover=grass and 160.000 for<br></div><div>landcover=trees, can rendering in Carto be on the table by this point?<br></div></blockquote><div><br></div> </body>
</html>