Caution - Arizona Airspace and Borders

[Andy[_1_]]

Turnpoint Exchange includes airspace files. The airspace files listed
under Arizona Soaring Association were not provided by ASA, are not
approved by ASA, and are known to not properly depict the location of
the US Mexico border.

In the file asa_2010_sua.sua the border is defined by the Southern
boundary of the following airspace - R2301W, R2301E, Sells 1 MOA, Ruby
1 and Fuzzy MOAs. The border is undefined between W Nogales and
Evelyn. It is then defined by the Southern edge of Tombstone C MOA
and Tombstone B MOA, and is then undefined all the way to El Paso.

A review of the current sectional chart will show that each of these
airspace areas extends to, and it terminated by, the US Mexico border.

The polygon closing line to the South of these airspace areas does not
represent the location of the border.

An airspace file that does properly depict the US Mexico border is
available to ASA contest series and South West Soaring Championship
contestants from the scorer.

Andy

[John Cochrane[_2_]]

On Sep 9, 8:14*am, Andy > wrote:
> Turnpoint Exchange includes airspace files. *The airspace files listed
> under Arizona Soaring Association were not provided by ASA, are not
> approved by ASA, and are known to not properly depict the location of
> the US Mexico border.
>
> In the file asa_2010_sua.sua the border is defined by the Southern
> boundary of the following airspace - R2301W, R2301E, Sells 1 MOA, Ruby
> 1 and Fuzzy MOAs. The border is undefined between W Nogales and
> Evelyn. *It is then defined by the Southern edge of Tombstone C MOA
> and Tombstone B MOA, and is then undefined all the way to El Paso.
>
> A review of the current sectional chart will show that each of these
> airspace areas extends to, and it terminated by, the US Mexico border.
>
> The polygon closing line to the South of these airspace areas does not
> represent the location of the border.
>
> An airspace file that does properly depict the US Mexico border is
> available to ASA contest series and South West Soaring Championship
> contestants from the scorer.
>
> Andy

So why not just send John Leibacher the right file? He does an amazing
job of quickly posting files to the turnpoint exchange.
John Cochrane

[Andy[_1_]]

On Sep 9, 7:14*am, John Cochrane >
wrote:

> So why not just send John Leibacher the right file? He does an amazing
> job of quickly posting files to the turnpoint exchange.

Because I do not have the right to distribute the data except, as
scorer, to participants in the contest.

It's a long story and I don't have time now.

Andy

[Darryl Ramm]

On Sep 9, 7:22*am, Andy > wrote:
> On Sep 9, 7:14*am, John Cochrane >
> wrote:
>
> > So why not just send John Leibacher the right file? He does an amazing
> > job of quickly posting files to the turnpoint exchange.
>
> Because I do not have the right to distribute the data except, as
> scorer, to participants in the contest.
>
> It's a long story and I don't have time now.
>
> Andy

And it will become the wrong file on the next update.

Darryl

[Mike the Strike]

On Sep 9, 7:39*am, Darryl Ramm > wrote:
> On Sep 9, 7:22*am, Andy > wrote:
>
> > On Sep 9, 7:14*am, John Cochrane >
> > wrote:
>
> > > So why not just send John Leibacher the right file? He does an amazing
> > > job of quickly posting files to the turnpoint exchange.
>
> > Because I do not have the right to distribute the data except, as
> > scorer, to participants in the contest.
>
> > It's a long story and I don't have time now.
>
> > Andy
>
> And it will become the wrong file on the next update.
>
> Darryl

I was the one who discovered the problem when I nicked an airspace
boundary during a recent contest. It's a complex area near the
international border with several MOAs and restricted military
training areas. In examining the data, I find the US/Mexico border is
displaced about 1 nautical mile south of the actual border (perhaps
because the data are based on ADIZ data). SeeYou and SeeYou mobile
clearly show the border in the wrong place. Two MOAs that are
adjacent to the border are correctly shown. The whole southern border
of Arizona is shown at latitude 31 degrees 19 minutes instead of 31
degrees 20 minutes. This 1 minute difference may be the ADIZ border
definition, but I am not sure. I am sure that the indicated border is
in the wrong place (it's obvious if you look at Nogales, for example).

Andy (our scorer) finds that scoring programs do not properly display
the border at all. Clearly, the use of closed polygons to display
lines has some problems.

Our two concerns are:

1) There are errors in the database that show airspace boundaries in
the wrong place.

2) Scoring programs (Winscore, for example) handle the airspace files
differently than the navigation problems (such as SeeYou Mobile) and
may plot garbage. The result may be penalizing pilots for airspace
violations that did not occur, or vice-versa.

One major message, though, is to take the warnings on the files
seriously - do NOT use them for navigation purposes! That's what
charts are for.

Mike

[Andy[_1_]]

On Sep 9, 9:02*am, Mike the Strike > wrote:

> Andy (our scorer) finds that scoring programs do not properly display
> the border at all. *Clearly, the use of closed polygons to display
> lines has some problems.

Not quite true. The airspace file the scorer is using depicts the
border in a way that I believe to be correct.

I used Cambridge Aero Explorer Plus to display both airspace sources
and have emailed you the screen captures. I used Aero Explorer Plus
because it was created by Byars and depicts the airspace in the same
way as Winscore. The program has the ability to overlay multiple
airspace files which Winscore (to the best of my knowledge) does not.

Anyone else wanting to see the screen captures is welcome to drop me
an email.

Andy

[Eric Greenwell]

On 9/9/2010 9:02 AM, Mike the Strike wrote:
> One major message, though, is to take the warnings on the files
> seriously - do NOT use them for navigation purposes! That's what
> charts are for.
>
How do you compare an IGC file to a paper chart? Can the pilot state "I
was legal according to my paper chart" and get away with it? I thought
the standard for contests was the pilot flew according to the turnpoint
and airspace files the contest provided, so pilots, scoring program, and
the contest managers were all using the same data.

--
Eric Greenwell - Washington State, USA (netto to net to email me)

[Mike the Strike]

On Sep 9, 11:27*am, Eric Greenwell > wrote:
> On 9/9/2010 9:02 AM, Mike the Strike wrote:> One major message, though, is to take the warnings on the files
> > seriously - do NOT use them for navigation purposes! *That's what
> > charts are for.
>
> How do you compare an IGC file to a paper chart? Can the pilot state "I
> was legal according to my paper chart" and get away with it? I thought
> the standard for contests was the pilot flew according to the turnpoint
> and airspace files the contest provided, so pilots, scoring program, and
> the contest managers were all using the same data.
>
> --
> Eric Greenwell - Washington State, USA (netto to net to email me)

Eric:

That's the rub. No official airspace file has been either defined or
given to contestants.

We have the situation where the scorer is using files he developed
himself and the rest of us are using files from the Turnpoint Exchange
that are not deemed "official". Who knows what the CD is using!

We didn't think that this was a big problem until we ran into the
latest glitch, now we are going to address the issue!

Mike

[kirk.stant]

On Sep 9, 2:09*pm, Mike the Strike > wrote:
> On Sep 9, 11:27*am, Eric Greenwell > wrote:
>
> > On 9/9/2010 9:02 AM, Mike the Strike wrote:> One major message, though, is to take the warnings on the files
> > > seriously - do NOT use them for navigation purposes! *That's what
> > > charts are for.
>
> > How do you compare an IGC file to a paper chart? Can the pilot state "I
> > was legal according to my paper chart" and get away with it? I thought
> > the standard for contests was the pilot flew according to the turnpoint
> > and airspace files the contest provided, so pilots, scoring program, and
> > the contest managers were all using the same data.
>
> > --
> > Eric Greenwell - Washington State, USA (netto to net to email me)
>
> Eric:
>
> That's the rub. *No official airspace file has been either defined or
> given to contestants.
>
> We have the situation where the scorer is using files he developed
> himself and the rest of us are using files from the Turnpoint Exchange
> that are not deemed "official". *Who knows what the CD is using!
>
> We didn't think that this was a big problem until we ran into the
> latest glitch, now we are going to address the issue!
>
> Mike

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?

Oh boy, this is going to be fun!

Kirk
66

[5Z]

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

[Darryl Ramm]

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

[Mike the Strike]

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

[John Godfrey (QT)[_2_]]

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

[Darryl Ramm]

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

[Andy[_1_]]

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

[Tuno]

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