Edzer Pebesma

Yes, I got it wrong, letting `threshold` depend on `cellsize` - it should depend on the spacing of `temp.c`. This however is irregular and expensive to compute for all neighboring...

That indeed doesn't work. Would it be O.K. if it raises an error, or is this something that you need?

I see your point (and the `st_rgb` docs suggest this); FYI `plot.stars()` has an `rgb` argument that lets you specify band indices, like `c(3,2,1)` if they come as BGR.

2: yes, but it didn't work, and seems much more complicated than I thought.

Thanks for you question, I understand your concern: it would have been easier if there would have been one package instead of two, or if the two packages did have...

`st_crs(NA)` (which is what you get when assigning `""`) is the CRS that is understood by `sf` as "unknown, Cartesian". Anything else will be assumed as "known, understood, convertible /...

When reading files with `LOCAL_CS["Undefined Cartesian SRS"]`, `sf` now assigns CRS `NA`, with a message.

There can be many reasons why `OGRCreateCoordinateTransformation` fails, having a `LOCAL_CS["Undefined Cartesian SRS"]` is only one of them. You could have for instance ellipsoidal coordinates associated with a different celestial...

We discussed in https://github.com/r-spatial/sf/issues/1776 whether to substitute (and keep) `LOCAL_CS["Undefined Cartesian SRS"]` for `NA`, as it is more explicit. It just didn't happen; we could still (try to) do it,...

However, ```r st_crs('LOCAL_CS["Cartesian (Meter)",LOCAL_DATUM["Local Datum",0],UNIT["Meter",1.0],AXIS["X",EAST],AXIS["Y",NORTH]]') == st_crs('LOCAL_CS["Undefined Cartesian SRS"]') # FALSE ``` (this check is done by GDAL SRS->IsSame(), [here](https://github.com/r-spatial/sf/blob/main/src/gdal.cpp#L320)), so where will this stop?