New Quest: Check if an object is still there

[westnordost]

Question asked: Is this X still here?

So with the maintenance quests in place, the next step could be to have a or have several quests where the user is asked to confirm if an object still exists. StreetComplete does currently not support deleting elements, so this must be implemented in the frame of this issue or before that.

The interface will be a simple yes/no button. If it still exists, check_date or maybe check_date:existance should be tagged. It should be discussed which of the two tags should be used.

Till the quest is ready to be implemented, feel free to add more ideas of objects whose existance should be rechecked every now and then.

For the following objects

very often because it is temporary by definition (1 year?):

• landuse=construction

often because it is small and not a big thing to remove (2 years?):

• amenity=post_box
• amenity=telephone
• amenity=clock
• amenity=vending_machine (less often for ticket vending machines)
• amenity=bench
• amenity=atm
• leisure=picnic_table
• amenity=waste_basket
• tourism=information + information=board or terminal or map

often because it is important that it is up-to-date

• emergency=phone
• emergency=defibrillator (only for those where it is known where they are - inside or outside, on which level)
• emergency=fire_extinguisher (only for those where it is known where they are - inside or outside, on which level)

a little less often (4 years?):

• amenity=bicycle_parking (only for stands, wall_loops etc)
• amenity=motorcycle_parking
• leisure=pitch + sport=table_tennis
• advertising=column or board or poster_box
• highway=path with ground surface and bad visibility. How to determine bad visibility though?
• most shops
• amenity=pharmacy maybe more often because it is more important

Post here if you have more ideas!

[matkoniecz]

amenity=restaurant =pub =cafe =fast_food =bank =car_sharing =bicycle_rental =ice_cream =bar

Maybe it would make to sense to ask about disused:amenity whatever this objects are now fully gone? https://taginfo.openstreetmap.org/keys/disused%3Aamenity

It also shows what tends to disappear.

[FloEdelmann]

When landuse=construction is answered as “does not exist anymore”, instead of deleting the node/area, wouldn't it make sense to only update the landuse tag to the value of the construction tag?

From the landuse=construction wiki page's “Additional tags” section:

construction=residential (the kind of construction, usually what the landuse-tag should be when the construction is complete)

[matkoniecz]

If landuse=construction is not existing anymore then adding construction=residential is not useful - it is too late for that.

Also, retagging it to landuse=residential would not be the best idea, as construction site often is larger/smaller than landuse of constructed object.

[Cj-Malone]

A bit of context for bus stops in the UK, in case you are not aware. They were imported per region from a gov dataset (NaPTAN) about a decade ago, and then forgotten about.

Some regions didn't even tag the nodes as bus stops, presumably because they wanted a human to confirm before the data being useful. So this is probably a bus stop, even though it's not tagged as such. It would be awesome if StreetComplete could help fix this mangled import.

Other regions tagged them as highway=bus_stop but had a naptan:verified=no, and the vast majority of these were never verified, or verified but not tagged as such. A decade later I don't think there is any value in changing that to naptan:verified=yes, I would remove naptan:verified and use whatever is decided regarding check_date. It would be awesome if StreetComplete could help fix this mangled import.

There is also naptan:BusStopType=CUS to make things a even more complicated. They may or may not still exist, and they may or may not be marked as bus stops on the ground. So you can't just remove them if you can't see them. At some point it was decided that bus stops that aren't marked, (but have been verified) should have physically_present=no, but it didn't go far. I don't know if StreetComplete could be of much help in this case.

[westnordost]

@Cj-Malone Can you summarize for which tags exactly it should be verified if the stop exists and which tags should be removed on a positive answer?

[Cj-Malone]

naptan:AtcoCode should be checked, it's written on the sign, I'll get you some pics later. If it is correct all other naptan:* should be correct, or at least were when the import happened. I don't think StreetComplete should check the others, I don't even think they belong in OSM. But if they stay it should be better to do a bulk update or manually look at both sources and update them.

naptan:NaptanCode is the one exception, it is useful to downstream OSM consumers as it's the code you text to get live bus times via SMS. It is sometimes on the bus stop, and sometimes not but if naptan:AtcoCode is correct this is.

name should probably be checked as in my experience they may have changed. Although sometimes there are 2 names, one announced on the bus and another written on the sign, but I think that's a niche issue.

The location probably doesn't need checking. The accuracy from NaPTAN was generally great, if someone wants to move one a few meters it's probably OSM that's offset not the bus stop. There are some examples of a bus stop moving down the street, and ideally the node would be moved to keep its history, but that's not the priority.

[peternewman]

There is also naptan:BusStopType=CUS to make things a even more complicated. They may or may not still exist, and they may or may not be marked as bus stops on the ground. So you can't just remove them if you can't see them. At some point it was decided that bus stops that aren't marked, (but have been verified) should have physically_present=no, but it didn't go far. I don't know if StreetComplete could be of much help in this case.

HAR is Hail and Ride which may not be physically present either but from what I understand from others is required for routing or something.

I wasn't aware of the verified thing, along the same lines (although perhaps one country is too niche for SC) you could update verified to yes whenever someone answers a bus stop shelter/tactile paving/bench quest with an answer that isn't this stop doesn't exist (which is probably any non-note answer, but could just be the positive ones if you're being cautious).

[Cj-Malone]

you could update verified to yes whenever someone answers a bus stop shelter/tactile paving/bench quest

Personally I think naptan:verified should mean the NaPTAN tags have been verified, even if that means StreetComplete ignoring it because it's too niche. The check_date system should be updated like you said.

[Cj-Malone]

Standard bus stop naptan:AtcoCode is at the top right in this case.

School bus stop doesn't even have the naptan:AtcoCode visible in this case (Isle of Wight).

[michaelblyons]

RE: landuse=construction, you could further check opening_date and do the last_check without waiting a whole year if it's supposed to be open already. You would also want to make sure that the last_check is older than opening_date in the query. Otherwise, you will be repeatedly asking about the same construction area if they have missed the scheduled opening date.

I am not familiar with overpass syntax, but something like last_check + 1y > today OR (opening_date > today AND opening_date < last_checked)

[matthiasfeist]

Also for landuse=construction I would suggest that if the user answers, that it's not there anymore, to add a FIXME tag to indicate that this area needs resurveying.

[peternewman]

For some of these things like picnic bench, ATM and bike parking, they really need to be shown visibly on the map to be able to answer these accurately. Or exclude them from the quest when there are others nearby.

If there are a group of them mapped, it becomes very hard to orientate yourself relative to quest pins and work out which ones really exist. This would also benefit the bike parking covered/capacity quests too.

[westnordost]

Right, difficult. For recycling containers, this is the case currently. If they are too close together, the app does not ever ask for recycled materials again. It would be a shame though if this crippled this quest here, maybe there would be another solution but nothing easy comes to my mind.

[peternewman]

Right, difficult. For recycling containers, this is the case currently. If they are too close together, the app does not ever ask for recycled materials again.

Doesn't that mean if someone has mapped every container you tag all of the things that can be recycled on the first one? Isn't it better to either fix this in the same way, or not ask at all if there are two or more within say 5m of each other?

I think they are on their own a lot of the time, so it will be valid most of the time.

Showing them on the map would help for some of us, but I don't know how much control you've got of that and it would mean more noise and data usage for the rest of the time. Or could you render them yourself just when completing these quests? Although actually I'd probably want to see a bench or a bin to aid orientating the nearby bike stands better, so maybe that doesn't work.

Thinking about it, generally for a few quests more data on the map would help me for bench backrests too. Especially if someone has already answered one, but there are two others etc.

[westnordost]

Doesn't that mean if someone has mapped every container you tag all of the things that can be recycled on the first one? Isn't it better to either fix this in the same way, or not ask at all if there are two or more within say 5m of each other?

Yes, that is what I said. The app does not ask for containers that are too close together.

[peternewman]

Yes, that is what I said. The app does not ask for containers that are too close together.

Sorry, I got confused by the word again (my emphasis):

Right, difficult. For recycling containers, this is the case currently. If they are too close together, the app does not ever ask for recycled materials again.

Although I guess just a "translation" error.

[westnordost]

No actually, my bad. I got confused.

[Etua]

I think that when SC will gain an ability to delete elements or at least create prefilled notes, a new option (This place is gone) should be added to opening hours quest because it is where I often discover that an element is gone and it would be a shame if after implementing this quest the users would still need to manually fill a new note each time that happens. Originally I wanted to open a separate issue for that but maybe this one is a better fit.

[peternewman]

No actually, my bad. I got confused.

Okay, now I'm more confused.

[peternewman]

I think that when SC will gain an ability to delete elements or at least create prefilled notes, a new option (This place is gone) should be added to opening hours quest because it is where I often discover that an element is gone and it would be a shame if after implementing this quest the users would still need to manually fill a new note each time that happens. Originally I wanted to open a separate issue for that but maybe this one is a better fit.

I'd have thought in most places if a shop for example is gone it should be tagged as shop=vacant @Etua as it's quite likely a new owner will take over the space and a new shop will appear soon, there is quite a high churn of smaller, usually independent shops like this in some places.

[RubenKelevra]

Shops need definitely a tighter resurvey interval here (NRW, Germany). I think on average a shop will stay like 2 years in the same location.

The same is true for 'crafts'.

If a shop or craft isn't up to date anymore it makes sense to set shop=vacant and remove everything except the addr tag (and building tag).

Shops/crafts which are vacant could be added as an additional quest - to add a shop which is new.

Vacant shops are not that common, so they should maybe be rechecked monthly or so?

There's also the case that shops are being renovated. I think we could use the 'construction' for this case, like shop=contruction and construction=bakery. Would be nice to have this as an option on the shop-existence quest.

Shops that gets renovated usually post an opening date in the shop window, so we might want to ask the user for this as well, to be able to pop the quest up at the day posted, to have it confirmed that it's open again.

[matkoniecz]

https://wiki.openstreetmap.org/wiki/Tag:birds_nest%3Dstork is the next, a bit exotic candidate

Proposed on Polish Telegram. There are also tags to tag bird presence - but it may be not enough to survey once, making it unsuitable for SC.

[peternewman]

Shops need definitely a tighter resurvey interval here (NRW, Germany). I think on average a shop will stay like 2 years in the same location.

Out of interest, do your brands stay for longer (i.e. chain stores)? I'm wondering if we should use brand= to ask less often for them, or more often for independents.

If a shop or craft isn't up to date anymore it makes sense to set shop=vacant and remove everything except the addr tag (and building tag).

Broadly agree, I suspect we should look more carefully at the tags, but yes phone number, website, name, cuisine etc should go. I suspect a list to remove is safer than a list to keep.

Shops/crafts which are vacant could be added as an additional quest - to add a shop which is new.

There is already a name quest they would trigger I believe, or could be tweaked to cover them.

There's also the case that shops are being renovated. I think we could use the 'construction' for this case, like shop=contruction and construction=bakery. Would be nice to have this as an option on the shop-existence quest.

That's not mentioned on the wiki at all, and I'd have thought would risk being confused with shop=diy/shop=doityourself

[mnalis]

If a shop or craft isn't up to date anymore it makes sense to set shop=vacant and remove everything except the addr tag (and building tag).

Another option for obsolete shops/etc. would be using disused: lifecycle prefix, so insted of shop=vacant it would become disused:shop=convenience, disused:name=Xyz, disused:cuisine=pizza etc.

Advantage being that one does not need to create and update whitelist/blacklist of tags to keep/remove, as we'd simply prefix all tags with disused: (and they can still be used for orienting oneself if billboards/signs etc. were not removed by manually looking at disused:name)

[peternewman]

Advantage being that one does not need to create and update whitelist/blacklist of tags to keep/remove, as we'd simply prefix all tags with disused: (and they can still be used for orienting oneself if billboards/signs etc. were not removed by manually looking at disused:name)

That will just generate a lot more work for people though @mnalis . If you take a look at this well known toy shop: https://www.openstreetmap.org/way/272198123

If all tags were prefixed with disused: then a number of building and address quests would have to be completed again (or would pop-up automatically) to repopulate that same data.

[mnalis]

@peternewman you are correct; I was thinking mostly of node POIs which don't have building stuff on them so wouldn't produce more work for users (whose time is absolute priority, I agree). Of course one could keep building and addr data from being renamed to disused:, but then we're back to implementing tag whitelists - which makes my suggestion moot...

[RubenKelevra]

https://wiki.openstreetmap.org/wiki/Tag:birds_nest%3Dstork is the next, a bit exotic candidate

