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,

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.

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.

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?

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?

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.

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

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:

1. Make a release and upload to PyPI. Then the instructions should be: pip install pymap3d
2. Download the zip/clone the repo and install using pip: cd pymap3d; pip install . (no -e)
3. 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.

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.

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.

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?

1. conda create -n myenv python=3.8
2. conda activate myenv
3. pip3 install pymap3d
4. python
5. import pymap3d
6. pymap3d.eci2aer()

OUTPUT: AttributeError: module 'pymap3d' has no attribute 'eci2aer'

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

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

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