Structual connectivity of forests (field level @30m)

[kapildadheech]

Ticket Contents

Description

Forest connectivity is a key ecological indicator that can reveal fragmentation, core forest health, and edge effects. Using Land Use/Land Cover (LULC) data, we can estimate structural connectivity to determine if deforestation or degradation occurs in the core of forests or along peripheries. Computation at 30m resolution will allow field-level analysis, and vectorization will enable integration with Micro Watershed (MWS) and Area of Interest (AoI) boundaries for decision-making.

Goals

Goals

• Compute structural connectivity of forests at 30m resolution using LULC datasets.
• Identify core forest areas vs. peripheral zones to detect potential degradation or deforestation.
• Generate raster outputs representing forest connectivity metrics for AoI and MWS boundaries.
• Vectorize raster outputs into polygons for field-level or MWS-level analysis.
• Publish raster and vector outputs as Earth Engine assets with metadata.
• Enable visualization of forest connectivity and integration with other forest health indicators.

Expected Outcome

• Raster dataset (30m resolution) representing forest structural connectivity (e.g., core vs. edge, fragmentation index).
• Vectorized polygons for AoI/MWS with attributes:
  • Connectivity class (core, edge, fragmented)
  • Area (ha)
  • Relevant metrics (e.g., distance from edge, patch size)
• Published Earth Engine assets (raster + vector) with metadata (source, computation date, LULC datasets used).
• GEE visualizations showing spatial distribution of connectivity classes across forests.
• Validation report confirming coverage, accuracy, and proper classification of core vs peripheral

Acceptance Criteria

Data Acquisition

• LULC datasets (Sentinel-2, Landsat, or existing land cover maps) must be preprocessed and clipped to AoI/MWS boundaries.
• Resolution standardized to 30m.
• Cloud-free composite images must be generated.

Raster Computation

• Forest structural connectivity metrics must be computed per pixel (core, edge, fragmented).
• Entire AoI/MWS must be covered with no gaps.
• Metrics must allow differentiation between core and peripheral forest areas.

Vectorization

• Raster outputs must be converted to vector polygons using reduceToVectors() in GEE.
• Each polygon must include:
  • Connectivity class
  • Area (ha)
  • Relevant metrics (distance from edge, patch size)
• Polygons must align with AoI/MWS boundaries.

Asset Publishing

• Raster and vector outputs must be published as Earth Engine assets.
• Metadata must include source datasets, processing date, resolution, and classification schema.

Quality & Validation

• Coverage check: all forested areas within AoI/MWS are included.
• Accuracy check: connectivity classes match reference LULC or high-resolution imagery.
• Resolution check: raster outputs at 30m.
• Attribute check: all polygons include connectivity class, area, and metrics.
• GEE visualization confirms correct spatial distribution of core and peripheral zones.

Implementation Details

Data Sources

• Land Use/Land Cover datasets: Sentinel-2, Landsat-8/9, or national LULC maps.
• AoI/MWS boundaries.

Processing

• Compute forest connectivity metrics using moving window analysis, patch analysis, or fragmentation indices.
• Assign connectivity classes (core, edge, fragmented) per pixel.
• Clip raster outputs to AoI/MWS boundaries.

Vectorization & Publishing

• Vectorize raster outputs into polygons representing connectivity zones.
• Export polygons with attributes: class, area, patch size, distance from edge.
• Upload raster and vector layers as Earth Engine assets with metadata.

Visualization

• GEE visualization: color-coded connectivity classes (e.g., core = dark green, edge = light green, fragmented = yellow).
• Overlay with AoI/MWS boundaries for inspection.

Validation

• Compare outputs with reference LULC maps or high-resolution imagery.
• Check that core areas are correctly classified away from edges.
• Generate report: coverage, accuracy, and attribute completeness.

Mockups/Wireframes

No response

Product Name

KYL

Organisation Name

C4GT

Domain

No response

Tech Skills Needed

Python

Organizational Mentor

@amanodt @kapildadheech @ankit-work7

Angel Mentor

No response

Complexity

High

Category

Backend

[dipak0000812]

Hi @kapildadheech @amanodt @ankit-work7,

I'm interested in contributing to this forest connectivity analysis project as part of C4GT.

My Technical Foundation:

• Strong Python skills: Proficient with NumPy and Pandas for data processing and analysis
• AI/ML background: Experienced in building data pipelines, preprocessing workflows, and validation frameworks
• C++ proficiency: Comfortable with complex programming and optimization
• Fast learner: Successfully picked up new libraries and domains before, confident doing it again

Why I'm a Good Fit:
The core of this project is data processing at scale - handling raster data (essentially multi-dimensional arrays), applying spatial operations, and building automated workflows. This aligns perfectly with my NumPy/Pandas experience. Google Earth Engine's Python API will be a natural extension of what I already know.

While I'm new to GEE and geospatial analysis specifically, I've tackled similar learning curves before. My approach: learn fast, validate early, iterate continuously.

Risk Mitigation:
I'll deliver a working proof-of-concept on a small test area within the first 2 weeks. This lets you evaluate my approach and code quality early before committing to full implementation.

To get started, I need:

1. Which LULC datasets are you using (Sentinel-2, Landsat, or specific maps)?
2. Sample AoI/MWS boundary files for initial testing
3. Connectivity metric specifications (thresholds for core/edge/fragmented classification)
4. Any existing reference scripts or methodology documents

Timeline:

• Week 1-2: GEE ramp-up + proof-of-concept
• Weeks 3-4: Full implementation with validation
• Weeks 5-6: Vectorization, publishing, documentation
• Availability:15-20 hours/week with regular progress updates

[dipak0000812]

Hi @kapildadheech @amanodt @ankit-work7,

Ready to start immediately. To begin the proof-of-concept, I need:

1. LULC Dataset: Which should I use?

   • Sentinel-2 (which collection?)
   • Landsat 8/9
   • Or specific national LULC map?

2. Test Area: Can you provide:

   • Sample AoI/MWS boundary shapefile/GeoJSON
   • Or coordinates of a small test region (~100-500 km²)

3. Connectivity Metrics: What defines:

   • Core forest (distance from edge > X meters?)
   • Edge forest (distance threshold?)
   • Fragmented (patch size < Y hectares?)

4. Any existing code/references from similar projects?

[aaditeshwar]

Hi all, Do please join the discord channel and googlegroup linked from this announcement of the CoRE stack innovation challenge, and do participate in the challenge too: https://core-stack.org/core-stack-innovation-challenge-1st-edition/. Our first community call on Friday 3-4pm will be very useful to get started.

[dipak0000812]

@aaditeshwar @kapildadheech @amanodt @ankit-work7

Hi mentors, I'm ready to start the POC but need access to the Discord
channel and Google Groups mentioned in the challenge announcement.

Could you please share the links? I want to join Friday's community call.

Thanks!

[amanodt]

Please join the Discord channel https://discord.gg/FpMArraM2X and the core-stack-dev Google group https://groups.google.com/u/2/g/core-stack-dev

[Kunxal]

Hello mentors, @kapildadheech @amanodt @ankit-work7
I went through the Forest Connectivity (Structural Connectivity using LULC at 30m resolution) ticket in detail and found it very interesting and well aligned with my skills and learning goals.

I would like to request you to please allot/assign this issue to me. I am keen to work on the implementation, validation, and documentation as per the acceptance criteria mentioned in the ticket.

Please let me know if any prerequisites or additional context is required from my side before starting.

Looking forward to your guidance.

Thank you for your time and consideration.

Regards,
Kunal

[dipak0000812]

Hi @kapildadheech @amanodt @ankit-work7,

Sharing an update on Issue #228 from my side. I’ve completed an end-to-end implementation of the forest structural connectivity pipeline and validated it against the acceptance criteria in the ticket.

All functional requirements are covered:
– 30m resolution connectivity computation
– Core / edge / fragmented classification using distance-to-edge and patch size
– Full AoI/MWS coverage with no gaps
– Raster outputs + vectorized polygons with attributes (class, area in ha, patch size, distance from edge)

The only difference from the ticket description is architectural. I implemented this as a standalone Python backend module (numpy / scipy / rasterio / geopandas) instead of a GEE-native script. This was an intentional choice, aligned with the ticket being categorized as Backend and listing Python as the required skill. The outputs (GeoJSON / raster) are fully compatible with Earth Engine if publishing or visualization in GEE is required as a downstream step.

Before proceeding further, I’d like to confirm the intended final direction:
Option A: Accept this as the backend forest-connectivity module, with outputs optionally uploaded to GEE.
Option B: Add a minimal GEE compatibility layer (reduceToVectors + asset publishing) on top, while keeping Python as the reference implementation.

Once this is clarified, I can finalize documentation or add the required GEE bridge accordingly.

[amanodt]

Hi Dipak, Option B is preferable. Also, please share the outputs so that we can review and provide any feedback beforehand. Thanks and Regards Aman Verma Lead Engineer CoRE Stack

…

On Sun, Dec 21, 2025 at 7:13 PM Dipak Dhangar ***@***.***> wrote: *dipak0000812* left a comment (core-stack-org/core-stack-backend#228) <#228 (comment)> Hi @kapildadheech <https://github.com/kapildadheech> @amanodt <https://github.com/amanodt> @ankit-work7 <https://github.com/ankit-work7> , Sharing an update on Issue #228 <#228> from my side. I’ve completed an end-to-end implementation of the forest structural connectivity pipeline and validated it against the acceptance criteria in the ticket. All functional requirements are covered: – 30m resolution connectivity computation – Core / edge / fragmented classification using distance-to-edge and patch size – Full AoI/MWS coverage with no gaps – Raster outputs + vectorized polygons with attributes (class, area in ha, patch size, distance from edge) The only difference from the ticket description is architectural. I implemented this as a standalone Python backend module (numpy / scipy / rasterio / geopandas) instead of a GEE-native script. This was an intentional choice, aligned with the ticket being categorized as Backend and listing Python as the required skill. The outputs (GeoJSON / raster) are fully compatible with Earth Engine if publishing or visualization in GEE is required as a downstream step. Before proceeding further, I’d like to confirm the intended final direction: Option A: Accept this as the backend forest-connectivity module, with outputs optionally uploaded to GEE. Option B: Add a minimal GEE compatibility layer (reduceToVectors + asset publishing) on top, while keeping Python as the reference implementation. Once this is clarified, I can finalize documentation or add the required GEE bridge accordingly. — Reply to this email directly, view it on GitHub <#228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPT2H6Z7FD7XUMY6533RE534C2PYRAVCNFSM6AAAAACG3DASUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZYHAYDMOBQHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dipak0000812]

Hi @amanodt,

I’ve uploaded the sample outputs for the Kanke AoI to Google Drive.

The folder contains:
– connectivity.tif (30 m raster: 1 = Fragmented, 2 = Edge, 3 = Core)
– connectivity.geojson (vectorized connectivity polygons with attributes)
– report.json (area statistics and summary metrics)

Drive link:
Folder Link : https://drive.google.com/drive/folders/1yWELcJOPi7r-icFURRIcLLwEAQjzvQYI?usp=drive_link

Let me know if everything looks correct or if you’d like any changes before I proceed with the GEE asset publishing layer.

Regards,
Dipak

[dipak0000812]

Hi @amanodt,

Following up on my last update regarding Issue #228.

I’ve already shared the sample outputs for the Kanke AoI (30 m raster, vectorized GeoJSON, and summary report) and, as discussed earlier, I’m proceeding with Option B — keeping the Python backend as the reference implementation and adding a minimal GEE compatibility layer (reduceToVectors + asset publishing).

Before opening the PR, I just need a quick confirmation on the following so I can finalize cleanly:

Are the shared outputs acceptable in terms of classification logic (core / edge / fragmented) and attributes?

Okay to proceed with the PR including:

Python backend module (reference implementation)

GEE bridge for vectorization + asset publishing

Documentation describing both flows

Once confirmed, I’ll open the PR immediately.

Thanks,
Dipak

[amanodt]

Dipak, Thanks for sharing the outputs. We've checked them, but they don't seem to be correct and lies on plantation area instead of the forest area. It would be good if you could share a brief explanation of how you computed structural connectivity (data used, method, and key parameters like window size or distance thresholds, etc.). If you want any additional resources regarding this task, you can check the link below: https://link.springer.com/article/10.1007/s10661-025-14257-2 Also, we can connect over a call if you want to discuss it further. Thanks and Regards Aman Verma Lead Engineer CoRE Stack

…

On Sat, Jan 3, 2026 at 7:18 PM Dipak Dhangar ***@***.***> wrote: *dipak0000812* left a comment (core-stack-org/core-stack-backend#228) <#228 (comment)> Hi @amanodt <https://github.com/amanodt>, Following up on my last update regarding Issue #228 <#228>. I’ve already shared the sample outputs for the Kanke AoI (30 m raster, vectorized GeoJSON, and summary report) and, as discussed earlier, I’m proceeding with Option B — keeping the Python backend as the reference implementation and adding a minimal GEE compatibility layer (reduceToVectors + asset publishing). Before opening the PR, I just need a quick confirmation on the following so I can finalize cleanly: Are the shared outputs acceptable in terms of classification logic (core / edge / fragmented) and attributes? Okay to proceed with the PR including: Python backend module (reference implementation) GEE bridge for vectorization + asset publishing Documentation describing both flows Once confirmed, I’ll open the PR immediately. Thanks, Dipak — Reply to this email directly, view it on GitHub <#228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPT2H66A7DABIU2PVWUYGCD4E7CDFAVCNFSM6AAAAACG3DASUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMBXGA3DOMBXGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dipak0000812]

Hi @amanodt,

Thanks for reviewing the outputs and for flagging this.

You’re absolutely right — the earlier results were affected by the forest mask definition, which included plantation classes and therefore inflated connectivity metrics over plantation areas.

This has now been corrected. The pipeline has been updated to explicitly distinguish natural forest from plantations, and structural connectivity is computed only on natural forest classes, with plantation classes excluded by design.

Methodology summary:

Data: CoRE Stack LULC (Sentinel-2–derived), standardized to 30 m

Approach: Euclidean distance–based Morphological Spatial Pattern Analysis (MSPA)

Forest definition:

Included: natural forest classes (e.g., deciduous / evergreen as per LULC schema)

Excluded: plantation classes (explicitly filtered)

Connectivity thresholds:

Fragmented: < 100 m from non-forest edge

Edge: 100–300 m

Core: > 300 m from non-forest edge

I’m currently re-running the analysis with this corrected forest definition and will share the updated, plantation-free outputs on the issue once ready.

Thanks again for pointing this out — it helped tighten the semantic correctness of the pipeline.

— Dipak

[amanodt]

Dipak, Hope you know that we've been having weekly dev calls on Fridays at 3pm. Will be good to join these calls and discuss there too. Details here: https://core-stack.org/core-stack-innovation-challenge-1st-edition/ Join the Googlegroup <https://groups.google.com/u/2/g/core-stack-dev> and Discord channel <https://discord.gg/FpMArraM2X>. Thanks and Regards Aman Verma Lead Engineer CoRE Stack

…

On Wed, Jan 7, 2026 at 9:36 PM Dipak Dhangar ***@***.***> wrote: *dipak0000812* left a comment (core-stack-org/core-stack-backend#228) <#228 (comment)> Hi @amanodt <https://github.com/amanodt>, Thanks for reviewing the outputs and for flagging this. You’re absolutely right — the earlier results were affected by the forest mask definition, which included plantation classes and therefore inflated connectivity metrics over plantation areas. This has now been corrected. The pipeline has been updated to explicitly distinguish natural forest from plantations, and structural connectivity is computed only on natural forest classes, with plantation classes excluded by design. Methodology summary: Data: CoRE Stack LULC (Sentinel-2–derived), standardized to 30 m Approach: Euclidean distance–based Morphological Spatial Pattern Analysis (MSPA) Forest definition: Included: natural forest classes (e.g., deciduous / evergreen as per LULC schema) Excluded: plantation classes (explicitly filtered) Connectivity thresholds: Fragmented: < 100 m from non-forest edge Edge: 100–300 m Core: > 300 m from non-forest edge I’m currently re-running the analysis with this corrected forest definition and will share the updated, plantation-free outputs on the issue once ready. Thanks again for pointing this out — it helped tighten the semantic correctness of the pipeline. — Dipak — Reply to this email directly, view it on GitHub <#228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPT2H6ZIMLTBQKQRGEDBX4T4FUVJ7AVCNFSM6AAAAACG3DASUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJZGYYDCMRYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>