Database changes

[Metrofire31]

I would like to ask that consideration be given to a slight modification in what constitute a "flagged" change in the database. I suspect I am but one of many RR supporters and followers who check the RR Database daily - quite often, more than once. At present, the Home Page highlights a county or system in green anytime a change is made to that record. For those of us who rely on these highlights to guide us to changes in scanner or two-way radio programming changes, the green highlights are a great, eye-catching way to see which record(s) has/have changed.

However, at present, a county or system item - frequency, talkgroup, function tag - is considered changed, and therefore triggers a "green" highlight, if a function tag is modified, a spelling error is corrected, a channel/talkgroup are added or deleted, or most anything has changed. Over the weekend, there have been several changes in numerous Georgia counties and TRS. Many of these say something like "talkgroup deleted". Unfortunately, we have no way of know exactly what was deleted. That also applies to "1 talkgroup updated".

I would like to ask that Database changes that trigger a green highlight either be explained more thoroughly or not trigger a highlight at all if it's not significant. At the present, we treat adding a new talkgroup and correcting a function tag exactly the same. The only difference is the new talkgroup is generally identified.

This change would be a very welcome improvement for those of us who follow database changes closely. I'd be happy to talk with someone live if appropriate.

Metrofire31
Atlanta
WQIT636

 

[dragon_slayer79]

I second this.

 

[kma371]

This issue has been discussed previously. Let me see if I can find the thread...

 

[Metrofire31]

Database

Perhaps it has been discussed previously but evidently nothing has changed. When I see a green highlighted county, for example, I always follow the link to see what the change was. If the database administrator posts the change as "1 frequency updated" but there's no way for the rest of us to know what that change was, how are we supposed to determine whether some action on our part is required related to programming. If your answer is that the change wouldn't have required any programming change anyway, why even highlight it on home page? In other words, why give it the same change status as a "real" change in which a new frequency/channel is added or a new TRS talkgroup is posted.

Chasing "ghost" database changes is very annoying for those of us who rely heavily on the database, yet whose time is at a minimum due to other constraints.

Metrofire31
Atlanta

 

[OCO]

This issue has been discussed previously. Let me see if I can find the thread...

Like this? Careful where you go with this discussion or you'll get an invite to write your own software..

 

[blantonl]

We'll get more granular change reporting on the roadmap for our 2012 strategic plan that is currently under development.

 

[Metrofire31]

Database

Thanks, Lindsay!

Just asking for this to be considered. I readily admit that this website is far and away the most meaningful tool ever invented for scanner and two-way radio enthusiasts. I certainly appreciate all the work that you and others perform on our behalf, not to mention the financial investment. I believe all of us who are serious subscribers should offer any reasonable ideas that would benefit the overall value of the website.

Thanks for all you do - it is greatly appreciated.

Mike
"Metrofire31"
Atlanta
WQIT636

 

[OCO]

We'll get more granular change reporting on the roadmap for our 2012 strategic plan that is currently under development.

Thanks for considering the issue, Lindsay!

