Rick is getting me back for all the suggestions and grumbles I provide him regarding T4Win and Unitrunker :lol:
XML tags that do nothing should be exterminated. The <talkgroups> and <sites> elements do nothing. Delete them!
I don't know Rick, I like them. They help bring a hierarchy to the data which makes it easier to process and read, IMHO of course.
Elements like country, state (or province), county, and city are really attributes. They don't need to exist as full-blown elements/objects. Having ctid's, stid's, coid's (are there city ids too?) adds an unnecessary extra level of indirection.
Actually, country, state, and county are really elements of a trunked system, since a system can reside in multiple, and we allow for that in the database. I can't represent that using attributes properly.
There are no city ID's, however stid's, ctid's, and aid's are important, since they are the primary keys to data in the database. So, if the software developers wanted to provide a link back up in the location hierarchy for a system, they'll need all of that information.
This reveals schema structure in the underlying database that might best be kept hidden from external applications. Ditto for tgids. I don't need to know the database's internal unique ID for something. If you do a backup/restore of the RR DB (BCP anyone ?), these values are likely to change.
That was exactly my intention (and the intention of a web service). Looking at tgids -- think about how we would match talkgroups in the database if we eventually implemented your suggestion to "Post" to the web service. Which is more efficient, match to a unique ID in the table, or cross reference to tg_dec, tg_group, and system? Hmmm.... I'll take the first one.
Also, the values WILL NOT change in the database, and a backup and restore would not impact this.... short of a complete loss of the database and we had to rebuild from scratch. Then we've got bigger problems.
So, in short, for some instances you will need to know the underlying schema, and that's the whole intention of the web service in the first place.
This would also reduce the number of HTTP transactions between client and server. If I understand this right, to pull down a list of TRSs for a region I have to get a list of ctids, stids, and coids - which I then use to issue the real query to the server.
Well, there is no other way to query the data. You can't just arbitrarily pick a point in the location hierarchy and fire away. you have to start from the top and work down - short of other query types which can be easily implemented (search by system name, sysid, etc as you have suggested below).
I have a similar gripe over System Types, System Flavors, and Voice Types. Instead of returning type id and flavor id and voice id, just go ahead and tell me what the darn thing is in plain text!
Well, as pointed out by some of the other developers, it's a lot easier to match and take action on enumerated values then it is strings. And what happens if MA/COM decides to sell EDACS to someone else, those hard coded values in your software are all the sudden invalid. Instead, enumerated values provide better flexibility, and my plan is to expose those enumerated values for you to query as well from the service.
For the site ct attribute: this is Motorola specific. APCO P25 has something similar called a NAC. I suggest renaming this attribute to some thing like "connect" or "access" ie. something generic so it can be used for both Motorola and P25.
I believe you are referring to the WACN, because for trunked systems the NAC is irrelevant, and I don't believe used. ct is fine, and we also have a field for wacn as well.
Here are the kinds of queries I'd like to support with minimal fuss:
1. retrieve a specific TRS by system type (ie. Motorola or P25) and system id.
Piece of cake, I'll get it done here soon. But you are still going to get ctid, stid, and coid, so if you want to back reference up the location hierarchy, you'll already have the data to do so.
2. retrieve a list of candidate TRS's that match a system type, system ID and have a control channel with LCN "X" whose frequency is "Y" Mhz.
If you take the existing Motorola SYSID query and add an extra type parameter, then you've got #1 above.
This second query is needed to pull down LTR and EDACS systems where the system id isn't unique enough. A variation on #2 might include state and city or county parameters to further limit the results.
These are two very useful "real world" queries that I'd like to support in some of my programs
I can do that to. No problem.
Suggestion #3 ...
Make sure that the sysid includes the WACN prefix when locating P25 systems. Example: Austin / Travis county is BEE09-13E. An RR DB search for sysid 13E might (eventually) return some other system.
I would prefer in this case that you provide some exception handling on your end versus exception handling on mine. BEE09 is a common WACN seen with just about all the P25 systems out there, so its a lot less unique then the system ID. If there are dup system ID's, we'll send both systems in the XML doc, and you can throw up a box asking the user "which one?"
Also, I know Lindsay does not track radio IDs in the RR DB, but for completeness, it would be nice to include an equivalent element for radio IDs - something like <rid> or whatever - with basically the same attributes as the <tg> element like desc, disc and group.
I concur...
EDACS - as everyone knows - comes in two flavors - 4800 and 9600. When searching for a specific system, it is not unusual for two systems to exist in the same area with the same EDACS system id. They may be distinguishable by being on different bands or operating at different control channel data rates.
Splitting EDACS into two types - EDACS48 and EDACS96 - would help when trying to find data for one by filtering out the other.
That is already enumerated in those types, flavors, and voice definitions you hate.. ;-)
Now ... Lindsay ... when are you going to support HTTP POSTs for submitting new findings to the moderators for review? I bet they'd love to be able to look at a submission and click "accept" or "decline" without having to do all that typing!
Well.... I'm looking at it, however we'll have to send down all those unique identifiers in the XML document so you can send'm back in that POST...
:lol:
