Use standard "Version:" label for CSV logging

[mash-graz]

while developing a nom based parser for the android RAW GNSS log file format, i stumbled over some issues concerning the "Version:" notation in the header and its subtle and incompatible differences in various implementations.

in contrast to googles RAW GNSS Log app, which uses a rather minimalist line of metainformation in it's log file header:

# Version: 1.4.0.0, Platform: N

GPSTest reports a much more verbose sequence of key-value-pairs in this section -- e.g.:

# GPSTest version: v3.8.4 (18076-osmdroid), Manufacturer: Xiaomi, Model: MI 8, GNSS HW Year: 2018, Platform: 9, API Level: 28

and other apps, like GPS Compare, even do not use comma separators in this line:

# Version: v2.0.0.1 Platform: 9 Manufacturer: Xiaomi Model: MI 8

all those variants are somehow valid, because the actual file format of this kind of log files was never explicitly specified anywhere in a more precise or formal manner and the actual compatibility to googles open source gps-measurement-tools are just determined by some vague implicit expectations realized in matlab code (ReadGnssLogger.m#L108). your remarks about this kind of log files in the GPSTest documentation are perhaps the most prominent source of information in practice, but unfortunately it also doesn't tell us anything useful about this particular header line.

although i like the additional information about the used hardware device etc. in this line of the GPSTest log file variant, because it looks rather useful e.g. for translation to RINEX files and their common metadata headers etc., i really have to criticize this preluding GPSTest version: key resp. the hardcoded VERSION_TAG used by this app.

sure, i could workaround all this peculiarities and slightly different appearances of the version-header-line in already existing apps by my parser grammar, but in case of GPSTest, which i really learned to like as very reliable solution for RAW GNSS logging on android mobile devices, i would suggest a more exemplary resp. compatible solution:

opening the line by using a simple more common Version:-tag as in googles reference implementation, would make the parsing much easier and cleaner.

it still makes sense to add the actual used software and its version in additional key value pairs, but IMHO this very prominent opening "Version:"-field should mainly refer to the actual file format resp. the expectations about all following data in the file. if we do not support this fundamental requirement, it will be very hard to realize any upcoming changes in the file format.

well -- it's somehow a rather hopeless cry, because many other questions about this file format and its compatibility still remain unsolved (e.g. which field order and filed names do we have to expect, etc.), if we could agree at least on this particular detail and fix it in case of GPSTest.

frank van diggelen (@gpsFrank) has already announced a new version of googles reference implementation of GNSSLogger and the measurement tools for Q3/2020. most likely this will introduce new changes and challenges for support of this file format in other compatible apps. nevertheless we should try use its richness of information...

[barbeau]

@mash-graz Thanks for opening this! I agree, this is a bit tricky as the format isn't officially standardized.

So in short I don't have a strong objection to changing this version key name to match the other apps if that makes parsing easier. This was an attempt to clarify that the file originated from GPSTest and not GNSSLogger, but that's likely apparent from the longer version string anyway.

I'll make this change for the upcoming release.

One note, which is implied above but I just want to be clear from anyone following this - the Version: output above is the Android app version, not the file format version. So it's very much unique to each app. If you're tracking what file format changes are make in each app based on the version then I think it's useful. But without that knowledge it won't be useful to compare this version number across files generated from different apps.

[mash-graz]

thanks for your fast and helpful reaction!

the Version: output above is the Android app version, not the file format version. So it's very much unique to each app. If you're tracking what file format changes are make in each app based on the version then I think it's useful.

yes -- the semantics of this "version" field will unfortunately always stay ambiguous.

but as long as all apps try to mimic the behavior of a specific reference implementation in its actual release as close as possible, the relevant information for a correct interpretation of the data should be at least accessible by a little bit of guesswork, if not necessary strictly deducible.

thanks again!