Closed mdsumner closed 4 years ago
Merging #32 into master will not change coverage. The diff coverage is
n/a
.
@@ Coverage Diff @@
## master #32 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 8 8
Lines 255 225 -30
=====================================
- Hits 255 225 -30
Impacted Files | Coverage Δ | |
---|---|---|
src/fasterize.cpp | 100% <ø> (ø) |
:arrow_up: |
src/rasterize_polygon.cpp | 100% <0%> (ø) |
:arrow_up: |
src/utils.cpp | 100% <0%> (ø) |
:arrow_up: |
src/pixelfn.cpp | 100% <0%> (ø) |
:arrow_up: |
src/edge.h | 100% <0%> (ø) |
:arrow_up: |
src/check_inputs.cpp | 100% <0%> (ø) |
:arrow_up: |
src/edgelist.cpp | 100% <0%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 5a9f0a1...51fce3f. Read the comment docs.
This is sufficient I think, checking all the possible variants and trying to compare proj strings is very complicated - the doc currently says
//' @return A raster of the same size, extent, resolution and projection as the //' provided raster template.
and this was not occurring, if non-NA the vector projection was copied over to the raster, with no checks. Unfortunately, this means the answer was always "correct", even if it's not what they intended.
As described in the return value it's now accurate. If folks are intending that sf data dictates the output projection then they won't achieve that, but there's really no convenient way to check this so I think the onus must be on users to input data in the same coordinate system.
(Anything else gets pretty complicated and hardly belongs in this package IMO - if raster moves to WKT, or using PROJ more under the hood then I'd revisit the rationale here - currently raster is broken for these new sf crs objects - for the
raster(sf)
workflow).