RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Site Administration Forums > Database Discussion Forum

Database Discussion Forum - This forum is for questions about the database such as how to use it, layout or usability issues or suggestions for improvement. It is not for pointing out wrong information or getting help with programming.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 06-11-2017, 2:51 PM
madrabbitt's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2004
Location: NM
Posts: 455
Default "location" information in the database license area.

To simplify what I dont understand:

My 536 has a favorite group set to the county i'm working in and surrounding areas.
(conventional) systems in that group which SHOULD be active based on GPS of where I am (my range is typically set to 25 miles) is not showing local systems as active.

When i look at location information in the scanner for those systems, its showing a GPS location and range far outside what it should be.

I have discovered that the city/county has about 7 active licenses. Each of those licenses covers pretty much the same frequencies, and multiple transmitter locations.
I am aware that there are mountaintop repeaters across the county, all or most of them are simulcasting the same frequencies.


I was able to manually change the GPS info and range in my scanner to properly reflect what the system is doing in the "real world" which may or may not be correct in some of the ULS listings.

My question is, what do I need to put in my submission to update the database so that others dont have to do the same thing?

Where does that "location" and "range" data come from between the RR database and the uniden updates?

Would it be as simple as finding which ULS listing has the current frequencies listed to the correct locations, and submitting that license to the database, and advise that previous ones are incorrect or depreciated?
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 06-11-2017, 3:59 PM
Spitfire8520's Avatar
Member
   
Join Date: Jun 2009
Location: Colorado
Posts: 1,461
Default

The Database Administrator Handbook has a section covering Geographic Tagging. What should be happening is that most categories in the database should have location and range data that covers the entire "service area" such as city or county boundaries, not radio coverage.

The exception to this is trunked sites where site location should be where the site is located and range is a rough approximation of the radio coverage.

Quote:
Originally Posted by madrabbitt View Post
My question is, what do I need to put in my submission to update the database so that others dont have to do the same thing?
Most admins use something like Google to find coordinates and then roughly draw a range to cover the area. This can frequently be incorrect as Google tends to give coordinates that are not the true center point of an area.

If you know the location data is incorrect, you can make a submission with more accurate coordinates and range that covers the area. I have done this several times, but this really depends on the willingness of the admin handling the submission to make the correction.

Quote:
Originally Posted by madrabbitt View Post
Where does that "location" and "range" data come from between the RR database and the uniden updates?
All the location data comes from RadioReference. They are directly tied into each category/subcategory listings found when you look at the database. You will notice an arrow pointing to the right of each category/subcategory where you can see specific coordinates and range data that is currently in the RadioReference Database.

Quote:
Originally Posted by madrabbitt View Post
Would it be as simple as finding which ULS listing has the current frequencies listed to the correct locations, and submitting that license to the database, and advise that previous ones are incorrect or depreciated?
Just pointing to ULS information is not sufficient for most cases due to the "service area" requirement. It might be useful for trunked sites if the ULS information is accurate.
__________________
Mile-High Spitfire
RadioShack Pro-106 RadioShack Pro-652 RTL-SDR
MNN-250

Last edited by Spitfire8520; 06-11-2017 at 4:04 PM.. Reason: Afterthought stuff.
Reply With Quote
  #3 (permalink)  
Old 06-11-2017, 4:25 PM
madrabbitt's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2004
Location: NM
Posts: 455
Default

Thanks. That answers a lot of what I needed.
The database admin for this state has been pretty responsive to all my submissions, so I'll get in contact with them to update the location of the primary site of this system, which should fix the issue.

Basically, the fact that it is a HUGE county by land area, even a 50 mile radius from the center of the county would not cover the two populated juristictions in the county.
Reply With Quote
  #4 (permalink)  
Old 06-12-2017, 8:05 AM
DaveNF2G's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Jan 2001
Location: Rensselaer, NY
Posts: 8,202
Default

I believe this might be further complicated on the insistence on using town names for site locations rather than the actual tower sites, which might be near the town center only coincidentally. Some sites have mailing addresses that are not the same as the actual town in which they sit.

