Main Database Conventions & Consistency

Status
Not open for further replies.

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
While the Main Database is certainly useful, it does have some major consistency issues regarding how things are named and how things are organized. For example, someone living in Berkeley County WV can hear traffic from VA, WV, MD, and PA. If you do an Add Channels On Range to create a Favorite List, or are scanning the Main Database, you'll get stuff from all 4 states. So if you see a conventional system labeled "State Police" you have no idea which of those 4 states' police the traffic is coming from, unless you recognize a zone or town referenced in the Department or channel labels. The same is true of other agencies. You see "Department of Fish & Game", "Game Commission", "Department of Conservation & Recreation", etc., and have no idea what state the traffic is coming from, especially if traveling, and you aren't familiar with local city names.

Having a convention of prepending the state abbreviation to the agency name would be immensely useful, e.g. "PA Game Commission", "VA Department of Conservation & Recreation", "WV State Police" and so on.

The same problem occurs when you have a city and a county with the same name. You see stuff referring to "Podunk" and don't know whether Podunk is Podunk City or Podunk County. Labeling county-level systems or departments as "Podunk Cty" or "Podunk Par" (in Louisiana) would disambiguate county- and city-level entities.

There is also no consistency in how business frequencies are organized. In some places, you have a system labeled "Attractions" (which should be "Podunk Cty Attractions" unless it's a Department under the System "Podunk Cty") that has a hodgepodge of stores and malls and such; in other cases you have a "Businesses" system and the Departments are labeled "Attractions - Wal-Mart" and such. In some counties, hospitals are listed under business Systems, and in others, hospitals are grouped with public safety entities.

What I'd like to propose is the development of a system of naming conventions and organizational hierarchy for system, department, and channel labels that makes it immediately clear to the user where traffic is coming from, without excessive redundancy. For example, if the System label references a county, then the Department labels do not need to reference it. But if the System label references a state, then it would be appropriate for the Department level to reference a county (if it's a county-level entity, as opposed to a zone or region other than a county/parish).

Mods, feel free to move this if appropriate.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
No disagreement from me except for tag limits on some radios...

But, if we're going to look at changes, I also would like to see more consistency in the way system talkgroups are "grouped".

In my area, we have some systems that have talkgroups grouped such that all talkgroups for a given county are in the same group where in other systems, each group (i.e. fire, police, services, etc.) are in their on groups.

In a similar fashion, we have groups of talkgroups where talkgroups deemed associated with a particular department within a given state are grouped into one very large group of 95 talkgroups that actually represent at least 6 major services. At the same time, there are multiple groups of talkgroups for the same system consisting of as little as 1 single talkgroup.

As for conventional channels -- there is also inconsistency once you leave the main / primarily public safety/county systems. Business? High education? Airport (businesses)?

Things have definitely changed over time. This is most notable with DNR and NXDN now appearing. It certainly seems like taking a step back and cleaning things up but only after some better, more consistent standards are defined for the database admins to follow.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
I'm not suggesting the data should be "tweaked" for any manufacturer or RR customer. I'm suggesting that some kind of consistency should be applied when the data is put in the RR database, not when it is extracted.

If there are any rules regarding naming conventions or hierarchical organization, they don't seem to be followed. Nor are the rules against entering the same frequency multiple times within the same agency.

For example, the VA Dept of Game & Fisheries has 10 entries for 159.435 MHz CTCSS 192.8 Hz.

Similarly, the Department of Natural Resources has over 20 entries for 159.450 MHZ CTCSS 114.8 Hz.

The entries are differentiated by various tones going into the repeater, but that's moot when listening to the output side of the repeater--they all have the same tone and freq on the output. It's super annoying when the frequency starts broadcasting a digital mode not supported by the scanner, and you have to Avoid 20+ channels in a row to make the noise go away.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
Jon - I didn't notice this earlier but maybe this should be moved out of the Uniden forum.... as long as it is here, the assumption will be that you're slanting your thoughts towards one vendor.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
I'm not claiming to have all the answers regarding the best way to consistently name systems and departments, but any system is better than the total chaos we have currently.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
I guess it depends if the System/Department hierarchy is assigned by RR or Uniden.
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Forums Manager
Joined
Jun 26, 2001
Messages
13,510
Location
Oot and Aboot
Moved to the Database Discussion forum since these are all RadioReference policies.
 

