Hi everyone,
The retrieval of the CSSI space weather doesn’t work anymore, the ftp:// URL is apparently no longer active (I get a 530 error when running the curl manually). The protocol in the URL now needs to be https://.
Cheers,
Clément
I will fix this.
It is weird they did not even switch to https…
Fixed, thanks for the report!
By the way, I used http, not https because curl returned the following error with https:
curl: (60) server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
I have just filled in a contact form on the AGI website with the following message:
This is a message for your IT service. There is an issue with the TLS certificates chain provided by your server https://ftp.agi.com
$ curl https://ftp.agi.com/pub/DynamicEarthData/SpaceWeather-All-v1.2.txt
curl: (60) server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
More details here: curl - SSL CA Certificates
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the webpage mentioned above.It seems that the second certificate in the chain is not that of the operational CA that signed the server’s TLS certificate:
- Issuer of the first certificat : DigiCert Global G2 TLS RSA SHA256 2020 CA1
- Subject du second certificat : DigiCert TLS RSA SHA256 2020 CA1
A test with the Firefox browser is successful, as this browser embeds its own CA certificate set, which contains the missing CA certificate. This is not the case with the CA certificate package supplied with a GNU/Linux system, which is used by most low-level tools (curl, wget, openssl…).
Could you fix this issue?
Thanks in advance
2 Likes
Hi,
I’m reviving this old topic because it seems that the http address now returns a 301 response with a redirect to the https address.
at 11:00:23 ❯ curl -s -v http://ftp.agi.com/pub/DynamicEarthData/SpaceWeather-All-v1.2.txt
* Host ftp.agi.com:80 was resolved.
* IPv6: (none)
* IPv4: 65.89.176.38
* Trying 65.89.176.38:80...
* Connected to ftp.agi.com (65.89.176.38) port 80
> GET /pub/DynamicEarthData/SpaceWeather-All-v1.2.txt HTTP/1.1
> Host: ftp.agi.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Wed, 22 Oct 2025 09:00:32 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Location: https://ftp.agi.com/pub/DynamicEarthData/SpaceWeather-All-v1.2.txt
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ftp.agi.com left intact
The script uses curl without the -L option so the redirect is not followed and the output file only contains the 301 response.
Thanks, it is fixed now (it seems they finally switched to https, which is good).
I have also added the -L switch to curl.
Thanks for the quick fix !
Hello !
Again, reviving this topic as the ftp link seems to be down since Wednesday October 29th.
I get a “502 bad gateway”.
Any news from AGI in that regard ?
Thanks !
Yes I have the same error. I also tried the Celestrak file which is mentioned in CssiSpaceWeatherData (OREKIT 13.1.2 API) , but it seems that it cannot be parsed by Orekit:
- the
DAILY_PREDICTEDsection has an emptyQcolumn - the
MONTHLY_PREDICTEDsection has multiple empty columns
I was able to use the Celestrak data by only copying the recent OBSERVED lines, and the DAILY_PREDICTED section after adding the Q column manually.
thanks for the workaround !
I can confirm that the empty Q column in the DAILY_PREDICTED section for the Celestrak file makes the Orekit CssiSpaceWeatherDataLoader fail.
Comspoc’s Spacebook website also provides a Space Weather data file in the Celestrak format:
https://spacebook.com/api/spaceweather/full
However, also this file cannot be parsed using Orekit because it contains an additional white space after the Q column and an additional white space at the end of the line. The CssiSpaceWeatherDataLoader however expects lines of width 130 (not 132).
It seems to me that both Celestrak and Spacebook provide Space Weather files that do not follow their own file specifications to the letter.
I have sent an email to Celestrak (Dr. Kelso) about the Space Weather data file provided on Celestrak. I will let you know if I get an answer.
1 Like
I have received an answer from the very kind Dr. Kelso:
The flux qualifier (Q) indicates the type of measurement used. There is no measurement for a predicted value. You can see the values allowed in the legacy documentation at:
https://celestrak.org/SpaceData/SpaceWx-format.php
A value of 0 means this is the original measured value. For predictions, where no measurement is available, the documentation (Item 4 in the Process section) clearly states “Missing values are left blank.”
In other words, the space weather data files in Celestrak format can have missing values, in particular when it comes to the predicted sections in the space weather data file. Therefore, the CssiSpaceWeatherDataLoader should be robust to missing values.
The (latest) files provided by AGI and Spacebook do not have missing values, but as stated above this filling of all fields is not required by the format.
OK, can you open an issue on the forge?
Created the issue in Gitlab: