Remove ref:gnis (org change to gnis:feature_id) in the waterway tagging options

[watmildon]

Discussion about the tagging of GNIS identifiers has settled on gnis:feature_id being the tag to use. (see: ​https://community.openstreetmap.org/t/cleanup-and-normalization-of-gnis-imports-to-only-use-gnis-feature-id-for-the-id-tag). Currently JOSM suggest ref:gnis (​https://github.com/JOSM/josm/blob/master/resources/data/defaultpresets.xml#L9820C68-L9820C68). JOSM should either remove the suggestion for ref:gnis or change the suggested tag to gnis:feature_id.

Definitely let me know if there are questions/concerns or if I've totally misunderstood something.

[taylor.smock]

Please update ​osmwiki:Key:ref (look for the ref:gnis entry). The ​osmwiki:Key:gnis:feature_id#Synonyms page lists the synonyms, which is good, but the synonym pages (if they exist) should link back to gnis:feature_id.

Also, I didn't see anything on the tagging mailing list about this. I'll wait 6 months to make the change so that people not involved on the community forum can give feedback or argue their case.

[watmildon]

Wiki redirects are fixed. I have posted about the GNIS work in the OSM US Slack and on the community forums with discussion ranging from last year. As it's a US only tag I will also mail talk-us to let folks know what has happened should they wish to comment. Fortunately, to date, no one has come defending the other equivalent keys and no one else wishes to do the work to move from gnis:feature_id to ref:gnis.

Is 6 months typical?

[taylor.smock]

Is 6 months typical?

For me, for tag changes, yes. I typically want at least one of the following:

• Wiki page definition has not significantly changed in 6 months
• A proposal to add/deprecate/remove the tag has passed with a sufficient number of votes and discussion and the wiki page has been updated
• The ​tagging mailing list has discussed it and come to a consensus and updated the wiki page

Other maintainers may have different criteria, but those are my primary criteria. Notably, I don't care about anything that is discussed on any country-specific mailing list or a forum (like ​https://community.osm.org ).

I'm open to using community.osm.org + wiki updates in the future, with the following caveats:

• I want to see a distributed backup system (the mailing lists have this in the form of individual email archives)
• There must still be a general post to the mailing list to let people know that a discussion is happening on the forums and an additional general post to the mailing list informing the mailing list that the discussion has ended, and what the conclusion was.
• Long-term support for the forum on the part of the OSMF; I think this is almost a given, but what happens if budget cuts need to be made? I anticipate the forum will be significantly more expensive to run than the mailing lists.

[watmildon]

Got it. I appreciate the thorough response.

[taylor.smock]

No problem. I figure being consistent and having those general rules saves me the trouble of dealing with a tagging war.

I often say something similar when someone makes a ticket saying "tag <foo> in JOSM doesn't match what it says in the wiki" or "the wiki now says that tag <foo> shouldn't be on the same object as tag <bar>", so I should probably have a text document with that response somewhere for easy copy-pasting. About the only real addition is the community.osm.org bit since you specifically called it out in the original ticket.

[watmildon]

Definitely. No reason for you to get stuck in the middle of a dispute. Absolutely don't want that.

One curious thing that came out of the discussion moving imports to the community forum was a few DWG folks being like "we don't care where it gets talked about so long as it's somewhere". So I may have skated to where to puck is going etc. Anyhow, it's not causing major headaches and we can get it worked out at whatever pace you feel is appropriate.

[taylor.smock]

One curious thing that came out of the discussion moving imports to the community forum was a few DWG folks being like "we don't care where it gets talked about so long as it's somewhere".

In some ways, an import requires less scrutiny than a change to a tag. Changing what a tag means has far wider impact on the rest of the ecosystem.

• Editors need to update their tagging schemes
• Downstream users need to update their understanding of the tagging scheme
• Editors who manually enter tags need to update their understanding of the tagging scheme
• Old values need to be updated to match the new meaning of the tag, or removed

It doesn't help that some tags are context dependent. For example (#23067), unisex=yes on a hairdresser used to mean male=yes + female=yes. The hairdresser wiki was modified a bit over 6 months ago to change unisex=yes so that it means "we don't know if it is male=yes + female=yes"; the changed meaning is more consistent with the unisex wiki page, but is still changing the meaning of the tag when used with another tag. With that said, the unisex wiki page also changed relatively recently (April 2023).

In the end, I don't care what the community decides, so long as:

• The changed meaning isn't completely contradictory to a naive understanding of the tag (example: unisex=yes means male=no + female=no)
• The changed meaning isn't completely contradictory to the original understanding of the tag (see above example)
• I feel like the discussion has had a chance for a variety of voices to give feedback; this includes downstream users of OSM, which is one reason why I still like the mailing list.
• There is some kind of backup/historical record of the discussion

[watmildon]

There's no reacts here but :100: :thumbs_up:. Gotcha.

[taylor.smock]

In 19025/josm:

Fix #23177: Change ref:gnis to gnis:feature_id in the waterway tagging options

ref:gnis, gnis:id, tiger:PLACENS, NHS:GNIS_ID, and nhs:gnis_id have
been merged into gnis:feature_id.

The wiki pages have been stable for 6 months, and the changes were discussed on
the OSM forum.

[watmildon]

Thanks for staying on top of this Taylor!

[GerdP]

@Taylor:
The entries in ignoretags cause error messages:

2024-04-03 09:50:38.753 SEVERE: Invalid line in c:\josm\core\resources\data\validator\ignoretags.cfg : 'NHD:GNIS_ID' does not contain '='
2024-04-03 09:50:38.754 SEVERE: Invalid line in c:\josm\core\resources\data\validator\ignoretags.cfg : 'gnis:id' does not contain '='
2024-04-03 09:50:38.754 SEVERE: Invalid line in c:\josm\core\resources\data\validator\ignoretags.cfg : 'nhd:gnis_id' does not contain '='
2024-04-03 09:50:38.755 SEVERE: Invalid line in c:\josm\core\resources\data\validator\ignoretags.cfg : 'ref:gnis' does not contain '='
2024-04-03 09:50:38.755 SEVERE: Invalid line in c:\josm\core\resources\data\validator\ignoretags.cfg : 'tiger:PLACENS' does not contain '='

I assume you wanted to use E: instead of K:?

[GerdP]

In 19027/josm:

see #23177: fix syntax error

[taylor.smock]

I think so, yes.

Oops. :(