Proposal to define aviation database pages...

[b52hbuff]

Well, the best way to do that (it's what I do) is create a system for NORCAL and a system for airports and turn them off and on as needed. I DO NOT think duplicating is the answer and I think that's the opinion of the DB admins as well.

It's really not all that simple to completely duplicate information from one location to another (unless it's just a hyperlink, which could be an option)

Admins have discussed creating state and nationwide listings for mutual aid frequencies so your example is going to be a thing of the past shortly.

We're getting a little off track, but BAYMACS is a Bay area thing. If you try to nationalize it, you'll lose the tone information.

I don't see why it's hard to duplicate data? Just copy it. But in the list of issues I have it's low. It's more convenient to have the per airport approach frequencies.

In the HP-1 paradigm, I can create a 'Favorites' list that pulls in all of the data at once. It's a bit of a pain because I have to troll around four counties to find the airports to do it (San Mateo, Santa Clara, Contra Costa and Alameda). But it's easier to pull that information together than to try and pull apart a combined list into individual airports.

 

[kma371]

Wirelessly posted (iPhone 3GS: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_2 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A400 Safari/6531.22.7)

Well, the best way to do that (it's what I do) is create a system for NORCAL and a system for airports and turn them off and on as needed. I DO NOT think duplicating is the answer and I think that's the opinion of the DB admins as well.

It's really not all that simple to completely duplicate information from one location to another (unless it's just a hyperlink, which could be an option)

Admins have discussed creating state and nationwide listings for mutual aid frequencies so your example is going to be a thing of the past shortly.

We're getting a little off track, but BAYMACS is a Bay area thing. If you try to nationalize it, you'll lose the tone information.

I don't see why it's hard to duplicate data? Just copy it. But in the list of issues I have it's low. It's more convenient to have the per airport approach frequencies.

In the HP-1 paradigm, I can create a 'Favorites' list that pulls in all of the data at once. It's a bit of a pain because I have to troll around four counties to find the airports to do it (San Mateo, Santa Clara, Contra Costa and Alameda). But it's easier to pull that information together than to try and pull apart a combined list into individual airports.

Well I said state and federal so that would be included in California.


And It's not as easy as just "copying" it.

When entering it into the DB, it isn't free form. Each frequnecy listing is divided into 10 sections. Freq in, freq out, license, type, mode, sort, alpha tag, description, tag, blah blah blah.

It may sound simple to you, but all that data is a nightmare to transfer, not to mention adding all the new agencies, categories, subcatagorys, sorting, and geotagging for each duplicate listing.

 

[kma371]

Wirelessly posted (iPhone 3GS: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_2 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A400 Safari/6531.22.7)

Well, the best way to do that (it's what I do) is create a system for NORCAL and a system for airports and turn them off and on as needed. I DO NOT think duplicating is the answer and I think that's the opinion of the DB admins as well.

It's really not all that simple to completely duplicate information from one location to another (unless it's just a hyperlink, which could be an option)

Admins have discussed creating state and nationwide listings for mutual aid frequencies so your example is going to be a thing of the past shortly.

We're getting a little off track, but BAYMACS is a Bay area thing. If you try to nationalize it, you'll lose the tone information.

I don't see why it's hard to duplicate data? Just copy it. But in the list of issues I have it's low. It's more convenient to have the per airport approach frequencies.

In the HP-1 paradigm, I can create a 'Favorites' list that pulls in all of the data at once. It's a bit of a pain because I have to troll around four counties to find the airports to do it (San Mateo, Santa Clara, Contra Costa and Alameda). But it's easier to pull that information together than to try and pull apart a combined list into individual airports.

Well I said state and federal so that would be included in California.


And It's not as easy as just "copying" it.

When entering it into the DB, it isn't free form. Each frequnecy listing is divided into 10 sections. Freq in, freq out, license, type, mode, sort, alpha tag, description, tag, blah blah blah.

It may sound simple to you, but all that data is a nightmare to transfer, not to mention adding all the new agencies, categories, subcatagorys, sorting, and geotagging for each duplicate listing.

 

[DaveNF2G]

When entering it into the DB, it isn't free form. Each frequnecy listing is divided into 10 sections. Freq in, freq out, license, type, mode, sort, alpha tag, description, tag, blah blah blah.

It may sound simple to you, but all that data is a nightmare to transfer, not to mention adding all the new agencies, categories, subcatagorys, sorting, and geotagging for each duplicate listing.

Isn't that what SQL is for?

I don't understand how having certain categories of frequencies in the Wiki is going to help the premium members and HP-1 users who want to download them into their scanner software.

 

[kma371]

Wirelessly posted (iPhone 3GS: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_2 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A400 Safari/6531.22.7)

When entering it into the DB, it isn't free form. Each frequnecy listing is divided into 10 sections. Freq in, freq out, license, type, mode, sort, alpha tag, description, tag, blah blah blah.

It may sound simple to you, but all that data is a nightmare to transfer, not to mention adding all the new agencies, categories, subcatagorys, sorting, and geotagging for each duplicate listing.

Isn't that what SQL is for?

I don't understand how having certain categories of frequencies in the Wiki is going to help the premium members and HP-1 users who want to download them into their scanner software.

I don't understand your reply to the quoted post.

 

[cipher66]

Where else to get 'unpublished' approach frequencies? How do the pilots get them?

They are handed off to them... Example..

The initial feeder freq for KBWI (Baltimore-Washington International Airport) from the NorthEast is 125.525 (Potomac TRACON BELAY Sector). But, neither the Airnav Website, nor the A/FD show this frequency... AirNav: KBWI - Baltimore/Washington International Thurgood Marshall Airport

According to the Air Nav website, the appropriate approach freq for this would be 119.0 which is actually "Finals-North".

The only way to truely know what freqs are used for what purpose is to get the info from the TRACON - or monitor the useage and determine the correct frequency... In the above case, the freq is listed at PCT - Sector Airspace & Frequency Maps

which shows this sector... Although I'll have to get someone to check it out, because the site is showing an error (they call it 123.525)

 

[b52hbuff]

I would not be opposed to increasing the Airfield ATC out to 20 NM but no more than that, I feel, would be realistic. Under no circumstances should the Airfield ATC database entries be given a radius less than what the official airspace service area is.

I am a little confused here. kma371 has said that in the name of reducing complexity, we're going to pick default distances for tower/field and for the approach subcategories. Since he has undertaken the huge task of entering in airport information for California, I think we need to understand the need to make this as easy as possible.

But I have two reservations that I want to clear up. kma371 wants to enter these defaults as STATUE and not nautical miles. So 10nm = 11.5sm and 20nm=23sm. If we convert the other way, 10sm=8.69nm and 20sm = 17,4nm.

The concern is that by picking the value for nautical miles and just inserting that number as a statute mile, you are off by -15%. I can understand the need to simplify the initial entry by picking reasonable defaults, but I don't see why it is so much more work to enter 11.5 instead of 10 as a default value? We already enter one or two decimal places in these values, so precision isn't the issue...

I think it shows some care, thought and concern for accuracy of the subject. It shows we understand the subject and we are careful with the data..

Also, I want to make sure that if motivated hobbyists decide to submit more accurate values based upon aviation charts, that these submissions will be accepted and installed.

 

[DaveNF2G]

I don't understand your reply to the quoted post.

Which part?

Modifying the data using SQL should not be so nightmarish once the proper outline has been set up.

Frequencies in the Wiki cannot be downloaded into scanner software.