(Retired 4 years and the phrase "strategic plan" ran a chill down my back....but then I thought - you should be working on 2015 right now shouldn't you??:wink

 

[wise871]

I was up in the Atlanta area during the New Years week and had my radios with me. I lived there for awhile and still have family there. I visit there several times a year. I made slight adjustments for the entire Atlanta area but I made no major changes except to clean up the descriptions, fix tags or make slight adjustments. I made sure I checked Supress Timestamp Update but the system still flags the county green indicating a change. If you look at the Map you can almost see the route I took to and from Atlanta. I always have several scanners running when I travel to help verify data in the database.

Metrofire31 has a good idea. I hate making adjustments and the system flags green for something as small as a correction. I hope I didn't scare anyone. Just trying to ensure the database is as accurate as possible.

 

[GTR8000]

I made sure I checked Supress Timestamp Update but the system still flags the county green indicating a change.

I hate making adjustments and the system flags green for something as small as a correction. I hope I didn't scare anyone. Just trying to ensure the database is as accurate as possible.

^ This.

I feel bad when I make very minor adjustments (such as removing a space in a callsign, correcting a spelling issue, etc.) or simply re-sort a subcategory, and all of a sudden everything lights up bright green even if Suppress Timestamp Update was checked. Especially when the change log is very vague and only reports something like Frequencies Updated (Updated: 12, Deleted 0), but none of them are highlighted because of the timestamp suppression.

In a similar vain, I've noticed that if the Type (Class Station Code) field is previously blank, when you edit the frequencies in a sub-category it automatically populates all the blank fields with RM, which then lights them all up bright green. Ordinarily I'd fill in any blanks I come across, but since the fields are populated before you even get a chance to look at them, it's not always easy to tell what was a legit existing RM station, and what was filled in automatically. I've gotten into the habit of opening the page in a new tab so I can compare old vs new, but that can be a pain with a very busy subcategory.

 

[K9DAK]

Another Question

OK, it sounds like one of my database update questions has been thoroughly covered and is planned to be addressed.

But, I wonder, when an update is submitted, how (or if) the information is verified. I've seen several examples of changes made, one just in the last few days, that are just plain wrong.

For example, my town's fire department had been listed correctly, but the latest update (02 May) removed that entry completely, and incorrectly listed its replacement. I'm a member of their Emergency Management Agency, so I know that Wauconda, IL Fire dispatch is still on 153.8900 (I'm listening to a tone-out as I type), and NOT on 155.6550.

This particular change may occur sometime in the future, but shouldn't the database accurately reflect what's actually in use, right now, at this point in time?

Perhaps the source of the information could be included with the description of change, or include the ticket number and make the that database available; that way someone with questions could contact the original submitter for further info.

 

[GTR8000]

OK, it sounds like one of my database update questions has been thoroughly covered and is planned to be addressed.

But, I wonder, when an update is submitted, how (or if) the information is verified. I've seen several examples of changes made, one just in the last few days, that are just plain wrong.

For example, my town's fire department had been listed correctly, but the latest update (02 May) removed that entry completely, and incorrectly listed its replacement. I'm a member of their Emergency Management Agency, so I know that Wauconda, IL Fire dispatch is still on 153.8900 (I'm listening to a tone-out as I type), and NOT on 155.6550.

This particular change may occur sometime in the future, but shouldn't the database accurately reflect what's actually in use, right now, at this point in time?

Perhaps the source of the information could be included with the description of change, or include the ticket number and make the that database available; that way someone with questions could contact the original submitter for further info.

Your best bet is to directly contact the DB Admin who processed the submission. You can find that in the Change History on the Downloads and Reports tab. Or, if you can't figure out who processed the change, make a submission explaining the error and asking that a DB Admin contact you if they need to hash it out.

It's not likely that the source of the info will ever be made publicly available, or the content of the submission itself. Especially considering a lot of these submissions are made anonymously (although the DB Admins can always see who made the submission), and the submissions often contain names and email addresses, or other info that might not be fit for public consumption.

Work out any issues you have with the DB Admins, that's what we're here for. Yes, there is the potential for "submission wars" when two people believe they are correct but have conflicting information. In that case, there is often one or two other locals in the area we would contact to figure out what is really going on.

 

[hfxChris]

One thing I've done before when I get conflicting submissions and I can't personally verify the information is post in the appropriate regional forum asking for input and consensus. If ten different people reply saying A is correct and nobody backs up B, then I think I know the answer.

 

[GTR8000]

One thing I've done before when I get conflicting submissions and I can't personally verify the information is post in the appropriate regional forum asking for input and consensus. If ten different people reply saying A is correct and nobody backs up B, then I think I know the answer.

Yup, that too. The first thing I generally do is look at the submission history for the area and see if there's a local or two with a solid submission history, and I'll check with them. If that doesn't work out for whatever reason, I'll take it to the forums.

 

[K9DAK]

Thanks!

Your best bet is to directly contact the DB Admin who processed the submission. You can find that in the Change History on the Downloads and Reports tab. Or, if you can't figure out who processed the change, make a submission explaining the error and asking that a DB Admin contact you if they need to hash it out.

...

Work out any issues you have with the DB Admins, that's what we're here for. Yes, there is the potential for "submission wars" when two people believe they are correct but have conflicting information. In that case, there is often one or two other locals in the area we would contact to figure out what is really going on.

OK, will do. Thanks for the advice!