Vectorized numpy operations

[shisha101]

Hello, I have large vectors of lat, lon, alt that I would like to convert to a local coordinate system some "enu" frame such that I can do calculations the ecef.Cartesian and the ecef.EcefKarney are doing the job but it is insanely slow to iterate over such a large number ~400,000 points. I believe that this would be much much faster if it could be vectorized with numpy and accept numpy vectors as input. Is this in anyway planned ?

what kind of effort would you estimate it would be to make such a change ? is there an alternative lib that I missed ?

I was also curious to know why the internal data types and not depend on numpy under the hood :), thanks in advance and for the great development :)

[mrJean1]

Not sure what the best way would be. Using numpy or scipy would only be faster if the conversion is done by a function built-in to numpy or scipy. Show an example of the conversions you need to perform. Without that it is impossible to guestimate what the effort is. Also, with respect to the "internal data types", several pygeodesy modules, classes and functions do support data in a numpy array format. However the modules, classes and functions, like EcefKarney or ellipsoidalKarney which use and require Karney's geographiclib (in Python) must use a format compatible with the latter, obviously.

[mrJean1]

The pygeodesy.EcefKarney class is a Python version of the Geocentric class transcribed from Karney's GeographicLib library in C++. That is one library to look into and perhaps other ones like pymap3d and oyb .

The pymap3d package does support numpy arrays for several functions and uses You's ecef2geodetic conversion like pygeodesy.EcefYou.reverse, see references in pygeodesy.EcefYou. In the oyb package see especially the oyb.earth and oyb.rot modules.

One other comment. Adding a vectorized version of the forward and reverse methods to the pygeodesy.Ecef... classes would be straightforward and worthwhile, depending on the specific functional requirements.

For example, those vectorized methods would accept a list, tuple or iterable of arguments and yield the results. Or, the arguments could be a numpy array wrapped in something like Numpy2LatLon (but extended to support height, named Numpy2LatLonHeight, TBD) to iterate over the numpy array.

Also, to reduce the overhead, the vectorized methods would do little or no argument checking and return a fixed, minimally required result.

Note, vectorize does not mean numpy.vectorize.

However, it remains to be seen -and measured- what the actual performance difference would be, especially for the EcefKarney.reverse case. Because that method is far more complicated and compute-intensive than other reverse -and forward- methods.

[shisha101]

I see, thanks for the response, I will show you an example to clarify the functional requirements.

The Idea would be IMO to have a function call that does all the computation using numpy under the hood, if a list, tuple is passed it can be converted to numpy and the operations needed to do the forward and backward operations would be done using numpy arrays, this would yield a significant speedup compared to the normal for loop approach. since numpy.vectorize is essentially a for loop under the hood.

[mrJean1]

Great, looking forward to that.

Also do check the PyMap3d package, it uses numpy provided that is installed. It wraps several Python functions with numpy.vectorize. However, it is unclear how much different/better that is versus calling the function from Python.