SC deletes tags if improving shop=yes to something more specific

[scaidermern]

In the shop types survey, when specifying the type of a shop that currently only has a generic shop=yes tag, SC removes other information such as name and opening_hours.

Example: https://www.openstreetmap.org/changeset/176614006

How to Reproduce
Answer "What type of shop is this?" (or something like that)

Expected Behavior
The shop value is changed, everything else is kept. Alternatively, SC asks the user if other information should be kept or deleted.

Versions affected
Android 13
SC 62.1

[matkoniecz]

in case of https://www.openstreetmap.org/way/91240972/history for example opening_hours were deleted

[peternewman]

in case of https://www.openstreetmap.org/way/91240972/history for example opening_hours were deleted

And the name, I don't know if you were giving one example or an exhaustive list @matkoniecz ?

[matkoniecz]

example (note "for example")

[mnalis]

Alternatively, SC asks the user if other information should be kept or deleted.

Yes, I think that this would be the best (just like we do ask in certain cases when Shop type is changed in Places Overlay).

Because it depends:

• if that shop=yes + name=whatever + opening_hours=.... were added a week ago, it is quite likely that is still the same shop, and it just need more precise shop=* type
• however, if that shop=yes + name=whatever + opening_hours=.... was added 8 years ago, it is very likely that it is no longer the same shop, so old information should be removed before adding new correct ones.

[matkoniecz]

Name is shown when asking for specifying shop type so should be up to date?

[mnalis]

Name is shown when asking for specifying shop type so should be up to date?

Well, as much as any other shop might (or might not) be "up to date" (i.e. have correct name=* and other data). Places change, and data becomes incorrect with time.

Also, some 33% (89k elements) of shop=yes do not have name=* tag at all according to taginfo, so user wouldn't be able to use that clue to know if it is still the same place (in which cases we should probably assume that it is different shop afterall, and re-ask name, opening_hours and other data if it exists)

[matkoniecz]

I guess that it could be handled that names ones preserve tags, while ones missing names are stripped from them?

[mnalis]

TL;DR: probably best to ask the user if that is still the same shop, just as we in Places Overlay when changing type.
(Other solutions seem too ineffective, wrong, and/or too expensive).

I guess that it could be handled that names ones preserve tags, while ones missing names are stripped from them?

Uh, no. While Perhaps that might help for few cases, it wouldn't address the main problem.

e.g. someone tagged many years ago shop=yes + name=SomeShop + opening_hours=whatever, and user being asked to specify specific shop type. (e.g. one of those)

IOW, the problem is :"Is that shop=yes still the same as when it was added?" and not "How much data was added when shop=yes was created?"...

I.e. :

• If the data is always preserved, it is likely to keep invalid data (e.g. it was added many years ago), and make it look like it was recently verified, which is bad.
• however, if the data is removed (current behaviour), and it is recent (i.e. likely valid) data, then it is still bad, but slightly less so.

Perhaps we might use some other heuristic (e.g. if the element was created¹ more than 6 month ago², assume it is still the same and keep the data, and if it is older, assume data is stale, and remove it)... But that sound like too expensive³ and complicated, and still does not solve the problem completely.

Thus, I think it would be best if we simply asked the user -- just like we do in Places Overlay when similar uncertanity overcomes us (see #4567 (comment))

Footnotes

1. actually, more properly: "was the last addition of shop=yes tag on that element more than 6 month ago" -- but that is likely even harder to detect. ↩

2. or 3 months, or a year, or some other period (with varying rates of false positives & false negatives) ↩

3. i.e. have to fetch and parse object history for such elements, and store metadata in local database ↩

[matkoniecz]

TL;DR: probably best to ask the user if that is still the same shop, just as we in Places Overlay when changing type.

also when it has no name? how it can be identified then?

If the data is always preserved, it is likely to keep invalid data (e.g. it was added many years ago), and make it look like it was recently verified, which is bad.

first is fine, why second would happen? edit description is quite clear

[westnordost]

I haven't been following the discussion so far, so I don't know if a consensus has been reached. Just dived into the code a bit to make a contribution:

• This is about the SpecifyShopType quest by @matkoniecz

• When a shop type is specified, it indeed always replaces all shop-related tags as if the shop completely changed

• the logic that decides whether a place should be 1. replaced, 2. not replaced or 3. the user should be asked about it currently sits in PlacesOverlayForm::createEditAction. If this logic is to be used in the SpecifyShopType quest type, too, it should be moved into Places.kt (or split up into several files in e.g. commonMain/osm/feature/ if that files becomes too big) into a function that returns an enum like PreferredUpdatePlaceAction { REPLACE, UPDATE, ASK } or similar.

[westnordost]

HOWEVER, actually looking at the logic in PlacesOverlayForm::createEditAction, that algorithm would always return PreferredUpdatePlaceAction.ASK in the case of shop=yes to any shop=*. So, one might shorten this and always ask.

(Anyway, it's not a bug)