-
-
Notifications
You must be signed in to change notification settings - Fork 358
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
Element is not updated after conflict on upload #5745
Comments
I can't reproduce this problem with version 58.2. Can you record a screen video? |
Thanks! This might be another instance of #5545. Can you try to reproduce it another time and then immediately after go to Menu -> About -> Show Logs, then change the filter to show only the logs around the time this bug happened and share these here? Alternatively, if you remember exactly when you reproduced this issue, i.e. apparently today at 16:12, you can also skip trying to reproduce it another time and directly look for the logs at that time. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
2024-07-15T16:04:38.065: I [Preloader] Loaded country boundaries in 0.2s |
Thank you! |
The relevant section should be this, as in the video one can see that the issue was reproduced 16:12.
And the error happens here:
When you create an edit, by default, it is immediately uploaded to OpenStreetMap. If a conflict occurs during upload, your change will be discarded because the assumption is that the data you just edited has been edited by someone else in the meantime and thus the premise under which the quest (etc.) has been created might not even be correct anymore. It looks like the building you edited was https://www.openstreetmap.org/way/397687189/history And it looks like that just three hours before you edited the building, someone else (Hello, @mcliquid ! The world is small!) also edited the same property. Judging by that all these buildings are displayed in red, I conclude that StreetComplete downloaded the area when these buildings were still tagged with So, it looks like in the end it is absolutely the correct behavior to refuse your edit. Now, a few open questions, though:
|
Yes, I confess that after checking changesets using OsmCha, I found several individual terraced houses in my area with But I would say it's a good idea to re-download the data if this occurs. |
@Helium314 you mentioned recently you would have a look into this, but I assume that you have all hands full at the moment with the merge, right? |
Currently I'm a little occupied by trying to make SCEE run again, but I think I'll wait with re-implementing broken features until the main screen is switched to compose... |
My plan was to first get the v59.0 alpha (i.e. release on github but no beta-release on google play) ready before finishing my work on composing the controls etc. on the main screen (it's not everything on the main screen, not the bottom sheet, not the map. Just the controls, edit history sidebar). Getting v59-alpha1 ready entails for me 1. rummaging through the issue tracker a bit more and fixing small things, especially stuff requiring translations and 2. dev-testing the version a bit to see and fix if there are any obvious issues with maplibre. Whether or not I will also squeeze mainscreen-compose into v59.0 I am not sure yet. I understand it would be more convenient for you if I put that into v59, too? |
Oh, then I'll need to do the fixes anyway. I'm not even sure whether there is anything related to those controls that needs fixing. |
The area seems to be invalidated correctly. The element is updated correctly with the new tags. But the overlay displays red, instead of the new value. |
In more detail:
A workaround (fix?) could be calling |
Hmm, I was about to write: no, because if the edit is still around when But if the upload fails due to a conflict, the "faulty" edit should also produce a conflict when trying to apply it locally onto the the updated data and hence is not applied. So, moving markSyncFailed in ElementEditsUploader below the map data update might just work! But this must be tested, of course. |
But wait, isn't there a simpler solution? The Checking whether there's any element in |
So if |
In building mode: after the building has been selected, it does not change color. You have to make the entry again so that the building is displayed as an apartment building, for example.
How to Reproduce
Go into the building mode, select a building and change the building type to an apartment building. After the confirmation, the building type is not displayed.
Expected Behavior
The apartment building is displayed after the confirmation
The text was updated successfully, but these errors were encountered: