"location" information in the database license area.

[madrabbitt]

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?

 

[Spitfire8520]

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.

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.

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.

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.

 

[madrabbitt]

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.

 

[DaveNF2G]

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.

 

[wa8pyr]

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.

 

[troymail]

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.

 

[Spitfire8520]

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.

 

[troymail]

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.

 

[GTR8000]

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.

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.

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.

6.3.9. SITES

Simulcast zones/layers shall be represented as a single logical “site” in the RR database.

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.

 

[Spitfire8520]

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.

 

[GTR8000]

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.

 

[wa8pyr]

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.

 

[GTR8000]

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.

 

[DaveNF2G]

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.