Why aren't database names constrained?

[SCPD]

I'll jump back in here. The screen shots of the software and radio display do not apply to me at all. I run a PRO-2067, PRO-92, PRO-96, (2) PSR-600 (one base and one mobile) and a PSR-500. None of these have a "System" line on the display. The system or bank is alternatively flashed on the channel ID line and the amount of time between flashes can be selected by the user. I find the flashing back and forth to be quite annoying as I don't know when I'm going to have a chance to look at the scanner display while I'm driving and I need to see the channel ID more than the system or bank ID. When I'm driving long distance I ask my wife to look at the display and the flashing bothers her as well. It is hard for anyone in the passenger seat to read the display as it is oriented to the driver as it is a in dash, DIN mount and that part of the dash ir angled toward the driver.

As a result I program the agency name on each line. I abbreviate as much as I can, but with about 30 full programs covering all of California, Nevada, Arizona and New Mexico, plus a a couple for the southern portions of Utah and Oregon, I can't abbreviate too much as it is easy to forget what MFD means, even when I know which county I'm in. Most of my programs are written for rural areas as I don't usually travel into metro areas by choice. A particular county may have several entities that begin with "M"

The majority of the time I have to add the name of the jurisdiction to every line once I download from the Radio Reference database. This is quite time consuming. I also find some abbreviations written by others to not match my thinking and I change them. Sometimes I wonder if writing a program from scratch is less time consuming than downloading one from the database. For large cities using trunked systems I usually use the database so I don't have to wonder if I've incorrectly entered a frequency or some other system setting that will render the rest of my programming useless.

It is easy to say that putting the agency name on every line is redundant if you have one of the radios that are being discussed here, but if you have the radios I have the redundancy is necessary. The other difference I have with most scanner users is 95%+ of my scanning is in rural counties, like the two county region I live in of about 34,000 people on 13,300 square miles of land.

 

[DaveNF2G]

I find it a little ironic that on one hand, people say that the RRDB can't be specific to certain scanners, yet you show a certain scanner as your reason for why the DB is set up the way it is.

My point in a nutshell, also.

How about we all take pictures of our non-HP scanners, programmed as per RRDB, and post them here? Maybe the issue will become apparent to the inexperienced.

 

[NDRADIONUT]

Maybe uniden shoud have the choice of using the decription field or the alpha tag field.... I can see exactly what the issue is... It will take a decision from the top the change how the dec. Field is done and a lot of work to change it....

 

[Voyager]

The alpha tag field is exceedingly short and non-descript. Again, look at Jason's pic for examples.

@David: I say gopher it. Although the aforementioned pic seems to demonstrate it well and is still dismissed.

 

[SCPD]

Maybe uniden shoud have the choice of using the decription field or the alpha tag field.... I can see exactly what the issue is... It will take a decision from the top the change how the dec. Field is done and a lot of work to change it....

Why do you only mention what Unident should do? Others here have been trying to raise the point that we should be looking at all models and manufacturers of scanners. We should be accommodating not just the latests models, such as the Home Patrol scanner photo a page or two ago.

 

[NDRADIONUT]

Ok anyone who uses the db for programming scanners or other radios should have the alpha / description choice....
We as in who ? The people who create the programming software are the ones who should provide that choice....

 

[SCPD]

I think (no idea) that Uniden chose the format for their RRDB aware scanners for the reason of actual use in those description fields.

The alpha tags use to only be 8 or 10 characters long. It should be now be 14 characters.

It can be really hard to fit anything useful in the alpha field at time (which was added as display scanners like the GRE came out).

Take the Los Angeles metro area. How many tags would be starting with LA? Quite a bit, but if you lived outside of the metro area proper, and you need to distinguish one agency from another if you travel around or visiting - or just live the next city over....

LAPD, LA City Fire, LA County Sheriff, LA County Fire, LAX Police, LAX, LASD (Los Angeles School District, Sheriff Department?) etc etc....

LA Sheriff (LASD) there goes 4 characters, CALTRANS - there's 8 before you need to work in what it is. An actual CALTRANS alpha tag is currently labeled as "DOT Red Mtn1". If you saw that on a GRE, would you know who that is? CALTRANS, County? Local? Someone named Dot with a FCC license?

Then add in the areawide systems that covers all sorts of agencies on top of conventional data, trunked data, blah blah.

It gets pretty involved to make it look good for everyone while maintaining data integrity and common sense. You can only have so many "Fire 1" before you look at that scanner that supports alpha tags only and guess on who it is

I don't have any "Fire 1" channel IDs in my scanner programs. I have an agency abbreviation included in the label for every channel. The channels in my program are labeled such things as "LAC Blue 1," VCFD 1 Dispatch" and "S Barb FD Cmd 3."

For Caltrans I don't show the entire "Cal abbreviation" in my scanner, I list the agency the same way in all of the files or programs I've written for the state. I use the letters "CT" and in cases where there are more than one Caltrans district in my program the letters are followed by the district number. As an example I have one program written for Ventura and Santa Barbara Counties. Ventura County is in Caltrans District 7 and Santa Barbara is in District 5. The alphanumerics in my Caltrans bank show "CT7" and "CT5."

In other states the departments of transportation are almost always abbreviated using "DOT," preceded by the state's single letter abbreviation. So I have ADOT, NDOT, UDOT, CDOT and ODOT in my scanners. The only multiple letter state I have written programs is New Mexico and thus I have NMDOT in my three programs for that state. I use an orange LED display for state DOTs and yellow for county and municipal road or public works agencies. This helps identify frequencies more quickly.

The GRE scanners I use when I travel have a 16 character capacity. "CTx" plus the space that follows allows 12 characters of use. That is plenty of space to list the repeater name and/or the area the repeater serves. Some Caltrans districts list the area served by a repeater and some the name of the peak the repeater is located on. I got a hold of a Caltrans handheld some years ago that had each district in a separate bank in the radio and was able see how each channel in the entire state was labeled at the time. The labeling in my scanners is the same as it is in the statewide program.

Other agencies such as: LAPD, LASO, CHP, CDF, LFD, LAC, and such don't take very many spaces either. I use the ICS 3 letter identifiers for fire departments I worked with on major wildland fire departments during my career, and use abbreviations for others that make sense to me. It takes some creative thinking, but all in all it works well. Having 16 characters is ample as compared with older 8 and 12 character displays.

I take issue with your statement that we should keep our eyes on the road 100% of the time because it is not realistic, especially on the more open roads in rural areas. Safe scanner listening and ham radio operation take focus and good judgement. Mobile radio use is exempt from cell phone laws in every state that has one. I've made my mobile scanner operation safer by eliminating the display's flashing between the system/bank and the individual channel label. If reading the scanner's display becomes too distracting when I'm alone I pull off the road.

 

[Voyager]

Ok anyone who uses the db for programming scanners or other radios should have the alpha / description choice....
We as in who ? The people who create the programming software are the ones who should provide that choice....

That's a moot point. Neither the Alpha Tag nor the Description is adequate for complete identification. The Alpha Tag is almost always an obscure abbreviation, and the Description is often nothing more than something like "Fire Operations".

 

[mancow]

I started this thread like a year ago and by now I'm totally confused.

So does it boil down to this; some software uses the alpha tag for channel naming and some use the description field?

If so, can the description be used as just another secondary alpha with text constrained to 16 spaces or whatever is adequate to accommodate the lowest tier of radios using that field, even if it means both end up being the same?

 

[NDRADIONUT]

It seems that no one is satisfied with any of the options so why dont you do as i do and type your own tags into the software....

 

[Voyager]

That's what I do, but it would be so much nicer if RR would do it for everyone - or at least stop making the descriptions useless as has been done of the past few years.

For Mancow, here is why your suggestion won't work:
http://forums.radioreference.com/da...database-names-constrained-8.html#post2517210

The alpha tags are confusing, and the descriptions are borderline useless.

what we need is an expanded Alpha tag that is not abbreviated like the short Alpha Tag is. It could be a full size tag. Maybe even call is a "Description" and do away with the current Description field.

That way SO45DISP could be something like "Licking County (45) Sheriff Dispatch" which is way more useful than just "Sheriff Dispatch".

Queue someone who will use the HP and an example of why that is not needed - like everyone uses HP-x's.

 

[mtindor]

I agree 100% and here is an issue ,I plus many other Ohio user have voiced with our portion of the database naming convention.

Jason,

Just curious, and not to be contrary... What Ohio users have expressed dissatisfaction besides you? How many? Where? When?

I remember when this decision was made. I remember barking about it myself. But it didn't take me long to realize that it was a good move. It makes the viewable version of the DB much tidier. It also helps to do away with the insanely long description lines that end up being imported into scanners, depending upon the software used to program the scanner. Sure, there are still long descriptions, but imagine how long they would be without this policy.

And all the current crop of scanners use that type of hierarchy and the display will show the hierarchy.

I'd rather see this in my scanner:

Carroll County
Fire and EMS
Fireground 1

versus

Carroll County
Fire and EMS
Carroll County Fireground 1

Oh, yeah, it also gets rid of some redundancy.

Sorry, but I have to respectfully disagree with the take that the way things are structured now is a bad thing. I like it.

Mike

 

[jasonhouk]

Mike,

See link to the Ohio forms where we discussed this in detail.

http://forums.radioreference.com/database-discussion-forum/293107-marcs-marcs-ip.html#post2205571

J

 

[wa8pyr]

Are there any constructive suggestions?

All,

I view this thread periodically to see if there are any constructive suggestions. Unfortunately, what I'm seeing is repetitive arguments from a few people.

As has been pointed out before, all of our data is made available through the API. I've looked at the issues some of you have raised, using many different scanners and software packages from different manufacturers, as well as Unitrunker and Pro96Com.

What I'm seeing is differences in the way the various software providers use the data rather than a failing of the database itself, and we have no control over the way the software providers make use of the API in their products. I really don't see any compelling reason to change the data in the database or the way it's configured.

Please keep in mind that the database serves two primary functions. It's a viewable source of information on the Web for everyone, including those folks who have to hand-program a scanner, as well as a source of data to program scanners via software. It's isn't all about one or the other; we have to strike a balance.

Is it perfect for everyone and every scanner? Obviously not, as it's almost impossible to suit everyone's personal preference. Does it strike a reasonable balance between a usable API that works for many scanners, and clean, non-repetitive data on the Web page? We think it does.

That being said, we can't be everything to everybody, all we can do is strike a reasonable balance, and it's a continual work in progress.

If anyone has any constructive suggestions, we would love to hear them. If you find information that is incorrect and doesn't conform to the guidelines in the handbook, please make a submission to that effect in the appropriate place. This forum is not the appropriate place.

As for this thread, it really isn't serving any useful purpose, and will be closed.