Discovered the following once I purchased an HP-1.
I live in Virginia and practically whatever zip code I punch in, the HP-1 scans the conventional frequencies from the 'Chesapeake Bay Bridge Tunnel'. I assumed this was because the 'Chesapeake Bay Bridge Tunnel' was listed as a state agency in the RR database.
I promptly sent a submission to the RRDB asking them to remove it as a state agency and add it to the proper county.
My submission to the database was clear and concise. I asked that an entity be removed as a State Agency and entered in respective area of operation in the database within a city or county (where it could inherit proper location data.)
RR did not make any of the changes I submitted.
a) The 'Chesapeake Bay Bridge Tunnel' is not a state agency, it is legally considered by the Commonwealth as a local government. However, because it spans multiple counties, RR considers it a statewide agency. I think they are mistaken, if you following thier multiple county policy, I agree with what they are doing, but it needs to be in Virginia Areawide Frequencies not the Virginia State Agencies list.
b) Because it spans multiple counties, they will not add it to two counties.
RR stated 'Currently that agency has no lat/long/radius information so it will never show up in a geo-search.'
My response was 'If I am using an HP-1, no matter what zip code I am in (when scanning in Virginia) these frequencies show up in the scan rotation.'
RR said, 'This is an HP1 issue. In this case it must be seeing lat/long/radius of 0/0/0 and automatically converting it to a statewide lat/long/radius. It's not an RR data issue.'
RR finally suggested I simply submit lat/long/radius for the agency and they will tag that frequency subcategory with the proper information. I have since submitted appropriate lat/long/range of 37.034, -76.065, 12 miles that hopefully is appropriate.
However, it appears to me that RR is quick to blame these things on a specific scanner, since the RRDB admin guide is clear to say they should not manipulate the database just to work with a specific scanner.
1) This is unfair just because the RR User happens to explain their example in detail with the model of their scanner.
2) With the advent of Uniden’s location based scanning and RR’s storing of lat/long/range data – I think RR is obligated to make sure the data works right with any location based capable scanner (not a specific scanner.)
I am hoping that by adding subcat lat/long/radius info I submitted that the HP-1 will pick up the correct coordinates.