Proposal to define aviation database pages...

[b52hbuff]

Goals
Create a uniform template for airports
Define a template division that separates frequencies by a common function
Define a division that allows similar frequencies to share a common geotag
Define a division that allows user to focus monitoring

I became interested in defining a common template for airports when I took my HP-1 to San Jose International Airport (KSJC). I thought the tagging was unsatisfactory. I was missing a lot of traffic. And there wasn't a convenient way to focus on a specific type of traffic.

I am an aviation enthusiast without a pilots license. So I admit there are some gaps in my book knowledge. But I have had a lot of experience taking a scanner to an airport and to an airshow. When I program my scanner for these activities, I create a 'System' for each airport. Within each airport, I define the following groups:
Field
Aviation Air Ops
Approach
I have TRACONS in another system. The advantage I see to my division is that it allows me to focus my monitoring on specific tasks. If I want to hear everything, then enable everything. If I want to focus on what I can see from the field, I enable the field group. Since approach in my area is very busy, enabling approach would mean I'd miss a lot of comms when the Tower unkeyed. And finally, if I want to focus on what is coming into the airport, I can enable approach.

The other advantage is that these groupings allow for a common geotag. All of the field frequencies would have a small radius like < 2miles, since they only cover what is going on around the field. The aviation air ops might be a bit further out, say 10-15 miles, since the airlines use these as they approach. And I can go to a sectional chart to geotag the approach, but that is about 20 miles out.

As part of the division, I would like to propose that we expand the Service Tag beyond 'Aviation' to allow systems like the HP-1 to subdivide the aviation band based upon usage. I propose the following tags:
Airfield-Ops (ATIS, Tower, Ground, FSS, Clr/Del)
Airline-Ops (Airline VHF Operations)
Aviation-Approach (for Approach / TRACON)


None of this ability to classify, and divide traffic exists within the current layout. I tried looking at the database administrators handbook, and there wasn't a lot of guidance for aviation. So I went to the reference county of Harris Co TX for guidance. Using it as a base, I decided to see if I could apply some of the goals of my suggestions.

In the table/example below, ICAO Identifier is the four character airport code. Given the global nature of RR.com, I think it is important to use all four characters. Having the ICAO identifier in the subcategories makes it easy to see at a glance the facility we're scanning.

I realize there are many holes in my proposal, but I didn't want to get too far into it if there wasn't sufficient interest. Ideally, I'd like to work together with folks from requirements into implementation. The bottom line isn't to accept my proposal at face value, but to use it as a starting point to identify opportunities to enhance the existing database and make it more user friendly for all.

Comments certainly welcome.

The attachment is a word document of this email message. I wanted to layout some ideas in a table, and I couldn't figure out how to do it elegantly/easily in this note. So I put the tables in the word cocument.

 

[cipher66]

Great Ideas! Although I am the ARTCC DB admin, which is where I focus my efforts. The airports pretty much fall within the scope of the individual admins for that geographic area. What I have been doing is updating the ARTCC DB entires with the approximate locations of the RCAGs (most are spot-on), along with FAA data that says what the intended "operational" range is for that RCAG. Each RCAG has a diffrent radius for the Operational range, and in cases where there are more than 1 frequency pair, I use the largest radius for the RCAG site from the "pair" that has the largest range. The ARTCCs I have updated to be "HP-1" compliant so far are: ZKC, ZBW, ZNY, ZDC, ZME, and am currently working ZHU, with ZAU being next. I have good recent freq managemnt FAA data for all ARTCC's and it will take some time, but I'll get to them.

TRACONS should, IMHO, be applied a minimum 40 mile radius, since the FAA data I have shows that the smallest TRACON area is 35NM (roughly 40 Ground Miles). Obviously, larger TRACONs like N90, Potomac, NORCAL, and SOCAL should probably have larger radii since they are large geographic areas... But I do have data for the RTR (same as an RCAG, but for TRACONS) sites for them as well.

TOWER and Ground should probably be in the 5-10 mile range since Aircraft could be transferred from App/Dep to TWR within that range (some airports could be farther out... but probably not more than 20 ground miles.

 

[b52hbuff]

Although airports may fall within the scope of inividual admins, that doesn't stop the board from making strong recommendations (requirements?) about how to layout the data. If you go take a look at AirNav or SkyVector: Flight Planning / Aeronautical Charts, you see that even though there are a variety of airports, there is a consistent presentation to the data.

My dream would be that we wouldn't have to actively admin the airport information. Take the FAA datastream these sites do and apply the appropriate scripting to install the data into whatever final format we decide. I realize that there would always be manual input required, since scanner folks would end up finding and reporting frequency information not provided by the FAA.

My idea about the database was to first agree on the division and grouping of the data. If we can get some consensus, then we can proceed to split things up as I suggest. In parallel, we can talk about how we go about geotagging those divisions.

I am a bit handicapped in understanding the geotagging because I live in a very congested area. KSJC, KOAK, KNUQ, and KSFO all share a huge approach. And then there are the variety of smaller airports contained within the space. It's a little confusing for me. I have to go look out at the boonies at a smaller airport and start with simpler layouts.

But to think out loud, tale a look a KBAB, Beale AFB in Yuba north of Sacramento. If I look at the sectional at SkyVector, I see two concentric purple circles. I thought that the inner circle defines the geotag for the tower?

As I said, the ultimate goal is automation. I realize that is probably not going to happen, but for a consistent layout, I see these steps:
1. Agree that we want to enhance the aviation section.
2. Agree on a common division of frequency data
3. (Optional) Agree on expanding the Aviation tags (not so important if we have function division within a subcategory)
4. Agree on a common algorithm for defining radius of geotag. The point should be pretty simple. It should come from the airport charts.

Once we figure it all out, I propose that we enhance the DB Admin guide so we're all on the same page. I'll volunteer to help write up all of this up...

 

[DaveNF2G]

According to the usual logic for operational radii, the tower radius should be the distance over which it can be received on the ground. This would not necessarily be the same as the assigned operational radii on aero charts, because the target audience there is airborne.

I can hear aircraft talking to the Port Authority at KEWR from the Albany, NY, area, but I can't hear the ground station. The geotag for the Port Authority transmitter should not, IMO, extend this far.

I have heard aircraft being handed off to the tower as far away as 10 miles, but this only happens when there is very little traffic in the vicinity.

 

[b52hbuff]

According to the usual logic for operational radii, the tower radius should be the distance over which it can be received on the ground. This would not necessarily be the same as the assigned operational radii on aero charts, because the target audience there is airborne.

I have heard aircraft being handed off to the tower as far away as 10 miles, but this only happens when there is very little traffic in the vicinity.

Thanks for participating in the discussion. It's good to hear different points of view. Even disagreement can help focus understanding. I have to say I respectfully disagree.

If the goal of location based scanning is to enable a radio system when the radio/gps has been moved inside the jurisdictional boundary, then I think the same theory applies to aviation. If I'm driving to the airport, and I want to hear when planes have entered the controlled area of the tower, then the geotag should specify that area.

I agree that I may or may not be able to hear the tower, but I'd like to be able to hear the plane as it enters the controlled area

Here is a refresher on the LBS concept:
LocationBasedScanning < UnidenMan4 < TWiki
With the geopolitical approach, you want the scanner to turn on the system/site or channel group at the limit of relevance rather than reception. This approach is useful for scanning targets that have a well-defined jurisdiction and their transmission are only relevant when you are within that jurisdiction
.

 

[DaveNF2G]

I see your point. Aircraft can be heard over tremendous distances, as you know. The trick is to come to a mutual understanding of what "relevance" means. I agree that aircraft under local control are relevant in the vicinity of the airfield, which makes the tower or other ground station relevant there, too.

ARTCCs and TRACONs are a different sort of animal. Ground reception of RCAG transmissions is extremely limited compared with ground reception of aircraft under their control. So, do we make all of the Boston Center RCAGs "relevant" to listeners throughout ZBW's area of responsibility? I think we would have to, but then how do you geotag for something like that?

 

[b52hbuff]

I see your point. Aircraft can be heard over tremendous distances, as you know. The trick is to come to a mutual understanding of what "relevance" means. I agree that aircraft under local control are relevant in the vicinity of the airfield, which makes the tower or other ground station relevant there, too.

I've been reading up a bit. Here is my reference:
Amazon.com: The Pilot&#39;s Radio Communications Handbook (9780070318328): Paul Illman: Books: Reviews, Prices & more

I think the place to start is the classification of the airspace (e.g. Class A, B, C, & D).

Check out this Wikipedia entry:
Airspace class (United States) - Wikipedia, the free encyclopedia

So, as always, let's start small. According to an article a pilot contacts tower in a Class D airspace at 5-10miles out. As I said in the proposal that started this thread, if we group all of the 'Airfield Ops' into one subcategory, and we should make that geotag with a radius of 10 miles.

 

[ootsk35]

I am a pilot, and would love to help but classification by airspace wouldn't work. As the ARTCC DB admin knows you will find that there are separate frequencies for aircraft below 23,000 feet and those above 23,000 feet. I would agree that it is probably better to classify based upon reception based upon distance received by scanner on the ground. However, there is probably a better way to classify. This because if I am scanning an airport. Say for instance KSUS - Spirit of St. Louis Airport it is going to be much different than KSTL - Lambert-St. Louis International Airport.

I think the DB should have a common layout when it comes to presenting the information but then if there is a TRACON that controls a larger area than normal (i.e. - SOCAL, NORCAL, MIZZOU, etc.) they should have a link on the airport page to direct you to the appropriate TRACON page.

TRACONs should be associated with the MAIN airport. For instance, KSGF - Springfield Branson National Airport should have the main information for Springfield Approach. This is because those individuals still control the area.

I would not recommended letting the FAA feeds update your databases because frequencies change more often and it can be more than two months or more before the appropriate information has been updated.

If you have any other questions feel free to ask.

 

[ericcarlson]

Regarding function tags, these tags are not intended to be a dynamic list and are essentially fixed at this time by Lindsay. Adding more specific tags as you suggest would open up the possibility of more specific tags throughout the database (think about things other than airports). The intent of function tags is for them to be used for large general groups; they are deliberately not specific.

Regarding geographic tags, I refer you to the Database Administrator Handbook section 6.6 which describes the intent and use of "geo tags." Specifically: "Geographic tagging of conventional frequency subcategories and talkgroup categories is used to indicate the 'service area,' e.g., a city center point and diameter (representing a circle to approximate the area of the city) -- not necessarily the actual area of radio reception." This is our standard procedure for geographic tagging throughout the database. As you can tell from the discussion on this thread, there are a lot of different individual ideas and opinions about how this "could" work, however we must adopt a standard for consistency.

 

[b52hbuff]

As you can tell from the discussion on this thread, there are a lot of different individual ideas and opinions about how this "could" work, however we must adopt a standard for consistency.

I agree with ootsk35, the airspace classifications are often described as inverted wedding cakes. Here is a picture that illustrates the point:
http://en.wikipedia.org/wiki/Airspace_class_(United_States)

I suggest that we pick the largest radius, since there is no way of practically determining altitude. The downside is that reception area is a bit larger than at the lower altitudes. The upside is that you get every aircraft in the airspace. Also note that you have other frequencies programmed into the radio to get the aircraft that are lower in altitude, and outside of the 'wedding cake'.

It is unfortunate that the tags are fixed. Realistically, they're not *that* fixed because someone has installed 'Tag this!!!' as a tag for much of the TX DPS talkgroups. But as we expand our collective experience with the HP-1 and other programmatic access, we might want to add tags.

Another tag I was thinking about was 'Research'. I saw a thread you were involved in where someone was trying to figure out an LCN of 0. I realize that the policy of the board is to only submit verified data, but the reality is that many folks submit data in hopes of facilitating collaboration. Check this out:
RadioReference.com - Scanner Frequencies and Radio Frequency Reference Database
...and I don't know how much other 'unknown stuff' is out there.

If we had some tag that indicated further research was required, it might standardize how folks post collaborative data.

Anyway, you guys make the call. If new tags are out of the question, then that will drive the aviation proposal I'm making. Since we won't have a service tag to filter on, we'll need to divide these frequencies by function so that folks can filter on subcategory.

Thanks for letting us know what is and isn't possible. Could you please take a look at my proposal and let me know what you think? What do you think is possible, what is unclear and what won't work in the current framework. After we get some more consensus and understanding, then we could make it an adendum to you DB handbook so folks could be more consistent with their aviation entries...

 

[cipher66]

I would not recommended letting the FAA feeds update your databases because frequencies change more often and it can be more than two months or more before the appropriate information has been...

Agreed on this topic, and that data does not "update" the RadioReference database. It is however, presented because some of the ARTCCs did not have accurate data in the first place and it was a good place to start with.

As far as ARTCCs are concerned, and please look at ZHU for reference, each RCAG is a transmitter location for the particular ARTCC. The data that I have (in addition to showing numerous other data points) provides the Lat/Lon of the RCAG and the "service radius" for each frequency off of that RCAG. So, if you look at ZHU, you'll see that many of the RCAGs have numerous VHF/UHF frequencies that transmitt from single RCAG locations. Because the RCAG location is the item that has the GeoTag, I used the service radius for the freq that had the largest area for that particular site. That way, the largest freq service area and all lesser areas are encompassed within that RCAG GeoTag. This is the way that meets the location based scanner philosophy that Lindsay wants to attain. I also have the same "service radius" data for all TRACONs & RAPCONs as well, and will work on them as time permits, although my primary area of concern is ARTCCs.

As to the question of geotagging an entire ARTCC - some of them that I have not yet edited the RCAGs for are geotagged as an entire ARTCC... ZOA I believe is in this format, as is ZAU.

As you can imagine, I'm hand jamming the info, so it will take time. I also confirm the data with the individual ARTCCs that wish to divulge such information (some do not, and I won't identify which one's they are).

 

[DaveNF2G]

I believe collaborative and speculative submissions belong in the Wiki, not the Database.

 

[cipher66]

I believe collaborative and speculative submissions belong in the Wiki, not the Database.

Agreed! Only confirmed data should exist in the database.

As for catagorization of Airports and their respective radar service areas, I too believe that TRACONs should be listed with the Airport that they mainly service, like the example that was given for KSGF in a previous thread, but that brings up the question of how do we handle large regional TRACONs like NORCAL, SOCAL, New York, Potomac, Boston CTF, etc... Those TRACONs are set up (comms wise) like an ARTCC, with remote transmitter/receiver (RTR) sites.

I just updated ZOA today, and started looking at ZLA, and discovered that someone had mistakingly inserted the NORCAL TRACON information into the ZLA database section. If anything, it should be it's own catagory (Like an ARTCC) under a state (or states for those that bridge multiple states)? What do you think?

 

[ootsk35]

I agree with just about everything said. TRACON facilities such as NORCAL or SOCAL should have a page setup similar to an ARTCC. That is how they are setup so that is how the data should be presented. I also agree with ericcarlson and b52hbuff when it comes to geotags. Center the tag on the Primary airport. While airspace does become a factor at that point I can fly in and around STL on a STL departure frequency 128.1 while normally being controlled by 123.7. It's a function of those should be tagged to STL for their approach facility.

For the most part you will find that Class B facilities will control up to 50 Nautical Miles out from the primary airport while Class C facilities will control up to 40 Nautical Miles. And while most Class D facilities only talk to aircraft up to 10 Nautical Miles out I have talked to a tower after being transferred at 20 Nautical Miles.

I also agree with ericcarlson that we should place an expected range ring around anticipated reception area. And only standard distances. If you show PM me or email me I can help with the ARTCC and other data.

 

[b52hbuff]

I also agree with ericcarlson that we should place an expected range ring around anticipated reception area. And only standard distances. If you show PM me or email me I can help with the ARTCC and other data.

Go back and read Eric's post again.

Specifically: "Geographic tagging of conventional frequency subcategories and talkgroup categories is used to indicate the 'service area,' e.g., a city center point and diameter (representing a circle to approximate the area of the city) -- not necessarily the actual area of radio reception." This is our standard procedure for geographic tagging throughout the database.

So the geotag represents service area and not reception. And as I said before, since we can't know altitude apriori, and there is no altitude input, we should pick the largest diameter service area for the airspace in question.

Anyway, please clarify, do you disagree with Eric's position (and I think most of us now agree on it), or did you mistype your message?

 

[b52hbuff]

I agree with just about everything said. TRACON facilities such as NORCAL or SOCAL should have a page setup similar to an ARTCC.

I agree and I disagree. I'd like to present some ideas and see how they flesh out. First, let me say I understand that the needs and resources will differ between a pilot and someone who is just listening on a radio. But I think we can draw some cues from how the information is presented to the pilot.

First, let's talk about the approach (no pun intended) that you advocate. I can get all of the Class B and Class C frequencies here:
SkyVector: Flight Planning / Aeronautical Charts
...just like a pilot can. I can navigate through the map to get an idea about where I am and what frequency to use.

Unfortunately, the geotagging doesn't work so well here, because even though the airspaces are circles, frequency usage is based on a compass heading. So I can't use geotagging to help me discriminate a set of field specific approach frequencies based upon where I am with my radio.

But if I want a list of all possible approach frequencies, then this is a good way to become situationally aware with a scanner to know what is in the Class B/C airspace.

Pilots also go to airport charts that show them which approach frequencies are used for that field. If I'm going to wait for uncle Buck at KRHV, which is under NORCAL approach, I go here:
AirNav: KRHV - Reid-Hillview Airport of Santa Clara County
It shows me that there are three VHF frequencies (out of fourteen) and what the Initial Contact (IC) approach frequency this is. There are fourteen NORCAL approach frequencies because it is a busy airspace. Why force a configuration that requires folks to scan all fourteen, when they are only interested in the three (or what ever subset) for the field they're interest in?

AirNav: KSJC - Norman Y. Mineta San Jose International Airport
KSJC, located just up the street, so to say, also has three approach frequencies, but one of the three is different. The IC frequency is the same.

AirNav: KSFO - San Francisco International Airport
If we go up to SFO, still in same Class B airspace, the approach frequencies and IC are different still. Putting the NORCAL approach frequencies with the airport they serve lets you customize the IC, Approach and Departure frequencies. Approach for an airport in the northern area will be a departure for an airport further south.

My point is that if you're planespotting at an unfamiliar airport, it is very convenient to have a per-airport NORCAL approach configuration. NORCAL approach is busy/chatty enough and having the appropriate subset of frequencies to monitor could be the difference between catching and missing the approach comm's for the airport you're interested in.

I can only see two downsides to duplicating the information. First is the maintenance overhead in mainting the information in two different places. In my mind, this is a false economy. I don't think the frequencies change enough for this to be that expensive in effort or storage.

The other issue is memory usage in the radio itself. The HP-1 appears almost unlimited in memory. The XT line has 25k channels. Memory capacities are going up. So having similar approach frequencies between airports in your scanner isn't that big of a deal. If you separate approach into a 'group', then you can still scan multiple groups across airport 'systems' if you just want to hear all of an approach.

...and if the data is also presented/available in a combined table, then folks can download that as well.

One other example to point out is how many municipal systems are configured in the database. In my local county, we have a group of mutual aid frequencies called BAYMACS. And as you would assume to be mutual aid, these frequencies need to be programmed into the radios of a variety of agencies. If you go look in my county, these frequencies are listed inside the individual agencies. And these frequencies are called out into their own section.

Anyway, I enjoy the debate, so let's talk about the pros and cons.

 

[ericcarlson]

I suggest that we pick the largest radius, since there is no way of practically determining altitude. The downside is that reception area is a bit larger than at the lower altitudes. The upside is that you get every aircraft in the airspace. Also note that you have other frequencies programmed into the radio to get the aircraft that are lower in altitude, and outside of the 'wedding cake'.

We don't have an official policy on the radius. You could also make a case for only encompassing the area of the airport since the base stations and planes on the ground are generally only monitor-able by us on the ground when we're on the airport grounds. I will give some thought to an official policy. (Please bear with us right now as we are dealing with a lot of maintenance and other issues resulting from the high level of interest in the HP-1. How airports are entered in the DB is not a high priority issue right now.) I am fine with using a reasonable radius out from the airport (based on the FAA airspace designations) so that planes may be monitor-able via geographic scanner programming.

Another tag I was thinking about was 'Research'. I saw a thread you were involved in where someone was trying to figure out an LCN of 0. I realize that the policy of the board is to only submit verified data, but the reality is that many folks submit data in hopes of facilitating collaboration.

Unconfirmed information does not go in the database. One main point of the wiki is to capture this information for collaboration purposes. The forums also are used for collaboration.

 

[b52hbuff]

We don't have an official policy on the radius. You could also make a case for only encompassing the area of the airport since the base stations and planes on the ground are generally only monitor-able by us on the ground when we're on the airport grounds. I will give some thought to an official policy. (Please bear with us right now as we are dealing with a lot of maintenance and other issues resulting from the high level of interest in the HP-1. How airports are entered in the DB is not a high priority issue right now.) I am fine with using a reasonable radius out from the airport (based on the FAA airspace designations) so that planes may be monitor-able via geographic scanner programming.

Actually, I can't make a case for it. The DB Lead says that geotag is service area, and not monitor-able area. (I just so happen to agree with the dude. )

And the service area for a tower is typically 10 statue miles.
Airspace class (United States) - Wikipedia, the free encyclopedia

Class D airspace is circular in form and normally extends from the surface to 2,500 feet (760 m) above the ground and to a variable radius (generally 5 statute miles) around airports with an operational control tower and not otherwise in Class C or Class B airspace. Class D airspace reverts to Class E during hours when the tower is closed, or under other special conditions.

Two-way communication with ATC must be established before entering Class D airspace, generally at 5 to 10 miles (16 km) out, but no transponder is required. VFR cloud clearance and visibility requirements are the same as Class C.

If all of the field frequencies are in the same geotaggable subcategory, then having a 10mi radius for the other stuff is reasonable too...

 

[ootsk35]

ok, so while I do agree with eric my only problem is actually wikipedia. Personally it may contain the correct data but since someone within the area of interest has to verify the data I don't like going there. And if I quote Wikipedia to the FAA, they will ask for another reference or suspend my certificate. So here is what the FAA has written about class D airspace.

Class D Airspace (taken from Pilot's Handbook of Aeronautical Knowledge)
Class D airspace is generally airspace from the surface to 2,500 feet above the airport elevation (charted in MSL) surrounding those airports that have an operational control tower. The con&#64257;guration of each Class D airspace area is individually tailored and when instrument procedures are published, the airspace is normally designed to contain the procedures. Arrival extensions for instrument approach procedures (IAPs) may be Class D or Class E airspace. Unless otherwise authorized, each aircraft must establish two-way radio communications with the ATC facility providing air traffic services prior to entering the airspace and thereafter maintain those communications while in the airspace.

So, while similar, FAA source verses non-FAA source, at least to me. Honestly it's close enough for the general public. The while I know people say 10 Statue miles, I have contacted a tower 20 Nautical Miles out because I know it's a busy place or because I can. So, while statue miles may be referenced, most pilots use nautical miles. If you want to define the radius based upon the standard airspace feel free, however, when talking about an approach facility you can always hear aircraft much further than you can hear a ground based transmitter.

buff I actually agree with you and think that we are thinking the same path. Each airport has a listed approach frequency and alternate frequencies used often. Then each approach facility has a page itself and those same frequencies are listed there as well.

For each airport you can designate North Approach Freq - 1xx.xxx or South Approach Freq - 1xx.xxx. I agree that airnav has it setup the right way. I also think that if you wanted you could use the FAA IAPs as the template for frequencies and take a clue as to the radi for which to geotag the airport. For instance, I was flying from STL area to the KC area today and was switched from approach to tower frequencies 15 nautical miles out. Does that mean that only those individuals within a 10 statue mile radius should hear me? Or should it be a more expansive? While California is a quandary itself, I think that 10 Nautical (or about 11 statue) would be appropriate. Just a pilot's perspective. And this one loves to listen to a scanner. Also, do you want to take the approach facility as T75 (STL approach) or STL apprpach?

 

[b52hbuff]

So, while similar, FAA source verses non-FAA source, at least to me. Honestly it's close enough for the general public. The while I know people say 10 Statue miles, I have contacted a tower 20 Nautical Miles out because I know it's a busy place or because I can. So, while statue miles may be referenced, most pilots use nautical miles. If you want to define the radius based upon the standard airspace feel free, however, when talking about an approach facility you can always hear aircraft much further than you can hear a ground based transmitter.

buff I actually agree with you and think that we are thinking the same path. Each airport has a listed approach frequency and alternate frequencies used often. Then each approach facility has a page itself and those same frequencies are listed there as well.
While California is a quandary itself, I think that 10 Nautical (or about 11 statue) would be appropriate.

I am selectivly quoting you here, because you've responded a bit over my head, and I want to do a little research. So I'm responding to the parts I understand. Just wanted you to know, I'm not trying to take you out of context.

The first/easist thing to say is that we're trying to develop guidelines by scannists, for scannists that will be implemented in scanners we can buy today and in the forseeable future. So the Uniden scanners accept geotags with units of statute miles. Most of the mapping tools we have access to as 'land dwellers' use statute miles. We should probably include the conversion between statute and nautical miles in the guide for clarity and to allw folks to extract data from aviation sources.

The one question I have about tower area is what is the distance at which point you will get in trouble, or otherwise raise suscpicion if you do not contact tower? As we all learned from Top Gun, buzzing the tower is not a good idea. But how close can you get to the tower as a General Aviation pilot without having contacted them? What is the dimension of the airspace they control?

I also wanted to clarify something about the multiple approach frequencies. I don't know where you fly, or how busy it is. My understanding of NORCAL is that the frequencies are configured based upon how you're approaching/departing the controlled airspace. Northern approaches ahve different sets of frequencies than southern approaches. So I don't think it is at a pilot's discretion to approach the airspace from the sounth and initiate contact on a northern approach frequency.

I wanted to make that clear, because an airport's selection of NORCAL frequencies isn't arbitrary. It is based upon their location within the airspace.