Request for Comments - RadioReference Web Service

[ericcarlson]

Hmmm. Why even try to get a fleet map for Type II systems, since they don't use fleet maps?

True. But which part of the XML is correct? The "flavor" saying it's a Type-II system, or the "fleetmap" indicating that it's a Type-I ?

Based on Eric's post above, it looks like we'll have to perform validation checks on all of the data, throwing error messages at the user when we detect inconsistencies (including, but not necessarily limited to: offset/step format problems, flavor vs. fleetmap disagreement).

The flavor precludes the fleetmap data. In this case (and I imagine many others), the TRS was at one time a Type I system and had a fleetmap assigned but was later changed to Type II. RR correctly tells you that it is Type II but also (erroneously) sends you the fleetmap data that is still in the database (but not displayed on the web site). Lindsay should update the XML generator so that it does not send the fleetmap data for Type II systems.

-Eric

 

[fmon]

Very very nice Don , this addition will be time saving for all Win programs.

Well, not all of them. It's only implemented in Win96.

-Don

Historically I've used excel for building Winxx files, with this Web import feature, one can build a p96 file and use selective copy/paste for others. Works for me and cuts out the middle man (excel).

 

[DonS]

Bad XML in some systems...

<trs sid="313" name="Tippecanoe County Public Safety" type="1" flavor="4" voice="1" updated="2005-01-05 16:56:10">
<country coid="1">United States</country>
<state stid="18" state_code="IN">Indiana</state>
<county ctid="771">Tippecanoe</county>
<city>Lafayette</city>
<sysid ct="138.46" wacn="">A62F</sysid>
<sysid ct="138.46" wacn="">2F2D</sysid>
<sysid ct="138.46" wacn="">2F2D</sysid>
<fleetmap b0="2" b1="2" b2="2" b3="2" b4="2" b5="2" b6="2" b7="B" />
<sites>
<site num="001" desc="System 1" callsign="WPUS488" county="Tippecanoe" location=" 2300 Carson St., Lafayette &amp; 31 Tower Drive, West Lafayette" niegh="" ct="" modulation="">
<notes>Also uses Call Sign WNQH693 ..This system’s eleven (11) frequencies come from two (2) interconnected FCC licenses.  Six (6) frequencies are from WNQHY693 (TIPPECANOE, COUNTY OF) and five (5) frequencies are from a mobile relay interconnect with WPUS488</notes>
...

Note the single quote in the (undocumented!) <notes> element.

EDIT: Hmmm... unless the apostrophe is legal inside an attribute value that's delimited by double quotes (and vice-versa). I just checked, and it appears that this is the case. Time to revisit my XML parser...

-Don

 

[ullbergm]

EDIT: Hmmm... unless the apostrophe is legal inside an attribute value that's delimited by double quotes (and vice-versa). I just checked, and it appears that this is the case. Time to revisit my XML parser...

-Don

FYI.. The .NET XML parser throws an exception (perhaps since it is not within double quotes?):

{System.Xml.XmlException}
System.SystemException: {"There is an invalid character in the given encoding. Line 28, position 49."}

 

[ericcarlson]

Bad XML in some systems...

<notes>Also uses Call Sign WNQH693 ..This system’s eleven (11) frequencies come from two (2) interconnected FCC licenses.  Six (6) frequencies are from WNQHY693 (TIPPECANOE, COUNTY OF) and five (5) frequencies are from a mobile relay interconnect with WPUS488</notes>

Note the single quote in the (undocumented!) <notes> element.

EDIT: Hmmm... unless the apostrophe is legal inside an attribute value that's delimited by double quotes (and vice-versa). I just checked, and it appears that this is the case. Time to revisit my XML parser...

Note the difference between the apostrophe above and the apostrophe below. The one above is not a standard ASCII apostrophe, it's an extended ASCII character that was probably introduced into the database via a copy-and-paste operation from a desktop application.

This is a 'regular' apostrophe.

-Eric

 

[loumaag]

Hmm, In reference to the &lt;notes> element, I am betting Lindsay missed this on initial testing. The NOTES field is freeform Text and has a maximum size of 255 characters. If it continues to appear in the XML output it probably should be moved as an attribute into the &lt;sites> element rather than standing seperate. The apostrophe of course needs to be translated to &amp;apos; to work properly in any case. As to the source of the apostrophe, Eric is right it is not the standard ASCII, I am willing to bet that it is a copy and paste from a Word (or other word processor) document. There are likely to be more instances of this kind of thing.

 

[DonS]

<notes>Also uses Call Sign WNQH693 ..This system’s eleven (11) frequencies come from two (2) interconnected FCC licenses.  Six (6) frequencies are from WNQHY693 (TIPPECANOE, COUNTY OF) and five (5) frequencies are from a mobile relay interconnect with WPUS488</notes>

EDIT: Hmmm... unless the apostrophe is legal inside an attribute value that's delimited by double quotes (and vice-versa). I just checked, and it appears that this is the case. Time to revisit my XML parser...

My XML parser is working just fine. The "offending" character above is not an apostrophe, at least not one that's valid in XML. It is character 0x92 - a "right single quotation" mark. The XML-valid apostrophe is character 0x27.

EDIT: wish I'd seen the two posts above before I dug into the parser

-Don

 

[ericcarlson]

The spec says that a request can be an HTTP GET or POST. I'm curious if anyone is using POST successfully. GET works for me but POST does not.

-Eric

 

[DonS]

Error in spec...

... or the XML, but I'm betting on the spec.

