<div dir="ltr"><div dir="ltr">On Mon, 21 Jan 2019 at 04:20, Andy Townsend <<a href="mailto:ajt1047@gmail.com">ajt1047@gmail.com</a>> wrote:</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One suggestion that I've made here before is explicitly to use <br>
"landuse=forestry" for areas that may or may not have trees on them, if <br>
the areas with trees within have been mapped separately<br></blockquote><div> </div><div>You're not the only one to have made that suggestion.  It makes a lot of sense, since</div><div>the original intent for landuse=forest was for forestry and the natural language/OSM</div><div>mismatch is one reason the tag is often used for a different purpose than intended.</div><div><br></div><div>I've mapped several areas of trees where the OS_OpenData_StreetView layer shows a</div><div>different extent than is visible in aerial imagery. - sometimes a lesser extent, sometimes</div><div> a greater extent.  And in some of those cases where the OS layer is larger than visible</div><div>in aerial imagery, the aerial imagery shows a fence matching up with the OS layer AND</div><div>what appears to be tree stumps or scrub or young trees or whatever where the two views</div><div>disagree.  If I map the visible extent of the trees, years from now somebody will have to</div><div>change the outline to match new growth.  If I include tree stumps then somebody might</div><div> change the outline the next day to match what is visible.  Having landuse=forestry that</div><div> really does mean forestry (as opposed to landuse=forest that was intended to mean forestry</div><div> but rarely does) would deal with some of the issues.  It would be up to the mapper to decide</div><div> whether it's worth the hassle of using landcover=trees to show the current extent of trees.<br></div><div><br></div>[...]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That renderer also processes landuse=forest the same way - see <br>
<a href="https://www.openstreetmap.org/way/44018882" rel="noreferrer" target="_blank">https://www.openstreetmap.org/way/44018882</a> and <br>
<a href="https://map.atownsend.org.uk/maps/map/map.html#zoom=15&lat=53.21319&lon=-1.18217" rel="noreferrer" target="_blank">https://map.atownsend.org.uk/maps/map/map.html#zoom=15&lat=53.21319&lon=-1.18217</a> <br>
for an example of that.<br></blockquote><div><br></div><div>And there's the rub.  The standard carto ignores landuse=forestry.  Which means that people</div><div>end up tagging for the renderer by using landuse=forest or natural=wood.  Because woodland</div><div>is tedious to map and there's no point going to all that effort if it's not going to render.  It's</div><div>unrealistic to expect most mappers to use landuse=forestry unless it renders.<br></div><div><br></div><div>Around and around we go.  This list cannot agree on approving landuse=forestry because it</div><div>doesn't get rendered.  The carto people refuse to render landuse=forestry because nobody</div><div>uses it.  Sometimes the semi-anarchic nature of OSM tagging can be very frustrating.  There</div><div> are days when I yearn for joined-up thinking.</div><div><br></div><div>How about...  I expect it will get shouted down for many reasons, but...</div><div><br></div><div>What if we suggest in the wiki that where trees are used for actual forestry people are</div><div>encouraged to dual-tag with landuse=forestry + natural=wood on the basis that with</div><div>enough usage the carto group will render landuse=forestry AND that when they do there</div><div>will be an effort to remove natural=wood when it appears in combination with</div><div>landuse=forestry.  What was I thinking?  That might actually get us somewhere, and we</div><div>wouldn't want to do that.<br></div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>