Consistent source of elevation data

[brynpickering]

At the moment, 3 arc second data is used for most of Europe, but it doesn't cover anything further North than 60N. To get Northern Nordic countries covered, I think the current approach is to supplement the data with 7.5 arc second GMTED data. Perhaps, for consistency, a single data source could be used, such as this attempt at filling in missing 3 arc second SRMT data: www.viewfinderpanoramas.org/dem3.html

[brynpickering]

@timtroendle after spending some time with EUDEM slope data, I have a method for processing it efficiently to get me a percentage available area for PV/wind on a "land-cover.tif" resolution. For comparison, the current method gives the following for near lake Geneva and across Europe (black = unavailable, white = available):

The new method would give the following (black = unavailable, white = available, gradient between indicates % area of tile available):

What we see is that, as expected, the binary indicator currently being used is too conservative, leading to many tiles being unavailable due to slope levels being perceived as too high when there is actually some percentage of the tile available for renewables deployment. I still need to fully quantify this difference on e.g. a national level. (edit: see below)

If this method is worth incorporating into the workflow, then I'm not sure how to incorporate it into the technically-eligible part of it. Namely, the binary indicator is currently used to switch tiles on/off, whereas this new indicator would need to be used to ascertain how much area in each tile is available. I assume this means it should be added into the rule invoking technically-eligible-area.py, but I'm a bit confused about how the different geoTIFFs are invoked in downstream rules...

[brynpickering]

I've now analysed each country:

	Available area for PV (EUDEM slope)	Available area for PV (current slope derivation method)	Diff of available area (from current method to using EUDEM slope)
country_code
AUT	23.745409	17.435512	1.361899
BEL	48.719916	46.666726	1.043997
BGR	48.384863	39.664101	1.219865
CHE	21.437984	14.464509	1.482109
CYP	25.131418	19.401198	1.295354
CZE	51.434518	45.642680	1.126895
DEU	58.977789	54.440393	1.083346
DNK	27.214287	27.183226	1.001143
EST	49.982117	49.994060	0.999761
GRC	10.486596	6.765412	1.550031
ESP	34.235245	27.886765	1.227652
FIN	49.187589	49.092151	1.001944
HRV	20.466139	16.725596	1.223642
HUN	54.905505	53.165866	1.032721
IRL	47.231235	45.429496	1.039660
ISL	42.208563	0.000000	inf
ITA	14.559876	10.890945	1.336879
LTU	60.881870	60.861813	1.000330
LUX	46.662229	37.198637	1.254407
LVA	54.071667	54.099441	0.999487
MNE	20.549528	9.669627	2.125162
MKD	34.601200	22.035211	1.570269
NLD	45.252168	45.228632	1.000520
NOR	11.189924	9.343354	1.197635
POL	68.429586	67.413675	1.015070
PRT	43.980715	36.971139	1.189596
ROU	47.386789	40.192612	1.178993
SWE	40.925751	39.976778	1.023738
SVN	27.188381	17.059800	1.593710
SVK	37.356925	29.510304	1.265894
GBR	25.967071	24.008591	1.081574
FRA	38.295325	34.903271	1.097184

Across Europe, (ignoring iceland, since the older dataset I'm using doesn't include it), available land increases from 29% to 38.8% for PV, based on a 10% slope limit.

[timtroendle]

@brynpickering, sorry for delaying this for so long. I appreciate this discussion, but it seems like a massive scope creep to me. Moving away from binary land eligibility to shares of eligibility may be worthwhile (in fact the latter is a method often employed in the literature), but it requires significant changes in the entire workflow.

I suggest to do the following: can we keep this issue to exchanging the data source only? Can we then discuss moving from binary eligibility to eligibility share in another issue (which is likely more a project than a single issue)? What do you think?

[brynpickering]

Sure, I will look into implementing that.