RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Site Administration Forums > Wiki Forum


Wiki Forum - Discussions regarding the RadioReference Wiki

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 07-11-2016, 3:03 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Question Testing Updates to "Template:Infobox_TRS" -- Request for comments

Good morning all,

An update to "Template:Infobox_TRS" is being tested on the articles listed below. Your review and comments are requested below.

---
The intent of the update is to:
  • Increase ease of reading/navigating by:
    • Making link-names shorter
    • Decreasing word-wrapping in link-names
    • Maximizing use of white-space
    • Increasing uniformity of text-positioning
    • Visually separating TRS details (NAC, WACN, RAN, etc.) from the TRS General Info (name, location, etc.)
    • Adding the optional ability to hide the following parameters in the TRS Details section of the Infobox, when they are unused/unrelated:
      • SysType
      • SysID
      • CTone
      • WACN
      • NAC
      • DMR CCode
      • NXDN RAN
      .
  • Decrease/Shorten overall length of the Infobox by:
    • Listing multiple callsigns in a horizontal comma- or space-delimited list instead of a vertical line-break-delimited list.
    • Adding the optional ability to hide any unused/unrelated parameters in the TRS Details section of the Infobox, as mentioned above.

  • Add new functionality or convenience
    • Provide uniform links to the TRS-specific Site Maps produced by the RRDB
    • Add the "Trunktracking FAQ", "Trunktracking Glossary", and "Wiki Editing FAQ" links to the "Other Resources" section, which did not exist when Template:Infobox_TRS was created.
    • Add the optional ability to include the "Tracker..." templates uniformly in the Infobox_TRS template-call, so that they no longer need to be applied separately to articles.

---
The pages used for this test are:

---
Additional change(s) planned:
  • Also, later, after initial implementation of the updated-template across the Wiki, the "FCC" parameter (which in the existing template can only handle one callsign), and the "MoreCallsigns" parameter, will be merged into one parameter that handles multiple callsigns.

  • Later, as needed, parameter(s) for TETRA systems will be added, with the option of hiding it/them.

  • After this update is finalized and implemented, then the other "Template:Infobox_TRS_..." templates will be updated accordingly, to achieve parameter and presentation uniformity across all TRS templates as much as possible.



Request for comment


Thanks in advance for your help and comments,
__________________
73 QDP

Last edited by QDP2012; 07-11-2016 at 3:10 AM..
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 07-12-2016, 1:13 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Some updates...
---
Quote:
Originally Posted by QDP2012 View Post
---
Additional change(s) planned:
  • Also, later, after initial implementation of the updated-template across the Wiki, the "FCC" parameter (which in the existing template can only handle one callsign), and the "MoreCallsigns" parameter, will be merged into one parameter that handles multiple callsigns.
To the test-template , the new parameter "Callsigns" has been added which overrides, and will later replace, both the "FCC" and the "MoreCallsigns" parameters. This will allow the existing-template, when updated, to be backward-compatible with the existing template's articles, and will allow the "FCC" and "MoreCallsigns" parameters to be deprecated smoothly article-by-article as the updated-template is applied across the Wiki. When all related articles have been updated to use the "Callsigns" parameter, the "FCC" and "MoreCallsigns" parameters will be considered deprecated entirely, and will then be removed from the template.



---
Quote:
Originally Posted by QDP2012 View Post
  • Add new functionality or convenience
In the test-template, the parameter "SysName" now has a default-value of (the system variable) "{{PAGENAME}}", which means that the parameter "SysName" will no longer be required on the TRS' primary-page, because the primary-page's name is the same as the TRS' name, and the Wiki engine will automatically place the page's name in place of the system variable "{{PAGENAME}}". If the InfoBox is applied to a TRS' secondary page (like RID/UID page, or Unknown TGs page, or other Trunking Info pages, etc.) then the "SysName" parameter would be used to specify the TRS' correct name on the TRS' secondary page.




---
EDIT:
Quote:
Originally Posted by QDP2012 View Post
  • Later, as needed, parameter(s) for TETRA systems will be added, with the option of hiding it/them.
TETRA related parameters have been added to the test-template, and can be hidden when unused/unrelated.


---
Comments and suggestions are welcome.

Thanks,
__________________
73 QDP

Last edited by QDP2012; 07-12-2016 at 2:23 AM..
Reply With Quote
  #3 (permalink)  
Old 07-12-2016, 8:33 AM
Wiki Admin Emeritus
  Amateur Radio Operator
Amateur Radio
 
Join Date: Jul 2002
Location: Bowie, Md.
Posts: 20,599
Default

It's really not necessary to even consider TETRA at this point. The FCC has put a kibosh on any public safety system using TETRA (see the thread on this topic), and like Open Sky, there are no scanners now, or in the planning stages (that anyone is talking about, anyway) that can copy this mode.

To me, it's a non sequitur

Mike
__________________
links editor, Utility Monitoring Central
HF Forum moderator, RadioReference
Friends don't let friends buy Scancat Lite Plus!
Reply With Quote
  #4 (permalink)  
Old 07-12-2016, 8:47 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

The TETRA components were added because TETRA information has already been added to the Wiki. The example below seems to be related to Business systems, not Public Safety systems. How the TETRA data was acquired, I do not know.

Example: John F. Kennedy International Airport (JFK) New York County (NY).
__________________
73 QDP
Reply With Quote
  #5 (permalink)  
Old 07-13-2016, 11:08 AM
Wiki Admin Emeritus
  Amateur Radio Operator
Amateur Radio
 
Join Date: Jul 2002
Location: Bowie, Md.
Posts: 20,599
Default

The New Jersey Turnpike entry should be using the Multi county template, since it goes up and down the state. I didn't change it since it's a part of your test bed

The only concern I might have would be the FCC callsigns. If there are more than a few of them, I can see that area becoming pretty crowded and hard to read. That's why I built the multi site templates - so we can use the RR mapping functions (which you already have) to view them.

It's a little odd seeing the trunktracking FAQ and the other one showing their links on two lines, but due to the length, you can't help it...Otherwise this looks nice..Mike
__________________
links editor, Utility Monitoring Central
HF Forum moderator, RadioReference
Friends don't let friends buy Scancat Lite Plus!
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 07-13-2016, 2:17 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default Thanks

Quote:
Originally Posted by ka3jjz View Post
The New Jersey Turnpike entry should be using the Multi county template, since it goes up and down the state. I didn't change it since it's a part of your test bed
Thanks for catching that. I noticed the county was designated as "multiple" or "various" but didn't stop to assign a different template at the time. Since you reminded me of it, I looked at all of the articles that use either the multi-county or the multi-state templates, and have made some adjustments to the test-template so that when I update the other templates, they will simply invoke the main TRS template but with custom values. That way the look-and-feel will be consistent no matter which template is assigned to a particular article.



Quote:
Originally Posted by ka3jjz View Post
The only concern I might have would be the FCC callsigns. If there are more than a few of them, I can see that area becoming pretty crowded and hard to read. That's why I built the multi site templates - so we can use the RR mapping functions (which you already have) to view them.
I understand and agree; but so far, I have only seen a few articles that have a good-handful of callsigns, which in this new format seems like it would only be two rows. So, hopefully, it won't be a problem. But, I will definitely monitor that in case something gets too long and needs some spacing-adjustment or something.



Quote:
Originally Posted by ka3jjz View Post
It's a little odd seeing the trunktracking FAQ and the other one showing their links on two lines, but due to the length, you can't help it...Otherwise this looks nice..Mike
Yeah, single-line would have been ideal, but this seems to work.

Thanks for the time it took to review everything and for the comments.


I will still be in test-mode for a while, working through the articles to make sure nothing gets messed-up by the updates to the test-template. I will post here again when things get finished up, and at any major points along the way as needed.

Thanks again,
__________________
73 QDP

Last edited by QDP2012; 07-13-2016 at 2:23 PM..
Reply With Quote
  #7 (permalink)  
Old 07-14-2016, 2:06 PM
DaveNF2G's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Jan 2001
Location: Rensselaer, NY
Posts: 8,434
Default

TETRA can be detected by DSDPlus. I'm not sure if it decodes it yet, but there are other tools for that as well.

Let's try to keep RadioReference salient to more than just scanners, please.
__________________
David T. Stark
NF2G WQMY980 KYR7128
ARRL VE & Registered Licensing Instructor
Reply With Quote
  #8 (permalink)  
Old 07-14-2016, 3:01 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by DaveNF2G View Post
TETRA can be detected by DSDPlus. I'm not sure if it decodes it yet, but there are other tools for that as well.
Maybe some day I will have some time to try DSDPlus, etc. It sounds interesting.


