pure-Python (Numpy optional) 3D coordinate conversions for geospace ecef enu eci

Geospace code

Last update: Dec 29, 2022

Related tags

Overview

Python 3-D coordinate conversions

Pure Python (no prerequistes beyond Python itself) 3-D geographic coordinate conversions and geodesy. API similar to popular $1000 Matlab Mapping Toolbox routines for Python PyMap3D is intended for non-interactive use on massively parallel (HPC) and embedded systems.

API docs

Thanks to our contributors.

Similar toolboxes in other code languages

Prerequisites

Pymap3d is compatible with Python ≥ 3.7 including PyPy. Numpy and AstroPy are optional; algorithms from Vallado and Meeus are used if AstroPy is not present.

Install

python3 -m pip install pymap3d

or for the latest development code:

git clone https://github.com/geospace-code/pymap3d

pip install -e pymap3d

One can verify Python functionality after installation by:

pytest pymap3d -r a -v

Usage

Where consistent with the definition of the functions, all arguments may be arbitrarily shaped (scalar, N-D array).

import pymap3d as pm

x,y,z = pm.geodetic2ecef(lat,lon,alt)

az,el,range = pm.geodetic2aer(lat, lon, alt, observer_lat, observer_lon, 0)

Python argument unpacking can be used for compact function arguments with scalars or arbitrarily shaped N-D arrays:

aer = (az,el,slantrange)
obslla = (obs_lat,obs_lon,obs_alt)

lla = pm.aer2geodetic(*aer,*obslla)

where tuple lla is comprised of scalar or N-D arrays (lat,lon,alt).

Example scripts are in the examples directory.

Functions

Popular mapping toolbox functions ported to Python include the following, where the source coordinate system (before the "2") is converted to the desired coordinate system:

aer2ecef  aer2enu  aer2geodetic  aer2ned
ecef2aer  ecef2enu  ecef2enuv  ecef2geodetic  ecef2ned  ecef2nedv
ecef2eci  eci2ecef eci2aer aer2eci geodetic2eci eci2geodetic
enu2aer  enu2ecef   enu2geodetic
geodetic2aer  geodetic2ecef  geodetic2enu  geodetic2ned
ned2aer  ned2ecef   ned2geodetic
azel2radec radec2azel
vreckon vdist
lookAtSpheroid
track2 departure meanm
rcurve rsphere
geod2geoc geoc2geod

Additional functions:

loxodrome_inverse: rhumb line distance and azimuth between ellipsoid points (lat,lon) akin to Matlab distance('rh', ...) and azimuth('rh', ...)
loxodrome_direct
geodetic latitude transforms to/from: parametric, authalic, isometric, and more in pymap3d.latitude

Abbreviations:

array vs scalar

Use of pymap3d on embedded systems or other streaming data applications often deal with scalar position data. These data are handled efficiently with the Python math stdlib module. Vector data can be handled via list comprehension.

Those needing multidimensional data with SIMD and other Numpy and/or PyPy accelerated performance can do so automatically by installing Numpy. pymap3d seamlessly falls back to Python's math module if Numpy isn't present. To keep the code clean, only scalar data can be used without Numpy. As noted above, use list comprehension if you need vector data without Numpy.

Caveats

Atmospheric effects neglected in all functions not invoking AstroPy. Would need to update code to add these input parameters (just start a GitHub Issue to request).
Planetary perturbations and nutation etc. not fully considered.

Notes

As compared to PyProj:

PyMap3D does not require anything beyond pure Python for most transforms
Astronomical conversions are done using (optional) AstroPy for established accuracy
PyMap3D API is similar to Matlab Mapping Toolbox, while PyProj's interface is quite distinct
PyMap3D intrinsically handles local coordinate systems such as ENU, while PyProj ENU requires some additional effort.
PyProj is oriented towards points on the planet surface, while PyMap3D handles points on or above the planet surface equally well, particularly important for airborne vehicles and remote sensing.

AstroPy.Units.Quantity

At this time, AstroPy.Units.Quantity is not supported. Let us know if this is of interest. Impacts on performance would have to be considered before making Quantity a first-class citizen. For now, you can workaround by passing in the .value of the variable.

Comments

Can't install using pip

When trying to install pymap3d on a fresh Ubuntu 16.04 installation using pip3, the following error is returned:

$ pip3 install pymap3d
Collecting pymap3d
Installing collected packages: pymap3d
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 209, in main
    status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/install.py", line 335, in run
    prefix=options.prefix_path,
  File "/usr/lib/python3/dist-packages/pip/req/req_set.py", line 732, in install
    **kwargs
  File "/usr/lib/python3/dist-packages/pip/req/req_install.py", line 837, in install
    self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/usr/lib/python3/dist-packages/pip/req/req_install.py", line 1039, in move_wheel_files
    isolated=self.isolated,
  File "/usr/lib/python3/dist-packages/pip/wheel.py", line 346, in move_wheel_files
    assert info_dir, "%s .dist-info directory not found" % req
AssertionError: pymap3d .dist-info directory not found

I also got the same error on another system using Mint 17.3. Any ideas ? Cheers,

opened by 2ar0n 11

eci2aer cross check against AstroPy

Thanks for porting over these MatLab codes! I was cross checking the eci2aer function with AstroPy before incorperating it into another project I am working on, but I must be missing something or these numbers are very far off...

from pymap3d.aer import eci2aer as eci2aer
from astropy.coordinates import SkyCoord, GCRS, EarthLocation, CartesianRepresentation, AltAz
from astropy import units as u
from datetime import datetime
import numpy as np

eci = np.asarray([-34320604.87943786,2010725.129018341, 2977059.1586334566]) # units in meters
lla = np.asarray([10.0,10.0, 100]) # units in degrees, degrees, meters
t = datetime(2020, 3, 15, 0, 0, 0) # time as a datetime object


sat = SkyCoord(x=eci[0]*u.m, y=eci[1]*u.m, z=eci[2]*u.m, frame=GCRS, 
               representation_type=CartesianRepresentation)
origin = EarthLocation(lat=lla[0]*u.deg, lon=lla[1]*u.deg, height=lla[2]*u.m)
sataltaz = sat.transform_to(AltAz(obstime=t,location=origin))

az, el, srange = eci2aer(eci[0], eci[1], eci[2], lla[0], lla[1], lla[2],t)

np.array(sataltaz.az)-az
#array([70.90364332])
np.array(sataltaz.alt)-el
#array([-120.90947987])
np.array(sataltaz.distance)-srange
#array([1.77086727e+11])

Is ECI ~ GCRS ? Any feedback is appreciated. If this is my error vice the projects, I will gladly delete this.

enhancement

opened by AshHarvey 10

Adding rcurve, rsphere, auxiliary latitudes, loxodrome_inverse, meanm, depature, meridianarc

Adding rcurve.py containing several functions that compute the radii of curvature for an ellipsoid. Adding rsphere.py containing several functions that compute the radii of auxiliary spheres. Adding latitude.py containing several functions that compute auxiliary latitudes and their inverse functions. Adding 'loxodrome_direct' to compute the end point of a loxodromic curve from a start lat/lon, azimuth, and distance. Fixing 'loxodrome_inverse', it previously failed on the degenerate case of east/west azimuth. Adding 'meanm' which computes the geographic mean of points on a spheroid. Adding 'departure' which computes the distance between two longitudes at a specified latitude. Adding 'meridianarc' which computes the distance between two latitudes along a specified longitude. Added 'thirdflattening' and 'eccentricty' attributes to ellipsoid definitions. Removed all instances of '%%' in comments.
enhancement

opened by ryanpavlick 9
Geocentric spherical coordinates are missing?

pymap3d is awesome, but seems to be missing a one basic coordinate system that would be useful: spherical ECEF. Currently one can do ecef2geodetic and vice versa, but not sph2geodetic and vice versa.

For example, if a user wants to convert geodetic lat/lon/alt to geocentric lat/lon/alt, they need to convert to XYZ ECEF with geodetic2ecef and then manually calculate spherical geocentric coordinates themselves. Is this by design? If not, would it be acceptable for me to submit a PR adding this to the library?

opened by asreimer 6
Overlap and collaboration with Harmonica
Hi @scivision, I've been developing a package for gravity and magnetic geophysics called Harmonica with @santisoler. We've been having the need for some coordinate conversions not found in proj4 and ended up implementing our own functions and an ellipsoid class. I recently thought of pymap3d and was poking around the code base again and there are some similarities with what we've been doing. I think there is opportunity for collaboration here and maybe porting some of our code into pymap3d. I always felt like these things were a bit out of place in Harmonica. Here are a few links:

Our ReferenceEllipsoid class and handling functions: https://github.com/fatiando/harmonica/blob/master/harmonica/ellipsoid.py

Conversion from geodetic to geocentric spherical: https://github.com/fatiando/harmonica/blob/master/harmonica/coordinates.py

Using ReferenceEllipsoid to compute Normal gravity: https://github.com/fatiando/harmonica/blob/master/harmonica/gravity_corrections.py#L10

I really like our way of handling ellipsoids across the library. We have a global default ellipsoid and ways of setting different (or custom) ellipsoids using context managers. For example, you can change ellipsoids like this:

import harmonica as hm # Set the ellipsoid globally hm.set_ellipsoid("GRS80") # Calculate with GRS80 normal_grav = hm.normal_gravity(latitude, height) # Set the ellipsoid locally with hm.set_ellipsoid("WGS84"): # Calculate with WGS84 normal_grav = hm.normal_gravity(latitude, height) # Set a custom ellipsoid ell = ReferenceEllipsoid(name="sphere", semimajor_axis=1, inverse_flattening=1, geocentric_grav_const=10, angular_velocity=1) with hm.set_ellipsoid(ell): normal_grav = hm.normal_gravity(latitude, height)

Functions that need an ellipsoid can get the currently set one by calling get_ellipsoid() and everything works. See these examples.

I really like this mechanic and I feel like it could work well with pymap3d. I don't what's the best way of moving forward but I wanted to make sure we're all aware of the two projects :slightly_smiling_face: Notice that we need more than a, b, f for our ellipsoids because of the gravity calculations (which could be made optional).

How committed are you to supporting the Matlab toolkit interface? If your primary goal is compatibility then it might not work well but I think there is a lot of room for improvement on the API front (many of these Matlab toolkits are a bit poorly design, IMO).

What do you think?
enhancement
opened by leouieda 5
Add conversion from geodetic to geocentric spherical

There is a function for converting latitudes from geodetic to geocentric but this is restricted to the surface of the ellipsoid. For many geophysical applications, we need to convert the (latitude, height) of points into (latitude_spherical, radius).

This is implemented in Boule as boule.Ellipsoid.spherical_to_geodetic. Boule is more focused on gravity calculations than coordinate conversions so I'd be happy to move that implementation to pymap3d if it's of interest to you.

I can volunteer to do this given a bit of guidance as to where to put the functions and what they should be called to fit with pymap3d.
enhancement

opened by leouieda 4
For Michael Hirsch, re: "Numpy / OpenCV image BGR to RGB"

Hi Michael,

I was looking through all of your contact information on scivision.dev, and couldn't find any email address.

I'm just here to report that your article at https://www.scivision.dev/numpy-image-bgr-to-rgb/ is very harmful. There are plenty of people taking that advice and linking to that page, which is why I have to reach you. I used to believe that the same technique was good, but it turns out that there's much more to BGR/RGB conversion than just modifying the "Numpy view" of the RAM storage. That's a "fake" conversion and doesn't actually work in real life.

Here's a full breakdown which explains what happens at a code-level in OpenCV when you give it such "faked" Numpy data:

https://answers.opencv.org/question/219040/fastest-way-to-convert-bgr-rgb-aka-do-not-use-numpy-magic-tricks/

The same is almost certainly true for matplotlib too.

With best regards, Johnny
question

opened by Bananaman 4
Install instructions
Part of openjournals/joss-reviews#580

It would be good to have more detailed install instructions. Things I found missing:

How to download the source (command to clone the repository or link to download a zip archive from Github)

How to install the Matlab version

Regarding the Python instructions, pip install -e is used for development but not recommended for deploying software because the user can't delete the source directory after install. I would recommend one of the following:

Make a release and upload to PyPI. Then the instructions should be: pip install pymap3d

Download the zip/clone the repo and install using pip: cd pymap3d; pip install . (no -e)

Install directly from master using pip: pip install https://github.com/scivision/pymap3d/archive/master.zip

1 is the best option but takes a bit more work to setup. With 3, you can also include instructions for installing specific versions using the same syntax but replacing master with the tag name (see #7). The problem with 2 and 3 is that they don't play well with dependency managers. So it's not easy for another package to depend on pymap3d.
opened by leouieda 3
pymap3d version 2.7.2 from conda-forge has import issues

When importing:

import pymap3d as pm

and invoking:

pm.vincenty.vdist(lat1, lon1, lat2, lon2)

raises the exception:

AttributeError: module 'pymap3d' has no attribute 'vincenty'

In fact, the imported module will no longer import the vincenty module, breaking code that needed pymap3d.vincenty.vdist

This behavior was not present in previous installations of the package.

opened by obbe79 2

loxodrome_direct still returns incorrect longitude when azimuth is close to 90 or 270

Thank you for fixing #42, the lox stability issue, and releasing the fix as v2.7.1. However, loxodrome_direct still returns incorrect longitude values, although is is improved before fixing.

The code is the same as one used in #42.

from pymap3d.lox import loxodrome_direct


clat, clon = 35.0, 140.0
az = [
    89,
    89.9,
    89.99,
    89.999,
    89.9999,
    89.99999,
    89.999999,
    90,
    90.000001,
    90.00001,
    90.0001,
    90.001,
    90.01,
    90.1,
    91,
]
tmp = [az_ + 180 for az_ in az]
az += tmp

for az_ in az:
    lat, lon = loxodrome_direct(clat, clon, 50_000, az_)
    print(f"{az_:.6f}, {lat:.14f}, {lon:.14f}")

This code prints lines like this in PyMap 2.7.1:

89.000000, 35.00786565022930, 140.54765888297607
89.900000, 35.00078660501723, 140.54771788308574
89.990000, 35.00007866054496, 140.54771634402164
89.999000, 35.00000786605369, 140.54771605442008
89.999900, 35.00000078660448, 140.54771541554422
89.999990, 35.00000007865957, 140.54770927042696
89.999999, 35.00000000786506, 140.54764724167964
90.000000, 34.99999999999901, 139.55133723928088
90.000001, 34.99999999213296, 140.54778537068364
90.000010, 34.99999992133847, 140.54772297468475
90.000100, 34.99999921339354, 140.54771678232532
90.001000, 34.99999213394431, 140.54771614079507
90.010000, 34.99992133945204, 140.54771583369782
90.100000, 34.99921339487867, 140.54771264295587
91.000000, 34.99213433955717, 140.54760647858132
269.000000, 34.99213433955717, 139.45239352141868
269.900000, 34.99921339487867, 139.45228735704418
269.990000, 34.99992133945204, 139.45228416630223
269.999000, 34.99999213394431, 139.45228385919867
269.999900, 34.99999921339354, 139.45228321768184
269.999990, 34.99999992133847, 139.45227702538708
269.999999, 34.99999999213296, 139.45221462306554
270.000000, 34.99999999999901, 139.55133723928088
270.000001, 35.00000000786506, 139.45235274366772
270.000010, 35.00000007865956, 139.45229076455408
270.000100, 35.00000078660448, 139.45228458430924
270.001000, 35.00000786605369, 139.45228394556526
270.010000, 35.00007866054496, 139.45228365597760
270.100000, 35.00078660501723, 139.45228211691446
271.000000, 35.00786565022930, 139.45234111702391

Now loxodrome_direct returns the same value 139.55133723928088 for both 90 and 270, and both are incorrect.

pymap3d version: 2.7.1

Many thanks.

bug

opened by noritada 2

AttributeError: module 'pymap3d' has no attribute 'eci2aer'
Describe the bug What is your expected output value(s)? What program/function are you comparing with?

Hi, I have been actively used an attribute eci2aer of pymap3d. However, today I suddenly faces an error when I use the attribute. Am I the only person who see this error: AttributeError: module 'pymap3d' has no attribute 'eci2aer' ?

How to reproduce the error?

conda create -n myenv python=3.8

conda activate myenv

pip3 install pymap3d

python

import pymap3d

pymap3d.eci2aer()

OUTPUT: AttributeError: module 'pymap3d' has no attribute 'eci2aer'
opened by dongsin-kim 2

[Bug]: TypeError upon import

What happened?

When attempting to import pymap3d, I get the following TypeError:

TypeError: expected string or bytes-like object

I have attempted to reinstall pymap3d, but the error persists.

Computer: MacOS Python: 3.9.15

Relevant log output

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/pymap3d/__init__.py", line 34, in <module>
    from .aer import aer2ecef, aer2geodetic, ecef2aer, geodetic2aer
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/pymap3d/aer.py", line 7, in <module>
    from .ecef import ecef2enu, ecef2geodetic, enu2uvw, geodetic2ecef
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/pymap3d/ecef.py", line 7, in <module>
    from .eci import ecef2eci, eci2ecef
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/pymap3d/eci.py", line 10, in <module>
    import astropy.units as u
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/units/__init__.py", line 17, in <module>
    from .quantity import *
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/units/quantity.py", line 25, in <module>
    from astropy.utils.compat import NUMPY_LT_1_22
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/utils/compat/__init__.py", line 19, in <module>
    from .numpycompat import *  # noqa
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/utils/compat/numpycompat.py", line 14, in <module>
    NUMPY_LT_1_19 = not minversion('numpy', '1.19')
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/utils/decorators.py", line 546, in wrapper
    return function(*args, **kwargs)
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/astropy/utils/introspection.py", line 167, in minversion
    return Version(module_version) >= Version(version)
  File "/Users/e30737/miniconda3/envs/py39/lib/python3.9/site-packages/packaging/version.py", line 264, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

bug

opened by ljlamarche 2

Improve code quality
Improve Code Quality

Improve typing

[x] Use mypy strict mode

[x] Add py.typed to enable typing (c.f. #73, PEP 561 compliant)

pre-commit

pyupgrade

isort

black

flake8

mypy

prettier

markdownlint

pre-commit-hooks

check-added-large-files

check-yaml

debug-statements

end-of-file-fixer

mixed-line-ending

trailing-whitespace

pygrep-hooks

python-check-blanket-type-ignore

python-no-eval

[ ] Update ruff configuration for the new release

Badges

Add some badges,

[x]

[x]

[x]

Contributing

[x] Create a CONTRIBUTING.md file to standardise how to set up pymap3d to contribute

[x] Setting up an environment

[x] Testing

[x] Committing with pre-commit

CI

[x] Run CI when a pull request is made

[ ] Activate pre-commit ci

[x] Activate Codecov
opened by JonathanPlasse 4
ECEF2ECI

ECEF to ECI velocity conversion In the tests functions for ECEF/ECI validation values are taken from matlab examples. The functions use position data, but not velocity data. I found that the resulting velocity was different from that in the matlab documentation after conversion from ECEF to ECI. I convert (3832 -4024 4837) from ECEF to ECI at datetime (2019, 1, 4, 12) I expect: (-3384 -4887 4843) I get: (-3004. -4669. 4842)

Python : 3.9.0 Pymap3d : 2.9.1
matlab-compare

opened by sambritton 1

Releases(v2.9.1)

v2.9.1(Jul 3, 2022)

thanks @EpicWink
Source code(tar.gz)
Source code(zip)
v2.9.0(Jun 17, 2022)

lookAtSpheroid allows all inputs to be arrays of same shape

add functions spherical2geodetic, geodetic2spherical thanks @leouieda

remove internal "use_astropy" option

add mathfun.py to abstract numpy/math fallback
Source code(tar.gz)
Source code(zip)
v2.8.0(Mar 30, 2022)

The type hinting for most numerics was removed to avoid causing external package problems as per #50. thanks @randallpittman The CI coverage was improved by testing each supported Python version across MacOS, Linux, and Windows. The PEP621 pyproject.toml meta was removed to avoid duplication and conflicts with setup.cfg. thanks @philblckwd
Source code(tar.gz)
Source code(zip)
v2.7.3(Nov 22, 2021)

enhance ecef2geodetic stability with float32
Source code(tar.gz)
Source code(zip)
v2.7.2(Oct 18, 2021)

Thanks to @noritada for finding and making tests for loxodrome_direct issues. Always appreciate hearing where the test suite isn't covering a broken case.

used numpy.broadcast_arrays to simplify code.
Source code(tar.gz)
Source code(zip)
v2.7.1(Oct 17, 2021)

CI tests Python 3.7...3.10

Added stability to loxodrome_direct for azimuth = {90,-90,270,-270} enhanced efficiency of loxodrome_inverse for stability
Source code(tar.gz)
Source code(zip)
v2.7.0(May 25, 2021)
Don't automatically import less widespread used modules including:

lox los rcurve rsphere

this speeds imports for most users.

add command line convenience functions:

python -m pymap3d.vdist python -m pymap3d.vreckon
Source code(tar.gz)
Source code(zip)
v2.6.1(Apr 13, 2021)

when implementing the speedup of 2.6.0, a mistake was made in ecef2geodetic that could cause an exception. This is now fixed thanks to @dschurman
Source code(tar.gz)
Source code(zip)
v2.6.0(Mar 21, 2021)

eliminated numpy.vectorize for ~100x speedup of many of the pymap3d functions, while still preserving the "no-Numpy" functionality for scalars.
Source code(tar.gz)
Source code(zip)
v2.5.1(Mar 10, 2021)

Source code(tar.gz)
Source code(zip)
v2.5.0(Feb 7, 2021)

For better internal quality, modernize type annotations in accord with Numpy 1.20 final release. This requires __future__.annotations, which requires Python >= 3.7. For many months, Python 3.5 use of pymap3d has been ≪ 1% Python 3.6 use of pymap3d continues to drop as current Numpy requires Python >= 3.7 as well.

Python 3.5 and 3.6 users can continue to use pymap3d 2.4.x. If we find any significant bugs, we plan to backport them to pymap3d 2.4.x as long as there is still significant pymap3d usage from Python < 3.7.
Source code(tar.gz)
Source code(zip)
v2.4.3(Sep 21, 2020)

Numpy 1.20 adds optional type hinting in the numpy.typing module. ArrayLike is a key type we feel appropriate for PyMap3D. PyMap3D will continue to work without Numpy or older versions of Numpy.

We add optional type hinting using numpy.typing.ArrayLike
Source code(tar.gz)
Source code(zip)
v2.4.2(Jul 23, 2020)
remove extraneous syntax from tests

add codecov

Source code(tar.gz)
Source code(zip)
v2.4.1(May 10, 2020)

v2.4.0 too boldly removed the non-AstroPy ECI conversions that only require Numpy. However, the Numpy-only fallback can have several percent error due to rotation only being considered. AstroPy considers higher-order effects that greatly increase accuracy of conversions involving ECI (eci2* or *2eci)

This release restores optional status of AstroPy for ECI, but Numpy is still required for ECI as it always has been for PyMap3d.
Source code(tar.gz)
Source code(zip)
v2.4.0(Apr 23, 2020)

The ECI calculation error was substantial for some applications due to only considering Earth rotation. Now ECI calculations use AstroPy for better accuracy (< 1% error) considering more factors in the ECI transformations. Fixes #33

Added geodetic2eci

Added more ECI self-tests

Temporarily pinned CI to Python 3.8 to avoid the usual issues with brand new Python releases not immediately having PyPi wheels for Astropy. We still also test Python 3.5.
Source code(tar.gz)
Source code(zip)
v2.3.1(Apr 23, 2020)

also move to python "src/" directory layout
Source code(tar.gz)
Source code(zip)
v2.3.0(Jan 27, 2020)

v2.0 introduced the use of numpy.vectorize to allow seamless pymap3d use with ndarray but also without numpy and scalars. However, this returned 0-d ndarray for certain functions rather than scalars for scalar inputs. This fixes that issue and adds tests for it.
Source code(tar.gz)
Source code(zip)
v2.2.0(Dec 29, 2019)

API change: the last releases geodetic2geocentric and geocentric2geodetic have a "alt_m" parameter now. Set it to zero to act like before / Matlab. include the altitude to account for object height above ellipsoid.

Type hinting / quality / refactoring

Added diagnostic plots

Corrected / updated docs and error messages.
Source code(tar.gz)
Source code(zip)
v2.1.0(Sep 24, 2019)

Thanks to @rpavlick for adding numerous functions in rcurve, rsphere, latitude, lox, utils and more. These functions each had tests written. Further, some Numpy functionality that was accidentally removed from v2.0 was restored for v2.1.

The goal of the PyMap3D package remains to support non-Numpy users, while also fully supporting those who have Numpy. The non-Numpy users are typically robots or platforms that stream positions in realtime, and don't need arrays, and want the faster performance of Python's built-in math module.
Source code(tar.gz)
Source code(zip)
v.2.0.1(Sep 23, 2019)

also breaking out tests to make easier to read and more comprehensive (checking for singularities, numpy vs scalar, etc.)
Source code(tar.gz)
Source code(zip)
v2.0.0(Sep 9, 2019)
Drop Python 2.x as code duplication and maintenance burden is too high.

improve numerical stability, thanks @bcminch #27

make non-Numpy use a first-class use case, with all but ECI working without Numpy (let us know if non-Numpy ECI is desirable). Of course Numpy, Pandas and Xarray are still handled first-class as well.

move CI to GitHub Actions.

Source code(tar.gz)
Source code(zip)
v1.8.1(Jun 30, 2019)

Put ellipsoid in own file put examples in own dir

test python setup.py install as well as python setup.py develop
Source code(tar.gz)
Source code(zip)
v1.8.0(May 17, 2019)

Full functionality of PyMap3D (as with Python in general in 2019) requires Python ≥ 3.5, but a useful subset is made available to Python 2.6, 2.7 and 3.4. This is relevant to MicroPython and ROS users and other special use cases where currently supported Python versions may not yet be readily available.

Put Ellipsoid() in its own file for clarity and flexibility with other packages.

ECI functions previously had an API unlike other PyMap3D functions, they are now the same as the rest of PyMap3D (scalar or N-D array for each variable).
Source code(tar.gz)
Source code(zip)
v1.7.15(Mar 25, 2019)

added several tests so that Pandas and Xarray are functioning.

Also handles ecef2geodetic scalar input.
Source code(tar.gz)
Source code(zip)
v1.7.14(Mar 8, 2019)

AER2GEODETIC was always going to the default WGS84 ellipsoid since the ell= argument was not present. We have fixed this error.

Also did a complete rewrite of documentation to numpydoc standards (mostly) and regenerated with pdoc3.
Source code(tar.gz)
Source code(zip)
v1.7.13(Jan 20, 2019)

Corrected algorithmic error for ecef2geodetic where negative altitude wrapped to positive altitude

parameterized tests to provide better coverage of singularities / edge cases
Source code(tar.gz)
Source code(zip)
v1.7.12(Dec 4, 2018)

use pdoc instead of sphinx for autogen docs

Don't limit altitude to be positive in geodetic2ecef, useful for near-earth WGS84 not exactly matching Earth's complicated surface.
Source code(tar.gz)
Source code(zip)
v1.7.11(Sep 28, 2018)

Improving accuracy and computation speed, a more modern closed form ecef2geodetic is implemented.

More self-tests.
Source code(tar.gz)
Source code(zip)
v1.7.10.1(Sep 9, 2018)

Source code(tar.gz)
Source code(zip)
v1.7.10(Sep 7, 2018)

Made AstroPy completely optional for all functions, including ECI conversions

added tests for times coming in from Pandas and Xarray.

Note: removed PyPy from Travis-CI because Travis has old PyPy versions. However PyMap3D does still work with the current release of PyPy3 (6.0)
Source code(tar.gz)
Source code(zip)