piebro/osm-data huggingface dataset:
Adamant1 (2019-11-14 08:12:33+00:00): Really? Why's that? Show me anywhere in the OSM guidelines where it says GIS "MUST!Q!!!!!!@#!#$@$" be PRESERVED!!@!!!!!!. People delete them in all kinds of situations all the time (for instance with TIGER imported roads). As they are essentially useless and just make it harder for people to edit things or understand what they are looking. 

You seem to say a lot of stuff, but don't back it up with any supporting evidence. At least I'll quote a wiki page here and there in between my ranting.
freebeer (2019-11-15 11:42:22+00:00): adman, calm down and lay off the methanol.  unlike the 20 to 30 per day fortified added-sugar beers i've resorted to for lack of good Reinheitsgebot beverages, i'm sure it can't be good for you.

TIGER roads probably do not have GNIS data.  tiger was an import with a lot of questionably-done things and changesets that added a lot of useless metadata.  tiger tags are partly automatically deleted, even in cases where i've found them useful for after-the-fact troubleshooting.  and a lot of obsolete and irrelevant tiger tags don't get touched with updates, probably because like maps.me mishandling the `name' key, they are hidden from the casual editor.

There is not a single GNIS tag remaining after you have removed them, losing the origin of the data.  there have been repeated cases where i have resorted to googling the gnis:feature_id value in order to check the data in osm, if it reflects the current reality or if something somehow went wrong with a node located offshore, several metres from its NADxx (versus WGS84) coörds but not making up for several dozens or hundred metres off from any logical position for an on-shore landmark.

the gnis:created field gives a further clue to the data, not reflecting the import time.  if the object was created long ago but is absent in the oldest bing clarity images, it's reasonable to make further assumptions about it.

now the county_id and state_id, the two other fields you deleted, aren't that useful other than as a sanity check, and aren't too different from the tiger tags that i've seen be incorrect in the original data on occasion, in coded form.

to leave the tags present helps a mapper looking at the data after your edit to know the origin.  if you've deleted them, i assume you've taken due care, but if other mappers delete the tags out of principle while armchair mapping, one has to look into the history to see whether a mapped feature is plausible, if it's likely to be mislocated, if someone nuked the `(historical)' label without understanding what it means to geonames, or what.

in short, the feature_id is unique to a gnis item, can be searched, and i feel it should be preserved for the reasons i've given and used repeatedly, pointing to its mechanical import origin and raising instant defences and wariness about blindly trusting the data.

i can't point out any guidelines and i don't feel it is worth searching, because it seems so blindingly obvious that it's useful metadata outside of an osm object property.  even if you claim it's useless.  let me point you at massgis tags that make navigating object properties a pain being uppercase and appearing early.

