Closed dbdean closed 3 years ago
Other potential examples can be found at https://overpass-turbo.eu/s/18Z7
Or even at https://overpass-turbo.eu/s/190s (without the bbox filter, as there are only 173 nodes matching that worldwide). There are 44 ways, see https://overpass-turbo.eu/s/190t.
What would a list of tags be that indicate that something may not be vacant (any more)?
There is an open-ended list of tags to look for. If it is really just 173 nodes worldwide, I doubt it is worth taking that into account
I think if a shop gets reused to an amenity (fast food restaurant etc.), shop=vacant is usually not valid anymore, because the rooms aren't vacant anymore, aren't they? Their usage changed from shop to amenity, but there isn't any vacant thing anymore,so shop=vacant isn't appropiate anymore, isn't it?
yes
I think if a shop gets reused to an amenity (fast food restaurant etc.), shop=vacant is usually not valid anymore, because the rooms aren't vacant anymore, aren't they? Their usage changed from shop to amenity, but there isn't any vacant thing anymore,so shop=vacant isn't appropiate anymore, isn't it?
@Lukas458, sure - but it's not necessarily something that can be easily fixed using armchair mapping, as most editing tools don't make it easy to tell which tag was added first, so I would suggest that each of these does need to be checked on site, and it does at least present a subpar experience already in SC where it assumes the shop=vacant tagging is correct, and not the other tagging.
This has happened to me about 2-3 times already, probably when I added a shop over a node/area with shop=vacant without remembering to remove the shop=vacant, and in answering it I'm not even sure if it would remove the other tagging if it wasn't correct anymore either.
For example, if I had a osm node/area with amenity=bakery and shop=vacant, but by the time the quest came around it had changed to a bookshop, I believe after answering 'Bookshop' in SC, we would end up with a node that was both shop=books and amenity=bakery (and keeping whatever name is has at present - probably the old bakery's name). And then someone would still need to come back and survey on site to determine if it is a bookshop or a bakery. Might as well check for the POIs that SC already knows about (because we check for opening hours, etc) and if it detects both one of those and the shop=vacant, ask if the POI is still there and correct the tagging on the spot.
Alternative that may fix the problem differently: When we ask for other quests that indicate that a node/area is not vacant (opening hours, etc), remove the shop
=vacant
tagging?
And don't ask if it is still vacant if there is alternative tagging that SC already knows about (we can't account for every possibility, but we can account for what SC already checks for other similar quests).
I think the above two would solve the problem over time, without having to ask any new questions.
What would a list of tags be that indicate that something may not be vacant (any more)?
The tags that SC already uses to check for opening hours would probably do.
Unless I'm missing something, SC already has a way to deal with this situation. Answering the quest will remove shop=vacant
and retag as amenity=fast_food
.
Unless I'm missing something, SC already has a way to deal with this situation. Answering the quest will remove
shop=vacant
and retag asamenity=fast_food
.
I think the problem is that when StreetComplete asks the question, it makes no reference to the fact that the object is already tagged as amenity=fast_food
, so it may not remove previous tags… I'm not 100% sure. I'm sure @dbdean will be able to clarify exactly what is meant.
There is an open-ended list of tags to look for.
Still, filtering like https://github.com/streetcomplete/StreetComplete/blob/f891ce49c46d268ad93ba9f1f827df3455638ffd/app/src/main/java/de/westnordost/streetcomplete/quests/shop_type/SpecifyShopType.kt#L17-L26 should eliminate basically all cases.
On the other hand such tagging situation is invalid already and very rare...
And we don't want to filter that out, do we? Otherwise, this mistake is never corrected
@10992-osm
I think the problem is that when StreetComplete asks the question, it makes no reference to the fact that the object is already tagged as amenity=fast_food, so it may not remove previous tags… I'm not 100% sure. I'm sure @dbdean will be able to clarify exactly what is meant.
Yes, it doesn't let you know that it is already tagged with something, and if you choose what it currently is, it won't remove the old non-vacant tagging (and name, and opening hours, and vegetarian/vegan status, etc.) if it is wrong.
I think the solution would be that when a quest is answered about a POI (opening hours, toilets, vegan, etc.), if that POI is also tagged shop=vacant, that tagging should be removed. Then this question would rarely come up, because the other question are more likely to be asked immediately, or at least more often than asking if a shop is still vacant.
I think the solution would be that when a quest is answered about a POI (opening hours, toilets, vegan, etc.), if that POI is also tagged shop=vacant, that tagging should be removed.
That is already done.
Use case
If a shop has both a
shop
=vacant
tag and something else that it indicates that it isn't vacant (e.g.amenity
=fast_food
), then a the moment SC (after it hasn't been edited for a while) asks if it is still vacant, and gives no indication of the other tagging.An example of this (at the moment at least) is https://www.openstreetmap.org/node/1376057058. When SC is loaded in this area, it asks if the shop is still vacant, even though it's also tagged as amenity=fast_food.
Proposed Solution
It would be better to ask 'is X still here?', and adjust the tagging appropriately. For the example above, It would be better to ask if Mosaic Kebab is still there instead - if so to remove the
shop
=vacant
, and if it isn't, then to ask what is here now.Other potential examples can be found at https://overpass-turbo.eu/s/18Z7