Bug: Drift function applied to isotrope coordinates

[MuellerSeb]

This is a bug in my opinion:

PyKrige/pykrige/uk3d.py

Line 166 in 48bc433

the drift values are calculated in the adjusted data frame.

In GSTools, drift is applied to the input coordinates and I think this should be done here as well.

@rth @bsmurphy @mjziebarth opinions?

[bsmurphy]

Sorry for the slow response on this, @MuellerSeb. I wouldn't necessarily call it a bug (since I think the kriging system is happy solving for the drift terms in any arbitrary coordinate system), but I do agree that maybe this implementation is suboptimal. (For example, if you wanted to extract the drift values and actually use them for something, having them calculated in the adjusted coordinate system would probably add another layer of difficulty in getting them back into a meaningful and usable form.) So, I agree a change here might be useful.

OK, now that I looked at the exact line you're pointing to, I think I see more exactly why you're calling it a bug... So you mean specifically with the arbitrary drift function capability? If so, then yes I agree this is more of a bug (or at least a non-ideal way of exposing this functionality), since really the function should probably operate in the same space as the original non-adjusted data, for physical (and intuitive) consistency. I probably just implemented it this way originally out of simplicity, but I agree changing this would be worthwhile.