Customized export label for file sharing (#333, #470)

[Kevin-Salazar-itcr]

• This PR is an extended feature of issue Change exported GPX filenames to 'YYYY-MM-DD_hh-mm-ss_OSMTracker.gpx' #333 according to Add device identifier to gpx tracks #470.

It allows the user to add a custom suffix label to the name of GPX files when sharing.

Instructions for Use

In Settings > GPX Settings, the option "Export label for sharing files" allows the user to customize the suffix of a track for export as a .gpx file. The exported file will follow the format:
YYYY-MM-DD_hh-mm-ss_EXPORT_LABEL, where _EXPORT_LABEL defaults to _OSMTracker.

[jer194]

@Binnette , could this be merged instead of #482 ?
I could then test whether it satisfies the request in #470 (if I get an apk to test ..).

[Binnette]

Same remark here, @Kevin-Salazar-itcr You changed code of ExportToTempFileTask. So your code applies when you upload track to OSM or Share Track.

But we also need the correct name for "Export to GPX", so code in ExportToStorageTask should be changed as well.

Thank for your correction 😊👍

[Binnette]

Hi @jer194 can you write down the export format you want?

Currently when we "Export as GPX", we get :

• A folder 2024-12-10_12-24-58(Are you Ok with this? Or prefer something else?)
• Inside this folder:
  • The GPX: 2024-12-10_12-24-58_2024-12-10_12-24-58.gpx (Should be 2024-12-10_12-24-58_OSMTracker.gpx)

Note we can also have shorter version like 20241210_122458_OSMTracker.gpx

• I prefer this solution, as it comply with the default android picture name. When you take a picture with your Android phone, the name of the picture is 20241210_122824.jpg and not 2024-12-10_12-28-24.jpg

What do you think @jer194 ? 😊

[jer194]

Hi @Binnette,

20241210_122458_OSMTracker.gpx, or
20241210_122458_<custom label>.gpx, or
20241210_122458-<custom label>.gpx

would be all ok for me, and personally I prefer the shorter formats.
I never know whether to use '_', or '-' (not sure whether there is some standard somewhere),
but maybe the delimiter within date/time should differ from the delimiter for the custom label.
In the past I was quite often using 'yymmdd' instead of 'YYYYmmdd', but that's maybe too short, and ambiguous.

Probably specifying the output name via the Unix 'date' format string convention would be the most flexible option for the
(experienced) user :-)

For the directory format, I usually prefer to not use this option.

Thanks a lot to you and all your fellows for all your dedication and work !
Jakob.

[Binnette]

Ok let's go for shorter format then: 20241210_122458_<custom label>.gpx but as stated by @Andyporras in #482

The export name also depends on the setting Filename for named tracks:

• Track name => export to TRACKNAME.gpx
• Name + datetime => export to TRACKNAME_DATETIME.gpx it should be DATETIME_TRACKNAME.gpx
• Datetime =>export to DATETIME.gpx

So there is a "conflict" between this PR and the current behavior.
Maybe instead of hard coding "OSMTracker" in the name of GPX. We should instead add a new setting to allow user pick a default name for track

The setting can be Default track name ans is a entry text with default value "OSMTracker".

And user can customize it. Note It will work only for new tracks as the track name is defined when the track starts.

What do you think @Kevin-Salazar-itcr, @jer194, @Andyporras, @miltonials ?

[jer194]

Hi @Binnette,
your proposal sounds good to me, and hopefully 'DATETIME_TRACKNAME.gpx'
is acceptable for legacy users.
Thanks - Jakob.

[Andyporras]

Hi @Binnette and @jer194,

Thank you for your input. I agree that the DATETIME_TRACKNAME.gpx format is a solid option and should be acceptable for current users.

Additionally, I would like to note that the track name can be modified after the track has started by accessing the track details. This provides extra flexibility and ensures that exports reflect any changes made by the user.

Regarding the Default track name setting, I think it could be implemented as an initial default value while keeping the ability for users to edit it as needed.

What do you think? I’m looking forward to hearing from @Kevin-Salazar-itcr and @miltonials as well.

Thanks again for your contributions and great work!

[jer194]

Regarding the Default track name setting, I think it could be implemented as an initial default value while keeping the ability for users to edit it as needed.

Yes, perfect, that's what I had thought of as well, and also had been proposed by @Binnette in his last post.

[miltonials]

Hi! 👋🏼 @Binnette I agree with the change of filename from TRACKNAME_DATETIME.gpx to DATETIME_TRACKNAME.gpx when the "Name, start date and time" is selected.

With the new functionality to allow the user set a custom label in the filename I think would be great allow the user not set a label too and leave the entry text in blank. A label is not always necessary and may cause long filenames. For example:

• Datetime: 20241210_122458
• Trackname: Santiago Bernabeu Stadium
• Label: Trip_to_Spain

Assuming the order DATETIME_TRACKNAME_LABEL this would result in 20241210_122458_Santiago_Bernabeu_Stadium_Trip_to_Spain.gpt. This potential new option is ideal for the use case mentioned in #157.

---

@jer194, I read your issue #470. You can add custom tags separated by comma in the "TrackDetails" activity. So, while this is implemented you can set tags or description with your device information and it will be exported inside the .gpx

Example using tags and description	As shown in the GPX file

Or maybe change the default folder name in "Storage folder in documents" to a folder like /osmtracker/<<device>>. Or simply add the device name to the trackname. 😄

---

With the duplicate datetime in filename mentioned by @Binnette and @Andyporras in #482. We can add a check to prevent the filename from being the same as the creation date. Maybe in this case we would add "osmtracker" in the filename to export something like DATETIME_osmtracker[_LABEL] .

The current exports filenames with the different "Filename for named tracks" options in develop branch are the following:

I think the issue #333 is only for "Share GPX", so is just needed to follow the format according to the option selected in "Filename for named tracks". This is consistent with the Export GPX and Upload to OSM functionalities.

[miltonials]

I'm not totally sure if implementing a "Custom labels for filename" functionality would provide us an added value. We have the option to add tags and descriptions inside the GPX file, the option to rename the track and the option of export to a custom folder. I think this already solve #157 and #470.

• With custom folder, we can export to documents/<custom name folder> for example set a Trip to Madrid and a National parks as folder name and the next exported trace will be exported to this locations.

./
├── National parks
│   ├── Trace folder 1
│   │   └── parkname1.gpx
│   ├── Trace folder 2
│   │   └── parkname2.gpx
│   └── Trace folder 3
│       └── parkname3.gpx
└── Trip to Madrid
    ├── Trace folder 4
    │   └── Santiago Bernabeu Stadium.gpx
    ├── Trace folder 5
    │   └── Wanda Metropolitano Stadium.gpx
    └── Trace folder n
        └── anotherPlace.gpx

• With tags, we can add any custom label directly in the metadata section of the exported GPX file. Similar with description.
• With rename, we can add any format name that we want.

May be we are overthinking this trying to add a specific functionallity to rename part of a track filename. A better approach would be set default custom comma separed tags for the traces. 🤔

[Andyporras]

Hi @miltonials,

I agree with your point. The current options for tags, descriptions, renaming tracks, and custom folders already address the use cases in #157 and #470. Adding default custom comma-separated tags seems like a simpler and more practical solution than a dedicated "Custom labels for filename" feature.

Thanks for sharing your thoughts!

[jer194]

For me it is not what I would like to have:
If I understand correctly the described method, I would have to edit all tracks before exporting them, to get a
custom file name.
What I wanted was a custom label (always the same) for all the files in a bulk export, and that's what @Binnette (and also @Andyporras) have described yesterday. And I think that's just a different usecase from what @miltonials has described.
My motivation for this wish is what I had put into #470 at the beginning:

I'm using several devices (for fun), and tracks from different hardware are of different quality sometimes.

Anyway, of course I can work around this in other ways, if I'm the only one, and if it is too much effort or too confusing for others. It just would have been convenient
(and less error prone, for my use case) ...

[miltonials]

@jer194, I understand your use case. I think we are trying to 'automate' two similar cases. We can add metadata inside the GPX file and we can rename a track, but in both ways we need to do it manually for each track.

That's why I proposed allowing set "comma-separated default custom tags" for traces, since we have no way to allow it without the user manually entering it. These being in the metadata section within the GPX file can also be identified as a tag when uploading in OpenStreetMap or opening the file in geographic information systems.

In this case "custom filename labels" seems more important for users. We could add this feature, this PR is a step forward to implement it (ty @Kevin-Salazar-itcr ). And if in the future more users need to set custom default metadata within the GPX file, we already know why they need it and the advantages of implementing it.

---

I would like to mention that as I have understood this functionality we have to make some modifications before the merge:

1. Match the filenames for Share GPX with Export GPX and Upload to OSM according to the option selected in Filename for named tracks.
2. Change the date and time format from YYYYYY-MM-DD_HH-MM-SS to YYYYMMDD-HHMMSS and change the order of the Name, start date and time option to something like Start datetime and name for the option in Filename for named tracks (here we could also match the associated photos and voice notes names to the new date and time format).
3. Fix the duplicate datetime in filename when Name, start date and time is selected.
4. Implement this PR.
5. Concatenate the custom labels not only to Share GPX, instead concatenate it to the default name of the trace. This will allow us to have the labels in Export as GPX and Upload to OSM too.

Of course we can implement the points 4 and 5 first, but it would be great if we fix the parts directly involved in the new functionality. I can collaborate in this. 🙋‍♂️

I recommend not allow special characters for labels some OS not allow all the availables, add the filename label inside parenthesis to make a distintion between the name and the label. At the end we would have a result similar to the following

Please correct me if I am misunderstanding something. I would love to hear your opinions on this matter. 😊
@jer194 @Binnette @Kevin-Salazar-itcr @Andyporras

[jer194]

@jer194, I understand your usecase. I think we are triying to "automize" two similar cases. We can add metadata inside the GPX file and we can rename a track, but in both ways we need to do it manually for each track.

Just a clarification about this:
For my use case there would be no need to do it manually for each track, it is a one time change in global settings.

[Andyporras]

I appreciate the detailed feedback and clarifications!

@jer194's Use Case: I understand that having a global setting for "custom filename labels" would streamline your workflow by eliminating the need for manual edits. This aligns well with the goal of automating the process for bulk exports and ensuring consistency across devices.

@miltonials's Suggestions: The proposal to match filenames across all functionalities (Share GPX, Export GPX, and Upload to OSM) and standardize the datetime format (e.g., YYYYMMDD-HHMMSS) makes a lot of sense. Additionally, allowing optional custom labels with clear formatting (e.g., using parentheses) adds flexibility without complicating the experience for users who don’t need it.

Next Steps: Combining these ideas, I believe implementing a global "custom filename label" option in the settings is a valuable step forward. This would support both cases: a global label for consistent file naming (as per @jer194’s needs) and the ability to opt out or customize further (following @miltonials’s recommendations). Addressing the identified points (duplicate datetime, associated media naming, etc.) would strengthen this feature further.

[Andyporras]

Note: this pr already complies with the sharing part, it would only be necessary to add it to the export as gpx and Upload to OSM.

[Andyporras]

Note: this pr already complies with the sharing part, it would only be necessary to add it to the export as gpx and Upload to OSM.

I can take care of this myself

[Andyporras]

The custom label functionality is now implemented in both "Share GPX" and "Export as GPX." Additionally, the bug causing duplicate filenames when the name and date were the same, and the "FILENAME_NAME_DATE" preference was selected, has been resolved.
You can test the pr now @jer194 to see if it meets your needs.

[Andyporras]

The change mentioned to @Kevin-Salazar-itcr by @Binnette has already been implemented. @Binnette, please feel free to review it and share your feedback.
nota: también se ha corregido el error que provocaba que se publicara el nombre y la fecha cuando coincidía con la preferencia FILENAME_NAME_DATE.

[jer194]

The custom label functionality is now implemented in both "Share GPX" and "Export as GPX." Additionally, the bug causing duplicate filenames when the name and date were the same, and the "FILENAME_NAME_DATE" preference was selected, has been resolved. You can test the pr now @jer194 to see if it meets your needs.

Thanks a lot! I'll check as soon as I can get hold of the corresponding apk :-)

[Andyporras]

@jer194 this is the apk:
app-debug.zip

[jer194]

Thanks Andy, it works perfectly for me now!

…

On 16 December 2024 13:24:35 CET, Andy Porras ***@***.***> wrote: @jer194 this is the apk: [app-debug.zip](https://github.com/user-attachments/files/18149896/app-debug.zip) -- Reply to this email directly or view it on GitHub: #483 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

Fixed

[Binnette]

Hi @Andyporras 6 tests are failing. Can you please run the tests in your Android Studio and adapt them to our new code?

[Andyporras]

Hi @Binnette,
Thanks for letting me know. I'll run the tests in Android Studio and adapt them to align with the new code. I'll let you know once everything is updated.

[Andyporras]

@Binnette, I’ve updated the ExportToStorageTaskTest file to reflect the new functionality. The changes resolve the failing tests, and all of them are now passing. Please let me know if additional adjustments are required.