[fixed] New version pushed to phone

[joss]

In the older release that was replaced, I could save a track by simply pressing one button in the landmarks view. This would allow me to select an export type (I prefere GPX) and to name the file and give it a description. The exported gpx would also contain the date of the hike in the file name. All one dialog. The file went to the app data folder.

I believe that with the release that was just pushed to my phone I have to take many more steps:
1: Select "save and stop" from the landmarks, there is no option to name the file or select a type.
2: View prior tracks to locate the file just closed.
3: Select my track.
4: Open the 3-dot menu and choose to edit the track to give it a name. Remember to add the date to the name.
5: Select the track again
6 Open the 3-dot menu and choose to export the the track as a GPX. The file goes to the "Exported Landmarks" folder in the app data folder.

This is a bit more complicated.

Am I doing this wrong, or did you indeed make this more complicatd than it used to be?

[Psyberia-Support]

Hi
Yes you're right this is more complicated if you need to directly export the track.
I'll will improve this point in a stability release that will be available quite soon.
Sorry about that
Best regards

[ds47uk]

I agree with Joss that there is a need to be able to export directly to GPX. I just got back from a trip with several TRK files (because I couldn't figure out how to save them as GPX!). Now I know why!!

regards
David

[vieuxdelamontagne]

I just want to add a little sense of urgency to this issue. ".gpx" has (finally; let us all render thanks) become a de facto standard for exchange of track and waypoint data. I'd like it to be the default, but I'll be happy if it's made easy to invoke in AlpineQuest.

Additionally, I'd sure like to see a return to the previous track file naming convention, because I have hundreds of track and waypoint files that use it, all stored on my computer where they are easy to find and use in cartography applications. It's also important that the .gpx files, as well as the .aqm maps, be easy to store and use on the microsSD card, so that it is easy to move them between gizmos.

Thanks. Otherwise--I like the new style, and the English is both accurate and colloquial.

--Bill, aka VieuxDeLaMontagne

[Psyberia-Support]

GPX, as the name stand for, is an "exchange" format (and a good one as you point out), offering great compatibility between apps. But it's absolutely not suited for a "working" format (I don't know any professional app that use it by default, including Google Earth, MemoryMap, QGIS, etc). It is text based (so good for human reading), but very long to read and save for a machine. It doesn't support areas, polygons, nor styling (coloring, dashes, etc.)... After displaying few GPX files, the app took ages to startup. Now with the new binary format, it loads in microseconds...
I understand your frustration, but it was just not possible anymore to use it like this. Now after the import (which is "transparent", just select a GPX file from your android file explorer or from the app's landmarks explorer), you can enjoy all the features of the application. I have already spent too much time answering questions like "why can't I change the color or add dashes on my track displayed on the map like explained in the online help", just because it was in the GPX format...

For the naming convention, it hasn't changed (as far as I remember).

[ds47uk]

GPX, as the name stand for, is an "exchange" format (and a good one as you point out), offering great compatibility between apps.

And that's why it is such a loss to users of AQ who (like myself) synchronise AQ data with their PCs (or Macs or whatever) and use other (Windows) programs to process the information. Programs such as GPS Track Editor or Route Convertor. It is MUCH easier to use a Windows program to do this than any Android app. OK - so we can still generate GPX files, but it is just a bit of a fiddle to do what used to be so easy - hence the moaning!

[redmanr]

Not quite sure how I got to the right place, but exporting to GPX does seem to be a (hidden) part of the interface. I had previously gone through the many steps needed to give a name to the track, just "test" in this case, and was back looking at the track displayed on the map. tapping the track popped up a two item menu to select the track or the waypoint; selecting the track popped a much larger menu of actions I could do with the track, one of which is "Export".
The actual name of the exported file is "export_test.gpx", which is a completely different naming convention than was previously used. Like others, I preferred the old naming convention track_date_time_myname.gpx. Especially, I liked having the datetime embedded automatically in the name. When I am entering a new name I cannot see which names I have already used. Embedding the datetime in the name autoatically saves me from accidentally overwriting an existing file even if my memory is faulty. It also lets me use the name I provide as an identifier for a topic to help group related tracks.
Export now lists a large number of file formats. This looks like a real improvement in the functionality of the app - many thanks for the hard work. I am sure I am going to like the program even more than I did before.

[redmanr]

Just reread my last post and realized that it waffles too much. My real suggestions are:
1) Exporting a track should be one of the top-level options (which I am sure you already understand).
2) The track should have a default name that looks like track_date_time, where the date_time identifies the START of the track and will not change if the user chooses to resume adding waypoints to an existing track.
3) Renaming a track is still a useful operation, but should NOT be required to export the track.
4) It should be possible to change the name of an exported file in the Export dialog without necessarily changing the name of the track.
Many thanks,
Russell