If the radius is centered on the town center, and the tower is at the edge of town, this could create some boundary ambiguity in one direction. It's a good thing RRDB does not deal with elevation under the circumstances.
__________________
David T. Stark
NF2G WQMY980 KYR7128
Wondering whether realpoo would be better than shampoo...
Reply With Quote
  #5 (permalink)  
Old 06-12-2017, 12:36 PM
wa8pyr's Avatar
Technischer Guru
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Location: Ohio
Posts: 3,522
Default

Quote:
Originally Posted by Spitfire8520 View Post
The Database Administrator Handbook has a section covering Geographic Tagging. What should be happening is that most categories in the database should have location and range data that covers the entire "service area" such as city or county boundaries, not radio coverage.

The exception to this is trunked sites where site location should be where the site is located and range is a rough approximation of the radio coverage.
It's actually a bit more involved than that for sites in a multi-site trunked system as terrain and surrounding sites have to be taken into account also.

The preferred default for sites in a multi-site trunked system is around 15 miles, but a tower site can be heard quite a distance farther due to elevation and variations in receiving antenna, so using a rough approximation of radio coverage can lead to too much signal attenuation at the edges of that range. The range setting in the database needs to be tweaked in order to avoid both excessive loss of signal at the edges as well as excessive overlap with adjacent sites; this sometimes takes a bit of trial-and error to get right.

On the other hand, a trunked system (single or multi site) owned and used by a single licensee such as a city uses the standard range setting based on the geographic center of the city, with a range sufficient to cover to the edges of the city and no farther.
__________________
Tom Swisher, WA8PYR
Lead Database Administrator
PSR500/Pro197/Pro2035+OS535/BCD436HP/TRX-1

If I PM you about a submission, please reply promptly or your submission may be rejected.
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 06-12-2017, 12:58 PM
troymail's Avatar
Member
   
Join Date: Dec 2002
Location: Supply, NC
Posts: 6,480
Default

Over time, I've found many location data entries in the RRDB to be incorrect. Most times, the admins accepting submissions apply various defaults to the data in terms of location because none was supplied with the submission.

This location data is also applied to "departments" (groups of talkgroups) as well.

The combination of the two will really cause havoc if the submitted data (or lack thereof) is wrong.

Just like with frequencies, the ULS data is only a "tool" and is also usually error prone. Just like with frequencies and other data, you shouldn't submit ULS data as gospel until you've done a bit of verification that the center point/location is correct. The range/radius is a bit more subjective since that isn't on the license anywhere and is based on many factors to include terrain, power of the transmitter, radiation pattern of the signal (they aren't all a big circle anymore).

And of course, keep in mind that simulcast systems will show multiple towers for a single site. In these cases, the centerpoint needs to be estimated over the entire set of tower locations.

EDIT: forgot to mention - for my area, I've submitted many updates to system and site location data. The local admin here has done a great job making the changes.
__________________
Unication G4
TRX-2,TRX-1,WS1098,1088x2,1095,1080, PSR800x2,500,PRO96
BCD536,436,396T,BC296D,245XLT,600XLT,IV,VX-8R,MD-390
Not a Radio Shack fan.....
Reply With Quote
  #7 (permalink)  
Old 06-12-2017, 2:00 PM
Spitfire8520's Avatar
Member
   
Join Date: Jun 2009
Location: Colorado
Posts: 1,461
Default

Quote:
Originally Posted by troymail View Post
And of course, keep in mind that simulcast systems will show multiple towers for a single site. In these cases, the centerpoint needs to be estimated over the entire set of tower locations.
This topic has actually puzzled me for sometime since the Handbook does not cover simulcast. I think that the centerpoint makes the most sense, but the Handbook states that it should be the actual location of the site. In some cases, using any of the individual site locations puts it on a far corner of the simulcast area and makes it difficult to put a correct range circle.
__________________
Mile-High Spitfire
RadioShack Pro-106 RadioShack Pro-652 RTL-SDR
MNN-250
Reply With Quote
  #8 (permalink)  
Old 06-12-2017, 2:16 PM
troymail's Avatar
Member
   
Join Date: Dec 2002
Location: Supply, NC
Posts: 6,480
Default

