Request for Comments - RadioReference Web Service

[jemassey]

The following is returned when retrieving sid=793 (Surry Nuclear Power Station in Surry county Virginia):

<?xml version="1.0" encoding="utf-8"?>
<!--
comments snipped for brevity
-->
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /home/radioref/public_html/apps/xml/index.php:264) in <b>/home/radioref/public_html/apps/xml/index.php</b> on line <b>263</b><br />
<?xml version="1.0" encoding="utf-8"?>
<!--
comments snipped for brevity
-->
<error><auth>Access Denied - System Information Restricted due to policy.</auth></error>

Joe

 

[loumaag]

The following is returned when retrieving sid=793 (Surry Nuclear Power Station in Surry county Virginia)

My guess is that you need to allow for systems you cannot access. That systems information was removed from access, see this link:
http://www.radioreference.com/modules.php?name=TRSDB&sid=793

 

[blantonl]

Yes, but he shouldn't be seeing invalid XML returned. I fixed the issue, I was sending the headers twice for restricted information.

Lindsay

 

[DonS]

Yes, but he shouldn't be seeing invalid XML returned. I fixed the issue, I was sending the headers twice for restricted information.

Are there any other cases where we'll see an <error><auth> message? I had removed my handling of those tags, instead handling only HTTP error 401.

I've added back handling for <error><auth>, but my message box text is incorrect. I display the PCDATA for the <auth> element, but also tell the user his username/password might be incorrect. I'm wondering about other causes for <auth> errors, so that I can parse the PCDATA correctly and give a more correct error display to the user.

Maybe this shouldn't be an <auth> element, at all. Instead, how about some other child of the <error> element (or perhaps PCDATA for the <error> element itself) ?

-Don

 

[paul34]

See the BC246T topic for an application note for a utility that uses this function: I think this link will take you there!

 

[DonS]

See the BC246T topic for an application note for a utility that uses this function: I think this link will take you there!

Not sure what that's saying (though I'll admit I didn't read the whole thread that closely, nor did I download any code that might be there). A bunch of us on this thread have apps that are reading and parsing the XML data. Does that thread add something extra?

 

[UPMan]

It adds info about a working app that reads and parses the XML data then exports it in UASD format.

 

[jemassey]

I noticed that sid 180 returns invalid XML. It has several   elements in it.

Joe

 

[blantonl]

Ok, wrote an updated text preprocessor to fix these invalid XML issues. fixed.

 

[blantonl]

Are there any other cases where we'll see an <error><auth> message? I had removed my handling of those tags, instead handling only HTTP error 401.

Yes, for non donating users, they will be authenticated but not authorized.

And for restricted systems.

 

[jemassey]

Now I'm getting the following for ctids. This is for ctid=41 but seems to apply to all counties with TRS's.

<?xml version="1.0" encoding="utf-8"?>
<!--Version 0.92b
snip
-->
<county_trs_result><br />
<b>Fatal error</b>:  Call to undefined function:  proc_texts() in <b>/home/radioref/public_html/apps/xml/index.php</b> on line <b>179</b><br />

Joe

 

[blantonl]

ooops!

 

[DonS]

Caching?

I've noticed a weirdness when switching between a contributing and non-contributing RR membership...

I first retrieve countries, states, counties, and systems with a non-contributing username. I then try to get a specific TRS, and get an <auth> error (as expected).

I immediately change the username/password to a contributing membership, and try to get the TRS again. I still get the <auth> error.

I've verified that the HTTP headers contain the new, contributing membership data.

If I wait a bit (a minute, or so), the contributing membership works again. It seems as if somebody is caching the response. It's not happening anywhere on my LAN (I've verified the outgoing/incoming data with a sniffer between my firewall and DSL bridge), and I don't believe my ISP is doing it.

Does the RR server cache responses, ignoring the auth header, for a brief period?

EDIT: IGNORE THIS. I must've messed up the sniffing operation mentioned above. It appears my local machine is doing the caching. The "failing" operation (second try, with contributing membership) does not result in any packets hitting the wire. I've fixed it by disabling local caching for these requests.

-Don

 

[DonS]

Talkgroup organization

How about organizing the talk groups in a manner similar to the sites? Instead of a non-hierarchical list, each with its own "group" attribute, a higher-level <group> element which then encloses the group's <tg> elements might be more intuitive for the end-user. I'm thinking of an XML representation of the RR DB's UI, guessing that the user will want to select IDs for import based on geographic location or usage, without having to search through the (currently) "dec"-sorted list.

Sure, it could be done in code on our end, but the parsing (to find unique group names), sorting, and organizing gets pretty ugly. How is the DB currently organized? A "dec" -indexed table of IDs, each with its own group attribute? Or a hierarchy like the current web display shows?

I think this would also shrink the size of the raw XML data (since each group name is present only once, instead of duplicated in each talkgroup in the group); for systems like the Michigan MPSCS, the difference could be quite significant.

I'm thinking of something like:

<talkgroups>
  <group name="Ogemaw County (65)">
    <tg dec="1389" subfleet="" desc="Central 9-1-1 Police - Dispatch" disp="65P911" mode="D" tgid="106815" />
    <tg dec="1390" subfleet="" desc="Central 9-1-1 Police - LEIN" disp="65LEIN" mode="D" tgid="106816" />
    </group>

instead of having 'group="Ogemaw County (65)"' in each <tg>

-Don

 

[loumaag]

An alternative to Don's suggestion that would partially solve the organization problem he mentioned is provide the Group List as a seperate element set prior to delivery of the <talkgroups> elements. If sent in raw form (including any sort elements that may be present) allows developers to present or use the TG data in exactly the manner presented on the RR page. This would add a set of elements and increase the size of the return data set, but would give more adaptability to the developer, as the developer could then organize the talkgroups on the fly in the already pre-defined groups.

 

[DonS]

Fleet map size codes

From the PDF:

<fleetmap b0="D" b1="K" b2="M" b3="M" b4="K" b5="" b6="2" b7="2"/>

What's the difference between the blank entry for block 5 and the "2" entries for blocks 6 and 7?

(And the entry for block 3 is superfluous, but that's just nitpicking )

-Don

 

[blantonl2]

2 == Type II block

NULL means either not known, or the block isn't used.

 

[DonS]

According to the PDF, the <tg> element will appear "one or more times" as a child of the <talkgroups> element.

I've found a couple of systems where the XML has:
<talkgroups></talkgroups>
with no intervening <tg> elements.

For example:
sid 2987
sid 2132

Is this an XML generation bug, or a typo in the PDF (i.e. should it say "zero or more times"?

-Don

 

[DonS]

Re: Talkgroup organization

How about organizing the talk groups in a manner similar to the sites? Instead of a non-hierarchical list, each with its own "group" attribute, a higher-level <group> element which then encloses the group's <tg> elements might be more intuitive for the end-user. I'm thinking of an XML representation of the RR DB's UI, guessing that the user will want to select IDs for import based on geographic location or usage, without having to search through the (currently) "dec"-sorted list.

Nevermind. I've already implemented the parsing/sorting code, and am presenting the hierarchical list of groups/IDs like the RR DB web interface does it. (Though my list of groups is sorted, alphabetically by the "group" attribute of the <tg> element.)

Lou's suggestion will still work, and won't break existing code.

-Don

 

[DonS]

2 == Type II block

Well, yeah, I'd figured that much. :roll: 8)

NULL means either not known, or the block isn't used.

So, from a scanner's perspective (a GRE-made PRO-9x, at least), it's equivalent to Type-II.

-Don