Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nz] remove operator:type from DOC #10296

Closed
wants to merge 1 commit into from
Closed

[nz] remove operator:type from DOC #10296

wants to merge 1 commit into from

Conversation

k-yle
Copy link
Contributor

@k-yle k-yle commented Jan 1, 2025

There have been some counterproductive changes to DOC presets recently...

  1. NSI suggests adding operator:type=government to thousands of protected areas & parks, which isn't helpful and just creates noise
  2. there are some equally unhelpful "upgrades" which actually destroy the data when people blindly accept these suggestions:
image image

@UKChris-osm
Copy link
Collaborator

Problem No.2 seems to be from the markers and information boards being a sub-tag of tourist=information, which is where the suggestion is coming from.

I don't know how to exclude sub-tags from a match, unless preserveTags would also work in this case?

Alternatively I wonder if we could also create a category for markers, boards and maps, using tourist=information as the template, but again, being that the sub-tag would be the focus, I don't know if that's possible?

@bhousel would you know??

@Snowysauce
Copy link
Collaborator

Regarding issue 1, operator:type is one of the "quick access" fields for parks in the iD editor (see here). Since iD is the most popular editor, it means that the "noise" values will probably be added eventually anyway, and thus it makes sense for NSI to provide a suggested best value for the tag. If you truly believe that operator:type is unnecessary data noise for parks, I would suggest submitting an issue to @openstreetmap/id-tagging-schema to have the field removed from the sidebar.

@Snowysauce Snowysauce requested a review from bhousel January 2, 2025 02:13
@k-yle
Copy link
Contributor Author

k-yle commented Jan 3, 2025

Regarding issue 1: @Snowysauce thanks for the explanation, I hadn't encountered an "error" like this before, the ones I usually see relate to the (brand|operator):* tags. Since this is intentional, I guess openstreetmap/iD#6101 or facebook/Rapid#1623 would be the long-term solution, so that users are not spammed with validator errors which they didn't cause (some people get really frustrated by this)


Regarding issue 2: @UKChris-osm would it be acceptable to delete the DOC entry for information=office as an interim solution? I'm concerned that people who blindly fix these "errors" will start damaging the data (or maybe it's already happened)

UKChris-osm added a commit that referenced this pull request Jan 3, 2025
@UKChris-osm
Copy link
Collaborator

would it be acceptable to delete the DOC entry for information=office as an interim solution?

I've removed the Wikidata reference from information=office so it'll stop being suggested, as an entry needs a Wikidata to make it into the final index.

@bhousel
Copy link
Member

bhousel commented Jan 3, 2025

Alternatively I wonder if we could also create a category for markers, boards and maps, using tourist=information as the template, but again, being that the sub-tag would be the focus, I don't know if that's possible?

@bhousel would you know??

I'm not sure. It sounds like a problem with the established tagging, if we need to look at a multiple tags (tourism=*+information=*) to know what a thing is. I wrote about this on #4765. My recommendation would be to remove everything from NSI that works this way.

Also operator:type=* is well established and the rail and infrastructure mappers like it. It should probably stay.

@k-yle
Copy link
Contributor Author

k-yle commented Jan 3, 2025

thanks everyone, I see this was resolved in 9c7cf80 so I'm gonna close this PR. appreciate the help!

@k-yle k-yle closed this Jan 3, 2025
@k-yle k-yle deleted the kh/doc branch January 3, 2025 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants