GPS data in the rr database for simulcast systems

[c5corvette]

Do you use the GPS feature at all on any of your scanners?

I am just starting to get into location based scanning and have a question about RR database and geotagging.

I will uses two particular trunked systems from the county where I live in Virginia for my question...

In a system like Fairfax county where multiple transmitters are simulcast someone has arbitrairily picked a single GPS coordinates / range and submittied that to the db. Its fair to say they guessed at the cented of the coverage area of all the simulcast sites. When I go to download via what ever software I am using to program my scanner, if I select the software to download the GPS scanning data, assumingI like the data from the db I can use that for my circle of reception (or i can edit it.)

However, for a system like Metropolitan Washington Airport Authority, also a simulcast system, no one has attached any coordinates info - and it has just dawned on me why. It is a realitively low range system operationally - mostly within the confines of the airport, but it operates in two distinct locations seperated by large space inbetween (ie. the two different airports, Regan National and Dulles International.) However, after thinking about GPS scanning for a couple days now, it occoured to me that I could still set this up by creating two exact sites under the same system, instead of one, and having each site with the specific coordinates for the two different airports. Further though this thought process, I was wondering how this type of situation could be added to the RR database so that a system with a single simulcast site could have 'optional sets of coordinates' attached to it so that if you were downloading GPS scanning data via some programming software that it would automatically create the additional site(s) for you (but this wouldnt be a visible site when looking at the site data and frequencies on the RR db online.)

Specifically right now I am using a 996T for GPS scanning and I can manually set this up if I want to, but am wondering if it can be accomplished in the database.

Next, I am wondering how GPS scanning works for the Home Patrol - what data does the db tranfer to HP-1 to know to scan that site without GPS coordinates being recorded in the db? Does the HP-1 scan by coordinates from the db first and then revert to county heirachy from RR data (by some magic manipulation by someone behind the scenes with the weekly db updates) or would I just not hear anything that wasn't geocoded in the db if I hooked GPS to an HP-1? How does it work???

Any admins that use GPS scanning have any thoughts on this topic and my questions?

 

[loumaag]

I will try and answer briefly what is done on our end.

Simulcast sites are all lumped under one site ID, because that is the intention of the simulcasting. A center point is picked for the intended coverage area of the sites and then a radius is applied that includes that intended coverage area. On systems that have a single simulcast site (in other words not multiple sites and a simulcast set) sometimes the site does not get a different geo-tag than the system; sometimes it does. It depends on a few factors, like when it was done, who did it, etc. You are mistaken in reference to the Washington Metropolitan Area Transit Authority TRS. It does have geo-data, which can be plainly seen on the site data page. I will grant that it is inheriting that from the system geo-data (not something you can see) but it is there.

What Uniden does, is download the DB as it is, including the available geo-data and then how the HP-1 DB is assembled I have no idea; however, I do know that if no geo-tag data is available at all, the HP-1 ignores the system. I am not aware of any system that does not have at least inherited data at this time (although there were some when the HP-1 first came out.)

 

[c5corvette]

You are mistaken in reference to the Washington Metropolitan Area Transit Authority TRS. It does have geo-data, which can be plainly seen on the site data page.

Thanks for the info Lou...

It is not WMATA, I was referring to MWAA -- very different. The system / site I am looking at that has no site location info is Simulcast Site Details (Metropolitan Washington Airports Authority)

If there is "inherited data" for the MWAA simulcast site, I would like to find out what it is so I can know what behavior to expect from my the HP-1?

I am hesitant to make addition to the db since I would want to make two different entries, one site is located at IAD 38.9474444 / -77.4599444 with a range of about 5 miles and the other at DCA 38.8520833 / -77.0377222 with a range of about 8 miles. (There are actually more sites than these two, but for example I dont want to complicate things.)

Any more info appreciated.

 

[loumaag]

...
Any more info appreciated.

Thanks for the clarification and sorry for the delay in responding, sometimes real life gets in the way of important stuff.

Okay, based on what your link and the license information (which has a problem) and the actual locations I have added a location for the system. You were correct, it did not have a location set and as I said, there were several before that did not. We thought we had at least set one for each system, obviously there are holes in our thought pattern. :roll:

In any case now that the system has one, the center point really could not be extracted from the license, and it covers the whole area from Dulles to Reagan and I managed to do it only using a 12 mile radius.

 

[c5corvette]

Thanks for the clarification and sorry for the delay in responding, sometimes real life gets in the way of important stuff.

Okay, based on what your link and the license information (which has a problem) and the actual locations I have added a location for the system. You were correct, it did not have a location set and as I said, there were several before that did not. We thought we had at least set one for each system, obviously there are holes in our thought pattern. :roll:

In any case now that the system has one, the center point really could not be extracted from the license, and it covers the whole area from Dulles to Reagan and I managed to do it only using a 12 mile radius.

Lou, help me understand what data the HP-1 uses in its auto download compared to when I import data into my 996 using software and RR import features.

I just noticed when I did an import this morning from RR to my 996T that one county with data imported and others with data didn't...

Simulcast Site Details (Fairfax County Public Safety) < imported the exact coordinates and range shown on this screen

850 MHz Simulcast Site Details (Washington, DC) < didnt import the data to my 996T

Simulcast Site Details (Metropolitan Washington Airports Authority) < didn't import the data to my 996T

 

[loumaag]

Lou, help me understand what data the HP-1 uses in its auto download compared to when I import data into my 996 using software and RR import features.

I just noticed when I did an import this morning from RR to my 996T that one county with data imported and others with data didn't...

Simulcast Site Details (Fairfax County Public Safety) < imported the exact coordinates and range shown on this screen

850 MHz Simulcast Site Details (Washington, DC) < didnt import the data to my 996T

Simulcast Site Details (Metropolitan Washington Airports Authority) < didn't import the data to my 996T

I will try and you have pointed out a couple of problems that need addressing, one for us, one for whoever builds your software.

Since the Fairfax Co. entry has geo-tag data for both the system and the site, it was expected that you got it on the download.

In the case of the Metropolitan Washington Airports Authority, this is the one I fixed yesterday by establishing the system's geo-tag. I did not establish the same geo-tag for the single site, which is all right since there is only one site and it covers the exact same area as the system itself. This is where your software vendor is failing, it is only looking at the level of the site for geo-tagged information instead of going up one level. Inherited data in this instance should be considered.

In the case of the Washington, DC system, both the 850 MHz and the 460 MHz simulcast sites are inheriting their locations from the system as a whole, like the Metro Airport Auth, but here we have another problem. The system itself is inheriting its location from the District's geo-tag and this is a problem from our standpoint, one I will be fixing in a few minutes (note: I will not be fixing the site geo-tags since inherited data is acceptable from a schema standpoint in this instance.) I guess I am going to have to look at all of the systems listed in DC to see if it is a problem of wider scope since you have found two of them in as many days. Surprisingly, the HP-1 has this system in its DB, although I don't know what it has as geo-tag information.

 

[c5corvette]

Again, Lou, help educate me. You are referencing 'system' geodata and 'site' geodata.

I can only find GPS coordinates info in two places, on the "siteId" page and on the "fccCallsign" page. I assume its the 'system' that I can't find? Where can I see it?

I am trying to find the example with DC or MWAA where the simulcast site has data and the system doesnt?

Or I would like to see the FAIRFAX example where the simulcast site has the data and the system has the exact same data and range.

The 'fccCallsign' page doesnt have any range data so thats not what I am looking for. What am I missing here?

Thanks in advance,

 

[loumaag]

Again, Lou, help educate me. You are referencing 'system' geodata and 'site' geodata.

I can only find GPS coordinates info in two places, on the "siteId" page and on the "fccCallsign" page. I assume its the 'system' that I can't find? Where can I see it?

Well there is a problem, as the system level geo-tag is not visible to you at the system level. It is more of a back-end thing locating on a map for the use in downloading. Although you bring up a valid point, which I will address on the DB Admin channel here.

I am trying to find the example with DC or MWAA where the simulcast site has data and the system doesnt?

Or I would like to see the FAIRFAX example where the simulcast site has the data and the system has the exact same data and range.

The 'fccCallsign' page doesnt have any range data so thats not what I am looking for. What am I missing here?

Thanks in advance,

Well I didn't find one where the site had data and system didn't as of now, since I fixed some; however, here is one that has the wrong data at the site level. The system level, until just a few minutes ago did not have any data at all, now it is right but the site is wrong. I will leave it alone for a little bit, but I will shortly wipe out the site level data or at least fix it to the system level.

 

[c5corvette]

Lou:

According to the manufacturer of my software... he thinks you said that neither system had geotag information at the site level . He said "Since this is what the scanner needs, no information could be sent to it." I think he may be confused about which data he is capturing because both sites that didnt download anything had site data - that was my point, I didnt understany why it wasnt retrieving the data. That said...

1) So in the future when I download a system and it comes up empty with GPS data, should I assume I need to contact an admin.

2) Now that I know where the 996 is getting the geo-tag and range data, how do you admins decide the effective range for systems? Do you have a default per band or something like that and then tweak as you see fit? I think I am noticing a pattern, except on 800MHz.

3) Should there be a visual indicator to tell the RR user that this system has been geotagged by the admins or someplace we can see the data. Not sure this will happen or not, but it could be very confusing if I am looking in the DB and see different ranges for sites as compared to what downloads to my scanner.

4) Or maybe a new WIKI on how this works with the DB and GPS scanning.

Please reply,

 

[c5corvette]

However, now I am confused, did you fix the Wash DC Type II system yet. I just tried his import again and still got nothing on DC but got data when importing Fairfax Public Safety.

The site info for the DC system clearly has geo-tag data: 850 MHz Simulcast Site Details (Washington, DC)

 

[loumaag]

Lou:

According to the manufacturer of my software... he thinks you said that neither system had geotag information at the site level . He said "Since this is what the scanner needs, no information could be sent to it." I think he may be confused about which data he is capturing because both sites that didnt download anything had site data - that was my point, I didnt understany why it wasnt retrieving the data. That said...

Well, he is correct, that is exactly what I said, but what I also said is that systems that have a single site or even if they have two sites covering the exact same place (see the last response) may not have SITE level geo-tag data if the SYSTEM level geo-tag data would be exactly the same. So, in other words, we set the system geo-tag, if it is a single site system, we may not set the the site. Hence, the software needs to look up one level (to the system) if the actual site level data is not set since the site is inheriting the geo-tag from the system level.

1) So in the future when I download a system and it comes up empty with GPS data, should I assume I need to contact an admin.

No, no necessarily.

2) Now that I know where the 996 is getting the geo-tag and range data, how do you admins decide the effective range for systems? Do you have a default per band or something like that and then tweak as you see fit? I think I am noticing a pattern, except on 800MHz.

It is not effective range, but rather intended range or service area. In other words, consider that National Zoo system may have a much larger effective range than it needs. The intended range for the zoo would only encompass the zoo and a a small fudge area around it, because that is service area, the fact that you may hear it 5 miles away has no bearing on what we establish for the geo-tag area.

3) Should there be a visual indicator to tell the RR user that this system has been geotagged by the admins or someplace we can see the data. Not sure this will happen or not, but it could be very confusing if I am looking in the DB and see different ranges for sites as compared to what downloads to my scanner.

4) Or maybe a new WIKI on how this works with the DB and GPS scanning.

Please reply,

As for the visual data, no, not really because actually, they should all be set at this time. The fact that you are finding some that are incorrect or not set at all is a testament to the fact that we are human. Assume that they are all set, and let us know when we have failed.

However, now I am confused, did you fix the Wash DC Type II system yet. I just tried his import again and still got nothing on DC but got data when importing Fairfax Public Safety.

The site info for the DC system clearly has geo-tag data: 850 MHz Simulcast Site Details (Washington, DC)

You are only confused because you believe the vendor. That system is fixed, it is set at the system level and both sites (remember I mentioned that above) are inheriting the data from the system. If your 996 is not getting the data it is because the software is not looking up one level. Understand that only Uniden radios can do this geo-tag following, and the HP-1 (which at this point does not correctly use any third party software) has no problem with this scheme. The only failing the HP-1 has with geo-tag data is that since we have incorporated the national level stuff, it had a problem getting it in properly on the weekly download. I am not sure if that has been corrected yet. But, for example it has no problem dealing with the Washington system which only has geo-tag data set at the system level.

 

[KE5TLF]

Let's see you could have fixed ALL of this in about 5 minutes or you could argue about it for about 5 days....sigh...

You can easily see that even the very RR DB reports themselves don't even pull inherited data when looking at location data reports. I pointed ALL of this out long ago...This is the way it has always been. Programs don't pull from the "default" point/circle data, they never have. They pull data from the actual categories/sites. If there is nothing there, then that's what you get, nothing.

Washington, DC Talkgroup Category Location Data Report
Washington, DC Site Location Data Report
Metropolitan Washington Airports Authority Talkgroup Category Location Data Report
Metropolitan Washington Airports Authority Site Location Data Report

 

[c5corvette]

Let's see you could have fixed ALL of this in about 5 minutes or you could argue about it for about 5 days....sigh...

You can easily see that even the very RR DB reports themselves don't even pull inherited data when looking at location data reports. I pointed ALL of this out long ago...This is the way it has always been. Programs don't pull from the "default" point/circle data, they never have. They pull data from the actual categories/sites. If there is nothing there, then that's what you get, nothing.

Washington, DC Talkgroup Category Location Data Report
Washington, DC Site Location Data Report
Metropolitan Washington Airports Authority Talkgroup Category Location Data Report
Metropolitan Washington Airports Authority Site Location Data Report

I think Lou can tell you, I am not arguing - I am just trying to understand how things work.

So this is what the scanner software programs are looking at? Washington, DC Site Location Data Report

So how does this Washington, DC Site Location Data Report get updated?

 

[c5corvette]

I think Lou can tell you, I am not arguing - I am just trying to understand how things work.

So this is what the scanner software programs are looking at? Washington, DC Site Location Data Report

So how does this Washington, DC Site Location Data Report get updated?

According to the manufacturer of the software I am using, the above pages are where the software is looking for data... http://forums.radioreference.com/sc...downloading-system-site-type.html#post1621277

 

[DonS]

As Lou stated above, the software should test the location data in each site; if it's empty or invalid, the software should use the system's location data, if any.

I do note that when using the web service (version 8 or later) to retrieve the site data for sid=234, both sites do have location data set. That data is exactly the same as the system's location data; the sites are inheriting from the system. This "inheritance" appeared in version 8 (as documented in the web service revision history). Earlier versions will likely give empty or invalid data in the sites' location fields.

Here's what version 8 returns:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <getTrsSitesResponse xmlns="http://api.radioreference.com/soap2">
         <return>
            <item>
               <siteId>5254</siteId>
               <sid>234</sid>
               <siteNumber>1</siteNumber>
               <siteDescr>850 MHz Simulcast</siteDescr>
               <zoneNumber/>
               <zoneDescr/>
               <siteNeighbors/>
               <siteLocation/>
               <siteCtid>315</siteCtid>
               <siteCt>83.72</siteCt>
               <siteModulation/>
               <siteNotes/>
               <lat>38.89244</lat>
               <lon>-77.041374</lon>
               <range>7</range>
               <splinter>0</splinter>
              ...

EDIT: Of course, if using web service version 7 or earlier to retrieve the above data, the <lat>, <lon>, and <range> fields are all zero. This is because version 7 doesn't have the "sites inherit location from system" feature - the consuming software is expected to do it.

 

[c5corvette]

... if using web service version 7 or earlier to retrieve the above data, the <lat>, <lon>, and <range> fields are all zero. This is because version 7 doesn't have the "sites inherit location from system" feature - the consuming software is expected to do it.

Thanks - this has all been very very helpful.

I will also ask the software provider what version of the SOAP web service they are using.

Thanks,

 

[c5corvette]

Programs don't pull from the "default" point/circle data, they never have. They pull data from the actual categories/sites. If there is nothing there, then that's what you get, nothing.

Washington, DC Talkgroup Category Location Data Report
Washington, DC Site Location Data Report

In talking to the programs author, they arent sure what they are pulling. I am told there are 6 fields to work with but not sure which programs / authors use which fileds for what. That is what I need to find out next (in addition to what version of the web service each program author is using.)

You can easily see that even the very RR DB reports themselves don't even pull inherited data when looking at location data reports. I pointed ALL of this out long ago...This is the way it has always been.

Hasn't anyone else noticed this?

As a RR user you can run reports on the web for the following info:

• Frequency Subcategory - if no location data is specified for the frequency subcategory, then it inherits location data from the parent Agency or County. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Agency or County.)

• Trunked System SITE – if no location data is specified for the site, then it inherits the location data based on the county that it is located in. If no county is defined for the site, the site inherits the trunked system default location data. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Agency or the Trunked System.)

• Trunked System Talkgroup Category – if no location data is specified for the Talkgroup Category, then it inherits the location data based on the trunked system default location data. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Trunked System.)


Do reports exist to see location data for Agency, County or Trunk System? I can't find them!
If there is no way for a RR user to see reports on the web with location data for Agency, County or Trunk System - the reports that are available should at least show the 'inherit' location data or tell you there is location data that can be inheritied (or both) shouldn't they?

 

[loumaag]

...Hasn't anyone else noticed this?

As a RR user you can run reports on the web for the following info:

• Frequency Subcategory - if no location data is specified for the frequency subcategory, then it inherits location data from the parent Agency or County. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Agency or County.)

• Trunked System SITE – if no location data is specified for the site, then it inherits the location data based on the county that it is located in. If no county is defined for the site, the site inherits the trunked system default location data. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Agency or the Trunked System.)

• Trunked System Talkgroup Category – if no location data is specified for the Talkgroup Category, then it inherits the location data based on the trunked system default location data. (Unfortunately, I cant find any report that lets me confirm there is location data attached to the Trunked System.)


Do reports exist to see location data for Agency, County or Trunk System? I can't find them!
If there is no way for a RR user to see reports on the web with location data for Agency, County or Trunk System - the reports that are available should at least show the 'inherit' location data or tell you there is location data that can be inheritied (or both) shouldn't they?

There is nothing to notice. And, not to demean KE5TLF, but he has an extremely limited view of how the DB works.

Let me clarify, in case Don's excellent explanation was not clear. In regard to TRS geographical location data; it is the intention of the DB model that all systems have a geo-tag specifying the system's intended service area. A lack of this data would be considered an error from the DB model standpoint. In regard to site geo-tag data, if that data would be more helpful or explanatory than the default system data, it should be entered. An example of this would be on wide area type TRS's, regional or state-wide in scope. Please note, site geo-tag is optional, and not required by the DB model since sites inherit data from the level above.

It is similar in regard to Talk Group (TG) geo-tags. If no geo-tag is attached to a TG category then it inherits the TRS geo-tag. Please note, these inheritances do not actually place the data in the appropriate place in the DB, but rather it is the responsibility of the accessing entity (whether it be web page or programming software) to take care of this inheritance by being aware of the model.

To your specific questions about reports, no, there are no user level reports that would show if a TRS has geo-tagged data for the system as a whole. Just as there is none that would show it for an agency or county. A DB admin can tell (if he has the authority to look at that area) if those tags are set, but again, we are all human. When geo-tagging came to the DB, some default data was stored for counties and it was up to the DB Admins to sweep through there respective areas to tighten up that data, again, we are human, so some of it did not get done or was done improperly. In regard to TRS system geo-tags, they received a default (inherited) geo-tag of the county (default) if they only existed in one county. If they covered more than one county, then they got no default data. This specific instance is what you discovered in a couple of places in the DC area. Are there any more? I am sure, because we are only human.

 

[c5corvette]

In regard to TRS geographical location data; it is the intention of the DB model that all systems have a geo-tag specifying the system's intended service area. A lack of this data would be considered an error from the DB model standpoint. In regard to site geo-tag data, if that data would be more helpful or explanatory than the default system data, it should be entered. An example of this would be on wide area type TRS's, regional or state-wide in scope. Please note, site geo-tag is optional, and not required by the DB model since sites inherit data from the level above.

It is similar in regard to Talk Group (TG) geo-tags. If no geo-tag is attached to a TG category then it inherits the TRS geo-tag. Please note, these inheritances do not actually place the data in the appropriate place in the DB, but rather it is the responsibility of the accessing entity (whether it be web page or programming software) to take care of this inheritance by being aware of the model.

Lou, again very helpful. Thanks. The pieces are starting to come together - especially since I now know that the software I was using is on an old version of the RR Web Service that does not pull 'inherited' data.