Resampling: Add spatial methods

[mlr-org]

Resampling: Add spatial methods

[pat-s]

We now have a good approach for this and the resampling methods are working as intended. Big thanks to @be-marc!
We'll soon update the README and the book with usage examples.

[mllg]

I don't know spatio-temporal stats very well. But you can mark columns to be treated specially. I've pushed a small example where two columns (x+y) are marked as coordinates by assigning them a special col_role. I assume they still count as feature?

Maybe you can look into the example script and then we do a call to discuss what is missing in mlr3.

[jannes-m]

Not sure if this is a good idea, since I have not had a look into the inner world of the mlr-verse but wouldn't it be an idea to just use the geometry-column of sf-objects (of the point type) as basis for the spatial resampling? This would have the additional benefit of sparing the user from providing an additional xy-data.frame. For the modeling-resampling stuff, we could just set the geometry column to NULL which again would be nice since this way we would force the user to provide spatial coordinates as predictors if he/she must use them.

[pat-s]

But you can mark columns to be treated specially. I've pushed a small example where two columns (x+y) are marked as coordinates by assigning them a special col_role. I assume they still count as feature?

Usually they do not, even though some people use it (with some arguments in favor) and therefore it should be allowed if they are explicitly in the DF.

However, as @jannes-m pointed out, we should have a "fool-safe" method to supply the coordinates next to the actucal predictors. Otherwise people will just put it in the DF and have no clue how that might affect the model fitting (this happens really often).

Since the sf pkg is used for pretty much any spatial analysis in R, depending on it wouldn't be so problemati from my point of view, even though it has a huge dep chain.

We would have to see how this interacts with all the data.table stuff in mlr3, however, as coercing to sf usually inhertics only classes data.frame and 'sf` but not data.table. Coercing back and forth would be tedious.

Maybe there is a way we can get it done. Would also be helpful for the plotting functions.

One option could be to force the user to supply a sf DF as the task which will be coerced to a data.table after we extracted the coords internally?

[pat-s]

and @jannes-m Due to the R6 class system, the idea is that after the extension pkg mlr3spatiotemporal gets loaded, the base classes are extended by specific methods of this pkg.

It should be possible to do both when the pkg is loaded and not be restricted to spatial stuff by forcing sf objects as task DFs. Mhh, this somehow contradicts my thought from above. Let's discuss this in more detail f2f.