Quote:
Originally Posted by DaveNF2G View Post
Let's try to keep RadioReference salient to more than just scanners, please.
Good point.


Thanks,
__________________
73 QDP
Reply With Quote
  #9 (permalink)  
Old 08-07-2017, 3:25 AM
Spitfire8520's Avatar
Member
   
Join Date: Jun 2009
Location: Colorado
Posts: 1,527
Default

Bringing this topic back to light as I believe there is an error with the Infobox_TRS_P25 and P25P2 templates. I do not believe that the CTone field is relevant to any P25 system as is it specifically related to Motorola systems. The CTone field should be removed from all P25 infoboxes.

I am a bit unsure on how to approach this as the current P25 infobox has been mass deployed to more than a hundred articles with "CTone = ?" already set by default.
__________________
Mile-High Spitfire
RadioShack Pro-106 RadioShack Pro-652 RTL-SDR
MNN-250
Reply With Quote
  #10 (permalink)  
Old 08-07-2017, 3:33 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by Spitfire8520 View Post
Bringing this topic back to light as I believe there is an error with the Infobox_TRS_P25 and P25P2 templates. I do not believe that the CTone field is relevant to any P25 system as is it specifically related to Motorola systems. The CTone field should be removed from all P25 infoboxes.

I am a bit unsure on how to approach this as the current P25 infobox has been mass deployed to more than a hundred articles with "CTone = ?" already set by default.
Good afternoon Spitfire8520,

Thanks for pointing out this issue, but I am already monitoring it, and have been since the design-phase of the Infobox_TRS update project.

Right now, I am still in the testing-phase for the new InfoBox TRS templates, though I am deploying the templates in a controlled manner while testing each individual deployment, (not "mass-deploying" -- meaning not without evaluation of the template-design at each step).

As I encounter any issue with template-design, I investigate and research the situation, and then adjust the template(s) accordingly, but only after ensuring that there are no exceptions to the hypothesis (whether a parameter should be added or removed).

Even though I agree (since initial design) that the parameter CTone seems to be unnecessary for P25 systems, the CTone parameter was included because, during the research part of the design-phase, the parameter was found to have a value listed in the DB and/or the Wiki for at least one P25 or P25P2 TRS.

During design and testing, I have been watching for this CTone issue, and already plan to review all of the P25 / P25P2 TRS pages (in DB and Wiki) again before ending the testing-phase, to confirm whether the CTone parameter can be removed, or whether it must be kept.

If during that review, I find that the CTone value is not displayed in the DB and also not in the Wiki for the P25 / P25P2 TRS's, then I will remove the CTone parameter from the related templates, and update the template-calls on the related P25 / P25P2 Wiki pages. (Of course, on the other hand, if the CTone parameter has a specific value in either the DB or the Wiki, then those situations would need to be addressed individually before I remove the parameter from the template.)

I appreciate you posting your concerns here instead of making adjustments to the templates that are still being tested.

Thanks again for bringing up the issue.
__________________
73 QDP
Reply With Quote
  #11 (permalink)  
Old 08-07-2017, 4:15 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 738
Default

Connect Tones are not used for P25 systems, period. If any wiki articles for P25 systems have any value in the CTone field, then it is incorrect and should be removed. As should the CTone field from the P25 templates.
Reply With Quote
  #12 (permalink)  
Old 08-07-2017, 4:59 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by GTR8000 View Post
Connect Tones are not used for P25 systems, period. If any wiki articles for P25 systems have any value in the CTone field, then it is incorrect and should be removed. As should the CTone field from the P25 templates.
That is what I expected when I started, but if I recall correctly, there were CTones listed on P25 TRSs in both the DB and Wiki. During my review I will check the DB and submit change-requests for any I find accordingly. I will also take care of the related templates and Wiki-pages.

Thanks to both Spitfire8520 and you for bringing up the topic and clarifying the correct use of Connect Tones.
__________________
73 QDP
Reply With Quote
  #13 (permalink)  
Old 08-07-2017, 5:37 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 738
Default

Quote:
Originally Posted by QDP2012 View Post
That is what I expected when I started, but if I recall correctly, there were CTones listed on P25 TRSs in both the DB and Wiki. During my review I will check the DB and submit change-requests for any I find accordingly. I will also take care of the related templates and Wiki-pages.

