Almost every satellite based forestry analysis rests on spectral indices, including NDVI, EVI, SAVI, and dozens more. Very few teams implement them from scratch, and they should not, because the formulas are standardised, catalogued, and maintained by an open source community that has done the work properly.
Credit Where It Belongs
The catalogue most of this ecosystem draws on is Awesome Spectral Indices, a curated, machine-readable list of remote sensing index definitions. The Python packages eemont and ee_extra, created by David Montero Loaiza and contributors, bring that catalogue into the Google Earth Engine Python API with a clean interface.
TREEO did not build any of that. Our pipeline uses it, and this article exists partly to say so plainly, because a stack that quietly presents other people's open-source work as its own is exactly the kind of overclaiming that erodes trust in this industry.
| Component | Who maintains it | What it provides |
|---|---|---|
| Awesome Spectral Indices | Open-source community | Standardised index definitions and formulas |
| eemont / ee_extra | David Montero Loaiza and contributors | Earth Engine Python integration |
| eemont-osi | TREEO fork | Pinned compatibility for our pipeline |
| forestry_carbon_arr utils | TREEO | Band-name adaptation layer |
What a Fork Is For
`eemont-osi` is a fork, not a rewrite. Forks exist for unglamorous reasons: pinning a version, keeping an interface stable while upstream evolves, or adapting naming so a downstream pipeline does not break.
That is the honest description. The index science is upstream; the fork keeps our side stable.
The Band-Name Problem
The one genuine piece of integration work is mundane and worth explaining, because anyone building a similar pipeline hits it.
Index formulas are published using standard band abbreviations, `N` for near-infrared, `R` for red, `S1` for shortwave infrared. A pipeline working across Planet, Sentinel-2 and Landsat imagery usually has its own internal band naming. The two have to be reconciled before a formula can be evaluated.
Formula from the catalogue: (N - R)/(N + R)
Mapped to pipeline bands: (nir - red)/(nir + red)
N → nir R → red G → green B → blue
S1 → swir1 S2 → swir2 RE1-4 → redE1-4
Coefficients (C1, C2, L, g) pass through unchanged.That translation is what our adapter does. It is a hundred lines of mapping, and it is the difference between a catalogue of formulas and a pipeline that can run them across multiple satellite sources.
Why This Matters Methodologically
Using a shared, public index catalogue rather than hand-implemented formulas has a direct benefit at verification: the definition of every index is citable and identical to what everyone else uses.
A verifier asking "how did you calculate EVI?" gets a reference to a published definition rather than a screenshot of a formula bar. That is the same reproducibility argument that applies to sampling design and allometric equations, the method should be checkable by someone who was not there.
Sources
1. Awesome Spectral Indices — https://awesome-ee-spectral-indices.readthedocs.io/
2. eemont, by David Montero Loaiza and contributors — https://github.com/davemlz/eemont
3. ee_extra — https://github.com/r-earthengine/ee_extra
4. eemont-osi (TREEO fork) — https://github.com/miqbalf/eemont-osi
5. forestry_carbon_arr — https://github.com/miqbalf/forestry_carbon_arr
eemont and ee_extra are the work of their upstream authors and contributors. TREEO's contribution is the pipeline integration described above.
Turn climate goals into a verified portfolio
TREEO connects the full carbon cycle, encompassing eligibility, simulation, real time monitoring, and registry ready reporting, while combining expert consulting with dMRV technology so the evidence exists before anyone asks for it.
