RRDB Table Formats

[MarkEagleUSA]

Is there a reason why there's no consistency in the RRDB conventional table layout? Here's the headings from the first 4 entries in my "home" county:

Frequency  Input  License  Type  Tone  Description  Mode  
Frequency  Input  License  Type  Tone  CH  Description  Mode  
Frequency  License  Type  Tone  Description  Mode  
Frequency  License  Type  Tone  CH  Description  Mode

It seems like having one format for conventional data would make copy & paste easier, especially if going through something like Excel to parse the data for entry into ones favorite scanner programming app.

There also appears to be an extra trailing "space" (or some other character) at the end of each data field as well. For example, 154.29500 is actually "154.29500 " when copied. Most of the software apps don't like that.

 

[Al42]

Is there a reason why there's no consistency in the RRDB conventional table layout? Here's the headings from the first 4 entries in my "home" county:

Frequency  Input  License  Type  Tone  Description  Mode  
Frequency  Input  License  Type  Tone  CH  Description  Mode  
Frequency  License  Type  Tone  Description  Mode  
Frequency  License  Type  Tone  CH  Description  Mode

You'll notice that there's different information in each line.

Granted, normalization would make things easier - this way we have to copy/paste in groups for some systems/counties, rather than copy the page, paste it, remove unwanted lines and let Excel take care of the rest. The current format makes making a single template for all conventional listings just about impossible. (Although I have one that makes things a bit easier.)

Then, again, it's easy for me to talk - I wouldn't have to redo the site if it's decided to redo it.

 

[FPO703]

Because each DB admin does things a bit different.

We may not have all of the information (output/input/callsign/channel number/CTCSS tone/Alpha Display,etc...)

We display the information that is known.

If you have information that isn't already included in the RRDB, by all means, submit the information and we'll include it.

 

[MarkEagleUSA]

We may not have all of the information (output/input/callsign/channel number/CTCSS tone/Alpha Display,etc...)

That's quite understandable. I was just wondering why the table format isn't fixed so as to be uniform.

If you have information that isn't already included in the RRDB, by all means, submit the information and we'll include it.

If I ever stumble across anything useful, I'll certainly submit it. My question, however, was only regarding the format/layout used to display the info.

 

[MarkEagleUSA]

You'll notice that there's different information in each line.

Granted, normalization would make things easier

Hence my question.

I wouldn't have to redo the site if it's decided to redo it.

I would hope it's at least a semi-automated task that could be fixed programmatically.

 

[Al42]

I would hope it's at least a semi-automated task that could be fixed programmatically.

I'd hope that the page is linked to the database, so that any entries/changes/deletions are automatically shown on the page. A single page template would make it trivial to make all conventional listings uniform. Of course that would also result in a lot of wasted real estate, but I'd rather that, or XML output of conventional listings, than non-uniform listings.

Of course, I'd rather have what we have than nothing. There's a huge difference between this and nothing, and only a small difference between uniformity and this.

 

[MarkEagleUSA]

Of course that would also result in a lot of wasted real estate, but I'd rather that, or XML output of conventional listings, than non-uniform listings.

I would think the real estate issue is trivial. Conventional XML (and a reader/parser for it) would be great!

Of course, I'd rather have what we have than nothing.

Agreed, but there's nothing wrong with striving for perfection either. :wink:

 

[Al42]

Of course that would also result in a lot of wasted real estate, but I'd rather that, or XML output of conventional listings, than non-uniform listings.

I would think the real estate issue is trivial. Conventional XML (and a reader/parser for it) would be great!

That part is trivial. I could modify one of my existing ones to produce a .usd file from XML.

 

[loumaag]

Well as has been pointed out, if the data is not available, generally the field is suppressed, of course this is by group heading. In another words if just one repeater output is paired with the input but no other inputs are known you are going to have blanks.

As to the trailing blanks pointed out by someone earlier, well they should not be there; and I am willing to bet that they are not blanks at all but some control character which ended up in somebody's submission. This generally happens when people submit from programs like Excel or a word processing program using Tabs. (I say this, becuase leading and trailing spaces " " are stripped in the update to DB process.)

Now as to the XML output. It is my understanding that Lindsay is working on that so that download will be available in the future, in a fashion like it is available for TRS entries. Things do not happen over-night. Remember, this site did not exist in it's present form before Feb. 28, 2004. :wink:

 

[Al42]

Well as has been pointed out, if the data is not available, generally the field is suppressed, of course this is by group heading.

The point, though, Lou, is that it would be a lot easier to copy/paste to a fixed format (like an Excel template) if the field were just left blank, not completely eliminated.

Now as to the XML output. It is my understanding that Lindsay is working on that so that download will be available in the future, in a fashion like it is available for TRS entries. Things do not happen over-night. Remember, this site did not exist in it's present form before Feb. 28, 2004. :wink:

Which would render the above moot.

 

[loumaag]

Well as has been pointed out, if the data is not available, generally the field is suppressed, of course this is by group heading.

The point, though, Lou, is that it would be a lot easier to copy/paste to a fixed format (like an Excel template) if the field were just left blank, not completely eliminated.

Oh, I understood your point. I believe it was a desired effect, not done by accident. Copy/Pasting was not ignored but was deemed less important than clean screen display. (If I remember the topics discussed almost 2 years ago now. :lol: )

 

[MarkEagleUSA]

Copy/Pasting was not ignored but was deemed less important than clean screen display.

Not trying to be obstinate here, but if you're maintaining a database the old fashioned way (on paper! :shock: ), you'd likely have a uniform table layout with blank columns.

For ease of use (read: copy & paste) and until (if?) XML conventional data is made available, a uniform RRDB table would be preferred, wouldn't it?

 

[K5MAR]

Gota agree with Mark here, a standardized format would be very helpful, if there is nothing to put in a column, leave is blank, mark in N/A or something like that. It may come as a shock to some of you, but some like me aren't interested in using XML, RSS, or whatever the latest flavor of the month is. When I copy from the database, I paste it to Notepad and save the file with the appropriate name. I may be old-fashioned, but I like hardcopy, I print the files and mark 'em up with pen, pencil and/or highlighter. Then I type in the data I want, or maybe cut'n'paste it from Notepad. It may not be the latest and greatest, but it works for me.

Mark S.

 

[blantonl]

Folks, I made a conscious decision to supress fields in a table that had no data in them -- if the entire table has no PL tones, or an A/D representation, or an FCC license, I don't see the need to send a bunch of blank cells to the page.

On the trailing whitespace, it's beceause it looks better in the table. I suppose I could use cell spacing and padding, but it was easier with the whitespace approach.

Data transfer and exchange will be done through XML, always, that is the direction. However, I'll take your suggestions to heart and potentially add a CSV download function for those who might find that useful....

XML and PDF are coming soon to the conventional database.

 

[KW4EZR]

XML and PDF are coming soon to the conventional database.

Great news, I asked about XML a while back on the conventional side, can't wait. This will make Don Starr's WIN96 and Win97 software so nice and easy to use for trunked and conventional use. (that is if he adds conventional import to the software) I love Radio Reference and visit the site many times a day. Keep up the great work.