This code is broken in many non-obvious ways...
Closed this issue · 3 comments
The code itself is not broken, but some of the conventions it uses are. Read last post for resolution.
Just a word of warning to others who might spend a day of their lives trying to get this to run: Compiling this source on OS X (High Sierra) as well as on Ubuntu 16.04 I cannot get this to run and produce any useful output other than a topo map of SRTM tiles - but even there, it doesn't plot the city names from the city list. If one omits the path to the SDF files, the city names are plotted, but in East/West reversed order around the transmitter position defined in the QTH file. Furthermore, the tiles that are loaded/selected for a given range around the QTH position appear to be only loosely related to the actual range given on the command line.
I then suspected the original author(s) only used this software in the contiguous US where latitudes are positive and longitudes are negative, so I "transported" my scene into the US by adding/subtracting lat/lon to make it match a central US location. The software still failed in the same way. Digging into the source code I found that internal calculations are done in non-SI units, in fact, the -metric command line parameter leads for metric input to be converted to magical snake potion units. I think that was about the point where I decided to give up... a shame, this looks like it could be extremely useful for propagation analysis. If it worked.
Did you seriously just post a malicious review attempting to undermine the core accuracy of this (20 year old) software because you didn't get an answer to the issues you raised only yesterday, one of which was in-fact user error?
For a long list of scientific institutions and organisations who read the manual and have the patience to use SPLAT! succesfully see here:
http://www.qsl.net/kd2bd/splat.html
My review is not malicious, although I admit to it being perhaps a bit tongue in cheek, I'm not a fan of the imperial system(s) as you might gather, but my review of problems encountered sadly is mostly accurate. Malicious is when I instruct you how to fix your code knowing that it will introduce more problems. I don't do that.
When putting software (20 year old or not) on github, the maintainer assumes a minimum duty of care, a responsibility that is taken seriously by most who host software on git. The code I found in this repo is not only broken in many non-obvious ways (as the titles states), it is also a dozen or so commits behind some of the forks that have been made which seem to address some of the problems, which leads me to believe the owner of this repo isn't interested in keeping things up to date, considering the fork owner has tried to merge back to this but apparently was not successful.
I understand you're unhappy to see a list of problems posted. Likewise, I hope you understand that I'm unhappy that I spent a perfectly good day of my life trying to figure out why this software doesn't even perform the most basic of functions it advertises in the documentation without falling over. The most basic function being the plotting of a topo map with place labels.
I'm closing this as most most of the problems I fund went away when using eastings instead of longitudes in the input files. If it's an eastern longitude, make it negative.
This is great lesson illustrating why it's a bad idea to mix units with the same name but different meanings. If you're using the term longitude in the context of earth position reference, the convention used in GIS, aviation, science, you name it, is that eastern longitudes are positive, western longitudes are negative. For some reason, the original authors of this software changed this around.