RadioReference.com 3.0 Alpha 1 Release

[owenmcc1]

I Like it, I say you should keep this! haha

 

[Tim-in-TX]

Love the new look! Can't wait until it is the standard.
I know that there are still plenty of "bugs" to work out...some you know of, others that you don't. The only error I have found so far is that, on the clickable map, Brazoria Co. is mislabeled as Bowie Co. and it links to Bowie as well. Other than that, the site is awesome!

 

[jgarber311]

Looks good, but what's with the porn advertisements? That's gotta go!

 

[Stick0413]

Looks good, but what's with the porn advertisements? That's gotta go!

??? I dont have any porn advertisments.

 

[Caesar]

i already miss the ugly white page of the current RR.com, lol but i am loving the new site so far..

 

[landonjensen]

:lol:

Looks good, but what's with the porn advertisements? That's gotta go!

 

[loumaag]

Please people, you are just feeding the problem.

 

[jpm]

lake and lasalle counties are backwords on the press the county in the state radio reference. Lake county is north of cook not south.

 

[loumaag]

In regard to:

lake and lasalle counties are backwords on the press the county in the state radio reference. Lake county is north of cook not south.

And other such comments, please see this post in this thread (back on page 4) where Lindsay says in part:

Folks, I am aware of the mapping inconsistencies...

 

[lesh12]

Maps are great, keep up the good work.

 

[tomdog2561]

Awesome

Fine work on the beta website. Kudos to your group for the improvements.

Tom-K0RVR

 

[kd4bas]

FYI I have noticed that some of the updated counties & states show updates on the older version but not the beta version. FYI

 

[BaLa]

FYI I have noticed that some of the updated counties & states show updates on the older version but not the beta version. FYI

I believe..
The Beta DB was only done once when converted.

Prolly just gonna fine-tune it, then switch to the new site completely.

 

[Bandingabout]

I felt the selected site icon was "THE" one immediately. RR is all good, useful. Kudos to everyone, always. Now, about that 2XX pocket tee?

 

[fireman_dude]

Very nice interface ! Looks great !

 

[KM4WLV]

Dammit man!!! Awesome, just freaking awesome. You guys are always on top of things, keep up the good work!!!!

 

[ricco]

Ok I only have 3 words for the new beta:
I LOVE IT!!!!!

 

[Dave_D]

Don't forget that many new submissions for this release when it goes to production will also center around location based data... for frequency subcategories, trunked system sites, and talkgroup categories, we'll be able to set lat/long/range for each of those.

God bless you!!! I am so all over this and will gladly test the heck out of these features for you w/ my trusty BCT15. I have tons of location data for Nevada and California Highway Patrol, just waiting for a good home. Some questions relating to location-based scanning data:

1. Will the RR database use location data to describe reception area (e.g., maximum useful distance from a transmitter) or application area (e.g., agency boundaries, county boundaries)? These are very different applications for location data, being that one is inclusive (demands a maximum range) while the other is exclusive (encourages a minimum range to define as closely as possible the application area). I recommend that RR standardize on one or the other, or support both in separate fields. Otherwise, you'll have confusing data and users fighting for the maximum distance vs. the minimum application area.
2. Will the database support multiple locations per frequency/system/category? This would alleviate most problems I've encountered when mapping systems to their respective counties, for example. Best of all, if these locations are exported, third-party developers (e.g., Butel) can automagically duplicate an entire system into each location. The alternative (the state of the art as we know it) is to manually copy systems for each geographic location; a nightmare. This RR feature, alone, would significantly improve location-based scanning. FWIW, this presumes support of application areas, per #1, above.
3. Might location data be assigned to counties? This way, every agency/site in the county without location data of its own could automatically default to the county boundaries. Afterall, you've gone to all this effort of organizing systems and agencies into counties; why not use this information?! This sorta presumes that multiple locations are supported, as described in #2, above, and that application areas are supported, per #1.

Thank you for everything! I hope this input is helpful and look so forward to playing with these location-based features! Thank you, thank you, thank you!!!

 

[UPMan]

Looking great (and the above 3 questions are some I've been mentally grappling with, as well). The "range" rule might need to depend on exactly what you are mapping. For a system (or agency) that covers a single geopolitical entity, I'd favor limiting the range to the smallest that would completely encompass that entity, and no larger. Personally, I'm doing what you are doing and approximating the shape of an entity by using multiple circles of various sizes...but rather than doing that it might be better to, as an enhanced layer in addition to the "big circle" approach, use an irregular polygon to delimit each agency's effective geopolitical area. Granted, no scanner (yet) could use the data this way, but I could see PC-driven apps that would be able to do this (and, who knows, if the data was there, perhaps a scanner would follow).

However, for site ranges on multi-site systems (like state-wide system), I'd favor using the estimated usable range approach (as sites on such systems are not necessarily tied to a single geopolitical entity).

One suggestion for newbie usability: Make the "System Type" a hot-link to the wiki page that describes that type of system; ensure that the wiki pages describing system types also list which scanners support that kind of system.
Like:

System Name: Abilene
Location: Abilene, TX
County: Taylor
System Type: EDACS Standard
System Voice: ProVoice and Analog
Last Updated: Changed talkgroup category names
Hits: 870

 

[blantonl]

Dave,

1. Location data will be application based, not reception based. This will be the policy going forward, and the database will provide the administrators a number of tools to manage this process.

2. The database will not at this time support multiple location based information entries for frequencies etc. Currently, we will provide location based information for trs sites, talkgroup categories, and frequency sub-categories.

3. Location data will be assigned to counties, and will become the "inherited" default for frequency subcategories when subcategories are not tagged specifically with location data.