Read TX and RX locations from a CSV file

[KyleMaas]

It would be great if we could read a list of TX and RX locations from a CSV file instead of having to specify them as individual files on the command line.

[hoche]

I'm thinking about using JSON for this, and combining the data in the lrp and qth file together into a single JSON object, then having the input file be a list of those objects.

Is there any reason to use CSV for this instead? The main reason to use something like JSON is that the specific fields can be in any old order. The "you have to get it exactly in the right order or I'll consider it wrong" thing drives me crazy.

[KyleMaas]

The main use case I can think of is that the average person could specify them using a spreadsheet program like LibreOffice without any knowledge of the format other than column order. If it makes you feel better about the specific field ordering being too opaque, you could include a starter CSV with column headings and a single row of sample data, just to get people started off on the right foot. While I like JSON for general data interchange (especially compared to YAML) and think it would also be a great option to add so Splat could be more easily used like a library for another larger UI, I don't see it as a particularly user-friendly choice for direct input of data by an end user.

[hoche]

Ok, yeah, I can see how that'd be useful. Initial thoughts:

• I'd still like to have a JSON feed, but it shouldn't be too hard to support both JSON and a CVS format. Either would be better than the current file formats that require things to be in a specific order.
• I'd probably require canonical names in the first line, to serve as field mapping indicators.
• As mentioned earlier, combine TX and LRP file data into one line? As near as I can tell, the only real advantage to having site files be separate from LRP files is that then you can check for propagation in the other direction by swapping the names of the tx and rx file names and keeping the lrp file name the same. On the otherhand, that's a silly way to do it, and if that's the case there should just be a -lrp switch on the command line and removing the "lrp file has to have the same name as the tx file" thing.
  Another option would be to have the CSV be able to have a column that has the path to an LRP files for each tx site, but at that point the user would be cut'n'pasting those paths repeatedly and maybe it'd be just as easy to cut'n'paste the actual LRP data.
  With JSON I could just refer to a different object in the submitted data, but CSV makes that harder, or at least more repetitive.
• I really need to improve the lat/long parsing to take more formats, and do that as part of the E/W fix in the submitted PR.

[davidsrsb]

This single line risks growing if you need to manage antenna patterns as well.
I rarely use antenna tilt
I do use a mix of omnidirectional, panel and back to back panel with a 3 dB splitter on TETRA projects, so likely at least 3 antenna patterns, each with unique azimuth per site.
I had complex patterns for terrestrial TV broadcast as well.
The current qth file as base file name system looks clumsy, but is flexible.

[KyleMaas]

@hoche I guess I would tend to think that combining TX and LRP into one line makes more sense to me for CSV instead of specifying LRP filenames. But then to @davidsrsb's point, you could say "you can only do basic stuff with CSV, for anything more advanced use a different format" so it doesn't balloon out of control as more features are added. I don't think CSV is the ideal format, nor does it need to be a universal format that can do everything the other format readers could do. But it would sure make for a nice easy user interface for editing by offloading all of that work to a separate spreadsheet program for at least the basic use cases.