App should not create maxspeed:type entries that conflict with existing source:maxspeed

[hholzgra]

See e.g. versions #9 and #10 on this way:

https://www.openstreetmap.org/way/25800616/history

In version #9 it only had

source:maxspeed=DE:urban

in version #10 a "Zone 30" limit was added as

maxspeed=30
maxspeed:type=DE:zone30

I don't care about the maxspeed:type vs. source:maxspeed discussions here, just about not having such conflicting values being created.

So please either remove conflicting source:maxspeed when setting maxspeed:type, or modify existing source:maxspeed accordingly ...

[westnordost]

This is bad indeed. I can tell you that this is indeed a bug, as the app should not show a quest if any of the implicit max speed tags is set. I will need to investigate, but a possible way how this particular case came to be was that both users downloaded the quest with StreetComplete 1.x, one did solve it with that version, one did solve it only much later, with StreetComplete 2.x. Usually, if two users try to solve the same quest, the Api will report a conflict and the app will discard the second user's answer. But since the tagging between 1.x and 2.x changed, there was no conflict, so the app happily tagged the second user's answer. If this was the cause of the issue here, then this particular problem will go away in a short time - when the users' quest cache is invalidated and the quests are being re-downloaded. I will need to check if it would be possible to add another check here before committing the changes whether the current element pulled from the Api still applies to the quest to avoid this problem for any quest. (or another solution that avoids this caching issue somehow) Am 14. Dezember 2017 05:45:34 GMT+07:00 schrieb Hartmut Holzgraefe <[email protected]>:

…

See e.g. versions #9 and #10 on this way: https://www.openstreetmap.org/way/25800616/history In version #9 it only had source:maxspeed=DE:urban in version #10 a "Zone 30" limit was added as maxspeed=30 maxspeed:type=DE:zone30 I don't care about the maxspeed:type vs. source:maxspeed discussions here, just about not having such conflicting values being created. So please either remove conflicting source:maxspeed when setting maxspeed:type, or modify existing source:maxspeed accordingly ... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #720

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[westnordost]

Ok, so when the server reports a conflict when uploading the change (= the to-be-updated element has a new version), StreetComplete now downloads the new version of the element and then checks if the quest is still applicable to the updated element.
If it can be determined, and the answer is "no", then StreetComplete will drop the change made by the user.
If it cannot be determined, the behavior of StreetComplete remains the same as before: It attempts to apply the changes to the element. If the changes cannot be applied because of an unsolvable conflict (i.e. adding maxspeed key but in the updated way, the key already exists; or the whole way has been deleted), the app will also drop the change made by the user.