[RFC] Feature Proposal - landcover proposal V2

General talk Tagging general discussion
,
203

Then, solve it, and be prepared to show your work. Whether this is a dismissal or a call to action only depends on your personal level of interest and motivation to roll up your sleeves and demonstrate a solution. I’ve certainly been told that “if you don’t like it, do it better” and then gone off and done so on this project. I’ve built software, executed hard tagging changes, and spoken at conferences and on YouTube on my exploits. And, I’m nobody. Just a hobbyist that felt like it.

Your language is in reverse, I think. OSM is not some entity which you sit outside of and chastise it to do better. OSM is you. It’s me, it’s @stevea, it’s @SomeoneElse entirely. It’s a software developer, an end user, it’s the OSM Foundation Board, a working group, a local chapter, an activist, a hobbyist. It’s nobody in particular. But it IS individuals that have seen problems and said “I can do better” and come up with the goods. That’s the reality in a decentralized project.

“OSM” doesn’t undertake anything. Individual contributors do.

1 Like
204

true, but is them up to them to find and fix the issue before distributing updated dataset to their users.
IOW, (theoretical) improvement of using such dataset would be that when tagging style changes, only one place (Overture or whoever) has to worry about it and do backwards-compatible fix; instead of every data consumer having to handle it.

Of course, it also creates another set of problems, not least of which being that tagging structure is ossified there, and you can not do any improvements in data tagging, because if you change or introduce any new type of data, you’re back on square one. Also since one had to check if there has been vandalism or new or changed tags before releasing, there would be delays in updated maps, but that can be an advantage too sometimes.

An actual versioning and backwards compatibility solution for OSM would allow a period of time where mappers could submit either v1 or v2 tags to the API and consumers could get data out with either v1 or v2 tags. A translation layer on both ends would be required. With the tag agnostic philosophy of the project this seems unlikely to happen.

If someone would like do such translation (which I don’t see as an idea with particularly useful); may I recommend (instead of such ugly extra-tag-prefix/suffix kludge) to instead create new API endpoint instead.

e.g. currently this API endpoint https://www.openstreetmap.org/api/0.6/relation/5876272 returns some XML. One could easily create implement translator API at https://whatever.example.com/api/0.7/relation/5876272 which would return that object in the way that they find preferred (e.g. replacing all natural=wood or landuse=forest to landcover=trees or whatever other change and reasoning one might have to deprecate/rename tags), e.g. it would “translate” regular OSM-ATYL-tags to my-more-rigid-and-clearer-set-of-tags, like this:

<?xml version="1.0" encoding="UTF-8"?>
-<osm version="0.6" generator="CGImap 0.8.10 (412697 spike-07.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
+<osm version="0.7" generator="My New Cool API 0.9.37  (116321 whatever.example.com)" upstream="CGImap 0.8.10 (412697 spike-07.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
 <relation id="5876272" visible="true" version="6" changeset="118694112" timestamp="2022-03-20T12:24:14Z" user="Muki Mačković" uid="3636444">
  <member type="way" ref="87194173" role="outer"/>
  <member type="way" ref="392034935" role="outer"/>
  <member type="way" ref="753330854" role="inner"/>
  <member type="way" ref="1041941121" role="inner"/>
-  <tag k="landuse" v="forest"/>
+  <tag k="landcover" v="trees"/>
  <tag k="name" v="Park šuma Grmoščica"/>
  <tag k="type" v="multipolygon"/>
  <tag k="wikidata" v="Q97353235"/>
  <tag k="wikipedia" v="hr:Park-šuma Grmoščica"/>
 </relation>
</osm>

Then people can then easily change their JOSM (or whatever) configuration to use that new API endpoint; and enjoy in their new&improved OSM tagged worldview.
The same modifications (if wanted) can be made for objects being PUT on the server, if you prefer to upload only the “new and better” tags instead of the equivalent-tags that user has specified (you probably should create an explicit changeset tag that indicate you did such auto-translation, though)

The best thing? One can do that right now with minimal effort (certainly one or more orders of magnitude less effort than this discussion has entailed so far), and one can test and develop such project on any small server/VPS, and gather smaller (or bigger) number of enthusiastic beta-testers to improve and test it before proposing it as an official one. And even if it is not accepted as official one, who cares? The ones who elected to use it would still reap all the benefits that such tag deprecation/renaming (supposedly) entails.

3 Likes
205

I think you should look at the context of both times I posted those suggestions; the first time to exemplify that it is (or might be) possible to have a scheme that allows changing tags in a consumer-friendly way, the second time to exemplify other alternatives to prefix/suffix versioning.

I’d love to take a stab at this in a more serious manner, but considering that I already have two rather major OSM-related projects I’m working on right now which are already consuming most of my free time I have to politely decline.

I was referring to OSM as an “organism” or a community, as this is not something any one single person can do. Sure, it will require one or a few heroes who pull the community together around the task and do a large share of the work, but in the end it will go nowhere without the involvement of a large part of the community.

Do note that your comment comes across as somewhat condescending. I’m well aware what drives a project such as OSM forward.

1 Like
206

“landcover vs landuse” has been debated since at least 2010. This particular thread isn’t even a year old yet. :smiley:

OSM (with its completely free tagging) has succeeded where other competitors have failed, just like wkipedia succeeded after nupedia failed.

What’s allowed OSM to be successful is allowing anyone to describe their local area so that they, or other people, can make a map from it. Restrict that, and you restrict what people can map - which wouldn’t be a good thing. That doesn’t mean that there can’t be a role for a set of data with a more or less fixed schema so that the problem Brian described above is less of an issue, and yes, the schemas for OpenMapTiles et al do intend to nail things down a bit so that a consumer of (say) vector tiles claiming to be using OpenMapTiles’ schema don’t have “lots of data suddenly missing” - but what Zeke said above is true - and it does mean that if people suddenly have the urge to change the tag in OSM for concept X from tag A to tag B, they’d better have a pretty good reason. One to one changes that literally add no value are NOT a good reason.

Maybe an example would help. I look after a couple of different sorts of maps - web based ones (click the changelog link to see more details and links to the sources of the components) and Garmin / mkgmap ones, source here. Where possible both use more or less the same schema, so that the way that I round up all possible taggings of (say) “broadleaved woodland” is the same in both cases, but the resulting map style code is very different…

If someone decides to change all tag A to tag B in the data, each map will just “see fewer examples of broadleaved woodland”. I’ve seen that happen with embassies, hill forts and pinfolds. That’s despite both those map styles being registered at taginfo, with a link to both github projects so that people can create an issue saying “I’m proposing to change tag A to tag B” alongside anything else that might apply.

3 Likes
207

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.

1 Like
208

I’d love to see a feature proposal that genuinely added value - how about an area data type? :smiley:

209

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 :slight_smile:

1 Like
210

You mean a primitive? I am aware of node, way, relation. Out of the relation type, multipolygon as far as I can tell only ever maps areas.

I think mapping intent is missing from the list.

211

8 posts were merged into an existing topic: Suggesting area data type

212

Where is that :popcorn: 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?

1 Like
214

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” ?

:popcorn:

216

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)

217

Can someone then create another topic with “idealistic ideas to improve OSM” or should I?
So as not to divert the main topic here.

218

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…

219

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.

220

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.

221

Ladies and gentlemen, please.

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.

I, too, am “simply a mapper” here.

222

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?

I did suggest to moderators to split to separate topic at [RFC] Feature Proposal - landcover proposal V2 - #208 by SomeoneElse, but nothing happened so far. Perhaps more people should click on that :black_flag: icon and suggest splitting topic?

1 Like
223

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.

3 Likes
224

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!