Thanks to both Spitfire8520 and you for bringing up the topic and clarifying the correct use of Connect Tones.
No 'Connect Tone' field exists within the RRDB for P25 systems, so it would have to be something that was entered into one of the free-form text fields. As far as a Connect Tone being listed in the wiki for a P25 system, well that's another story entirely.
Reply With Quote
  #14 (permalink)  
Old 08-07-2017, 5:58 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by GTR8000 View Post
No 'Connect Tone' field exists within the RRDB for P25 systems, so it would have to be something that was entered into one of the free-form text fields. As far as a Connect Tone being listed in the wiki for a P25 system, well that's another story entirely.
Thanks again to both of you for clarifying these points. The P25 / P25P2 templates still being tested have been updated accordingly, and the Wiki pages to which they were applied were also updated.

I will still do the planned review just for quality-control, as the project continues.

Thanks again,
__________________
73 QDP
Reply With Quote
  #15 (permalink)  
Old 08-07-2017, 6:02 PM
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2013
Posts: 738
Default

While we're on the subject, how does the Wiki handle P25 systems that have multiple SysID's, WACN's, NAC's?
Reply With Quote
  #16 (permalink)  
Old 08-07-2017, 9:48 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by GTR8000 View Post
While we're on the subject, how does the Wiki handle P25 systems that have multiple SysID's, WACN's, NAC's?
The new Infoboxes that are still being tested can handle multiple values for those parameters without any problem, as comma-separated values, which allows natural wrapping within the column. Also, the html <br/> command can be used to force a new-line, if really needed. Commas are easier for most people, and should be used unless there is a clear reason to employ a <br/> in the parameter's value-list.

Examples of comma-separated values
e.g.: SysID = 123, 234, 345, 456, etc.
e.g.: WACN = ABC12, ABC13, ABC14, etc.
e.g.: NAC = 123, 124, 125, 150, etc.

Examples of consistent multiple values
e.g.: WACN = BEE00 (for all SysIDs)
e.g.: NAC = 123 (for all SysIDs)


If you know of a different use-case, please let me know, so I can consider it relative to the current template-design. -- Thanks.


After testing and initial deployment is complete, and all "initial" template-changes have been finalized, I will create corresponding documentation for the templates which will include examples of multiple values for the given parameters.


Hope this helps,
__________________
73 QDP

Last edited by QDP2012; 08-07-2017 at 9:58 PM..
Reply With Quote
  #17 (permalink)  
Old 09-13-2017, 9:40 AM
Wiki Admin Emeritus
  Amateur Radio Operator
Amateur Radio
 
Join Date: Jul 2002
Location: Bowie, Md.
Posts: 20,599
Default

I noticed that infobox template is being built based on the trunk type- in this case, Project 25 phase 2. While it looks nice, it's opening up a HUGE can of worms. Are you planning on going through every state and province, adding a new infobox for each, then adding new templates for everything that uses NXDN and DMR trunking?

That's where this is heading; that's a whole lot of work that is really unneeded, as the warning templates can be put on any article, and no changes are needed for the infobox based on trunk type. Not to mention the cleanup that will be necessary to remove all the orphaned templates once the conversion is done. I doubt Bob would be looking forward to doing that (heh)


Mike
__________________
links editor, Utility Monitoring Central
HF Forum moderator, RadioReference
Friends don't let friends buy Scancat Lite Plus!
Reply With Quote
  #18 (permalink)  
Old 09-13-2017, 9:48 AM
W9BU's Avatar
Lead Wiki Manager
  RadioReference Database Admininstrator
Database Admin
Amateur Radio Operator
Amateur Radio
 
Join Date: Jul 2004
Location: Brownsburg, Indiana
Posts: 4,732
Default

As I've stated before:

Quote:
If we make the Wiki too complicated and challenging to edit, I think we risk losing user contributions to the Wiki.
Let's try to keep things simple. The whole idea of the Wiki is that is less structured than the DB.
__________________
Lead Wiki Manager and Forum Moderator.

"The whole world's living in a digital dream. It's not really there, it's all on the screen." -- WB6ACU
Reply With Quote
  #19 (permalink)  
Old 09-13-2017, 10:03 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2012
Posts: 1,878
Default

Quote:
Originally Posted by ka3jjz View Post
I noticed that infobox template is being built based on the trunk type- in this case, Project 25 phase 2. While it looks nice, it's opening up a HUGE can of worms.
From my chair, I see no can of worms being opened here.

Quote:
Originally Posted by ka3jjz View Post
Are you planning on going through every state and province, adding a new infobox for each, then adding new templates for everything that uses NXDN and DMR trunking?

That's where this is heading...
Completely incorrect assessment/guess and conclusion. The new Infobox_TRS... templates are first type-specific, then (as was in the earlier generation of templates) by US or CA/Canada. I am not creating InfoBox_TRS... templates based upon states or provinces.

Quote:
Originally Posted by ka3jjz View Post
Not to mention the cleanup that will be necessary to remove all the orphaned templates once the conversion is done. I doubt Bob would be looking forward to doing that (heh)
Again, inaccurate/incomplete assessment and conclusion. When I am done, there will only be nine (9) Infobox_TRS templates that will need to be deleted because they will no longer be used at that time.



Quote:
Originally Posted by W9BU View Post
As I've stated before:
Let's try to keep things simple. The whole idea of the Wiki is that is less structured than the DB.
The new versions of the Infobox_TRS... templates do not create more structure in the Wiki than the old Infobox_TRS... templates did/do. Any Wiki-editor is as free in choosing their page design now as before. As mentioned earlier, too much simplicity is what led to the problems we have with the Infobox_TRS... templates that are being replaced. They are templates that were created when the Wiki had one primary type of TRS (Moto Type II), and were updated to handle P25, then P25P2, then TRBO, then NXDN, then Tetra, etc. The revisions made the "simple" Infobox_TRS templates convoluted and unusable, hence the need for newer templates.

The new Infobox_TRS templates simply...
(1) present the TRS' information in a more readable format in the box,
(2) eliminate incorrect/unused fields that do not relate to the particular TRS' system-type,
(3) follow the existing/pre-established owner-type groups found on (nearly) every "Trunked Radio Systems (ST)" page (education, public, private, utility, etc.), which makes it easier to maintain those static lists because of the templates' "What Links here" feature,
(4) make it much more obvious which TRS is being referenced so that when TRS's get renamed in the DB, or worse when a TRS name is reused verbatim in the DB for one of a newer type, then the existing Wiki page (for the old TRS) is not confused with the new TRS, as has happened _many_ times in the Wiki heretofore, and can be appropriately preserved and deprecated if needed.

Hope this helps,
__________________
73 QDP
Reply With Quote
  #20 (permalink)  
Old 09-13-2017, 11:15 PM
Wiki Admin Emeritus
  Amateur Radio Operator
Amateur Radio
 
Join Date: Jul 2002
Location: Bowie, Md.
Posts: 20,599
Default

I don't think you understood what I was questioning. If you look in the list of templates just for Phase 2, you have one that is just for the US, military, military multi county, military multi state, public, public multi county, public multi state, utility, utility multi state; roughly 24 in all.

The logical progression of this is that this pattern would be extended for TRBO and NXDN trunks. This would mean a HUGE amount of work to convert all the trunked system articles, and you would eventually need to drop the originals (all right I will accept your 9 - I think there's more but I could be wrong...). In addition, the one you have coded that says 'US' on it suggests that, at some point, you would need one for Canada, and other countries that we have in the wiki. And each of them would require a series of infoboxes for P2, DMR, etc.

And it's all unnecessary.

It may well be more readable, but it's absolutely less flexible. By using the various warning templates, variations on the original 9 can be easily coded. And here's the kicker - if a new trunk type were ever to be identified, you are painting yourself into a corner by having to create numerous new infoboxes to maintain the pattern. The way it is now, all you'd need to do is to create a new warning template and apply that where needed.

Needed? In my not-so-humble opinion, no. More complex? Yes, most definitely. Potentially setting up additional confusion (even now, folks aren't always sure as to which infobox template to use, when they do use them) as to which infobox to use? Without a question.

This is an unnecessary exercise. You're free to do as you wish, of course, but I think you're making a huge mistake in making things a heckuva lot harder for folks to use. This path seems to be somewhat similar to the one the database uses - even money says that a page with a hard coded message for Phase 2 was built for these systems.

Do we really want to go down that rather inflexible path?

Mike
__________________
links editor, Utility Monitoring Central
HF Forum moderator, RadioReference
Friends don't let friends buy Scancat Lite Plus!

Last edited by ka3jjz; 09-13-2017 at 11:42 PM..
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 6:33 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions