[BUG] aantal/100ha is broken
SanderDevisscher opened this issue · 12 comments
Describe the bug
On the map "Gerapporteerd afschot/100ha van wild zwijn in 2021" all communes with shot animals are within the second bin (0-0.25) while they should be more spread between bins.
When looking at the graphs "Evolutie gerapporteerd afschot Vlaanderen" & "Evolutie gerapporteerd afschot Gemeente" the values on the y-axis have weird units attached to it.
To Reproduce
Steps to reproduce the behavior:
- Go to 'faunabeheer.inbo.be'
- Click on 'Eenheid'
- Select 'Aantal/100ha'
- Select some communes
- See error
Expected behavior
- larger & more diverse values on map
- no weird units on graph
Screenshots
Additional context
Issue occurs at all years with all species.
Issue does not occur on wbe-page
Git SHA (after 0.3.1)
9286fea
It is because the 'OPPERVL' I read from ~/git/reporting-rshiny-grofwildjacht/data/provinces.geojson in createShapeData() is in a different unit.
Geodetic CRS: +proj=longlat +datum=WGS84
UIDN TERRID geometry OIDN NAAM NISCODE NUTS2
1 6 357 MULTIPOLYGON (((4.773922 51... 2 Antwerpen 10000 BE21
2 7 359 POLYGON ((5.08873 51.04982,... 4 Vlaams Brabant 20001 BE24
3 9 356 POLYGON ((4.260741 51.34843... 5 Oost-Vlaanderen 40000 BE23
4 10 355 MULTIPOLYGON (((5.538639 51... 1 Limburg 70000 BE22
5 11 351 POLYGON ((3.366323 51.36899... 3 West-Vlaanderen 30000 BE25
LENGTE OPPERVL
1 409906.2 2876444170
2 507999.1 2118893799
3 404985.3 3008166146
4 397732.6 2428024237
5 356653.0 3197075771
@SanderDevisscher I see 2 options:
(1) I update the code such that the current AREA is divided by 10^6 to have it in 100ha. Next, we deploy a new version of the app with the code fix
(2) You update the raw geojson file at your side to have the unit for 'OPPERVL' to be in 100ha and run reportingGrofwild::createShapeData() to update the data in the S3 bucket.
@mvarewyck I think option 2 is the most sustainable and thus preferable. However I fear this might revive #431 which hasn't been solved yet. So I suggest a intermediate solution: I'll recalculate the provinces areas of both communes and provinces, I'll provide the updated geojsons and you run reportingGrofwild::createShapeData()? after testing the UAT I'll migrate to PRD.
The issue seems to occur for all region levels. Also why don't we use the _habitats.csv files ?
The issue seems to occur for all region levels. Also why don't we use the
_habitats.csvfiles ?
Yes, I expect it to occur for all regions.
It was not being used for historical reasons: the unit 'aantal/100ha' was implemented before the habitats files were available. I quickly checked and it should be rather straightforward to also use it for 'aantal/100ha' (now only for 'aantal/100ha bos &natuur').
Can you implement this ?
Should anything change for the createshapedata flow ? like add habitat files to temporary spatial data folder as source for createshapedata ?
Can you implement this ? Should anything change for the
createshapedataflow ? like add habitat files to temporary spatial data folder as source forcreateshapedata?
Yes, I've implemented but need to run some more tests to see whether it affects any other plots.
I would keep the createshapedata flow as it is for now. I've included a comment in the code that the AREA calculation might be redundant.
Yes, I've implemented but need to run some more tests to see whether it affects any other plots.
Seems to work fine, except for fbz_gemeentes. I need to fix for the fact that some regions need to be matched multiple times with the habitat data. I merge spatial data and habitat data based on the NISCODE. Then e.g. for Aartselaar, it occurs in the spatialData both as 6_Aartselaar and 4_Aartselaar, while in the in the habitatData it occurs only as 4_Aartselaar.
@SanderDevisscher Can we use the same area for both regions or should it be split up in habitat data (fbz_gemeentes_habitats.csv)?
I can further look into this on Monday.
For reference: #295
> spatialData$fbz_gemeentes[grepl("Aartselaar", spatialData$fbz_gemeentes$NAAM), ]
Simple feature collection with 2 features and 21 fields
Geometry type: GEOMETRY
Dimension: XY
Bounding box: xmin: 4.353738 ymin: 51.10949 xmax: 4.408756 ymax: 51.15102
Geodetic CRS: +proj=longlat +datum=WGS84
NAAM GEOMDAT PERIMETER GEOMID TERRID NISCODE Code TERRDATINW
4 4_Aartselaar 20021009 22076.82 140 140 11001 4 19820101
5 6_Aartselaar 20021009 22076.82 140 140 11001 6 19820101
Shape_Le_1 REGION_ID EUCODE REGION_ AREA
4 14094.90 4 BE21100001 4 3509671
5 15238.35 4 BE21100001 4 7523344
geometry FID_Gemeen OBJECTID Shape_Leng FID_Faunab
4 MULTIPOLYGON (((4.380721 51... 4 45 22076.82 4
5 POLYGON ((4.401422 51.14982... 4 46 22076.82 7
CENTROID_X Aantal CENTROID_Y FBZ_GEMLIN
4 149886.1 0 202634.3 4_11001
5 151468.9 0 202317.0 6_11001
@mvarewyck this version of fbz_gemeentes_habitats.csv now contains a id column which can be used to add the habitat data to fbz_gemeentes.geojson. Can you confirm the file is ok like this ?
Yes, looks good now!
@SanderDevisscher Can you replace the habitat data on UAT bucket using reportingGrofwild::createHabitatData()? I don't have 'WBE_habitats_2023.csv'
I'm a bit busy today, here's WBE_habitats_2023.csv. Can you upload it ?
I'm a bit busy today, here's WBE_habitats_2023.csv. Can you upload it ?
@SanderDevisscher Done, created a PR #440