Re: [Gpsbabel-code] [Gpsbabel-misc] Can help analyze this format and add this?

[Robert L. <rob...@gp...>]

As public closure on this, AzureSky and I worked together to get this
format implemented in GPSBabel.  It's now checked in as 'mapbar' format and
will be in the next release.

That's how formats get added.  He understood (and wanted) the Mapbar half
and was willing to help code it and I worked with him on the GPSBabel half.


On Wed, Feb 27, 2013 at 11:10 AM, Robert Lipe <rob...@gp...>wrote:

> I've added gpsbabel-code (and moved -misc to the bcc list) to increase the
> audiences of programmers that may be willing to implement that for you and
> to move the conversation to a more programmer-ish audience.
>
> That seems like a reasonable start of reverse engineering the format.
>  It's not a format we support today, but formats get added by people
> wanting it badly enough to make it happen, either by writing the code or
> funding it.
>
> I don't quite understand your description, but someone wanting to take a
> run at this format could probably start there (at least read-only) and
> iterate down to something useful.  It's not self-evident why the coords are
> in tuples instead of just a list.  (Why would it be four start-end pairs of
> lat/longs, instead of just eight lat/longs?
>
> Usually the key to unknown values is to run it through whatever vendor
> software you can find and see what's special or otherwise atypical about
> changes in those numbers.  Perhaps your "010000" is the edge of a 3D lock
> or loss of satellite lock, for example.
>
> As a note to whomever tries to implement it, the coord pairs seem to have
> no timestamp or altitude and are 32-bit little endian floats that are then
> scaled to an appropriate number of decimal points to get doubles.  Starting
> from the data at 0x108 at one of his examples:
>
> #include <stdio.h>
>
> char x[] = {0x43,0x66,0x23,0x00,0x8f,0xe3,0xac,0x00,0x5e,0x62,0x23,0x00,
> 0xc8,0xda,0xac,0x00,0x5e,0x62,0x23,0x00,0x8f,0xe3,0xac,0x00,0x6b,0x66,0x23,0x00
> ,
> 0x7c,0x0f,0x00,0x00};
>
> int main() {
> int i;
> for (i = 0; i < 6; i++) {
>   int *ip = &x[i*4];
>   fprintf(stderr, "%d/%d\n", ip[0], ip[1]);
> }
>   return 0;
> }
> 2319939/11330447
> 11330447/2318942
> 2318942/11328200
> 11328200/2318942
> 2318942/11330447
> 11330447/2319979
>
>
> I don't know if it's worth reversing the lat/lon of alternate entries and
> treating them as separate or just skipping the odd numbered ones is best.
>  It's probably best to do whatever the native software does.
>
> Frankly, you could implement a super-simple reader for this format just by
> ignoring all the data up to 0x108 and reading tuples until you hit the EOF.
>   It's probably worth some study to see if the things like track name are
> actually fixed length or variable length.  If the latter, that might mean
> it's not a constant ot "0x108", but you may have to read the other things
> to find out where the track starts.
>
>
>
> On Wed, Feb 27, 2013 at 6:00 AM, AzureSky <azu...@gm...> wrote:
>
>> I try to analyze this, ant got this result:
>>
>> 1.head (0000~00DF), the name maybe in 0018~00DF(with wchar_t,2byte)
>> whit \0 at end
>> start time (UTC):
>> 0000~0001: hour,
>> 0002~0003: minute,
>> 0004~0005: second,
>> 0006~0007: year,
>> 0008~0009: mouth,
>> 000A~000B: day,
>>
>> end time (UTC):
>> 000C~000D: hour,
>> 000E~000F: minute,
>> 0010~0011: second,
>> 0012~0013: year
>> 0014~0015: mouth
>> 0016~0017: day.
>>
>> 2.body 1 (00e0~0113), I think it is about start ,end points, way
>> length and other information.
>>
>> thie point is my real traker.
>> start point: 00e0~00e7
>> end point : 00e8~00ef
>>
>> thie point I dnot know purpose.
>> start 2 point :00f0~00f7
>> end 2 point: 00f8~00ff
>>
>> there points look like:
>> point 1 (A, B) (C, D)
>> point 2 (C, B) (A, D)
>>
>> but there are subtle differences. for example:
>>
>> 2013_02_23_15_58_23.trk:
>> 1 (23.17511,113.29513) (23.17064,113.29699)
>> 2 (23.17061,113.29513) (23.17513,113.29753)
>>
>> 2013_02_23_13_46_42.trk:
>> 1 (23.19939,113.28200) (23.18942,113.30447)
>> 2 (23.18942,113.28200) (23.19979,113.30447)
>>
>>
>> way length:0100~0103, but the 0104~0107 are zero(all file are the
>> same), maybe the length is long type.
>>
>> 3.body 2(0108~~end)
>>
>> unknow:0108~010B.all file are Fixed value:2A. maybe is buffers max size.
>>
>> The following space are coordinates.
>>
>> each coordinate buffer have 8byte head. In head, the front 4 byte has
>> 2 states: 010000 or 000000, unknow purpose.
>> The last 4byte I think it is buffer length, but the real length is it +
>> 16.
>>
>> all coordinates are int type, <longitude, latitude>
>>
>> I don't know whether it is a new foramt for GPSBabel, if yes, Can add
>> it to GPSbabel?
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Gpsbabel-misc mailing list http://www.gpsbabel.org
>> Gps...@li...
>> To unsubscribe, change list options, or see archives, visit:
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>
>
>