Split in WPT-file into waypoints-only and airfields-only files

[Joerg-CH]

I was thinking of deprecating the airfield data from these files and just keep the turnpoints, and rename the files as such. The openaip data is i hope better maintained.

Following your comment in PR 501, I created an airfield file from OpenAIP, and removed these airfields in the existing waypoint file DE-WPT-National-XSCoar.cup.
Unfortunately, the direct export from OpenAIP in the "SeeYou CUP" format does not have much information in the description field (desc): no "Flugplatz", no "Segelflug" no "UL", only some additional info more important to powered aircraft.

Therefore, I created the CUP-file DE-APT-National-XCSoar.cup based on the downloaded information from OpenAIP.

The values for the CUP-file are taken from an "Newline-Delimited GeoJSON"-file with a VBA-macro (I am not so fluid with other programming languages), which gives basically the same output as the "SeeYou CUP" format in OpenAIP - except the rwdir, where I could not see a clear pattern, when the direction in the "SeeYou CUP" is lower or higher than 180°. In the new file, the rwdir is now allways >=180°.

The difference to the direct downloadable "SeeYou CUP"-file is the field description (desc):
If available on OpenAIP, there is

• the Callsign of the primary radio frequency (which is given in the "freg"-field),
• Frequency and Callsign of a glider frequency,
• classification as "Segelfluggelände" or "UL-Platz",
• info about glider towing or winch-only,
• info "Sprungbetrieb" if skydive activity,

plus the existing remarks from OpenAIP.

In the airfield details, this looks like:

With unusual callsign:

With additional remarks from OpenAIP:

Compatibility: For older versions as v7.44 (only 1 waypoint file selectable), the "100%"-file DE-WTP-National-XCSoar.cup should be still downloadable. Perhaps it could be renamed then to: DE-APT+WPT-National-XCSoar.cup.

What do you think about this? Or is the additional information in desc not really necessary (Landefeld has already a different icon as Flugplatz/Segelflug)?
I have prepared a pull request for the modified/new files, but want to wait for discussion before launching it.

[lordfolken]

That dialog has always bothered me; that it doesn't show the icon nor the type of waypoint. Abusing the comment field for this was done to put this into ancient navigation computers such as CAI-NAV and LX5000.

The cup format has some differentiation of what type a landable is:
https://github.com/naviter/seeyou_file_formats/blob/main/CUP_file_format.md#7---waypoint-style

2 Airfield with grass surface runway
3 Outlanding
4 Gliding airfield
5 Airfield with solid surface runway

But there isn't a UL designation.

One thing which we are currently not parsing from a cup file is rwwidth. https://github.com/naviter/seeyou_file_formats/blob/main/CUP_file_format.md#10-runway-width (which actually would be useful, given large span gliders...) (and would also be interesting for some warning logic)

Openaip allows for remarks, and these are added to the cup export file; see the remarks field here:
https://www.openaip.net/data/airports/6261519acb27f42509466e36
and the cup entry:
"DITTINGEN","LSPD",CH,4726.316N,00729.484E,536.0m,4,290,620.0m,30.0m,118.180,"Takeoff only on RWY 11\nLanding only on RWY 29"

Potentially more of the data could be added to the comment field automatically by openaip's export. but this is something that should be discussed with @reskume in https://github.com/openaip/openaip/issues/

But yeah.. CUP is designed to be user generatable and it unfortunately has stuck around. Its a severely limited format, and not extensible.

[dspreitz]

Dear all,

now that XCSoar reads CUPX (FileType::WAYPOINT includes *.cupx), the AIP
approach charts can travel inside the waypoint file itself. That is why I
think the split proposed here makes sense — and it also addresses the
problem that started this thread from a different angle.

@lordfolken's point about desc being abused to carry "Segelfluggelände",
"UL", winch-only and so on: with CUPX that pressure largely goes away. If the
actual visual approach chart is on screen when you select the aerodrome, you
no longer need to compress the field into a comment string. The information
that matters — traffic pattern, frequencies, runway data, local restrictions
— is on the chart, in the form the authority published it.

A working example for France

I combined the French openAIP waypoint file from this repository with the
visual approach charts from the French AIP VFR (SIA):

• 11,921 waypoints, of which 420 aerodromes carry charts
• 1,640 chart pages (Approche à vue, Atterrissage à vue, plus the
  associated text pages)
• AIRAC 2026-08-06, 146.6 MB
• SHA-256 f11679a6f71d8999eda50be3e148f0cdf9f8068449f927323fa65df50dc82fdc

Download (release asset, because of the size):
https://github.com/dspreitz/xcsoar-data-content/releases/download/fr-vac-2026-08-06/FR-WPT-National-OpenAIP.cupx

Licences — please read before considering this

Two sources, two licences, and the stricter one wins:

• Charts: SIA France, Licence Ouverte / Open Licence (Etalab).
  Redistribution and commercial use are explicitly permitted, subject to
  attribution and to not altering or distorting the information. The
  attribution is carried in the userdata column of every waypoint.
• Waypoints: openAIP, CC BY-NC 4.0. Non-commercial only — and that
  restriction propagates to the combined file. Anyone reusing it inherits
  it.

The charts are reproduced unaltered apart from rasterisation (PNG, 64
colours, 1240 px long edge); no cropping, no overdrawing.

Germany is not possible today

The DFS terms still prohibit redistribution. I asked them; the reply came
from their Aeronautical Data department and covers only the AIXM datasets at
https://aip.dfs.de/datasets/ — those are planned to move to CC-BY-4.0 "later
this year", though the portal still shows the old restrictive notice. The
VFR charts fall to a different department and that answer is still pending. I
have built a German file for my own use but cannot share it. I filed #555 to
track the dataset side separately.

Questions

1. Is this direction useful to the project at all? If the answer is "CUP
   files should stay small and text-only", that is a fair call and I would
   rather hear it now.
2. If it is useful: data/remote/waypoint/country/ already exists for
   externally hosted content, and the largest file currently in the repo is
   1.25 MB — so committing a 146 MB binary is clearly out. Would a remote
   entry pointing at a release asset be acceptable, and should the asset live
   in this organisation rather than in my fork?
3. check_waypoints.py validates .cup through aerofiles' CupReader,
   which will not accept a .cupx (it is two concatenated ZIPs). If CUPX is
   to be supported, that check needs a branch. I am happy to write it.

I can automate the whole chain to follow the 28-day AIRAC cycle — the French
fetch already resolves the current cycle by itself. Before I invest in that,
I would like to know whether the result has a home here.

On size: 146 MB is a lot for an Oudie. A charts-only variant (visual
approach and landing charts, dropping the text pages) is about a quarter of
that, and resolution is a further lever. If the format is welcome in
principle, I would tune the defaults to whatever the project considers
reasonable.

[lordfolken]

So a couple of things:

• attribution is not a problem, but belongs in the main repo: THIRD_PARTY_NOTICES.md and AUTHORS and in a comment line for the dataset
• Openaip explicitly states: "Third parties may ship openAIP data with paid/commercial applications as long as they don't exclusively sell openAIP data, e.g. as a paid monthly data update."
• We already offer the cupx files from openaip containing images for the airfields that have them
• Unmanaged data i don't want in the repository. It ages quickly and the people that created it disappear. Posing more a threat to safety than solving a problem.
• desc being abused to carry "Segelfluggelände",
  "UL", winch-only and so on. -> This is addressed in recent xcsoar releases as we now show the waypoint type column in a text field, so description is no longer necessary.
• for me the added value would be a job / process that creates these datasets automatically
• for me even more added value would be if those charts would find their way into openaip or openflightmaps and we consume from there. have you talked to @reskume from openaip?
• enroute seems to also serve some VACCs from France: https://github.com/Akaflieg-Freiburg/enrouteServer/blob/main/scripts/generateVACCollections.py their dataset is even georeferenced and the approach charts are overlayed on the map

About cup/cupx:
This format is severely limited. CUPX with the two unnecessary zip files is plain braindead.
cup doesn't support multiple frequencies, runways, or for example extensible flags such as airtow available.
I think these formats are holding gliding back in general.

[dspreitz]

Hi @lordfolken ,

thx for getting back on this.

• attribution is not a problem, but belongs in the main repo: THIRD_PARTY_NOTICES.md and AUTHORS and in a comment line for the dataset

OK, understood. No problem.

• Openaip explicitly states: "Third parties may ship openAIP data with paid/commercial applications as long as they don't exclusively sell openAIP data, e.g. as a paid monthly data update."

OpenAIP license was not my concern. The license of DFS and others is my concern.

• We already offer the cupx files from openaip containing images for the airfields that have them

I wasn't aware. Thx for the hint. Will check.

• Unmanaged data i don't want in the repository. It ages quickly and the people that created it disappear. Posing more a threat to safety than solving a problem.

Understood and agreed. My hope is to provide sth automatized based on the 28 day AIRAC cycle. Outdated files should be deleted automatically.

• desc being abused to carry "Segelfluggelände",
  "UL", winch-only and so on. -> This is addressed in recent xcsoar releases as we now show the waypoint type column in a text field, so description is no longer necessary.
• for me the added value would be a job / process that creates these datasets automatically

Yes, I am thinking exactly into that direction.

• for me even more added value would be if those charts would find their way into openaip or openflightmaps and we consume from there. have you talked to @reskume from openaip?

I have not talked to @reskume yet, but will reach out to him. Thx for the hint, that you want the data to be consumed from there.

• enroute seems to also serve some VACCs from France: https://github.com/Akaflieg-Freiburg/enrouteServer/blob/main/scripts/generateVACCollections.py their dataset is even georeferenced and the approach charts are overlayed on the map

I will have a look at what they are doing.