Quality of SUA file for WGC Uvalde

Over the weekend I had a look at the quality of the airspace file for the WGC in Uvalde. And I must say, my airspace file check program was not impressed. The open air file is not self-consistent. The beginning and ending radii of arcs are quite often not matching, even when the matching criterion is defined very coarse like 100 meter.

Today I stated to compare the file open-air file with the official publication (FAA Order 740.8U). I just inspected the first airspace (Corpus Christi). The first radius of this airspace is 25nm in FAA Order 740.8U while the open-air file claims 25.205nm. For the second radius FAA Order 740.8U states 20nm while the open-air file defines this radius as either 19.940nm or 19..919nm, depending whether the beginning or ending of the arc is used to define the radius of the arc.

This inconsistencies might quite likely result in an disqualification of a pilot.

Dear hlt,

I produce the freely redistributable airspace files for the US upon which at least some of the Uvalde files are based, and I can provide a little insight. I didn't produce any of the contest files directly, but my work in transcoding the FAA data for the entire US has been used in part by the contest organizers.

The issues you are seeing are artifacts of the conversion of the special use airspace data from the text-based raster descriptions published by the FAA in the unlicensed NASR data to the Tim Newport-Peace and OpenAir formats. For Uvalde, only Special Use airspace such as Alerts and MOAs (as opposed to ATC-controlled airspace such as Class B, C, and D) are affected in this way.

The problem arises because the unlicensed digital versions of the FAA data for Alerts and MOAs do not currently contain arc descriptions at all -- just a raster list of some points along the edges. I have written software that does a regression analysis of those points and does a best fit arc through them. This might be a little hard to understand, but (for an arc that isn't a full circle) even though the arc radius and center point may not be perfectly computed, the arc itself can very closely approximate the published position, with only very slight differences in curvature. The parameters of my fitting algorithm are a tolerance of .05 nm, or about 100m. This issue is described in the header of the file. The arc consistency issues you mention originate directly in the FAA's own digital versions of the data. The endpoints of the arcs are not part of the fit.

Normally, MOAs and Alerts aren't used in contest scoring, but I understand in Uvalde they will be. I'm not on the contest committee, but I understand that the organizers have established scoring versions of the airspace files that set the boundaries of the off-limits airspace slightly outside of the boundary as set forth in the FAA data. As long as pilots all use the same description of the airspace as published by the contest committee, things will be OK.

This whole issue of arc fitting will be behind us as early as October, when the FAA will use a new format AIXM5, for publishing unlicensed versions of the airspace data. Of course the contest will be over by then. Other vector-based versions of the FAA data do exist, but they bear license restrictions that prevent their free redistribution.

Lynn Alley
"2KA"

Dear Lynn!

Thank you for explaining why it is this way. But the arc regression is not the only problem, but most likely the most important one.

I think that the airspace file for teh WGC dserved a little bit more work. I think that radii should be manually entered from the official FAA orders, which are available for download, for the airspaces which are used for the WGC.

Two technical question. Do you do the arc regression on a sphere or on an ellipsoid? The inconsistencies of the open-air arcs would be easier understood when you do it on a sphere.


HLT
Hans L. Trautenberg

I think that the use of only polygons in airspace files to be used by glider pilots would reduce the chances of wrong interpretation significantly. An arc on a sphere and on a ellipsoid expressed in geodetic coordinates is something quite different. The geodesic on a sphere and on a ellipsoid expressed in geodetic coordinates is for sufficiently short geodesics (20 km) for all practical purposes the same.

I do use a sphere. I have code that does it using an ellipsoid, but I found that the match to other FAA sources (such as visual charts and licensed digital data) is not as good. I think the FAA may use a spherical model when producing their own digital representations.

No digital source exists that perfectly matches the FAA orders. For example, the licensed data (such as is available from for-charge services) for MOAs often shows significant differences from the FAA orders. So you're correct that the only way to get a match would be to code it by hand. The orders themselves are not perfectly internally consistent either. One near me specifies radii in both nautical and statue miles, using a conversion factor of 1.1.

L.

Thanks for the explanation.

In the data you use to derive the radii and vertices of the arcs, are the arcs approximated by a polygon with significantly more than 2 vertices? If so it might be much better to keep the original polygon approximating the arc, as the the result of air space checks would be nearly independent from the used Earth model, provided that the length of geodesic between the vertices of the polygon is not significantly larger than 12nm.

There are only 45 DB records in the Uvalde airspace file. I think that before the WGC starts it is worthwhile to enter these radii and vertices by hand, so that we can be sure that all competitors and also navigation software and scoring programs will interpret the open-air-format information consistently.

I know we have the 30 day rule, but the current state of inconsistency is not something one would expect for a file used at a WGC.

It appears to me that the scoring files (the ones marked for weekend and weekday use) have already been hand-edited. As I understand it, the file with Corpus Christi in it is informational, not for scoring.

But again, just to be clear... please understand that I'm not affiliated with the contest in any way. The organizers just used my work to build the airspace files. It might be best to send feedback directly to them, rather than in this forum.

Lynn

On 7/19/12 3:35 PM, hlt wrote:
This inconsistencies might quite likely result in an disqualification of a pilot.

How would this happen if the pilot and scorer both use the same data?

Am Samstag, 21. Juli 2012 06:06:42 UTC+2 schrieb Tom S:
On 7/19/12 3:35 PM, hlt wrote:
> This inconsistencies might quite likely result in an disqualification of a pilot.

How would this happen if the pilot and scorer both use the same data?

Because the data is written in a way that it can be interpreted in different ways.

Have a look at an example from the Uvalde data of last weekend, data was now update respectively is no longer available:

*## CRYSTAL NORTH ##
AN CRYSTAL NORTH 0800-0930 & 1300-1430 TUE-FRI O/T BY NTM
AC CTA/CTR
AL 6000 ALT
AH FL 180
DP 28:38:38 N 099:26:26 W
V D=-
V X=27:28:43 N 099:25:04 W
DB 28:38:38 N 099:26:26 W, 28:20:23 N 100:18:24 W

In the case the radius of the arc described by the DB record is 69.739 nm at the beginning and 69.910. In the open air format it is not defined which radius is to be used under these circumstances.

As as side remark:
The same arc is described in a different data format on the same
web page as

POINT=N283838 W0992626
ANTI-CLOCKWISE RADIUS=70.00 CENTRE=N272843 W0992504 TO=N282023 W1001824

So the arc definition in open air is not only not unique, it differs in
addition also from the definition in the TNP format.


The airspace open-air files now at the website use no longer the DB record. The DA record is used in the files currently available for download. With the DA record the Earth model has an even larger impact on the actual position of the arc than with the DB record.

Am Samstag, 21. Juli 2012 10:17:02 UTC+2 schrieb hlt:
In the case the radius of the arc described by the DB record is 69.739 nm at
the beginning and 69.910.

The words "at the end" are missing at the end of sentence above.