-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
garmin_fit does not support course_point types well #1182
Comments
Also the list of types is not complete (I know it is only a comment): Line 224 in dfc770a
A full list of types can be found in the mentioned SDK. Open |
I figured out that the code is not called and found this: Line 1277 in dfc770a
Unfortunately the intermediate "format" Could that be enhanced? For example: gpx waypoint has the name "water spring" or "WATER spring" the course_point is assigned type 3 and the name "spring". Or do you see any other way to around that limitation? |
Actually, the gpx reader records the value of the sym element as the field icon_descr in the Waypoint class. |
What he said.
We have dozens of examples (some good, some bad) of code turning numeric
values into textual strings inside icon_descr and then doing the inverse
for the opposite in read/write. Supporting round-trip to GPX/CSV is table
stakes. You get bonus (imaginary internet) points for applying the Postel
Principle. If you can take take either "red flag" and "flag, red" on read
and convert those to 1,475 internally (or whatever) and then write the
"best" on output, everyone wins.
hummin_bird_icons is a reasonable example.
osm_icon_mapping is a featureful example as they have complicated problems
garmin_icon_tables contains hundreds of icon # mappings as used in their
receiver and mapping products. It's complicated because "Airport" is 107 in
Mapsource and 16384 in PCX, for example.
It looks like the code you've pointed to kind of tries to do this, but only
for five languages worth of "left" and 'right". That is, well, interesting.
Our older formats tend to use brute force traditional linear table lookups.
Newer code tends to use more C++ indigenous structures like maps and
hashes
If you have knowledge of a number<->string mapping for icons, there are
plenty of examples for you to add here. Looks like you found the place on
read and probably let fit_parse_data look in lappt (?) f.course_data_type
or whatever to look up the textual valu of that number. We can work with
you to get it integrated if you can work out the tymbol table and get it
basically working from your device/.
…On Mon, Oct 9, 2023 at 4:11 PM tsteven4 ***@***.***> wrote:
Unfortunately the intermediate "format" Waypoint does not support
something like a type or symbol.
Actually, the gpx reader records the value of the sym element as the field
icon_descr in the Waypoint class.
—
Reply to this email directly, view it on GitHub
<#1182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD32FSV5LZZ7B53PMRTX6RSBDAVCNFSM6AAAAAA43WHPN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHA4DGMRXHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hello,
I am using gpsbabel to convert gpx files to fit. After some debugging I have found out that gpsbabel does not take the icon types into account when converting the gpx to fit.
I tried the following combinations in my gpx file:
sym
tag with numeric type (e.g.<sym>3</sym>
for water)sym
tag with lower case type (e.g.<sym>water</sym>
)sym
tag with upper case type (e.g.<sym>WATER</sym>
)type
tag with numeric type (e.g.<type>3</type>
)type
tag with lower case type (e.g.<type>water</type>
)type
tag with upper case type (e.g.<type>WATER</type>
)I then converted those 6 files to fit using
gpsbabel -i gpx -f file_x.gpx -o garmin_fit -F file_x.fit
I then converted the fit files to csv using the FitCSVTool from the Fit/Garmin SDK (https://developer.garmin.com/fit/download/):
java -jar Downloads/FitSDKRelease_21.115.00/java/FitCSVTool.jar -b file_x.fit file_x.csv
Then I was sure that it must be an error in gpsbabel. I search your repository and found this line: https://github.com/GPSBabel/gpsbabel/blob/dfc770ac0a68a0827f89ddf8ef09c5766f16a53c/jeeps/gpscom.cc#L1282C5-L1282C34 I am not sure if this code is really used when converting....
I did not find any upstream repository for "jeeps" so I am reporting this here.
I would expect that when I convert a gpx file with a waypoint with
<type>WATER</type>
(or maybe<type>water</type>
) to be converted to acourse_point
withtype = 3
The text was updated successfully, but these errors were encountered: