Functions of loxodrome or rhumb line are needed

[AkexStar]

I have did a lot of surveys, but found that there is few libs about rhumb_inverse and rhumb_direct.
I noticed that Geographiclib has a solution for rhumb, but PROJ still lacks of functions to calculate rhumb line.

Rhumb Line is very important for air/sea track calculation.
I hope that there will be funtions just similar to Geodesic calculations to solve rhumb line.

I will be very grateful if any developer could reply me.

[kbevers]

Is there a reason why you can't just use Geographiclib? The geodesic functionality is included in PROJ because it is useful in various instances. I am not sure the same is the case for the rhumb lines, but maybe @cffk can enlighten that topic better than me.

[busstoptaktik]

@AkexStar perhaps compute the Mercator coordinates of the end points, then interpolate linearly, and call the inverse Mercator, to obtain the geographical coordinates of a series of points along the loxodrome?

[mwtoews]

I'll aggrege with @kbevers that the best option is to use GeographicLib directly. I believe that Rhumb line support is only implemented for the C++ library (GeographicLib::Rhumb and GeographicLib::RhumbLine).

PROJ's geodesic functions are directly from GeographicLib's C implementation, as noted here.

[cffk]

@AkexStar
The machinery needed for ordinary rhumb calculations is already in PROJ as noted by @busstoptaktik. You'll need some understanding of rhumb lines to make this work. Also if you're trying to do the direct rhumb line calculation, you'll need to use the distance along the meridian (multiplied by the secant of the heading).

Is it really the case that rhumb lines are still used for navigation? Surely, all electronic systems are set up to follow geodesics and, even though the heading is continuously changing, the course does not have to be constantly adjusted, since the geodesic path corresponds to "rudder amidships".

[AkexStar]

Is there a reason why you can't just use Geographiclib? The geodesic functionality is included in PROJ because it is useful in various instances. I am not sure the same is the case for the rhumb lines, but maybe @cffk can enlighten that topic better than me.

@kbevers
Well, I am not familiar with C/C++. I use python for most projects.
I firstly created an Issue 1332 in pyproj. Pyproj's developer said that the Rhumb caculation needs to be added in PROJ, so they can wrapper it in python libs. Then I was here to raise this Issue.
And actually in the solution of plains or ships navigation, Rhumb Line is preferred. Because it is a path with constant bearing, which means easy to keep heading.

@busstoptaktik
Thank you for your suggestion~ I will check the Mercator Projection in pyproj recently to see if it can solve my problems.

@mwtoews
So there is no chance in PROJ to involve Rhumb in the feature?
Sad news...

[mwtoews]

Looking around for Python wrappers for GeographicLib I see GeoFun, which has Rhumb line functions. I've not used this, but try pip install pygeofun to install a built distribution.

Another project is geographiclib-cython-bindings, but this project seems to have stalled, and no built distributions are available, and I only see Rhumb line in an unmerged PR

[avitase]

That's funny. I had the exact same issue two weeks ago. Indeed, the geographiclib-cython-bindings seems to be dead and I see three options to go from here: First, we ask @cffk if he would accept PRs that port features from the C++ implementation to the C version (besides Rhumb lines, gnomonic projections + friends could come in handy) and then write a thin wrapper in PROJ. In case this is not an option, it isn't too hard to do what geographiclib-cython-bindings intended to do by setting up a new GitHub repository, adding geographiclib-c as a Git submodule, wrapping the src/*.{h,c} files with Cython, implement our desired features on top, and ship this in wheels. (Note that in contrast to geographiclib-cython-bindings, this solution does not require the user to install the dependencies manually!) I already started implementing this option but then I saw that my setup is almost identical to what pyproj does with the bundled files in PROJ. (Rather than a Git submodule they download the latest version before building the wheel in a shell script.) So this is the third option, in order to avoid code duplication the features could be implemented in pyproj directly.

IMO, having a bit more of GeographicLib's features in PROJ would be very helpful for other libraries that bundle PROJ. Let me know if you need my help:)

[AkexStar]

@mwtoews
Thank you for your recommendation!
Actually, two weeks ago I tried pygeofun, and It worked. However, pip install pygeofun can't run well because this command seems leading to lack of .so or .pyd files.
Pygeofun needs to be built from source(especially geographiclib C++ source code) when implement it in a new machine everytime. Or download pygeofun's Built Distributions from .whl file according to the machine's OS and python's version.
It means it is a little hassle to use.

And that is why I seek for pyproj as an alternative, which is very easy to use. I plan to create a new Issue in pygeofun to see if @jrversteegh could make its pypi more convenient.

[AkexStar]

The machinery needed for ordinary rhumb calculations is already in PROJ as noted by @busstoptaktik. You'll need some understanding of rhumb lines to make this work. Also if you're trying to do the direct rhumb line calculation, you'll need to use the distance along the meridian (multiplied by the secant of the heading).

Is it really the case that rhumb lines are still used for navigation? Surely, all electronic systems are set up to follow geodesics and, even though the heading is continuously changing, the course does not have to be constantly adjusted, since the geodesic path corresponds to "rudder amidships".

Thanks to @cffk, I do need to learn more about rhumb and geodesic. I will try to study these.
After all, I do need rhumb caculation for now...

[jrversteegh]

@AkexStar I'd be happy to build more wheels. What platform would you need?

[jjimenezshaw]

compute the Mercator coordinates of the end points, then interpolate linearly, and call the inverse Mercator, to obtain the geographical coordinates of a series of points along the loxodrome?

I like @busstoptaktik 's solution. The main purpose of Mercator projection is that a loxodrome is a straight line in the map. Linear interpolation there is simple and fast. Just be careful with the antimeridian.

Also if you're trying to do the direct rhumb line calculation, you'll need to use the distance along the meridian (multiplied by the secant of the heading).

As @cffk says, to compute the distance there is a direct formula.

Fun fact: the distance to the pole is finite, but takes infinite number of turns.

[cffk]

I'm on vacation right now. I'll start contributing again once I've returned (Sept 8).

[AkexStar]

@jjimenezshaw
Yes, mercator projection can transfer a stright line on map to a rhumb line on sphere. I have tried it but it solved part of my problem.
I want to Interpolate points equidistantly between start-point and end-point on a rhumb line.

[jjimenezshaw]

@AkexStar If I understood properly the distance in a loxodrome, equidistant points in the curve will be equally distributed in latitude. Am I right? Convert those latitudes into y coordinate in Mercator, and intersect with the straight line between source and destination.

[busstoptaktik]

I want to Interpolate points equidistantly between start-point and end-point on earth with their (B, L) coordinates.

You cannot do that: Equidistant in both latitude and longitude would imply a plate-carré projection, and straight lines in a plate-carré projection are not loxodromes.

You can get loxodromic equidistance in longitude by splitting your input linearly wrt. the longitude span, then iterating bisectionally wrt. easting, along the mercator-projected line (you may be able to find a closed form solution, at least for the spherical case)

[AkexStar]

If I want to get a series of equidistant points between source and destination on ellipsoid(WGS84), is there a way to use mercator projection?
Maybe spherical approximation is enough?

[busstoptaktik]

If I want to get a series of equidistant points between source and destination on ellipsoid(WGS84), is there a way to use mercator projection?

Essentially no. Not without numerical integration along the path. You could probably do it in the Mercator space, and correct the length of each integration-step by the local scale factor, which you can get through the PROJ API and get a feeling for using the proj executable:

$ echo 12 55 | proj -VS +proj=merc

#Mercator
#       Cyl, Sph&Ell
#       lat_ts=
# +proj=merc +break_cs2cs_recursion +ellps=GRS80
#Final Earth figure: ellipsoid
#  Major axis (a): 6378137.000
#  1/flattening: 298.257222
#  squared eccentricity: 0.006694380023

Longitude: 12dE [ 12 ]
Latitude:  55dN [ 55 ]
Easting (x):   1335833.89
Northing (y):  7326837.71
Meridian scale (h) : 1.73952661  ( 73.95 % error )
Parallel scale (k) : 1.73952661  ( 73.95 % error )
Areal scale (s):     3.02595283  ( 202.6 % error )
Angular distortion (w): 0.000
Meridian/Parallel angle: 90.00000
Convergence : 0d [ -0.00000000 ]
Max-min (Tissot axis a-b) scale error: 1.73953 1.73953

[jrversteegh]

@AkexStar. I think it would be helpful if you explain on a higher level what you're trying to achieve. Obviously splitting either an orthodrome (geodesic: shortest distance) or a loxodrome (rhumb line: constant heading/azimuth) from point A to point B into a number of equal length segments is trivial. So in what way is that not sufficient?

[cffk]

If I want to get a series of equidistant points between source and destination on ellipsoid(WGS84), is there a way to use mercator projection?
Maybe spherical approximation is enough?

Assuming the latitudes of source and destination are different, then just pick points equally spaced in latitude using the geodesic machinery of PROJ for a meridional geodesic. This gives a series of latitudes; convert each latitude to the Mercator y coordinate; compute the corresponding x coordinate in the Mercator projection and this gives you the longitude.

If the latitudes of source and destination are the same, just divide the longitude interval evenly.

My paper on rhumb lines gives a method which maintains accuracy if the difference in latitudes is small.

[AkexStar]

I think it would be helpful if you explain on a higher level what you're trying to achieve. Obviously splitting either an orthodrome (geodesic: shortest distance) or a loxodrome (rhumb line: constant heading/azimuth) from point A to point B into a number of equal length segments is trivial. So in what way is that not sufficient?

@jrversteegh
Well, I am trying to caculate plane's path in an Air Traffic Control project. I want to predict the aircrafts' coordinates(lat, lon) along their flying rhumb lines.
Because I choose to detect conflicts among routes with equal time span, I need equidistant interpolations when assuming speed is constant. For now, I use your funtion rhumb_direct() in pygeofun to solve this demand.
And I aggre with your opinion. Difference between geodesic and rhumb is relatively small, when the distance between the starting point and the end point is not so far.

[AkexStar]

Also thanks to explanations from @busstoptaktik and @cffk
You help me to understand more about loxodrome and PROJ

[jrversteegh]

@AkexStar I've updated the readme at https://github.com/jrversteegh/geofun with such a case: JFK-AMS flight paths.

[jjimenezshaw]

Some people showed here how to easily compute a loxodrome using the Mercator projection. Should this issue be closed?

[kbevers]

Should this issue be closed?

Yes