Proposed on Polish Telegram. There are also tags to tag bird presence - but it may be not enough to survey once, making it unsuitable for SC.

Very cool and unexpected quest idea. Should be doable. They usually come back in early spring on the northern hemisphere, so we could add a starting date when this quest pops up.

Bird present could be tagged like:

birds_present:2019:start=2019-03-04

When no birds have been seen it would be 'no' with a check_date to skip the quest for like 7 days.

In the fall this quest could pop up again after a given date to capture the end in this manner:

birds_present:2019:end=2019-07-15
birds_present:2019:end:checks=2
birds_present:2019:end:check_date=2019-08-09

and show up weekly again.

When no birds are present for like 5 checks, the quest won't show up anymore, since the first date is expected to be right.

When there are still birds present the quest would just set something like this:

birds_present:2019:end=no
birds_present:2019:end:check_date=2019-08-09

and reset birds_present:2019:end:checks to 0.

Hope this brainstorming helps! :)

---

@westnordost this gets quite messy with all the different ideas.

Maybe just let us do a new ticket and everyone just creates one comment with his idea and everyone interested in having this quest just gives a thumbs up, in kind of approval voting - regardless of the implementation details.

This let's you guys pick the most interesting quest ideas and create dedicated tickets for it and hide the comment as outdated to clean up the 'thread'. :)

[RubenKelevra]

Shops need definitely a tighter resurvey interval here (NRW, Germany). I think on average a shop will stay like 2 years in the same location.

Out of interest, do your brands stay for longer (i.e. chain stores)? I'm wondering if we should use brand= to ask less often for them, or more often for independents.

Yes indeed that's the case. But brands are pretty rarely tagged. It's somewhat new that I saw them tagged at all on shops.

On the other hand brand shops actually are more prone to be renovated from time to time, since there's an update on the brand interior available and they usually have more traffic/income.

I think we could just exclude supermarkets and fuel stations, since they stay for much longer. Maybe avg time is 5 years.

If a shop or craft isn't up to date anymore it makes sense to set shop=vacant and remove everything except the addr tag (and building tag).

Broadly agree, I suspect we should look more carefully at the tags, but yes phone number, website, name, cuisine etc should go. I suspect a list to remove is safer than a list to keep.

I could gather a list of stuff which definitely needs to be removed from the currently set tags.

Shops/crafts which are vacant could be added as an additional quest - to add a shop which is new.

There is already a name quest they would trigger I believe, or could be tweaked to cover them.

Well, currently the name quest handles shop=vacant like a =no and completely ignores it - which makes sense.

So we need a quest which let us choose the type of shop or craft etc. first, to replace vacant with something useful.

Maybe add a 'is this shop still vacant?' (yes/no) question first? 🤔

There's also the case that shops are being renovated. I think we could use the 'construction' for this case, like shop=contruction and construction=bakery. Would be nice to have this as an option on the shop-existence quest.

That's not mentioned on the wiki at all, and I'd have thought would risk being confused with shop=diy/shop=doityourself

Okay, maybe

shop=vacant
construction=yes
construction:shop=bakery

Makes more sense. 🤔

@peternewman you are correct; I was thinking mostly of node POIs which don't have building stuff on them so wouldn't produce more work for users (whose time is absolute priority, I agree). Of course one could keep building and addr data from being renamed to disused:, but then we're back to implementing tag whitelists - which makes my suggestion moot...

I think you're correct @peternewman forget my idea, we should go for a blacklist of tags which should be removed, like opening name, hours, phone, website etc.

disused: on the other hand would mean it's still there, and wasn't emptied and cleaned up. At least in Germany that's extremely rare.

I don't think I have ever seen a shop which stayed full but closed for more than a week.

If that's common for other parts of the world it might be interesting to add this as an option: (vacant/disused/construction)

But implementing disused just to keep the data doesn't make much sense, since we never 'delete' data permanently in a versioned database - we just hide them as not current anymore. :)

[westnordost]

@RubenKelevra Well when I implement this, I first implement a generic "is X still there" quest. Everything that does not fit into the generic one will be outsourced into separate tickets, then.

[RubenKelevra]

Okay makes sense :)

[peternewman]

Yes indeed that's the case. But brands are pretty rarely tagged. It's somewhat new that I saw them tagged at all on shops.

http://nsi.guide is working to fix that!

