Help with Patch Proximity and Connectivity Index in Fragstats

I'm using Fragstats to analyze the connectivity of urban green areas in Pune, but I'm encountering an issue with the patch proximity metric and connectivity index. Here's a summary of what I've done so far:

• I had multiple vector files representing different types of urban areas, which I merged into a single layer. Each patch has its own unique ID.
• I converted the merged vector layer into a raster format and then ran Fragstats, selecting all metrics.
• I did not upload any class attribute table.

The problem is that I’m getting zero values for most of the patch proximity metrics and N/A for the connectivity index. I’ve checked the raster data, and everything seems correct, but I suspect something might be off either with the raster conversion process or the thresholds in Fragstats.Could anyone suggest:

1. If I need to adjust the proximity threshold or other parameters?
2. Whether I need to upload a class attribute table for these metrics?
3. Any common mistakes I should check in the raster conversion or Fragstats setup?

Thanks in advance for your help!Note: Cell size was 30 and search radius as 150 for PROX.

Hi Mehta,

If each patch has a unique ID after everything is converted to raster then you don't have a landscape in the sense Fragstats needs. Each cell in this case will belong to a patch not a class (conversely, each patch will be a class in itself). A class comprises of multiple cells aggregated into distinct patches. Only then we can talk about relationships between patches (connectance, proximity, etc) of the same class.
So the first step would be to properly prepare the landscape.

The second step is to choose parameter values that are meaningful for your desired analysis. 150 meters sounds a bit short in a landscape of 30 meter cells (only 5 cells) but if it makes sense to you you can use it.

Creating and uploading a class descriptor table will make the interpretation of the results easier and more intuitive. I think you should do it if it's not too much effort.

Good luck with your analysis and enjoy using Fragstats.

Best regards,
Eduard

Hi Eduard,

Thanks again for your previous response—it was very helpful! I followed your advice and reclassified my patches into broader classes (e.g., parks, gardens, etc.), and I also created and uploaded a class descriptor table. This definitely helped with the analysis and made the Fragstats output more intuitive.

However, I’m now facing another challenge. I want to join the Fragstats results (ENN, PROX) to my attribute table in ArcGIS for further site selection analysis. My goal is to get these values for specific areas in my study. The issue is:

My original attribute table in ArcGIS has 4616 rows.
The Fragstats results are not matching exactly with the number of rows in my attribute table.
I'm particularly interested in getting the Euclidean Nearest Neighbor (ENN) and Proximity (PROX) values for separate patches/areas, but the mismatch in the number of rows between ArcGIS and Fragstats is causing issues.

Could you provide some guidance on how to ensure the correct linkage between Fragstats results and my ArcGIS attribute table? Is there a specific setting in Fragstats or ArcGIS that I should adjust to get a matching output?

Thanks in advance for your help!

Best regards,
Vaidehi Mehta

Hi Mehta,

I don't think there is a shortcut for your problem but I guess you could use the Patch ID (PID) layer output from Fragstats to match the patches in your ArcGIS layer. Some may be aggregated or split depending on how the neighborhood rule applies in each case.

Or you could simply vectorize the PID and have a layer and a table matching your Fragstas results.

Your original patch layer is very unlikely to match the output from Fragstats because the patches are identified based on your neighborhood option. You can get two somewhat different set of patches depending on your neighborhood option and none may match the original.

Your best option (if possible) is to use the PID output because it will match the results perfectly. If you vectorize it, you get the benefit of a matching attribute table.

I hope this helps.

Best regards,
Eduard