Ticket #28 (new enhancement)

Opened 3 years ago

Last modified 2 years ago

Make GPX format the default storage format

Reported by: saua Assigned to: saua
Priority: major Milestone: 1.0
Component: MIDlet Version: 0.3.0
Keywords: Cc:

Description

GPX should become the default storage format in order to avoid binary blobs that only bbTracker can read.

For this to become reality two things are needed:

  • every bit of information about a track has to be present in the GPX file produced by bbTracker
  • bbTracker must be able to import all of that data (see issue #27)

Change History

08/15/07 16:32:23 changed by saua

  • type changed from defect to enhancement.

09/08/08 04:38:42 changed by davidb

Hi, just wondering if your taking this forward, and checking whether you mean that you would write the gpx file as the data is being processed? I've been using bbtracker for a while now, and one issue is the export - which can take quite a while.

thanks

09/08/08 09:23:46 changed by saua

First I'd have to implement reading GPX data at all (this is which issue #27 is about).

Saving a track in GPX format would take about the same time as exporting one now would, so I don't think there'd be a great performance gain.

Looking into the performance of writing GPX files is another matter altogether.

I'm also wondering if writing GPX files in the phone is desirable at all. I'm planning to provide an online platform where you can upload your files (directly from the phone) and where you can download them in any format that bbTracker supports (and possibly a lot more via GPSBabel).

Would this be a more viable approach for you? Or does this not work for your workflow?

09/09/08 08:33:44 changed by davidb

Re #27, even importing gpx written by bbtracker would be great. I have done some reading of GPX files from garmin & bbtracker for graphing, they didn't seem too wildy different ignoring extensions, the main diff was the timestamp format.

All i am really after is a portable format for the GPS track files - GPX was just the one i settled on - maybe there is something better? To be honest i wasn't planning to use the GPX files on the phone - i have uploaded via opera a few times to view a trail, but that is it - most of my interest is post-processing of the track data.

What i was kind of hoping you would be doing is writing the gpx file incrementally - so there is no final save/export stage - i realise this affects writing things like bounds (really not sure why the GPX spec writers didn't make the sequences easier to write...), but aside from that i can't see that the GPX isn't possible to write as the track is recorded - probably without the weight of an XML lib - maybe i should try this and see how it goes? The main reason for desiring this is that larger tracks (2000+ points) take a while to export, and some have failed - not sure of the reason, maybe memory or a phone/OS bug.

I haven't looked to much at the internal file format you're using, is there a good place to start looking at that from (spec - or the code)