Check map centering for Modeling: atlantic and pacific center

[arunge]

Regarding:

A map centred in the Pacific should be generated in a similar way as a map centred in the Atlantic. After all, this is just a transposition/re-centring along the x-axis.

I probably have asked this previously, but why cannot the following be done:

1) When the user selects the option to centre in the Pacific one keeps using the "Atlantic" modelling approach but one redefines the x variable as x' variable which is simply transposed by 180 degrees (or the equivalent in whatever unit you are using). That is: x' = x +180

2) The modelling is now done on x' as it would be done on x

3) Once the results are generated transpose these back so that display correctly for the Pacific

Originally posted by @isomemo in https://github.com/Pandora-IsoMemo/iso-app/issues/175#issuecomment-1630375477

• [x] check the current implementation
• [x] check how one would implement the above method and where this differs from the current implementation

Additional notes:

• Why not use spherical modelling? - Planar modelling is much faster
• we need a symmetric transposition from Atlantic to Pacific
• why is the Pacific center at 160° instead of 180°? If possible use 180°

[arunge]

@f-lukas Please, let us discuss how we could find a better solution.

[isomemo]

@arunge @f-lukas I just want to add that transposition may not be as I described above since there is a projection into a plane of a spheric-like system. However, there would be some function that does this.

[mgross]

The reason why it's not just transposed by 180 degrees is that if you have data covering the whole world you would have a problem at the atlantic border nontheless, which is nondesirable, too. How it is currently implemented is that it creates mirrored pseudo data at all 4 borders, such that in effect we don't see a boarder anymore. (still can be seen for the Bayesian case with not so much iterations, but this is due to random fluctuations: with enough iterations this will be not visible).

The spherical modelling is actually faster than the planar one with mirrored data.

160 degrees instead of 180 because then europe is not cut in the global map.

[arunge]

I have added a detailed description of the features that are related to map centering to the wiki of this repository. For this, very helpful input was provided by @mgross.

@isomemo please, let us discuss based on the current logic how to continue here.

[arunge]

@isomemo Today we discussed the issue of centering the map. Following points came up:

• the user expects that there is no difference for modelling if one switches between Atlantic and Pacific center However, currently switching does not shift the data, only the results are displayed on a pacific centered map:
• "shifting data" is not implemented, and it would only catch the case for pacific data not for data at the poles
• "border correction" is more general, but the user might be confused why Numbers of MCMC iterations sometimes must be increased for pacific data, unlikely that the user will take the time to check the docu
• @mgross mentioned that spherical modeling is also very fast, faster than the border correction option. He recommends to use sperical modeling anyway

At the end the question came up if we could just remove the option for a planar modeling and always use the spherical modeling.

@mgross Is there any reason to keep planar modeling? Do you know typical use cases when planar modeling should be used instead of sperical modeling?

[arunge]

Today, @mgross @isomemo and @arunge discussed that

• spherical and planar modelling options must be kept
  • planar modelling is better when having data only on a small area
• it will not be possible to argue why data from the pacific needs more iterations when using Bayesian modelling than data from the atlantic
  • [ ] an option for a simpler transposition to the pacific will be needed
  • [ ] the map centering should center at 180° not at 160°

@mgross and @arunge will discuss the details regarding the implementation of the transformation next week.

However, currently implementation of the transformation will not have priority!

[arunge]

This issue will be continued within the new task:

• https://github.com/Pandora-IsoMemo/iso-app/issues/196

I am closing here.