-
Notifications
You must be signed in to change notification settings - Fork 160
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
Add some common name fields #215
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the name
field be added as a prerequisiteTag
of these additional name fields?
For this round, I omitted some common name fields because they weren’t as straightforward:
alt_name
andold_name
are likely to be localized and contain multiple values at the same time, but neithersemiCombo
norlocalized
provides all the necessary functionality.
The wiki says that multiple valued names are the exception: “In rare cases, the key is used for multiple semicolon-separated names, e.g. alt_name=name1;name2;name3, but this usage is not preferred.” I would say that a regular localized
field is also good enough for alt_name
and old_name
.
sorting_name
is especially relevant in some languages but completely irrelevant in others, so it would be nice to filter thelocalized
field type’s language list accordingly.
ok, let's omit that one (it's also used relatively less often than the other mentioned "names" here: 20k occurrences vs. 100k+ for the others). It might be included in the future on a per-region basis, perhaps.
That may be too strict, since I’ve heard of mappers using combinations like |
OK, but in my opinion that seems to be rather an exception / edge case. Also iD currently doesn't "really support" the |
I’m willing to try making it a |
Good question. I would say that for a first iteration it's ok to have the fields operate independently (only based on the main part of the key), but perhaps this could be improved further down the line. It could be slightly tricky to balance the UI for this, though: Some places (e.g. major capitals) have lots of |
Would this be considered a showstopper for this PR, or can the PR land as is for now while we track this idea in a separate issue? These fields are hidden by default unless already set, so clutter wouldn’t be an issue. |
9d3204d
to
49f529e
Compare
This PR was mentioned in this forum discussion as a way to help mappers avoid listing multiple values in |
Also mentioned in this forum discussion as a way to keep |
@tyrasd can you please give this PR another look? Mappers keep making controversial edits (politically sensitive in this case) possibly because they don’t know about |
@1ec5 is there a preview on this PR? Maybe its older than the preview-generator; in this case another change to the PR should re-trigger the preview generator, I think. I wanted to look into the preview to understand if those new files are "moreFields" or always visible. I don't think having them visible always where a good idea. It will lead to people duplicating terms just to fill out fields… |
🍱 Preview the tagging presets of this pull request here: https://pr-215--ideditor-presets-preview.netlify.app/id/dist/#locale=en. |
@1ec5 I looked this over to get it merged. I read the thread the way that Martin's request was to add I would feel comfortable to merge this without further discussion once that is applied. |
As you can see from the preview, a This applies to the other name fields as well. I think this behavior is suboptimal because some languages simply don’t have an alternative name to speak of while others do, but I think we can track it in openstreetmap/iD#10323. It isn’t a showstopper for landing this PR. As of openstreetmap/iD#10181, universal fields now sort below preset-specific fields in the “Add field” menu. For some presets with many optional fields, inexperienced users will be less likely to find these name fields. It’s unfortunate but not a blocker for landing this PR. |
@1ec5 the general setup of this works as expected. I checked the wikidata item descriptions which look good as well. One thing I am still wondering about is, what the difference between those three names actually are https://taghistory.raifer.tech/#***/loc_name/&***/reg_name/&***/nat_name/ My question is, as a mapper, when I see the options in the more tags dropdown, how will I know when to pick local, regional, national? I wonder if we should at least remove the regional name with only 40k usage. Or maybe make that an unsearchable field (is there such a thing?) so we only expose what is there, but not offer it in the dropdown. The difference for local vs. national seems a bit easier to make. Even though I would expect the name or official_name to be the national name … |
The I don’t think these fields or the documentation should clearly spell out when “local”, “regional”, and “national” apply. There are already complaints about the global “Key:name” page being too long and difficult to digest, so I don’t think going into detail about each country’s peculiarities would help matters at all. Instead, local communities such as Canada should document country-specific expectations on their respective pages. The raw usage numbers are not particularly meaningful. These keys often clarify geopolitical disputes (some of them quite petty). One I’m familiar with is this lake, for which the national government insists on one name (which national map publishers follow), the locals insist on another, and the state government has sided with the locals. This is not to say that the four-way local/region/national/international name classification system is perfect: in the U.S., we sometimes see disagreements at a local/county/state/national level over the name of something, not to mention cross-border disagreements like this lake that’s been the subject of a bitter disagreement over the name between two states. But those situations don’t have clear tagging solutions, whereas these keys are clear solutions for enough situations.
I don’t think this option currently exists. But the stakes are already very low if all we’re doing is putting some more items in this menu. If this PR had been merged in its current state three years ago, I’m pretty sure we’d look back and agree that the benefits would have outweighed any confusion from not knowing the difference between a local or regional name.
|
Thanks for taking the time to get into this more @1ec5. I know this is tedious, but in feel better looking at more angles for a case like this (where I plan to merge something prev. reviewed, long open and global…). I will merge now, based on the thinking that those fields will mainly present data that is already there – which is a big win – but not cause any "lets fill out every field just because it is there" kind of mapping (which we should avoid with our presets if possible). I think the I am still unsure that mappers will really understand when to use Unfortunately we missed the 1k days mark since the PR was opened (1,072 days says ChatGPT) and are a few weeks short of the actual birthdays. ;-) |
Thanks, I do agree that there should be documentation about #1288 tracks adding a field for |
Added some of the most common name fields as universal fields to all presets:
loc_name
)nat_name
)official_name
)reg_name
)short_name
)For this round, I omitted some common name fields because they weren’t as straightforward:
alt_name
andold_name
are likely to be localized and contain multiple values at the same time, but neithersemiCombo
norlocalized
provides all the necessary functionality.sorting_name
is especially relevant in some languages but completely irrelevant in others, so it would be nice to filter thelocalized
field type’s language list accordingly.Fixes #283 and fixes openstreetmap/iD#1554.