Tracktable 1.7.1

[atwilso]

This is the release that was supposed to be Tracktable 1.7.0... but with the release bugs fixed. The release notes below are a combination of the things we fixed for 1.7.1 and what we added for 1.7.0.

New Features

• Linux wheel-building scripts will now attempt to build Tracktable for
  all versions of CPython newer than 3.6 that are available in the
  manylinux wheel. This improves on previous work where we used a
  hardcoded and oft-duplicated list of versions to build.

• The manylinux tag is now a CMake argument. We will continue to default
  to manylinux2014 for the moment but when it comes time to change that
  we will only need to update it in one place.

• We now control wheel building with setup.cfg and pyproject.toml
  instead of the outdated python setup-generic.py. This puts our
  build process on much sounder footing and will work better with
  the conda-forge build process.

• The function libraries used by the MacOS CI scripts and wheel-building
  scripts have been consolidated to remove duplication.

• Large files in tracktable-docs and tracktable-data have been moved
  into Git LFS.

• Maps in Folium can now be created with the attr and crs
  parameters. The attr argument is used to pass an attribution string
  for custom tile sets. The crs argument names a coordinate transform
  to project geographical points into pixel coordinates and back. The
  functions tracktable.render.render_trajectories.render_trajectories()
  and tracktable.render.render_heatmap.render_heatmap() both support these
  new arguments.

• Trajectory maps in Folium can be animated. See the arguments animate,
  anim_display_update_interval, anim_trail_duration, and use_markers
  in tracktable.render.render_trajectories.render_trajectories().

• New function tracktable.rw.load.load_trajectories() that will load a
  .traj, .csv, or .tsv file and assemble points into trajectories.
  An optional flag will cause it to return points instead of trajectories.
  Examples that load trajectories or points have been updated to use this
  feature.

• Sea ports and airports can be rendered into maps for both the Cartopy
  and Folium back ends.

• Docs and data have been separated out into their own repositories
  implemented as submodules. Note that you will need to git clone --recursive
  when cloning the source code.

Bug fixes

• There is a compile error caused by a ternary expression inside a
  constexpr in tracktable/ThirdParty/catch2.hpp. This is an error because
  of some new rules in GCC. The fix is to eliminate the ternary expression
  and just set the stack size for Catch2 to 32K.

• We now include boost-cpp in the Anaconda dependencies for our build
  and runtime environments. In some situations, compiled libraries in
  Boost that we rely upon were only present in that package.

• Fixed a typo in setup-generic.py that broke wheel building.

• Switched to libmamba solver on ReadTheDocs. Without it, our builds
  time out while waiting for conda install to decide what packages
  it wants.

• Fixed an unbound variable error in build_osx_wheels.sh when a
  wheel output directory was explicitly specified.

• Fixed a problem that led to great-circle fitting returning numerically
  incorrect answers.

• Removed deprecated uses of std::unary_function<>. This was deprecated
  in C++11 and removed entirely in C++17.

• We identified and fixed a problem with the I/O library that could cause
  a buffer overflow if the user opened a file containing UTF-8 data in
  Python in text mode and then passed it to one of Tracktable's loaders.

• Map scale bars were being rendered incorrectly in static images under
  map projections that did not use geodetic coordinates (longitude/
  latitude) as their native coordinate system.

• Tests for C++ point generators and great circle estimation were failing
  because points did not initialize their coordinates by default. Fixing
  this results in a very minor slowdown.

• Setting a point property's value to None no longer crashes the interpreter.

• DeprecatedDeclaration.h was not being installed when the user called
  make install.

Known issues

• The documentation for tracktable.rw.load.load_trajectories() implies
  that it takes a file-like object as its input. It does not -- it takes
  a string containing a filename.

• Documentation for tracktable.rw is not picking up the module contents.

• There are a few files in the wheel (Jupyter notebooks and response files) that really don't belong there. They are harmless but should be removed.

Other changes

• The data generators in tracktable.examples.data_generators have now moved
  to tracktable.data_generators.

• Movies can be rendered directly from tracktable.render.render_movie.render_trajectory_movie
  now. This subsumes the code that used to be in the
  movie_from_trajectories example.

• Jupyter notebook tutorials are built locally and stored in a
  separate repository (tracktable-docs) so that we no longer run
  into the CPU usage limits when uploading to ReadTheDocs.

• The latest release branch in our repository is now called main,
  not master.

• Sample data has been moved into a separate repository (tracktable-data)
  to help keep the Tracktable repository itself small(er).

Infrastructure and Support

Python 3.6, 3.7 no longer supported

We no longer officially support Python 3.6 or 3.7. Python 3.6 stopped
getting security updates in December 2021. Python 3.7 stopped getting
security updates in June 2023.

Having said that, we have not yet made any changes to the code that
actually require Python 3.8 or newer.

If you need to build and run Tracktable 1.7 in an environment where you
absolutely cannot update to a more recent Python version, contact us.
We sympathize -- we have plenty of experience with such environments --
and we'll work with you to get you up and running.

Wheels available on PyPI, GitHub

We are now building wheels for Python versions up through 3.11. On Linux,
we build and upload wheels to PyPI for Python
versions 3.6 through 3.11. On Windows and MacOS (Intel), we build wheels
for Python 3.8 through 3.11. On MacOS (Apple Silicon/arm64), we build
wheels for Python 3.10 and 3.11.

Internal changes to build infrastructure

We've moved all of our Linux build infrastructure to Docker containers
for easier management. This also helps us build wheels with the manylinux
standard that are usable on most common distributions. Along the way,
we've integrated test coverage and code linting into our CI pipeline.

We're planning to do something similar for our Windows builds now that
Docker on Windows hosts can run containers with the Windows kernel.

MacOS build and test procedures are still run via shell scripts due to
the lack of container support in the MacOS kernel.

---

This discussion was created from the release Tracktable 1.7.1.