Quote:
Originally Posted by Spitfire8520 View Post
This topic has actually puzzled me for sometime since the Handbook does not cover simulcast. I think that the centerpoint makes the most sense, but the Handbook states that it should be the actual location of the site. In some cases, using any of the individual site locations puts it on a far corner of the simulcast area and makes it difficult to put a correct range circle.
You need to think beyond what you currently view as a "site".

Remember - a "site" doesn't always mean/equate to one "tower" or "transmitter". For standalone (single tower) "sites", they are probably the same. However, "simulcast sites" typically are comprised of multiple towers/transmitters that are spread out over and area.

In my area, the state system is made up of a mixture of stand-alone and simulcast (multiple tower) sites. Many of the towers for the state system sites are not even identified on licenses as they are licensed under a state 700 Mhz license.

There are several county level systems in my area that are also simulcast and are broken into two different "simulcast sites" -- a couple are "north county" and "south county" simulcasts - there is another that is "east" and "west". In each of these cases, each "site" has multiple towers/transmitters.

Baltimore City is a single "simulcast site" that has at least 6 tower/transmitter locations that all are part of the same "simulcast site". In that case, the "site" is the entire city.
__________________
Unication G4
TRX-2,TRX-1,WS1098,1088x2,1095,1080, PSR800x2,500,PRO96
BCD536,436,396T,BC296D,245XLT,600XLT,IV,VX-8R,MD-390
Not a Radio Shack fan.....
Reply With Quote
  #9 (permalink)  
Old 06-12-2017, 2:23 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 538
Default

Quote:
Originally Posted by DaveNF2G View Post
I believe this might be further complicated on the insistence on using town names for site locations rather than the actual tower sites, which might be near the town center only coincidentally.
No one is "insisting" that this be done, so that assertion is false.

Just because you know a site by the local name "Snake Hill" doesn't mean everyone else does. One of the rules of the database is that it shouldn't be tailored to appeal just to locals, but to everyone. Therefore, giving a site a name that can be universally recognized is generally preferred over using an obscure name that only people from the area would be familiar with. There is a place within the site details to add information such as the specific site location, etc.


Quote:
Originally Posted by troymail View Post
Over time, I've found many location data entries in the RRDB to be incorrect. Most times, the admins accepting submissions apply various defaults to the data in terms of location because none was supplied with the submission.
Actually, most admins don't do anything to apply various defaults; the geodata generally inherits whatever the higher level is that has geotags. So a conventional subcategory that has no individual geotags would default to the County level geodata; a trunked system site or subcategory would default to the System level geodata; and so on.

Yes, it's important for admins to pay attention to the geodata when adding agencies, sites, conventional subcategories, talkgroup subcategories, etc. However it's often not anything specific that the admin is doing, rather it's the lack of adding any specific geodata that causes an automatic inheritance of less than ideal defaults.


Quote:
Originally Posted by Spitfire8520 View Post
This topic has actually puzzled me for sometime since the Handbook does not cover simulcast. I think that the centerpoint makes the most sense, but the Handbook states that it should be the actual location of the site. In some cases, using any of the individual site locations puts it on a far corner of the simulcast area and makes it difficult to put a correct range circle.
The Handbook doesn't need to explicitly cover how to geotag simulcast cells, since a simulcast cell is merely a single logical site comprised of multiple subsites. You treat it as you would anything else you're geotagging, which is to set the centerpoint and range so that it encompasses the intended coverage area.

Quote:
6.3.9. SITES

Simulcast zones/layers shall be represented as a single logical “site” in the RR database.
Quote:
6.6. GEOGRAPHIC TAGGING

Geographic tagging of trunked system sites is used to indicate the location of the site and the approximate coverage area of the site (represented by a circle centered on the site). Since actual coverage areas are typically not exact circles, you shall approximate the coverage area by including the entire intended coverage area even if this means including extra area.

Geographic data (latitude, longitude and radius) shall be assigned to conventional frequency subcategories, talkgroup categories and trunked system sites.
Reply With Quote
Sponsored links
  #10 (permalink)  
Old 06-12-2017, 2:48 PM
Spitfire8520's Avatar
Member
   
