Mass remove `gnis:created` and similar tags? [final version presented]

Would you consider removing of gnis:created | Keys | OpenStreetMap Taginfo and other similar tags as welcome and useful?

I think that OSM data would be improved by removing them as

  • they are being removed from OSM anyway (see gnis:created | Keys | OpenStreetMap Taginfo )
  • they are confusing, pointless and not needed
  • and therefore makes harder to edit in tag mode and view tags
  • their presence encourages to import other useless tags during other imports
  • mappers spending time on reviewing their status, deciding whether to delete them, deleting them manually
  • people asked to review edits spend time on pointing out that these could be removed (that is how I noticed this tags)

Therefore I am proposing to remove:


And gnis:Class=* and gnis:feature_type=* - where entirely duplicated by existing OSM tagging

with an automated edit.

What you think about such action?

(was discussed a bit at Slack )


I figured that this would usually be the case, since the feature’s original feature tags were based on these fields. To the extent that the feature tags have changed, it was probably intentional (for example, retagging leisure=park as leisure=nature_reserve). What’s an example of where you wouldn’t delete one of these tags?

1 Like


I’m in favor of removing all of these tags.

The county and state information is redundant since we have county and state boundaries in OSM. And it’s probably wrong half the time where features span boundaries.

I’d still delete gnis:feature_type from node/369153637 since even GNIS doesn’t provide enough information to determine whether this feature is a quarry or a mine. You have to look at other sources like USGS Topo to make that determination.


It is not uncommon for these tags to be wrong. For example, a “park” can either be a recreation area - such as a national park - or a valley, but there are many cases in GNIS where valleys have been mis labeled as recreation areas.

1 Like

There are cases where the gnis:feature_id tag ended up on the wrong element in OSM, but these cases are generally not resolved by keeping the gnis:Class or gnis:feature_type tags around.

At that point, the tagging is messed up anyway, so there’s no reason to trust that the class/type tags are correct. Resolving issues like this usually means going back to the original GNIS record and/or reviewing OSM history to see what happened and how to fix it.


in this case it is deleted manually - with review. I do not want to mass delete from such cases in fully automatic fashion without review.

If you change your mind, you have my blessing.


I fully support removal of those tags - I’m always manually removing them already when I edit GNIS features.

However, because they don’t really hurt other than being annoying, I don’t think a mass edit is nessecary here - those tags should simply be added to the discardable tag lists for iD and JOSM instead, so the tags are automatically removed whenever someone edits/actually improves an object with those tags. This is already done with various other useless tags added by imports.
Keep in mind that a mass edit would impact +700,000 features, which have the tags proposed for removal here.

1 Like

main problem with this approach is that these tags will still show up in tag list in iD ( see Stop showing discardable keys like created_by · Issue #9854 · openstreetmap/iD · GitHub )

What’s the practical problem with these tags appearing in iD’s raw tag list? That list is intended to be a raw representation of what’s actually in the database or, after editing, what will be saved to it. Most iD users never open that section of iD’s sidebar, so if anything, it’s more of a problem that the discardable tags show up when browsing elements on the main website.


not sure how popular it is but I commonly edit by editing raw tag list and presence of gnis: tags there is exactly what triggered this proposal.

I am team if these are useless, let’s remove them in a big edit and be done with it. Is there a compelling technical reason why some number of objects (700,000 in this case) shouldn’t be touched? My impression is that this amount of fiddling is completely reasonable traffic in the db.

1 Like

It makes it a little more difficult to tell what hasn’t gotten edited since the import. But it wouldn’t be nearly the first time GNIS features have gotten touched en masse anyways. A thorough query would have to look at history to be sure.

“traffic in the db” is not a problem at all

Reasonable objections that I am aware of include:

  • resets “last edit time”
  • messes up history (though removal as discardable tag in unrelated edit does not seem to be better)

anything else?

Bumping this old thread with a summary after skimming it again. Feel free to let me know if I’ve misinterpreted something.

It appears that there are no strong objectors to removal of this tag. There are a decent number of folks that are strong supporters of the proposal to remove all gnis:+ tags that are not gnis:feature_id.

Currently no one is signed up to do this work but if someone wished to proceed that would be okay. (feel free to vote :+1: :-1: in the reacts to this last sentence to get a rough consensus)


Strictly speaking I planned to do this, but would not be sad if edit itself would be run by someone else (I am definitely not in danger of running out of things to improve in OSM)


Did someone say “mass edit”? :eyes:


It looks like a couple of people implemented some sort of mass edit, although the changesets are so large it’s hard to analyze them. See for example Changeset: 147973766 | OpenStreetMap and Changeset: 147953938 | OpenStreetMap. For posterity’s sake, can those users (I see @ablevi202 and @Friendly_Ghost at least) document here or somewhere else exactly which tags they removed in these edits?

1 Like

I removed all gnis: tags except gnis:feature_id, gnis:edited, and gnis:reviewed.

Therefore, this is the whole list of tags that were remvoed: gnis:fcode gnis:ftype gnis:created gnis:county_id gnis:state_id gnis:county_name gnis:feature_type gnis:import_uuid gnis:County gnis:ST_num gnis County_num gnis:ST_alpha gnis:Class gnis:name gnis:Cell gnis:ST_alph gnis:ufi gnis:uni gnis:state gnis:county