Example of the iD error message:
to be found here:
(The l=i tag is on the surrounding area but not on the plot itself)
Example of the Osmose error message:
Same situation as above, to be found here:
Fun fact: The iD error and the Osmose error are not popping up at the same object …
It looks like, from software perspective, there’s no check if the smaller industrial area is within a larger one, and it just expects each separate area to have the same tag. I wouldn’t necessarily call that error, more like lack of feature. If the discussion here shows that indeed l=i shouldn’t be in each separate area if already a broader area one exists which encapsulates them, then an issue on iD’s github should be raised to propose this check.
This is a good comment for sure but leaving my question unanswered … 
… what would YOU do in such situation - break the whole large landuse=industrial up and add the tag to every single plot or would you save your time, put just an additional landuse=industrial tag to that very plot and move on?
If I have limited time or limited knowledge, I’d do a “first draft” on the larger area. If I have time to invest and deep, detailed knowledge, I’d spend that time curating as much detail as I know and know how to tag / map (asking in places like here, checking out wiki if I have a question about tagging or so…).
In both cases, as I upload my contributions, I “sign them proudly with my username, for others to enjoy.”
Edit: Enjoy, yes, but especially in the case of a “first draft” (which should be something like “B+ or better quality”) for others to potentially improve, too.
Some renderers have handled industrial= on it’s own for ages - see e.g. mine here.
It’s not that uncommon - try moving this overpass query around.
This needs to be clarified: The wiki said that this tag is not a primary key which can not be used standalone before some kind of edit war started on this page. Wiki page for Key:industrial has been completely rewritten. Was this discussed or voted on? (for anyone not following)
Same landuse=* inside another landuse=* is somewhat acceptable (ditto for =residential) , but is fundamentally only a workaround for the lack of suitable feature tags. I avoid it as much as possible, only using at the largest functional level (individual industrial parks, or “plots” when standalone). landuse= is a homogeneous statistical classification of the land (effectively a paint on the map). Other than a few viz =works , There is no man_made= feature to act as the PoI for many industrial= facilities.
While I generally agree with all of your post, there is this sentence which merits attention, IMHO. “Zoning” is about the permissible landuse, it is a planning instrument, what we are recording with landuse is the actual current landuse as observable on the ground. This may be about the same in many regions, but it could also considerably diverge in other places, so it is important to note it is the actual landuse, not the permissible.
I offer huge gratitude to you for making this distinction. Yes, I was lazy in conflating zoning and landuse, as that has been done in OSM around here (USA) and in fact an early “clean up” I did was somebody who had imported (circa 2009) the Zoning polygons from my county GIS into landuse=* tagging, and I’ve literally been cleaning it up for 14 years.
You are both correct about “this may be about the same in many regions” as well as “it could also considerably diverge.” You make the critical distinction between the two as landuse=* being actual landuse, while “zoning” (and this varies quite a bit depending on state and local laws) is what is permissible landuse (by law). Sometimes the same, sometimes not, occasionally conflated around here, conflated by me earlier, though I shouldn’t have done that. Thank you for your clarification, I’m sure I’m not the only one helped by you pointing this out as you have.
We use landuse=military to tag a large area (perhaps along with military=base) but contained within that area are often multiple independently tagged military=* items (e.g., barracks) for which we do not duplicate the landuse tag.
In theory, I see no reason why it should be any different if there are genuine uses of an industrial= tag.
I like that one - unfortunately not available for my area. … 
I also agree with @dieterdreist but nevertheless I got your point anyhow … 
The difference is industrial= grew under landuse=industrial , and remains the dominant use. The 2nd most common combination is double-tagging with man_made= or craft= . What’s left without having any of them is only ~14k = ~5%. The 3k node in this is related to whether landuse= can be used on a point (which is acceptable to me, same as building=).
In comparison, military= has been used as features early on, eg =trench . That being said, there is some overlap of military=bunker (that’s ~52%) with building=bunker depending on how it should be defined, as Proposal:Military bases - OpenStreetMap Wiki has changed =barracks to be for buildings only. Same for it suggesting office=military instead of military=office .
military=airfield has also been asked on its combination with =aerodrome . Talk:Tag:military=airfield - OpenStreetMap Wiki
I don’t see a particular problem with one landuse=industrial and industrial=* polygon or landuse=industrial and and man_made=* polygon being inside another landuse=industrial polygon, with the former indicating a specific industrial use and the latter that there is general industrial use.
Similarly, I have no problem with landuse=grass Way: 29094789 | OpenStreetMap for a neighbourhood green space inside landuse=residential. or landuse=retail Way: 276177733 | OpenStreetMap for neighbourhood shops within a larger landuse=residential area.
The definition of the landuse key is according to the wiki:
“Mainly used for describing the primary use of areas of land. Show/edit corresponding data item.”
Please emphasize “primary” here. You cannot have two primary land uses at the same time. This rules out an overlap of landuse areas.
Similarly, I have no problem with landuse=grass
because “grass” is not a landuse
It’s true to say that “landuse” in OSM is supposed to be fairly broad-brush, but I think it’s possible to be a little over-zealous, especially when it comes to interpreting what someone’s written in the wiki.
I can think of plenty of examples of multiple overlapping landuse - this afternoon I walked through an area that has been engineered as a basin to store floodwater (a natural dip has been increased, and clay’s been used to control drainage). When not full of water, it’s also got sheep grazing there. Further up the same river, a new floodwater storage scheme is been engineered as a wetland wildlife habitat.
note “mainly” and later explicit mention of possibility of multiple overlapping landuses.
Maybe it should be made even more visible.
Yes, but with an example so that this restriction becomes more tangible. Namely, for example, a playground in a landuse=residential. Not two landuse=industrial on top of each other. That is a very big difference and, in my view, the latter is no longer covered by this exception.
This was my point of view for quite some time but I have to admit that there are cases where an area cannot clearly be assigned to one landuse only. The best example imho are military areas which are used as managed forests as long as there is no military training going on. Or
In some of these cases one can avoid using 2 different landuse tags for the same area by using some other tags like natural=* or water=* or leisure=* as workaround but that is just a formality - fact is that some ares are subject to different landuse changing time by time.
Nevertheless I would always try to avoid overlapping landuse as far as possible.
Agreed, that’s how I see it in general and many mappers do so as well but I understood (from some of the earlier comments) that others see the broad coverage landuse as a first mapping step, possibly being refined later into more detailed coverage landuse mapping.
So the rule is: go ahead one way or the other.
In the USA, there are many instances (especially in urban areas / central business districts) where a single “site,” a building, usually, is what we call “mixed use.” For example, my little city has what many decades ago was an old leather tannery, but over the last decade or two has been redeveloped into an “arts district,” where the old buildings are part live-in industrial space (for artists who lease industrial space in lofts where they can craft things like glass-blowing art and metal casting), while also having small residential apartments where they live. Additionally, there are (rather nice, high-end, “High Street”) kinds of shops where the art is displayed and sold. Restaurants and public theatre space round out the amenities, so it truly is all of commercial, residential and industrial on one site (in a couple of cases, on different floors of the same building). The solution here seems to be similar to other tagging in OSM where “the highest, most intensive usage tends to dominate the tagging.” (For example, in rail tagging, a railway is tagged usage=main instead of usage=branch even as the latter might seem more correct, because a line is a heavily-travelled passenger rail, it gets main). So our Tannery Arts Center (remains) tagged industrial, even as it also has (pockets of) commercial and residential landuse on-site.
Similarly, my little county has areas that are “zoned residential-agriculture,” roughly meaning a family farm (farming occurs, but there is also an area surrounded by landuse=farmyard which has a house, barn and other appurtenant structures for farming, or living, such as a poolhouse to house the machinery to filter / heat the water and offer clothes-changing cabanas).
So, you absolutely can have two primary land uses at the same time, even in the same building, for example on different floors. Mostly, “pick one,” again, it has emerged as an OSM convention to use “highest use” (often industrial) when there is a choice. This isn’t limited to big, urban centers, either: there are many, many small towns across this country where a shop exists at the ground level and the owners / proprietors live upstairs. There may also be a “shop around the back” for maintenance / repair which could correctly be classified as industrial landuse, so again: a “three-in-one.” In that case, I’d tag landuse=commercial, as that predominates.
The point of conflict there is that the landuse key indicates either land use or land cover, because attempts to split out a separate landcover key haven’t quite succeeded yet. This is on top of the conflict between using landuse areas to paint broad swaths of the map that are contiguous by happenstance, versus using the same key to indicate the land use of a specific site.
The broad-brush approach is entrenched in large part because renderers treat landuse as a thematic layer. If we were to rationalize landuse tagging to focus more explicitly on answering “What is it?”, then landuse=industrial would be replaced by a number of tags under man_made=* and a few other yet-to-be-coined keys. Former landuse=industrial areas would have quite different tagging than former landuse=commercial areas. This would be frustrating for traditional OSM rendering stacks as well as anyone coming from a GIS background.
On the other hand, the more granular land use areas often represent hard-won local knowledge about both the land use and the edges of that land use, which can’t easily be detected from aerial imagery using machine learning. The broad-brush land use mapping should never come at the expense of this valuable data.
I partially agree. If I map a named development that’s already covered by a broad-brush land use area, I go out of my way to cut out a piece of the existing land use area to avoid overlap.
On the other hand, if I’m mapping some even more granular land use within a development, such as a golf course, waste dump, or residential subdivision on a military base, I won’t cut it out of the military base, because some overlap is fine in these cases. Think of the smaller land use area as an exception to the larger land use area. Renderers can follow the example set by osm-carto, which automatically prioritizes rendering the smaller area over the larger areas.
