Open loreabad6 opened 7 months ago
This also relates to another feature I hope cubble can have. Say, one creates a cubble from a tibble and would like to add a crs. One should be able to do this with something like:
climate_flat |> as_cubble(key = id, index = date, coords = c(long, lat), crs = sf::st_crs(4326))
This makes me think as_cubble()
should probably accept a crs argument and parse it as an attribute. We will also need to add a st_transform.cubble_df
to handle coordinate transformation.
Let me know your thoughts on this.
Say, one creates a cubble from a tibble and would like to add a crs.
Yes, I agree this would be useful, also considering that one would not to create an sf
object first. Would this always create a geometry column? I would assume so, since it would basically be passed onto an sf internally. In that same line of thought, does it make sense to keep the x/y lat/long columns on the cubble, or should a geometry column suffice, following what sf does?
We will also need to add a st_transform.cubble_df to handle coordinate transformation.
I imagine sf methods would only be for the spatial_cubble_df
class? I think having a seamless interaction with sf would be great. Is this not handle when the spatial_cubble_df
inherits the sf
class? Should it always do so?
Yes, if users decide to incorporate crs in their workflow, they should get familiar with sf objects.
If crs becomes an additional attribute, then st_transform.cubble_df
will need to come in, and it is no longer relevant now.
If spaital_cubble_df
inherits the sf
class, st_transform
should already work.
Now, for both tbl_df and stars objects, they are first created as a cubble (as_cubble
) and then use sf for processing crs (make_spatial_sf
).
I see, I would argue that if cubble
intends to be at its core a bridge between sf
and tsibble
then the methods of both packages should be inheritted to the classes in cubble. That would make any other package built on top of these two work as well, for example for plotting.
I personally see the benefit of adding a crs variable, and not only adding st_transform.cubble_df
but also st_set_crs.cubble_df
as methods, assuming that a cubble_df
is always spatial then make_spatial_sf
would be an internal process. I am not sure if this will sacrifice any time or performance though.
Raster data cubes do not inherit the CRS when coerced to cubble. This is because the cubble creation is extracting the coordinate values as integers, losing the geometry here.
One option would be to coerce the tibble to sf before coercing to cubble before line 192, to recover the CRS:
or to add
make_spatial_sf()
after line 192:But that is not such a fast approach and also adds an extra geometry column that the user might find unexpected. So I am not sure what would be the best approach here.