Comments (7)
I'm seeing the same, but only on one of my machines (an M1 mac; I also have an intel mac that runs everything just fine). I don't know if the behavior is specific to M1 or to some other difference between the machines (compiler toolchain, OS, goodness knows what else), but I see that @LewisAJones was on M1 and also that a related issue here #54 suggests that the M1 architecture is implicated. In this comment I'll use "M1" and "Intel" as shorthands for everything that might be different between the machines.
The behavior is pretty spooky, and comes from dggridR:::GEO_to_SEQNUM
. On the M1, if I do:
library(dggridR)
grid_large <- dgconstruct(res = 6)
dgGEO_to_SEQNUM(grid_large, -85, 30)
I get
FATAL ERROR: DgQ2DDtoIConverter::convertTypedAddress(): coordinate out of range: (27, 25)
$seqnum
[1] 729
This is particularly dangerous, because the fatal error didn't actually raise an error in the R session, it did produce a syntactically correct output, and the output is wrong. On an intel mac, I get 3672 as the seqnum, with no FATAL ERROR
message.
But it gets spookier, and even (much) more dangerous.
The coordinates where the M1 raises the message and then fails are geographically coherent. For example:
# These all raise the `FATAL ERROR` message and return 729
dgGEO_to_SEQNUM(grid_large, -84.20946, 30.3995)
dgGEO_to_SEQNUM(grid_large, -84.2, 30.4)
dgGEO_to_SEQNUM(grid_large, -85, 30)
dgGEO_to_SEQNUM(grid_large, -85, 31)
dgGEO_to_SEQNUM(grid_large, -84, 31)
dgGEO_to_SEQNUM(grid_large, -83, 31)
# If we move around enough, we (seemingly) flip over to an adjacent cell. Still raises
# `FATAL ERROR`, but now with seqnum = 730
dgGEO_to_SEQNUM(grid_large, -82, 31)
# These do not raise the `FATAL ERROR` message, and they return either 3671, 3672, or 3698
dgGEO_to_SEQNUM(grid_large, -85, 32)
dgGEO_to_SEQNUM(grid_large, -84, 30)
dgGEO_to_SEQNUM(grid_large, -85, 33)
dgGEO_to_SEQNUM(grid_large, -85, 29)
dgGEO_to_SEQNUM(grid_large, -85, 28)
HOWEVER, although on the M1 mac dgGEO_to_SEQNUM(grid_large, -85, 32)
does not raise the FATAL ERROR
message and returns $seqnum = 3671
(see above), the Intel mac returns a DIFFERENT seqnum $seqnum = 728
(and still no errors)!!! Thus, an M1 user could get the wrong behavior silently!
I've confirmed that this behavior comes directly from the dggridR:::GEO_to_SEQNUM
call and doesn't depend on any usual suspects such as the state of sf_use_s2()
.
So then I reverted to d92fc92, and all of the weird behavior on the M1 vanished. No more FATAL ERROR
messages; all seqnums mentioned above consistent with the Intel mac running the CRAN version. More spelunking and waiting to compile the C++... and we have our culprit in 6d9129a. There, the behavior is similar to the contemporary CRAN behavior, except that rather than seeing the FATAL ERROR
messages, the "bad" coordinates just crash my R session. If I run any of the "good" coordinates (including the one that gives the apparently wrong seqnum), I get the same (sometimes incorrect) seqnum as I did running the CRAN version on the M1.
I don't have any brilliant ideas about what to do here, except to mention to @LewisAJones that you might be able to make progress by reverting with remotes::install_github("r-barnes/dggridR", ref = "ec2a040")
(the commit before 6d9129a). But the bigger problem is the behavior on dgGEO_to_SEQNUM(grid_large, -85, 30)
, because the user won't even see the weird FATAL ERROR
message to follow up on and hopefully land here.
Here's the sessionInfo from the M1, which is where all the problems are occurring:
> sessionInfo()
R version 4.2.2 (2022-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.2
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] dggridR_3.0.0 sp_1.6-0 sf_1.0-9 rlang_1.0.6 dplyr_1.1.0
loaded via a namespace (and not attached):
[1] Rcpp_1.0.10 rstudioapi_0.14 magrittr_2.0.3 units_0.8-1
[5] tidyselect_1.2.0 lattice_0.20-45 R6_2.5.1 fansi_1.0.4
[9] tools_4.2.2 grid_4.2.2 KernSmooth_2.23-20 utf8_1.2.3
[13] cli_3.6.0 e1071_1.7-13 DBI_1.1.3 class_7.3-21
[17] tibble_3.1.8 lifecycle_1.0.3 vctrs_0.5.2 glue_1.6.2
[21] proxy_0.4-27 compiler_4.2.2 pillar_1.8.1 generics_0.1.3
[25] classInt_0.4-9 boot_1.3-28.1 pkgconfig_2.0.3
from dggridr.
This issue has been fixed in PR #66, at least for the use cases flagged above. While this PR is not merged, Apple Silicon users can install from my fork e.g. remotes::install_github("SebKrantz/dggridR")
.
from dggridr.
@SebKrantz i updated my dggridR 3.0.0 to 3.1.0 follow the code
library(remotes) remotes::install_github("SebKrantz/dggridR")
but it still not works well when i run
`library(dggridR)
#Generate a dggs specifying an intercell spacing of ~25 miles
dggs <- dgconstruct(spacing=100, metric=FALSE, resround='nearest')
#Read in the South Africa's borders from the shapefile
sa_border <- st_read(dg_shpfname_south_africa(), layer="ZAF_adm0")
st_crs(sa_border) = 4326
#Get a grid covering South Africa
sa_grid <- dgshptogrid(dggs, dg_shpfname_south_africa())
#Plot South Africa's borders and the associated grid
p <- ggplot() +
geom_sf(data=sa_border, fill=NA, color="black") +
geom_sf(data=sa_grid, fill=alpha("blue", 0.4), color=alpha("white", 0.4))
p
`
from dggridr.
from dggridr.
Thanks for your response.
after adding library(sp) library(sf)
to my script.it works well for me on Apple M1 .
i think maybe dggridR 3.1.0 solve the hole
from dggridr.
@Daniel-Huff, sp
was removed in 3.1.0 thus you don't need to import it. I am also unable to reproduce your issue using a M1 mac:
library(dggridR)
library(ggplot2)
library(sf)
#> Linking to GEOS 3.11.0, GDAL 3.5.3, PROJ 9.1.0; sf_use_s2() is TRUE
#Generate a dggs specifying an intercell spacing of ~25 miles
dggs <- dgconstruct(spacing=100, metric=FALSE, resround='nearest')
#> Resolution: 7, Area (mi^2): 14491.99750509, Spacing (mi): 93.7218051701576, CLS (mi): 107.077441232619
#Read in the South Africa's borders from the shapefile
sa_border <- st_read(dg_shpfname_south_africa(), layer="ZAF_adm0")
#> Reading layer `ZAF_adm0' from data source
#> `/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/dggridR/extdata/ZAF_adm0.shp'
#> using driver `ESRI Shapefile'
#> Simple feature collection with 1 feature and 1 field
#> Geometry type: MULTIPOLYGON
#> Dimension: XY
#> Bounding box: xmin: 16.45802 ymin: -46.93639 xmax: 37.87945 ymax: -22.14108
#> CRS: NA
st_crs(sa_border) = 4326
#Get a grid covering South Africa
sa_grid <- dgshptogrid(dggs, sa_border)
#Plot South Africa's borders and the associated grid
p <- ggplot() +
geom_sf(data=sa_border, fill=NA, color="black") +
geom_sf(data=sa_grid, fill=alpha("blue", 0.4), color=alpha("white", 0.4))
p
Created on 2023-08-07 with reprex v2.0.2
Note that in v3.1.0, you can also direcly pass the sf data frame to dgshptogrid()
.
Given that this is working well and solving people's problems, it would be nice if @r-barnes could still consider merging it and pushing it to CRAN.
from dggridr.
Related Issues (20)
- Vignette not available HOT 5
- installation failed HOT 7
- How to export successfully? HOT 1
- plotting problems HOT 1
- Issues in ArcGIS Pro 3D map. HOT 1
- how to export GeoJSON type? HOT 1
- missing cells when creating a small-scale grid (~10 km or less spacing)? HOT 2
- Can dggridR output neighbors of each cell? HOT 2
- FATAL ERROR: coordinate out of range on M1 mac HOT 1
- vignette βdggridRβ not found HOT 1
- Cannot install dggridR on R 4.2.1 HOT 9
- Tag or release HOT 1
- Hexagons at resolution 16 appear distant from each other not sharing their borders HOT 4
- Return cell centroids instead of shape furing grid generation HOT 1
- Triangular grid HOT 1
- gaps between grid cells
- How to Create FULLER43H: Fuller Mixed Aperture 4,3 Hexagonal Grid?
- Grid cell sizes are different - but should be the same?
- Making a high resolution grid for a small area
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dggridr.