batch GPX export (or TRK file format)

[flipflip]

Hi,

exporting all my tracks to GPX (for use in photo management software for geotagging) is quite tedious.
Any chance there could be a batch export all tracks to GPX tool implemented?
Otherwise, can you disclose the TRK file format so that I could write my own script for that (which I would be happy to share)? (Unless the format is changing with every version..)

Thanks!

Regards,
flipflip

P.S. Awesome app, btw! I use it all the time.

[Psyberia-Support]

Hi and thanks for your support!
Here is a tip that should help you: create an empty "landmark file" (from the landmarks explorer, use the + button create it), then copy/paste all your tracks inside it (to do it in one time, click on the dot menu right of the "Tracks" category header and select "Copy all"). Then export the landmark file in a GPX file.
Let me know if you have any problem or question.

Note that the specs of landmark formats used by the application is published here, but for sure the method above is much easier!

Best regards

[alexlong]

Hi.
Either I do it wrong or something is wrong in 2.0.7 beta
I can copy a gpx track but I can not paste it into the empty "landmark file". Trying to do this I see clipbord —> "clear" command but not "paste" command. I can explain further or make a screen video if necessary.

[flipflip]

Hi

Neat! That worked (version 2.0.5)!
Note that pasting into the empty landmark file triggered the "application not responding" thing in Android (a few dozen or so tracks a few hours each). It toke a while to complete the paste. Not a problem for me.

Thanks also for the file format specs. My google-foo wasn't strong enough to find that. I'll post here if I come up with something useful for others. A presume you would be okay with me creating and releasing scripts dealing with alpine quest files or adding support to existing open source software?

Regards,
flipflip

@alexlong: The "paste" function is the clipboard icon, not a menu entry.

[alexlong]

I know. Please have a look here (screen video from my device) —> Copy-paste wpt and gpx
I can copy and paste a .wpt waypoint but I can not do it the same with a .gpx waipoint.
I do not quite understand what I've done wrong.

[Psyberia-Support]

Hi Alex,
Actually you cannot paste .GPX files inside "landmark files" or any other types of files. You can only paste native Alpinequest landmarks like waypoints (.wpt), tracks (.trk), etc.
It's not like a generic zip archive or so, it's really another type of AlpineQuest landmarks. It allows the application to display a while landmark files (whereas you need to import GPX files and cannot display them).

@flipflip: last version released on Google Play (2.0.6) should have a progress bar when pasting lot of items to avoid the "app not responding" message.
Also, feel free to do anything with the specs, but don't hesitate to ask new actions instead of spending lot of time on it. For your information here is a pearl reader for .wpt waypoint files.

[alexlong]

Thanks, understood.

[flipflip]

Thanks, Psyberia.

I've got something working for the TRK, WPT, SET, RTE and ARE files. I've noticed that the specs don't seem to be up-to-date:

- There seems to be a 0xffffffff (-1?) after every {Metadata} in newer files. I have an old version 2 trk file that doesn't have that but with otherwise identical {Metadata} structs.

- The {Segment} struct spec isn't correct. There are two ints (always 0x00000000 and 0xffffffff it seems) before the number of locations field in version 3 TRK files, and one int (0x0000000 I think) in version 2 TRK files.

- The TRK header doesn't seem correct in the spec for both versions. I'm using this, which seems to provide results more or less in line with what AlpineQuest displays for the same file:

Code: Select all

        # - int         file version (= 3)
        # - int         header size (size of data to before {Metadata}, = 4 + 4 + 4 + 4 + 4 + 8 + 8 + 8 + 8 + 4 + 4 = 60)
        # - int         number of locations (not documented in spec)
        # - int         number of segments
        # - int         number of waypoints
        # - coordinate  longitude of first location
        # - coordinate  latitude of first location
        # - timestamp   time of first location
        # - double      total track length (in m)
        # - double      unknown (not documented in spec), accuracy?
        # - double      total track elevation gain (in m)
        # - long        total track time (in s)
        # - {Metadata}
        # - {Waypoints}
        # - {Segments}

- I'm using this for the RTE header:

Code: Select all

        # - int         file version (= 2)
        # - int         header size (size of data to before {Metadata}, = 4 + 4 + 4 + 8 + 8 + 8 + 8 + 8 = 52)
        # - int         number of waypoints
        # - coordinate  longitude of first waypoint
        # - coordinate  latitude of first waypoint
        # - timestamp   time of first waypoint
        # - double      total route length (in m)
        # - double      total route elevation gain (in m)
        # - double      unknown (not documented in spec), always 0x7ff8000000000000 (NaN) it seems
        # - long        total route time (in s)
        # - {Metadata}
        # - {Waypoints}

Do you have some info on the LDK format?

Regards,
flipflip

[Psyberia-Support]

Hi and thanks a lot for your reports.
I've published a new, corrected, version of the specs.

For the .ldk format, it's actually a container of other files (a bit like a tar archive), but each landmarks are stored using the same file format inside it.
I'll try to find time to publish its specs (at least the parts used for landmarks), I'll let you know soon.

[flipflip]

Hi and thanks, too!

I've identified the WPT and other files within the LDK format. I could probably work out the structure around it. But if you can document it, that would be easier.

Thanks for the update on the TRK format. This raises another question: I have a real-world track. I extract this:

- total track length = 13160.21
- total elevation gain = 745.0
- total track length due to elevation changes = 221.0

AlpineQuest shows for the same file in the statistics section:
- length = 13.37 [km]
- gain = 745

So the gain is okay, I see the same in the file. But the total track length doesn't match. And the total track length due to elev. changes (221.0) I see in the file (from app version 2.0.5) doesn't make sense. Is that perhaps _additional_ track length due to elevation changes? (although just 221 metres doesn't seem right either for last weekend's hike)
If it were: 13.160+0.221=13.381km is closer to 13.37km displayed in the app than 13.16..

Don't worry, I don't care too much. All the positions I get out of the TRK file are okay and that's all I'm after. There's no place for this information in a GPX file anyway.

I'm much more interested in the LDK format details.

In case anyone's interested: I have a Perl tool that can read all the landmark files (but the LDK ones, so far) and write JSON and GPX files. I'll upload it to github soon and post the link here.

[Psyberia-Support]

Hi again,
I've written a basic specification for the archive container used by .ldk files.
It's available here.

Concerning the statistics stored in the file headers for tracks and routes, they are indicative only. They are used for previews and sorting without having to load all the file content. But the application will compute its own statistics in the "Details" view, based on the user settings (especially the noise reduction setting will impact the results).

[flipflip]

Hi,

many thanks! I'm getting somewhere. Nice puzzle. I'm enjoying it!

[flipflip]

In case anyone is interested, the script is here: https://github.com/phkehl/apq2gpx

[Psyberia-Support]

I'm impressed! Good job. And thanks a lot for sharing it.

[Yoshida]

In case anyone is interested, the script is here: https://github.com/phkehl/apq2gpx

Thanks flipflip! The script works perfect, big timesaver.