Descriptions created for routes/tracks disappear after the route is closed about osmand

[yuriiurshuliak]

The bug was partially reproduced. Follow these steps to reproduce:

• Create a new track without a description.
• Add a description to the track.
• Attempt to edit this description; editing is not possible.
• Toggle the display of the track on the map off and then on again.
• Check the description; you should now be able to edit it.
• Edit the description and repeat the process of toggling the track display on and off.
• Review the track description again.

As a result, the original description will be displayed instead of the edited one.

OsmAnd~ 4.8.0#2318m, released: 2024-05-16

video_2024-05-16_18-37-16.mp4

[sonora]

@vshcherb Caused by 0ef5334.

When we now first write a description, it goes to the osmand:desc extension. Is then shifted to metadata:desc, and later read from there. But upon an edit the new version again goes to the osmand:desc extension, leaving the value in metadata:desc untouched.

Problem is e.g. here

OsmAnd/OsmAnd/src/net/osmand/plus/track/fragments/controller/EditGpxDescriptionController.java

Line 46 in 5074717

gpx.metadata.getExtensionsToWrite().put("desc", editedText);

• EDIT: This PR #19888 fixes at least the issue of Description edits being saved to the wrong field. I have merged as a hotfix.
• But there is a remaining issue that if a user has a GPX file which has both metadata:desc and osmand:desc present, we do not display the latter. (Such files were produced by e.g. the buggy v4.7.17 Desc-Edit functionality, or users may have directly file-edited GPX files, or perhaps also by having a 3rd party GPX with a description already present and there having used an OsmAnd <=v4.7.16's Description-Edit function.)

[sonora]

@vshcherb Perhaps here

OsmAnd/OsmAnd-java/src/main/java/net/osmand/gpx/GPXUtilities.java

Line 677 in 0ef5334

public void readDescription() {

we should concatenate desc and readDescription rather than filtering a shift action to cases where desc is empty, like in this PR #19900?

I have interim merged this as an urgent fix because as of before every track in this condition upon a user editing the description did actually lose data.