Caution - Arizona Airspace and Borders

On Sep 9, 5:55*pm, 5Z wrote:
On Sep 9, 1:54*pm, "kirk.stant" wrote:

And just to throw some more fuel on this fire, as pilots we are
responsible for navigating with reference to approved data, which
means Sectional charts or VFR GPSs with up to date navigation data
(say a Garmin with current cycle data loaded). *So what happens if the
scoring program, using non-official airspace data, shows a violation,
and the pilot proves, somehow, that he used his up to date VFR Garmin
and/or sectional and did not bust the airspace? Who is right? *The
pilot is right as far as the FAA is concerned, but wrong in Winscores
mind?

For scoring there needs to be a single source of digital information,
whether it matches reality or not, that is what the pilots and scorer
should use. *This file IMHO, should be available a "reasonable" time
before the first contest day.

As for FAA, the pilot is responsible for that issue using "APPROVED"
information. *So if the contest says the restricted airspace is bigger
than reality, then that is what it is as far as the contest is
concerned. *If the airspace file is in error the other way, then it is
up to the pilot to use other, official, means to stay legal. *Again,
IMHO, airspace boundaries for scoring are just that, SCORING
boundaries, not "real" airspace boundaries.

Yes, that means that a pilot could violate FAA airspace and get a
valid score, but if that happens, I see no reason against someone
submitting a protest AGAINST THE PILOT or pilots involved, but not
against the competition. *These boundaries are not to be used for
navigation, just for scoring.

-Tom

So how is the JustSoar airspace data in that area in comparison to the
data on Soaring Turnpoint Exchange?

Darryl

On Sep 9, 8:06*pm, Darryl Ramm wrote:
On Sep 9, 5:55*pm, 5Z wrote:



On Sep 9, 1:54*pm, "kirk.stant" wrote:

And just to throw some more fuel on this fire, as pilots we are
responsible for navigating with reference to approved data, which
means Sectional charts or VFR GPSs with up to date navigation data
(say a Garmin with current cycle data loaded). *So what happens if the
scoring program, using non-official airspace data, shows a violation,
and the pilot proves, somehow, that he used his up to date VFR Garmin
and/or sectional and did not bust the airspace? Who is right? *The
pilot is right as far as the FAA is concerned, but wrong in Winscores
mind?

For scoring there needs to be a single source of digital information,
whether it matches reality or not, that is what the pilots and scorer
should use. *This file IMHO, should be available a "reasonable" time
before the first contest day.

As for FAA, the pilot is responsible for that issue using "APPROVED"
information. *So if the contest says the restricted airspace is bigger
than reality, then that is what it is as far as the contest is
concerned. *If the airspace file is in error the other way, then it is
up to the pilot to use other, official, means to stay legal. *Again,
IMHO, airspace boundaries for scoring are just that, SCORING
boundaries, not "real" airspace boundaries.

Yes, that means that a pilot could violate FAA airspace and get a
valid score, but if that happens, I see no reason against someone
submitting a protest AGAINST THE PILOT or pilots involved, but not
against the competition. *These boundaries are not to be used for
navigation, just for scoring.

-Tom

So how is the JustSoar airspace data in that area in comparison to the
data on Soaring Turnpoint Exchange?

Darryl

The ASA_2010.sua data on the Turnpoint Exchange utilizes border
locations from ADIZ data that lie about 1 mile outside of the actual
border - mostly to the south.

I spent some time today checking the actual border location by finding
many of the existing border monuments on Google Earth and find Tuno's
data on the JustSoar site to be very accurate.

Mike

On Sep 10, 2:16*am, Mike the Strike wrote:
On Sep 9, 8:06*pm, Darryl Ramm wrote:



On Sep 9, 5:55*pm, 5Z wrote:

On Sep 9, 1:54*pm, "kirk.stant" wrote:

And just to throw some more fuel on this fire, as pilots we are
responsible for navigating with reference to approved data, which
means Sectional charts or VFR GPSs with up to date navigation data
(say a Garmin with current cycle data loaded). *So what happens if the
scoring program, using non-official airspace data, shows a violation,
and the pilot proves, somehow, that he used his up to date VFR Garmin
and/or sectional and did not bust the airspace? Who is right? *The
pilot is right as far as the FAA is concerned, but wrong in Winscores
mind?

For scoring there needs to be a single source of digital information,
whether it matches reality or not, that is what the pilots and scorer
should use. *This file IMHO, should be available a "reasonable" time
before the first contest day.

As for FAA, the pilot is responsible for that issue using "APPROVED"
information. *So if the contest says the restricted airspace is bigger
than reality, then that is what it is as far as the contest is
concerned. *If the airspace file is in error the other way, then it is
up to the pilot to use other, official, means to stay legal. *Again,
IMHO, airspace boundaries for scoring are just that, SCORING
boundaries, not "real" airspace boundaries.

Yes, that means that a pilot could violate FAA airspace and get a
valid score, but if that happens, I see no reason against someone
submitting a protest AGAINST THE PILOT or pilots involved, but not
against the competition. *These boundaries are not to be used for
navigation, just for scoring.

-Tom

So how is the JustSoar airspace data in that area in comparison to the
data on Soaring Turnpoint Exchange?

Darryl

The ASA_2010.sua data on the Turnpoint Exchange utilizes border
locations from ADIZ data that lie about 1 mile outside of the actual
border - mostly to the south.

I spent some time today checking the actual border location by finding
many of the existing border monuments on Google Earth and find Tuno's
data on the JustSoar site to be very accurate.

Mike

For a sanctioned contest, the scorer's airspace file and turnpoint
file are required to be published 30 days prior to the contest and to
be readily available at all times from the scorer in computerized form
(Rule 5.6). If contestants choose to use other airspace files, their
mileage (literally) may vary.

That said, I think we all want the same things:
- accurate airspace files
- automatically generated, updated and posted on the turnpoint
exchange

Since I've been using my term on the Rules Committee to focus on
things that explain (diagrams in the rules appendix) and simplify
contest mechanics (improved accuracy of handicap files for winscore,
relaxation of logger requirements, MSL start and finish heights) I'll
also be working on how we can improve this. We recently began
publishing contest specific airspace files on the WWTX that include
only forbidden airspace (R, P, B, C and the volume above it) this is
just a continuation of that effort.

Just to be clear, I can't take all (or even most) of the credit for
implementing these changes, it's just what I focus on.

John Godfrey (QT)
Rules Committee

On Sep 10, 5:05*am, "John Godfrey (QT)"
wrote:
On Sep 10, 2:16*am, Mike the Strike wrote:





On Sep 9, 8:06*pm, Darryl Ramm wrote:

On Sep 9, 5:55*pm, 5Z wrote:

On Sep 9, 1:54*pm, "kirk.stant" wrote:

And just to throw some more fuel on this fire, as pilots we are
responsible for navigating with reference to approved data, which
means Sectional charts or VFR GPSs with up to date navigation data
(say a Garmin with current cycle data loaded). *So what happens if the
scoring program, using non-official airspace data, shows a violation,
and the pilot proves, somehow, that he used his up to date VFR Garmin
and/or sectional and did not bust the airspace? Who is right? *The
pilot is right as far as the FAA is concerned, but wrong in Winscores
mind?

For scoring there needs to be a single source of digital information,
whether it matches reality or not, that is what the pilots and scorer
should use. *This file IMHO, should be available a "reasonable" time
before the first contest day.

As for FAA, the pilot is responsible for that issue using "APPROVED"
information. *So if the contest says the restricted airspace is bigger
than reality, then that is what it is as far as the contest is
concerned. *If the airspace file is in error the other way, then it is
up to the pilot to use other, official, means to stay legal. *Again,
IMHO, airspace boundaries for scoring are just that, SCORING
boundaries, not "real" airspace boundaries.

Yes, that means that a pilot could violate FAA airspace and get a
valid score, but if that happens, I see no reason against someone
submitting a protest AGAINST THE PILOT or pilots involved, but not
against the competition. *These boundaries are not to be used for
navigation, just for scoring.

