Storing freqs in the wiki

Status
Not open for further replies.

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
As seen in the above list, something like "Airline Frequencies" could easily be a child under "Aircraft Monitoring".

Another idea:

Maybe it would be clearer if "Aircraft Monitoring" were simply renamed to "Aviation". Then it could have a child named "Aviation Frequencies" under which all other aviation-related specific "...Frequencies" catergories could be listed.

It would grammatically make-sense for a category named "Aviation" to also include information about aviation-related ground communications, etc., whereas "Aircraft Monitoring" only relates directly to aircraft, (though over-time the category seems to have become the parent for all aviation-related articles).

Thoughts?
 
D

DaveNF2G

Guest
As you probably guessed, the "Aircraft Monitoring Frequencies" suggestion was an unpolished-attempt to suggest a "...Frequencies" category that would:

I did understand this and was, to some degree, pulling your leg. This is difficult to convey in straight text, of course. I'm glad you didn't take offense. :)

As seen in the above list, something like "Airline Frequencies" could easily be a child under "Aircraft Monitoring". Others could be added, too.

Yes, I agree. In fact, my objection to aviation frequency categorization is more severe in connection with the DB, where airline ops are categorized as Business.
 
D

DaveNF2G

Guest
Another idea:

Maybe it would be clearer if "Aircraft Monitoring" were simply renamed to "Aviation". Then it could have a child named "Aviation Frequencies" under which all other aviation-related specific "...Frequencies" catergories could be listed.

I second this idea.
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
We might also look into consolidation where it makes sense to do so.

Case in point - there are 3 categories that really cross over one another where they describe - or are used for - similar purposes; Statewide trunked systems, Trunked Radio Systems and Trunking Information could all be lumped into one category like Trunked Systems Under Development, which would be much more descriptive of the purpose of the category

Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
We might also look into consolidation where it makes sense to do so.

Case in point - there are 3 categories that really cross over one another where they describe - or are used for - similar purposes; Statewide trunked systems, Trunked Radio Systems and Trunking Information could all be lumped into one category like Trunked Systems Under Development, which would be much more descriptive of the purpose of the category

Mike

That one might be a tougher-call. While adding "Return To" links to Wiki-pages, I also try to update each page's category-list, and have been doing so with these thoughts in mind:
  • As I understand it, the purpose of the "Trunked Radio Systems" category is to represent any system that is a known, identified, TRS.

    • As such, when I can verify that a Wiki-page corresponds to a particular TRS's RRDB page (verified by making sure that the RRDB page's "Wiki" button goes directly to the Wiki page in-question), I make sure the "Trunked Radio Systems" category is applied.

  • As I understand it, the "Statewide Trunked Systems" category is for systems like Virginia's STARS system which is intended to (and will when fully implemented) physically span the whole state, and provide communication from "any" point in the state to "any other" point in the state.

    • If my above understanding is correct, I can see how this would be useful in that it helps Wiki-visitors narrow down their category-based search so that they do not have to wade through all of the regional or municipal TRSs for a given state, when they are looking for only the state-sized TRSs.

    • Suggestion: Maybe "Statewide Trunked Systems" should be a child of "Trunked Radio Systems"

  • As I understand it, the "Trunking Information" category is for all of the speculative information about TRSs.

    • If the contents of Wiki pages were compartmentalized in a way where speculation about a TRS would be on a different page that is separate from that TRS's "official" (RRDB-linked via the "Wiki" button) page, then the "Trunking Information" category would seem more useful in that it would help maintain a clearer separation between the "confirmed" and the "speculative" information in the Wiki.

    • But, given that many "official" TRS pages contain not just "confirmed" but also "speculative" information, it might seem that the category "Trunking Information" has less value or purpose now.

    • Suggestion: For any specific TRS, for which there is an entry in the RRDB, and for which there is a corresponding "official" (via the RRDB "Wiki" button) Wiki article, I am in-favor of placing into the "official" Wiki article, all information regarding that TRS, whether confirmed or speculative. (Article size might require multiple pages, but still considered all part of one article.)

    • As such, this would/could reduce the use of the "Trunking Information" category to only those occasions when there is speculation about a proposed TRS, not a known TRS. If someone "heard-a-rumor" or has unofficial knowledge of an upcoming system that is not yet in the RRDB, or maybe is not even yet fully delivered to the municipality, then the speculative information about that TRS would seem to be appropriately categorized in the "Trunking Information" category.

      I don't know what the internal procedures/policies are for the RRDBAs as to how "early" they can/will enter a new entity into the RRDB--whether the system must be installed at some level or whether it can still be in the concept stage--but at whatever point the RRDBAs create the RRDB entry for the discussed TRS, it would seem that the Wiki article's category should then change from "Trunking Information" to "Trunked Radio Systems" because the TRS "exists" in the RRDB at that point. Future updates to the RRDB and to the Wiki would be simply that--updates. Confirmed and speculative information would be in the same Wiki article, and the "Trunking Information" category would not seem necessary at that point, whereas it might have been necessary before the RRDBAs entered the TRS into the RRDB.

