Oh, dear Andy our Support moderator, thank you for both your reminder of the longevity of this issue (and related ones about tag deprecations) — I remember 2010 in OSM, too — as well as your helpful personal experiences.
Taginfo “registrations,” GitHub project links that foster good communication and many other earnest, genuine attempts at “reconciliation” (for lack of a better word, though “harmonization” also gets close…I know you might prefer the z be an s) and more are all important ingredients at how this continues to move forward.
Though, for now, may we split this topic into a new one that is more aligned with tag deprecation and let this topic continue to discover (and accept) that the Feature Proposal that it purports to be about simply isn’t viable? Thank you.
You are thinking along the right lines, but retooling the API endpoint alone is insufficient. You would need to consider all the pipelines through which data consumers get their data. At a minimum you’d need to distribute parallel planet files and diffs, and likely stand up parallel overpass services to cover the most common pipelines.
All of this is assuming that the problem we identify is worth all this effort
Where is that emoji reaction when you need it… Anyway, might I suggest splitting that area data type part of the discussion to another subthread?
Sure, but only because (as you said) it has neither area=yes nor area=no tag. If you know of the real situation, you could just add area=* tag, and the problem would be solved, right? Or am I missing something else there?
And it could be done, in my opinion, without an API change. You could have some code between the API and the database that rejects changes that turn a valid multipolygon into an invalid one. Because really, we have areas, they’re just multipolygon relations that have no integrity guarantee. The difference between not allowing users to break multipolygon relations and actual area types in the API is, in my opnion, just syntactic sugar around the core problem of ensuring data integrity.
Of course, like this proposal for landcover, areas aren’t that interesting because they doesn’t solve a significant problem. After all, data consumers are handling areas just fine – though a little extra data integrity would be nice.
Actually, can we rename this thread to “idealistic ideas to improve OSM” ?
We could try and “make a rule” that all areas need to be mapped as relations (not ways), but I suspect that there would be considerable resistance to that change…
(for the avoidance of any doubt I would not be in favour of any such rule)
For further avoidance of doubt, you could include closed ways with area=yes or with tags normally associated with areas in that syntactic sugar. Really, rejecting obvious errors like area=yes on an unclosed way is something the API could do today with no API change.
Heck, we could make the API accept landcover=trees but silenty write natural=wood to the database. I’m not sure if that would make the proposers happy or sad though…
Circling back to the landcover proposal V2, I think a tagging overhaul with deprecations and redoing stuff is not viable.
Looking at the proposed new tags, I think the important targeted OSM features all belong to the “natural” category. The natural object category is meant for feautures that grow or flow by nature. Even when shaped, originated or maintained by humans.
Therefore my preference is to use the natural key for all elements for which a landcover tag was proposed. Most already have an existing natural=* value in wide use.
That is why I asked: a new primitive? That would get us: nodes, ways, areas, relations. Some would like to remove nodes that are not POIs from the list…
No, a fenced park is not a fence the size of a park. Area or circular way is better handled in geometry rather than semantics.
I ask that “the topic and channel” tighten up towards order. There is a lot here, let us continue to discuss and digest. A nearly-year-long dialog (which goes back “decades” even if that is only 1.4 decades). This could split in many ways, there is a first and maybe second to do so, it could also explode into myriad topics for those of us (and many more) who pay attention. Drive it back to landcover v2 taking an exit, please.
The least we can do is “steer it back” to the instant topic, which appears dead on arrival after nearly a year and 200+ posts. There are moderators, they know how to steer things back onto a highway.
Sure, that is why area=* key has both no and yes values; so you can apply correct one. If that fence is not an area, you could add area=no to indicate that in no uncertain terms, no?
this is not a feature I am waiting for. The Api should not modify tags but just literally accept any tags you send, or the any tags you like concept would not work any more.
I think the peeling away (up, up and away) of layers of this has begun. Keep up the good work. It is work to do this, but we are harvesting some gold and silver here, this can be spun into wisdom if we do it right.
We are literally full of good ideas and meritocracy-based methods of promulgating the many seeds since being broadcast about this might grow, flourish or wither. Moderators do nourish such gardens; I thank them for their careful, deliberate teasing apart of things and allowing other topics to take root elsewhere.
It’s called “winding down” and it’s good to see it being done carefully. Oh, yes, this is certainly a group effort!
I think the answer is that “natural” implies that the landcover is indeed natural… that the trees just grew there of their own accord. “landcover=trees” implies that someone planted them… that it’s managed, like a tree farm.
Yes, this is indeed also what I thought, landuse=cemetery has a high chance of having smaller landcover=graves inside of them.
While it is true that if you expand the definition of natural many items that are proposed from landcover can fit inside of natural.
However, for some items this limits the mapping potential, take for example a named heathland mapped as natural=heath. Many heathlands are not 100% covered by heat plants. There might be tracks running through them, or patches of sand.
With separation of landcover and natural entities you can split the exact cover of the heat plants (landcover=heath) from the rougher area of the natural entity (natural=heath).
This may sound uncommon however we do this already for other situations like squares. Many squares are manly pedestrian areas; however, they can also include greenery or fountains. To include these items onto the square the named place item place=square is separated from the pedestrian walk able area highway=pedestrian+area=yes.
this is not what I would expect from “landcover”. Graves are under the surface, you cannot see them, you can only see the plants growing on them, the tombstone, etc. (ok, we might consider all this together “the grave”, but in terms of landcover, I would rather describe these physically (plants) instead of functionally (grave).
landuse=cemetery would have smaller polygons (patches) tagged with cemetery=grave (and/or historic=tomb), and those smaller polygons might additionally be tagged with landcover=* (or surface=*, for those who dislike landcover) with value of e.g.:
In other words, if one is about to use landcover=*, please use it only to describe the material that is actually covering that specific patch of land, eh? Not the function of it – doing that does not make any sense at all, and would destroy any credibility that landcover=* tag might have left.
Because what would be next in the line if landcover=graves would be OK? landcover=pitch? landcover=parking_space? landcover=restaurant? landcover=mailbox? landcover=motorway?
emoji reaction when you need it… Anyway, might I suggest splitting that 
icon and suggest splitting topic?
.jpg){kind=link}
