Hello. I’ve been editing things in the Northwestern California National Forest area for a few days now and it seems like the national forest imports that were done there in the past have major problems. First, there are large square areas everywhere where there is no national forest areas, even though there probably should be, which causes the map in that area to look like a checkers board when it should’t. Second, the national forest areas go across a lot of other areas that don’t have trees in them like lakes, retail areas, large areas of rocks, etc etc, but those things are still rendered with tree overlay even though they shouldn’t be. I know it is possible to make an inner relation, but it seems like putting duct tape on the problem instead of solving it. For one, it doesn’t solve the checkerboard issue. Plus, I don’t have the time, motivation, or knowledge to turn everything into an inner relation. I think this is a good example of the pitfalls of landuse. The landuse=forest should not graphically override other landuses or objects that it crosses. That does not seem to happen with any other landuse key. Not to mention most of the instances of landuse=forest are way to big etc to alter in any major way later on, especially since they are all relations with each other. So what can I do to clean things up and fix the area? Id like to make it actually geographically accurate. So should I just delete the offending landuse=forest areas if I can and replace them more well defined ones? Or suggest to the map coders that landuse=forest be made to not override other things geographically? Or what?
Ultimately this is a problem with imported data (meant, I think, to signify an administrative boundary, but I may be wrong) being wrongly tagged as a forest. Something like http://www.openstreetmap.org/way/64298556 really should not be tagged as landuse=forest. It’s not particularly a map rendering issue - the data is simply wrong.
So yes, by all means, dive in and correct the data, such that any landuse=forest tags only cover the actual forest. Generally you should be somewhat careful about large-scale modifications to data already in OSM, but in this case, the data is so spectacularly broken that I’d encourage you to slash and burn!
IIRC, consensus is that US National Forest should not be tagged as landuse=forest. The very slogan of the USFS is “land of many uses”, so it is not all timber production as implied by OSM’s landuse=forest tag.
In my area south of you in California I see the Los Padres with a multi-polygon boundary relation tagged with:
boundary:type=protected_area
boundary=national_park
leisure=nature_reserve
name:de=Nationalforst Los Padres
name=Los Padres National Forest
operator=United States Forest Service
ownership=national
protect_class=6
protected=perpetuity
protection_title=National Forest
source=http://fsgeodata.fs.fed.us/vector/lsrs.php
type=boundary
website=http://www.fs.usda.gov/lpnf/
wikidata=Q3290802
wikipedia=en:Los Padres National Forest
I did not have anything to do with that administrative level tagging and am not sure all those tags are correct or needed. But you can see that landuse=forest is not among the tags.
Independent of the administrative boundary polygon, within there are areas tagged to indicate the land use, land cover, etc. Those areas may cross over the administrative boundary.
For land cover there are a couple of schemes in use that I know of: natural=* and landcover=*
I prefer landcover=* as I can tell if an area has trees, grass, etc. But can be uncertain if the trees, grass, etc. are there because of human intervention or not. I generally use both tagging schemes (natural=* to work with many current rendering implementations and landcover=* so that if a rendering implementation uses what I consider a more logical tagging it will have data to work with).