So, my suggestions:
  • Keep all three categories

  • Define "Trunked Radio Systems" as the category that is assigned to every Wiki article (whether single or multi-page article) that is linked from a corresponding RRDB-TRS page via the RRDB page's "Wiki" button.

  • Make "Statewide Trunked Systems" a child of "Trunked Radio Systems", and assign one or the other to an article, but not both.

  • Redefine the scope and purpose of the "Trunking Information" category to be only for information about TRS's for which there is not yet an entry in the RRDB. (By this definition, when an RRDB entry is created for a given TRS, then the corresponding Wiki article would lose the "Trunking Information" category and gain the "Trunked Radio Systems" category. This would help avoid having both tags on the same article, and would make "Trunking Information" more useful in narrowing a category-search for "new" TRSs, as compared to "existing" TRSs.

  • EDIT: It might also be appropriate to consider creating something like a "Multi-state Trunked Systems" subcategory under "Trunked Radio Systems", for things like the TRSs used by large utility companies, large transportation companies, and for wide-area systems used by government entities, like those used near state borders (like Chattanooga, TN and its peripheral communities) and those used by the Feds/Military.


Thoughts?
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
Some random thoughts...

I'm unsure whether a multi state category for trunked systems would be all that valuable - there aren't all that many of them. Perhaps a statewide trunk category would be useful - that should be something that can be done pretty quickly since there's a limited number of articles for them.

'Trunked Information''s original purpose was to capture data on a TRS that was not yet ready for the database, such as unidentified talkgroups or new custom tables needed for trunktrackers that had not yet been validated. It's probably evolved somewhat to handle things like RID/UID data and other things that the database can't handle. I think it still pretty much serves that purpose, but if there are other articles that don't fit into that mold, they of course can be moved.

