Currently, the cup files contains descriptions in German.
Shall they be translated into English?
For example, does "Flugplatz" should be converted into "Airfield"?

As stated in issue #83:

The waypoint type (Field 7) shows that its an airport: there are 3 values in existence:
2 Airfield with grass surface runway
4 Gliding airfield
5 Airfield with solid surface runway

I would like to have some clarifications about the type of airports to specify in the cup file depending on the airfield condition:

• Some airfields have both a solid and a grass surface. I suggest to use label 2 if there is a grass surface runway, and label 5 if there is only a solid surface runway. My rationale is as follow:

  • if you have the label "grass runway", you will see in any case the solid runway nearby.
  • we prefer to land on a grass runway, so indicate that there is one.

• About label 4 (Gliding airfield), what is your understanding: an "airfield dedicated to gliding only" (i.e. "vélisurface" in French) or an airfield with a gliding activity?

Please, comment.

RASP sources, should not be in the XCSoar's source code

They should be added here as their own category.

Also see XCSoar/XCSoar#768

This file is outdated (Feb 2020) and is missing key airspace.
Please can it be deleted in the absence of a maintainer?

Background:
This file has been generated from https://asselect.uk/ which allows users to create an up-to-date file and which is updated every four weeks. If the file is going to exist at all in xcsoar-data-content, it would need to have a maintainer that is prepared to update it on this frequency.

Many users in any case will prefer to use https://asselect.uk to create their own file with their choices of what to include in the file.

Currently we maintain xcsoar-data-repository and this one. This is especially bad because the xcsoar-data-repository maintains references to files contained in this repo.

Here we are maintaining Data, which is not something we should be doing from an XCSoar project perspective.

This repo is an emergency solution, as the welt2000 team has decided to stop supporting their file. The philosophy was that http://openflightmaps.org/ would be taking over all the countries that welt2000 supports.

However OFM does not maintain gliding turnpoints or outlanding sites. Neither are there metric charts available and the charts available do not display gliding specific airspace. (At least Switzerland).
In addtion all their data is zipped, so we cannot link directly from xcsoar to that site. This is something I discussed with them in spring 2018, they stated that they would change that, but sofar no change is visible.

OpenAIP also does also not feature turnpoints or outlanding sites. In addition there is the liscensing issue which prohibits commercial use.

Which brings us to the soaringweb.org turnpoint exchange. There are resources there, but they are decades old and unmaintained.

So in the end, what we currently have here is the most clean / up2date dataset.

The future strategy could possibly be:

• Remove airfields from the files (as long as they are in other sources)
• Merge external data, such as OFM or openaip data.

In the description of the cup file format (https://download.naviter.com/docs/CUP-file-format-description.pdf), it is stated that:

"name, code, country, lat, lon, elev, style, rwydir, rwylen, freq, desc" is contained at line number 1 and is ignored when reading.
This line is currently missing from (most of/all) the cup files of the repository.

Currently, the cup files contains no metadata. So, after download, one does not know where it came from, when it was created, what to expect from it, how to contribute, etc.
What are you thoughts about it?
And is it possible to add such metadata in a cup file? ... I could not find anything in the description of the file format...

Some urls just change the content, but leave the file the same.
XCSoar's update mechanism dosen't yet recognize that. We should checksum the airspace
in the nightly job and change the update= tag in the repo if the contents change.
Example: #280

The repository check workflow's Badge is shown as failing, despite the recent workflow runs succeeding.

it looks like CI is currently broken for PRs because we're trying to decrypt the SSH key unconditionally

/cc @lordfolken

XCSoar versions having and not having the problem

7.38

System information

Pixel 6 Pro
Android 13

Steps to reproduce the behavior

Try downloading an airspace file from the download section of XCSoar using the SoaringWeb.txt links.

Expected behavior

A file should download.

Actual behavior

The download hangs at 0%.

Do you have any idea what may have caused this?

Soaringweb.org has been taken down.

Do you have an idea how to solve the issue?

Two mirrors: http://serkowski.com/soaring & https://soaring.silentflight.ca

Currently all the National airspaces are located in the region directory. They should move to the country section.

/home/travis/build/XCSoar/xcsoar-data-content/waypoints/Turkey.cup /home/travis/build/XCSoar/xcsoar-data-content/waypoints/United_Kingdom.cup Traceback (most recent call last): File "/home/travis/build/XCSoar/xcsoar-data-content/scripts/check-waypoints", line 10, in <module> cupfile.read(open(str(sys.argv[1]))) File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 57, in read waypoint = self.decode_waypoint(fields) File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 93, in decode_waypoint 'frequency': self.decode_frequency(fields[9]), File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 216, in decode_frequency raise ParserError('Reading frequency failed') aerofiles.errors.ParserError: Reading frequency failed /home/travis/build/XCSoar/xcsoar-data-content/waypoints/United_States.cup /home/travis/build/XCSoar/xcsoar-data-content/waypoints/Uzbekistan.cup /home/travis/build/XCSoar/xcsoar-data-content/waypoints/xcsoar_waypoints.cup Traceback (most recent call last): File "/home/travis/build/XCSoar/xcsoar-data-content/scripts/check-waypoints", line 10, in <module> cupfile.read(open(str(sys.argv[1]))) File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 57, in read waypoint = self.decode_waypoint(fields) File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 93, in decode_waypoint 'frequency': self.decode_frequency(fields[9]), File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/aerofiles/seeyou/reader.py", line 216, in decode_frequency raise ParserError('Reading frequency failed') aerofiles.errors.ParserError: Reading frequency failed /home/travis/build/XCSoar/xcsoar-data-content/waypoints/Zambia.cup /home/travis/build/XCSoar/xcsoar-data-content/waypoints/Zimbabwe.cup The command "for each in $TRAVIS_BUILD_DIR/waypoints/*.cup ; do python $TRAVIS_BUILD_DIR/scripts/check-waypoints "${each}" ; done" exited with 0.

Hi everyone, i can't find any map for using in Turkey, it should be good if there is no map the app use google's map ?

https://www.openaip.net/data/reporting-points

1. Download them from the google bucket by looping through countries
2. replace the type in the waypoint with the proper cup type type 19
3. append them to the cup files for each country
4. upload these

shedule the process once a week on github actions

More information here: https://www.openaip.net/develop

@dspreitz

Indepdently of your current merge request:

What if we could generate a list of the mountain peaks with OSM?:

Relevant tags:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeak
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dsaddle

I'm trying to prevent it to be necessary to care for this data by hand.

The idea is to provide a date when the file was last updated, not the current timestamp.

Eventually xcsoar will use this information to compare to local file date and display to the end user that updates are necessary.

See: #169

Download of waypoints is broken for all the countries having a space in the name.

commit 9f2eba7 broke the waypoint download links for a bunch of countries.

https://www.xcsoar.org/download/waypoints/

Try for instance New Zealand

#69 (wow I got my favourite number PR) should fix the issue, as a quick fix. A proper fix is suggested in the PR.

About Github I wanted to edit a line. Due to the inconsistent line-end format, Github has changed all lines in the final format with CR-LF.

Not very clear diff result for a pull request

While cleaning the file France.cup, I came to wonder if we want in the cup files all the existing airfields.

My rationale is that we want only waypoints with the label airfields (i.e. 2, 4 or 5; see below) if they are a suitable for landing a sailplane or for orientation purpose (like major airports).

Here is a proposal for the kind of airfields we do NOT want in the cup files:

• altisurfaces. But could be labelled as waypoint (label 1) or outlanding (label 3) depending on the condition (some are on glaciers...).
• very small airfields, essentially too narrow and too short for sailplanes (like the ones dedicated to ultralight trikes). Which criterias (length and width) to sort them out, and to label it as an airfield (2), an outlanding (3), a waypoint (1) or to discard it?
• helistation. To be set as a waypoint (label 1)?
• any other type of airfield to discard?
  Thank you for your input.

RASP Source for Poland needs a url in
https://github.com/XCSoar/xcsoar-data-content/tree/master/data/remote/rasp/region

When loading the Germany.cup file via xcsoar 6.8.10Android, a html file of the github page with the name Germany.cup is loaded.
Of course this html file can not be interpreted by XCSOAR and the waypoints corrupted. May be the problem is more on XCSOAR site.
Other waypoint files, like Poland.cup are downloaded correctly.

@csindle hmm the waypoints.js only reports 0.0 for the waypoints:
http://download.xcsoar.org/waypoints/waypoints.js

Originally posted by @lordfolken in #175 (comment)

I few days ago i updated the radio frequencies in "Germany.cup", than after updating the waypoints on my phone via XCSoar-Filemanager i wondered why i still had the old frequencies.

It seems that the content on "http://download.xcsoar.org/" was last time updated on "03-Jul-2018". Is there a procedure to sync this server with this repo? It would be really nice to do this....

1. Currently, there is no method to test deploying one's PRs. Only after merging into master does the PR's deploy actually get tested. This enhancement simplifies deploying all PRs to the developers own testing server for verification/debugging, before creating a PR.

2. Currently, developers working on their own fork/repo on their own feature branch, never run the build checks, because the GH workflow only runs on master branch. This enhancement runs the ./scripts/build.bash on every commit to any of the developer's branches (and optionally deploys if she has set up the relevant secrets in a GH Environment (e.g. DEPLOY_KEY, DEPLOY_HOST, etc.).

To do this:

1. Set up a development GH Environment for this repository, and with the relevant secrets (maybe copy all and only update DEPLOY_PATH to a new value?)
2. Move the existing secrets to a production GH Environment.
3. Merge: #184

https://github.com/Turbo87/united-flarmnet
This generates a united flarmnet file from all the sources:

• ogn
• flarmnet
• weglide

We should automatically update this one and deploy it via repository.

TravisCI is finally dead.
We need to copy over from the xcsoar-data-repository the .github action yaml and configure deployment correctly.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

the ci should be extended so that the mapgen can use the current data.

Sort the repository file according to:
GLB (global)
REG (regional)
ISO-Code (Country)

1. Add current MW Waypoints to include ALL airfields, with better descriptions
2. Create an Airspace file for MW
3. Create a terrain file for MW

I have access to all this information, but need to better understand the required format to enable me to create a pull request - will do some reading to aquire this information.

OpenFlightMaps has carefully managed resources for airspaces and waypoints.

OFM supplies them as compressed archives, not interpretable for XCSoar.

Idea:

• generate a workflow that downloads the resources
• unarchives them
• upload them to download.xcsoar.org

@ventus99

Proposal for consolidating XCSoar data content.

This is presented as:

1. A starting point for discussing the ending point: what would be the ideal layout look like?
2. A concrete example of the potentially useful concepts listed below in Notes.

Semantic Directory Layout:

Inside data:

content/
.
├── airspace
│   └── region
│       ├── Czech Wave Airspace.txt
│       ├── HWW17_Airspace_ohne.txt
│       └── Polish Wave Airspace.txt
└── waypoint
    ├── country
    │   ├── AF.cup
    │   ├── AL.cup
    │   ├── ...
    │   ├── ZM.cup
    │   └── ZW.cup
    └── region
        ├── 2019_Hotzenwald_V11.cup
        ├── CAN_PG_A-M.cup
        ├── ...
        ├── WP2020_Bronkow.cup
        └── ZA_Cape_20211007.cup


remote/
.
├── airspace
│   ├── country
│   │   ├── Australia_Airspace.txt.json
│   │   ├── Austria_Airspace.txt.json
│   │   ├── ...
│   │   ├── Ukraine_Airspace.txt.json
│   │   └── USA_Airspace.txt.json
│   └── region
│       └── Thermal_Spaces_EU.txt.json
├── flarmnet
│   └── globe
│       ├── data.fln.json
│       └── ogn-device-database.fln.json
├── waypoint
│   ├── globe
│   │   └── OpenAIP-Hotspots.cup.json
│   └── region
│       ├── TBG_DoubleSeater_tomorrow.cup.json
│       ├── TBG_SelfLaunch_tomorrow.cup.json
│       └── TBG_SingleSeater_tomorrow.cup.json
└── waypoint-detail
    └── region
        ├── TBG_AirportDetails_DoubleSeater_tomorrow.txt.json
        ├── TBG_AirportDetails_SelfLaunch_tomorrow.txt.json
        └── TBG_AirportDetails_SingleSeater_tomorrow.txt.json

source/
.
├── map
│   ├── country
│       └── ZA.xcm.json
│   └── region
│       ├── ALPS.xcm.json
│       ├── ...
│       └── US_WA_STATE.xcm.json
└── topology

Notes:

Zeroth (top) Level:

1. A directory called data.

First Level:

1. Specifies what type of data is contained herein: Actual content (content), URLs to content (remote), or configuration parameters on how to generate content (source).

2. Specifies what type of checks might need to be performed on the contents: E.g. remote URLs need to be validated (HTTP GET or HEAD) upon PRs and regularly scheduled.

3. The directory layout on http://download.xcsoar.org/ is identical to inside content. Just rsync the whole directory across.

Second Level:

1. The second level directory (map, waypoint, etc.) specifies the file type. E.g. type=map in repository

Third Level:

1. */country/*: naming convention is ISO3166.alpha2 stem (filename sans extension), and is the repository area field.

2. region is the old special.

3. */region/*: The repository area field will be best-effort extracted from the filename prefix (underscore separated). E.g. ca_quebec.*

4. All nouns: globe, region, country, etc.

Fourth (last) Level (files):

1. One file per item. E.g. map/country would contain ar.json, de.json, za.json, etc.

2. The repository's update field is generated from the git commit date.

3. Easier to track & merge file-based edits (as opposed to a massive JSON file).

Misc:

1. If generated files are still required on http://download.xcsoar.org/ (not in any of the git repos), they should be separate from this directory layout.

2. This implies merging and removing [at least] the following git repositories:

   • https://github.com/XCSoar/xcsoar-data-repository
   • https://github.com/XCSoar/xcsoar-data-maps

"Talk is cheap. Show me the code."

https://github.com/csindle/xcsoar-data-content/tree/test/semantic_layout

Examples of file contents:

source

$ cat data/source/map/region/ALPS.json 
{
  "bounding_box": "[4.5, 43.4, 16.5, 49.0]"
}

remote

$ cat data/remote/waypoint-detail/TBG_AirportDetails_DoubleSeater_tomorrow.json 
{
  "uri": "http://travelbyglider.eu/TBG_AirportDetails_DoubleSeater_tomorrow.txt"
}

$ cat data/remote/flarmnet/ogn-device-database.json 
{
  "uri": "http://ddb.glidernet.org/download/download-fln.php"
}

All required manifest files can be automatically generated from this structure & data.

Manifest files:

1. https://download.xcsoar.org/repository (required by XCSoar)
2. https://download.xcsoar.org/waypoints/waypoints.js **
3. https://download.xcsoar.org/waypoints/waypoints_compact.js **
4. https://download.xcsoar.org/maps/maps.config.js ** (required by mapgen?)
5. https://download.xcsoar.org/waypoints/xcsoar_waypoints.cup (required by mapgen?)
6. https://download.xcsoar.org/waypoints-special/waypoints-special.json, https://download.xcsoar.org/waypoints/waypoints-by-country.json, etc.

** Required by website. Could they be generated as needed?

Hi,
downloading the Germany Airspace Data does not work.

We should configure TravisCI to run some code that validates the files. Using https://github.com/Turbo87/aerofiles/ might be an option.