Occasionally, "ALT" is used instead of "ft MSL". Parser should handle this alternative altitude definition also.

Currently parser will output valid GeoJSON geometries only. If error occurs, the parser outputs this error. With the current behavior, it's not possible to visualize invalid geometries. To be able to also visualize invalid geometries, the parser may output LineString instead of Polygon geometries. With LinString geometry, it's possible to show e.g. self-intersections.

          Hi

I'm getting another similar error:
Error found at line 14167: Token 'DC' on line 14166 does not allow subsequent token 'DY' on line 14167

Originally posted by @llauner in #31 (comment)

A failed validation of an openair file exists with an exit code of 0 when it should exit with 1
This would help integrate an automated validation in a github workflow for instance

Hi
Have you changed anything in the file validation ?
I'm getting this error which I think wasn't there in the past:
Error found at line 156: Token 'AL' on line 155 does not allow subsequent token 'AF' on line 156

Where should AF be located then ?
It's going to be tough if I have to relocate the AF line somewhere else...
Thanks

Hi
Might not be the best place to discuss this, but I didn't know how to reach you:

In the openaip format,:

1. The AY tag does not seem to support the value: AERIAL_SPORTING_RECREATIONAL
   In reality it seems to be OK

2. AY GLIDING_SECTOR should be AY W
   If not, SeeYou, doesn't recognize it.

With the incorrect AY value, SeeYou displays the area as "unclassified" which leads to lots of grey areas on the map

Do you have any link to a more up to date version of the format ?
Could you make sure that your parser / converter to the extended format are in line with what is currently supported by SeeYou, ...

Support the new extended OpenAIR format that features additional "non-standard" tokens:

• AI: A unique identifier for each airspace. Ideally, this identifier will not change for the same airspace over different versions of a file.
• AF: A frequency that can be used to contact a radio station for information on the specific airspace. Format "123.456".
• AG: Call-sign of the station if frequency is given.
• AY: Specifies the type of the airspace, e.g. "RMZ", "CTR". The AC tag MUST exclusively define only ICAO class of the airspace.

This was fixed in 1.10 but it's there again in 1.16
#31
Thanks

Noted in #6 .

Output GeoJSON polygons must follow the right-hand rule. See https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.6 for spec.

Current behavior of the parser is to consider inline comments as invalid syntax. Since this seems to be common practice, the parser should allow this type of comment.

I am willing to improve your parser and before doing this, I would like to get your feedback on the idea and if you would be willing to accept the changes:

PROBLEM:

This is an excerpt from german airspace which is very typical

DP 48:38:54 N 009:37:28 E
V D=-
V X=48:41:19 N 009:12:39 E
DB 48:38:54 N 009:37:25 E, 48:53:47 N 009:29:13 E
DP 48:49:10 N 008:47:51 E

the problem is the first coordinates of "DB". It is very close (18m) to the previous DP and I think this is a human mistake. The author always tried to have the same coordinates for:

• The first coordinates of DB and the previous DP
• the second coordinates of DB and the next DP

However, sometimes they differ by a few meters.

IMPACT:

You can see the resulting problem, if you zoom into the airspace as presented by http://airspace.xcontest.org or burnair.cloud or whatever. It is kind of "zick zack". I also work for a paragliding computer called "strato" (https://github.com/fhorinek/BB) implementing airspace calculation. They also suffer from this problem, as too many intersections are found, because of wrong coordinates.

PROPOSED SOLUTION

Either check explicitely for the above two cases in

What do you think about rhis?

The workflow github-create-release.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

Ceiling definitions like below must be rejected.

AC W
AN AREA G5 (NARVA)
AL SFC
AL FL80
DP 59:23:32 N 028:07:58 E
DP 59:19:24 N 027:47:31 E
DP 59:00:33 N 027:33:05 E
DP 58:59:23 N 027:13:43 E
DP 59:21:20 N 027:23:56 E
DP 59:25:16 N 027:30:42 E
DP 59:27:00 N 028:03:00 E
DP 59:23:32 N 028:07:58 E

When fixing geometries, the parser creates a small buffer area around an invalid geometry which may resolve issues with self-intersections and holes. Due to the size of the buffer area, the new polygon coordinates may be very close together. When exporting a geometry to OpenAIR, the default OpenAIR coordinate format DMS is not sufficient to reflect those subtle difference in polygon point coordinates which then results in duplicate coordinates being created due to rounding issues.

With enclosed file (v3) I got the following error:
Error found at line 26402: Geometry of airspace 'ZSM 11 Mt FERRON / Bird Protection Area' starting on line 26402 is invalid. First and last Position are not equivalent.

Then I fix it, but now I'm getting this error:
The "path" argument must be of type string or an instance of Buffer or URL. Received undefined

Any idea ? I'm using of course the same command line:
node cli.js -f /mnt/c/Users/SESA644858/Downloads/france-2023-fixed-v4.txt --validate --debug

france-2023-fixed-v4.txt
france-2023-fixed-v3.txt

Hi, really awesome lib. Thank you so much for creating and maintaining this!

Would it be possible to get a flag to skip over invalid airspaces rather than breaking the entire parsing process?

Token checks should check previous and next tokens to better find syntax errors.