Once we supported converting UIView log files into Xastir log files
so that we could pull them in as additional data. This was done using
a script, UIView2XastirLog.pl.
This script is outdated and unnecessary to be included with our source
tree. It has never been installed as part of an Xastir installation,
and just clutters the source tree.
c.f. #336
The Xastir project no longer builds RPM files, either for source or
for binaries. The BUILDRPMs script is woefully outdated (last updated
in 2016 prior to the 2.0.8 release and before we moved to git) and no longer
needs to be cluttering the scripts directory.
c.f. #336
The scripts directory had a number of scripts that have been useless
for a long time.
- mapblast2geo.pl was created to allow users to download map images
from a site called mapblast (which was one of the most popular map
sites in the 1990s) and use them as base layers in Xastir.
Mapblast was acquired by Microsoft in 2002 and shut down shortly
thereafter.
- ridge_radar.pl was a script to download weather radar images for
use in Xastir. The site it referenced went down many years ago,
and the same data is available through the national weather
service's WMS servers via the Online/NWS geo files we provide.
- two scripts, toporama250k.pl and toprama50k.pl were used to access
topographic map images of Canada. The URLs referenced in these
scripts have not worked for years, and the scripts were last
meaningfully updated in 2005. Toporama still exists, but these
scripts are no longer helpful methods of accessing the data
there. Users needing access to Toporama map data will need to
determine how to do so using other means.
These scripts are being removed as part of cleanup of the scripts
directory.
c.f. #336
Our scripts directory contained a file, "example_objects.log" that was
clearly intended as a test input for various object types.
It was, however, filled with nothing but *item* packets, and had
incorrectly padded item names (the spec says that item names are only
padded with spaces if they are less than three characters). It has
been in the repository since Xastir was first imported into CVS. It
has not been modified except to update its copywrite date since 2002.
It is now clutter of the scripts directory and is being removed.
c.f. #336
NWS changed their files right after we updated get-NWSdata to get the
3 March versions, and delayed implementation until 16 April.
I had previously set up get-NWSdata to exit with a non-zero exit code
if any dbfawk files were out of date, but I failed to make it do so if
any files failed to download.
Had I done so back in commit ee337c07, the automated github testing we
do on every commit would have pointed out the problem to us long ago.
Instead, it was silently "passing" the get-NWSdata test precisely
because it was failing to download any files and wasn't causing an
error exit.
Now, if either download of a file fails *or* dbfawks are out of date,
the script will exit with exit code 1, and it will exit with exit
code 0 only if all downloads succeeded and all dbfawks work. It will
report at the end which downloads failed and which dbfawks are out of
date.
Had this code been in place earlier, we would have known that NWS
pulled the rug out from under us the day it happened instead of 4
months later and after having inconvenienced users.
C.f. #390
While we had made sure that Xastir 2.2.4 had correct get-NWSdata
information for the NWS shapefiles that were released on 3 March, they
apparently then turned around and released another set on 16 April.
The new set requires an updated DBFAWK file for the hz coastal and
offshore marine zones file.
Closes#390
NWS has issued new shapefiles for use after 3 March 2026.
This commit updates get-NWSdata to assure we're ready for it. I have
confirmed that NWS did NOT change any shapefile signatures and so this
will be good to go on 3 March 2026.
Closes#349
Make all copyright notices include this year.
Most say "2000-2026" but some files created later had later start
dates, and some created last year only had the start date. They now
all have "-2026" regardless.
Closes#340
We are using get-NWSdata in CI testing now to make sure we catch when
our shapefiles for weather alerts don't have matching dbfawk files.
But the script exited cleanly whether we have 'em or not, even though it
reported when it found that some didn't work.
Make the script exit with error code one if any dbfawk doesn't match,
and report which ones don't so we know what has to be fixed.
This will make CI builds fail if any NWS changes break a dbfawk, and
call it to our attention when it happens.
Under normal circumstances, developers have to change get-NWSdata
manually every time NWS issues new shapefiles, and proper process
should be for us to *run* the thing ourselves after changing the
download links to make sure the dbfawks are right. But if that were
to be forgotton, CI will now be there to tell us we've screwed up.
Xastir went through a lot of work to make the code compatible with the
Linux Standard Build (LSB), but LSB is a dead project since 2015.
Keeping scripts and ifdefs and configure tests all over the place to
support a way of supporting LSB makes no sense and bloats the code and
repo.
Closes#324
GNIS files ceased to be useful map sources in 2009. A lengthy
discussion on the xastir@xastir.org mailing list (currently
unavailable for either posting or viewing the archives) ensued because
the map_gnis.c code was changed to recognize the new format, but was
not changed in any way to *use* them properly. Old format files were
supported by creation of a "map_pop.c" renderer, and old files were
made available on a couple of servers that are long gone.
README.MAPS still documented the state of GNIS use prior to 2009.
This commit removes the get-gnis script, the split_gnis.bash script,
and the split_gnis.pl script.
get-gnis tried to download post-2009 GNIS files from a server that
doesn't exist anymore (the base URL redirects elsewhere, where one can
find ONE file that Xastir can use). The two split_gnis scripts were
designed to break out state-level GNIS gazetteer files into
county-level files to allow them to be usable on 2004 vintage
computers. They relied on the old, pre-2009 format of GNIS files to
work, and would be worthless on any files from after 2009. The slow
map rendering that was of great concern in 2004 is less of an issue
now.
Closes#316
Remove the get-pop script as it points to data that is no longer
there.
Update the get-NWSdata script to point at the current versions of the
files. New versions go into effect on September 10th and the script
should be updated again then.
Closes#35.
NWS has changed its data files again, and has made a change to the
field names in the "w" file. The only change to the field name is
that they're all upper case now, whereas previous versions were mixed
case.
This commit updates get-NWSdata to make it download the new shapefiles
and adds a new dbfawk file to make it work with the new "w" shapefile.
Closes#196
Prior to our move to git, Xastir used to put the date it was compiled
into the Help dialog. We stopped doing that, partly because it was
not that informative, but also because it made the build
"non-reproducible" (two consecutive builds of Xastir from the same
source code produced binaries that were not byte-for-byte identical).
For a while now, we've been inserting the git SHA-1 from which the code
was built into the Help dialog. This only happens if the Xastir
source tree has a ".git" directory --- so it will not happen if Xastir
is built from a tarball, or if someone has unpacked Xastir sources
into their own git repo (as is done by some Linux packaging systems).
The purpose of putting the git sha in there was so that users of
Xastir from the development git repo could know how current their
build actually is just by looking at the Help->About dialog and seeing
if it's the same as the one in their git tree.
Until now, Xastir's release tags have all been on dead-end branches,
or were old CVS release tags. Thus, the most information we could get
out of git was the SHA-1 of the current commit being built.
Now that we've changed our release process so that release tags are
reachable from the head of master, "git describe" becomes a more
informative way of identifying the code.
I am changing XastirDateStamp.sh to populate the gitstring variable
with the output of "git describe --dirty" instead of the old git log
command it used. This will now populate the Help dialog with a string
like "Release-2.1.8-1-g8de3f8a1-dirty", which means "1 commit past
release 2.1.8, git SHA g8de3f8a1, with uncommitted code present".
Now you can not only tell what the last commit was, but whether
you're running *that* code or some modified code, and how many commits
have happened since the last release.
The FCC has moved the URL for l_amat.zip and the old one no longer
redirects to it. Trying to run get-fcc-ac.pl with the old URL fails
now.
I hunted down the new link and have updated the script. It works again.
Zip files can now be downloaded without a date stamp,
but the unzipped file still has a date stamp in the filename.
Determine the unzipped filename on the fly so the date stamp
does not need to be hard coded.
Closes#162
As noted in previous commit, http: worked fine, but https: is more
correct because the server redirects anyway. But I forgot to change
both URLs in the file in my first commit.
Further addresses #161
Xastir_tigerpoly.py was a script that used GDAL python bindings to
convert the ancient topological format TIGER/LINE map files to simple
shape shapefiles.
Apparently this script requires python 2 (which is no surprise,
because it was written years before there was a python 3), and at
least one distro has made their Xastir package depend on python2
solely because of this script. As a result, Xastir is now slated for
removal from that distro's packages because they're removing python2.
A simpler approach would just be to drop the python dependency and let
this script simply not work, but that is not what was being done.
I am therefore removing this script from the Xastir distribution. The
old TIGER/LINE format was discontinued years ago, and is of little
interest to anyone. And anyone *that* interested in ancient mapping
data can resurrect this script from git history.
It's been a while since the bit-strings were checked against the
current assignments and the Mode-S group "Countries.dat" file.
Also the way the coding was done originally it was one big if/else...
Now it is more efficient as it checks shorter strings first by
country, then if a country match, goes into a block which has
country-specific additional strings to check.
Add a .travis.yml that builds for Linux (two iterations) and MacOS.
Fix a bug where now that there is no *.sh files in the scripts
directory a chmod in "make install" was failing.
Wheen I replaced the non-portable "#!/usr/bin/perl" with the portable
"#!/usr/bin/env perl" I neglected the fact that some scripts have a -w
or -W argument after the command. This can't work with env, and the
correct approach is to put "use warnings;" in the script instead.
A lot of scripts in this directory had "#!/usr/bin/perl" hard coded at
their tops. This is wrong, because perl may not be installed
there (it isn't on a lot of non-Linux systems). I have replaced the
hard-coded path with "/usr/bin/env perl" which will locate the perl
binary in the user's PATH.
Some scripts in this directory already had that. Those are scripts
that I actually use myself on a system that has perl in
/usr/local/bin, and so I had already fixed them.
Another alternative to using /usr/bin/env would be to create a
configure test to find the perl binary, then substitute it in a .in
version of the script. That is more work, for negligible benefit.
The script snippets "values" and "values.pl" were generated from
"values.in" and "values.pl.in", respectively, at configure time. A
handful of scripts then included (via "source" for shell or "require"
for perl) these snippets for no reason other than to obtain the
install prefix given in the "--prefix" option to configure.
The result was that the scripts themselves would ONLY work if run
from the installation directory, OR if one ill-advisedly builds Xastir
in its own source tree --- if one followed the recommended procedure
of building out-of-source, the scripts would be broken because
values (or values.pl) don't live in the same directory as the script.
This commit does away with values and values.pl entirely, and has
configure scribble the prefix directly into the scripts themselves ---
in exactly the same manner as it had been scribbling into the values*
files.
I am also removing xastir-migrate.sh and xastir-fixcfg.sh. These two
scripts were added in July of 2003 when the Xastir project reorganized
how Xastir installs itself. At the time anyone who was running older
code would have had to move a lot of data and fix up their .cnf files
to upgrade to the new code and not lose settings and maps. These
scripts did that for them so they didn't have to figure anything out.
But nobody is running 2003-vintage Xastir anymore, and if they were,
the right answer to "why isn't Xastir finding my maps and other
configuration" would be "Because you need to wipe out your old install
and start over" not "run this 16 year old script."
Curt asked me to make this one-line change for him.
His statement was that:
With this change aircraft don't jump forward with dead-reckoning, then jump
backwards when new plane data comes in that doesn't have lat/long.
