Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try using an inverse-transform-based approach to limits #149

Closed
wants to merge 24 commits into from

Conversation

asinghvi17
Copy link
Member

basically, the user should interact with the limits in the space of source ("input space") and the limits should be actually specified in the space of target ("transformed space"). Ticks etc can be found by applying an inverse transform to the data limits of the Scene.

@asinghvi17 asinghvi17 force-pushed the as/inverse_transform branch from a785923 to 389c661 Compare February 2, 2023 06:49
@asinghvi17 asinghvi17 force-pushed the as/inverse_transform branch from 389c661 to 88119b2 Compare February 2, 2023 07:09
@asinghvi17 asinghvi17 force-pushed the as/inverse_transform branch from 88119b2 to b60f3da Compare February 2, 2023 08:42
@asinghvi17
Copy link
Member Author

A way to get the axis stuff could be that the GeoAxis has two kinds of limits. One, which is the traditional "limits/targetlimits/finallimits" pipeline, is concerned purely with transformed space, i.e., the space of the Scene. Meanwhile, let us introduce a new attribute input_limits, which will concern itself purely with the limits in input space, i.e., where the latitude and longitude ticks should be. This can influence the transformed limit space only when set by lonlims!/latlims!/lims!.

However, the transformed limits can influence the input limits, subject to the following conditions.

  1. If the transformed limits change, they update the input limits, so that ticks can be updated.
  2. There should be an attribute dynamic_longlat_limits or something which can be set to false if the user does not want the limits to change.

Things we still have to figure out for this interface:

  1. Right now, the lat/long bbox is a strict superset of the transformed-space bbox, i.e., the frame of the geoaxis extends outside the Scene. We need to figure out how to get these to fit within the scene.
  2. How do we deal with transformations which show singularities in (long, lat) space? i.e. orthographic projections which show the pole, etc.

@asinghvi17
Copy link
Member Author

asinghvi17 commented Feb 13, 2023

The eventual goal is to do e.g. this

using GMT; GMT.coast(proj=(name=:Orthographic, center = [74 15]), R="global", show=true)

GMTjl_tmp
in GeoMakie. Note that you can actually see the pole here, and the black border around the globe is not a straight line in lon/lat space.

I would also want ticks, ticklabels, grid etc to be shown.

The interesting thing is that they seem to be using a contour line to show the border here, which we could do pretty easily. Then, from there you just do a bunch of projection on a lon/lat grid between pixel, lon/lat and transformed space to figure out how this should work. Since we're using a contour line, with sufficient resolution it should be pretty accurate.

@asinghvi17
Copy link
Member Author

Figured out a contour line solution for the border. This looks good when not interacting with the plot:
Screen Shot 2023-02-14 at 4 18 24 PM
but when you do start interacting it takes a terribly long time to recompute, and doesn't exactly look great 😢

Untitled.mov

@asinghvi17 asinghvi17 changed the base branch from sd/block-geoaxis to master February 14, 2023 11:08
@asinghvi17 asinghvi17 closed this Feb 14, 2023
@asinghvi17 asinghvi17 reopened this Feb 14, 2023
@asinghvi17
Copy link
Member Author

Implemented in GeoMakie v0.7.0

@asinghvi17 asinghvi17 closed this Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants