-
Notifications
You must be signed in to change notification settings - Fork 164
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 preset stolperstein
with deprecations and memorial:addr
field
#964
Conversation
🍱 Preview the tagging presets of this pull request here: https://pr-964--ideditor-presets-preview.netlify.app/id/dist/#locale=en. |
- having "image" visible when the "wikimedia_commons" from moreFields is shown looks wrong, so now both are optional - reorder fields
@tyrasd ready to review. Please have a look at the todo list above for your input. 🙏 |
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.
Regional Preset
Given that there are (logically) very few exceptions outside of Europe, maybe limiting the scope to Europe (code Q46) would be reasonable. On the other hand, it would also be fine to keep the preset global (the only minor issue I can think of would be that people searching for Memorial Plaque outside of Europe might not be familiar with the term Stolperstein and therefore could be potentially confused and use it for other plaque type memorials).
At least for the new tagging of memorial=stolperstein all users agreed to use
memorial:addr
But the wiki page recommends to put the full address as a string into memorial:addr=…
and that also seems to be more common than using the address subtags. 🤷 🤔
Also, I'd not include the regular addr
field, for the reason mentioned on the wiki.
I think the reference (i) info could just point to the regular addr
page, as that one explains at least something about the structure of the used tags. OSM-wikibase-Q1507 does not seem to be too helpful here 😅
Where does the empty "wikipedia" field come from? / how to remove it? It is not part of the preset…
This is the behaviour of the wikidata
field type: It automatically tries to sync a matching wikipedia page for wikidata entries, adding the field for the wikipedia entry. This does of course not make all too much sense for wikidata entries which don't have a corresponding wikipedia entry. This must be fixed on iD's side, however. //edit: turn out this can be fixed in the preset of the generic wikipedia field, see 14bd2c7
Following openstreetmap#964 (review) - rename file to follow convention that locationSets should be part of the filename - add Q46 which represents europe Code via https://location-conflation.com/?locationSet=%7B%20include%3A%20%5B%27q46%27%5D%20%7D%0A
- remove "addr:" field since small usage and discouraged - add addr_string which is the thing used most often - update addr_addr to only show if at least "memorial:addr:street" is present
Thanks for your feedback & help @tyrasd. This is ready for review again. Testing-Locations: #964 (comment)
Good idea! I added it like that in tordans@8e90f99
OMG this tagging is so unfortunate… Now, there is just an optional (moreFields) address string field…
I think that is fine for now… |
The `prerequisiteTag` did work nicely. However, the `"type": "address"` only allows to set `addr:*` keys, so we cannot re used it as is. Removing it for now…
as not all wikidata items have a matching wikipedia page, this field would inevitably be always empty in these cases. As it is automatically filled in when a user selects a wikidata entry with a matching wikipedia page, the field shows up in the "regular" case anyway. only if the wikipedia page exists, but a map feature only has the wikidata tag (e.g. because it was mapped by another editor, or added manually in the raw tag editor), the field is now missing; it can still be added manually through "more fields" in this case, though see #964 (review)
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.
Looks good to me.
I gave the wikipedia/wikidata field a second look and think I have a better solution for the case where there is a wikidata identifier, but no wikipedia page: see 14bd2c7
Also, for the memorial:addr
vs. memorial:addr:*
tag(s): not sure what you tried, but one can use different address prefixes in the field, see #971 / 0fe03d7. Would you like to integrate this approach here before we merge?
…gger special address section Thanks at 0fe03d7
@tyrasd thanks for the help with the I looked at the data https://overpass-turbo.eu/s/1z4c and Hamburg uses this schema a lot, so it is worth adding… Testcase
@tyrasd this is ready to be merged IMO |
Recently the wiki page https://wiki.openstreetmap.org/wiki/DE:Stolpersteine was updated which resolved a few of the blockers I saw in #318.
Preset
material
on the Stolperstein Preset which always brass AFAIK and none of the wiki pages does recommend itperson:date_of_birth
fields because I did not want to research how to add custom date fields but also I think those special fields can be added with the "Tags" area in iD when users want to…memorial:addr
fieldmemorial=stolperstein
all users agreed to use "memorial:addr" (Taginfo)deprecations
memorial:type
(usage 25k with a bit of double tagging)memorial:text
at the same time (usage 21k)Regional preset?
In #318 (comment) we talked about making this a regional preset or not. The wiki page on which countries/cities have Stolpersteine (https://de.wikipedia.org/wiki/Liste_der_Orte_mit_Stolpersteinen) is quite long.
Given this long list, I think we should either make it a regional preset for just the top 3 countries … or keep it as a general preset.
TODOs
Closes #318