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

Add preset stolperstein with deprecations and memorial:addr field #964

Merged
merged 10 commits into from
Aug 25, 2023

Conversation

tordans
Copy link
Collaborator

@tordans tordans commented Jul 21, 2023

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

  • The fields are split of from the regular memorial preset in order to now show the material on the Stolperstein Preset which always brass AFAIK and none of the wiki pages does recommend it
  • The name "Memorial Plaque Stolperstein" is meant to be descriptive for other language users. I think the German translations should just be "Stolperstein"
  • I did not add a ref pr memorial:ref field because again, the wiki/community is not clear on what to use but mainly there is no current usage of either in Taginfo
  • I did not add those person: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…
  • Info-i: Nothing to do here; the wiki and wikidata is present https://wiki.openstreetmap.org/wiki/Tag:memorial%3Dstolperstein

memorial:addr field

  • TODO: Lets see if this works in the branch preview…
  • The wiki and talk page are not clear on which tag to use, so I added both "address" and "memorial:addr". At least for the new tagging of memorial=stolperstein all users agreed to use "memorial:addr" (Taginfo)
  • The wiki is not clear on which address, so I took a risk here and clarified as "Nearest building address" which is the only think that makes sense IMO because we map what we see in OSM. Research tasks like "where did this person live" can be recorded on the Wikidata item. It is also what makes sense for the completeness-verification process that is described on the wiki.
  • I only added the subkeys that are most often used https://taginfo.openstreetmap.org/search?q=memorial%3Aaddr#keys but also described as importent on the wiki
  • Info-i: There is no wiki page (Search) but there is an empty Wiki data item https://wiki.openstreetmap.org/wiki/Item:Q1507

deprecations

  • The wiki is now pretty clear about the update path for memorial:type (usage 25k with a bit of double tagging)
  • And it makes sense to also update the core info from 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

  • Check address-field ==> Works great
  • Later: Add info on address-wikidata item
  • Resolve regional preset
  • Where does the empty "wikipedia" field come from? / how to remove it? It is not part of the preset…
    image

Closes #318

@github-actions
Copy link

🍱 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
@tordans
Copy link
Collaborator Author

tordans commented Jul 21, 2023

@tyrasd ready to review. Please have a look at the todo list above for your input. 🙏

Copy link
Member

@tyrasd tyrasd left a 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

data/fields/memorial/addr.json Outdated Show resolved Hide resolved
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
@tordans
Copy link
Collaborator Author

tordans commented Jul 24, 2023

Thanks for your feedback & help @tyrasd. This is ready for review again.

Testing-Locations: #964 (comment)

Regional Preset

Given that there are (logically) very few exceptions outside of Europe, maybe limiting the scope to Europe (code Q46) would be reasonable.

Good idea! I added it like that in tordans@8e90f99

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. 🤷 🤔

OMG this tagging is so unfortunate…
I tried adding both variants and make it that the UI picks the right one based on existing tags. However, the type:address does not allow other tags that addr:* (it does not automatically use a different prefix), so that was a dead end.

Now, there is just an optional (moreFields) address string field…

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.

I think that is fine for now…

@tordans tordans requested a review from tyrasd July 24, 2023 08:41
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…
tyrasd added a commit that referenced this pull request Aug 3, 2023
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)
Copy link
Member

@tyrasd tyrasd left a 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?

@tordans
Copy link
Collaborator Author

tordans commented Aug 17, 2023

@tyrasd thanks for the help with the *addr* part. I changed it to use the street instead of housenumber since that is a good fit as well and a bit more broad IMO.

I looked at the data https://overpass-turbo.eu/s/1z4c and Hamburg uses this schema a lot, so it is worth adding…
image

Testcase

https://pr-964--ideditor-presets-preview.netlify.app/id/dist/#background=Bing&disable_features=boundaries&id=n2652126042&locale=en&map=19.00/53.57327/10.03401

  1. First update the tags
  2. Now the address-fields show up (because now the Stolpersteine preset is active)

@tyrasd this is ready to be merged IMO

@tyrasd tyrasd merged commit cb87cc1 into openstreetmap:main Aug 25, 2023
5 checks passed
@tordans tordans deleted the stolpersteine branch November 3, 2024 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add preset for memorial=stolperstein
2 participants