Curious How EOMaps Calculates Compass Rotation

[moss-xyz]

I'm working on a personal package for adding a north arrow to matplotlib maps I am making, using a similar methodology to EOMaps (namely, drawing a polygon and adding it to an OffsetBox).

One thing I haven't cracked yet is rotating the north arrow based on the input CRS of the data, which it does look like EOMaps can do. Particularly, it seems like the _get_transform function in compass.py calculates the angle of rotation somehow:

def _get_transform(self, pos):

        lon, lat = self._m._transf_plot_to_lonlat.transform(*pos)
        x, y = self._m._transf_lonlat_to_plot.transform([lon, lon], [lat, lat + 0.01])

        try:
            ang = -np.arctan2(x[1] - x[0], y[1] - y[0])
        except Exception:
            _log.error("EOmaps: Unable to add a compass at the desired location.")
            return
...

And then it adds that angle as a rotation to the Affine2D transformation that happens later.

However, I'm not fully understanding the code here. It looks like _transf_lonlat_to_plot (and its inverse) use PyProj's Transformer function to convert between the plot CRS and a geodetic system... somehow? Where does as_geodetic() come from? And why do you add 0.01 to the second lat value, but keep the lon values the same?

[raphaelquast]

Hey,
since you have lots of questions... let me ask you one myself:

Just out of curiosity, what's keeping you from using/contributing to EOmaps directly?

OK, and now to your questions 🙂:

First, as_geodetic is coming from the cartopy CRS (which uses pyproj under the hood): here

Concerning the method for determining the rotation, the idea is the following:

1. transform the position from the plot-crs to lon/lat
2. get the initial position and a position with a slightly shifted latitude (the use of the hard-coded 0.01 here is something that could actually be improved... )
3. reproject the points back to the plot-crs and use the triangle spanned by the grid-lines of the projected crs and the transformed points to determine the approx. rotation angle for the compass

... and since a picture is usually worth more than long explanations... I mean something like this:

[moss-xyz]

Just out of curiosity, what's keeping you from using/contributing to EOmaps directly?

Ha good point! I only just came across the repository today and I'm working on a time-sensitive project, so not willing to overhaul all my script to fit it in yet, but hopefully I can later!

That picture was very helpful thank you! Brings me back to my trig days...

Curious: what do you envision as a better solution that the hard-coded 0.01 value to make the shift?

[raphaelquast]

Just out of curiosity, what's keeping you from using/contributing to EOmaps directly?
Ha good point! I only just came across the repository today and I'm working on a time-sensitive project, so not willing to overhaul all my script to fit it in yet, but hopefully I can later!

ok that makes sense 😅
My intention with EOmaps is to create a package that ultimately saves time... So it might come in handy for future projects!

Concerning the value for the shift... That ultimately depends on the desired accuracy for the angle... As long as you don't use extremely distorted projections i think 0.01 should be fine. Something related to the extent of the map in relation to the dpi of the figure could provide a robust estimate (but i doubt that it would result in clearly visible differences for "reasonably sized" maps...)