[BUG] Vervormde leafletkaartjes
RuttenAnneleen opened this issue · 29 comments
In de dev-versie van de faunabeheer website zijn de leafletkaartjes momenteel vervormd (uitgerokken en in bij wildschade ligt Vlaanderen in Frankrijk)
issue occurs locally (via docker) & on UAT
On all public pages:
afschot :
wildschade :
achtergrondinfo dashboard :
issue is not present on private UAT (wbe-dev.inbo.be)
This issue is breaking
@SanderDevisscher I can reproduce. I guess it's due to a wrong projection. Did you update the spatial data?
I did not consciously, but I'll check if something changed.
I did not consciously, but I'll check if something changed.
Last update is from 20th October: spatialData_sf.RData 2023-10-20T09:42:20.000Z
I did update the spatial rdata but the source data for the communes for example did not change. I added the wbe binnengrenzen for 2023
In case of the wildschade maps, the points are placed correctly but the communes are placed somewhere in France1.
But when I look at the source data for the communes they seem to be placed correctly2
1
2
@SanderDevisscher Could you send me one of the geojson files you use as input in createShapeData()? E.g. provinces.geojson.
this zip contains provinces.geojson I use as input. this file was last changed 3 years ago.
provinces.zip
The input file looks fine. I'm creating new shapes spatialData_mv.RData in the bucket, to detect whether the problem persists.
If I create new shape data, the maps look correct
readS3(file = "spatialData_mv.RData")
leaflet(spatialData$provinces) %>% addTiles() %>% addPolygons()
If I use the current sf shapes on the bucket, it doesn't look fine
readS3(file = "spatialData_sf.RData")
leaflet(spatialData$provinces) %>% addTiles() %>% addPolygons()
@SanderDevisscher Which R package versions did you use when creating the shape data?
> packageVersion("geojsonsf")
[1] ‘2.0.3’
> packageVersion("sf")
[1] ‘0.9.8’
I used the following versions:
> packageVersion("geojsonsf")
[1] ‘2.0.3’
> packageVersion("sf")
[1] ‘1.0-14’
so probably sf is the culprit
so probably sf is the culprit
Exactly, I found this in their NEWS file:
use s2 spherical geometry as default when coordinates are ellipsoidal. This can be switched off (defaulting to planar geometry, using GEOS, as in sf < 1.0-0) by setting environment variable _SF_USE_S2 to false before package sf is loaded, or by sf_use_s2(FALSE); #1649
I can try to implement a fix in the code.
For now, I think the quickest solution is you add sf_use_s2(FALSE) in your script?
I should read the News more often :-/
I should read the News more often :-/
No one does, until they get into trouble :)
NB: I'm not allowed to remove files from S3 bucket anymore. So I failed to remove my test file
aws.s3::delete_object(object = "spatialData_mv.RData", bucket = config::get("bucket", file = system.file("config.yml", package = "reportingGrofwild")))
I'll remove it
PS I've uploaded the files using sf_use_s2(FALSE) but my laptop is busy with something else so haven't had time to test!
The maps don't look fine yet. I'll implement a fix in the code on our side.
I forgot to load sf so sf_use_s2(FALSE) failed, rerunning now
done, testing locally
issue persist :-(
I've deleted "spatialData_mv.RData"
I've deleted "spatialData_mv.RData"
I see :) You'll have to do once more.
I've deleted "spatialData_mv.RData"
I see :) You'll have to do once more.
done
should I upload the spatialdata again ?
should I upload the spatialdata again ?
Yes, I want to be sure it works on your side using createShapeData()