If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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 |
#12
|
|||
|
|||
Caution - Arizona Airspace and Borders
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 |
#13
|
|||
|
|||
Caution - Arizona Airspace and Borders
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 |
#14
|
|||
|
|||
Caution - Arizona Airspace and Borders
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 |
#15
|
|||
|
|||
Caution - Arizona Airspace and Borders
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 |
#16
|
|||
|
|||
Caution - Arizona Airspace and Borders
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 |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Wichita Airspace Question and overlapping airspace | Owen[_4_] | Piloting | 1 | February 14th 07 09:35 PM |
Caution Wake Turbulence | [email protected] | Instrument Flight Rules | 7 | November 29th 06 04:14 AM |
FLAPS-Caution | Steve Leonard | Soaring | 0 | August 27th 05 04:10 AM |
Phoenix Arizona airspace | Andy | Soaring | 0 | August 3rd 05 12:24 AM |
caution - wake turbulence | John Harlow | Piloting | 1 | June 4th 04 04:40 PM |