What Happened to the USFS Listings?

[jbaker6953]

The LACoFD listings will be "cleaned up" very shortly as its on my to-do list.

Again, the idea behind the DB is not to duplicate agency radio programming channel line ups, and end up listing the same frequency over and over across multiple agencies, but to list frequencies only belong to each agency.

We can get that by looking up their FCC license. What value is RR adding if they're just essentially going to offer a duplicate of the FCC license database?

While I can see how this can be frustrating for some, it can likewise be frustrating and take up precious scanner memory space for others downloading the same frequencies multiple times needlessly when they access the DB.

Let's hold a public vote open to all members.

I can't see how excluding channels that agencies actually use is of any use to anybody. If I load up an agency it's probably safe to assume it's because I want to listen in on their activity. The way RR has rearranged the database means I am locked out of hearing any activity not on the frequencies assigned to that agency. Not very useful, especially to a new scanner user who might not have any idea that Angeles dispatch is going to use LA County TAC 19 to direct a medivac helicopter to a forest incident (for example).

Additionally I would like to draw attention to problems that can be encountered when frequencies are updated by their primary agency, and you might now have old and incorrect orphan listing left in the DB under various other agencies that had the original frequencies listed also. Not a model for data accuracy.

Then change the way your backend works. You only need to have one actual record for NIFC TAC 1, for example, and any agency's comm plan that has NIFC TAC 1 can reference that frequency. Regardless, that's a problem that agencies face every day. If their radios are out of date, so too will the RR data for their agency. Do you want the database to reflect what an agency's comm plan should be, or what it actually is?

 

[kma371]

Wirelessly posted (iPhone 3GS: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8G4 Safari/6533.18.5)

Ok folks. Again, if you have problems with the way the format is, contact eric carlson. We (laflyer and I) arent in any position to have a "vote" on the subject.

 

[WayneH]

Let's hold a public vote open to all members.

Please take it to the DB Administration forum. You all need to stop arguing with the DB Admin. They're only following the guidelines and arguing with them is pointless.

I for one hate downloading data from the DB and having five instances of the White fire channels.

 

[jbaker6953]

I for one hate downloading data from the DB and having five instances of the White fire channels.

That's a valid concern. However, when evaluating a course of action you have to weigh the consequences. Sometimes there is no perfect solution and only a less evil solution. In your case, you are annoyed by having multiple instances of the same channel downloaded into various places on your radio. The action required to address this on your end is to find the duplicates and delete them.

On the other hand, removing the duplicates from the RR database removes important information over and above the frequencies. When you remove a frequency from an agency's lineup, you are removing documentation of interagency relationships. That information is very difficult to come by and frequently we only know of them because "insiders" let the cat out of the bag by sharing their channel lineups. The action required to address this is to independently figure out each agency's communication plan. This requires a great deal more effort than finding and deleting duplicate channels.

In essence, this boils down to a choice between making users who don't like duplicate channels find and delete them on their own, and making users who like having an agency's entire channel lineup independently find this information from somewhere else and manually program it. This information used to come from RR, but now not only will users interested in hearing ALL of an agency's communications have to reprogram the channels in their scanner just like people who hate duplicates, but on top of that reprogramming they have to research the interagency communications relationships for each agency they wish to monitor. This seems like an unfair burden to place on people simply so some people can avoid being annoyed by having to delete nuisance channels.

 

[SCPD]

Please take it to the DB Administration forum. You all need to stop arguing with the DB Admin. They're only following the guidelines and arguing with them is pointless.

I for one hate downloading data from the DB and having five instances of the White fire channels.

I don't think any of us are arguing with the DB Admin folks. I certainly did not. If we move this discussion to the DB Admin forum it will die because people like me never look there. This discussion is specific to the removals from the USFS listings, although it can apply to other agency listings.

I cannot find the repeater tone listings for each agency in the Wiki pages. It seems to have disappeared entirely. If it is there someone needs to show us its location.

I for one do not use the database download. I prefer to customize my file writing. For example, I'm not going to download the entire Forest Service page. Why would I wan't the Klamath NF in a scan list when I'm in L.A.? I use the database similar to the way I use a printed frequency directory, I read it, print it out and then manually enter the information. I do have duplicates so that when I'm in a particular area, such as Yosemite National Park, which is in a separate scan list, it shows the Park's entire channel list and labeled as such. So the NIFC channels are duplicated as they are also in my eastern Sierra list.

The point is, the RR DB is beginning to replace many printed frequency directories. Those directories are often times the only place we can find specific information such as the channel listings we are talking about. Those guides also have repeater info, call sign info, and the like. We can write Wiki pages for this into and this should be done. RR is being provided as a link or listed in receiver owner's manuals. We are beginning to be the central source of information. We need to have all the information available in the database that the printed directories have. Some of those directories may not be published in the future. Our database should make sure this information is not lost.

Wayne, please don't move this thread to the DB Admin forum as it will end a good discussion of an important topic. More people read the regional forums than go to the the DB admin forum.

 

[WayneH]

I don't think any of us are arguing with the DB Admin folks. I certainly did not. If we move this discussion to the DB Admin forum it will die because people like me never look there. This discussion is specific to the removals from the USFS listings, although it can apply to other agency listings.

Actions performed in the DB involving USFS for California were done based on what's stated in the DB Admin Handbook. Since the statements in the Handbook are not CA specific this issue needs to be handled in the DB Admin Forum so this matter can be addressed. This is not about USFS, it is about how the handbook states data should be handled and how the USFS has been modified to reflect that. You all can keep discussing it but it will be pointless since DB Admin can do nothing about it.

Sorry guys but I am not going to keep explaining it in different ways until someone understands.

 

[jbaker6953]

Thanks for your help. I suppose this is just one of those things where some members of the community disagree. In the open source software world, this is when you fork a project. I'm looking into the costs and feasibility of developing an independent database that is designed for users who want to basically "clone" an agency's radio programming to hear what agency employees hear, and who want to learn more details about how an agency's radio communications work. The RR admins have made the executive decision that their database is to be one that conveys only frequency assignment information as opposed to actual usage information. That is their prerogative.

Shouldn't be too hard to slap together some PHP and SQL to get something preliminary up and running.

 

[lbfd09]

Please take it to the DB Administration forum. You all need to stop arguing with the DB Admin. They're only following the guidelines and arguing with them is pointless.

I for one hate downloading data from the DB and having five instances of the White fire channels.

I don't think anyone is trying to be argumentative, but rather discussing how we as various users are using the data. Different scanners = different load types, different parts of the country can influence loading strategies. Yes rules are in place and I am sure no one is wanting any of the Admins to disregard the rules, Sometimes when one is posting their prospective and their using of the data base, passion might intertwine when it is perhaps should be more monotoned.

Yes Wayne, I too think many times that a listing of the White channel even is it is licensed to that agency and is used regularly, might be overly redundant. Yet for example, the listings of the airports (another valuable resource) can also be construed that way; as are there are a limited number of frequencies for unmanned airports. And at least in my programming software, I am given the ability to pick and choose what I want to "snatch" for the data base and transfer to the scanner.

Hopefully everyone is moving this discussion to the Data Base Forum and we will continue to improve this great site even more.

 

[gmclam]

People need to think and act outside the box

This is an interesting thread/discussion to say the least. I'd bet the issue was instigated because of the scanners that now come with the DB loaded in their memory cards.

I have often questioned the need to list the same frequencies over and over. But I have also questioned the listing of frequencies that are no longer used, although someone may be squatting on a license.

