Explain the connectivity metric more fully

[anders-kolstad]

From the documentation I take that the connectivity metric is calculated as the mean distance to other mire polygons within a 500 m buffer. But also in the code I see that @VegarBakkestuen calculate mean distance to infrastructure. Why is this?

How can infrastructure influence the mean distance to other mire polygons, esp when adding the infrastrukture layer does not split polygons?

It appears that with this metric large polygons can have low connectivity , so probably polygygon size does not influence the metric, yet we want the metric to penalise the fragmentation of large intact peatlands. Actually, fragmenting a large peatland could increase the connectivity with this metric, I think, because the distance between the two new polygons will be very short and pull down the average distance.

[VegarBakkestuen]

The calculation of mean distance to infrastructure provides an insight into how accessible or disrupted a mire polygon is due to the presence of infrastructure, such as roads or other human-made structures. This can be an important aspect of connectivity analysis, especially when considering the impact of infrastructure on wildlife movement or hydrological connections. It helps capture how easily organisms or water can move across the landscape in the presence of these barriers. Infrastructure, such as roads, can act as barriers, and the mean distance to infrastructure can influence the overall mean distance to other mire polygons. If a mire polygon is close to infrastructure, it may have a lower mean distance to other mire polygons because it's more accessible. Conversely, if a mire polygon is far from infrastructure, it may have a higher mean distance because it's less connected due to the presence of barriers.

You're correct that this connectivity metric might not directly consider the size of mire polygons. This can be a limitation if we want to specifically penalize the fragmentation of large intact peatlands. As you've noted, the metric can be misleading in such cases because splitting a large peatland could lead to a lower average distance due to the short distance between the new polygons. To address this concern, we may need to modify the metric to consider the size of the polygons explicitly. For example, we could introduce a weighting factor that accounts for both distance and polygon size? But I don't think they introduced such a weithing in the ØT fjell report.

And big roads should split wetland polygons. The one in the example in the report is a mountain road (setervei) much smaller than a 10 meter pixel in Sentinel 2 used for making the wetland model.

[anders-kolstad]

Ok, I understand a bit more now. I see that distance to infrastructure is a relevant aspect of connectivity as such, but it's not part of the actual indicator calculation, right? If so, can we add a short note in the code annotation that that step is for a deeper insight?

Also, I ment that adding the infrastructure lauer does not automatically split polygons, and it depends on the mire models ability to detect it. Since the wetland map sometimes have polygons that span roads, we could consider splitting those polygons, esp if we are interested in hydrological connectivity. If we want to capture hydrological connectivity we might need to think differently about some other things as well, like ditches, so we can out a pin in that for now.