marksmith

Member
Joined
Jun 20, 2007
Messages
4,331
Location
Anne Arundel County, MD
None of these interesting conventions will take place on RR because of 1. The no favoratism policy, 2. The fact that descriptions are provided by various listeners from everywhere, and 3. Much more logical suggestions have been made and ignored by the moderators in the past and 4. Different radios have different tag lengths.

Also don't see how Uniden would do it without hiring someone to "enhance" the listings as they pull them from RR or in some other way monitoring and adjusting the Uniden version, which would then not match the RR version, which creates it's own problem.

This might be the reason that these radios and software have the ability for the USER to make any enhancements to descriptions to their own liking, with regard to how they are grouped, the descriptions of each category of departments or description of channels.

I change descriptions on all these things, create departments not in the database so that I can hold on more precise groups of talkgroups, etc. Frankly, even if someone came up with a real good system of naming and grouping, I probably would not agree 100%.

There are numerous examples of various threads suggesting changes to description or grouping. That's all they ever amount to, is discussion threads.

Mark
536/436/WS1095/HP1/HP2/996T/996XT/996P2/396XT/325P2/PSR800/15X/others
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
I don't see how implementing some naming and grouping consistency in RR would be any kind of "favoritism" to a manufacturer.

And I understand that no system is going to be 100% agreed with by everyone. But having zero consistency is worse by every conceivable measure.
 

marksmith

Member
Joined
Jun 20, 2007
Messages
4,331
Location
Anne Arundel County, MD
I don't see how implementing some naming and grouping consistency in RR would be any kind of "favoritism" to a manufacturer.

And I understand that no system is going to be 100% agreed with by everyone. But having zero consistency is worse by every conceivable measure.
Whistler scanners don't have a dept and limited characters for description. That's where the favoritism comes in.

Mark
536/436/WS1095/HP1/HP2/996T/996XT/996P2/396XT/325P2/PSR800/15X/others
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
Then how does Uniden group channels into Departments, and assign GPS coordinates to Departments?
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
The entries are differentiated by various tones going into the repeater, but that's moot when listening to the output side of the repeater--they all have the same tone and freq on the output. It's super annoying when the frequency starts broadcasting a digital mode not supported by the scanner, and you have to Avoid 20+ channels in a row to make the noise go away.

Since RadioReference's audience is not limited to scanner-users, the DB architecture should not be either.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
It's not an architecture problem, its a data problem. If the entries are located in different physical locations, that should be noted in the RR database. Each entry should have the GPS coordinates of the tower and intended service area. Fixing this will benefit everyone, not just scanner users. For scanner users, the data would get binned into separate departments so that most of them would be turned off by location control (and so the scanner isn't scanning 20-fold duplicates of a frequency), and other users would benefit by having a clearer idea of what is in their local area.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
Whistler scanners don't have a dept and limited characters for description. That's where the favoritism comes in.

Mark
536/436/WS1095/HP1/HP2/996T/996XT/996P2/396XT/325P2/PSR800/15X/others

Actually - incorrect.

I did point out above the there are some radios with limited alpha tagging display lengths. That presents a problem - but only in terms of those labels.

While it is true that Whistlers do not have "departments", they still use "group" names (Uniden calls department) to allow users to do imports of subsets of information from systems.

I agree with Jon that there does need to be some better semblance of consistency in the way the information is posted across the board - not left to individual or pockets or database admins to decide how they want to do it - which is where the inconsistency comes from.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
Actually - incorrect.

I did point out above the there are some radios with limited alpha tagging display lengths. That presents a problem - but only in terms of those labels.

Devising a consistent and concise label convention will benefit users with these radios.
 
D

DaveNF2G

Guest
It needs to be a cooperative venture between RR, which has already gone a long way toward accommodating as many different scanners as possible, and the manufacturers and software developers. Perhaps if the RRDB had behind-the-scenes pointers to labels/descriptions/alphatags that are suitable for different ranges of scanner display size (and maybe it does), then the software developers should use that system to draw the appropriate presentation info from the RRDB for whichever scanner model is to be programmed.

As for programming commercial two-way radios, I personally don't believe that professional radio systems should be relying on a database maintained by hobbyists, no matter how well-intentioned the admins might be.
 

jonwienke

More Info Coming Soon!
Joined
Jul 18, 2014
Messages
13,416
Location
VA
It needs to be a cooperative venture between RR, which has already gone a long way toward accommodating as many different scanners as possible, and the manufacturers and software developers. Perhaps if the RRDB had behind-the-scenes pointers to labels/descriptions/alphatags that are suitable for different ranges of scanner display size (and maybe it does), then the software developers should use that system to draw the appropriate presentation info from the RRDB for whichever scanner model is to be programmed.

The current data in the database doesn't make any accommodation for radios with short label limits. The admins' style guide frowns on abbreviations for clarity reasons (Pennsylvania State Police vs. PSP). "County" is always spelled out in full whenever it appears.

As for programming commercial two-way radios, I personally don't believe that professional radio systems should be relying on a database maintained by hobbyists, no matter how well-intentioned the admins might be.[/QUOTE]

Agreed. It's ludicrous to imagine that a police department would program their radios based off RR data, rather than their FCC liaison.

Here's what I'm proposing for consistency guidelines:

1. No abbreviations, except for the following:
a. 2-letter state code shall always be substituted for the state name ("PA" vs "Pennsylvania").
b. "Cty." shall always be substituted for "County". "City" is not to be abbreviated, to disambiguate between county and city.
c. "Par." shall always be substituted for "Parish" when referring to the county-equivalent governmental unit in Louisiana, but shall be spelled out when referring to a subunit of a Catholic diocese.

2. Eliminate redundancies in system, group, and channel names. If the state and agency are mentioned in the system name, then the group name should be "Southwest Region", rather than "Pennsylvania Game Commission Southwest Region". If the system name, group/department name, and channel name are concatenated, the concatenated string should not contain any duplicate or repeated names.

3. The state name shall always be included in the system or group name for a state-level agency.

4. The county name shall always be included in the system or group name of a county-level agency.

5. If a county has a city with the same name within its borders, the use of Cty. or Par. shall disambiguate county-level entities from city-level entities. "Podunk Cty." indicates a county entity, and "Podunk" indicates a city-level entity.

6. Duplicate frequency entries with the same DCS/CTCSS/color code shall not be allowed within the same group/department. If there are 20 state parks using 159.450 MHz and CTCSS 114.8 Hz, then each park shall be in its own group/department, tagged with a reasonable approximation of the park boundaries. This will declutter scan lists by preventing a scanner from scanning a frequency 20 times in a row--19 of the 20 entries should be locked out by Location Control or the manufacturer's equivalent. It will also ensure that the scanner user is accurately informed of the source of the transmission. Currently, any transmission on the duplicated frequency shows as the first duplicate in the scan list, even if it is hundreds of miles away. Duplicate frequencies shall be allowed if the DCS/CTCSS/color code is different for each frequency entry.
 

marksmith

Member
Joined
Jun 20, 2007
Messages
4,331
Location
Anne Arundel County, MD
The current database allows the manufacturer to pull the database and modify as needed. Those with 16 character displays use the "alpha tag" and Uniden uses the "Description" because it will fit.

Uniden uses the headings as departments while Whistler just uses them to more precisely pull talkgroups from the database to scanlists.

Each manufacturer uses the database to fit their own needs, and uses the fields differently.

Therefore, any kind of standardization in the database won't necessarily translate to standards in the manufacturers database.

Mark
536/436/WS1095/HP1/HP2/996T/996XT/996P2/396XT/325P2/PSR800/15X/others
 
Status
Not open for further replies.
Top