When we're ready, some review of these categories is in order (to coincide with the previous discussions about renaming the aero categories) to clean some of this up. But I'd suggest waiting until I (and whomever else wants to jump in here) am done walking through all of the state stuff (I'm up to Kentucky). There are a LOT of articles that were simply never categorized beyond going at the state level, and we would be missing a great deal of data if we tried to do all of that now.

Once we have everything categorized, then we will have a handle on the scope and volume contained in the categories. Things will always fall through the cracks of course - we can't stop new development or modifications that other folks are making - but once this walkthrough is complete, we should have most of the categories fully populated.

I do feel confident though that the <statename> frequencies categories are pretty stable, though, so I think we can write them off of the list for modifications (and the cat tree) for now. They're specific enough that there's little question as to what they represent. That also goes for the regional categories - they're geographically pretty specific too

Mike
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
I would also say that the FTO and RID/UID categories are also stable - these are very specific and well known, so we can, in theory, wipe them off the cat table as well

Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
'Trunked Information''s original purpose was to capture data on a TRS that was not yet ready for the database, such as unidentified talkgroups or new custom tables needed for trunktrackers that had not yet been validated. It's probably evolved somewhat to handle things like RID/UID data and other things that the database can't handle. I think it still pretty much serves that purpose, but if there are other articles that don't fit into that mold, they of course can be moved.

From the Collaboration-Gateway page:

Category:Trunking Information - Put all data regarding research of new, rebanded or unknown trunking systems here. Data posted here should eventually be sent to the admin to be included in the database.

The above quote can be rephrased as "Put all speculative (yet-to-be-confirmed) trunking-system information in this category."


Thoughts:

  • It might be useful to other folks, like maybe the RRDBAs, but I don't see the benefit of the broadly-named "Trunking Information" category. Unless the RRDBAs use the "Trunking Category" as a navigational tool for rountinely checking the Wiki pages related to their portion of the RRDB, I just don't see the category's benefit--more specifically who it would benefit.

  • RIDs/UIDs and FTOs each already have their own category, so "Trunking Information" should not cover those topics.

  • By definition, the Wiki is where information goes when it cannot go into the RRDB. So, whether something is speculative (not yet validated) or is beyond the RRDB's capacity/purpose, the Wiki is where it goes. So, I expect to find both confirmed and unconfirmed information in each Wiki article that corresponds to an RRDB page. Having a category that indicates "speculative" or "not-yet-confirmed" seems redundant by both definition and practice, because that is already a primary purpose of the Wiki when compared to the RRDB.

  • If speculative information about a specific TRS exists, I would expect to find it, along with any confirmed information, on that TRS's "official" Wiki page (linked to by the TRS's RRDB page's "Wiki" button).
    • I would expect to navigate to that TRS's Wiki page specifically because I was interested in that locale and wanted to know about any speculative information relating to it.
    • I would not expect to navigate to that TRS's Wiki page simply because I chose it from a long list of pages that contain speculative information.

  • Custom tables seems to be a solution for a trunking-scanner's problem, and thus should be listed in the "Trunking Scanners" category, so that Wiki-visitors who navigate-by-category to the list(s) of Trunking Scanners, will also see articles for specific TRSs that explain how to program the related custom trunking-tables into those trunking scanners.

Suggestions:
  • Eliminate the category "Trunking Information".

  • For articles with custom scanner-tables either use the category "Trunking Scanners" or create a category named "Custom Trunking Tables", that would be a child under "Trunking Scanners", and possibly .also a child under "Trunked Radio Systems".

  • If there are other specific purposes for which "Trunking Information" category has been used, let's determine each purpose and, as appropriate, create categories with detailed names reflecting those purposes.


Thoughts?
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
Custom tables need to be placed on the system where they're relevant - putting themi in the 'Trunktracker Scanners' articles would create a horrendous mess, since similar data (if the tables are slightly different - case in point Grundy county Illinois) would have to be repeated over and over again. Not good from either a database or maintenance standpoint. If you make an article out of the information, it's only slightly better - you would have to build links from every radio to point to it. It would turn out to be a very messy proposition. It's probably better to keep it on the trunked system page. Besides if someone hits the WIKI button link in the database and brings up that particular article, the information is right there in front of them

We do have a number of RID/UID lists posted on articles that are just for a trunked system - so perhaps it would be a good idea to split them off onto their own article. It would certainly allow for future growth. Another item for the to-do list...

I think it's time to formally start such a list. We're coming up with a number of ideas and things to do, but if we don't collect them somewhere, they're just as likely to get lost. Perhaps as a link from the category tree article...

Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
I think it's time to formally start such a list. We're coming up with a number of ideas and things to do, but if we don't collect them somewhere, they're just as likely to get lost. Perhaps as a link from the category tree article...Mike

QDP2012 said:
First draft is in this new article:

Categories-Tree Notes

Hope this helps,

Indeed it does. A good start.

I've added some detail to the item about applications that can copy data from the wiki. There already is such an article, but it needs some expansion (and so far, no one has stepped forward) to document which BuTel products can do this, and specifically what option to use. As there are a few older BuTel packages floating around out there (notably ARC780 for the old BC780) it's an important piece of data to include.
 
Last edited by a moderator:

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Custom tables need to be placed on the system where they're relevant - putting themi in the 'Trunktracker Scanners' articles would create a horrendous mess

Agreed, My suggestion, though maybe poorly stated, was not not to move data from one article to another, but instead put a category (like a new category "Custom Tables") on the existing article, but then make the "Custom Tables" category a child-category under "Trunking Scanners", so that when the owners of trunking scanners navigate to the category "Trunking Scanners" looking for more help with their scanner, then they will also see that there is a category "Custom Tables", which they can then click to see a list of all the municipalities that require custom tables. Then the user can click on their municipality's link and go to its existing page to learn more about the required custom tables.

No data would move, just a more specifically named category would be applied, with the idea that its purpose and scope would be clearer and more specific than the general topic of "Trunking Information".
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
We do have a number of RID/UID lists posted on articles that are just for a trunked system - so perhaps it would be a good idea to split them off onto their own article. It would certainly allow for future growth.

Many such lists have already been moved to separate pages within a multi-page article. This seems to happen either when the article-author finds it easier to maintain the rest of the article without having to navigate around their RID/UID list, or when they are doing many revisions to the RID/UID list.

Except for some obviously long articles that clearly should be adjusted into a multi-page format, this might be best left as a preferential choice for each article-author to make as they maintain their lists.

Making sure the "RID/UID Lists" category is applied properly (whether the article-author has kept the RID/UID info in their main single-page article or has used a multi-page format) might be all that needs to happen at this point. And, I think you mentioned earlier you had already verified this as complete/stable.

Just a thought,
 
Last edited:

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Edit vs Reply ?

I don't really understand why or how, but from my end it looks like post #70 above was "edited" instead of "replied to".

Am I missing something here?

Thanks,
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
I don't really understand why or how, but from my end it looks like post #70 above was "edited" instead of "replied to".

Am I missing something here?

Thanks,

Yeah I screwed up when I was trying to reply - my bad. That's what I get for trying to do something like this when I'm tired...Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Yeah I screwed up when I was trying to reply - my bad. That's what I get for trying to do something like this when I'm tired...Mike

I have been computing while tired before too. I just wanted to verify that it was something simple like that. No problem.
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Staff member
Super Moderator
Joined
Jul 18, 2004
Messages
10,135
Location
Central Indiana
Moderators have the ability to Edit posts in the forums in they moderate. Mike and I are moderators in this forum. I'm also a moderator in the Amateur Radio forums. I occasionally find myself hitting the Edit button rather than the Quote button. That's usually met with a reaction on my part along the lines of "Why does this screen look different?".
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
By the way, in case you didn't know about it, you have your own private work area attached to your ID in the wiki. Everyone does. I use mine constantly when I'm developing something. It keeps everything active, but not in the public eye (unless someone knows how to access the user lists) until it's ready for prime time. Just click on your ID and see where you go. If you need to develop multiple pages, be sure to store them in a text format (Notepad ++ is excellent for this, but there are several other such packages). I'd avoid Word - it tends to put wierd characters all over the place that gets to be a royal pain if you forget to save as text...

I just created that page and put my growing Wiki-to-do lists on it, but will use only the Categories-Tree, and Categories-Tree Notes articles, and this thread, for suggestions etc on your project. That way related notes, comments, etc. stay in as few places as possible, and don't get "spread all over the place".

Thanks,
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Moderators have the ability to Edit posts in the forums in they moderate. Mike and I are moderators in this forum. I'm also a moderator in the Amateur Radio forums. I occasionally find myself hitting the Edit button rather than the Quote button. That's usually met with a reaction on my part along the lines of "Why does this screen look different?".

That makes sense. I've seen that happen in non-RR situations, too.

Thanks,
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,721
Location
Bowie, Md.
OK I'm down into the North Carolina category now - we're getting there. Man this is one mind-numbing exercise. But I have found what I had thought - many articles simply had their statename category in them and not much else, even though they had a LOT of other information that can be categorized. We would have missed a bunch of data had I not decided to walk through them all. I've probably missed a few articles here and there, but it's coming along...slowly.

Hopefully I'll be finished with walking through all of these states before the holidays. Then the real job of cleaning up these categories can begin. At least then we'll have a good handle on the size and scope of what needs to be done...Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
OK I'm down into the North Carolina category now - we're getting there. Man this is one mind-numbing exercise. But I have found what I had thought - many articles simply had their statename category in them and not much else, even though they had a LOT of other information that can be categorized. We would have missed a bunch of data had I not decided to walk through them all. I've probably missed a few articles here and there, but it's coming along...slowly.

Hopefully I'll be finished with walking through all of these states before the holidays. Then the real job of cleaning up these categories can begin. At least then we'll have a good handle on the size and scope of what needs to be done...Mike

Good job! I am still busy with non-RR projects that I am trying to complete before the school-season really starts-up again.

Keep up the good work.

Thanks,
 
Status
Not open for further replies.
Top