[StackKorora]

I have a quest suggestion: crossings and tactile bumps.

I think this is a lower priority item as it happens enough that I make notes of it but not frequent enough that it is a regular problem.

It is /very/ common in the older neighborhoods around me that there are no road markings nor any tactile bumps of any kind on crossings. However, I've noticed that in the last few years or so whenever they do construction on a road or sidewalk these things are added. I know of one street where all four crossings were uncontrolled without tactile until a car destroyed the curb, so now one corner has tactile for both directions on just that one corner. (waiting for them to update the other corners so I can update the map :-D ) But I also have manually noted crossings for update that were previously a 'uncontrolled/no' because of an upgrade during construction work where they added bumps and markings.

I don't think this needs to be checked very often. Maybe once a year? or two? Also, I think it really should be only for unmarked/uncontrolled as the general direction I see is that crossings are made safer, not less safe. :-)

Thanks!

[matkoniecz]

I have a quest suggestion: crossings and tactile bumps.

This is implemented already, and soon will be extended - see #2183 and existing "Does this crosswalk have tactile pavings on both sides?" quest :)

[StackKorora]

I have a quest suggestion: crossings and tactile bumps.

This is implemented already, and soon will be extended - see #2183 and existing "Does this crosswalk have tactile pavings on both sides?" quest :)

Greetings, Sorry. I may not have been clear enough. I know that there are quests for crossings and tactile bumps. I was specifically asking that they be re-checked every so often if they are unmarked/uncontrolled or a 'no' on the tactile bumps.

The link you posted is adding a new quest type. I see nothing about re-checking a crossing to see if it is still unmarked/uncontrolled. Thanks!

[matkoniecz]

This quest is reasked for old data. Less often than once a year, but it is also done already :)

[StackKorora]

This quest is reasked for old data. Less often than once a year, but it is also done already :)

Oh, I guess I didn't realize it was already done. Thanks!

[westnordost]

Started working on it. Will likely be in the next major release.

[westnordost]

rough categorization now

• every year: telephones, vending machines, storks nests
• every two years: ATMs, post boxes
• every four years: clocks, benches, picnic tables, waste baskets, fire pits, tourism information boards, maps and terminals, advertising columns, boards and poster boxes, public transport tickets vending machines, ping pong tables

[goldfndr]

Minor note: existance is a misspelling of existence. (At least, I haven't seen it spelled that way in English.)

[natrius]

Because i could not find any information about it: Do you check for last_checked as well? Does StreetComplete just change the date or switch it to check_date as well?

EDIT: Thx btw for that, that is really usefull.

[westnordost]

Yes, I check for all more or less used check date keys.

When a new check date is set, the app always uses check_date and removes the other keys of there are any.

Am 5. Januar 2021 12:08:11 MEZ schrieb Stefan notifications@github.com:

Because i could not find any information about it: Do you check for last_checked as well? Does StreetComplete just change the date or switch it to check_date as well?

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/streetcomplete/StreetComplete/issues/2074#issuecomment-754569517

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[Elefant-aus-Wuppertal]

Am I right that in the existence quest, the existence of vending_machines is checked only for some ones? I can imagine that some types of products might be excluded from the quest, so maybe vending=cigarettes, vending=condoms or vending=syringes.

But what is about vending=drinks, vending=sweets, vending=stamps, vending=excrement_bags, vending=bicycle_tube or vending=newspapers?

I know they are used not so often, but most over 2000 times and especially vending=bicycle_tube, vending=newspapers, vending=sweets and vending=stamps are machines that could be gone often, so I think it would be very useful and not so much effort to expend the quest on these, wouldn't it?

[Helium314]

It checks for vending_machine except for fuel and parking_tickets: https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/existence/CheckExistence.kt#L25

[Elefant-aus-Wuppertal]

Oh, for vending machines except these ones. Oh sorry then, I thought it would check only for these. So I read the !~ wrong. Thank you for the information.

[dreua]

I don't think this has been implemented for amenity=car_sharing and I've just opened a few notes for car sharing stations which are probably gone. Would be useful to add this imo. (Shall I create a new issue instead of commenting here?)

[matkoniecz]

If it was not discussed here, there is no issue for that (including closed) and it is a good idea: better open a new issue. Comments in old closed issues are likely to be missed or forgotten.