-
-
Notifications
You must be signed in to change notification settings - Fork 362
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
stile resurvey, fixes #3187 #3370
stile resurvey, fixes #3187 #3370
Conversation
when changing style type also step count should be removed
resurvey happens after 8 years, so only small pool of old stiles with stile=* becomes qualified stiles without stile=* tag would get this quest anyway note that in rare cases, where stile type is unchanged and material tag is added - then not strictly necessary stile:check_date will be added
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
14c2292
to
6965331
Compare
in this case maybe deleting all of them would be a good idea, but it has history of being changes to whitelist anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM, a few possible resurvey improvements.
This is however going to make #2754 harder again unfortunately. I suspect the ideal would be a generic update function which takes a list of tags to deleteIfExist if the main tag's value has changed, but I can do that in my PR if you'd rather.
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
Spotted one problem - on marking stepover stile where material was marked already it is not OK to (1) delete it in general function (2) later add it It results in:
|
in case where wooden stepover stile is replaced by stone stepover tile (or in reverse) - delete tags such as step count
extracts complex repeated part, so applyAnswerTo can be comprehended
For now missing (BTW, I am curious how many people are actually using SC in areas with stiles anyway - and is time saved by implementing this quests greater than total time used to implement. research and discuss them :) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More minor suggestions
private fun StringMapChangesBuilder.deleteIfExistList(keys: List<String>) { | ||
keys.forEach { deleteIfExists(it) } | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not go in app/src/main/java/de/westnordost/streetcompletedata/osm/edits/update_tags/StringMapChangesBuilder.kt
so it can be reused elsewhere?
Can we override like in C++ so they're both called deleteIfExists and you can pass in a List or a String?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matkoniecz
please either put this function into app/src/main/java/de/westnordost/streetcompletedata/osm/edits/update_tags/StringMapChangesXt.kt
or at the end of this file outside the class definition (your choice).
Can we override like in C++ so they're both called deleteIfExists and you can pass in a List or a String?
Yes, no problem. The naming of the function is all the same to me though.
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Show resolved
Hide resolved
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Show resolved
Hide resolved
Co-authored-by: Peter Newman <[email protected]>
As in you don't think it's worth asking earlier for the material than during a traditional resurvey?
I try and use SC whenever I go out walking (and wherever I walk). I very rarely bother with iD or other local editing in front of my PC (or anything else aside from SC). I've also just finished walking coast to coast across the UK (via Hadrian's Wall) although it seems I've only answered five stile quests so far (partly as some weren't tagged, hence #3372 ) and partly not enough data loaded (it's a very long way). However that's more than the number of CCTV quests I've done, which have been around for similar lengths of time and I spend far more time in the city... Aside from the relative value of different types of quests/their data, then generally I'll go places with stiles less frequently, and the same place less so, than say commuting around parts of the city, so gathering that data then is more valuable than somewhere I pass daily for work and so could build up over a number of days. The secret truth I probably don't want to tell myself is that for me personally I only really use OSM for car sat nav currently, so the connected graph of streets, road and house names/numbers and maybe speed limit and road surface is all I directly use... Although I'm seeing more websites switch to it recently. |
I haven't been following the conversation. @matkoniecz , please mark if this ready to review/merge by requesting a review when everything that you think should be resolved is resolved. |
Given that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the added complexity in applyAnswerTo
, I strongly suggest to write test cases to cover the different code paths here but I'll leave this up to you. In the end, this is your quest type.
It might be possible to reduce the complexity by following @peternewman 's advice.
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
private fun StringMapChangesBuilder.deleteIfExistList(keys: List<String>) { | ||
keys.forEach { deleteIfExists(it) } | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matkoniecz
please either put this function into app/src/main/java/de/westnordost/streetcompletedata/osm/edits/update_tags/StringMapChangesXt.kt
or at the end of this file outside the class definition (your choice).
Can we override like in C++ so they're both called deleteIfExists and you can pass in a List or a String?
Yes, no problem. The naming of the function is all the same to me though.
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileType.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: Tobias Zwick <[email protected]>
It would crash completely without barrier tag It would not tag barrier=stile if it wold be unset and stile would be selected Co-authored-by: Tobias Zwick <[email protected]>
prevent claim that value was modified in cases where it was not actually changed
app/src/test/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileTypeTest.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: Flo Edelmann <[email protected]>
confirm that toMutableList is avoidable
fun deleteIfExistList(keys: List<String>) { | ||
keys.forEach { deleteIfExists(it) } | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I wrote in my earlier review, I'd prefer if you added this function to StringMapChangesXt.kt
, i.e. as an extension function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think your function probably still needs a little more improvement and that these test cases should be added either way.
app/src/test/java/de/westnordost/streetcomplete/quests/barrier_type/AddStileTypeTest.kt
Show resolved
Hide resolved
Co-authored-by: Peter Newman <[email protected]>
This reverts commit d259ed0.
3f0e575
to
281cca9
Compare
@peternewman Thanks for noticing the problem! |
ok so err... should I review this again? |
There were no significant architectural changes, though a serious bug was fixed. Oh, and tests were added. And I still need to handle #3370 (review) |
Don't mind that, I will do this after merging. |
Hm, after merge I found some more deficiencies and one bug. I'll create a PR. |
Vespucci uses it for stile related presets, although maybe just to tag them, I don't know if it displays the info too: |
Well done for spotting the far bigger bug I missed with the wrong key! |
resurvey stiles, fixes #3187
resurvey happens after 8 years, so only small pool of old stiles with stile=* becomes qualified
stiles without stile=* tag would get this quest anyway
note that in rare cases, where stile type is unchanged and material tag is added - then not strictly necessary stile:check_date will be added