StreetComplete
StreetComplete copied to clipboard
streetcomplete
Map maintenance with overlays
The overlays offer a method to comprehensively map and check the situation for different views on the OpenStreetMap data such as the sidewalk situation, the cycleway situation, shops etc.
However, it is currently not possible to record the fact that one was on-site and checked the situation when the situation did not change. E.g. that the shop is still there, or that this particular road still has a cycle lane.
When the user already went through the effort to be on-site, it would be very convenient to also have this possibility. So in short:
Use case
As someone wanting to comprehensively update and maintain the e.g. cycleway situation, I need the ability to tick off as already checked roads.
Proposed Solution
Display in the overlay
- Elements in applicable overlays whose last-checked age are older than a certain set age are always highlighted in red, as if the information is missing. I.e. this is a similar behavior than for quests, where old information is also treated similarly as missing or invalid information.
- Add a setting (either per overlay or globally) that determines this last-checked age. Default is I think best set to ∞ / N/A as it may be confusing if not deliberately set to some value
Behavior of the overlay form
When opening the preview of an element (e.g. a cycleway), allow the user to tap the ✓-button even if he changed nothing. In that case, only the check date is being updated. This must at least be limited to "today". I.e. if it has already been checked today, the ✓-button remains disabled.
There should also be some UI feedback about this.
One idea would be to show to the user the last-checked date which then subsequently gets updated in the UI. Another cumulative idea is to make the ✓-button look different if nothing was changed, e.g. add the text "Checked ✓" or similar.
Another point to discuss would be whether if elements are updated in overlays (with the show-older-than-x-as-missing setting on?), always a new check date should set, even if other changes were made. The argument behind this thought is that if a person wants to really comprehensively check and update the situation for one kind of information on OpenStreetMap, he basically wants to record the check date for all the elements, even for those he did change.
Thank you for opening this.
- I like the idea of being able to confirm valid data with hitting a "checked" button. I agree that their highlighting needs to be visually changed
- Highlighting old data in red however has the downside of not being able to see what is currently set
- For this a better solution should be found (I don't have a good one right now)
- I am questioning if a generic
check_datewould be sufficient or if it better should be a more specificcheck_date:*e.g.check_data:cycleway(see https://wiki.openstreetmap.org/wiki/Key:check_date#Examples), because e.g. while having the bicycle overlay open, you would not validate sidewalks tagged for the same road - yes:
check_date:*should also be set when changing data through the overlay then. Because while validation you would mostly find some to confirm and some to change, but finally you have checked both of them. Alternatively SC would need to parse the date a relevant property was last changed.
- Highlighting old data in red however has the downside of not being able to see what is currently set
- For this a better solution should be found (I don't have a good one right now)
I had thought about removing highlight for validated sections. This would support the view of getting things completed (like in StreetComplete). However this would make the overlay scattered with some highlights shown and some not, resulting in a loss of overview.
A button to quickly toggle between showing all and only unvalidated could be helpful. Not sure if this would be acceptable to add (only in overlay mode).
Thinking more about it, the suggested approach to highlight old data red would only serve a re-validation use case and not work for every first round of validation, as either
- coloring would not change (if no
check_dateshows up in it's overlay color) - or initially always show a "completely" red map (if
check_dateshows up in red)
So I think the solution needs to change visuals on validation without making every existing value invisible upfront (e.g. like I proposed above).
A lot of text here. Regarding check_date: Yes, of course I meant check_date:*. Also, note that if no check_date:* is set, StreetComplete generally takes the last edit date as a fallback.
Regarding showing data as red on the map that is already there, valid and not ambiguous but whose check date exceeds a certain age:
What is your use case exactly that you need to see also in the overview how the cycleway situation is currently mapped if you already set in the settings that you want to re-survey all roads whose check date age exceeds a certain threshold?
If you want to resurvey all the cycleways older than a year, it doesn't matter as what it has been mapped before, you want to go there and check anyway. Hence, you do not need to see the current situation before you click on the cycleway in question.
A lot of text here
Sorry
I am seeing it from the point of view to correct / align / harmonize one sort of data in a certain area.
Right now I am using the existing visible data to see where there are probably errors and especially go there to check. This would not be possible any longer. And exactly for this I need the feature to see which parts are still relevant and interesting to check (all valid/unchanged ones would not be very interesting, therefore good to be able to check them off)
When - while passing by - I see multiple valid ones, I can continue and confirm all of them at the next stop (e.g. the next wrong entry or a suitable spot). Otherwise I will have to stop every few meters, click to reveal, confirm and only then can proceed. The first would require significantly less time and keep focus on the interesting answers.
Regarding last edit date to me it seems not sufficient, as just anything could have been changed, besides the keys the overlay is relevant for (same reason as for check_date:*).
Right now I am using the existing visible data to see where there are probably errors and especially go there to check. This would not be possible any longer.
Of course it would. You set yourself the maximum age the cycleway is still considered acceptable in terms of check date. I.e. it is like a todo list: "I want to check the following cycleways because they have been checked last too long ago." You can still check and update the cycleways that are on the way to it if you see that they are wrong now, but those cycleways you marked you want to check anyhow.
I am not selecting "where there are probably errors" by age, but rather by looking at the whole picture if it seems unreasonable (e.g. a street with mostly advisory lane, but then in between a segment tagged as track). That is where I see the strength of the overlays.
And e.g. in the city of Herrenberg unfortutately there still are a lot of error I want to fix.
You can still check and update the cycleways that are on the way
Today I can check also others on the way (because I can see the current value as highlight), but I cannot checkmark & hide the ones I found to be valid afterwards. This is what I need - not the other way round (hiding/changing what was not updated in a while).
So the todo list is rather "everything that was not yet checked". Only after that there will be the need to revalidate at some point in time.
So the todo list is rather "everything that was not yet checked".
Then set the max age to something like 1 month or whatever. Everything is red, and you work your way through.
And then
looking at the whole picture if it seems unreasonable [...] That is where I see the strength of the overlays.
won't be there, which is why I use the overlays 🤷
I agree with @SLMapper , I too much prefer overlay to always show me currently mapped situation, so I can verify it easily (and correct/update if needed). And when I want the be notified about old (and thus possibly changed) data, I use recurring quest - which will warn me about old data.
But I also can see @westnordost use case when mapper claims some area as under their protection, and want to keep it up-to-date at all time. While less important to me (i.e. see "recurring quest" workaround above), it still might have use.
Perhaps, the colors could be made to represent the situation on the ground, but make their shade much darker if they are very old? That might make both sides happy. (if a solution like that is too much work, then I'd prefer to keep situation as is)
make their shade much darker if they are very old
Think that would not be well visible due to low contrast
I like the idea, however I think it is important to be able to distinguish "old data" (needing resurvey) from "no data" (never surveyed before) because I would like to give priority to the last. For the same reason, it would be nice if the shop opening hours resurvey quest had a slightly different icon from the one asking for opening hours for the first time...
would it be better to have two variants (or a setting per) of overlay to 1) complete the data and only add missing data. and 2) re-survey existing data (and possibly add missing data too).
so the second variant would be an extension of the first enabled by a switch for the people who want to? otherwise any instance of identified "old" data could be put into a dedicated re-survey quest, no?