The size of polygons is a bit arbitrary. For example, two large mires can be connected with a very narrow strip and in reality be no more connected than two disjunt mires. In the map view below we see that the orange polygon is quite patchy, and in fact it is split by a road in the middle. This arbitrariness might make it less informative studying the values for individual polygons, but when aggregated to a regional indicator value (#144) , then I don't see that it should indroduce bias. But if we where to make a time series for this indicator based in two wetland models from different times, then we need to think about this some more.

[VegarBakkestuen]

I made some changes to the GEE script. In the first script, I was encountering issues with getting many 0 values for distance because it included the myr area itself when calculating distances. The new script addresses this issue by using the myr.not() expression to exclude the myr area itself from distance calculations. And in addition I now use fastDistanceTransform:

// Bruk fastDistanceTransform for å beregne avstand fra myrområdene var distanceToMyr = myr.not() .fastDistanceTransform({ neighborhood: bufferDistance }) .sqrt() .rename('myrDistance');

This part of the script calculates the distance to the nearest myr area using the fastDistanceTransform function. It computes the distance within a specified neighborhood (defined by bufferDistance) and renames the resulting image to 'myrDistance'.

This is the complete script:

// Senter kartet til en bestemt geografisk posisjon (bredde- og lengdegrad) og velg en zoomnivå Map.setCenter(11.0534047, 62.14137, 12);

// Laste inn myr datasett fra Google Earth Engine Data var myrpred2 = ee.ImageCollection('users/vegarbakkestuen/Myr153'); var myr = myrpred2.mean();

// Laste inn infrastrukturindeks fra Google Earth Engine Data var infrastruktur = ee.Image('users/vegar/NY_INFRA_IND');

// Definer en bufferavstand (i meter) som bestemmer området som blir analysert rundt hvert myrpolygon var bufferDistance = 500;

// Funksjon for å beregne gjennomsnittlig avstand til nærmeste nabo-myr og infrastruktur var calculateMeanDistance = function (feature) { // Hent myrpolygonets sentrum var myrCenter = feature.geometry().centroid(100);

// Bruk fastDistanceTransform for å beregne avstand fra myrområdene var distanceToMyr = myr.not() .fastDistanceTransform({ neighborhood: bufferDistance }) .sqrt() .rename('myrDistance');

// Filtrer infrastrukturbildet basert på grenseverdien var threshold = 2; // Definer din grenseverdi for infrastruktur var filteredInfrastructure = infrastruktur.gt(threshold);

// Bruk fastDistanceTransform for å beregne avstand fra infrastruktur var distanceToInfra = filteredInfrastructure .fastDistanceTransform({ neighborhood: bufferDistance }) .sqrt() .rename('infraDistance');

// Reduser avstandsbildene til gjennomsnittlig spikselverdier var meanDistanceToMyr = distanceToMyr.reduceRegion({ reducer: ee.Reducer.mean(), geometry: myrCenter.buffer(bufferDistance), scale: 10, // Oppløsningen til datasettet (meters per piksel) maxPixels: 1e13 });

var meanDistanceToInfra = distanceToInfra.reduceRegion({ reducer: ee.Reducer.mean(), geometry: myrCenter.buffer(bufferDistance), scale: 10, // Oppløsningen til datasettet (meters per piksel) maxPixels: 1e13 });

// Hent gjennomsnittlige spikselverdiene fra reduksjonene var meanDistanceToMyrValue = ee.Number(meanDistanceToMyr.get('myrDistance')); var meanDistanceToInfraValue = ee.Number(meanDistanceToInfra.get('infraDistance'));

// Beregn kvotienten (forholdet mellom avstand til infrastruktur og avstand til myr) var kvotient = meanDistanceToInfraValue.divide(meanDistanceToMyrValue);

var properties = { 'mean_myr_distance': meanDistanceToMyrValue, 'mean_infra_distance': meanDistanceToInfraValue, 'kvotient': kvotient };

return feature.set(properties); };

// Velg områder med myr (myrinnhold > 80%) og bruk dette som geometri for analysen var omraderMedMyr = myr.gt(0.8).selfMask();

// Hent geometriene for hvert område med myr var omraderGeometries = omraderMedMyr.reduceToVectors({ geometry: geometry, scale: 10, // Oppløsningen til datasettet (meters per piksel) maxPixels: 1e13 });

// Bruk funksjonen calculateMeanDistance for å beregne gjennomsnittlig avstand til nærmeste nabo-myr og infrastruktur var omraderMedMeanDistance = omraderGeometries.map(calculateMeanDistance);

// Legg til lag som viser myrpolygonene og lag med gjennomsnittlig avstand til nærmeste nabo-myr og infrastruktur på kartet Map.addLayer(omraderMedMyr, { min: 0, max: 1, palette: ['white', 'green'] }, 'Myrpolygoner'); Map.addLayer(omraderMedMeanDistance, { min: 0, max: 500, palette: ['blue', 'yellow', 'red'] }, 'Gjennomsnittlig avstand til nærmeste nabo-myr og infrastruktur');

// Eksporter resultatene som en Shapefile til Google Drive Export.table.toDrive({ collection: omraderMedMeanDistance, description: 'Gjennomsnitt_avstand_til_myr_infra_mean2', fileFormat: 'SHP', });

[VegarBakkestuen]

I needed to correct a new mistake; myr.not() was used to select areas that were not myr (myr areas were represented by 0). However, this also included the myr area itself in the calculation, resulting in incorrect zero-distance values.

To correct this mistake and calculate the distance to the nearest myr area (excluding itself), the code should be updated as follows: // Bruk fastDistanceTransform for å beregne avstand fra myrområdene var distanceToMyr = myr.eq(1) // Select myr areas .fastDistanceTransform({ neighborhood: bufferDistance }) .sqrt() .rename('myrDistance');

[VegarBakkestuen]

Infrastructure can influence the mean distance to other mire polygons in several ways, even when adding the infrastructure layer itself does not directly split polygons. The infrastructure index is based on national maps and accurately represents physical features like roads that do split mire polygons, then the impact of infrastructure on mire polygon connectivity should be accurate and aligned with the actual landscape conditions. In this case, roads that physically split mire polygons will indeed affect connectivity by creating barriers between the divided parts. But remember that the wetland map is based on 10 m Sentinel 2 pixels, some roads less wide than this can accidentally be classified as mire.

Then we have an issue on cables. The impact of cables on mire polygon connectivity can depend on their physical characteristics and they are represented in the infrastructure data, but they are given less weigh. Their influence on connectivity index may be limited, as the mean distance metric primarily measures distances within polygons.

[VegarBakkestuen]

And you are correct in your observation. The metric that we are using to calculate mean distance to other mire polygons may not necessarily penalize the fragmentation of large intact peatlands, and in some cases, it might even show an unexpected increase in connectivity. But it is the same used in økologisk tilstand fjell. There are several ways to improve this in the future like weighted mean distance or spatial clustering analysis. But the data contains almost 5 million wetland polygons and it is time consuming to calculate advanced algorithms.

[VegarBakkestuen]

The new updated script is below: Note that it uses minimum distance instead of mean distance:

// Laste inn myr datasett fra Google Earth Engine Data var myrpred2 = ee.ImageCollection('users/vegarbakkestuen/Myr168NN'); var myr = myrpred2.mean();

// Laste inn infrastrukturindeks fra Google Earth Engine Data var infrastruktur = ee.Image('users/vegar/NY_INFRA_IND');

// Konverter infrastruktur til en vektorbasert maske med terskelverdi 2 var infrastrukturMask = infrastruktur.gt(2);

// Masker infrastrukturen med myrpolygonene var maskedInfra = infrastrukturMask.mask(infrastrukturMask);

// Definer en bufferavstand (i meter) som bestemmer området som blir analysert rundt hvert myrpolygon var bufferDistance = 500;

// Funksjon for å beregne minimum avstand mellom myrer og infrastruktur innenfor samme datasett var calculateMinimumDistance = function (feature) { // Beregn avstanden til nærmeste nabo-myrene ved å bruke map-funksjonen var minDistanceToMyr = ee.FeatureCollection(omraderMedMyrFC) .filter(ee.Filter.neq('system:index', feature.get('system:index'))) .map(function (neighbor) { var distanceToMyr = feature.geometry().distance(neighbor.geometry(), bufferDistance); return ee.Feature(null, {'distance_to_myr': distanceToMyr}); });

// Finn den minimale avstanden til myr ved å sortere samlingen minDistanceToMyr = minDistanceToMyr.sort('distance_to_myr');

// Hent den minimale avstanden til myr fra den første funksjonen i samlingen var minDistanceToMyrValue = ee.Number(minDistanceToMyr.first().get('distance_to_myr'));

// Konverter infrastrukturen til en vektorbasert maske var infraVector = maskedInfra.reduceToVectors({ geometry: feature.geometry().buffer(bufferDistance), // Bruk buffer rundt myrpolygonet scale: 10, // Oppløsningen til datasettet (meters per piksel) maxPixels: 1e13 });

// Beregn avstanden til infrastruktur ved å finne avstanden til nærmeste nabo i infrastrukturen var distanceToInfra = feature.geometry().distance(infraVector.geometry(), bufferDistance);

// Legg til avstandsverdiene som egenskaper feature = feature.set({ 'min_myr_distance': minDistanceToMyrValue, 'min_infra_distance': distanceToInfra, 'kvotient': distanceToInfra.divide(minDistanceToMyrValue) });

return feature; };

// Velg områder med myr (myrinnhold > 80%) og bruk dette som geometri for analysen var omraderMedMyr = myr.gt(0.8).selfMask();

// Hent geometriene for hvert område med myr var omraderMedMyrFC = omraderMedMyr.reduceToVectors({ geometry: geometry, // Bruk den definerte geometrien scale: 10, // Oppløsningen til datasettet (meters per piksel) maxPixels: 1e13 });

// Bruk funksjonen calculateMinimumDistance for å beregne minimum avstand til nærmeste nabo-myr og infrastruktur var omraderMedMinimumDistance = omraderMedMyrFC.map(calculateMinimumDistance);

// Legg til lag som viser myrpolygonene og lag med minimum avstand til nærmeste nabo-myr og infrastruktur på kartet Map.addLayer(omraderMedMyr, { min: 0, max: 1, palette: ['white', 'green'] }, 'Myrpolygoner'); //Map.addLayer(infrastruktur, { min: 0, max: 1, palette: ['white', 'blue'] }, 'infra'); Map.addLayer(omraderMedMinimumDistance, { min: 0, max: 500, palette: ['blue', 'yellow', 'red'] }, 'Minimum avstand til nærmeste nabo-myr');

// Eksporter resultatene som en Shapefile til Google Drive Export.table.toDrive({ collection: omraderMedMinimumDistance, description: 'NYMinimum_avstand_til_myrinfrastruktur, fileFormat: 'SHP', });