Join Date: Jun 2009
Location: Colorado
Posts: 1,461
Default

Quote:
Originally Posted by GTR8000 View Post
The Handbook doesn't need to explicitly cover how to geotag simulcast cells, since a simulcast cell is merely a single logical site comprised of multiple subsites. You treat it as you would anything else you're geotagging, which is to set the centerpoint and range so that it encompasses the intended coverage area.
It appears to be open to interpretation by individual admins, which is why I am looking for explicit clarification. I have previously run into an admin that refused to use the centerpoint of a simulcast because it was not "the actual site location" even though it better represented the intended coverage area.
__________________
Mile-High Spitfire
RadioShack Pro-106 RadioShack Pro-652 RTL-SDR
MNN-250
Reply With Quote
  #11 (permalink)  
Old 06-12-2017, 2:57 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 538
Default

That should not be something that is open to interpretation. If an admin refuses to properly set the location and range for a simulcast cell, then they were in the wrong.

If you have an issue like that where you feel the local admin is in the wrong, and are unable to work it out to a satisfactory resolution, contact Lead Database Admin Tom Swisher (wa8pyr) with your grievance so that it can get sorted out.
Reply With Quote
  #12 (permalink)  
Old 06-12-2017, 3:06 PM
wa8pyr's Avatar
Technischer Guru
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Location: Ohio
Posts: 3,522
Default

Quote:
Originally Posted by GTR8000 View Post
No one is "insisting" that this be done, so that assertion is false.

Just because you know a site by the local name "Snake Hill" doesn't mean everyone else does. One of the rules of the database is that it shouldn't be tailored to appeal just to locals, but to everyone. Therefore, giving a site a name that can be universally recognized is generally preferred over using an obscure name that only people from the area would be familiar with. There is a place within the site details to add information such as the specific site location, etc.
The procedure in Ohio has for years been to list the "official" name of the site (as it's known to the system), and if that varies from the actual physical location, to put the name of the physical location in parenthesis following the official site name. This serves to prevent confusion when service techs and others refer on air to a site using the official name, while still giving the actual physical location to those with enquiring minds.

This is one of the alterations I'm working on for the administrator handbook.

As regards simulcast sites as mentioned in other previous posts, simulcast sites are among those considered a single "site" which are to use the geographic center of the affected city or county as the GPS location, with a range that goes only out to the edge of that jurisdiction, and no farther. The Baltimore City site mentioned earlier is a good example; the range should cover only the limits of the City of Baltimore, but not any more of Baltimore County than necessary.
__________________
Tom Swisher, WA8PYR
Lead Database Administrator
PSR500/Pro197/Pro2035+OS535/BCD436HP/TRX-1

If I PM you about a submission, please reply promptly or your submission may be rejected.

Last edited by wa8pyr; 06-12-2017 at 3:10 PM..
Reply With Quote
  #13 (permalink)  
Old 06-12-2017, 3:27 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 538
Default

Quote:
Originally Posted by wa8pyr View Post
The procedure in Ohio has for years been to list the "official" name of the site (as it's known to the system), and if that varies from the actual physical location, to put the name of the physical location in parenthesis following the official site name. This serves to prevent confusion when service techs and others refer on air to a site using the official name, while still giving the actual physical location to those with enquiring minds.

This is one of the alterations I'm working on for the administrator handbook.
Reply With Quote
  #14 (permalink)  
Old 06-13-2017, 8:45 AM
DaveNF2G's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Jan 2001
Location: Rensselaer, NY
Posts: 8,202
Default

Quote:
Originally Posted by wa8pyr View Post
The procedure in Ohio has for years been to list the "official" name of the site (as it's known to the system), and if that varies from the actual physical location, to put the name of the physical location in parenthesis following the official site name. This serves to prevent confusion when service techs and others refer on air to a site using the official name, while still giving the actual physical location to those with enquiring minds.

This is one of the alterations I'm working on for the administrator handbook.
Excellent. Let's make that the procedure in New York as well, pending a revised handbook.
__________________
David T. Stark
NF2G WQMY980 KYR7128
Wondering whether realpoo would be better than shampoo...
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 9:10 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions