bring back See You support #1280
Conversation
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesCodacy will stop sending the deprecated coverage status from June 5th, 2024. Learn more |
|
I also note these files were deleted, not moved to deprecated, so I had to resurrect this from git. |
|
@Plantain I will also point out that with style based formats like cup, you can very likely use a version of gpsbabel that had this format deleted if you have the style file (cup.style) e.g. |
|
I might be able to get my hands on some SeeYou files, it's used by many glider pilots. I don't use it myself but I can certainly ask around. |
|
CUP files collected just from my computer, not guaranteed to be technically valid, but all "real" files being actually used. CUPX files (an extended format of cup, suspect this was not previously supported and not necessarily proposing it needs to be - https://downloads.naviter.com/docs/SeeYou_CUPX_file_format.pdf ): |
|
For the strictest validation, there is a python library aerofiles that checks very rigidly (https://aerofiles.readthedocs.io/en/latest/api/seeyou.html) For more 'general-purpose' validation, I can manually test files across broadly used software (SeeYou Desktop/Cloud/Navigator, and various other devices) |
|
Our support for seeyou assumes a few things that are not guaranteed by the latest cup format spec I could find. These assumptions allow us to use our generic xscv format with a style file to designate the fields. With this approach we don't have to write any c++ code, just the style file (cup.style). If you have been happy with the support for seeyou that gpsbabel has offered in the past which had these assumptions then we can go ahead. Alternatively, if you desire support that allows for the variability allowed in the latest spec then a custom format would be required. This would be much more work to develop and maintain, and I am not willing to volunteer for that. My willingness to bring this format back is predicated on being able to support it with a style file as we have always done. |
|
As it was worked well for many people. I think the only reason no one else
noticed yet is distros stable releases lagging behind.
…On Fri, May 17, 2024 at 4:17 PM tsteven4 ***@***.***> wrote:
Our support for seeyou assumes a few things that are not guaranteed by the
latest cup format spec I could find.
https://github.com/naviter/seeyou_file_formats/blob/main/CUP_file_format.md
i) we assume a fixed order of the columns. specifically:
name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc
ii) we assume elevation is designated by m for meters. we do not support
ft for feet.
We read the following fields: code, lat, lon, elev, desc.
These assumptions allow us to use our generic xscv format with a style
file to designate the fields. With this approach we don't have to write any
c++ code, just the style file (cup.style). If you have been happy with the
support for seeyou that gpsbabel has offered in the past which had these
assumptions then we can go ahead. Alternatively, if you desire support that
allows for the variability allowed in the latest spec then a custom format
would be required. This would be much more work to develop and maintain,
and I am not willing to volunteer for that. My willingness to bring this
format back is predicated on being able to support it with a style file as
we have always done.
—
Reply to this email directly, view it on GitHub
<#1280 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACODFZGVBYG3KCVHZNGKVTZCYGPZAVCNFSM6AAAAABH3AANVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXG4YTGNZRGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
OK, I will bite on this one. cup is a style based format which requires minimal support. Just as that came out of my mouth the cup documentation bit me on the docbook 4 -> 5 conversion we did some time ago, nothing is free.
What we never had was any testing of the cup format. @Plantain can you supply some small files representative of this format and verify the results of a conversion to and from that format? If so perhaps we can bring this one back.