Anatolii Tsyplenkov
Anatolii Tsyplenkov
Hi @ateucher! As far as I understand, not really. However, it does provide a significant increase in speed. See a quick reprex below. UPD: `ms_union` is even faster than `terra::union`...
Hey, any update on this PR?
Awesome, thanks! I will test it soon and will let you know.
@juliasilge I have quickly tested the `RuntimeCodeExecutionMode.Silent` in my extension and it works as expected! Thank you for that. I will explore the new API features in detail later this...
Sure thing! However, I don't understand how my PR differs from the current behavior and philosophy of `st_crs`. https://github.com/r-spatial/sf/blob/97a179a206c8ceacf1a6999b98e3489a5bdd45f4/R/crs.R#L73-L76 I am suggesting improving `st_crs` only for `SpatVector` objects, which rely...
Thank you for your reply. The roadmap is clear. I am happy to contribute to the package as much as I can. My thinking is that it would be better...
I have encountered the same issue with the new stable `ggplot2_3.5.0`
Currently the `sf` objects can be stored only in a serialized `.qs` `.Rds` or `.qs2` formats. But the `parquet`, `arrow` or `csv` options will fail in writing or reading the...
I like the @elipousson approach, but there are several caveats: 1. Translating into WKT leads to a decrease in accuracy, for example just compare the original `nc` file with `read_sf_parquet()`...
I've tweaked Eli's code a bit. Using **WKB** instead of WKT can help with accuracy and file size, making it even smaller than GeoArrow. However, with the current WKT/WKB approach,...