GeoStat-Framework integration: PyKrige v2

Hurray! PyKrige is now part of the GeoStat-Framework

Now we have to think about, how to smoothly integrate PyKrige into this Framework and how to organize the coexistence with GSTools.

With this PR: https://github.com/GeoStat-Framework/GSTools/pull/67 in GSTools a set of kriging routines is introduced in GSTools:

• simple kriging
• ordinary kriging
• universal kriging
• external drift kriging
• detrended kriging

All of these procedures work in 1D, 2D and 3D.

PyKrige could work as the extension for fancy kriging, like

• moving-window
• regression kriging
• N-dimensional kriging (#138)
• integration with scikit-learn (#143)

I think it would be nice to collect stuff, that should be provided by PyKrige and things that could be out-sourced to GSTools to reduce redundancy.

TODOs ATM

• N-dimensional kriging (to provide rotation, we could simply demand a rotation matrix [orthogonal matrix with det=1]) #133 #31
• choosable distance metric #120
• add all Variogram-models that are provided in GSTools
• bring parametrization of variogram-models in line with GSTools #119
• variogram-estimation with GSTools (working on automated estimation ATM) #130 #29 #57 #97
• use import-export routines of GSTools for mesh-io #122
• building wheels with cibuildwheel
• dropping py2 support (https://python3statement.org/)
• updating DOC to be in line with the GeoStat style
• create a separate develop branch; master should hold latest release

Project

https://github.com/GeoStat-Framework/PyKrige/projects/1

What do you think? @rth @bsmurphy @LSchueler

[rth]

You are right, making these changes in 2.0 would probably be best.

[bsmurphy]

Thanks for taking this on, @MuellerSeb! A few quick thoughts on this…

The tools for variogram estimation/modeling/etc in PyKrige are admittedly underdeveloped, so relying on your efforts in GSTools would be good I think. Probably won’t be too hard to refactor the existing PyKrige code to use the GSTools variogram code.

I think refactoring to ND kriging would be very valuable, and actually shouldn’t be too hard in the existing PyKrige framework. And the existing universal kriging drift terms could then be extended into N dimensions.