Editing a POI can be based on already outdated data?

[stephan75]

OrganicMaps has a feature to edit POI data that comes originally from the OSM database.

The edition date of that POI data is from the moment when the offline map files are produced by the OrganicMaps team, I assume.

So what is happening when I examine some POI data in OrganicMaps, and I edit that data like opening_hours or similar, but in the meantime some other users has already edited that outdated data via any other OSM editor programm or app?

Is there any conflict detection or resolving like in JOSM editor?

[biodranik]

There is no UI for conflict detection. Some simple logic tries to merge your changes with already existing ones in the OSM (fresh ones, at the time of uploading). Check editor/xml_feature.cpp file for more details.

[stephan75]

Hello @biodranik

Recently I had a user experience where I would say:

Organic Maps has no or maybe no efficient conflict handling for those cases.

I came across a restaurant that has a new name in real life, and I edited that POI via the new Every Door app by zverik.
But that app has a cumbersome way to update the opening_hours.

So a few hours later I tried to edit that POI node via OrganicMaps about the opening hours.
There I had the OLD restaurant name displayed in the edit mode.
With uploading the fresh opening hours, OrganicMaps uploaded also the OLD POI name!

My guess of a good conflict management would be:

1. OrganicMap knows the OSM element ID number ... correct?
2. When the user wants to edit a POI, try to load its keys and values not only from the offline map files, but also ask the OSM api to get the freshest version, and display THAT fresh data for the user who wants to edit that POI.
3. Also display a warning when an OSM element has been deleted some days ago, but offline map files have an older non-deleted version.

Or am I wrong about my thoughts?
Sorry I have not enough skills to view into that source code you mentioned ...

How do other POI editing OSM apps that conflict handling?

[biodranik]

1. Incorrect. It would make our maps data files too big.
2. Interesting idea, but it won't cover the offline case.
3. A complex UI could help, but we're limited in resources.

At the moment, the code tries to get the freshest version from OSM at upload time and "merge" the conflict in a smart way. But looks like there is a bug. It would be great to reproduce it with a unit test on the dev osm server, to test a proper merge fix.