[theksmith]

the new landmarks interface is a huge step backwards.

one of the main reasons i used AQ over similar apps was that GPX was natively supported instead of having to do the import/export dance constantly.

yes, GPX can be slower. yes there are technical limitations to the format. but completely removing the option for your users to work natively in that format was a mistake. please put the ability to work directly with GPX files without import/export BACK into your app.

[Psyberia-Support]

redmanr, I completely agree with points 1, 2, 3. The next update should work like this.

For 4, it's always possible to rename an exported file without changing the track name if you want (long press a GPX/KML file and select "Rename").

[Psyberia-Support]

theksmith: I'll improve the import/export process.
My point of view is that the support of GPX is still "native", you don't need to configure anything or install addons to make it work, the app can handle this format by default.
Now, talking about import and export can sound complicated, but it's not. You just have to see it as an "open the file, work on it, save&close it", something you do with all documents. Just replace "open" by "import" and "save and close" by "export".
At least this is what I want to achieve, that's why I still need to improve the export part to be more straightful...

[theksmith]

the reason it's not "native" to me is that the GPX file is not actually open and being edited. let me attempt to explain why i feel this import/export maneuver is such a hassle to anyone that actually stores multiple GPX files and uses them in different apps...

as a user i now need to remember to export and overwrite the original file if i make a change in AQ, instead of just closing the app. that's not too bad of a deal unless the GPX has been edited elsewhere and now i'm overwriting my other changes to it. or, if i do happen to forget to export before i open the GPX in another app, then i'm going to end up with a mess of changes and overlapping files.

if AQ isn't going to work with the actual GPX file directly then i think it should have some advanced abilities to detect and merge changes between an imported file and the source GPX.

the import workflow is actually more of a concern than the export procedure. i'll likely remember to export if i've just made changes in AQ. but with hundreds of GPX files that i use in multiple programs, how do i easily know for sure if i have edited a GPX since i last imported it into AQ? this matters because if i don't know whether AQ's imported version is "in-sync" with the GPX, i'll need to re-import every GPX each time i use it in AQ and that creates a bunch of duplicates in AQ's imported folder with just numbers appended to the name. so now as a user i've got to constantly clear out all these duplicates and hope that i don't delete something with pending changes that i forgot to export.

i am quite familiar with the fact that many other apps do require import/export as well - but that was one of the very reasons i chose AQ as my "go-to" app previously. you seem adamant about not using GPX as the native (directly edited/preferred) file format. therefore i'll just hope you can understand these issues and provide some innovative functionality that addresses them.

[Psyberia-Support]

Version 2.0.1 now ask you for a name as soon as you've finished to record a track (like before).
The saved and exported files now also have the previous naming scheme.

Also, when importing a file that as previously been imported, the application ask to re-use the existing copy or import another one.

[theksmith]

Version 2.0.1 now ask you for a name as soon as you've finished to record a track (like before).
The saved and exported files now also have the previous naming scheme.

Also, when importing a file that as previously been imported, the application ask to re-use the existing copy or import another one.

both good updates, thanks!