FIT developer field name collision: "LapPower" (PbRun) vs "Lap Power" (Stryd) #463
Unanswered
chcoste
asked this question in
4. Bug Reports / Feature Requests
Replies: 1 comment
|
Regarding the JSON collision, this is documented in the
It might be helpful to make a sample available in case Phil (@boardhead) needs one. If you do not want to share the file publically, you can send an email to exiftool(at)gmail.com. Make sure you refer to this issue (#463) in the email. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi Phil,
While investigating developer fields in a Garmin FIT file (dual Stryd +
pbRun setup), I noticed that ExifTool's tag-name normalization causes a
collision between two distinct developer fields that happen to produce
the same generated tag name.
File details (from -G1 -s -u -ee -a output):
DeveloperDataIndex 0 = pbRun
FieldDescr: FieldName = "LapPower" (no space)
NativeMesgNum = Lap, FieldDefinitionNumber = 211, FitBaseTypeID = sint32
Units = "W"
DeveloperDataIndex 1 = Stryd (Manufacturer ID 95)
FieldDescr: FieldName = "Lap Power" (with space)
NativeMesgNum = Lap, FieldDefinitionNumber = 10, FitBaseTypeID = uint16
Units = "Watts"
Both raw names normalize to the same tag: [Lap] LapPower. With -a, both
values are extracted correctly as duplicates in text/CSV output (in
practice: 4 occurrences per file = 2 apps x 2 laps), so no data is lost.
However:
value survives in the object, silently dropping the other app's data
for that field name.
requires manually cross-referencing FieldDescr/DevDataID, since the
displayed tag name alone doesn't indicate the source once normalized.
Would it be feasible to disambiguate developer-field tag names by
DeveloperDataIndex (or by manufacturer/app name once resolvable, e.g.
via DevDataID) when a naming collision occurs between two different
developer data sources in the same file? Even a fallback numeric
suffix on the generated tag name (distinct from the existing -a
duplicate-count suffix, which currently conflates same-source repeats
with cross-source collisions) would resolve the JSON ambiguity.
Happy to share the full file (or a stripped sample) or run further
diagnostic commands if useful.
Thanks for everything you do with ExifTool and the Geolocation
database — the FIT support in particular has been extremely useful
for endurance-sport data analysis.
Best regards,
Charles-André Coste
All reactions