-Tom

So how is the JustSoar airspace data in that area in comparison to the
data on Soaring Turnpoint Exchange?

Darryl

The ASA_2010.sua data on the Turnpoint Exchange utilizes border
locations from ADIZ data that lie about 1 mile outside of the actual
border - mostly to the south.

I spent some time today checking the actual border location by finding
many of the existing border monuments on Google Earth and find Tuno's
data on the JustSoar site to be very accurate.

Mike

For a sanctioned contest, the scorer's airspace file and turnpoint
file are required to be published 30 days prior to the contest and to
be readily available at all times from the scorer in computerized form
(Rule 5.6). *If contestants choose to use other airspace files, their
mileage (literally) may vary.

That said, I think we all want the same things:
* - accurate airspace files
* - automatically generated, updated and posted on the turnpoint
exchange

Since I've been using my term on the Rules Committee to focus on
things that explain (diagrams in the rules appendix) and simplify
contest mechanics (improved accuracy of handicap files for winscore,
relaxation of logger requirements, MSL start and finish heights) I'll
also be working on how we can improve this. *We recently began
publishing contest specific airspace files on the WWTX *that include
only forbidden airspace (R, P, B, C and the volume above it) this is
just a continuation of that effort.

Just to be clear, I can't take all (or even most) of the credit for
implementing these changes, it's just what I focus on.

John Godfrey (QT)
Rules Committee

Out of interest did that contest specific airspace data come from the
NFD derived data that Ted uses or was it the from the usual STX
airspace data?

Seems the NFD derived data has less border issues, and is if I
understand correctly is also what badge and records are checked
against.


Darryl

On Sep 10, 6:55*am, Darryl Ramm wrote:

Out of interest did that contest specific airspace data come from the
NFD derived data that Ted uses or was it the from the usual STX
airspace data?

Seems the NFD derived data has less border issues, and is if I
understand correctly is also what badge and records are checked
against.

Darryl

I'm sure Ted has said there is NO border data in the NFD. The border
data that Ted has made public were not derived from NFD. That is why
that data is public. The NFD data is required to have a controlled
distribution. That is why I don't understand how it can be published
on TP Exchange.

Since I stated this tread as a caution. I'll add another. The review
of this mess has also shown that Garmin databases depict the border
well South of the actual location. In the area of interest I found
errors of 0.2 to 0.3 NM.

Andy

Darryl sent me an email on this topic and my reply reiterates what
Andy has already has said: the FAA's National Flight Database (NFD)
does not contain border data, and this is why the "border airspace"
files at www.justsoar.com/public/sua/ and www.justsoar.com/public/openair/
are freely downloadable (use at your own risk, blah blah blah).

(The US/Mexico and US/Canada files are at the end of the listings,
after all the US states.)

The individual state border files on my web site were created by
taking publicly available ESRI ShapeFiles from the US Census web site
and running them through a shapefile-to-SUA/OpenAir converter.

The international border files were created by snipping out the
appropriate segments of the appropriate individual state files and
stitching them together into new entities of manageable size (hence CA-
AZ/Mexico, TX/Mexico, etc). This was not a trivial process, as some
states ran clockwise, some anti-clockwise, and a few counter-anti-
clockwise (requiring temporary use of a crossover cable on the flux
capacitor). Fortunately it only had to be done one time

Some things that all users of “border airspace” files should
understand:
* User applications (SeeYou, SYM, xcsoar, etc) all insist on closing
“border airspace” files, even SUA with TYPE=BOUNDARY, by connecting
the first and last points in the sequence. This requires adding
fictional points on the “closed” side of the boundary so that no point
on the “open” side of the border lies in the closed polygon. This is
why plots of “border airspace” files look … funny.
* They are approximations. (To wit, how long is the coastline of
England.)
* Pilots who fly near borders must take the time to either append the
appropriate “border airspace” files to the one they’re using, or tell
their software which one(s) to use.

I don't know where the files on the TPE came from, but if John wants
to post mine there or link to them, he is more than welcome to do so.

go fly

tuno