The spec says that the &lt;channel> element "will exist one or more times" as a child of the &lt;site> element. However, there are systems which contain sites that have no channels.

For example: sid=38, site number 8. The XML for that site is:

<site num="008" desc="1201 Franklin" callsign="" county="Harris" location="1201 Franklin Street, Houston" niegh="" ct="" modulation="">
  <notes>Criminal Justice Center building coverage only</notes>
  </site>

For now, I'll presume that the spec is in error, and will change my code to allow sites with empty channel lists, instead of barfing on an XML vs. spec disagreement.

-Don

 

[ullbergm]

Is this the right place to submit weird things seen in the XML even if it is data related? Or should this be submitted in a email / Site update request?

If so, while looking at sid 38 that DonS mentioned i found this:

&lt;site num="004" desc="Clodine" callsign="WPKL474" county="Fort Bend" location="21001 FM 1093" niegh="1, 2. 10, 15" ct="" modulation="">

It looks like the neighbor sites should look like "1, 2, 10, 15".

 

[ericcarlson]

If you find problems with the data (i.e., stuff inside quotes), please submit an update to the database through the normal path ("Submit Info" link or "Submit Changes" button).

-Eric

 

[ullbergm]

If you find problems with the data (i.e., stuff inside quotes), please submit an update to the database through the normal path ("Submit Info" link or "Submit Changes" button).

-Eric

Ok. Will do

Thanks,
Magnus

 

[Guest]

Is this the right place to submit weird things seen in the XML even if it is data related? Or should this be submitted in a email / Site update request?

If so, while looking at sid 38 that DonS mentioned i found this:

&lt;site num="004" desc="Clodine" callsign="WPKL474" county="Fort Bend" location="21001 FM 1093" niegh="1, 2. 10, 15" ct="" modulation="">

It looks like the neighbor sites should look like "1, 2, 10, 15".

Whereas that specific error (a typo) should be submitted as an update to the system (don't bother, I'll bet Eric has already fixed it :lol: ) the one that Don mentioned bears further comment. That specific site is correct in the way it comes down, the reason is that although the frequencies are known for that site, you have to be in the building for them to work. Needless to say, you are not going to be in the building unless you have a reason (like being in jail) so the frequencies were never put there. I am sure that there may be others like that for one reason or another, so I think Don's approach is right in this instance. One has to view the Spec with some common sense, obviously Lindsay (who wrote it by himself) could not remember every detail. That is why we are here on the thread to try and help get things correct.

Added before pressing "Submit": I see as I was typing this, Eric has weighed in with a response similar to mine above, I am not editing this message to allow for that. :lol:

 

[loumaag]

Okay, somehow I got logged out. Anyway, the above message from Guest is actually from me.

 

[ericcarlson]

Guest, I'm assuming you're Lou?

If the frequencies for that site are known then they should show up in the database. I would imagine you could monitor the system if you were sitting in front of the building; in fact I've been meaning to do just that for a while. The reason that site has no frequencies is because the site ID and location is confirmed but no one has submitted frequencies; I think this is fine and the spec should be changed to allow it. Incidentally, so far as I'm aware, there is no license for this site so it probably uses some unused downtown site frequencies and/or recycles frequencies from remote sites.

-Eric

 

[DonS]

Site descriptions

In the web UI for the database, site descriptions sometims have an asterisk at the end to signify certain characteristics. For example, in the Michigan statewide system, it "means that the site number has been confirmed".

This asterisk also comes down in the XML.

My app is currently stripping the last character from the site description if it's an asterisk. Does this seem like a reasonable thing to do? That is, is it safe to presume that a trailing asterisk in a site description is really only significant if one is viewing the database via the RR web interface?

-Don

 

[loumaag]

Re: Site descriptions

My app is currently stripping the last character from the site description if it's an asterisk. Does this seem like a reasonable thing to do? That is, is it safe to presume that a trailing asterisk in a site description is really only significant if one is viewing the database via the RR web interface?

Yes. The "*" means nothing as far as RR. As a matter of fact, this point probably should be brought up for you and the other developers so that you can make sure your users are aware of the following when using your applications.

The perferred method of doing confirmed and not confirmed is to use different series of site numbers. Take a look at the Entergy multi-state system for an example of what I mean. This method is used widely and the impact of this will be felt most in the EDACS and LTR systems where confirmed LCN's are in one site group and the Unconfirmed ones in another.

 

[ericcarlson]

The * is not used uniformly; it can mean anything depending on what the Misc System Info text says on the web UI. You can strip the * off the site name if you want but I don't really think it is necessary. If a user is already familiar with the RR web UI then they may be familar with the meaning of * on a particular system, so it may be helpful to them to not strip the * off.

-Eric

 

[blantonl]

Spec was updated, attached for version 0.94.


Fixed the following:

- Statewide systems now returned in a ctid query
- Fleetmaps only returned for Type I and Type IIi systems.
- "niegh" to "neigh"

Did I miss anything?

Don, did you want me to only return the parent &lt;talkgroups> element if there are actually talkgroups? In the mean time I said in the spec that &lt;tg> can appear zero or more times. I don't want to change that just yet and break your app.

-LB

 

[blantonl]

Another note:

Developers, I would prefer that you not hard code the URL into your apps, in case I need to change the location of the service. It would be better to have the user have the ability to input the service URL which is currently:

http://www.radioreference.com/apps/xml

You could prefill it if you want to, but I'd like the user to have the ability to change it, or add other services if someone else wants to adopt the spec for their data.

Lindsay