The "load outs" of official radios has also not gone unnoticed. I can see that for people who want those frequencies (fire fighters programming scanners to match their work radios, etc) the information is essential. But when the DB is blindly cloned into those memory cards, there is a lot of redundancy. Putting the load outs into the Wiki does not work either, because it is too easily changed (same reason I won't submit to a Wiki).

There are clearly competing interests here. RR needs to decide if their DB is going to continue to be useful for everyone, and/or wake up and realize that a lot of people are going to stop submitting to a DB that no longer fits their needs.

I think a creative solution is required. It can happen in one of several ways. Perhaps it means essentially "multiple databases" or at least the ability for the user to "filter" DB data to match their needs. It seems much easier to list all radio load outs and post multiple frequencies as we have been doing, and to run some simple "remove duplicate data" script when exporting. This script could be incorporated as part of the web site, in the multitude of programs that import for scanner programming, or when the DB is exported to those scanners' memory cards.

Without some clever solution, one group or another will find this site no longer useful.

 

[jbaker6953]

I think a creative solution is required. It can happen in one of several ways. Perhaps it means essentially "multiple databases" or at least the ability for the user to "filter" DB data to match their needs.

Extremely easy to implement by adding a column to the table used to store frequency listings. You could make the column a BIT value that would only add about 1kB of data for every 8,192 frequency listings. 0 meaning the frequency is assigned to the current agency, and 1 meaning that the frequency is licensed to another agency but is programmed into the current agency's radios. Then it's a matter of a proper query to pull the data you want.

Without some clever solution, one group or another will find this site no longer useful.

The solution will come, the question is whether the solution will be hosted at RR or not. Competition is good.

 

[ericcarlson]

Please see my reply in this thread for some clarification on this topic:
http://forums.radioreference.com/da...se-rules-regarding-duplicate-frequencies.html

I would like to add that the capability to have native RR database support for "nationwide" frequencies is under development so that will be coming (I don't have a timeline yet). This would allow you to download the nationwide frequencies directly from the DB without reading through the wiki.

 

[brianearlspilner]

Please take it to the DB Administration forum. You all need to stop arguing with the DB Admin. They're only following the guidelines and arguing with them is pointless.

I for one hate downloading data from the DB and having five instances of the White fire channels.

Same here. I remember downloading Data from the LACOFD part of the database only to find that there is a weather channel and those marine channels listed on there. What is the point of that? Marine channels I can understand, even though those come on the scanner already. But the weather channel that was there? (Don't know if it's still there) Give me a break.

 

[trooperdude]

Personally (as a user) I absolutely HATE having to go to 4 different places to find the frequencies I need to program up an agency loadout into a scanner (not a pre-loaded listening device),

I tend to program banks by agency, and by tactical use. Often
time repeating NIFOG and Interop channels per bank.

But it's not my call to make, and I don't see the current DB guidelines changing to re-accommodate us legacy scanner users anytime soon.

Not too fond of the DB changes that were required to accommodate the pre-loaded
devices. Made my programming life much more difficult.

FWIW. My 2 cents as a USER.

 

[b52hbuff]

Yet for example, the listings of the airports (another valuable resource) can also be construed that way; as are there are a limited number of frequencies for unmanned airports. And at least in my programming software, I am given the ability to pick and choose what I want to "snatch" for the data base and transfer to the scanner.

Since I am an aviation buff, I found your comment interesting...

122.7 Search Results
122.8 Search Results
123 Search Results

...those are the more common listings in California. So would the RR.com db consider collapsing all of these duplicates into these list of unicom frequencies:
UNICOM - Wikipedia, the free encyclopedia

The issue of course, given the huge amount of distance that aviation RF can travel is how do you know what is used at the particular facility at which you're monitoring?

In another example, how about this mutual air frequency:
460.025 Search Results
...would all of these uses be collapsed? Or only the ones that don't have a tone or have CSQ?

btw, I'm not complaining, but trying to understand from examples...

 

[lbfd09]

Since I am an aviation buff, I found your comment interesting...

122.7 Search Results
122.8 Search Results
123 Search Results

...those are the more common listings in California. So would the RR.com db consider collapsing all of these duplicates into these list of unicom frequencies:
UNICOM - Wikipedia, the free encyclopedia

The issue of course, given the huge amount of distance that aviation RF can travel is how do you know what is used at the particular facility at which you're monitoring?

Someone much smarter and wiser than I assigned the Unicom to the various smaller airports and landing strips. Many neighboring facilities share the same Unicom, which when one thinks about it makes sense. Pilots want to hear traffic in their area, too much traffic needs their own frequency. (Sorry preaching to the choir.)

It makes more sense keeping the listings here way they are already set up, but...

In another example, how about this mutual air frequency:
460.025 Search Results
...would all of these uses be collapsed? Or only the ones that don't have a tone or have CSQ?

btw, I'm not complaining, but trying to understand from examples...

That is the CLEMARS frequency if memory serves me correctly. Most, if not all of the repeaters do require a PL, as one does not want to trip the repeater on the other hill, when accessing the one in town. These should most likely be kept in. With PLs in the scanners it only make sense. Now the simplex 154.9200 and low band equivalent do not make use of repeaters, thus I would think follow similar guides as White Fire.

Again only my observations and "If I were King" thoughts.