whatever, a lot of osm guidelines or rules have never been codified, or have been mealy-mouthed (use of `should' where due to abuse i'd interpret as a MUST in order to get along with the larger community, f'rinstance), that it sounds to me you're attacking the messenger rather than absorbing the message here.

i'll shut up and wade off to try to find some beer and watch the torrential water of the last three weeks continue to take away large parts of the ravaged hillsides.
SomeoneElse (2019-11-17 17:08:01+00:00): Hello, Andy from OSM's Data Working Group here.  Echoing freebeer's comments it'd be great if everyone could calm down a bit.  

Firstly, the historical tags on objects can be seen at http://osm.mapki.com/history/way.php?id=283793237 .  In this case someone expolicitly added them in http://osm.org/browse/changeset/31255848 (perhaps as a result of a merge?).  

Generally speaking, there isn't really a rule worldwide that says that external keys for wherever data happened to be sourced from (and in this case, this park existed without GNIS info for some time).  GNIS in the US is a bit problematic because quite frankly some utter rubbish has been imported from there.  If anyone has a particular reason to keep tags like "gnis:created" around then please do explain that, and link to where it was discussed with the community.  I know that the US community has more imports to deal with than others worldwide (for various reasons that we don't need to go in to here), so it may be that this has been discussed before.  If that's the case, please do link to that discussion.

I'd also suggest that changeset comments are a bit more descriptive than just "fixed tags", although I understand that typing in some more verbose text every time is a pain.

Best Regards,

Andy Townsend on behalf of OSM's Data Working Group
UAN51 (2019-11-17 21:25:43+00:00): Well, here's the wiki page about GNIS https://wiki.openstreetmap.org/wiki/USGS_GNIS and https://wiki.openstreetmap.org/wiki/United_States/Data

"The Geographic Names Information System (GNIS) is the authoritative database on place names. The tags may possibly be imprecise in position, so GNIS-tagged features should be corrected for position and especially name, keeping the gnis:feature_id=* tag intact." (from the 2nd link)

Only delete the GNIS tag/place IF AND ONLY IF the place no longer exist (or alternatively add "historical" to the name).

"The Feature ID uniquely identifies a feature in the GNIS database and is thus the most important thing to tag when relating an OSM feature to a GNIS feature. The tag gnis:feature_id is by far the most commonly used for this purpose." (from the 1st link)
Adamant1 (2019-11-17 21:37:35+00:00): Sorry for the heatedness on my side. It just seems like there's been an almost constant onslaught of people taking issue with things that aren't issues in an extremely passive aggressive manor. Which has just put me on edge. In this case use of capitals and exclamation marks in UAN51's message seemed overly aggressive and set a bad tone IMHO. My response was more mocking it then anything. 

I'm also dealing with people in changeset 77110404 who immediately reverted my edit and accused me of doing vandalism that supposedly caused serious damage OSM, because I deleted a grassy area that I planned to map more accurately. Which the user who reverted me even said could be mapped better. I probably could have responded better there to, but whatever. Getting reverted and called a vandal for nothing won't exactly put someone in a great mood. 

Things are just pretty ridiculous at this point and I'm getting extremely tired of it all. Especially when it comes to people who rely on imports. They rarely seem to go through the proper procedures, mostly don't care about normal tagging conventions, and often get extremely upset when anyone touches their "work." All of that's a generalization of course, but has largely been my experience. Anyway, I'll leave it at that and wait for UAN51 to respond to SomeoneElse before adding anymore, likely useless, commentary.
Adamant1 (2019-12-05 02:58:24+00:00): A few thoughts about the GNIS thing now that I have looked into is that the only reason given for why we shouldn't delete GNIS tags is because "GNIS if possibly the only database in the US to share work from OSM." I'd say 

1. In both instances of that being mentioned  the sentences were entered in 2013 or before and there is no discussion about it anywhere that I can find. So I wouldn't call it authoritative or relevant to current tagging practices. 

2. GNIS tags where added by multiple users, from multiple imports, over multiple years. Both before and after 2013. So there is no "unified field theory" of how to treat the GNIS tags in all situations. Since hey were added by many different people, with different priorities, and at least some cases where only added as a by product of importing the main data. Not as a thing themselves, but were just never removed when they should have been.

3. The reason original and only reason of saving the tags for "feeding the data back to the USGS after improving it" is clearly out of the intent and purpose of OSM. Plus, it probably violates the TOS. If I didn't, I doubt there would even be community support for it anyway. If there is cases where altered data in OSM has been fed back into the USGS map I'd like to see them and actual mailing list discussions where it was approved. 

Given those points, and the lack of any other good reason not to, I say the tags are deletable and that's what I'm going to continue doing until there's a valid argument not to besides "because I say so." They are being deleted all over the place by users anyway and personally I think it's for the better. We shouldn't save every ancient, obscure, leftover tag "just because."
MikeN (2019-12-05 04:08:20+00:00): There was some talk of exchanging GNIS updates with OSM, but once the current OSM license terms solidified, it's clear that it would not be within the OSM data license terms.
Adamant1 (2019-12-05 05:16:38+00:00): Thanks for the information. That's what I figured.
UAN51 (2019-12-08 00:28:42+00:00): Anywhere on the wiki or someplace that discuss about removal of GNIS? I'm only seeing wiki pages that says to keep them.
Adamant1 (2019-12-08 03:00:51+00:00): I don't think there has to be. The responsibility is on you to justify why the tags shouldn't be deleted. As Andy said, "If anyone has a particular reason to keep tags like "gnis:created" around then please do explain that, and link to where it was discussed with the community." You both failed to explain why the rubbish tags should be maintained (the reason given in the wiki is clearly outdated/not valid/or based on census IMO) and haven't link to a discuss that provides either community buy in or a good justification/use case for keeping the tags. Given that I see know reason not to delete them, or even continue this discussion about it. Feel free to start a conversation about it on the tagging mailing list and if you get buy in from others about keeping them I won't delete them anymore. 

Until then though, I'm not going by some ridiculous standard of having to link to somewhere to qualify removing rubish. Otherwise, I could just edit the Wiki to say the tags can be deleted and get on my with life. Since it would hold about as much weight as one person in 2013 saying to keep them.  

Btw, in the gnis:feature_id it says
"Please do not remove this tag from an object without understanding the implications." Not "DON'T DELETE THE TAGS EVER" as your insinuating. So there's that. It's clearly not as cut and dry as your making it. Plus, I 100% understand the implications, absolutely none. There are also a darth of discussions out there about cleaning up old/obsolete/not used/undiscussed etc tags from old imports/general edits/etc etc more generally. Which I don't feel the need to link to. Since it's pretty much common knowledge that we do that and Andy didn't put the responsibility of proof here on me anyway.
Adamant1 (2019-12-08 03:27:42+00:00): UAN51, go to https://taghistory.raifer.tech/ and look at the tagging history for gnis:feature_id, etc. All of them where added in a single import in 2009, which contentious at the time and still is, and they have all been on a steady decline since then. The use of gnis:state_id has gone down by almost two hundred thousand since 2013 and has seen a more dramatic decrees this year then any other. It's obvious from the decline the community is cleaning up the tags. I only deleted a small fraction of them and you arguing me with me about it has zero effect on the overall trend toward getting rid of them. My guess is that if we actually had a mapping community in America, which these kinds of forced discussions about everything stifle, they would be completely gone by now.
Minh Nguyen (2019-12-08 19:21:24+00:00): The gnis:feature_id tag and its synonyms are also documented at <https://wiki.openstreetmap.org/wiki/Key:gnis:feature_id>. Unlike many other import tags, gnis:feature_id contains a stable external identifier. In that sense, it’s quite like a Wikidata QID, except that it’s the U.S. federal government’s canonical identifier for place names (replacing older schemes like FIPS).

In my own mapping, I’ve not only preserved gnis:feature_id tags when converting POIs to areas, but I’ve also manually *added* gnis:feature_id tags where there’s a direct relationship between the feature I’m mapping and the GNIS entry. For one thing, it’s a more explicit kind of source tag. Even when GNIS isn’t my primary source, it serves as a citation so that a far-future mapper will know for sure that I didn’t just make up a park, lake, or cemetery to improve my Pokémon Go gameplay.

So no, the GNIS feature ID isn’t useless. But if you feel strongly that gnis:feature_id should not go on this feature for some other reason, then please at least replace it with wikidata=Q49497832. Virtually all of GNIS has been imported into Wikidata (and the Cebuano Wikipedia); you can usually find the correct item by searching Wikidata for the GNIS feature ID. At least the wikidata tag leaves the “paper trail” that some mappers clearly value.
Minh Nguyen (2019-12-08 19:27:27+00:00): * virtually all parks in GNIS, that is
Adamant1 (2019-12-09 00:16:45+00:00): I appreciate you bringing that up. I didn't know it was an option. I have zero problem with converting them to QIDs where I can going forward. I only delete them in extremely rare cases anyway. I can't remember why I did here. I probably would have been cool with UAN51 just adding them back if his tone had of been better and if his changeset comment hadn't of been one in a string of other demanding messages including private ones where he made it clear that his issue had more to do with me editing things in "his area" without "consulting him first" then it did anything else. Plus, he said he was going to undo my "damage" over the holidays, whatever the outcome of the conversations was anyway. So, I was inclined just to blow him off about the whole thing. If he really cares about it though he should add a part to their Wiki articles about converting them to QIDs. Which is actually supported by a lot of things and has consensus behind it. Rather then keeping rubish tags just because like he suggests or deleting them in mass without converting them to something useful like the community is currently doing.
Adamant1 (2019-12-09 00:21:29+00:00): I had actually suggested we take it to the tagging mailing list to get it clarified better, but UAN51 said not to because it was "personal" and that he didn't want other people getting involved in it. So I never did. Looking back I probably should have though.
UAN51 (2019-12-09 04:05:37+00:00): Calm down Adamant1. I'm only doing what the Wiki says. If you actually clicked and read the links I sent above, you should have seen the part where it says "he tags may possibly be imprecise in position, so GNIS-tagged features should be corrected for position and especially name, keeping the gnis:feature_id=* tag intact. These corrections can be submitted to the USGS directly, and will also be shared back from OSM, making GNIS possibly the only database in the US to share work from OSM.[1] Because of this two-way connection, it is very important that GNIS features only be deleted or renamed if the feature no longer exists or the name is definitely wrong." or "The Feature ID uniquely identifies a feature in the GNIS database and is thus the most important thing to tag when relating an OSM feature to a GNIS feature." I don't know why you sound aggressive and condescending on this entire journey, even in our DMs. I've provided my reasons to keep GNIS, but you haven't demonstrated a good reason to delete gnis:feature_id. Deleting the other GNIS tags, I'm fine with (like gnis:state_id).

Now, I had no idea that QIDs contains GNIS data. I didn't bother to add QIDs for Happy Rock Park because no Wikipedia page exist for this park hence I assumed no existence of QIDs for this park.

I didn't take it up to the mailing list because of better methods of communication (like Slack or Discord).

I get OSM is "edit anywhere", but PLEASE edit in your own local area (or state) or areas you traveled. If I asked why you did the edit you did, don't be toxic about it. It's normal that I ask.
Adamant1 (2019-12-09 05:54:15+00:00): Hhhmm, it seems this park doesn't have a QID. Bummer. Oh well. It's not like it's in my state anyway. I don't want the locals here to go off me for editing things where I don't live anyway. "shrug." Maybe someone who cares about it and lives here can create one for it instead. Nudge nudge UAN51.
Minh Nguyen (2019-12-09 06:53:11+00:00): There’s nothing inherently wrong with contributing in an area where you don’t live or haven’t visited lately. That’s called armchair editing and I’m guiltier of it than anyone in this thread.

Once you get comfortable enough with OSM, you should feel free to fix what needs fixing beyond your neck of the woods. We don’t have a ton of mappers who live in the Ozarks, for instance, but there’s plenty to map there anyways.

However, all editing requires due diligence. I spent this weekend massaging flagpole tags around the country, including here in Missouri. Since I had zero local knowledge of any of the flagpoles, it was incumbent on me to squint at every available imagery source – and also keep my hands off any perfectly correct, valid tag, even if I wouldn’t normally use it in my own mapping. Circumspection goes a long way toward avoiding conflicts.

The worst GNIS tags have already been deleted by bots that were subject to plenty of mailing list debate beforehand. The ones that remain are either genuinely useful or so benign as to not really register on anyone’s radar. If the gnis:feature_id tag’s existence were really a problem, it would’ve been deleted by now along with the GNIS node tags.

There’s no hard requirement that a mapper copy over all the GNIS tags when transforming a node into an area. But if someone goes through the trouble of doing so, they’ve gone beyond the minimum requirements and it won’t break the map or mislead anyone as far as I can tell.

If you disagree with the status quo on GNIS feature IDs and would like to see them removed systematically, you should take the idea to a broader audience, whether one of the mailing lists or chat groups. If this park was an exceptional case where the individual GNIS feature ID didn’t belong, a note=* or not:gnis:feature_id=* tag would make that clearer. I don’t see the point in removing the tag selectively or haphazardly.

Changeset 78131764 adds wikidata=Q49497832 to the park as mentioned above. I found this QID at the bottom of <https://www.wikidata.org/wiki/Special:Search/2477746>. You can also search for the item by name using iD’s Wikidata field. Either way, you’d want to visit <https://www.wikidata.org/wiki/Q49497832> to be sure it’s the right Happy Rock Park.
Adamant1 (2019-12-09 07:07:11+00:00): Minh, I did do a search for it on Wikidata. I thought that entry was for a different park though. My bad. Thanks for adding it.
eggie (2019-11-04 07:38:46+00:00): Dag MWM,
Een crossing kun je wellicht beter alleen op een node mappen, want nu loopt de way nergens naar toe.
De routering gaat immers via de hoofdrijbaan.
Verder heeft het veranderen van gebouwen meestal weinig zin.
De verbouwing is al verwerkt in de BAG (Kadaster).. 
Je zou dan het gebouw ook opnieuw kunnen laten importeren via het forum van OSM. Verzoek in het draadje Verzoek BAG import.
https://forum.openstreetmap.org/viewforum.php?id=12
MVG,
Eggie
eggie (2019-11-04 07:48:10+00:00): De gebouwen heb ik nu goed gelegd conform de data van het Kadaster. Nieuwe import is nu niet nodig.
Als achtergrond gebruik ik dan de BGT omtrekgericht. 
Parallelparkeren langs  de weg is ook altijd weer een punt van discussie. amenity=parking is dan niet correct.
Kijk in de wiki naar parking:lane=   https://wiki.openstreetmap.org/wiki/Key:parking:lane
MVG,
Eggie
streinger (2019-11-04 12:06:38+00:00): Оставьте только правильное название с тегом name, если сейчас это "фасоль", значит только его.
az09 (2020-10-24 17:33:10+00:00): Спасибо за замечание, но простите претензии не ко мне. Это мапсми запутывает так. У меня интерфейс телефона на английском и поэтому видимо тег name не правится, а только name:ru. Там логика сложная, в зависимости от раскладки клавиатуры и фазы луны... Так что будьте осторожнее с ним )
streinger (2020-10-24 18:30:16+00:00): Что-то вы долго не отвечали, год прошел, уже исправили это название.
az09 (2020-11-04 18:42:30+00:00): Теперь бы еще и правильно исправить. Потому что внесенный мной график работы оказался стерт(
https://www.openstreetmap.org/changeset/76784439
streinger (2020-11-04 19:15:28+00:00): Эта сеть магазинов?  https://myfasol.ru/stores/  если она, то нет здесь его больше нет, судя по их сайту.
streinger (2020-11-04 19:18:44+00:00): неправильно я посмотрел, если она, то график с сайта добавлю.
az09 (2020-11-13 19:18:38+00:00): Она самая, партнерка Метро насколько понял. У нас в Магнитогорске только-только появляться стали, надо бы тоже поотмечать.
aixbrick (2019-11-04 09:42:40+00:00): Danke
mavl (2019-11-07 16:41:57+00:00): This changeset was redacted. Reason: copyrighted data were used.
user_5359 (2019-11-04 15:33:37+00:00): Welcome to OSM! I have delete your SEO SPAM (mostly no standard keys, no verifiable data or not positive verifiable address data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.
maraf24 (2019-11-04 18:40:21+00:00): Duplikat.
Андрей Первоуральский (2019-11-04 09:08:26+00:00): Господа, я лично отрисовал село Гора около Шамар! Почему произошло смещение домов относительно снимка, по которому собственно рисовал дороги, дома???? Кто-то приложил руку!!!!
user_5359 (2019-11-04 14:57:28+00:00): This change record should be reversed:  
*For one, the range of changes is too large, 
* parks are set as points, although they already exist as areas, 
* churches are created that are definitely not churches (company creates fans) and 
* the standards for the spelling of values are not met.
skquinn (2019-11-04 17:33:16+00:00): > *For one, the range of changes is too large, 

Yes, larger than normal, but going one state at a time was getting to be tedious and in many cases I was only finding one or two things that needed fixing.

> * parks are set as points, although they already exist as areas, 

If this did happen it's because a park node existed with an opening_hours tag and the park area was not. I am in favor of merging the fixed data into the area and deleting the now-duplicate node if that's the case anywhere.

> * churches are created that are definitely not churches (company creates fans) and 

Any such fake churches existed before I edited the service_times/opening_hours tag on them (or cleaned up things like invalid characters in description, which were a small number of the overall edits).

> * the standards for the spelling of values are not met.

I fixed as many of these as I could find but I wanted to get the fixes I had up before the data got too stale and I risked having to fix even more conflicts than I did.