OSGeo - User contributions [en]

TorchGeo embeddings

2026-05-03T17:41:19Z

Darkblueb: Created page with "Notes on '''EARTH EMBEDDINGS AS PRODUCTS: TAXONOMY, ECOSYSTEM, AND STANDARDIZED ACCESS''' <pre> Heng Fang† ∗ Adam J Stewart‡ ∗ Isaac Corley§ * Xiao Xiang Zhu *..."

Notes on
'''EARTH EMBEDDINGS AS PRODUCTS: TAXONOMY, ECOSYSTEM, AND STANDARDIZED ACCESS'''
<pre>
Heng Fang† ∗ Adam J Stewart‡ ∗ Isaac Corley§ * Xiao Xiang Zhu * Hossein Azizpour†
† KTH Royal Institute of Technology, Stockholm, Sweden
‡ Chair of Data Science in Earth Observation, Technical University of Munich, Munich, Germany
§ Wherobots, San Antonio, USA
</pre>
arXiv:2601.13134v1 19 Jan 2026 [LINK](https://arxiv.org/abs/2601.13134)

Introduction

• A comprehensive survey that organizes existing geospatial embedding products into a structured taxonomy and provides a detailed metadata atlas (resolution, license, etc.).
• Unified Integration: implements standardized data loaders for these embeddings in [TorchGeo](https://www.osgeo.org/projects/torchgeo/)

An overview landscape is proposed : a) Analysis Frameworks & Tools; b) Embeddings data artifacts; c) charting downstream application value, specifically mapping tasks and retrieval tasks. Embeddings are differentiated as either location-typed, patch-typed or pixel-typed. Details of existing products are shown.

🌍 1. Foundation Models for Earth Observation (EO)

These are the leading projects that aim to build general-purpose models capable of representing Earth from
satellite imagery and other geospatial modalities.

🔧 Projects:
- Clay Foundation Model – [Hugging Face](https://huggingface.co/made-with-clay/Clay) 2024
*A multimodal foundation model for Earth using diverse data sources.*

- Major TOM – [AFrancis IGARSS 2024](https://huggingface.co/Major-TOM)
*Expandable datasets and models for global EO coverage.*

- Earth Index Embeddings – [Earth Genome](https://www.earthgenome.org/earth-index), 2025
*A large-scale embedding system built from Earth observation data.*

- Copernicus-Embed – [Zhu et al., AI4Copernicus Project](https://github.com/zhu-xlab/Copernicus-FM)
*Foundation model leveraging Copernicus Sentinel data.*

- Presto Embeddings – [NASA Harvest](https://nasaharvest.github.io/presto-embeddings/)
*Embedding framework for satellite time series and land use analysis.*

- Tessera Embeddings – [GeoTessera Docs](https://geotessera.readthedocs.io/en/latest/) [REPO](https://github.com/ucam-eo/tessera)
*pixel-based Temporal spectral embeddings for Earth representation.*

- Google Satellite Embedding (AlphaEarth) – [Google Earth
Engine](https://developers.google.com/earth-engine/datasets/catalog/GOOGLE_SATELLITE_EMBEDDING_V1_ANNUAL)
*An early-stage embedding model using Google's global satellite data.*

- OlmoEarth – [AllenAI, 2025](https://allenai.org/olmoearth)
*Latent image modeling approach for multimodal Earth observation.*

📚 Key Papers:
- XXZhu 2025 [LINK](https://www.nature.com/articles/s43247-025-03127-x) – “On the Foundations of Earth Foundation Models”
- CFBrown 2025 [LINK](https://arxiv.org/abs/2507.22291) – “AlphaEarth Foundations”
- KKlemmer 2023 [LINK](https://arxiv.org/abs/2311.17179) – “SatCLIP: Global Location Embeddings with Satellite Imagery”

---

📦 2. **Datasets**

Large-scale, open-access datasets play a central role in training and evaluating Earth foundation models.

🗃 Datasets:
- EuroSAT – [Zenodo](https://zenodo.org/records/7711810)
*Land use classification dataset using Sentinel-2 satellite data.*

- EuroCrops – [PMC 10495462](https://pmc.ncbi.nlm.nih.gov/articles/PMC10495462/)
*Crop type mapping dataset for Europe.*

- National Land Cover Database (NLCD) – Photogrammetric Engineering & Remote Sensing 2001 [LINK](https://www.ingentaconnect.com/content/asprs/pers/2004/00000070/00000007/art00005;jsessionid=2awgc0agiboi4.x-ic-live-02)
*USA land cover classes*

- SSL4EO-S12 – IEEE Geoscience and Remote Sensing 2023 [LINK](https://github.com/zhu-xlab/SSL4EO-S12)
*Multimodal, multitemporal dataset for self-supervised learning.*

- Copernicus-Pretrain – [IEEE Geoscience and Remote Sensing 2023](https://github.com/zhu-xlab/Copernicus-FM)
*an extension of the SSL4EO-S12 dataset to all major Sentinel missions (S1-S5P)*

---

🧠 3. **Models & Methods**

These include both classical and cutting-edge machine learning approaches used in building Earth foundation
models.

⚙ Core Methods:
- SatCLIP** – AAAI 2025 etc [LINK](https://arxiv.org/abs/2311.17179)
*Vision-language model for global location representations.*

- MMEarth** – [EU/CV 2024](https://arxiv.org/abs/2405.02771)
*Multimodal pretext tasks for geospatial representation learning.*

- ResNet** – [KHe IEEE/CV 2016](https://viso.ai/deep-learning/resnet-residual-neural-network/)
*Baseline CNN architecture widely used in EO.*

- ConvNeXt V2** – [Woo et al., IEEE/CVF 2023](https://github.com/facebookresearch/ConvNeXt-V2)
*Efficient ConvNet architecture using masked autoencoders (MAE).*

- DINO, DINOv2, DINOv3** – INRIA 2021–2023, META [LINK](https://dinov3.org/)
*Vision transformers with self-supervised learning capabilities.*

- MAE (Masked Autoencoders)** – IEEE/CVF 2021 [LINK](https://arxiv.org/abs/2111.06377)
*Self-supervised learning for vision transformers.*

🧬 Distillation & Advanced Approaches:
- **Distillation methods** – Transfer knowledge from large models.
- **Neural plasticity-inspired models** – [ZXiong, arXiv 2024]
*Inspired by biological learning mechanisms.*
- **Multi-label guided soft contrastive learning** – [YWang, IEEE TGRS, 2024]
- **Barlow Twins** – [Zbontar et al., arXiv 2021]
*Method for learning representations without contrastive loss.*
- **Continual Barlow Twins** – [IEEE JSTARS, 2023]
*Extends Barlow Twins to continual learning in EO segmentation.*

---

🛠 4. **Tools & Benchmarks**

These are software systems and frameworks that support development, evaluation, or deployment of EO AI
models.

🧰 Tools:
- TorchGeo** – [AJStewart ACM 2025](https://www.osgeo.org/projects/torchgeo/)
*PyTorch library for geospatial deep learning.*

- NeuCo-Bench** – [RVinge, arXiv 2025](https://arxiv.org/html/2510.17914v1)
*Benchmarking framework for neural embeddings in Earth observation.*

- GeoINRID** – [GitHub: arjunarao619/GeoINRID](https://github.com/arjunarao619/GeoINRID)
*Geospatial inference and representation learning toolkit.*

🏆 Challenges:
- **Embed2Scale Challenge** – [CVPR CAlbrecht 2025](https://research.ibm.com/publications/the-2025-cvpr-earthvision-data-challenge-by-embed2scale)
*Large-scale Earth vision challenge focused on scale-aware embeddings.*

- TerraMind Blue-Sky Challenge** – [JJakubik, arXiv 2025]
*Generative modeling for Earth observation.*

---

🧭 5. **Key Themes & Trends**

1. Foundation Models**: TorchGeo now includes data loaders designed for search/retrieval (Clay, Major TOM, Earth
Index), and for dense prediction tasks like land cover mapping (Copernicus, Presto, Tessera, Google). TorchGeo allows us to enable fair, side-by-side benchmarking of different embedding models on the same downstream tasks, forming the basis for future experiments. Projects are encouraged to strengthen and improve explainability.

1.1 Major TOM Notes** Major TOM embeddings are not (yet) really product-oriented and are aimed with a similar purpose to the MT Core datasets - to make it easier to experiment and benchmark model outputs (hence, unlike TESSERA and AEF which came a few months after, MT embeddings do not have consistent or aggregated temporal scope). We haven't had enough time to finish off the preprint, but my current plan is to provide a simple MT Embedding benchmark at this year's EGU and integrate that into the arxiv pre-print. --Miko

1.2 Earth Index / Earth Genome** Use the Earth Index application (earthindex.ai) for non-technical users to use the embeddings we published on source.coop. Users of the web app (non-technical journalists, indigenous communities/allies, NGOs) have been our main focus. Users of the source.coop embeddings have generally been more technical folks interested in exploring/innovating in what's possible --BenStrong

1.3 Clay** Clay and Presto offer documented tutorials on generating new embeddings with their models. In CLAY, the encoder receives unmasked patches, latitude-longitude data, and timestep information. Notably, the last 2 embeddings from the encoder specifically represent the latitude-longitude and timestep embeddings.

2. Self-Supervised Learning (SSL)**:

3. Multimodal Integration**:

4. Open Data & Tools**: Open-source projects (e.g., TorchGeo, Copernicus-Embed) and public datasets
(EuroSAT, EuroCrops) are crucial for reproducibility and democratization of EO AI. Projects are encouraged to increase Input Data Diversity, and to adopt cloud-native data formats for geospatial data.

5. Benchmarking**: Projects are encouraged to standardize in benchmarking. Benchmarks including NeuCo-Bench and Embed2Scale.

---

📌 Research Directions

- Unified Earth Foundation Models**:
- Interpretability in EO AI**: Exploring how these embeddings can be interpreted by domain experts.
- Ethics and Bias**: Investigating fairness and bias in global EO models trained on unevenly distributed
data.
- Edge Deployment**: Making these large foundation models deployable on resource-constrained platforms
(e.g., for field use).

[[Category:TorchGeo]]

File:Torchgeo logo 370x206.png

2026-04-21T15:48:44Z

Darkblueb: add Category

torchgeo

[[Category:TorchGeo]]

TorchGeo Code Provenance

2026-04-21T15:47:48Z

Darkblueb: add Cetegory tag

=Code Provenance Review Process=

TorchGeo project
'''refer : https://www.osgeo.org/about/committees/incubation/graduation/'''

'''Incubation application questionnaire : https://trac.osgeo.org/osgeo/wiki/TorchGeo'''

==Document Status==

{| class="wikitable"
|-
| '''Version:''' || 0.5
|-
| '''Status:''' || Updated
|-
| '''Last Edited:''' || 15 Jan 2026
|}

==Purpose==

Show to "reasonable comfort level" that TorchGeo
does not have improperly contributed code, and that the code is all under the Project license.

Notice: ''It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the OSGeo Incubation Committee to prove there are no problems. However, OSGeo Incubation Committee does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.''

=TorchGeo Provenance Review=

== Project History ==

TorchGeo started as an internship project at Microsoft's AI for Good Lab in 2021, with continued support and funding from the University of Illinois Urbana-Champaign and the National Center for Supercomputing Applications. Since then, TorchGeo has been adopted by a diverse community of researchers from academia, industry, and government research institutions who have contributed to the success of the library. In 2025, we founded a new TorchGeo Organization to manage the TorchGeo Project, with the support of members from the above organizations.

'''Key milestones''':

- '''2021-05-11''': Initial commit (2330aad) by Adam J. Stewart

- '''2021-2024''': Organic growth to 120+ contributors

- '''2025''': Formation of TorchGeo Organization with formal governance structure

- '''2026''': OSGeo incubation application submitted

==Libraries==

All dependencies are external (not bundled in source tree). All licenses are OSI-approved and compatible with MIT.

{| class="wikitable" border="1"
|-
! Library !! License !! Compatible? !! In Core? !! Issues? !! Ok? !! Comments
|-
| einops || MIT || Yes || External || - || Yes || Tensor operations
|-
| geopandas || BSD-3-Clause || Yes || External || - || Yes || Geospatial dataframes
|-
| jsonargparse || MIT || Yes || External || - || Yes || CLI argument parsing
|-
| lightly || MIT || Yes || External || - || Yes || Self-supervised learning
|-
| lightning || Apache-2.0 || Yes || External || - || Yes || Training framework
|-
| matplotlib || PSF || Yes || External || - || Yes || Plotting
|-
| numpy || BSD-3-Clause || Yes || External || - || Yes || Numerical computing
|-
| pandas || BSD-3-Clause || Yes || External || - || Yes || Data manipulation
|-
| pillow || HPND [https://github.com/python-pillow/Pillow/issues/1507 *] / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || External || - || Yes || Image I/O
|-
| pyproj || MIT || Yes || External || - || Yes || Cartographic projections
|-
| rasterio || BSD-3-Clause || Yes || External || - || Yes || Geospatial raster I/O
|-
| segmentation-models-pytorch || MIT || Yes || External || - || Yes || Segmentation architectures
|-
| shapely || BSD-3-Clause || Yes || External || - || Yes || Geometric operations
|-
| timm || Apache-2.0 || Yes || External || - || Yes || Vision model zoo
|-
| torch || BSD-3-Clause || Yes || External || - || Yes || PyTorch core
|-
| torchmetrics || Apache-2.0 || Yes || External || - || Yes || Metrics computation
|-
| torchvision || BSD-3-Clause || Yes || External || - || Yes || Vision utilities
|-
| *kornia || Apache-2.0 || Yes || External || - || Yes || Computer vision ops
|}

==Copyright Holders==
{| class="wikitable" border="1"
|-
! Copyright Holder !! Contact !! Issues !! Comments
|-
| TorchGeo Contributors || N/A (collective) || None || Per LICENSE file
|}

The MIT License file states: "Copyright (c) TorchGeo Contributors."

This is a collective copyright model - individual contributors retain copyright but license under MIT. Historical other markings include:

<pre>
> git gr Copyright | grep -v TorchGeo
torchgeo/models/convlstm.py:# Copyright (c) 2017 Andrea Palazzi
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Copyright (c) Microsoft Corporation.
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/ltae.py:# Copyright (c) 2020 VSainteuf (Vivien Sainte Fare Garnot)
</pre>

== Committers ==
'''Total human contributors:''' 122

'''Total commits:''' 2778 (excluding bots)

'''Top contributors''' (TSC members marked with *):

{| class="wikitable" border="1"
|-
! Committer !! Email !! Affiliation
|-
| Adam J. Stewart * || ajstewart426@gmail.com || TUM / UIUC
|-
| Caleb Robinson * || calebrob6@gmail.com || AI for Good Msft
|-
| Isaac Corley * || isaac.corley@proton.me || Wherobots
|-
| Nils Lehmann * || nils.lehmann24@gmail.com || TUM
|-
| Ashwin Nair * || ashnair0007@gmail.com || Space42
|-
| Anthony Ortiz * || Anthony.Ortiz@microsoft.com || Microsoft
|-
| Robin Cole || robmarkcole@gmail.com || EarthDaily
|-
| Yi Wang || wangyi111@users.noreply.github.com || TUM
|-
| Yi-Chia Chang || yichiac@users.noreply.github.com || UIUC
|-
| Burak Ekim || burakekim@users.noreply.github.com || Bundeswehr Munich
|-
| Blaz Rolih || blaz-r@users.noreply.github.com || ULjubljana, Slovenia
|-
| Maciej Kilian || iejMac@users.noreply.github.com || Stability AI
|-
| Qiusheng Wu || giswqs@gmail.com || UTenn Knoxville
|}

'''Note:''' 122 total contributors. Full list available via <code>git shortlog -sne --all</code>.

==Source Files==
'''Total Python files:''' 557

'''Files with copyright header:''' 557 (100%) - ''after PR #3262 merged''

'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.

{| class="wikitable" border="1"
|-
! File !! License !! Copyright Holder !! Header? !! Issues? !! Ok? !! Comments
|-
| docs/user/metrics/update_timeline.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|-
| tests/data/landcoverai/split.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|}

'''Note:''' PR https://github.com/torchgeo/torchgeo/pull/3262 adds copyright headers to the 2 files that were missing them.

==Further Issues ==
'''Resolved:'''
* Copyright headers added to 2 missing files via PR #3262: https://github.com/torchgeo/torchgeo/pull/3262

* OSGeo does not require a CLA. We ask projects to think about what they want during incubation.

* Contributor agreement confirmed

'''Pending:'''

== TorchGeo Application Questionnaire ==
See the main application questionnaire for additional project details:
https://trac.osgeo.org/osgeo/wiki/TorchGeo

==Process==

'''This Code Provenance Review followed the OSGeo Incubation process:'''
{| class="wikitable"
|-
! Step !! Status !! Date !! Notes
|-
| 1. Create Provenance Review Document || Complete || 06 Jan 2026 || Document created from [https://wiki.osgeo.org/wiki/Provenance_Review_Template Provenance Review Template]
|-
| 2. Library/Component Review || Complete || 08 Jan 2026 || 18 dependencies reviewed, no issues found
|-
| 3. Code Copyright Review || Complete || 08 Jan 2026 || 557 files reviewed, no issues found
|-
| 4. Submit to Project Mentor || Complete || 08 Jan 2026 || Brian M Hamlin (Mentor)
|}
=== Review Summary ===
{| class="wikitable"
|-
| '''Components in source tree:''' || None (all external dependencies)
|-
| '''Problematic licenses:''' || None identified
|-
| '''License conflicts:''' || None identified
|-
| '''Files reviewed:''' || 557 Python files
|-
| '''Files with headers:''' || 557 (100%)
|-
| '''External code derivations:''' || 2 files (both MIT licensed, properly attributed)
|-
| '''Copyright model:''' || Collective ("TorchGeo Contributors")
|}
=== Outstanding Items ===
* '''Pending merge:''' [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262] - adds copyright headers to 2 files
* '''Resolved:''' CLA/DCO status confirmation. OSGeo does not require a CLA. OSGeo asks projects to think about what they want during incubation.
''ajstewart'' -- We used to have a CLA when we were under MSFT. We no longer have any CLA or DCO. We currently have no plans to add one. I know the Linux Foundation requires DCO. Does OSGeo have any requirements?
* '''Resolved:''' a TSC Members Agreement is not required by OSGeo

=== Conclusion ===
'''The TorchGeo codebase passes the Code Provenance Review''' with no blocking issues identified. The project demonstrates good license hygiene and is ready for OSGeo incubation from a code provenance perspective.

==Library/Component Review Process==

'''Review completed:''' 08 Jan 2026
=== 1. Components in Source Tree ===
'''Finding:''' '''None'''
TorchGeo does '''not''' bundle any third-party libraries in its source tree. Unlike projects like GDAL (which includes copies of libtiff, libjpeg, etc.), TorchGeo treats all dependencies as external packages installed via pip/conda.
* No <code>vendor/</code> directory
* No <code>third_party/</code> directory
* No <code>external/</code> directory
* No embedded library copies
This is the recommended approach and simplifies license management.
=== 2. External Dependencies ===
'''Total required dependencies:''' 18
'''All licenses are OSI-approved and compatible with MIT.'''
{| class="wikitable"
|-
! Package !! License !! Compatible? !! Potentially Problematic?
|-
| einops || MIT || Yes || No
|-
| geopandas || BSD-3-Clause || Yes || No
|-
| jsonargparse || MIT || Yes || No
|-
| kornia || Apache-2.0 || Yes || No
|-
| lightly || MIT || Yes || No
|-
| lightning || Apache-2.0 || Yes || No
|-
| matplotlib || PSF (BSD-style) || Yes || No
|-
| numpy || BSD-3-Clause || Yes || No
|-
| pandas || BSD-3-Clause || Yes || No
|-
| pillow || HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || No
|-
| pyproj || MIT || Yes || No
|-
| rasterio || BSD-3-Clause || Yes || No
|-
| segmentation-models-pytorch || MIT || Yes || No
|-
| shapely || BSD-3-Clause || Yes || No
|-
| timm || Apache-2.0 || Yes || No
|-
| torch || BSD-3-Clause || Yes || No
|-
| torchmetrics || Apache-2.0 || Yes || No
|-
| torchvision || BSD-3-Clause || Yes || No
|}

=== 3. License Distribution ===
{| class="wikitable"
|-
! License Type !! Count !! Notes
|-
| MIT || 6 || Permissive, fully compatible
|-
| BSD-3-Clause || 7 || Permissive, fully compatible
|-
| Apache-2.0 || 4 || Permissive, fully compatible
|-
| PSF || 1 || Python Software Foundation, BSD-style
|-
| HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || 1 || Historical Permission Notice and Disclaimer, permissive
|}

=== 4. Potentially Problematic Licenses ===
'''Finding:''' '''None identified'''
* No GPL or LGPL dependencies (no copyleft)
* No AGPL dependencies
* No proprietary or non-free dependencies
* No "viral" license concerns
=== 5. License Conflicts ===
'''Finding:''' '''None identified'''
All dependency licenses are permissive and compatible with each other and with TorchGeo's MIT license. There are no conflicts analogous to GDAL's use of GPL'ed GRASS libraries.
=== 6. Optional Dependencies ===
TorchGeo has optional dependencies for the <code>datasets</code> extra. All use permissive licenses:
{| class="wikitable"
|-
! Package !! License
|-
| h5py || BSD-3-Clause
|-
| laspy || BSD-2-Clause
|-
| netcdf4 || MIT
|-
| opencv-python || Apache-2.0
|-
| pycocotools || BSD-2-Clause
|-
| rioxarray || Apache-2.0
|-
| scikit-image || BSD-3-Clause
|-
| scipy || BSD-3-Clause
|-
| xarray || Apache-2.0
|}
=== 7. Conclusion ===
'''Overall assessment:''' No library/component issues identified
* No bundled code in source tree
* All 18 required dependencies use permissive OSI-approved licenses
* No GPL/copyleft dependencies
* No license conflicts
* Clean dependency model suitable for OSGeo incubation

== Code Copyright Review ==
'''Review completed:''' 08 Jan 2026
'''Reviewer:''' Brian M Hamlin (Mentor), with assistance from automated tooling
'''Scope:''' All 557 Python source files in the TorchGeo repository
=== 1. License Headers ===
{| class="wikitable"
|-
| '''Total Python files:''' || 557
|-
| '''Files with standard header:''' || 557 (100%)
|-
| '''Files missing header:''' || 0 (after [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262])
|}
'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.
'''Finding:''' All source files include the standard license header. Two utility scripts (<code>docs/user/metrics/update_timeline.py</code> and <code>tests/data/landcoverai/split.py</code>) were identified as missing headers during this review and fixed via [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262].
=== 2. License Consistency ===
'''Finding:''' All files are under the '''MIT License'''. No files use a different or conflicting license.
* No GPL, LGPL, or copyleft licenses found
* No Apache-only or BSD-only files found
* All code consistently uses MIT
=== 3. Code Origins ===
Two files contain code derived from external sources. Both are properly attributed and both original sources use MIT License (compatible):
{| class="wikitable"
|-
! File !! Source !! Source License !! Compatible? !! Attribution in File?
|-
| <code>torchgeo/models/btc.py</code> || [https://github.com/blaz-r/BTC-change-detection blaz-r/BTC-change-detection] || MIT || Yes || Yes
|-
| <code>torchgeo/models/croma.py</code> || [https://github.com/antofuller/CROMA antofuller/CROMA] || MIT || Yes || Yes
|}
'''Finding:''' Both external code sources are MIT licensed, which is fully compatible with TorchGeo's MIT license. Attribution is properly documented in the source file headers.
=== 4. Vendored/Bundled Code ===
'''Finding:''' No vendored or bundled third-party code exists in the source tree. All dependencies are external and installed via pip/conda.
* No <code>vendor/</code>, <code>third_party/</code>, or <code>external/</code> directories
* No embedded copies of libraries (unlike GDAL which bundles libtiff, libjpeg, etc.)
* All 18 dependencies are fetched externally at install time
=== 5. Copyright Holders ===
{| class="wikitable"
|-
! Copyright Holder !! Type !! Notes
|-
| TorchGeo Contributors || Collective || Single copyright holder for all files
|}
'''Finding:''' The project uses a '''collective copyright model'''. All files use "Copyright (c) TorchGeo Contributors" rather than individual contributor names.
'''Implications for relicensing:'''
* Simplified model - no need to contact 122 individual contributors
* Contributors implicitly agree to collective copyright by submitting PRs
* '''Resolved:''' Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) satisfactory and/or not required for incubation.

=== 6. Outstanding Issues ===
'''Resolved:'''
* Copyright headers added to 2 missing files: [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262]
* Confirm whether a CLA/DCO is in place or planned
* Contributor agreement status for TSC members

'''Pending:'''

=== 7. Conclusion ===
'''Overall assessment:''' No provenance issues identified.
The TorchGeo codebase demonstrates good copyright hygiene:
* 100% of source files have proper license headers
* All code is consistently MIT licensed
* External code derivations are properly attributed and license-compatible
* No vendored code complicates the license picture
* Collective copyright model simplifies governance
The codebase is ready for OSGeo incubation from a code provenance perspective, pending confirmation of contributor agreement procedures from the TSC.

[[Category:TorchGeo]]

TorchGeo DOFA

2026-04-21T14:39:16Z

Darkblueb: add Category

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN][https://arxiv.org/pdf/2512.05025 pdf] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

{| class="wikitable"
|+ Overview
|-
! Topic
! DOFA
! RAMEN
! Notes
|-
| Design Philosophy
| Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
| Modular approach with explicit resolution parameterization and multi-resolution support
|
|-
| Flexibility Mechanism
| Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
| Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions
|
|-
| Adaptation Strategy
| Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
| Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference
|
|-
| Training Approach
| Wavelength-conditioned dynamic hypernetwork
| Masked autoencoding with random resolution selection
|
|-
| Code Implementation
| More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
| Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.
|
|-
| Resolution Handling
| No explicit resolution handling; adapts through channel count flexibility
| Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters,
and resolution-aware positional embeddings
|
|-
| Architecture Modularity
| Unified architecture with dynamic MLP layers for adaptability
| Separate encoder/decoder components with clear division of labor
|
|-
| Training Flexibility
| Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
| Resolution varies during training (random selection), explicit feature map control
|
|-
| Data Handling
| Simpler data handling focused on channel count variations
| Complex <code>MultiDataset</code> with time-series handling for different modalities
|
|-
| Input Handling
| Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR:
2 channels, S2: 9 channels, RGB: 3 channels)
| Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input
requirements
|
|-
| Training Approach
| Pre-trained using five different data modalities in remote sensing
| Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)
|
|-
| Evaluation Focus
| Demonstrates capability across various tasks but doesn't emphasize resolution control
| Explicitly emphasizes adjustable feature map resolution as a key contribution
|}

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== Encoder Architectures ===

==== DOFA: Neuroplasticity-Inspired Multi-Modal Encoder ====
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

==== RAMEN: Resolution-Adjustable Multi-Modal Encoder ====
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

[[Category:TorchGeo]]

Category:TorchGeo

2026-04-21T14:36:42Z

Darkblueb: new

notes

PROJ Report 2025

2026-02-27T05:36:46Z

Darkblueb: /* Milestones */

= General information =

* Project officer: Kristian Evers (kbevers)
* Project page information: https://github.com/OSGeo/PROJ

= Milestones =

The PROJ project had a productive year in 2025

'''Version 9.6 Series:'''
* '''9.6.0 (March 15, 2025):'''
* Improved `projinfo` display for time-dependent operations.
* Added CMake options for embedding resources (`EMBED_RESOURCE_FILES`, `USE_ONLY_EMBEDDED_RESOURCE_FILES`).
* Enhanced database ingestion for deprecated ESRI names.
* Improved `proj_factors()` speed for repeated calls.
* Added the Airocean (formerly Dymaxion) projection.
* Optimized `createOperations()` for CRS lookups.
* Added explicit type members to PROJJSON exports for Projected CRSs.
* Improved handling of CompoundCRS transformations.
* Mapped EPSG methods to PROJ equivalents.
* Added support for Coordinate Frame rotation methods.
* Added CMake option for embedding .tif/.json files.
* Incorporated new EPSG methods for TIN interpolation.
* Added native CA configuration option.
* Enhanced the concatenated operation step table in the database.
* Updated ETRF and WGS 84 records in the database.
* Updated to C++17.
* Added bash completion script for `projinfo`.
* Refactored 4D API code.
* Added `proj_trans_bounds_3D()`.
* Added engineering datum and CRS tables to the database.
* Added support for EUREF-FIN transformations.
* Added the Spilhaus projection.
* Exported ESRI:54099 as PROJ string.
* Updated the EPSG database to version 12.004.
* Improved cache invalidation for downloaded files.
* '''9.6.1 (June 2, 2025):''' Focused on bug fixes and minor improvements:
* Addressed issues with ConcaveHullOfPolygons, RelateNG, and LineString handling.
* Added missing includes and fixed build issues.
* Improved error handling in WKT parsing.
* Fixed issues with NAD83 transformations.
* Fixed memory leaks and other bugs.
* Updated EPSG database to version 12.012.
* '''9.6.2 (June 6, 2025):''' Primarily focused on bug fixes and database updates:
* Updated EPSG to version 12.013.
* Addressed issues with ESRI deprecated records and D_Unknown_based_on_WGS_84_ellipsoid datums.
* Improved `proj_trans_bounds()` for world-wide coverage.

'''Version 9.7 Series:'''
* '''9.7.0 (September 15, 2025):''' Introduced major new features and improvements:
* Implemented 'exact' authalic latitude conversions.
* Implemented uniform conversions between auxiliary latitudes.
* Improved WKT2 parser.
* Updated the EPSG database to version 12.022.
* Enabled compiler warnings for improved code quality.
* Improved Geostationary projection performance.
* Improved WKT importer error messages.
* Added `proj_geod_direct` for PJ transformations.
* Supported exporting Mercator (Spherical) as Mercator_1SP in WKT1.
* Addressed various bug fixes related to transformations, memory management, and data handling.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and releases within the version 9.7 series.
* Addressing feedback and bug fixes for the ongoing version 9.7 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

PROJ Report 2025

2026-02-27T05:36:13Z

Darkblueb: /* General information */

= General information =

* Project officer: Kristian Evers (kbevers)
* Project page information: https://github.com/OSGeo/PROJ

= Milestones =

The PROJ project had a productive year in 2025

'''Version 9.6 Series:'''
* '''9.6.0 (March 15, 2025):''' Introduced significant enhancements and new capabilities:
* Improved `projinfo` display for time-dependent operations.
* Added CMake options for embedding resources (`EMBED_RESOURCE_FILES`, `USE_ONLY_EMBEDDED_RESOURCE_FILES`).
* Enhanced database ingestion for deprecated ESRI names.
* Improved `proj_factors()` speed for repeated calls.
* Added the Airocean (formerly Dymaxion) projection.
* Optimized `createOperations()` for CRS lookups.
* Added explicit type members to PROJJSON exports for Projected CRSs.
* Improved handling of CompoundCRS transformations.
* Mapped EPSG methods to PROJ equivalents.
* Added support for Coordinate Frame rotation methods.
* Added CMake option for embedding .tif/.json files.
* Incorporated new EPSG methods for TIN interpolation.
* Added native CA configuration option.
* Enhanced the concatenated operation step table in the database.
* Updated ETRF and WGS 84 records in the database.
* Updated to C++17.
* Added bash completion script for `projinfo`.
* Refactored 4D API code.
* Added `proj_trans_bounds_3D()`.
* Added engineering datum and CRS tables to the database.
* Added support for EUREF-FIN transformations.
* Added the Spilhaus projection.
* Exported ESRI:54099 as PROJ string.
* Updated the EPSG database to version 12.004.
* Improved cache invalidation for downloaded files.
* '''9.6.1 (June 2, 2025):''' Focused on bug fixes and minor improvements:
* Addressed issues with ConcaveHullOfPolygons, RelateNG, and LineString handling.
* Added missing includes and fixed build issues.
* Improved error handling in WKT parsing.
* Fixed issues with NAD83 transformations.
* Fixed memory leaks and other bugs.
* Updated EPSG database to version 12.012.
* '''9.6.2 (June 6, 2025):''' Primarily focused on bug fixes and database updates:
* Updated EPSG to version 12.013.
* Addressed issues with ESRI deprecated records and D_Unknown_based_on_WGS_84_ellipsoid datums.
* Improved `proj_trans_bounds()` for world-wide coverage.

'''Version 9.7 Series:'''
* '''9.7.0 (September 15, 2025):''' Introduced major new features and improvements:
* Implemented 'exact' authalic latitude conversions.
* Implemented uniform conversions between auxiliary latitudes.
* Improved WKT2 parser.
* Updated the EPSG database to version 12.022.
* Enabled compiler warnings for improved code quality.
* Improved Geostationary projection performance.
* Improved WKT importer error messages.
* Added `proj_geod_direct` for PJ transformations.
* Supported exporting Mercator (Spherical) as Mercator_1SP in WKT1.
* Addressed various bug fixes related to transformations, memory management, and data handling.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and releases within the version 9.7 series.
* Addressing feedback and bug fixes for the ongoing version 9.7 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

PROJ Report 2025

2026-02-27T05:35:40Z

Darkblueb: /* General information */

= General information =

* Project officer: Kristian Evers (kbevers)
* Project page information: https://github.com/proj4/proj

= Milestones =

The PROJ project had a productive year in 2025

'''Version 9.6 Series:'''
* '''9.6.0 (March 15, 2025):''' Introduced significant enhancements and new capabilities:
* Improved `projinfo` display for time-dependent operations.
* Added CMake options for embedding resources (`EMBED_RESOURCE_FILES`, `USE_ONLY_EMBEDDED_RESOURCE_FILES`).
* Enhanced database ingestion for deprecated ESRI names.
* Improved `proj_factors()` speed for repeated calls.
* Added the Airocean (formerly Dymaxion) projection.
* Optimized `createOperations()` for CRS lookups.
* Added explicit type members to PROJJSON exports for Projected CRSs.
* Improved handling of CompoundCRS transformations.
* Mapped EPSG methods to PROJ equivalents.
* Added support for Coordinate Frame rotation methods.
* Added CMake option for embedding .tif/.json files.
* Incorporated new EPSG methods for TIN interpolation.
* Added native CA configuration option.
* Enhanced the concatenated operation step table in the database.
* Updated ETRF and WGS 84 records in the database.
* Updated to C++17.
* Added bash completion script for `projinfo`.
* Refactored 4D API code.
* Added `proj_trans_bounds_3D()`.
* Added engineering datum and CRS tables to the database.
* Added support for EUREF-FIN transformations.
* Added the Spilhaus projection.
* Exported ESRI:54099 as PROJ string.
* Updated the EPSG database to version 12.004.
* Improved cache invalidation for downloaded files.
* '''9.6.1 (June 2, 2025):''' Focused on bug fixes and minor improvements:
* Addressed issues with ConcaveHullOfPolygons, RelateNG, and LineString handling.
* Added missing includes and fixed build issues.
* Improved error handling in WKT parsing.
* Fixed issues with NAD83 transformations.
* Fixed memory leaks and other bugs.
* Updated EPSG database to version 12.012.
* '''9.6.2 (June 6, 2025):''' Primarily focused on bug fixes and database updates:
* Updated EPSG to version 12.013.
* Addressed issues with ESRI deprecated records and D_Unknown_based_on_WGS_84_ellipsoid datums.
* Improved `proj_trans_bounds()` for world-wide coverage.

'''Version 9.7 Series:'''
* '''9.7.0 (September 15, 2025):''' Introduced major new features and improvements:
* Implemented 'exact' authalic latitude conversions.
* Implemented uniform conversions between auxiliary latitudes.
* Improved WKT2 parser.
* Updated the EPSG database to version 12.022.
* Enabled compiler warnings for improved code quality.
* Improved Geostationary projection performance.
* Improved WKT importer error messages.
* Added `proj_geod_direct` for PJ transformations.
* Supported exporting Mercator (Spherical) as Mercator_1SP in WKT1.
* Addressed various bug fixes related to transformations, memory management, and data handling.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and releases within the version 9.7 series.
* Addressing feedback and bug fixes for the ongoing version 9.7 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

PROJ Report 2025

2026-02-27T05:34:55Z

Darkblueb: Created page with "= General information = * Project officer: (To be filled in - no project officer specified in input) * Project page information: https://github.com/proj4/proj = Milestones =..."

= General information =

* Project officer: (To be filled in - no project officer specified in input)
* Project page information: https://github.com/proj4/proj

= Milestones =

The PROJ project had a productive year in 2025

'''Version 9.6 Series:'''
* '''9.6.0 (March 15, 2025):''' Introduced significant enhancements and new capabilities:
* Improved `projinfo` display for time-dependent operations.
* Added CMake options for embedding resources (`EMBED_RESOURCE_FILES`, `USE_ONLY_EMBEDDED_RESOURCE_FILES`).
* Enhanced database ingestion for deprecated ESRI names.
* Improved `proj_factors()` speed for repeated calls.
* Added the Airocean (formerly Dymaxion) projection.
* Optimized `createOperations()` for CRS lookups.
* Added explicit type members to PROJJSON exports for Projected CRSs.
* Improved handling of CompoundCRS transformations.
* Mapped EPSG methods to PROJ equivalents.
* Added support for Coordinate Frame rotation methods.
* Added CMake option for embedding .tif/.json files.
* Incorporated new EPSG methods for TIN interpolation.
* Added native CA configuration option.
* Enhanced the concatenated operation step table in the database.
* Updated ETRF and WGS 84 records in the database.
* Updated to C++17.
* Added bash completion script for `projinfo`.
* Refactored 4D API code.
* Added `proj_trans_bounds_3D()`.
* Added engineering datum and CRS tables to the database.
* Added support for EUREF-FIN transformations.
* Added the Spilhaus projection.
* Exported ESRI:54099 as PROJ string.
* Updated the EPSG database to version 12.004.
* Improved cache invalidation for downloaded files.
* '''9.6.1 (June 2, 2025):''' Focused on bug fixes and minor improvements:
* Addressed issues with ConcaveHullOfPolygons, RelateNG, and LineString handling.
* Added missing includes and fixed build issues.
* Improved error handling in WKT parsing.
* Fixed issues with NAD83 transformations.
* Fixed memory leaks and other bugs.
* Updated EPSG database to version 12.012.
* '''9.6.2 (June 6, 2025):''' Primarily focused on bug fixes and database updates:
* Updated EPSG to version 12.013.
* Addressed issues with ESRI deprecated records and D_Unknown_based_on_WGS_84_ellipsoid datums.
* Improved `proj_trans_bounds()` for world-wide coverage.

'''Version 9.7 Series:'''
* '''9.7.0 (September 15, 2025):''' Introduced major new features and improvements:
* Implemented 'exact' authalic latitude conversions.
* Implemented uniform conversions between auxiliary latitudes.
* Improved WKT2 parser.
* Updated the EPSG database to version 12.022.
* Enabled compiler warnings for improved code quality.
* Improved Geostationary projection performance.
* Improved WKT importer error messages.
* Added `proj_geod_direct` for PJ transformations.
* Supported exporting Mercator (Spherical) as Mercator_1SP in WKT1.
* Addressed various bug fixes related to transformations, memory management, and data handling.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and releases within the version 9.7 series.
* Addressing feedback and bug fixes for the ongoing version 9.7 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

Marble Report 2025

2026-02-27T04:18:44Z

Darkblueb:

= General information =

* Project officer: Dennis Nienhüser (Earthwings)
* Project page information: https://apps.kde.org/marble/

= Key Accomplishments =

The KDE-Marble project released a dozen updates to the stable version 24 series, also the final iterations of version 23.

As of 2025, KDE Marble had not yet completed its official Qt6 port, but active development and a functional Qt6 branch were in progress. A community contributor successfully ported Marble to Qt6 in early 2023, with the work available in a public branch (''marble-qt6'') on KDE's Invent platform. Despite this, the official master branch of Marble still primarily relied on Qt5 throughout 2025.

'''Version 24 Development and Releases:''' (Throughout 2025)
* About 15 releases of version 24 were made throughout the year.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

https://github.com/sponsors/KDE
https://kde.org/community/donations/

= Outlook for 2026 =

* Continued development and releases within the version 24 series.
* Addressing feedback and bug fixes for the ongoing version 24 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

GEOS Report 2025

2026-02-27T01:51:16Z

Darkblueb: /* Milestones */

= General information =

* Project officer: Paul Ramsey (pramsey)
* Project page information: https://libgeos.org/

= Milestones =

In the spring of 2025, update releases for versions 3.9.x, 3.10.x, 3.11.x, 3.12.x, 3.13.x were made available. Version 3.14 was released in August of 2025, updated by 3.14.1 two months afterward.

'''Update Releases:''' (March 3, 2025)
* '''3.13.1 :''' Primarily focused on bug fixes, including improvements to
ConcaveHullOfPolygons, RelateNG, and LineString handling.
* '''3.12.3 :''' Addressed several crashes and stability issues, including fixes related to
TopologyPreservingSimplifier, Centroid calculations, and handling of NaN inputs.
* '''3.11.5 :''' Included fixes to the TopologyPreservingSimplifier and improvements to
ConcaveHullOfPolygons and handling of NaN values.
* '''3.10.7 :''' Focused on robustness improvements, particularly in Intersection calculations
using DoubleDouble computation, and fixes for various crash scenarios.
* '''3.9.6 :''' Bug fixes / improvements:
Intersection: change to using DoubleDouble computation to improve robustness (GH-937, Martin Davis)
Centroid: Fix crash on polygons with empty holes (GH-1075, Dan Baston)
GEOSRelatePatternMatch: Fix crash on invalid DE-9IM pattern (GH-1089, Dan Baston)

'''Version 3.14:'''

* '''3.14.0 (August 21, 2025):''' Introduced significant new features and changes:
* Added clustering functions to the C API.
* Ported LineDissolver and CoverageCleaner.
* Added GEOSGridIntersectionFractions to the C API.
* Added functions to interrupt processing in a specific thread/context.
* Added "geos-targets.cmake" to the build tree for easier integration with other software.
* Added GEOSCoordSeq_hasZ, GEOSCoordSeq_hasM, GEOSCoordSeq_createWithDimensions, GEOSCoordSeq_setM, and GEOSCoordSeq_getM functions.
* Added GEOSGeoJSONWriter_setOutputDimension and GEOSGeom_transformXYZ functions.
* Added GEOSisSimpleDetail function.

'''Breaking Changes:''' Required C++17, implemented stricter WKT parsing, and modified GEOSCoordSeq_setOrdinate behavior.
* '''3.14.1 (October 27, 2025):''' Focused on bug fixes and minor improvements:
* Fixed floating-point exception handling for geosop.
* Fixed undefined behavior in CoordinateSequence::closeRing.
* Fixed crashes in GridIntersection for certain polygons outside the grid extent.
* Fixed incorrect envelope calculation for arcs.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

[[Category:Annual Reports]]
[[Category: Reports 2025]]

GEOS Report 2025

2026-02-27T01:50:20Z

Darkblueb:

= General information =

* Project officer: Paul Ramsey (pramsey)
* Project page information: https://libgeos.org/

= Milestones =

In the spring of 2025, update releases for versions 3.9.x, 3.10.x, 3.11.x, 3.12.x, 3.13.x were made available. In August of 2025 3.14 was released, updated by 3.14.1 two months afterward.

'''Update Releases:''' (March 3, 2025)
* '''3.13.1 :''' Primarily focused on bug fixes, including improvements to
ConcaveHullOfPolygons, RelateNG, and LineString handling.
* '''3.12.3 :''' Addressed several crashes and stability issues, including fixes related to
TopologyPreservingSimplifier, Centroid calculations, and handling of NaN inputs.
* '''3.11.5 :''' Included fixes to the TopologyPreservingSimplifier and improvements to
ConcaveHullOfPolygons and handling of NaN values.
* '''3.10.7 :''' Focused on robustness improvements, particularly in Intersection calculations
using DoubleDouble computation, and fixes for various crash scenarios.
* '''3.9.6 :''' Bug fixes / improvements:
Intersection: change to using DoubleDouble computation to improve robustness (GH-937, Martin Davis)
Centroid: Fix crash on polygons with empty holes (GH-1075, Dan Baston)
GEOSRelatePatternMatch: Fix crash on invalid DE-9IM pattern (GH-1089, Dan Baston)

'''Version 3.14:'''

* '''3.14.0 (August 21, 2025):''' Introduced significant new features and changes:
* Added clustering functions to the C API.
* Ported LineDissolver and CoverageCleaner.
* Added GEOSGridIntersectionFractions to the C API.
* Added functions to interrupt processing in a specific thread/context.
* Added "geos-targets.cmake" to the build tree for easier integration with other software.
* Added GEOSCoordSeq_hasZ, GEOSCoordSeq_hasM, GEOSCoordSeq_createWithDimensions, GEOSCoordSeq_setM, and GEOSCoordSeq_getM functions.
* Added GEOSGeoJSONWriter_setOutputDimension and GEOSGeom_transformXYZ functions.
* Added GEOSisSimpleDetail function.

'''Breaking Changes:''' Required C++17, implemented stricter WKT parsing, and modified GEOSCoordSeq_setOrdinate behavior.
* '''3.14.1 (October 27, 2025):''' Focused on bug fixes and minor improvements:
* Fixed floating-point exception handling for geosop.
* Fixed undefined behavior in CoordinateSequence::closeRing.
* Fixed crashes in GridIntersection for certain polygons outside the grid extent.
* Fixed incorrect envelope calculation for arcs.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

[[Category:Annual Reports]]
[[Category: Reports 2025]]

GEOS Report 2025

2026-02-27T01:49:04Z

Darkblueb: Created page with "= General information = * Project officer: Paul Ramsey * Project page information: https://github.com/geosproject/geos = Key Accomplishments = In the spring of 2025, update..."

= General information =

* Project officer: Paul Ramsey
* Project page information: https://github.com/geosproject/geos

= Key Accomplishments =

In the spring of 2025, update releases for versions 3.9.x, 3.10.x, 3.11.x, 3.12.x, 3.13.x were made available. In August of 2025 3.14 was released, updated by 3.14.1 two months afterward.

'''Update Releases:''' (March 3, 2025)
* '''3.13.1 :''' Primarily focused on bug fixes, including improvements to
ConcaveHullOfPolygons, RelateNG, and LineString handling.
* '''3.12.3 :''' Addressed several crashes and stability issues, including fixes related to
TopologyPreservingSimplifier, Centroid calculations, and handling of NaN inputs.
* '''3.11.5 :''' Included fixes to the TopologyPreservingSimplifier and improvements to
ConcaveHullOfPolygons and handling of NaN values.
* '''3.10.7 :''' Focused on robustness improvements, particularly in Intersection calculations
using DoubleDouble computation, and fixes for various crash scenarios.
* '''3.9.6 :''' Bug fixes / improvements:
Intersection: change to using DoubleDouble computation to improve robustness (GH-937, Martin Davis)
Centroid: Fix crash on polygons with empty holes (GH-1075, Dan Baston)
GEOSRelatePatternMatch: Fix crash on invalid DE-9IM pattern (GH-1089, Dan Baston)

'''Version 3.14:'''

* '''3.14.0 (August 21, 2025):''' Introduced significant new features and changes:
* Added clustering functions to the C API.
* Ported LineDissolver and CoverageCleaner.
* Added GEOSGridIntersectionFractions to the C API.
* Added functions to interrupt processing in a specific thread/context.
* Added "geos-targets.cmake" to the build tree for easier integration with other software.
* Added GEOSCoordSeq_hasZ, GEOSCoordSeq_hasM, GEOSCoordSeq_createWithDimensions, GEOSCoordSeq_setM, and GEOSCoordSeq_getM functions.
* Added GEOSGeoJSONWriter_setOutputDimension and GEOSGeom_transformXYZ functions.
* Added GEOSisSimpleDetail function.

'''Breaking Changes:''' Required C++17, implemented stricter WKT parsing, and modified GEOSCoordSeq_setOrdinate behavior.
* '''3.14.1 (October 27, 2025):''' Focused on bug fixes and minor improvements:
* Fixed floating-point exception handling for geosop.
* Fixed undefined behavior in CoordinateSequence::closeRing.
* Fixed crashes in GridIntersection for certain polygons outside the grid extent.
* Fixed incorrect envelope calculation for arcs.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

[[Category:Annual Reports]]
[[Category: Reports 2025]]

Marble Report 2025

2026-02-27T00:34:37Z

Darkblueb: KDE-Marble from Github info using gemma3:12b locally and edits

= General information =

* Project officer: Dennis Nienhüser (Earthwings)
* Project page information: https://apps.kde.org/marble/

= Key Accomplishments =

The KDE-Marble project released a dozen updates to the stable version 24 series, also the final iterations of version 23. KDE has ported many applications to Qt6, including Marble versions.

'''Version 24 Development and Releases:''' (Throughout 2025)
* About 15 releases of version 24 were made throughout the year.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

https://github.com/sponsors/KDE
https://kde.org/community/donations/

= Outlook for 2026 =

* Continued development and releases within the version 24 series.
* Addressing feedback and bug fixes for the ongoing version 24 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

Marble Report 2025

2026-02-27T00:12:05Z

Darkblueb: Created page with "= General information = * Project officer: (To be filled in - no project officer specified in input) * Project page information: https://kde.org/applications/gnome-integratio..."

= General information =

* Project officer: (To be filled in - no project officer specified in input)
* Project page information: https://kde.org/applications/gnome-integration/marble/

= Key Accomplishments =

The KDE-Marble project in 2025 releases a dozen updates to the version 24 series, and the final iterations of version 23.

'''Version 23 Final Releases:''' (Early 2025)
* (Space for details of the final version 23 releases - e.g., 23.x.x, 23.y.y, 23.z.z)
* (Brief description of changes/fixes in these releases)

'''Version 24 Development and Releases:''' (Throughout 2025)
* Numerous releases of version 24 were made throughout the year.
* (Space for listing the major releases within version 24 - e.g., 24.1.0, 24.2.0, etc.)
* (Summarize key improvements and bug fixes across the version 24 releases. Focus on significant changes.)
* (Example: "Fixed a crash related to...")
* (Example: "Improved rendering of...")
* (Example: "Added support for...")

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and releases within the version 24 series.
* Addressing feedback and bug fixes for the ongoing version 24 releases.
* Potential exploration of new features and improvements.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

GeoNode Report 2025

2026-02-26T23:51:15Z

Darkblueb: geonode using gemma3:12B local on Github Release Notes

= General information =

* Project officer: Giovanni Allegri (giohappy)
* Project page information: https://www.osgeo.org/projects/geonode/

= Key Accomplishments =

The GeoNode project in 2025 focused on improvements to version 4 series and culminating in a major release of version 5.0.

'''Version 4.x Improvements:''' Numerous bug fixes and enhancements were implemented across the 4.x series:
* '''4.4.4 (December 4, 2025):''' Upgraded dependencies including Django 4.2.24, PostGIS 3.5, and Nginx
1.26.3. Security upgrades to base Docker image.
* '''4.4.3 (May 14, 2025):''' Fixed regression in 4.4.2 related to GetLegendGraphic requests and issues with remote WMS dataset stores. Upgraded to Django 4.2.17 and security upgrades to base Docker image.
* '''4.4.2 (March 17, 2025):''' Introduced improvements to the client interface, including:
* Info panel for datasets accessible from the map's table of contents.
* Backport of MapStore WMS adaptive legends.
* Improved Entra ID configurations.
* Recaptcha support for Sign-In Form.
* Improved handling of 3D Tiles index file names.
* Improved handling of remote service URLs.
* Allow editing Documents advertised flag in the Django admin.
* Other fixes included improvements to 3DTiles asset downloads, metadata parser handling, custom map layer settings, and Geoserver layer styling. Bumped geoserver-restoconfig to 2.0.13.

* '''Version 5.0 Release (December 16, 2025):''' A major release introducing significant architectural changes and new features.
'''Redesigned Layout:''' A completely redesigned user interface focused on usability, clarity, and customization.
'''Rewritten Metadata Engine and Editor:''' A new, configurable metadata framework based on JSON Schemas, allowing for full customization of metadata schemas and validation rules. Supports standards like INSPIRE (RNDT).
'''Dataset Replacement and Update:''' Reintroduced the ability to replace datasets with newer versions, including an experimental "Update" mode for vector datasets.
'''Validation and Constraints:''' Integration of GeoServer constraints for dataset fields, enabling validation during updates and creation.
'''Dynamic Rule-Based Permissions:''' A new permission system allowing for flexible and customizable access control.
'''New Download Formats:''' Added support for Excel and CSV download formats.
'''MapStore Integration:''' Improved synchronization with MapStore, incorporating recent enhancements.
'''Asynchronous Engine Upgrade:''' Migrated to Redis for Celery's result backend and message handling, improving performance and scalability. (Breaking change requiring configuration updates).
'''Enhanced Harvesting System:''' Improvements to the harvesting subsystem including dynamic task expiration and a new monitoring layer.
'''QGIS Plugin Update:''' Updated the QGIS plugin to version 2.1.0 (support for GeoNode 3 deprecated).
'''Software Updates:''' Upgraded Geoserver to 2.27.3, Ubuntu base image to 24.04, Python to 3.12, and Django to version 5.

= Participation in Conferences =

* (No specific conference participation details were provided in the input.)

= Budget =

* Budget from OSGeo: (TBD)

= Outlook for 2026 =

* Continued development and stabilization of GeoNode 5.
* Further enhancements to the metadata engine and editor.
* Addressing feedback and bug fixes for the new version 5.0 release.
* Potential exploration of new features based on community input.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

OSGeoLive Report 2025

2026-02-26T06:01:18Z

Darkblueb: Created page with "OSGeoLive did not make a release in 2025. $ gdalinfo --formats|sort ;echo '#ogr'; ogrinfo --formats|sort user@osgeolive:~ PARQUET not-found = Key Accomplishments..."

OSGeoLive did not make a release in 2025.

$ gdalinfo --formats|sort ;echo '#ogr'; ogrinfo --formats|sort
user@osgeolive:~ PARQUET not-found

= Key Accomplishments & Activities (2025) =

Debian GIS saw ongoing maintenance and development activity throughout 2025, primarily focused on package updates, dependency management, and addressing technical challenges.

* '''Package Maintenance:''' Several key packages received updates. Bas Couwenberg actively removed outdated or unused packages from various task definitions, including:
* Dropping `libhdf4-alt-dev` from the devel task.
* Removing `python3-mapnik` from the workstation task.
* Eliminating `googleearth-package` from the remotesensing task.
* '''Technical Challenges - python-mapnik:''' A significant issue arose with the `python-mapnik` package due to the upstream project's lack of tagged releases, absence from PyPI, and unresponsiveness to issues (particularly after pybind11 changes broke imports). This impacted the ability to transfer maintenance of mapproxy.
* '''Project Status:'''
* Git repositories were maintained (migrated from Alioth to Salsa).
* Focus remained on core GIS tools: GRASS, GDAL, PostGIS, and QGIS.
* While the project wiki and documentation haven't been updated since 2018, active development and package tracking (via the Debian Package Tracker) confirm ongoing work.
* '''Community & Coordination:'''
* Active discussions on the debian-gis mailing list and IRC channel (#debian-gis on OFTC) regarding package transitions, sponsorship, and new contributions.
* The Debian GIS Policy document remains a central reference.

MapServer Report 2025

2026-02-26T05:42:30Z

Darkblueb: /* Outlook for 2026 */

= General information =

* Project officer: Steve Lime (Chair) @sdlime

* Project page information: https://www.osgeo.org/projects/mapserver/

= Key Accomplishments =

The MapServer project has released two major versions in 2025: 8.4.0 (January) and 8.6.0 (December). These releases include significant new features and improvements to enhance functionality and performance.

* '''MapServer 8.4.0 (January 2025):''' Introduced support for PCRE2 library, a new CONNECTIONTYPE RASTERLABEL, increased LEGEND_KEYSIZE_MAX, four new COMPOSITE blending operations, and improved encryption key file handling. Also enabled use_default_extent_for_getfeature for OGC Features API and PostGIS.
* '''MapServer 8.6.0 (December 2025):''' Added support for appending additional query parameters for OGCAPI: Features, a new MapServer index page, enhanced WMS GetFeatureInfo functionality for precise point identification, a FALLBACK parameter for CLASS objects, and vendorSpecificParameters in the OpenAPI document.
* '''Demo Server Maintenance:''' The demo server ([https://demo.mapserver.org MAPSERVER]) continues to be updated and maintained, providing a valuable resource for the community.
* '''Binary Distributions:''' Debian binaries are readily available, and OSGeoLive and UbuntuGIS releases are incorporating the new versions. MS4W users have access to updated builds.

= Participation in Conferences =

* No specific conference participation details were provided in the release announcements.

= Budget =

* Budget from OSGeo: TBD

= Outlook for 2026 =

* '''PostGIS Day 2026:''' Planned event.
* '''Conference Attendance:''' MapServer developers anticipate attending FOSS4G, FOSS4G EU, FOSS4G NA, and code sprints.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

MapServer Report 2025

2026-02-26T05:42:12Z

Darkblueb: /* Key Accomplishments */

= General information =

* Project officer: Steve Lime (Chair) @sdlime

* Project page information: https://www.osgeo.org/projects/mapserver/

= Key Accomplishments =

The MapServer project has released two major versions in 2025: 8.4.0 (January) and 8.6.0 (December). These releases include significant new features and improvements to enhance functionality and performance.

* '''MapServer 8.4.0 (January 2025):''' Introduced support for PCRE2 library, a new CONNECTIONTYPE RASTERLABEL, increased LEGEND_KEYSIZE_MAX, four new COMPOSITE blending operations, and improved encryption key file handling. Also enabled use_default_extent_for_getfeature for OGC Features API and PostGIS.
* '''MapServer 8.6.0 (December 2025):''' Added support for appending additional query parameters for OGCAPI: Features, a new MapServer index page, enhanced WMS GetFeatureInfo functionality for precise point identification, a FALLBACK parameter for CLASS objects, and vendorSpecificParameters in the OpenAPI document.
* '''Demo Server Maintenance:''' The demo server ([https://demo.mapserver.org MAPSERVER]) continues to be updated and maintained, providing a valuable resource for the community.
* '''Binary Distributions:''' Debian binaries are readily available, and OSGeoLive and UbuntuGIS releases are incorporating the new versions. MS4W users have access to updated builds.

= Participation in Conferences =

* No specific conference participation details were provided in the release announcements.

= Budget =

* Budget from OSGeo: TBD

= Outlook for 2026 =

* '''PostGIS Day 2027:''' Planned event.
* '''Conference Attendance:''' MapServer developers anticipate attending FOSS4G, FOSS4G EU, FOSS4G NA, and code sprints.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

MapServer Report 2025

2026-02-26T05:41:00Z

Darkblueb: /* Key Accomplishments */

= General information =

* Project officer: Steve Lime (Chair) @sdlime

* Project page information: https://www.osgeo.org/projects/mapserver/

= Key Accomplishments =

The MapServer project has released two major versions in 2025: 8.4.0 (January) and 8.6.0 (December). These releases include significant new features and improvements to enhance functionality and performance.

* '''MapServer 8.4.0 (January 2025):''' Introduced support for PCRE2 library, a new CONNECTIONTYPE RASTERLABEL, increased LEGEND_KEYSIZE_MAX, four new COMPOSITE blending operations, and improved encryption key file handling. Also enabled use_default_extent_for_getfeature for OGC Features API and PostGIS.
* '''MapServer 8.6.0 (December 2025):''' Added support for appending additional query parameters for OGCAPI: Features, a new MapServer index page, enhanced WMS GetFeatureInfo functionality for precise point identification, a FALLBACK parameter for CLASS objects, and vendorSpecificParameters in the OpenAPI document.
* '''Demo Server Maintenance:''' The demo server ([https://demo.mapserver.org](https://demo.mapserver.org)) continues to be updated and maintained, providing a valuable resource for the community.
* '''Binary Distributions:''' Debian binaries are readily available, and OSGeoLive and UbuntuGIS releases are incorporating the new versions. MS4W users have access to updated builds.

= Participation in Conferences =

* No specific conference participation details were provided in the release announcements.

= Budget =

* Budget from OSGeo: TBD

= Outlook for 2026 =

* '''PostGIS Day 2027:''' Planned event.
* '''Conference Attendance:''' MapServer developers anticipate attending FOSS4G, FOSS4G EU, FOSS4G NA, and code sprints.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

MapServer Report 2025

2026-02-26T05:40:35Z

Darkblueb: Created page with "= General information = * Project officer: Steve Lime (Chair) @sdlime * Project page information: https://www.osgeo.org/projects/mapserver/ = Key Accomplishments = The Ma..."

= General information =

* Project officer: Steve Lime (Chair) @sdlime

* Project page information: https://www.osgeo.org/projects/mapserver/

= Key Accomplishments =

The MapServer project has released two major versions in 2025: 8.4.0 (January) and 8.6.0 (December). These releases include significant new features and improvements to enhance functionality and performance.

* '''MapServer 8.4.0 (January 2025):''' Introduced support for PCRE2 library, a new CONNECTIONTYPE RASTERLABEL, increased LEGEND_KEYSIZE_MAX, four new COMPOSITE blending operations, and improved encryption key file
handling. Also enabled use_default_extent_for_getfeature for OGC Features API and PostGIS.
* '''MapServer 8.6.0 (December 2025):''' Added support for appending additional query parameters for OGCAPI: Features, a new MapServer index page, enhanced WMS GetFeatureInfo functionality for precise point identification, a FALLBACK parameter for CLASS objects, and vendorSpecificParameters in the OpenAPI document.
* '''Demo Server Maintenance:''' The demo server ([https://demo.mapserver.org](https://demo.mapserver.org)) continues to be updated and maintained, providing a valuable resource for the community.
* '''Binary Distributions:''' Debian binaries are readily available, and OSGeoLive and UbuntuGIS releases are incorporating the new versions. MS4W users have access to updated builds.

= Participation in Conferences =

* No specific conference participation details were provided in the release announcements.

= Budget =

* Budget from OSGeo: TBD

= Outlook for 2026 =

* '''PostGIS Day 2027:''' Planned event.
* '''Conference Attendance:''' MapServer developers anticipate attending FOSS4G, FOSS4G EU, FOSS4G NA, and code sprints.

[[Category:Annual Reports]]
[[Category: Reports 2025]]

TorchGeo Code Provenance

2026-02-26T01:53:30Z

Darkblueb: /* 7. Conclusion */

TorchGeo Code Provenance

2026-02-26T01:53:21Z

Darkblueb: /* 6. Outstanding Issues */

TorchGeo Code Provenance

2026-02-26T01:53:04Z

Darkblueb: TSC

=Code Provenance Review Process=

TorchGeo project
'''refer : https://www.osgeo.org/about/committees/incubation/graduation/'''

'''Incubation application questionnaire : https://trac.osgeo.org/osgeo/wiki/TorchGeo'''

==Document Status==

{| class="wikitable"
|-
| '''Version:''' || 0.5
|-
| '''Status:''' || Updated
|-
| '''Last Edited:''' || 15 Jan 2026
|}

==Purpose==

Show to "reasonable comfort level" that TorchGeo
does not have improperly contributed code, and that the code is all under the Project license.

Notice: ''It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the OSGeo Incubation Committee to prove there are no problems. However, OSGeo Incubation Committee does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.''

=TorchGeo Provenance Review=

== Project History ==

TorchGeo started as an internship project at Microsoft's AI for Good Lab in 2021, with continued support and funding from the University of Illinois Urbana-Champaign and the National Center for Supercomputing Applications. Since then, TorchGeo has been adopted by a diverse community of researchers from academia, industry, and government research institutions who have contributed to the success of the library. In 2025, we founded a new TorchGeo Organization to manage the TorchGeo Project, with the support of members from the above organizations.

'''Key milestones''':

- '''2021-05-11''': Initial commit (2330aad) by Adam J. Stewart

- '''2021-2024''': Organic growth to 120+ contributors

- '''2025''': Formation of TorchGeo Organization with formal governance structure

- '''2026''': OSGeo incubation application submitted

==Libraries==

All dependencies are external (not bundled in source tree). All licenses are OSI-approved and compatible with MIT.

{| class="wikitable" border="1"
|-
! Library !! License !! Compatible? !! In Core? !! Issues? !! Ok? !! Comments
|-
| einops || MIT || Yes || External || - || Yes || Tensor operations
|-
| geopandas || BSD-3-Clause || Yes || External || - || Yes || Geospatial dataframes
|-
| jsonargparse || MIT || Yes || External || - || Yes || CLI argument parsing
|-
| lightly || MIT || Yes || External || - || Yes || Self-supervised learning
|-
| lightning || Apache-2.0 || Yes || External || - || Yes || Training framework
|-
| matplotlib || PSF || Yes || External || - || Yes || Plotting
|-
| numpy || BSD-3-Clause || Yes || External || - || Yes || Numerical computing
|-
| pandas || BSD-3-Clause || Yes || External || - || Yes || Data manipulation
|-
| pillow || HPND [https://github.com/python-pillow/Pillow/issues/1507 *] / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || External || - || Yes || Image I/O
|-
| pyproj || MIT || Yes || External || - || Yes || Cartographic projections
|-
| rasterio || BSD-3-Clause || Yes || External || - || Yes || Geospatial raster I/O
|-
| segmentation-models-pytorch || MIT || Yes || External || - || Yes || Segmentation architectures
|-
| shapely || BSD-3-Clause || Yes || External || - || Yes || Geometric operations
|-
| timm || Apache-2.0 || Yes || External || - || Yes || Vision model zoo
|-
| torch || BSD-3-Clause || Yes || External || - || Yes || PyTorch core
|-
| torchmetrics || Apache-2.0 || Yes || External || - || Yes || Metrics computation
|-
| torchvision || BSD-3-Clause || Yes || External || - || Yes || Vision utilities
|-
| *kornia || Apache-2.0 || Yes || External || - || Yes || Computer vision ops
|}

==Copyright Holders==
{| class="wikitable" border="1"
|-
! Copyright Holder !! Contact !! Issues !! Comments
|-
| TorchGeo Contributors || N/A (collective) || None || Per LICENSE file
|}

The MIT License file states: "Copyright (c) TorchGeo Contributors."

This is a collective copyright model - individual contributors retain copyright but license under MIT. Historical other markings include:

<pre>
> git gr Copyright | grep -v TorchGeo
torchgeo/models/convlstm.py:# Copyright (c) 2017 Andrea Palazzi
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Copyright (c) Microsoft Corporation.
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/ltae.py:# Copyright (c) 2020 VSainteuf (Vivien Sainte Fare Garnot)
</pre>

== Committers ==
'''Total human contributors:''' 122

'''Total commits:''' 2778 (excluding bots)

'''Top contributors''' (TSC members marked with *):

{| class="wikitable" border="1"
|-
! Committer !! Email !! Affiliation
|-
| Adam J. Stewart * || ajstewart426@gmail.com || TUM / UIUC
|-
| Caleb Robinson * || calebrob6@gmail.com || AI for Good Msft
|-
| Isaac Corley * || isaac.corley@proton.me || Wherobots
|-
| Nils Lehmann * || nils.lehmann24@gmail.com || TUM
|-
| Ashwin Nair * || ashnair0007@gmail.com || Space42
|-
| Anthony Ortiz * || Anthony.Ortiz@microsoft.com || Microsoft
|-
| Robin Cole || robmarkcole@gmail.com || EarthDaily
|-
| Yi Wang || wangyi111@users.noreply.github.com || TUM
|-
| Yi-Chia Chang || yichiac@users.noreply.github.com || UIUC
|-
| Burak Ekim || burakekim@users.noreply.github.com || Bundeswehr Munich
|-
| Blaz Rolih || blaz-r@users.noreply.github.com || ULjubljana, Slovenia
|-
| Maciej Kilian || iejMac@users.noreply.github.com || Stability AI
|-
| Qiusheng Wu || giswqs@gmail.com || UTenn Knoxville
|}

'''Note:''' 122 total contributors. Full list available via <code>git shortlog -sne --all</code>.

==Source Files==
'''Total Python files:''' 557

'''Files with copyright header:''' 557 (100%) - ''after PR #3262 merged''

'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.

{| class="wikitable" border="1"
|-
! File !! License !! Copyright Holder !! Header? !! Issues? !! Ok? !! Comments
|-
| docs/user/metrics/update_timeline.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|-
| tests/data/landcoverai/split.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|}

'''Note:''' PR https://github.com/torchgeo/torchgeo/pull/3262 adds copyright headers to the 2 files that were missing them.

==Further Issues ==
'''Resolved:'''
* Copyright headers added to 2 missing files via PR #3262: https://github.com/torchgeo/torchgeo/pull/3262

* OSGeo does not require a CLA. We ask projects to think about what they want during incubation.

* Contributor agreement confirmed

'''Pending:'''

== TorchGeo Application Questionnaire ==
See the main application questionnaire for additional project details:
https://trac.osgeo.org/osgeo/wiki/TorchGeo

==Process==

'''This Code Provenance Review followed the OSGeo Incubation process:'''
{| class="wikitable"
|-
! Step !! Status !! Date !! Notes
|-
| 1. Create Provenance Review Document || Complete || 06 Jan 2026 || Document created from [https://wiki.osgeo.org/wiki/Provenance_Review_Template Provenance Review Template]
|-
| 2. Library/Component Review || Complete || 08 Jan 2026 || 18 dependencies reviewed, no issues found
|-
| 3. Code Copyright Review || Complete || 08 Jan 2026 || 557 files reviewed, no issues found
|-
| 4. Submit to Project Mentor || Complete || 08 Jan 2026 || Brian M Hamlin (Mentor)
|}
=== Review Summary ===
{| class="wikitable"
|-
| '''Components in source tree:''' || None (all external dependencies)
|-
| '''Problematic licenses:''' || None identified
|-
| '''License conflicts:''' || None identified
|-
| '''Files reviewed:''' || 557 Python files
|-
| '''Files with headers:''' || 557 (100%)
|-
| '''External code derivations:''' || 2 files (both MIT licensed, properly attributed)
|-
| '''Copyright model:''' || Collective ("TorchGeo Contributors")
|}
=== Outstanding Items ===
* '''Pending merge:''' [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262] - adds copyright headers to 2 files
* '''Resolved:''' CLA/DCO status confirmation. OSGeo does not require a CLA. OSGeo asks projects to think about what they want during incubation.
''ajstewart'' -- We used to have a CLA when we were under MSFT. We no longer have any CLA or DCO. We currently have no plans to add one. I know the Linux Foundation requires DCO. Does OSGeo have any requirements?
* '''Resolved:''' a TSC Members Agreement is not required by OSGeo

=== Conclusion ===
'''The TorchGeo codebase passes the Code Provenance Review''' with no blocking issues identified. The project demonstrates good license hygiene and is ready for OSGeo incubation from a code provenance perspective.

==Library/Component Review Process==

'''Review completed:''' 08 Jan 2026
=== 1. Components in Source Tree ===
'''Finding:''' '''None'''
TorchGeo does '''not''' bundle any third-party libraries in its source tree. Unlike projects like GDAL (which includes copies of libtiff, libjpeg, etc.), TorchGeo treats all dependencies as external packages installed via pip/conda.
* No <code>vendor/</code> directory
* No <code>third_party/</code> directory
* No <code>external/</code> directory
* No embedded library copies
This is the recommended approach and simplifies license management.
=== 2. External Dependencies ===
'''Total required dependencies:''' 18
'''All licenses are OSI-approved and compatible with MIT.'''
{| class="wikitable"
|-
! Package !! License !! Compatible? !! Potentially Problematic?
|-
| einops || MIT || Yes || No
|-
| geopandas || BSD-3-Clause || Yes || No
|-
| jsonargparse || MIT || Yes || No
|-
| kornia || Apache-2.0 || Yes || No
|-
| lightly || MIT || Yes || No
|-
| lightning || Apache-2.0 || Yes || No
|-
| matplotlib || PSF (BSD-style) || Yes || No
|-
| numpy || BSD-3-Clause || Yes || No
|-
| pandas || BSD-3-Clause || Yes || No
|-
| pillow || HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || No
|-
| pyproj || MIT || Yes || No
|-
| rasterio || BSD-3-Clause || Yes || No
|-
| segmentation-models-pytorch || MIT || Yes || No
|-
| shapely || BSD-3-Clause || Yes || No
|-
| timm || Apache-2.0 || Yes || No
|-
| torch || BSD-3-Clause || Yes || No
|-
| torchmetrics || Apache-2.0 || Yes || No
|-
| torchvision || BSD-3-Clause || Yes || No
|}

=== 3. License Distribution ===
{| class="wikitable"
|-
! License Type !! Count !! Notes
|-
| MIT || 6 || Permissive, fully compatible
|-
| BSD-3-Clause || 7 || Permissive, fully compatible
|-
| Apache-2.0 || 4 || Permissive, fully compatible
|-
| PSF || 1 || Python Software Foundation, BSD-style
|-
| HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || 1 || Historical Permission Notice and Disclaimer, permissive
|}

=== 4. Potentially Problematic Licenses ===
'''Finding:''' '''None identified'''
* No GPL or LGPL dependencies (no copyleft)
* No AGPL dependencies
* No proprietary or non-free dependencies
* No "viral" license concerns
=== 5. License Conflicts ===
'''Finding:''' '''None identified'''
All dependency licenses are permissive and compatible with each other and with TorchGeo's MIT license. There are no conflicts analogous to GDAL's use of GPL'ed GRASS libraries.
=== 6. Optional Dependencies ===
TorchGeo has optional dependencies for the <code>datasets</code> extra. All use permissive licenses:
{| class="wikitable"
|-
! Package !! License
|-
| h5py || BSD-3-Clause
|-
| laspy || BSD-2-Clause
|-
| netcdf4 || MIT
|-
| opencv-python || Apache-2.0
|-
| pycocotools || BSD-2-Clause
|-
| rioxarray || Apache-2.0
|-
| scikit-image || BSD-3-Clause
|-
| scipy || BSD-3-Clause
|-
| xarray || Apache-2.0
|}
=== 7. Conclusion ===
'''Overall assessment:''' No library/component issues identified
* No bundled code in source tree
* All 18 required dependencies use permissive OSI-approved licenses
* No GPL/copyleft dependencies
* No license conflicts
* Clean dependency model suitable for OSGeo incubation

== Code Copyright Review ==
'''Review completed:''' 08 Jan 2026
'''Reviewer:''' Brian M Hamlin (Mentor), with assistance from automated tooling
'''Scope:''' All 557 Python source files in the TorchGeo repository
=== 1. License Headers ===
{| class="wikitable"
|-
| '''Total Python files:''' || 557
|-
| '''Files with standard header:''' || 557 (100%)
|-
| '''Files missing header:''' || 0 (after [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262])
|}
'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.
'''Finding:''' All source files include the standard license header. Two utility scripts (<code>docs/user/metrics/update_timeline.py</code> and <code>tests/data/landcoverai/split.py</code>) were identified as missing headers during this review and fixed via [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262].
=== 2. License Consistency ===
'''Finding:''' All files are under the '''MIT License'''. No files use a different or conflicting license.
* No GPL, LGPL, or copyleft licenses found
* No Apache-only or BSD-only files found
* All code consistently uses MIT
=== 3. Code Origins ===
Two files contain code derived from external sources. Both are properly attributed and both original sources use MIT License (compatible):
{| class="wikitable"
|-
! File !! Source !! Source License !! Compatible? !! Attribution in File?
|-
| <code>torchgeo/models/btc.py</code> || [https://github.com/blaz-r/BTC-change-detection blaz-r/BTC-change-detection] || MIT || Yes || Yes
|-
| <code>torchgeo/models/croma.py</code> || [https://github.com/antofuller/CROMA antofuller/CROMA] || MIT || Yes || Yes
|}
'''Finding:''' Both external code sources are MIT licensed, which is fully compatible with TorchGeo's MIT license. Attribution is properly documented in the source file headers.
=== 4. Vendored/Bundled Code ===
'''Finding:''' No vendored or bundled third-party code exists in the source tree. All dependencies are external and installed via pip/conda.
* No <code>vendor/</code>, <code>third_party/</code>, or <code>external/</code> directories
* No embedded copies of libraries (unlike GDAL which bundles libtiff, libjpeg, etc.)
* All 18 dependencies are fetched externally at install time
=== 5. Copyright Holders ===
{| class="wikitable"
|-
! Copyright Holder !! Type !! Notes
|-
| TorchGeo Contributors || Collective || Single copyright holder for all files
|}
'''Finding:''' The project uses a '''collective copyright model'''. All files use "Copyright (c) TorchGeo Contributors" rather than individual contributor names.
'''Implications for relicensing:'''
* Simplified model - no need to contact 122 individual contributors
* Contributors implicitly agree to collective copyright by submitting PRs
* '''Resolved:''' Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) satisfactory and/or not required for incubation.

=== 6. Outstanding Issues ===
'''Resolved:'''
* Copyright headers added to 2 missing files: [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262]
* Confirm whether a CLA/DCO is in place or planned
* Contributor agreement status for PSC members

'''Pending:'''

=== 7. Conclusion ===
'''Overall assessment:''' No provenance issues identified.
The TorchGeo codebase demonstrates good copyright hygiene:
* 100% of source files have proper license headers
* All code is consistently MIT licensed
* External code derivations are properly attributed and license-compatible
* No vendored code complicates the license picture
* Collective copyright model simplifies governance
The codebase is ready for OSGeo incubation from a code provenance perspective, pending confirmation of contributor agreement procedures from the PSC.

TorchGeo Code Provenance

2026-02-26T01:52:30Z

Darkblueb: TSC

=Code Provenance Review Process=

TorchGeo project
'''refer : https://www.osgeo.org/about/committees/incubation/graduation/'''

'''Incubation application questionnaire : https://trac.osgeo.org/osgeo/wiki/TorchGeo'''

==Document Status==

{| class="wikitable"
|-
| '''Version:''' || 0.5
|-
| '''Status:''' || Updated
|-
| '''Last Edited:''' || 15 Jan 2026
|}

==Purpose==

Show to "reasonable comfort level" that TorchGeo
does not have improperly contributed code, and that the code is all under the Project license.

Notice: ''It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the OSGeo Incubation Committee to prove there are no problems. However, OSGeo Incubation Committee does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.''

=TorchGeo Provenance Review=

== Project History ==

TorchGeo started as an internship project at Microsoft's AI for Good Lab in 2021, with continued support and funding from the University of Illinois Urbana-Champaign and the National Center for Supercomputing Applications. Since then, TorchGeo has been adopted by a diverse community of researchers from academia, industry, and government research institutions who have contributed to the success of the library. In 2025, we founded a new TorchGeo Organization to manage the TorchGeo Project, with the support of members from the above organizations.

'''Key milestones''':

- '''2021-05-11''': Initial commit (2330aad) by Adam J. Stewart

- '''2021-2024''': Organic growth to 120+ contributors

- '''2025''': Formation of TorchGeo Organization with formal governance structure

- '''2026''': OSGeo incubation application submitted

==Libraries==

All dependencies are external (not bundled in source tree). All licenses are OSI-approved and compatible with MIT.

{| class="wikitable" border="1"
|-
! Library !! License !! Compatible? !! In Core? !! Issues? !! Ok? !! Comments
|-
| einops || MIT || Yes || External || - || Yes || Tensor operations
|-
| geopandas || BSD-3-Clause || Yes || External || - || Yes || Geospatial dataframes
|-
| jsonargparse || MIT || Yes || External || - || Yes || CLI argument parsing
|-
| lightly || MIT || Yes || External || - || Yes || Self-supervised learning
|-
| lightning || Apache-2.0 || Yes || External || - || Yes || Training framework
|-
| matplotlib || PSF || Yes || External || - || Yes || Plotting
|-
| numpy || BSD-3-Clause || Yes || External || - || Yes || Numerical computing
|-
| pandas || BSD-3-Clause || Yes || External || - || Yes || Data manipulation
|-
| pillow || HPND [https://github.com/python-pillow/Pillow/issues/1507 *] / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || External || - || Yes || Image I/O
|-
| pyproj || MIT || Yes || External || - || Yes || Cartographic projections
|-
| rasterio || BSD-3-Clause || Yes || External || - || Yes || Geospatial raster I/O
|-
| segmentation-models-pytorch || MIT || Yes || External || - || Yes || Segmentation architectures
|-
| shapely || BSD-3-Clause || Yes || External || - || Yes || Geometric operations
|-
| timm || Apache-2.0 || Yes || External || - || Yes || Vision model zoo
|-
| torch || BSD-3-Clause || Yes || External || - || Yes || PyTorch core
|-
| torchmetrics || Apache-2.0 || Yes || External || - || Yes || Metrics computation
|-
| torchvision || BSD-3-Clause || Yes || External || - || Yes || Vision utilities
|-
| *kornia || Apache-2.0 || Yes || External || - || Yes || Computer vision ops
|}

==Copyright Holders==
{| class="wikitable" border="1"
|-
! Copyright Holder !! Contact !! Issues !! Comments
|-
| TorchGeo Contributors || N/A (collective) || None || Per LICENSE file
|}

The MIT License file states: "Copyright (c) TorchGeo Contributors."

This is a collective copyright model - individual contributors retain copyright but license under MIT. Historical other markings include:

<pre>
> git gr Copyright | grep -v TorchGeo
torchgeo/models/convlstm.py:# Copyright (c) 2017 Andrea Palazzi
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Copyright (c) Microsoft Corporation.
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/ltae.py:# Copyright (c) 2020 VSainteuf (Vivien Sainte Fare Garnot)
</pre>

== Committers ==
'''Total human contributors:''' 122

'''Total commits:''' 2778 (excluding bots)

'''Top contributors''' (TSC members marked with *):

{| class="wikitable" border="1"
|-
! Committer !! Email !! Affiliation
|-
| Adam J. Stewart * || ajstewart426@gmail.com || TUM / UIUC
|-
| Caleb Robinson * || calebrob6@gmail.com || AI for Good Msft
|-
| Isaac Corley * || isaac.corley@proton.me || Wherobots
|-
| Nils Lehmann * || nils.lehmann24@gmail.com || TUM
|-
| Ashwin Nair * || ashnair0007@gmail.com || Space42
|-
| Anthony Ortiz * || Anthony.Ortiz@microsoft.com || Microsoft
|-
| Robin Cole || robmarkcole@gmail.com || EarthDaily
|-
| Yi Wang || wangyi111@users.noreply.github.com || TUM
|-
| Yi-Chia Chang || yichiac@users.noreply.github.com || UIUC
|-
| Burak Ekim || burakekim@users.noreply.github.com || Bundeswehr Munich
|-
| Blaz Rolih || blaz-r@users.noreply.github.com || ULjubljana, Slovenia
|-
| Maciej Kilian || iejMac@users.noreply.github.com || Stability AI
|-
| Qiusheng Wu || giswqs@gmail.com || UTenn Knoxville
|}

'''Note:''' 122 total contributors. Full list available via <code>git shortlog -sne --all</code>.

==Source Files==
'''Total Python files:''' 557

'''Files with copyright header:''' 557 (100%) - ''after PR #3262 merged''

'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.

{| class="wikitable" border="1"
|-
! File !! License !! Copyright Holder !! Header? !! Issues? !! Ok? !! Comments
|-
| docs/user/metrics/update_timeline.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|-
| tests/data/landcoverai/split.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|}

'''Note:''' PR https://github.com/torchgeo/torchgeo/pull/3262 adds copyright headers to the 2 files that were missing them.

==Further Issues ==
'''Resolved:'''
* Copyright headers added to 2 missing files via PR #3262: https://github.com/torchgeo/torchgeo/pull/3262

* OSGeo does not require a CLA. We ask projects to think about what they want during incubation.

* Contributor agreement confirmed

'''Pending:'''

== TorchGeo Application Questionnaire ==
See the main application questionnaire for additional project details:
https://trac.osgeo.org/osgeo/wiki/TorchGeo

==Process==

'''This Code Provenance Review followed the OSGeo Incubation process:'''
{| class="wikitable"
|-
! Step !! Status !! Date !! Notes
|-
| 1. Create Provenance Review Document || Complete || 06 Jan 2026 || Document created from [https://wiki.osgeo.org/wiki/Provenance_Review_Template Provenance Review Template]
|-
| 2. Library/Component Review || Complete || 08 Jan 2026 || 18 dependencies reviewed, no issues found
|-
| 3. Code Copyright Review || Complete || 08 Jan 2026 || 557 files reviewed, no issues found
|-
| 4. Submit to Project Mentor || Complete || 08 Jan 2026 || Brian M Hamlin (Mentor)
|}
=== Review Summary ===
{| class="wikitable"
|-
| '''Components in source tree:''' || None (all external dependencies)
|-
| '''Problematic licenses:''' || None identified
|-
| '''License conflicts:''' || None identified
|-
| '''Files reviewed:''' || 557 Python files
|-
| '''Files with headers:''' || 557 (100%)
|-
| '''External code derivations:''' || 2 files (both MIT licensed, properly attributed)
|-
| '''Copyright model:''' || Collective ("TorchGeo Contributors")
|}
=== Outstanding Items ===
* '''Pending merge:''' [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262] - adds copyright headers to 2 files
* '''Resolved:''' CLA/DCO status confirmation. OSGeo does not require a CLA. OSGeo asks projects to think about what they want during incubation.
''ajstewart'' -- We used to have a CLA when we were under MSFT. We no longer have any CLA or DCO. We currently have no plans to add one. I know the Linux Foundation requires DCO. Does OSGeo have any requirements?
* '''Resolved:''' a PSC Members Agreement is not required by OSGeo

=== Conclusion ===
'''The TorchGeo codebase passes the Code Provenance Review''' with no blocking issues identified. The project demonstrates good license hygiene and is ready for OSGeo incubation from a code provenance perspective.

==Library/Component Review Process==

'''Review completed:''' 08 Jan 2026
=== 1. Components in Source Tree ===
'''Finding:''' '''None'''
TorchGeo does '''not''' bundle any third-party libraries in its source tree. Unlike projects like GDAL (which includes copies of libtiff, libjpeg, etc.), TorchGeo treats all dependencies as external packages installed via pip/conda.
* No <code>vendor/</code> directory
* No <code>third_party/</code> directory
* No <code>external/</code> directory
* No embedded library copies
This is the recommended approach and simplifies license management.
=== 2. External Dependencies ===
'''Total required dependencies:''' 18
'''All licenses are OSI-approved and compatible with MIT.'''
{| class="wikitable"
|-
! Package !! License !! Compatible? !! Potentially Problematic?
|-
| einops || MIT || Yes || No
|-
| geopandas || BSD-3-Clause || Yes || No
|-
| jsonargparse || MIT || Yes || No
|-
| kornia || Apache-2.0 || Yes || No
|-
| lightly || MIT || Yes || No
|-
| lightning || Apache-2.0 || Yes || No
|-
| matplotlib || PSF (BSD-style) || Yes || No
|-
| numpy || BSD-3-Clause || Yes || No
|-
| pandas || BSD-3-Clause || Yes || No
|-
| pillow || HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || No
|-
| pyproj || MIT || Yes || No
|-
| rasterio || BSD-3-Clause || Yes || No
|-
| segmentation-models-pytorch || MIT || Yes || No
|-
| shapely || BSD-3-Clause || Yes || No
|-
| timm || Apache-2.0 || Yes || No
|-
| torch || BSD-3-Clause || Yes || No
|-
| torchmetrics || Apache-2.0 || Yes || No
|-
| torchvision || BSD-3-Clause || Yes || No
|}

=== 3. License Distribution ===
{| class="wikitable"
|-
! License Type !! Count !! Notes
|-
| MIT || 6 || Permissive, fully compatible
|-
| BSD-3-Clause || 7 || Permissive, fully compatible
|-
| Apache-2.0 || 4 || Permissive, fully compatible
|-
| PSF || 1 || Python Software Foundation, BSD-style
|-
| HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || 1 || Historical Permission Notice and Disclaimer, permissive
|}

=== 4. Potentially Problematic Licenses ===
'''Finding:''' '''None identified'''
* No GPL or LGPL dependencies (no copyleft)
* No AGPL dependencies
* No proprietary or non-free dependencies
* No "viral" license concerns
=== 5. License Conflicts ===
'''Finding:''' '''None identified'''
All dependency licenses are permissive and compatible with each other and with TorchGeo's MIT license. There are no conflicts analogous to GDAL's use of GPL'ed GRASS libraries.
=== 6. Optional Dependencies ===
TorchGeo has optional dependencies for the <code>datasets</code> extra. All use permissive licenses:
{| class="wikitable"
|-
! Package !! License
|-
| h5py || BSD-3-Clause
|-
| laspy || BSD-2-Clause
|-
| netcdf4 || MIT
|-
| opencv-python || Apache-2.0
|-
| pycocotools || BSD-2-Clause
|-
| rioxarray || Apache-2.0
|-
| scikit-image || BSD-3-Clause
|-
| scipy || BSD-3-Clause
|-
| xarray || Apache-2.0
|}
=== 7. Conclusion ===
'''Overall assessment:''' No library/component issues identified
* No bundled code in source tree
* All 18 required dependencies use permissive OSI-approved licenses
* No GPL/copyleft dependencies
* No license conflicts
* Clean dependency model suitable for OSGeo incubation

== Code Copyright Review ==
'''Review completed:''' 08 Jan 2026
'''Reviewer:''' Brian M Hamlin (Mentor), with assistance from automated tooling
'''Scope:''' All 557 Python source files in the TorchGeo repository
=== 1. License Headers ===
{| class="wikitable"
|-
| '''Total Python files:''' || 557
|-
| '''Files with standard header:''' || 557 (100%)
|-
| '''Files missing header:''' || 0 (after [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262])
|}
'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.
'''Finding:''' All source files include the standard license header. Two utility scripts (<code>docs/user/metrics/update_timeline.py</code> and <code>tests/data/landcoverai/split.py</code>) were identified as missing headers during this review and fixed via [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262].
=== 2. License Consistency ===
'''Finding:''' All files are under the '''MIT License'''. No files use a different or conflicting license.
* No GPL, LGPL, or copyleft licenses found
* No Apache-only or BSD-only files found
* All code consistently uses MIT
=== 3. Code Origins ===
Two files contain code derived from external sources. Both are properly attributed and both original sources use MIT License (compatible):
{| class="wikitable"
|-
! File !! Source !! Source License !! Compatible? !! Attribution in File?
|-
| <code>torchgeo/models/btc.py</code> || [https://github.com/blaz-r/BTC-change-detection blaz-r/BTC-change-detection] || MIT || Yes || Yes
|-
| <code>torchgeo/models/croma.py</code> || [https://github.com/antofuller/CROMA antofuller/CROMA] || MIT || Yes || Yes
|}
'''Finding:''' Both external code sources are MIT licensed, which is fully compatible with TorchGeo's MIT license. Attribution is properly documented in the source file headers.
=== 4. Vendored/Bundled Code ===
'''Finding:''' No vendored or bundled third-party code exists in the source tree. All dependencies are external and installed via pip/conda.
* No <code>vendor/</code>, <code>third_party/</code>, or <code>external/</code> directories
* No embedded copies of libraries (unlike GDAL which bundles libtiff, libjpeg, etc.)
* All 18 dependencies are fetched externally at install time
=== 5. Copyright Holders ===
{| class="wikitable"
|-
! Copyright Holder !! Type !! Notes
|-
| TorchGeo Contributors || Collective || Single copyright holder for all files
|}
'''Finding:''' The project uses a '''collective copyright model'''. All files use "Copyright (c) TorchGeo Contributors" rather than individual contributor names.
'''Implications for relicensing:'''
* Simplified model - no need to contact 122 individual contributors
* Contributors implicitly agree to collective copyright by submitting PRs
* '''Resolved:''' Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) satisfactory and/or not required for incubation.

=== 6. Outstanding Issues ===
'''Resolved:'''
* Copyright headers added to 2 missing files: [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262]
* Confirm whether a CLA/DCO is in place or planned
* Contributor agreement status for PSC members

'''Pending:'''

=== 7. Conclusion ===
'''Overall assessment:''' No provenance issues identified.
The TorchGeo codebase demonstrates good copyright hygiene:
* 100% of source files have proper license headers
* All code is consistently MIT licensed
* External code derivations are properly attributed and license-compatible
* No vendored code complicates the license picture
* Collective copyright model simplifies governance
The codebase is ready for OSGeo incubation from a code provenance perspective, pending confirmation of contributor agreement procedures from the PSC.

Talk:TorchGeo Code Provenance

2026-02-26T00:04:07Z

Darkblueb: record the final vote

<pre>
On Mon, Feb 2, 2026 at 8:08 AM Brian M Hamlin via Incubator <incubator@lists.osgeo.org> wrote:

Hello All -

With this email, I am pleased to present to the OSGeo Incubation Committee an OSGeo Project Candidate : TorchGeo [0]. As Project Mentor I have worked closely with the TorchGeo PSC and code base. In my best judgement, I find that TorchGeo is not only a suitable candidate, but in fact a substantial addition to a large set of consequential and significant geospatial software projects of our current era, represented by OSGeo.

The Program Steering Committee (PSC) of TorchGeo is composed of a small but diverse group of committers; the PSC has defined clear standards for code contributions, bugs, features and additions. Due to the unique character of this training and benchmarking environment, many complete teams from more than a hundred institutions worldwide are contributing and active in the project. As a Machine Learning and Artificial Intelligence environment itself, new data LICENSE challenges are present as well.

You will find abundant links and details in the project Application [1] and Code Review [2]. The TorchGeo project release cycle is integrated with OSGeo Planet and news -- special thanks to JSanz.

Please review and cast your vote at your earliest convenience. Questions and other inquiries will be handled on an OSGeo TRAC instance ticket [3]. The voting period shall begin with the date of this email, and scheduled to conclude in 14 days hence.

Special gratitude on this important day goes out to the OSGeo Systems Administration Team for TRAC, MediaWiki, email and support infrastructure

signed --Brian M Hamlin / MAPLABS / TorchGeo Project Mentor on behalf of #osgeo

##-----------------------------------------------------------------------------------------------------------------------

[0] https://www.osgeo.org/projects/torchgeo/

[1] https://trac.osgeo.org/osgeo/wiki/TorchGeo

[2] https://wiki.osgeo.org/wiki/TorchGeo_Code_Provenance

[3] https://trac.osgeo.org/osgeo/ticket/3519

Congrats to team, and thanks for mentoring. I will review this weekend.

- -
Jody Garnett

_______________________________________________
Incubator mailing list
Incubator@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/incubator
</pre>

Board Meeting 2026-02-24

=== Recognize TorchGeo as OSGeo Project via recent Incubation Committee vote ===

* Brian Hamlin reporting as mentor of the TorchGeo project
* MOTION: Motion to recognize TorchGeo as OSGeo Project
* Motion passed during the meeting: +1 by: Mike, Jeroen, Vicky, Tim, Codrina, Angelos, Joana, Tom

<pre>OSGeo Board Members and Guests
On behalf of the TorchGeo Project technical-steering-committee , authors, testers, academics and users of all kinds, I want to emphasize implementation of the newest additions to computer science and remote sensing theory and practice, in a community setting, evolving quickly and with results.

With #torchgeo, the OSGeo ecosystem will grow, strengthen and extend into rapidly evolving new discoveries and applications. It will be a wild ride.
</pre>

'''Note''': AI LLM assistance was employed in the production of this document.

{| class="wikitable"
|+ LLM Engine contributions by operator
|-
! Operator !! Tool !! Model 1 !! Model 2
|-
| '''omniverdi''' || opencode || claude-opus || devstral2-2512
|-
| '''darkblueb''' || ollama local-only || gemma3:12b || qwen3-coder
|}

Board Meeting 2026-02-24

2026-02-20T15:21:15Z

Darkblueb: TorchGeo award

This board meeting is '''scheduled Tuesday 24 February 2026''' at [https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=02&day=24&hour=17&min=0&sec=0&p1=250&p2=26&p3=49&p4=155&p5=16&p6=133 '''17:00''' UTC] through [https://meet.jit.si/OsgeoBoard Jitsi], a record of motions is preserved on [https://www.loomio.org/g/kdSmIwxu/osgeo-board Loomio] and actions on the [https://git.osgeo.org/gitea/osgeo/todo/issues OSGeo todo] issue tracker.

== Agenda ==

=== Current items ===

# ''roll call''
# ''appoint meeting chair, meeting scribe/secretary''
# ''Review and approve past minutes''
#* [[Board_Meeting_2026-01-26]]
# Finalize [https://www.loomio.com/d/5jiKNtgb/executive-positions-2026 board executive positions]
# Recognize [https://www.osgeo.org/projects/torchgeo/ TorchGeo] as OSGeo Project via recent Incubation Committee vote [https://lists.osgeo.org/pipermail/incubator/2026-February/005161.html LINK]
# Funding ideas for 2026
# Update on Pretalx (Jeroen)
# Update on OSGeo legal entity in Europe (The Netherlands) (Jeroen)
# Update on [https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/topic-details/horizon-cl6-2026-03-governance-06 Horizon Europe call HORIZON-CL6-2026-03-GOVERNANCE-06] - A services and business incubator for geospatial open-source developments (Jeroen)
# Conference Committee (LoI FOSS4G 2027)
# Cyber Resilience Act
# New membership process
# Respond to [https://gitea.osgeo.org/Lads/llm-survey ''OSGeo member survey on the impact of LLMs on open-source projects''] proposal
# Email from The FOSS Club at Delhi Technical Campus - Manya Yadav (4 February 2026)
# ''Add your topic here''

== Minutes ==

* Presiding:
* Scribing:
* Attending:
* Guests:

=== Actions ===

* See https://git.osgeo.org/gitea/osgeo/todo/issues

== IRC Log ==
* no log, Jitsi meeting

== Next meeting ==
*[[Board Meeting 2026-03-31]]

[[Category:Board]]
[[Category:Board Meetings 2026]]

Incubation Committee

2026-02-13T23:43:58Z

Darkblueb: /* TorchGeo */

The project incubation committee is responsible for overseeing the incubation process for new projects entering the foundation. The incubation committee provides resources to assist new projects to reach full membership, and makes recommendations to the board when they feel projects have completed incubation.

== About the Incubation Committee ==

The OSGeo Incubation Committee is an open source advocacy and outreach activity welcoming projects and development teams to our foundation.

The committee is responsible for:

# [https://www.osgeo.org/projects/ OSGeo project website] review
#* Reviewing applications to list projects on the OSGeo website
#* Preparing and recommend criteria and review process for projects to be listed on the OSGeo website
# [https://www.osgeo.org/projects/#community Community project program]
#* Reviewing community project applications and recommending projects to the board to be accepted as community projects
#* Reporting on the status of projects in the community project program to the board periodically (via Chair)
#* Preparing and recommending community project process and criteria to the board.
#* See [[OSGeo_Community_Projects]] for more information
# [https://www.osgeo.org/about/committees/incubation/incubation-process/ OSGeo Incubation process]
#* Reviewing applications for incubation and making recommendations to the board on projects that should be admitted into incubation.
#* Appointing [https://www.osgeo.org/about/committees/incubation/mentor/ mentors] for incubation projects.
#* Reviewing progress of projects against incubation requirements, and recommending projects for full project status to the board, when deemed appropriate.
#* Reporting on the status of projects in incubation and the incubation process to the board periodically (via Chair).
#* Preparing and recommending incubation process and criteria to the board.

The OSGeo incubation committee is not responsible for graduated OSGeo Projects. Graduated OSGeo projects are recognized as a committee who report directly to the board via their project officer.

== Supporting project teams ==

If you would like your software project to listed on the website, or apply to become an OSGeo Community project, please send a description of your project to the OSGeo Incubation Committee Mailing List.

We look forward to helping you!

{| class="wikitable"
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Responsibility
! scope="col" width="155" style="text-align: center; font-weight: bold;" | Website Listing
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Community
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Project
|-
| Geospatial 
- README or project description
| X
| X
| X
|-
| Geospatial 
- User guide or quickstart
|
| X
| X
|-
| Free or Open Source License 
- See LICENSE.md
| X
| X
| X
|-
| Free or Open Source License 
- Check headers
|
| X
| X
|-
| Free or Open Source License 
- Providence Review
|
|
| X
|-
| Participatory 
- See CONTRIBUTING.md
| X
| X
| X
|-
| Participatory 
- History of pull requests or patches
|
| X
| X
|-
| Participatory 
- CODE_OF_CONDUCT.md
|
| X
| X
|-
| Open Community 
- communication channel 
- decision making process
|
|
| X
|-
| Active Healthy Community 
- user and developer collaboration 
- long term viability
|
|
| X
|-
| Development Process 
- version control 
- issue tracker 
- leadership open to new members 
- transparent decision making
|
|
| X
|-
| Documentation 
- user documentation 
- developer documentation
|
|
| X
|-
| Release Procedure 
- release process 
- documented testing process 
|
|
| X
|-
| style="font-weight: bold;" | Foundation Resources
! scope="col" width="155" style="text-align: center; font-weight: bold;" | Website Listing
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Community
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Project
|-
| website project list
| X
| X
| X
|-
| website choose-a-project
| X
| X
| X
|-
| OSGeo Live
| X
| X
| X
|-
| Marketing Collateral
|
| X
| X
|-
| Representation
|
|
| project officer
|-
| infrastructure and facilities
|
| X
| X
|-
| promotion & marketing
|
| X
| X
|-
| budget
|
| osgeo board
| project budget
|-
| fundraising
|
| X
| X
|}

=== Financial support ===

The incubation process establishes a project as a full fledged OSGeo committee, with a project project officer, with direct access to OSGeo treasurer, and reporting to the board during annual general meeting.

While Community projects are not recognized as an independent committee, the OSGeo board maintains an "OSGeo Community" initiative with budget to support your activities. Attend one of the OSGeo board monthly meetings, or ask on the board mailing list, if your project has an activity that can benefit from financial support.

For more information see [https://github.com/OSGeo/osgeo/blob/master/board/documents/osgeo_financial_guidance.pdf osgeo_financial_guidence.pdf]

=== Branding ===

{| class="wikitable"
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Community
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Project
|-
| [[File:OSGeo community.png|frameless|OSGeo Community Project]]
| [[File:OSGeo project.png|frameless|OSGeo Project]]
|}

== Step 1: Add OSGeo Website Project Page ==

To be listed on the OSGeo website:

# Be geospatial
#* Confirm by checking README or project description
# Have a free license or open source license
#* The license must be OSI approved
# Welcome participation and new contributors.
#* We look for a clear contribution policy

If you have questions about the above, or would like guidance on setting up your open source project, please reach out to us.

Here is an example email request ([https://lists.osgeo.org/mailman/listinfo/incubator mailing list sign up required]):

: '''to''': incubator@lists.osgeo.org
:
: '''subject''': water topology api
:
: '''message''':
:
:: Incubation committee:
::
:: I would like to ask permission to to list my project "water topology api" on the OSGeo website in order to share my work with more people!
::
:: The project is built on PostGIS topology providing a REST API to help with watershed analysis and maintenance.
::
:: The repository is located here: https://gitlab.host.net/watertopo/ released using GPL license.
::
:: My OSGeo userid is "atlantis" and I will need permission to create a project page.
::
:: Thanks!

== Step 2: Join OSGeo Community Projects Initiative ==

Projects applying to the *OSGeo Community Projects* initiative are asked to:

# Be geospatial
#* Confirm by checking README or project description
#* project page on the osgeo website
#* We ask projects have some user documentation, for example an OSGeo Live quickstart
# Have a free license or an open source license.
#* The license must be OSI approved
#* We ask that the project team check the file headers and double check the license has been appropriately applied
# Welcome participation and new contributors.
#* We look for a clear contribution policy
#* We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
#* Projects are required to have a code of conduct

OSGeo provides [https://www.osgeo.org/code_of_conduct/ code of conduct guidance], many projects selecting [https://www.contributor-covenant.org/ contribution covenant]).

OSGeo [[Community Projects]] can take part in the incubation committee for guidance on open source use, setting up project governance, promoting the project, and building the project community. We look forward to working with you. For sensitive topics (patents, copyright, trademarks, and license) you wish to attend a video meeting.

Here is an example email request ([https://lists.osgeo.org/mailman/listinfo/incubator mailing list sign up required]):

: '''to''': incubator@lists.osgeo.org
:
: '''subject''': water topology community project application
:
: '''message''':
:
:: Incubation committee:
::
:: The Water Topology project would like to apply to join the OSGeo community program. We recently re-branded to just "water topology" to reflect client libraries being include in our project. The project provides web services built on PostGIS topology to help with watershed analysis and maintenance.
::
:: The osgeo project page is available here: https://osgeo.org/projects/watertopology and our user guide is located at https://watertopo.gitlab.host.net/ .
::
:: The repository remains at https://gitlab.host.net/watertopo/ with GPL license, contribution policy and code of conduct. We have checked our source code to ensure GPL license has been correctly applied. Our issue tracker is active, and we have received a number of merge-requests.
::
:: Thank you for your consideration and we look forward to your questions!

== Step 3: Incubation process and Graduation ==

The *OSGeo Project* designation is intended to recognize established projects with a diverse community of developers and users with a proven track record.

To be recognized as an *OSGeo Project* a project team applies for the OSGeo incubation program. Successful projects are teamed up with an experienced open source mentor to help answer questions, obtain legal council, and help guide work on transparency and community development as required.

Although incubation is a lot of work, this is opportunity for project teams to grow and improve and be publicly recognized for their accomplishment.

To be recognized as an *OSGeo Project* we ask that project teams excel in each of areas mentioned above, see [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.pdf graduation checklist] ( [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.md markdown] ) or the comparison table on this page for more detail.

The OSGeo incubation process takes place in three stages:

# Initial Application
## Application request
## Mentor volunteer
# Incubator
## Project Status: project details, and a few resourcing questions for the system admin committee (see [[Project Status Template]]).
## Provenance Review: project team check to ensure the project is open source and has permission to distribute its source code.
## Project team and mentor work on [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.pdf graduation checklist] ( [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.md markdown] ) priorities
# Graduation
## Mentor recommends project for graduation with motion to the incubation committee
## Committee chair informs the OSGeo board, who appoints the project team as a newly formed OSGeo committee

== Incubation ==

The following projects are currently in OSGeo incubation. The links provided are used to track the progress of incubation projects and are used by the developer team (and OSGeo mentor). In many cases the links will take you to a project specific wiki or website in order to be closer to their target community.

When projects have completed the graduation checklist their mentor will recommend them to the Incubation committee for graduation.

=== IstSOS ===

'''IstSOS''': http://wiki.osgeo.org/wiki/IstSOS
# [[IstSOS Provenance Review]]
# [[IstSOS Incubation Status]]
# ''Mentor'': [[User: Jeff_McKenna|Jeff McKenna]]

=== Opticks ===

'''Opticks''': http://opticks.org
# [[Opticks Incubation Status]]
# no provenance review provided
# [[Opticks Incubation Checklist]]
# ''Mentor'': [[User: Mark_Lucas|Mark Lucas]]

=== Oskari ===

'''Oskari''': http://oskari.org/
# [[Oskari Incubation Application]]
# [[Oskari Incubation Status]]
# [https://github.com/oskariorg/oskari-docs/wiki/Oskari-Incubation-Checklist Oskari Graduation Checklist]
# ''Mentor'': [[Arnulf Christl]]

=== TEAM Engine ===

'''TEAM Engine''': http://teamengine.sourceforge.net
# [https://trac.osgeo.org/osgeo/ticket/1016 Incubation Application] from 2012
# [https://github.com/opengeospatial/teamengine/wiki/OSGEO-Graduation TEAM Engine Incubation Checklist]
# ''Mentor'': [[User: Jive|Jody Garnett]]

=== TorchGeo ===

'''TorchGeo''': https://www.osgeo.org/projects/torchgeo/
# [[TorchGeo_Code_Provenance|TorchGeo Provenance Review]]
# [https://trac.osgeo.org/osgeo/ticket/3519|TorchGeo Incubation Status]
# ''Mentor'': [[User:darkblueb|Brian M Hamlin]]

== Graduated ==

The following status and provenance documents are for historical purposes, and are no longer actively maintained.

* Community Mapbuilder: [[Community Mapbuilder Incubation Progress]] | [[Community Mapbuilder Provenance Review]] (Entered 2006-02-04, Graduated 2006-07-14, Mentor: Steve Lime)
* deegree: [[deegree Incubation Status]] | [[deegree Provenance Review]] (Entered: 2008-06-09, Graduated 2010-02-04, Mentor: Jody Garnett)
* FDO: [[FDO Incubation Status]] | [[FDO Provenance Review]] (Entered 2007-03-06, Graduated 2008-02-08, Mentor: Daniel Morissette)
* GEOS: [[GEOS Incubation Status]] | [[GEOS Provenance Review]] (Entered 2007-11-02, Graduated 2012-04-28, Mentor: Frank Warmerdam)
* GDAL/OGR: [[GDAL Incubation Progress]] | [[GDAL Provenance Review]] (Entered 2006-02-04, Graduated 2008-02-08, Mentor: Paul Spencer)
* Geomajas: [[GeoMajas Incubation Status]] | [[GeoMajas Provenance Review]] (Entered 2010-03-04, Graduated 2010-11-22, Mentor: Paul Spencer)
* GeoNetwork: [[GeoNetwork Incubation Status]] | [[GeoNetwork Provenance Review]] (Entered 2006-11-10, Graduated 2008-06-21, Mentor: Jody Garnett)
* GeoNode: [[GeoNode Incubation Status]] [[GeoNode Provenance Review]] [[GeoNode Incubation Checklist]] (Entered 2015-08-13, Graduated 2016-11-09, Mentor: David Bitner)
* GeoMOOSE: [[GeoMoose Incubation Status]] | [[GeoMoose Provenance Review]] | [[GeoMoose Incubation Checklist]] (Entered 2011-12-08, Graduated 2013-04-19, Mentor: Jody Garnett)
* GeoTools: [[GeoTools Incubation Progress]] | [[GeoTools Provenance Review]] (Entered 2006-02-27, Graduated 2008-07-18, Mentor: Cameron Shorter)
* GeoServer: [http://old.geoserver.org/OSGEO%20incubation%20questionnaire.html Incubation Questionnaire] | [http://old.geoserver.org/GeoServer%20Incubation%20Status.html Incubation Status] | [https://github.com/geoserver/geoserver/wiki/GeoServer-Provenance-Review Provenance Review] | [https://github.com/geoserver/geoserver/wiki/GeoServer-Incubation-Checklist Incubation Checklist] | [[Geoserver Mentor Notes]] (Entered 2009-11-05, Graduated 2013-03-15, Mentor: Landon Blake)
* gvSIG: [[gvSIG Incubation Status]] | [[gvSIG Provenance Review]] | [[gvSIG Incubation Checklist]] (Entered 2007-09-07, Graduated 2015-11-26, Mentor: Dimitris Kotzinos)
* GRASS: [[GRASS Incubation Progress]] | [[GRASS Provenance Review]] (Entered 2006-02-27, Graduated 2008-02-08, Mentor: Norman Vine and Arnulf Christl)
* Mapbender: [[Mapbender Incubation Progress]] | [[Mapbender Provenance Review]] (Entered 2006-02-04, Graduated 2006-07-15, Mentor: Paul Spencer)
* MapFish: [[MapFish Incubation Status]] | [[MapFish Provenance Review]] (Entered 2009-11-09, Graduated 2011-09-01, Mentor: Gary Sherman)
* MapGuide Open: [[MapGuide Incubation Status]] | [[MapGuide Provenance Review]] (Entered 2006-02-04, Graduated 2007-03-02, Mentor: Daniel Morissette)
* MapServer: [[MapServer incubation status]] | [[MapServer Provenance Review]] (Entered 2006-02-04, Graduated 2008-12-16, Mentor: Chris Holmes)
* Marble: [[Marble Incubation Status]] | [[Marble Code Provenance Review]] | [[Marble Graduation Checklist]] (Entered 2012-10-12, Graduated 2013-10-17, Mentor: Arnulf Christl)
* OpenLayers: [[OpenLayers Incubation Status]] | [[OpenLayers Provenance Review]] (Entered 2006-11-10, Graduated 2007-11-16, Mentor: Howard Butler)
* Orfeo ToolBox (OTB): [[OTB Project Incubation Status]] | [[OTB Code Provenance Review]] (Entered 2009-10-26, Graduated 2017-07-20, Mentor: Landon Blake)
* OSGeoLive: [[Live_GIS_Incubation_Graduation_Checklist|Graduation Checklist]] (Entered 2017-10-05, Graduated 2018-04-14, Mentor: Jody Garnett)
* pgRouting: [https://github.com/pgRouting/pgrouting/wiki/Project-Graduation-Checklist Project Graduation Checklist] (Entered: 2022-07, Graduated 2024-11, Mentor: Angelos Tzotsos)
* PostGIS: [[PostGIS Incubation Status]] | [[PostGIS Provenance Review]] (Entered 2009-08-06, Graduated 2012-06-07, Mentor: Arnulf Christl)
* PROJ: [https://trac.osgeo.org/osgeo/ticket/2268 Incubation Application] | [https://github.com/OSGeo/PROJ/wiki/Incubation-checklist PROJ Graduation Checklist] (Entered 2019-05-04, Graduated 2019-11-26, Mentor: Michael Smith )
* pycsw: [https://github.com/geopython/pycsw/wiki/Project-Status Incubation Status] | [https://github.com/geopython/pycsw/wiki/Project-Graduation-Checklist Graduation Checklist] | [https://github.com/geopython/pycsw/wiki/pycsw-Provenance-Review Provenance Review] (Entered 2013-03-30, Graduated 2015-03-05, Mentor: Jeff McKenna)
* pygeoapi: [https://github.com/geopython/pygeoapi/wiki/OSGeoIncubation-ProjectStatus Incubation Status] | [https://github.com/geopython/pygeoapi/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/geopython/pygeoapi/wiki/ProjectProvenanceReview Provenance Review] (Entered 2021-11-03, Graduated 2022-08-21, Mentor: Michael Smith)
* PyWPS: [[PyWPS|Incubation Status]] | [https://github.com/geopython/pywps/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/geopython/pywps/wiki/ProjectProvenanceReview Provenance Review] (Entered 2009-02-27, Graduated 2018-04-11, Mentor: Tom Kralidis)
* OSSIM: [[OSSIM incubation status]] | [http://trac.osgeo.org/ossim/wiki/ossimprovenance OSSIM Provenance Review] (Entered 2006-02-27, Graduated 2009-06-02, Mentor: Richard Gould)
* QGIS: [[QGIS Incubation Status]] | [[QGIS Provenance Review]] (Entered 2007-03-02, Graduated 2008-03-14, Mentor: Bob Bray)
* ZOO-Project: [https://github.com/ZOO-Project/ZOO-Project/wiki/OSGeoIncubationStatus Incubation Status] | [https://github.com/ZOO-Project/ZOO-Project/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/ZOO-Project/ZOO-Project/wiki/ProvenanceReview Provenance Review] (Entered 2011-11-09, Graduated 2023-06-21, Mentors: Tom Kralidis, Dimitris Kotzinos, Frank Warmerdam)

The initial projects to go through the incubation process helped define what is required. The above pages tracked the progress (and capture the experience) of these projects.

== Withdrawn ==

The following projects did not complete incubation:

* '''[http://www.rasdaman.org rasdaman]''': : [[ rasdaman Incubation Status ]] | [http://rasdaman.org/wiki/OSGeoCodeProvenance Code Provenance] | [http://www.rasdaman.org/wiki/OSGeoIncubationChecklist Incubation Checklist] (Mentor [[User: Bruce.bannerman|Bruce Bannerman]] )
* '''[http://trac.osgeo.org/metacrs/ MetaCRS]''': :: [[MetaCRS Incubation Status]] (Mentor: Daniel Morissette)

== Committee Operation ==

The incubation committee operates within the OSGeo committee guidelines, operating in a close working relationship with the OSGeo board as reflected in our responsibilities above.

* Voting members: Voting members are maintained on this page as outlined below. This committee is volunteer based with committee member ship driven by email request to be added or removed. Inactive members (see below) are removed as needed to preserve committee function.
* Project mentors: Have volunteered to represent our organization at a personal level as a guest on the projects email list and meetings. Project mentors are responsible for recommending when a project is ready for graduation based on this first hand experience. For more information see mentor guidelines.
* Committee chair: Committee chair appointed by motion, result forward to the board for approval and recognition as an officer of the foundation. Committee chair is responsible for operation of the committee.
* Communication: This committee operates on the [https://lists.osgeo.org/mailman/listinfo/incubator incubator mailing list]. With the occasional breakout IRC meeting, hangout, or phone call to explore specific issues.
* Decision making: Decision making is performed by email motion. Motions are held open for a two week period. Each motion requires a 50% quorum within the two week period. Voting consists of +1 (approval), +0 (slight agreement), -0 (slight disagreement), -1 (against). The committee chair is responsible for replying to the email thread with voting results and motion resolution.
** Email motions should be clearly worded and have a subject line “Motion:”.
** Motions are held open for a two week period to give everyone a chance to respond, this accounts for volunteers that are only available on weekends.
** At discretion of the chair a motion may be held open longer than two weeks.
** If a motion does not gather a 50% response within a two week period we may need to revisit our active member list – removing members that have not voted within the last year.
** Voting +0 and -0 are a good way to reach quorum for volunteers that have not had a chance to follow the discussion, or to abstain if you feel uncomfortable voting on a topic.
** There is no veto in the incubation committee, but we tend to respect -1 votes and withdraw motions that are divisive. It is noted that when reviewing graduation checklists -1 votes tend to track outstanding issues that are then addressed within the voting period.
* Independence: Our mandate is focused on providing to the OSGeo board as outlined above.

Example email:

Subject: motion: accept project x as a community project

The following motion has been made by Firstname Lastname:

Motion to accept project x as an community project.

This motion is held open for two weeks closing MONTH DAY, requiring 50% quorum,
from the following incubation committee members:

* LINE BY LINE BULLETED LIST OF CURRENT MEMBERS

A subsequent email will be sent when the motion is completed, either by the elapsed time period, or by unanimous consent before the closing period.

=== Committee Members ===

'''Volunteers Welcome''' - if you would like to take part we are always looking for new members, sign up to the [https://lists.osgeo.org/mailman/listinfo/incubator email list], and introduce yourself to volunteer.

Current members:

* [[User:Kalxas|Angelos Tzotsos]]
* Arnulf Christl
* Bob (CI-StPaul) Basques
* [[User:darkblueb|Brian M Hamlin]]
* Daniel Morissette
* Dimitris Kotzinos
* Frank Warmerdam
* [[User:Jive|Jody Garnett]] (chair)
* Michael Smith
* [[User:Nickbearman|Nick Bearman]]
* [[User:Robe|Regina Obe]]
* Steve Lime
* Tom Kralidis

'''Thank you''' - we ask that volunteers remain active, joining the discussion and voting on the email list. If you are unable to take part please send us an email. As volunteers we understand that life can get in the way of advocacy – you are welcome to rejoin at any time. We will also retire inactive members as needed. Prior members:

* Bruce Bannerman
* Landon Blake
* Robert Bray
* Howard Butler
* [[User:JoCook|Jo Cook]]
* Chris Holmes
* Julien-Samuel Lacroix
* Mark Lucas
* Judit Mays
* Jeff McKenna
* Markus Neteler
* Markus Schneider
* Cameron Shorter
* Paul Spencer
* Jeroen Ticheler
* Norman Vine

=== Documents ===

* Official incubator public web page is at: https://www.osgeo.org/about/committees/incubation/ (with members list).
* [[OSGeo_Community_Projects]]
* [[Incubation FAQ]]
* [[Official_IncCom_Documents]]
* Incubation process docs: https://www.osgeo.org/about/committees/incubation/incubation-process/ (original [[Official_IncCom_Documents|wiki draft documents]])
* [[Incubation Badges]]

Draft or discussion documents
* Draft [[Commiter Responsibilities Guidelines]]
* Draft [[5-star-rating]] - discussion about more fine incubation procedure
* OSGeo Distribution and Committer [[http://www.osgeo.org/content/foundation/legal/licenses.html licenses] which can be used as is, or as an example for projects starting off with participatory open source.
** Geotools Copyright Assignment ([http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf pdf], [http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.odt odt]) - previous example
** [[Project Copyright Assignment]] - previous example
* [[Contributor Agreement]] and FAQ
* [[Incubation Phases]] proposal

Document Refresh 2014
* [[Project Graduation Checklist]]

References:
* [[Project Infrastructure Migration]]
* [http://producingoss.com/html-chunk/index.html Producing OSS] - by Karl Fogel - an excellent primer on running an FOSS project.

Reports:
* [[Incubation Committee Report 2012]]
* [[Incubation Committee Report 2011]]

Trac:
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&order=priority Open Incubator Trac Issues]
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&keywords=%7Eapplication&order=priority Pending Incubation Applications]

== Meetings and Reports ==
Meetings are scheduled via [http://lists.osgeo.org/mailman/listinfo/incubator Mailing List] and take place via [[Getting_Started#Jump_on_IRC | IRC]] at the times specified in the [[Foundation Calendar]].
* [[IncCom Meeting1|First Meeting]] - March 13th 2006
* [[IncCom Meeting2|Second Meeting]] - March 20th 2006
* [[IncCom Meeting3|Third Meeting]] - March 27th 2006
* [[IncCom Meeting4|Fourth Meeting]] - April 10th 2006
* [[IncCom Meeting5|Fifth Meeting]] - April 24th 2006
* [[IncCom Meeting6|Sixth Meeting]] - June 19th 2006
* [[IncCom Meeting7|Seventh Meeting]] - August 7th 2006
* [[IncCom Meeting8|Eighth Meeting]] - October 30th 2006
* [[IncCom Meeting9|Nineth Meeting]] - February 12th 2007
* [[IncCom Meeting10|Tenth Meeting]] - June 11th 2007
* [[IncCom Meeting11|Eleventh Meeting]] - October 29th 2007
* [[IncCom Meeting12|Twelfth Meeting]] - September 8th 2008
* [[IncCom Meeting13|Thirteenth Meeting]] - October 29th 2009
* [[IncCom Meeting14|Fourteenth Meeting]] - March 1th 2010
* [[IncCom Meeting15]] - Nov 21 2011
* [[IncCom Meeting16]] - Jan 17 2012
* [[IncCom Meeting17]] - March 19 2012
* [[IncCom Meeting18]] - May 21 2012
* [[IncCom Meeting19]] - July 23 2012
* [[IncCom Meeting20]] - Sep 24 2012
* [[IncCom Meeting21]] - Feb 18 2013
* [[IncCom Report22]] - 2013 Q2
* [[IncCom Report23]] - 2013 Q3
* [[IncCom Report24]] - 2014 Q1
* [[Fall 2014 Committee Report for OSGeo Journal]]

[[Category:Incubation]]
[[Category:Committees]]

Incubation Committee

2026-02-13T23:41:44Z

Darkblueb: /* TorchGeo */

The project incubation committee is responsible for overseeing the incubation process for new projects entering the foundation. The incubation committee provides resources to assist new projects to reach full membership, and makes recommendations to the board when they feel projects have completed incubation.

== About the Incubation Committee ==

The OSGeo Incubation Committee is an open source advocacy and outreach activity welcoming projects and development teams to our foundation.

The committee is responsible for:

# [https://www.osgeo.org/projects/ OSGeo project website] review
#* Reviewing applications to list projects on the OSGeo website
#* Preparing and recommend criteria and review process for projects to be listed on the OSGeo website
# [https://www.osgeo.org/projects/#community Community project program]
#* Reviewing community project applications and recommending projects to the board to be accepted as community projects
#* Reporting on the status of projects in the community project program to the board periodically (via Chair)
#* Preparing and recommending community project process and criteria to the board.
#* See [[OSGeo_Community_Projects]] for more information
# [https://www.osgeo.org/about/committees/incubation/incubation-process/ OSGeo Incubation process]
#* Reviewing applications for incubation and making recommendations to the board on projects that should be admitted into incubation.
#* Appointing [https://www.osgeo.org/about/committees/incubation/mentor/ mentors] for incubation projects.
#* Reviewing progress of projects against incubation requirements, and recommending projects for full project status to the board, when deemed appropriate.
#* Reporting on the status of projects in incubation and the incubation process to the board periodically (via Chair).
#* Preparing and recommending incubation process and criteria to the board.

The OSGeo incubation committee is not responsible for graduated OSGeo Projects. Graduated OSGeo projects are recognized as a committee who report directly to the board via their project officer.

== Supporting project teams ==

If you would like your software project to listed on the website, or apply to become an OSGeo Community project, please send a description of your project to the OSGeo Incubation Committee Mailing List.

We look forward to helping you!

{| class="wikitable"
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Responsibility
! scope="col" width="155" style="text-align: center; font-weight: bold;" | Website Listing
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Community
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Project
|-
| Geospatial 
- README or project description
| X
| X
| X
|-
| Geospatial 
- User guide or quickstart
|
| X
| X
|-
| Free or Open Source License 
- See LICENSE.md
| X
| X
| X
|-
| Free or Open Source License 
- Check headers
|
| X
| X
|-
| Free or Open Source License 
- Providence Review
|
|
| X
|-
| Participatory 
- See CONTRIBUTING.md
| X
| X
| X
|-
| Participatory 
- History of pull requests or patches
|
| X
| X
|-
| Participatory 
- CODE_OF_CONDUCT.md
|
| X
| X
|-
| Open Community 
- communication channel 
- decision making process
|
|
| X
|-
| Active Healthy Community 
- user and developer collaboration 
- long term viability
|
|
| X
|-
| Development Process 
- version control 
- issue tracker 
- leadership open to new members 
- transparent decision making
|
|
| X
|-
| Documentation 
- user documentation 
- developer documentation
|
|
| X
|-
| Release Procedure 
- release process 
- documented testing process 
|
|
| X
|-
| style="font-weight: bold;" | Foundation Resources
! scope="col" width="155" style="text-align: center; font-weight: bold;" | Website Listing
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Community
! scope="col" width="155" style="text-align: center; font-weight: bold;" | OSGeo Project
|-
| website project list
| X
| X
| X
|-
| website choose-a-project
| X
| X
| X
|-
| OSGeo Live
| X
| X
| X
|-
| Marketing Collateral
|
| X
| X
|-
| Representation
|
|
| project officer
|-
| infrastructure and facilities
|
| X
| X
|-
| promotion & marketing
|
| X
| X
|-
| budget
|
| osgeo board
| project budget
|-
| fundraising
|
| X
| X
|}

=== Financial support ===

The incubation process establishes a project as a full fledged OSGeo committee, with a project project officer, with direct access to OSGeo treasurer, and reporting to the board during annual general meeting.

While Community projects are not recognized as an independent committee, the OSGeo board maintains an "OSGeo Community" initiative with budget to support your activities. Attend one of the OSGeo board monthly meetings, or ask on the board mailing list, if your project has an activity that can benefit from financial support.

For more information see [https://github.com/OSGeo/osgeo/blob/master/board/documents/osgeo_financial_guidance.pdf osgeo_financial_guidence.pdf]

=== Branding ===

{| class="wikitable"
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Community
! scope="col" width="310" style="text-align: center; font-weight: bold;" | Project
|-
| [[File:OSGeo community.png|frameless|OSGeo Community Project]]
| [[File:OSGeo project.png|frameless|OSGeo Project]]
|}

== Step 1: Add OSGeo Website Project Page ==

To be listed on the OSGeo website:

# Be geospatial
#* Confirm by checking README or project description
# Have a free license or open source license
#* The license must be OSI approved
# Welcome participation and new contributors.
#* We look for a clear contribution policy

If you have questions about the above, or would like guidance on setting up your open source project, please reach out to us.

Here is an example email request ([https://lists.osgeo.org/mailman/listinfo/incubator mailing list sign up required]):

: '''to''': incubator@lists.osgeo.org
:
: '''subject''': water topology api
:
: '''message''':
:
:: Incubation committee:
::
:: I would like to ask permission to to list my project "water topology api" on the OSGeo website in order to share my work with more people!
::
:: The project is built on PostGIS topology providing a REST API to help with watershed analysis and maintenance.
::
:: The repository is located here: https://gitlab.host.net/watertopo/ released using GPL license.
::
:: My OSGeo userid is "atlantis" and I will need permission to create a project page.
::
:: Thanks!

== Step 2: Join OSGeo Community Projects Initiative ==

Projects applying to the *OSGeo Community Projects* initiative are asked to:

# Be geospatial
#* Confirm by checking README or project description
#* project page on the osgeo website
#* We ask projects have some user documentation, for example an OSGeo Live quickstart
# Have a free license or an open source license.
#* The license must be OSI approved
#* We ask that the project team check the file headers and double check the license has been appropriately applied
# Welcome participation and new contributors.
#* We look for a clear contribution policy
#* We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
#* Projects are required to have a code of conduct

OSGeo provides [https://www.osgeo.org/code_of_conduct/ code of conduct guidance], many projects selecting [https://www.contributor-covenant.org/ contribution covenant]).

OSGeo [[Community Projects]] can take part in the incubation committee for guidance on open source use, setting up project governance, promoting the project, and building the project community. We look forward to working with you. For sensitive topics (patents, copyright, trademarks, and license) you wish to attend a video meeting.

Here is an example email request ([https://lists.osgeo.org/mailman/listinfo/incubator mailing list sign up required]):

: '''to''': incubator@lists.osgeo.org
:
: '''subject''': water topology community project application
:
: '''message''':
:
:: Incubation committee:
::
:: The Water Topology project would like to apply to join the OSGeo community program. We recently re-branded to just "water topology" to reflect client libraries being include in our project. The project provides web services built on PostGIS topology to help with watershed analysis and maintenance.
::
:: The osgeo project page is available here: https://osgeo.org/projects/watertopology and our user guide is located at https://watertopo.gitlab.host.net/ .
::
:: The repository remains at https://gitlab.host.net/watertopo/ with GPL license, contribution policy and code of conduct. We have checked our source code to ensure GPL license has been correctly applied. Our issue tracker is active, and we have received a number of merge-requests.
::
:: Thank you for your consideration and we look forward to your questions!

== Step 3: Incubation process and Graduation ==

The *OSGeo Project* designation is intended to recognize established projects with a diverse community of developers and users with a proven track record.

To be recognized as an *OSGeo Project* a project team applies for the OSGeo incubation program. Successful projects are teamed up with an experienced open source mentor to help answer questions, obtain legal council, and help guide work on transparency and community development as required.

Although incubation is a lot of work, this is opportunity for project teams to grow and improve and be publicly recognized for their accomplishment.

To be recognized as an *OSGeo Project* we ask that project teams excel in each of areas mentioned above, see [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.pdf graduation checklist] ( [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.md markdown] ) or the comparison table on this page for more detail.

The OSGeo incubation process takes place in three stages:

# Initial Application
## Application request
## Mentor volunteer
# Incubator
## Project Status: project details, and a few resourcing questions for the system admin committee (see [[Project Status Template]]).
## Provenance Review: project team check to ensure the project is open source and has permission to distribute its source code.
## Project team and mentor work on [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.pdf graduation checklist] ( [https://github.com/OSGeo/osgeo/blob/master/incubation/documents/graduation_checklist.md markdown] ) priorities
# Graduation
## Mentor recommends project for graduation with motion to the incubation committee
## Committee chair informs the OSGeo board, who appoints the project team as a newly formed OSGeo committee

== Incubation ==

The following projects are currently in OSGeo incubation. The links provided are used to track the progress of incubation projects and are used by the developer team (and OSGeo mentor). In many cases the links will take you to a project specific wiki or website in order to be closer to their target community.

When projects have completed the graduation checklist their mentor will recommend them to the Incubation committee for graduation.

=== IstSOS ===

'''IstSOS''': http://wiki.osgeo.org/wiki/IstSOS
# [[IstSOS Provenance Review]]
# [[IstSOS Incubation Status]]
# ''Mentor'': [[User: Jeff_McKenna|Jeff McKenna]]

=== Opticks ===

'''Opticks''': http://opticks.org
# [[Opticks Incubation Status]]
# no provenance review provided
# [[Opticks Incubation Checklist]]
# ''Mentor'': [[User: Mark_Lucas|Mark Lucas]]

=== Oskari ===

'''Oskari''': http://oskari.org/
# [[Oskari Incubation Application]]
# [[Oskari Incubation Status]]
# [https://github.com/oskariorg/oskari-docs/wiki/Oskari-Incubation-Checklist Oskari Graduation Checklist]
# ''Mentor'': [[Arnulf Christl]]

=== TEAM Engine ===

'''TEAM Engine''': http://teamengine.sourceforge.net
# [https://trac.osgeo.org/osgeo/ticket/1016 Incubation Application] from 2012
# [https://github.com/opengeospatial/teamengine/wiki/OSGEO-Graduation TEAM Engine Incubation Checklist]
# ''Mentor'': [[User: Jive|Jody Garnett]]

=== TorchGeo ===

'''TorchGeo''': https://www.osgeo.org/projects/torchgeo/
# [[TorchGeo Provenance Review]] https://wiki.osgeo.org/wiki/TorchGeo_Code_Provenance
# [[TorchGeo Incubation Status]] https://trac.osgeo.org/osgeo/ticket/3519
# ''Mentor'': [[User:darkblueb|Brian M Hamlin]]

== Graduated ==

The following status and provenance documents are for historical purposes, and are no longer actively maintained.

* Community Mapbuilder: [[Community Mapbuilder Incubation Progress]] | [[Community Mapbuilder Provenance Review]] (Entered 2006-02-04, Graduated 2006-07-14, Mentor: Steve Lime)
* deegree: [[deegree Incubation Status]] | [[deegree Provenance Review]] (Entered: 2008-06-09, Graduated 2010-02-04, Mentor: Jody Garnett)
* FDO: [[FDO Incubation Status]] | [[FDO Provenance Review]] (Entered 2007-03-06, Graduated 2008-02-08, Mentor: Daniel Morissette)
* GEOS: [[GEOS Incubation Status]] | [[GEOS Provenance Review]] (Entered 2007-11-02, Graduated 2012-04-28, Mentor: Frank Warmerdam)
* GDAL/OGR: [[GDAL Incubation Progress]] | [[GDAL Provenance Review]] (Entered 2006-02-04, Graduated 2008-02-08, Mentor: Paul Spencer)
* Geomajas: [[GeoMajas Incubation Status]] | [[GeoMajas Provenance Review]] (Entered 2010-03-04, Graduated 2010-11-22, Mentor: Paul Spencer)
* GeoNetwork: [[GeoNetwork Incubation Status]] | [[GeoNetwork Provenance Review]] (Entered 2006-11-10, Graduated 2008-06-21, Mentor: Jody Garnett)
* GeoNode: [[GeoNode Incubation Status]] [[GeoNode Provenance Review]] [[GeoNode Incubation Checklist]] (Entered 2015-08-13, Graduated 2016-11-09, Mentor: David Bitner)
* GeoMOOSE: [[GeoMoose Incubation Status]] | [[GeoMoose Provenance Review]] | [[GeoMoose Incubation Checklist]] (Entered 2011-12-08, Graduated 2013-04-19, Mentor: Jody Garnett)
* GeoTools: [[GeoTools Incubation Progress]] | [[GeoTools Provenance Review]] (Entered 2006-02-27, Graduated 2008-07-18, Mentor: Cameron Shorter)
* GeoServer: [http://old.geoserver.org/OSGEO%20incubation%20questionnaire.html Incubation Questionnaire] | [http://old.geoserver.org/GeoServer%20Incubation%20Status.html Incubation Status] | [https://github.com/geoserver/geoserver/wiki/GeoServer-Provenance-Review Provenance Review] | [https://github.com/geoserver/geoserver/wiki/GeoServer-Incubation-Checklist Incubation Checklist] | [[Geoserver Mentor Notes]] (Entered 2009-11-05, Graduated 2013-03-15, Mentor: Landon Blake)
* gvSIG: [[gvSIG Incubation Status]] | [[gvSIG Provenance Review]] | [[gvSIG Incubation Checklist]] (Entered 2007-09-07, Graduated 2015-11-26, Mentor: Dimitris Kotzinos)
* GRASS: [[GRASS Incubation Progress]] | [[GRASS Provenance Review]] (Entered 2006-02-27, Graduated 2008-02-08, Mentor: Norman Vine and Arnulf Christl)
* Mapbender: [[Mapbender Incubation Progress]] | [[Mapbender Provenance Review]] (Entered 2006-02-04, Graduated 2006-07-15, Mentor: Paul Spencer)
* MapFish: [[MapFish Incubation Status]] | [[MapFish Provenance Review]] (Entered 2009-11-09, Graduated 2011-09-01, Mentor: Gary Sherman)
* MapGuide Open: [[MapGuide Incubation Status]] | [[MapGuide Provenance Review]] (Entered 2006-02-04, Graduated 2007-03-02, Mentor: Daniel Morissette)
* MapServer: [[MapServer incubation status]] | [[MapServer Provenance Review]] (Entered 2006-02-04, Graduated 2008-12-16, Mentor: Chris Holmes)
* Marble: [[Marble Incubation Status]] | [[Marble Code Provenance Review]] | [[Marble Graduation Checklist]] (Entered 2012-10-12, Graduated 2013-10-17, Mentor: Arnulf Christl)
* OpenLayers: [[OpenLayers Incubation Status]] | [[OpenLayers Provenance Review]] (Entered 2006-11-10, Graduated 2007-11-16, Mentor: Howard Butler)
* Orfeo ToolBox (OTB): [[OTB Project Incubation Status]] | [[OTB Code Provenance Review]] (Entered 2009-10-26, Graduated 2017-07-20, Mentor: Landon Blake)
* OSGeoLive: [[Live_GIS_Incubation_Graduation_Checklist|Graduation Checklist]] (Entered 2017-10-05, Graduated 2018-04-14, Mentor: Jody Garnett)
* pgRouting: [https://github.com/pgRouting/pgrouting/wiki/Project-Graduation-Checklist Project Graduation Checklist] (Entered: 2022-07, Graduated 2024-11, Mentor: Angelos Tzotsos)
* PostGIS: [[PostGIS Incubation Status]] | [[PostGIS Provenance Review]] (Entered 2009-08-06, Graduated 2012-06-07, Mentor: Arnulf Christl)
* PROJ: [https://trac.osgeo.org/osgeo/ticket/2268 Incubation Application] | [https://github.com/OSGeo/PROJ/wiki/Incubation-checklist PROJ Graduation Checklist] (Entered 2019-05-04, Graduated 2019-11-26, Mentor: Michael Smith )
* pycsw: [https://github.com/geopython/pycsw/wiki/Project-Status Incubation Status] | [https://github.com/geopython/pycsw/wiki/Project-Graduation-Checklist Graduation Checklist] | [https://github.com/geopython/pycsw/wiki/pycsw-Provenance-Review Provenance Review] (Entered 2013-03-30, Graduated 2015-03-05, Mentor: Jeff McKenna)
* pygeoapi: [https://github.com/geopython/pygeoapi/wiki/OSGeoIncubation-ProjectStatus Incubation Status] | [https://github.com/geopython/pygeoapi/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/geopython/pygeoapi/wiki/ProjectProvenanceReview Provenance Review] (Entered 2021-11-03, Graduated 2022-08-21, Mentor: Michael Smith)
* PyWPS: [[PyWPS|Incubation Status]] | [https://github.com/geopython/pywps/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/geopython/pywps/wiki/ProjectProvenanceReview Provenance Review] (Entered 2009-02-27, Graduated 2018-04-11, Mentor: Tom Kralidis)
* OSSIM: [[OSSIM incubation status]] | [http://trac.osgeo.org/ossim/wiki/ossimprovenance OSSIM Provenance Review] (Entered 2006-02-27, Graduated 2009-06-02, Mentor: Richard Gould)
* QGIS: [[QGIS Incubation Status]] | [[QGIS Provenance Review]] (Entered 2007-03-02, Graduated 2008-03-14, Mentor: Bob Bray)
* ZOO-Project: [https://github.com/ZOO-Project/ZOO-Project/wiki/OSGeoIncubationStatus Incubation Status] | [https://github.com/ZOO-Project/ZOO-Project/wiki/ProjectGraduationChecklist Graduation Checklist] | [https://github.com/ZOO-Project/ZOO-Project/wiki/ProvenanceReview Provenance Review] (Entered 2011-11-09, Graduated 2023-06-21, Mentors: Tom Kralidis, Dimitris Kotzinos, Frank Warmerdam)

The initial projects to go through the incubation process helped define what is required. The above pages tracked the progress (and capture the experience) of these projects.

== Withdrawn ==

The following projects did not complete incubation:

* '''[http://www.rasdaman.org rasdaman]''': : [[ rasdaman Incubation Status ]] | [http://rasdaman.org/wiki/OSGeoCodeProvenance Code Provenance] | [http://www.rasdaman.org/wiki/OSGeoIncubationChecklist Incubation Checklist] (Mentor [[User: Bruce.bannerman|Bruce Bannerman]] )
* '''[http://trac.osgeo.org/metacrs/ MetaCRS]''': :: [[MetaCRS Incubation Status]] (Mentor: Daniel Morissette)

== Committee Operation ==

The incubation committee operates within the OSGeo committee guidelines, operating in a close working relationship with the OSGeo board as reflected in our responsibilities above.

* Voting members: Voting members are maintained on this page as outlined below. This committee is volunteer based with committee member ship driven by email request to be added or removed. Inactive members (see below) are removed as needed to preserve committee function.
* Project mentors: Have volunteered to represent our organization at a personal level as a guest on the projects email list and meetings. Project mentors are responsible for recommending when a project is ready for graduation based on this first hand experience. For more information see mentor guidelines.
* Committee chair: Committee chair appointed by motion, result forward to the board for approval and recognition as an officer of the foundation. Committee chair is responsible for operation of the committee.
* Communication: This committee operates on the [https://lists.osgeo.org/mailman/listinfo/incubator incubator mailing list]. With the occasional breakout IRC meeting, hangout, or phone call to explore specific issues.
* Decision making: Decision making is performed by email motion. Motions are held open for a two week period. Each motion requires a 50% quorum within the two week period. Voting consists of +1 (approval), +0 (slight agreement), -0 (slight disagreement), -1 (against). The committee chair is responsible for replying to the email thread with voting results and motion resolution.
** Email motions should be clearly worded and have a subject line “Motion:”.
** Motions are held open for a two week period to give everyone a chance to respond, this accounts for volunteers that are only available on weekends.
** At discretion of the chair a motion may be held open longer than two weeks.
** If a motion does not gather a 50% response within a two week period we may need to revisit our active member list – removing members that have not voted within the last year.
** Voting +0 and -0 are a good way to reach quorum for volunteers that have not had a chance to follow the discussion, or to abstain if you feel uncomfortable voting on a topic.
** There is no veto in the incubation committee, but we tend to respect -1 votes and withdraw motions that are divisive. It is noted that when reviewing graduation checklists -1 votes tend to track outstanding issues that are then addressed within the voting period.
* Independence: Our mandate is focused on providing to the OSGeo board as outlined above.

Example email:

Subject: motion: accept project x as a community project

The following motion has been made by Firstname Lastname:

Motion to accept project x as an community project.

This motion is held open for two weeks closing MONTH DAY, requiring 50% quorum,
from the following incubation committee members:

* LINE BY LINE BULLETED LIST OF CURRENT MEMBERS

A subsequent email will be sent when the motion is completed, either by the elapsed time period, or by unanimous consent before the closing period.

=== Committee Members ===

'''Volunteers Welcome''' - if you would like to take part we are always looking for new members, sign up to the [https://lists.osgeo.org/mailman/listinfo/incubator email list], and introduce yourself to volunteer.

Current members:

* [[User:Kalxas|Angelos Tzotsos]]
* Arnulf Christl
* Bob (CI-StPaul) Basques
* [[User:darkblueb|Brian M Hamlin]]
* Daniel Morissette
* Dimitris Kotzinos
* Frank Warmerdam
* [[User:Jive|Jody Garnett]] (chair)
* Michael Smith
* [[User:Nickbearman|Nick Bearman]]
* [[User:Robe|Regina Obe]]
* Steve Lime
* Tom Kralidis

'''Thank you''' - we ask that volunteers remain active, joining the discussion and voting on the email list. If you are unable to take part please send us an email. As volunteers we understand that life can get in the way of advocacy – you are welcome to rejoin at any time. We will also retire inactive members as needed. Prior members:

* Bruce Bannerman
* Landon Blake
* Robert Bray
* Howard Butler
* [[User:JoCook|Jo Cook]]
* Chris Holmes
* Julien-Samuel Lacroix
* Mark Lucas
* Judit Mays
* Jeff McKenna
* Markus Neteler
* Markus Schneider
* Cameron Shorter
* Paul Spencer
* Jeroen Ticheler
* Norman Vine

=== Documents ===

* Official incubator public web page is at: https://www.osgeo.org/about/committees/incubation/ (with members list).
* [[OSGeo_Community_Projects]]
* [[Incubation FAQ]]
* [[Official_IncCom_Documents]]
* Incubation process docs: https://www.osgeo.org/about/committees/incubation/incubation-process/ (original [[Official_IncCom_Documents|wiki draft documents]])
* [[Incubation Badges]]

Draft or discussion documents
* Draft [[Commiter Responsibilities Guidelines]]
* Draft [[5-star-rating]] - discussion about more fine incubation procedure
* OSGeo Distribution and Committer [[http://www.osgeo.org/content/foundation/legal/licenses.html licenses] which can be used as is, or as an example for projects starting off with participatory open source.
** Geotools Copyright Assignment ([http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf pdf], [http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.odt odt]) - previous example
** [[Project Copyright Assignment]] - previous example
* [[Contributor Agreement]] and FAQ
* [[Incubation Phases]] proposal

Document Refresh 2014
* [[Project Graduation Checklist]]

References:
* [[Project Infrastructure Migration]]
* [http://producingoss.com/html-chunk/index.html Producing OSS] - by Karl Fogel - an excellent primer on running an FOSS project.

Reports:
* [[Incubation Committee Report 2012]]
* [[Incubation Committee Report 2011]]

Trac:
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&order=priority Open Incubator Trac Issues]
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&keywords=%7Eapplication&order=priority Pending Incubation Applications]

== Meetings and Reports ==
Meetings are scheduled via [http://lists.osgeo.org/mailman/listinfo/incubator Mailing List] and take place via [[Getting_Started#Jump_on_IRC | IRC]] at the times specified in the [[Foundation Calendar]].
* [[IncCom Meeting1|First Meeting]] - March 13th 2006
* [[IncCom Meeting2|Second Meeting]] - March 20th 2006
* [[IncCom Meeting3|Third Meeting]] - March 27th 2006
* [[IncCom Meeting4|Fourth Meeting]] - April 10th 2006
* [[IncCom Meeting5|Fifth Meeting]] - April 24th 2006
* [[IncCom Meeting6|Sixth Meeting]] - June 19th 2006
* [[IncCom Meeting7|Seventh Meeting]] - August 7th 2006
* [[IncCom Meeting8|Eighth Meeting]] - October 30th 2006
* [[IncCom Meeting9|Nineth Meeting]] - February 12th 2007
* [[IncCom Meeting10|Tenth Meeting]] - June 11th 2007
* [[IncCom Meeting11|Eleventh Meeting]] - October 29th 2007
* [[IncCom Meeting12|Twelfth Meeting]] - September 8th 2008
* [[IncCom Meeting13|Thirteenth Meeting]] - October 29th 2009
* [[IncCom Meeting14|Fourteenth Meeting]] - March 1th 2010
* [[IncCom Meeting15]] - Nov 21 2011
* [[IncCom Meeting16]] - Jan 17 2012
* [[IncCom Meeting17]] - March 19 2012
* [[IncCom Meeting18]] - May 21 2012
* [[IncCom Meeting19]] - July 23 2012
* [[IncCom Meeting20]] - Sep 24 2012
* [[IncCom Meeting21]] - Feb 18 2013
* [[IncCom Report22]] - 2013 Q2
* [[IncCom Report23]] - 2013 Q3
* [[IncCom Report24]] - 2014 Q1
* [[Fall 2014 Committee Report for OSGeo Journal]]

[[Category:Incubation]]
[[Category:Committees]]

Talk:TorchGeo Code Provenance

2026-02-03T05:02:55Z

Darkblueb:

'''Note''': AI LLM assistance was employed in the production of this document.

{| class="wikitable"
|+ LLM Engine contributions by operator
|-
! Operator !! Tool !! Model 1 !! Model 2
|-
| '''omniverdi''' || opencode || claude-opus || devstral2-2512
|-
| '''darkblueb''' || ollama local-only || gemma3:12b || qwen3-coder
|}

<pre>
On Mon, Feb 2, 2026 at 8:08 AM Brian M Hamlin via Incubator <incubator@lists.osgeo.org> wrote:

Hello All -

With this email, I am pleased to present to the OSGeo Incubation Committee an OSGeo Project Candidate : TorchGeo [0]. As Project Mentor I have worked closely with the TorchGeo PSC and code base. In my best judgement, I find that TorchGeo is not only a suitable candidate, but in fact a substantial addition to a large set of consequential and significant geospatial software projects of our current era, represented by OSGeo.

The Program Steering Committee (PSC) of TorchGeo is composed of a small but diverse group of committers; the PSC has defined clear standards for code contributions, bugs, features and additions. Due to the unique character of this training and benchmarking environment, many complete teams from more than a hundred institutions worldwide are contributing and active in the project. As a Machine Learning and Artificial Intelligence environment itself, new data LICENSE challenges are present as well.

You will find abundant links and details in the project Application [1] and Code Review [2]. The TorchGeo project release cycle is integrated with OSGeo Planet and news -- special thanks to JSanz.

Please review and cast your vote at your earliest convenience. Questions and other inquiries will be handled on an OSGeo TRAC instance ticket [3]. The voting period shall begin with the date of this email, and scheduled to conclude in 14 days hence.

Special gratitude on this important day goes out to the OSGeo Systems Administration Team for TRAC, MediaWiki, email and support infrastructure

signed --Brian M Hamlin / MAPLABS / TorchGeo Project Mentor on behalf of #osgeo

##-----------------------------------------------------------------------------------------------------------------------

[0] https://www.osgeo.org/projects/torchgeo/

[1] https://trac.osgeo.org/osgeo/wiki/TorchGeo

[2] https://wiki.osgeo.org/wiki/TorchGeo_Code_Provenance

[3] https://trac.osgeo.org/osgeo/ticket/3519

Congrats to team, and thanks for mentoring. I will review this weekend.

- -
Jody Garnett

_______________________________________________
Incubator mailing list
Incubator@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/incubator
</pre>

Talk:TorchGeo Code Provenance

2026-02-03T05:01:51Z

Darkblueb:

'''Note''': AI LLM assistance was employed in the production of this document.

{| class="wikitable"
|+ LLM Engine contributions by operator
|-
! Operator !! Tool !! Model 1 !! Model 2
|-
| '''omniverdi''' || opencode || claude-opus || devstral2-2512
|-
| '''darkblueb''' || ollama local-only || gemma3:12b || qwen3-coder
|}

<pre>
Congrats to team, and thanks for mentoring. I will review this weekend.

- -
Jody Garnett

On Mon, Feb 2, 2026 at 8:08 AM Brian M Hamlin via Incubator <incubator@lists.osgeo.org> wrote:

Hello All -

With this email, I am pleased to present to the OSGeo Incubation Committee an OSGeo Project Candidate : TorchGeo [0]. As Project Mentor I have worked closely with the TorchGeo PSC and code base. In my best judgement, I find that TorchGeo is not only a suitable candidate, but in fact a substantial addition to a large set of consequential and significant geospatial software projects of our current era, represented by OSGeo.

The Program Steering Committee (PSC) of TorchGeo is composed of a small but diverse group of committers; the PSC has defined clear standards for code contributions, bugs, features and additions. Due to the unique character of this training and benchmarking environment, many complete teams from more than a hundred institutions worldwide are contributing and active in the project. As a Machine Learning and Artificial Intelligence environment itself, new data LICENSE challenges are present as well.

You will find abundant links and details in the project Application [1] and Code Review [2]. The TorchGeo project release cycle is integrated with OSGeo Planet and news -- special thanks to JSanz.

Please review and cast your vote at your earliest convenience. Questions and other inquiries will be handled on an OSGeo TRAC instance ticket [3]. The voting period shall begin with the date of this email, and scheduled to conclude in 14 days hence.

Special gratitude on this important day goes out to the OSGeo Systems Administration Team for TRAC, MediaWiki, email and support infrastructure

signed --Brian M Hamlin / MAPLABS / TorchGeo Project Mentor on behalf of #osgeo

##-----------------------------------------------------------------------------------------------------------------------

[0] https://www.osgeo.org/projects/torchgeo/

[1] https://trac.osgeo.org/osgeo/wiki/TorchGeo

[2] https://wiki.osgeo.org/wiki/TorchGeo_Code_Provenance

[3] https://trac.osgeo.org/osgeo/ticket/3519

_______________________________________________
Incubator mailing list
Incubator@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/incubator
</pre>

TorchGeo Code Provenance

2026-01-21T04:02:38Z

Darkblueb: /* Code Provenance Review Process */

=Code Provenance Review Process=

TorchGeo project
'''refer : https://www.osgeo.org/about/committees/incubation/graduation/'''

'''Incubation application questionnaire : https://trac.osgeo.org/osgeo/wiki/TorchGeo'''

==Document Status==

{| class="wikitable"
|-
| '''Version:''' || 0.5
|-
| '''Status:''' || Updated
|-
| '''Last Edited:''' || 15 Jan 2026
|}

==Purpose==

Show to "reasonable comfort level" that TorchGeo
does not have improperly contributed code, and that the code is all under the Project license.

Notice: ''It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the OSGeo Incubation Committee to prove there are no problems. However, OSGeo Incubation Committee does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.''

=TorchGeo Provenance Review=

== Project History ==

TorchGeo started as an internship project at Microsoft's AI for Good Lab in 2021, with continued support and funding from the University of Illinois Urbana-Champaign and the National Center for Supercomputing Applications. Since then, TorchGeo has been adopted by a diverse community of researchers from academia, industry, and government research institutions who have contributed to the success of the library. In 2025, we founded a new TorchGeo Organization to manage the TorchGeo Project, with the support of members from the above organizations.

'''Key milestones''':

- '''2021-05-11''': Initial commit (2330aad) by Adam J. Stewart

- '''2021-2024''': Organic growth to 120+ contributors

- '''2025''': Formation of TorchGeo Organization with formal governance structure

- '''2026''': OSGeo incubation application submitted

==Libraries==

All dependencies are external (not bundled in source tree). All licenses are OSI-approved and compatible with MIT.

{| class="wikitable" border="1"
|-
! Library !! License !! Compatible? !! In Core? !! Issues? !! Ok? !! Comments
|-
| einops || MIT || Yes || External || - || Yes || Tensor operations
|-
| geopandas || BSD-3-Clause || Yes || External || - || Yes || Geospatial dataframes
|-
| jsonargparse || MIT || Yes || External || - || Yes || CLI argument parsing
|-
| lightly || MIT || Yes || External || - || Yes || Self-supervised learning
|-
| lightning || Apache-2.0 || Yes || External || - || Yes || Training framework
|-
| matplotlib || PSF || Yes || External || - || Yes || Plotting
|-
| numpy || BSD-3-Clause || Yes || External || - || Yes || Numerical computing
|-
| pandas || BSD-3-Clause || Yes || External || - || Yes || Data manipulation
|-
| pillow || HPND [https://github.com/python-pillow/Pillow/issues/1507 *] / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || External || - || Yes || Image I/O
|-
| pyproj || MIT || Yes || External || - || Yes || Cartographic projections
|-
| rasterio || BSD-3-Clause || Yes || External || - || Yes || Geospatial raster I/O
|-
| segmentation-models-pytorch || MIT || Yes || External || - || Yes || Segmentation architectures
|-
| shapely || BSD-3-Clause || Yes || External || - || Yes || Geometric operations
|-
| timm || Apache-2.0 || Yes || External || - || Yes || Vision model zoo
|-
| torch || BSD-3-Clause || Yes || External || - || Yes || PyTorch core
|-
| torchmetrics || Apache-2.0 || Yes || External || - || Yes || Metrics computation
|-
| torchvision || BSD-3-Clause || Yes || External || - || Yes || Vision utilities
|-
| *kornia || Apache-2.0 || Yes || External || - || Yes || Computer vision ops
|}

==Copyright Holders==
{| class="wikitable" border="1"
|-
! Copyright Holder !! Contact !! Issues !! Comments
|-
| TorchGeo Contributors || N/A (collective) || None || Per LICENSE file
|}

The MIT License file states: "Copyright (c) TorchGeo Contributors."

This is a collective copyright model - individual contributors retain copyright but license under MIT. Historical other markings include:

<pre>
> git gr Copyright | grep -v TorchGeo
torchgeo/models/convlstm.py:# Copyright (c) 2017 Andrea Palazzi
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Copyright (c) Microsoft Corporation.
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/ltae.py:# Copyright (c) 2020 VSainteuf (Vivien Sainte Fare Garnot)
</pre>

== Committers ==
'''Total human contributors:''' 122

'''Total commits:''' 2778 (excluding bots)

'''Top contributors''' (PSC members marked with *):

{| class="wikitable" border="1"
|-
! Committer !! Email !! Affiliation
|-
| Adam J. Stewart * || ajstewart426@gmail.com || TUM / UIUC
|-
| Caleb Robinson * || calebrob6@gmail.com || AI for Good Msft
|-
| Isaac Corley * || isaac.corley@proton.me || Wherobots
|-
| Nils Lehmann * || nils.lehmann24@gmail.com || TUM
|-
| Ashwin Nair * || ashnair0007@gmail.com || Space42
|-
| Anthony Ortiz * || Anthony.Ortiz@microsoft.com || Microsoft
|-
| Robin Cole || robmarkcole@gmail.com || EarthDaily
|-
| Yi Wang || wangyi111@users.noreply.github.com || TUM
|-
| Yi-Chia Chang || yichiac@users.noreply.github.com || UIUC
|-
| Burak Ekim || burakekim@users.noreply.github.com || Bundeswehr Munich
|-
| Blaz Rolih || blaz-r@users.noreply.github.com || ULjubljana, Slovenia
|-
| Maciej Kilian || iejMac@users.noreply.github.com || Stability AI
|-
| Qiusheng Wu || giswqs@gmail.com || UTenn Knoxville
|}

'''Note:''' 122 total contributors. Full list available via <code>git shortlog -sne --all</code>.

==Source Files==
'''Total Python files:''' 557

'''Files with copyright header:''' 557 (100%) - ''after PR #3262 merged''

'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.

{| class="wikitable" border="1"
|-
! File !! License !! Copyright Holder !! Header? !! Issues? !! Ok? !! Comments
|-
| docs/user/metrics/update_timeline.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|-
| tests/data/landcoverai/split.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|}

'''Note:''' PR https://github.com/torchgeo/torchgeo/pull/3262 adds copyright headers to the 2 files that were missing them.

==Further Issues ==
'''Resolved:'''
* Copyright headers added to 2 missing files via PR #3262: https://github.com/torchgeo/torchgeo/pull/3262

* OSGeo does not require a CLA. We ask projects to think about what they want during incubation.

* Contributor agreement confirmed

'''Pending:'''

== TorchGeo Application Questionnaire ==
See the main application questionnaire for additional project details:
https://trac.osgeo.org/osgeo/wiki/TorchGeo

==Process==

'''This Code Provenance Review followed the OSGeo Incubation process:'''
{| class="wikitable"
|-
! Step !! Status !! Date !! Notes
|-
| 1. Create Provenance Review Document || Complete || 06 Jan 2026 || Document created from [https://wiki.osgeo.org/wiki/Provenance_Review_Template Provenance Review Template]
|-
| 2. Library/Component Review || Complete || 08 Jan 2026 || 18 dependencies reviewed, no issues found
|-
| 3. Code Copyright Review || Complete || 08 Jan 2026 || 557 files reviewed, no issues found
|-
| 4. Submit to Project Mentor || Complete || 08 Jan 2026 || Brian M Hamlin (Mentor)
|}
=== Review Summary ===
{| class="wikitable"
|-
| '''Components in source tree:''' || None (all external dependencies)
|-
| '''Problematic licenses:''' || None identified
|-
| '''License conflicts:''' || None identified
|-
| '''Files reviewed:''' || 557 Python files
|-
| '''Files with headers:''' || 557 (100%)
|-
| '''External code derivations:''' || 2 files (both MIT licensed, properly attributed)
|-
| '''Copyright model:''' || Collective ("TorchGeo Contributors")
|}
=== Outstanding Items ===
* '''Pending merge:''' [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262] - adds copyright headers to 2 files
* '''Resolved:''' CLA/DCO status confirmation. OSGeo does not require a CLA. OSGeo asks projects to think about what they want during incubation.
''ajstewart'' -- We used to have a CLA when we were under MSFT. We no longer have any CLA or DCO. We currently have no plans to add one. I know the Linux Foundation requires DCO. Does OSGeo have any requirements?
* '''Resolved:''' a PSC Members Agreement is not required by OSGeo

=== Conclusion ===
'''The TorchGeo codebase passes the Code Provenance Review''' with no blocking issues identified. The project demonstrates good license hygiene and is ready for OSGeo incubation from a code provenance perspective.

==Library/Component Review Process==

'''Review completed:''' 08 Jan 2026
=== 1. Components in Source Tree ===
'''Finding:''' '''None'''
TorchGeo does '''not''' bundle any third-party libraries in its source tree. Unlike projects like GDAL (which includes copies of libtiff, libjpeg, etc.), TorchGeo treats all dependencies as external packages installed via pip/conda.
* No <code>vendor/</code> directory
* No <code>third_party/</code> directory
* No <code>external/</code> directory
* No embedded library copies
This is the recommended approach and simplifies license management.
=== 2. External Dependencies ===
'''Total required dependencies:''' 18
'''All licenses are OSI-approved and compatible with MIT.'''
{| class="wikitable"
|-
! Package !! License !! Compatible? !! Potentially Problematic?
|-
| einops || MIT || Yes || No
|-
| geopandas || BSD-3-Clause || Yes || No
|-
| jsonargparse || MIT || Yes || No
|-
| kornia || Apache-2.0 || Yes || No
|-
| lightly || MIT || Yes || No
|-
| lightning || Apache-2.0 || Yes || No
|-
| matplotlib || PSF (BSD-style) || Yes || No
|-
| numpy || BSD-3-Clause || Yes || No
|-
| pandas || BSD-3-Clause || Yes || No
|-
| pillow || HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || No
|-
| pyproj || MIT || Yes || No
|-
| rasterio || BSD-3-Clause || Yes || No
|-
| segmentation-models-pytorch || MIT || Yes || No
|-
| shapely || BSD-3-Clause || Yes || No
|-
| timm || Apache-2.0 || Yes || No
|-
| torch || BSD-3-Clause || Yes || No
|-
| torchmetrics || Apache-2.0 || Yes || No
|-
| torchvision || BSD-3-Clause || Yes || No
|}

=== 3. License Distribution ===
{| class="wikitable"
|-
! License Type !! Count !! Notes
|-
| MIT || 6 || Permissive, fully compatible
|-
| BSD-3-Clause || 7 || Permissive, fully compatible
|-
| Apache-2.0 || 4 || Permissive, fully compatible
|-
| PSF || 1 || Python Software Foundation, BSD-style
|-
| HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || 1 || Historical Permission Notice and Disclaimer, permissive
|}

=== 4. Potentially Problematic Licenses ===
'''Finding:''' '''None identified'''
* No GPL or LGPL dependencies (no copyleft)
* No AGPL dependencies
* No proprietary or non-free dependencies
* No "viral" license concerns
=== 5. License Conflicts ===
'''Finding:''' '''None identified'''
All dependency licenses are permissive and compatible with each other and with TorchGeo's MIT license. There are no conflicts analogous to GDAL's use of GPL'ed GRASS libraries.
=== 6. Optional Dependencies ===
TorchGeo has optional dependencies for the <code>datasets</code> extra. All use permissive licenses:
{| class="wikitable"
|-
! Package !! License
|-
| h5py || BSD-3-Clause
|-
| laspy || BSD-2-Clause
|-
| netcdf4 || MIT
|-
| opencv-python || Apache-2.0
|-
| pycocotools || BSD-2-Clause
|-
| rioxarray || Apache-2.0
|-
| scikit-image || BSD-3-Clause
|-
| scipy || BSD-3-Clause
|-
| xarray || Apache-2.0
|}
=== 7. Conclusion ===
'''Overall assessment:''' No library/component issues identified
* No bundled code in source tree
* All 18 required dependencies use permissive OSI-approved licenses
* No GPL/copyleft dependencies
* No license conflicts
* Clean dependency model suitable for OSGeo incubation

== Code Copyright Review ==
'''Review completed:''' 08 Jan 2026
'''Reviewer:''' Brian M Hamlin (Mentor), with assistance from automated tooling
'''Scope:''' All 557 Python source files in the TorchGeo repository
=== 1. License Headers ===
{| class="wikitable"
|-
| '''Total Python files:''' || 557
|-
| '''Files with standard header:''' || 557 (100%)
|-
| '''Files missing header:''' || 0 (after [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262])
|}
'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.
'''Finding:''' All source files include the standard license header. Two utility scripts (<code>docs/user/metrics/update_timeline.py</code> and <code>tests/data/landcoverai/split.py</code>) were identified as missing headers during this review and fixed via [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262].
=== 2. License Consistency ===
'''Finding:''' All files are under the '''MIT License'''. No files use a different or conflicting license.
* No GPL, LGPL, or copyleft licenses found
* No Apache-only or BSD-only files found
* All code consistently uses MIT
=== 3. Code Origins ===
Two files contain code derived from external sources. Both are properly attributed and both original sources use MIT License (compatible):
{| class="wikitable"
|-
! File !! Source !! Source License !! Compatible? !! Attribution in File?
|-
| <code>torchgeo/models/btc.py</code> || [https://github.com/blaz-r/BTC-change-detection blaz-r/BTC-change-detection] || MIT || Yes || Yes
|-
| <code>torchgeo/models/croma.py</code> || [https://github.com/antofuller/CROMA antofuller/CROMA] || MIT || Yes || Yes
|}
'''Finding:''' Both external code sources are MIT licensed, which is fully compatible with TorchGeo's MIT license. Attribution is properly documented in the source file headers.
=== 4. Vendored/Bundled Code ===
'''Finding:''' No vendored or bundled third-party code exists in the source tree. All dependencies are external and installed via pip/conda.
* No <code>vendor/</code>, <code>third_party/</code>, or <code>external/</code> directories
* No embedded copies of libraries (unlike GDAL which bundles libtiff, libjpeg, etc.)
* All 18 dependencies are fetched externally at install time
=== 5. Copyright Holders ===
{| class="wikitable"
|-
! Copyright Holder !! Type !! Notes
|-
| TorchGeo Contributors || Collective || Single copyright holder for all files
|}
'''Finding:''' The project uses a '''collective copyright model'''. All files use "Copyright (c) TorchGeo Contributors" rather than individual contributor names.
'''Implications for relicensing:'''
* Simplified model - no need to contact 122 individual contributors
* Contributors implicitly agree to collective copyright by submitting PRs
* '''Resolved:''' Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) satisfactory and/or not required for incubation.

=== 6. Outstanding Issues ===
'''Resolved:'''
* Copyright headers added to 2 missing files: [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262]
* Confirm whether a CLA/DCO is in place or planned
* Contributor agreement status for PSC members

'''Pending:'''

=== 7. Conclusion ===
'''Overall assessment:''' No provenance issues identified.
The TorchGeo codebase demonstrates good copyright hygiene:
* 100% of source files have proper license headers
* All code is consistently MIT licensed
* External code derivations are properly attributed and license-compatible
* No vendored code complicates the license picture
* Collective copyright model simplifies governance
The codebase is ready for OSGeo incubation from a code provenance perspective, pending confirmation of contributor agreement procedures from the PSC.

TorchGeo Code Provenance

2026-01-20T23:49:28Z

Darkblueb: /* Code Provenance Review Process */

=Code Provenance Review Process=

TorchGeo project
'''refer : https://www.osgeo.org/about/committees/incubation/graduation/'''

'''Incubation application questionnaire link : https://trac.osgeo.org/osgeo/wiki/TorchGeo'''

==Document Status==

{| class="wikitable"
|-
| '''Version:''' || 0.5
|-
| '''Status:''' || Updated
|-
| '''Last Edited:''' || 15 Jan 2026
|}

==Purpose==

Show to "reasonable comfort level" that TorchGeo
does not have improperly contributed code, and that the code is all under the Project license.

Notice: ''It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the OSGeo Incubation Committee to prove there are no problems. However, OSGeo Incubation Committee does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.''

=TorchGeo Provenance Review=

== Project History ==

TorchGeo started as an internship project at Microsoft's AI for Good Lab in 2021, with continued support and funding from the University of Illinois Urbana-Champaign and the National Center for Supercomputing Applications. Since then, TorchGeo has been adopted by a diverse community of researchers from academia, industry, and government research institutions who have contributed to the success of the library. In 2025, we founded a new TorchGeo Organization to manage the TorchGeo Project, with the support of members from the above organizations.

'''Key milestones''':

- '''2021-05-11''': Initial commit (2330aad) by Adam J. Stewart

- '''2021-2024''': Organic growth to 120+ contributors

- '''2025''': Formation of TorchGeo Organization with formal governance structure

- '''2026''': OSGeo incubation application submitted

==Libraries==

All dependencies are external (not bundled in source tree). All licenses are OSI-approved and compatible with MIT.

{| class="wikitable" border="1"
|-
! Library !! License !! Compatible? !! In Core? !! Issues? !! Ok? !! Comments
|-
| einops || MIT || Yes || External || - || Yes || Tensor operations
|-
| geopandas || BSD-3-Clause || Yes || External || - || Yes || Geospatial dataframes
|-
| jsonargparse || MIT || Yes || External || - || Yes || CLI argument parsing
|-
| lightly || MIT || Yes || External || - || Yes || Self-supervised learning
|-
| lightning || Apache-2.0 || Yes || External || - || Yes || Training framework
|-
| matplotlib || PSF || Yes || External || - || Yes || Plotting
|-
| numpy || BSD-3-Clause || Yes || External || - || Yes || Numerical computing
|-
| pandas || BSD-3-Clause || Yes || External || - || Yes || Data manipulation
|-
| pillow || HPND [https://github.com/python-pillow/Pillow/issues/1507 *] / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || External || - || Yes || Image I/O
|-
| pyproj || MIT || Yes || External || - || Yes || Cartographic projections
|-
| rasterio || BSD-3-Clause || Yes || External || - || Yes || Geospatial raster I/O
|-
| segmentation-models-pytorch || MIT || Yes || External || - || Yes || Segmentation architectures
|-
| shapely || BSD-3-Clause || Yes || External || - || Yes || Geometric operations
|-
| timm || Apache-2.0 || Yes || External || - || Yes || Vision model zoo
|-
| torch || BSD-3-Clause || Yes || External || - || Yes || PyTorch core
|-
| torchmetrics || Apache-2.0 || Yes || External || - || Yes || Metrics computation
|-
| torchvision || BSD-3-Clause || Yes || External || - || Yes || Vision utilities
|-
| *kornia || Apache-2.0 || Yes || External || - || Yes || Computer vision ops
|}

==Copyright Holders==
{| class="wikitable" border="1"
|-
! Copyright Holder !! Contact !! Issues !! Comments
|-
| TorchGeo Contributors || N/A (collective) || None || Per LICENSE file
|}

The MIT License file states: "Copyright (c) TorchGeo Contributors."

This is a collective copyright model - individual contributors retain copyright but license under MIT. Historical other markings include:

<pre>
> git gr Copyright | grep -v TorchGeo
torchgeo/models/convlstm.py:# Copyright (c) 2017 Andrea Palazzi
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Adapted from https://github.com/bwconrad/flexivit. Copyright (c) 2023 Ben Conrad.
torchgeo/models/copernicusfm.py: Copyright (c) Microsoft Corporation.
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/earthloc.py: Adapted from https://github.com/gmberton/EarthLoc. Copyright (c) 2024 Gabriele Berton
torchgeo/models/ltae.py:# Copyright (c) 2020 VSainteuf (Vivien Sainte Fare Garnot)
</pre>

== Committers ==
'''Total human contributors:''' 122

'''Total commits:''' 2778 (excluding bots)

'''Top contributors''' (PSC members marked with *):

{| class="wikitable" border="1"
|-
! Committer !! Email !! Affiliation
|-
| Adam J. Stewart * || ajstewart426@gmail.com || TUM / UIUC
|-
| Caleb Robinson * || calebrob6@gmail.com || AI for Good Msft
|-
| Isaac Corley * || isaac.corley@proton.me || Wherobots
|-
| Nils Lehmann * || nils.lehmann24@gmail.com || TUM
|-
| Ashwin Nair * || ashnair0007@gmail.com || Space42
|-
| Anthony Ortiz * || Anthony.Ortiz@microsoft.com || Microsoft
|-
| Robin Cole || robmarkcole@gmail.com || EarthDaily
|-
| Yi Wang || wangyi111@users.noreply.github.com || TUM
|-
| Yi-Chia Chang || yichiac@users.noreply.github.com || UIUC
|-
| Burak Ekim || burakekim@users.noreply.github.com || Bundeswehr Munich
|-
| Blaz Rolih || blaz-r@users.noreply.github.com || ULjubljana, Slovenia
|-
| Maciej Kilian || iejMac@users.noreply.github.com || Stability AI
|-
| Qiusheng Wu || giswqs@gmail.com || UTenn Knoxville
|}

'''Note:''' 122 total contributors. Full list available via <code>git shortlog -sne --all</code>.

==Source Files==
'''Total Python files:''' 557

'''Files with copyright header:''' 557 (100%) - ''after PR #3262 merged''

'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.

{| class="wikitable" border="1"
|-
! File !! License !! Copyright Holder !! Header? !! Issues? !! Ok? !! Comments
|-
| docs/user/metrics/update_timeline.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|-
| tests/data/landcoverai/split.py || MIT || TorchGeo Contributors || Yes || None || Yes || Fixed in PR #3262
|}

'''Note:''' PR https://github.com/torchgeo/torchgeo/pull/3262 adds copyright headers to the 2 files that were missing them.

==Further Issues ==
'''Resolved:'''
* Copyright headers added to 2 missing files via PR #3262: https://github.com/torchgeo/torchgeo/pull/3262

* OSGeo does not require a CLA. We ask projects to think about what they want during incubation.

* Contributor agreement confirmed

'''Pending:'''

== TorchGeo Application Questionnaire ==
See the main application questionnaire for additional project details:
https://trac.osgeo.org/osgeo/wiki/TorchGeo

==Process==

'''This Code Provenance Review followed the OSGeo Incubation process:'''
{| class="wikitable"
|-
! Step !! Status !! Date !! Notes
|-
| 1. Create Provenance Review Document || Complete || 06 Jan 2026 || Document created from [https://wiki.osgeo.org/wiki/Provenance_Review_Template Provenance Review Template]
|-
| 2. Library/Component Review || Complete || 08 Jan 2026 || 18 dependencies reviewed, no issues found
|-
| 3. Code Copyright Review || Complete || 08 Jan 2026 || 557 files reviewed, no issues found
|-
| 4. Submit to Project Mentor || Complete || 08 Jan 2026 || Brian M Hamlin (Mentor)
|}
=== Review Summary ===
{| class="wikitable"
|-
| '''Components in source tree:''' || None (all external dependencies)
|-
| '''Problematic licenses:''' || None identified
|-
| '''License conflicts:''' || None identified
|-
| '''Files reviewed:''' || 557 Python files
|-
| '''Files with headers:''' || 557 (100%)
|-
| '''External code derivations:''' || 2 files (both MIT licensed, properly attributed)
|-
| '''Copyright model:''' || Collective ("TorchGeo Contributors")
|}
=== Outstanding Items ===
* '''Pending merge:''' [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262] - adds copyright headers to 2 files
* '''Resolved:''' CLA/DCO status confirmation. OSGeo does not require a CLA. OSGeo asks projects to think about what they want during incubation.
''ajstewart'' -- We used to have a CLA when we were under MSFT. We no longer have any CLA or DCO. We currently have no plans to add one. I know the Linux Foundation requires DCO. Does OSGeo have any requirements?
* '''Resolved:''' a PSC Members Agreement is not required by OSGeo

=== Conclusion ===
'''The TorchGeo codebase passes the Code Provenance Review''' with no blocking issues identified. The project demonstrates good license hygiene and is ready for OSGeo incubation from a code provenance perspective.

==Library/Component Review Process==

'''Review completed:''' 08 Jan 2026
=== 1. Components in Source Tree ===
'''Finding:''' '''None'''
TorchGeo does '''not''' bundle any third-party libraries in its source tree. Unlike projects like GDAL (which includes copies of libtiff, libjpeg, etc.), TorchGeo treats all dependencies as external packages installed via pip/conda.
* No <code>vendor/</code> directory
* No <code>third_party/</code> directory
* No <code>external/</code> directory
* No embedded library copies
This is the recommended approach and simplifies license management.
=== 2. External Dependencies ===
'''Total required dependencies:''' 18
'''All licenses are OSI-approved and compatible with MIT.'''
{| class="wikitable"
|-
! Package !! License !! Compatible? !! Potentially Problematic?
|-
| einops || MIT || Yes || No
|-
| geopandas || BSD-3-Clause || Yes || No
|-
| jsonargparse || MIT || Yes || No
|-
| kornia || Apache-2.0 || Yes || No
|-
| lightly || MIT || Yes || No
|-
| lightning || Apache-2.0 || Yes || No
|-
| matplotlib || PSF (BSD-style) || Yes || No
|-
| numpy || BSD-3-Clause || Yes || No
|-
| pandas || BSD-3-Clause || Yes || No
|-
| pillow || HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || Yes || No
|-
| pyproj || MIT || Yes || No
|-
| rasterio || BSD-3-Clause || Yes || No
|-
| segmentation-models-pytorch || MIT || Yes || No
|-
| shapely || BSD-3-Clause || Yes || No
|-
| timm || Apache-2.0 || Yes || No
|-
| torch || BSD-3-Clause || Yes || No
|-
| torchmetrics || Apache-2.0 || Yes || No
|-
| torchvision || BSD-3-Clause || Yes || No
|}

=== 3. License Distribution ===
{| class="wikitable"
|-
! License Type !! Count !! Notes
|-
| MIT || 6 || Permissive, fully compatible
|-
| BSD-3-Clause || 7 || Permissive, fully compatible
|-
| Apache-2.0 || 4 || Permissive, fully compatible
|-
| PSF || 1 || Python Software Foundation, BSD-style
|-
| HPND / MIT-CMU[https://github.com/python-pillow/Pillow/pull/8460 *] || 1 || Historical Permission Notice and Disclaimer, permissive
|}

=== 4. Potentially Problematic Licenses ===
'''Finding:''' '''None identified'''
* No GPL or LGPL dependencies (no copyleft)
* No AGPL dependencies
* No proprietary or non-free dependencies
* No "viral" license concerns
=== 5. License Conflicts ===
'''Finding:''' '''None identified'''
All dependency licenses are permissive and compatible with each other and with TorchGeo's MIT license. There are no conflicts analogous to GDAL's use of GPL'ed GRASS libraries.
=== 6. Optional Dependencies ===
TorchGeo has optional dependencies for the <code>datasets</code> extra. All use permissive licenses:
{| class="wikitable"
|-
! Package !! License
|-
| h5py || BSD-3-Clause
|-
| laspy || BSD-2-Clause
|-
| netcdf4 || MIT
|-
| opencv-python || Apache-2.0
|-
| pycocotools || BSD-2-Clause
|-
| rioxarray || Apache-2.0
|-
| scikit-image || BSD-3-Clause
|-
| scipy || BSD-3-Clause
|-
| xarray || Apache-2.0
|}
=== 7. Conclusion ===
'''Overall assessment:''' No library/component issues identified
* No bundled code in source tree
* All 18 required dependencies use permissive OSI-approved licenses
* No GPL/copyleft dependencies
* No license conflicts
* Clean dependency model suitable for OSGeo incubation

== Code Copyright Review ==
'''Review completed:''' 08 Jan 2026
'''Reviewer:''' Brian M Hamlin (Mentor), with assistance from automated tooling
'''Scope:''' All 557 Python source files in the TorchGeo repository
=== 1. License Headers ===
{| class="wikitable"
|-
| '''Total Python files:''' || 557
|-
| '''Files with standard header:''' || 557 (100%)
|-
| '''Files missing header:''' || 0 (after [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262])
|}
'''Standard header format:'''
# Copyright (c) TorchGeo Contributors. All rights reserved.
# Licensed under the MIT License.
'''Finding:''' All source files include the standard license header. Two utility scripts (<code>docs/user/metrics/update_timeline.py</code> and <code>tests/data/landcoverai/split.py</code>) were identified as missing headers during this review and fixed via [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262].
=== 2. License Consistency ===
'''Finding:''' All files are under the '''MIT License'''. No files use a different or conflicting license.
* No GPL, LGPL, or copyleft licenses found
* No Apache-only or BSD-only files found
* All code consistently uses MIT
=== 3. Code Origins ===
Two files contain code derived from external sources. Both are properly attributed and both original sources use MIT License (compatible):
{| class="wikitable"
|-
! File !! Source !! Source License !! Compatible? !! Attribution in File?
|-
| <code>torchgeo/models/btc.py</code> || [https://github.com/blaz-r/BTC-change-detection blaz-r/BTC-change-detection] || MIT || Yes || Yes
|-
| <code>torchgeo/models/croma.py</code> || [https://github.com/antofuller/CROMA antofuller/CROMA] || MIT || Yes || Yes
|}
'''Finding:''' Both external code sources are MIT licensed, which is fully compatible with TorchGeo's MIT license. Attribution is properly documented in the source file headers.
=== 4. Vendored/Bundled Code ===
'''Finding:''' No vendored or bundled third-party code exists in the source tree. All dependencies are external and installed via pip/conda.
* No <code>vendor/</code>, <code>third_party/</code>, or <code>external/</code> directories
* No embedded copies of libraries (unlike GDAL which bundles libtiff, libjpeg, etc.)
* All 18 dependencies are fetched externally at install time
=== 5. Copyright Holders ===
{| class="wikitable"
|-
! Copyright Holder !! Type !! Notes
|-
| TorchGeo Contributors || Collective || Single copyright holder for all files
|}
'''Finding:''' The project uses a '''collective copyright model'''. All files use "Copyright (c) TorchGeo Contributors" rather than individual contributor names.
'''Implications for relicensing:'''
* Simplified model - no need to contact 122 individual contributors
* Contributors implicitly agree to collective copyright by submitting PRs
* '''Resolved:''' Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) satisfactory and/or not required for incubation.

=== 6. Outstanding Issues ===
'''Resolved:'''
* Copyright headers added to 2 missing files: [https://github.com/torchgeo/torchgeo/pull/3262 PR #3262]
* Confirm whether a CLA/DCO is in place or planned
* Contributor agreement status for PSC members

'''Pending:'''

=== 7. Conclusion ===
'''Overall assessment:''' No provenance issues identified.
The TorchGeo codebase demonstrates good copyright hygiene:
* 100% of source files have proper license headers
* All code is consistently MIT licensed
* External code derivations are properly attributed and license-compatible
* No vendored code complicates the license picture
* Collective copyright model simplifies governance
The codebase is ready for OSGeo incubation from a code provenance perspective, pending confirmation of contributor agreement procedures from the PSC.

TorchGeo DOFA

2026-01-18T16:15:50Z

Darkblueb: /* More Architectural Contrasts */

TorchGeo DOFA

2026-01-18T02:04:47Z

Darkblueb:

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN][https://arxiv.org/pdf/2512.05025 pdf] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

{| class="wikitable"
|+ Overview
|-
! Topic
! DOFA
! RAMEN
! Notes
|-
| Design Philosophy
| Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
| Modular approach with explicit resolution parameterization and multi-resolution support
|
|-
| Flexibility Mechanism
| Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
| Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions
|
|-
| Adaptation Strategy
| Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
| Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference
|
|-
| Training Approach
| Wavelength-conditioned dynamic hypernetwork
| Masked autoencoding with random resolution selection
|
|-
| Code Implementation
| More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
| Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.
|
|-
| Resolution Handling
| No explicit resolution handling; adapts through channel count flexibility
| Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters,
and resolution-aware positional embeddings
|
|-
| Architecture Modularity
| Unified architecture with dynamic MLP layers for adaptability
| Separate encoder/decoder components with clear division of labor
|
|-
| Training Flexibility
| Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
| Resolution varies during training (random selection), explicit feature map control
|
|-
| Data Handling
| Simpler data handling focused on channel count variations
| Complex <code>MultiDataset</code> with time-series handling for different modalities
|
|-
| Input Handling
| Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR:
2 channels, S2: 9 channels, RGB: 3 channels)
| Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input
requirements
|
|-
| Training Approach
| Pre-trained using five different data modalities in remote sensing
| Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)
|
|-
| Evaluation Focus
| Demonstrates capability across various tasks but doesn't emphasize resolution control
| Explicitly emphasizes adjustable feature map resolution as a key contribution
|}

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T23:15:42Z

Darkblueb: /* Comprehensive Architectural Comparison' */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

{| class="wikitable"
|+ Overview
|-
! Topic
! DOFA
! RAMEN
! Notes
|-
| Design Philosophy
| Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
| Modular approach with explicit resolution parameterization and multi-resolution support
|
|-
| Flexibility Mechanism
| Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
| Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions
|
|-
| Adaptation Strategy
| Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
| Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference
|
|-
| Training Approach
| Wavelength-conditioned dynamic hypernetwork
| Masked autoencoding with random resolution selection
|
|-
| Code Implementation
| More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
| Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.
|
|-
| Resolution Handling
| No explicit resolution handling; adapts through channel count flexibility
| Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters,
and resolution-aware positional embeddings
|
|-
| Architecture Modularity
| Unified architecture with dynamic MLP layers for adaptability
| Separate encoder/decoder components with clear division of labor
|
|-
| Training Flexibility
| Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
| Resolution varies during training (random selection), explicit feature map control
|
|-
| Data Handling
| Simpler data handling focused on channel count variations
| Complex <code>MultiDataset</code> with time-series handling for different modalities
|
|-
| Input Handling
| Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR:
2 channels, S2: 9 channels, RGB: 3 channels)
| Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input
requirements
|
|-
| Training Approach
| Pre-trained using five different data modalities in remote sensing
| Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)
|
|-
| Evaluation Focus
| Demonstrates capability across various tasks but doesn't emphasize resolution control
| Explicitly emphasizes adjustable feature map resolution as a key contribution
|}

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T23:05:39Z

Darkblueb: /* More Architectural Contrasts */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T23:05:16Z

Darkblueb: /* More Architectural Contrasts */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

Talk:TorchGeo DOFA

2026-01-17T22:22:34Z

Darkblueb: Created page with "'''Note''': AI LLM assistance was employed in the production of this document. {| class="wikitable" |+ LLM Engine contributions by operator |- ! Operator !! Tool !! M..."

TorchGeo DOFA

2026-01-17T19:47:47Z

Darkblueb: /* Comprehensive Architectural Comparison' */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T19:46:42Z

Darkblueb: /* Purpose */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP layers allow DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T19:41:18Z

Darkblueb: /* Implementation approach */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP layer acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T19:40:44Z

Darkblueb: /* Implementation approach */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
*<code> TransformerWeightGenerator</code>: A component that dynamically generates network weights based on central wavelengths
* '''Hypernetwork''' concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:36:40Z

Darkblueb:

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:35:39Z

Darkblueb: /* Core Architectural Differences */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:33:49Z

Darkblueb: /* 5. Code Implementation */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

A fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

== Core Architectural Differences ==

=== 1. Design Philosophy ===
* DOFA: Unified architecture with dynamic adaptation capabilities
* RAMEN: Modular approach with explicit resolution parameterization

=== 2. Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count
* RAMEN: Explicit resolution-aware design with <code>ScaleResampler</code> and <code>all_res</code>
parameters

=== 3. Modularity ===
* DOFA: Single model architecture with dynamic components
* RAMEN: Separate encoder/decoder with specialized projection modules

=== 4. Training Approach ===
* DOFA: Wavelength-specific processing through <code>wave_lists</code>
* RAMEN: Resolution-randomized training with explicit masking strategies

=== 5. Code Structure ===
* DOFA: More compact, single-file approach to channel adaptation
* RAMEN: More complex, multi-file modular design with specialized utilities

Both use PyTorch's standard Vision Transformer components but implement them differently based on their core design goals - DOFA focuses on adaptability through dynamic layers, while RAMEN focuses on resolution controllability through explicit architectural parameters.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:32:20Z

Darkblueb: /* Dynamic MLP Layers in DOFA: */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

The fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters. Both are sophisticated solutions to the multi-modal EO challenge but address different aspects of the problem space.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

== Core Architectural Differences ==

=== 1. Design Philosophy ===
* DOFA: Unified architecture with dynamic adaptation capabilities
* RAMEN: Modular approach with explicit resolution parameterization

=== 2. Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count
* RAMEN: Explicit resolution-aware design with <code>ScaleResampler</code> and <code>all_res</code>
parameters

=== 3. Modularity ===
* DOFA: Single model architecture with dynamic components
* RAMEN: Separate encoder/decoder with specialized projection modules

=== 4. Training Approach ===
* DOFA: Wavelength-specific processing through <code>wave_lists</code>
* RAMEN: Resolution-randomized training with explicit masking strategies

=== 5. Code Structure ===
* DOFA: More compact, single-file approach to channel adaptation
* RAMEN: More complex, multi-file modular design with specialized utilities

Both use PyTorch's standard Vision Transformer components but implement them differently based on their core design goals - DOFA focuses on adaptability through dynamic layers, while RAMEN focuses on resolution controllability through explicit architectural parameters.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:31:46Z

Darkblueb: /* MLP Layers */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, ''dynamic MLP layers'' refers to a specific architectural component that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its
weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

The fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters. Both are sophisticated solutions to the multi-modal EO challenge but address different aspects of the problem space.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

== Core Architectural Differences ==

=== 1. Design Philosophy ===
* DOFA: Unified architecture with dynamic adaptation capabilities
* RAMEN: Modular approach with explicit resolution parameterization

=== 2. Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count
* RAMEN: Explicit resolution-aware design with <code>ScaleResampler</code> and <code>all_res</code>
parameters

=== 3. Modularity ===
* DOFA: Single model architecture with dynamic components
* RAMEN: Separate encoder/decoder with specialized projection modules

=== 4. Training Approach ===
* DOFA: Wavelength-specific processing through <code>wave_lists</code>
* RAMEN: Resolution-randomized training with explicit masking strategies

=== 5. Code Structure ===
* DOFA: More compact, single-file approach to channel adaptation
* RAMEN: More complex, multi-file modular design with specialized utilities

Both use PyTorch's standard Vision Transformer components but implement them differently based on their core design goals - DOFA focuses on adaptability through dynamic layers, while RAMEN focuses on resolution controllability through explicit architectural parameters.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:31:01Z

Darkblueb: /* Implementation approach */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, 'dynamic MLP layers' refers to a specific architectural component
that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its
weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

==== Purpose ====
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

The fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters. Both are sophisticated solutions to the multi-modal EO challenge but address different aspects of the problem space.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

== Core Architectural Differences ==

=== 1. Design Philosophy ===
* DOFA: Unified architecture with dynamic adaptation capabilities
* RAMEN: Modular approach with explicit resolution parameterization

=== 2. Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count
* RAMEN: Explicit resolution-aware design with <code>ScaleResampler</code> and <code>all_res</code>
parameters

=== 3. Modularity ===
* DOFA: Single model architecture with dynamic components
* RAMEN: Separate encoder/decoder with specialized projection modules

=== 4. Training Approach ===
* DOFA: Wavelength-specific processing through <code>wave_lists</code>
* RAMEN: Resolution-randomized training with explicit masking strategies

=== 5. Code Structure ===
* DOFA: More compact, single-file approach to channel adaptation
* RAMEN: More complex, multi-file modular design with specialized utilities

Both use PyTorch's standard Vision Transformer components but implement them differently based on their core design goals - DOFA focuses on adaptability through dynamic layers, while RAMEN focuses on resolution controllability through explicit architectural parameters.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>

TorchGeo DOFA

2026-01-17T04:30:39Z

Darkblueb: /* Dynamic MLP Layers in DOFA: */

Contrast and compare [https://github.com/nicolashoudre/RAMEN RAMEN] and [https://github.com/zhu-xlab/DOFA DOFA] based on README and python :

== DOFA Theory and Architecture Analysis ==

=== Core Design Principles ===
* Neuroplasticity-inspired: Based on brain's dynamic reorganization capacity in response to novel stimuli
* Wavelength-conditioned dynamic hypernetwork: Uses wavelength as unifying parameter across EO modalities
* Unified Transformer framework: Single architecture that handles diverse spectral bands and sensor modalities

=== Key Technical Components ===
1. '''Dynamic Hypernetwork''': Generates network weights based on central wavelengths of each spectral band
2. '''Shared Vision Backbone''': Universal feature learning module for all heterogeneous data modalities
3. Wavelength-aware Masked Image Modeling ('''MIM'''): Pretraining strategy that interpolates in weight space according to wavelength configurations

=== Key Classes: ===
1. <code>MaskedAutoencoderViT</code> - Main encoder class
2. <code>Dynamic_MLP_OFA</code> - Dynamic MLP layer for channel adaptation
3. <code>TransformerWeightGenerator</code> - For neuroplasticity-inspired weight generation

=== Architectural Features: ===
* Single unified ViT: Uses standard Vision Transformer backbone with modifications
* Dynamic MLP layers: <code>Dynamic_MLP_OFA</code> that adapts based on input channels
* Wavelength-aware processing: Uses <code>wave_lists</code> for different spectral band handling
* Neuroplasticity-inspired: Weight generation through transformer-based mechanism
* Channel-flexible design: Works with 2-202+ channels through dynamic layer adaptation

=== DOFA+ Enhancement ===
* Hierarchical Distillation Strategy: Preserves semantic priors from source model while guiding EO-specific pattern learning
* Dual Training Strategy:
** Wavelength-aware MIM for EO-specific spatial patterns
** Hierarchical feature distillation for refining inherited semantic representations

=== MLP Layers ===
Looking at the DOFA code structure, 'dynamic MLP layers' refers to a specific architectural component
that adapts its parameters based on input characteristics:

==== Dynamic MLP Layers in DOFA: ====

* <code>Dynamic_MLP_OFA</code> - A specialized MLP (Multi-Layer Perceptron) layer that dynamically adjusts its
weights and structure
* Unlike standard fixed MLPs, these layers can modify their internal parameters based on input features

How MLP Layers work:
1. Channel-adaptive processing': The MLP adapts to different input channel counts (2-202+ channels)
2. Wavelength-conditioned': Uses wavelength information to determine the appropriate weight
configuration
3. Dynamic weight generation: Instead of fixed weights, the layer generates weights based
on input characteristics

==== Implementation approach ====
* TransformerWeightGenerator: A component that dynamically generates network weights based on central wavelengths
* Hypernetwork concept: The dynamic MLP acts as a hypernetwork that produces weights for other layers
* Spectral band awareness: The layer structure changes to accommodate different spectral configurations

Purpose:
The dynamic MLP allows DOFA to handle varying sensor specifications without requiring multiple fixed architectures. When input data has 2 channels (SAR), 3 channels (RGB), or 202 channels (hyperspectral), the same model architecture can adapt through these dynamic layers rather than needing separate models for each modality.

== RAMEN Theory and Architecture Analysis ==

=== Core Design Principles ===
* Resolution-adjustable: Treats spatial resolution as a controllable output parameter
* Sensor-agnostic but resolution-aware: Supports any modality with explicit resolution handling
* Multi-modal fusion: Combines data from multiple modalities into unified representation

=== Key Technical Components ===
1. <code>ScaleResampler</code> handles different spatial resolutions dynamically
2. Modality-specific Projectors: <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code> for different data types
3. Resolution-aware Positional Embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
4. Feature Map Resolution Control: Explicit parameterization of output resolution

=== Key Classes: ===
1. <code>RamenViT</code> - Main encoder class
2. <code>RamenDecoderViT</code> - Decoder component
3. <code>ScaleResampler</code> - Resolution handling module
4. <code>SpectralProjector</code>, <code>RadarProjector</code>, <code>DemProjector</code>- Modality-specific projectors
5. <code>AttentionPoolLatent</code> - Attention-based pooling

=== Architectural Features: ===
* Modular encoder/decoder: Separate components with clear division of labor
* Multi-resolution support: <code>ScaleResampler</code> handles different spatial resolutions
* Modality-specific projections: Different projectors for spectral, radar, and DEM data
* Resolution-aware positional embeddings: Uses <code>get_2d_sincos_pos_embed_with_resolution</code>
* Feature map resolution control: Explicit parameterization of output resolution

== Comprehensive Architectural Comparison' ==

=== 1. Design Philosophy ===
* DOFA: Neuroplasticity-inspired approach with dynamic weight generation based on wavelength
* RAMEN: Modular approach with explicit resolution parameterization and multi-resolution support

=== 2. Flexibility Mechanism ===
* DOFA: Dynamic hypernetwork that adapts weights based on spectral characteristics (wavelengths)
* RAMEN: Explicit resolution control with <code>ScaleResampler</code> and configurable feature map resolutions

=== 3. Adaptation Strategy ===
* DOFA: Continuous pretraining via MIM + knowledge distillation, with wavelength-aware adaptation
* RAMEN: Resolution-randomized training, explicit multi-resolution handling during both pretraining and inference

=== 4. Training Approach ===
==== DOFA: ====
* Wavelength-conditioned dynamic hypernetwork
* MIM with wavelength interpolation in weight space
* Hierarchical feature distillation
==== RAMEN: ====
* Masked autoencoding with random resolution selection
* Resolution-specific masking strategies
* Multi-dataset training with different resolutions

=== 5. Code Implementation ===
* DOFA: More compact, single-file approach with specialized dynamic components. Uses one model that can handle any number of input channels from different modalities (SAR, optical, hyperspectral)
* RAMEN: Complex, multi-file modular design with dedicated utilities for each component type. Multimodal fusion approach: Combines data from multiple modalities into unified representation. Users can customize the resolution of feature maps for downstream tasks.

The fundamental difference is that DOFA focuses on spectral band adaptability through dynamic weight generation, while RAMEN focuses on spatial resolution adaptability through explicit architectural parameters. Both are sophisticated solutions to the multi-modal EO challenge but address different aspects of the problem space.

=== Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count flexibility
* RAMEN: Explicit resolution parameterization with <code>ScaleResampler</code>, <code>all_res</code> parameters, and resolution-aware positional embeddings

=== Architecture Modularity ===
* DOFA: Unified architecture with dynamic MLP layers for adaptability
* RAMEN: Separate encoder/decoder components with clear division of labor

=== Training Flexibility ===
* DOFA: Channel count varies, wavelength-specific processing, neuroplasticity-inspired adaptation
* RAMEN: Resolution varies during training (random selection), explicit feature map control

=== Data Handling ===
* DOFA: Simpler data handling focused on channel count variations
* RAMEN: Complex <code>MultiDataset</code> with time-series handling for different modalities

=== Input Handling: ===
* DOFA: Takes any number of channels as input, with preprocessing handling different sensor specifications (SAR: 2 channels, S2: 9 channels, RGB: 3 channels)
* RAMEN: Requires specifying input shape, channels, and original spatial resolution (GSD) - more structured input requirements

=== Training Approach: ===
* DOFA: Pre-trained using five different data modalities in remote sensing
* RAMEN: Uses masked autoencoding strategy on multimodal datasets (FLAIR-HUB, WorldStrat, MMEarth)

=== Evaluation Focus: ===
* DOFA: Demonstrates capability across various tasks but doesn't emphasize resolution control
* RAMEN: Explicitly emphasizes adjustable feature map resolution as a key contribution

== Significant Contrasts ==

1. Design Philosophy: DOFA focuses on neuroplasticity and adaptability to new sensors; RAMEN focuses on
resolution adjustability and computational efficiency

2. Flexibility Mechanism: DOFA's flexibility comes from channel count handling; RAMEN's comes from
resolution parameterization

3. Use Case Emphasis: DOFA emphasizes multimodal representation learning across different sensor types;
RAMEN emphasizes efficient processing with controllable detail levels

4. Architecture Approach: DOFA uses a unified ViT architecture; RAMEN implements separate encoder/decoder architectures.

Both are foundation models for Earth observation but solve different aspects of the multi-modal, multi-resolution challenge in EO data. DOFA is fundamentally different from RAMEN's approach where resolution is handled through explicit architectural parameters and resampling mechanisms rather than dynamic layer adaptation.

== More Architectural Contrasts ==

=== RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder ===
1. Multi-resolution Framework: Explicitly designed to handle different spatial resolutions as a
controllable parameter
2. Modular Components:
* <code>ScaleResampler</code> for resolution handling
* <code>RamenViT</code> with resolution-aware positional embeddings
* Separate encoder/decoder architecture
* Resolution-specific masking during training

3. Training Strategy:
* Masked autoencoding with random resolution selection during training
* Feature map resolution customization for downstream tasks
* Support for multiple datasets with different resolutions

4. Key Innovation: Treats spatial resolution as a tunable hyperparameter rather than fixed

=== DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder ===
1. Modality-Flexible Architecture:
* Single unified ViT that works across 2,3,4,6,9,12,13,202+ channels
* Uses <code>Dynamic_MLP_OFA</code> for channel-adaptive processing
* Spectral/Channel-aware positional embeddings

2. Training Strategy:
* Masked autoencoding with wavelength-specific processing
* Uses <code>wave_lists</code> to handle different spectral bands per modality
* Channel count as the primary adaptation mechanism

3. Key Innovation: Neuroplasticity-inspired adaptability to new sensor experiences through dynamic weight generation

=== MAE Applications ===
both DOFA and RAMEN use Masked Autoencoding (MAE)
techniques, but in different ways:

==== DOFA MAE Implementation: ====
* Uses <code>MaskedAutoencoderViT</code> class
* Implements masked image modeling (MIM) for pretraining
* Uses <code>wave_lists</code> for wavelength-specific processing
* Employs dynamic MLP layers that adapt to spectral bands
* Uses continuous pretraining via MIM and knowledge distillation

==== RAMEN MAE Implementation: ====
* Uses <code>RAMENMAE</code> class that combines encoder/decoder
* Implements masked autoencoding with random resolution selection during training
* Uses <code>MaskCollator</code> for multi-resolution masking strategies
* Employs resolution-aware training where effective resolution is chosen randomly
* Has separate encoder and decoder components

Both models implement MAE techniques, but:
* DOFA focuses on wavelength-aware MAE with dynamic weight generation
* RAMEN focuses on resolution-aware MAE with multi-resolution masking

The key difference is that RAMEN explicitly makes resolution a controllable parameter in their MAE approach, while DOFA makes spectral bands the primary adaptation mechanism in theirs.

== Key Technical Differences ==

== Design Philosophy ==

RAMEN: Systematic approach to resolution control - treats resolution as a first-class citizen in the
architecture and training process.

DOFA: Adaptive approach to modality diversity - uses neuroplasticity concepts to adapt to different sensor
characteristics through dynamic weight generation.

Both are foundation models for Earth Observation but RAMEN specifically addresses the multi-resolution
challenge while DOFA focuses on multi-modality with neuroplasticity-inspired adaptability. The RAMEN
approach appears more systematic in its resolution handling, while DOFA's approach is more about adaptive
learning across different sensor specifications.

== Core Architectural Differences ==

=== 1. Design Philosophy ===
* DOFA: Unified architecture with dynamic adaptation capabilities
* RAMEN: Modular approach with explicit resolution parameterization

=== 2. Resolution Handling ===
* DOFA: No explicit resolution handling; adapts through channel count
* RAMEN: Explicit resolution-aware design with <code>ScaleResampler</code> and <code>all_res</code>
parameters

=== 3. Modularity ===
* DOFA: Single model architecture with dynamic components
* RAMEN: Separate encoder/decoder with specialized projection modules

=== 4. Training Approach ===
* DOFA: Wavelength-specific processing through <code>wave_lists</code>
* RAMEN: Resolution-randomized training with explicit masking strategies

=== 5. Code Structure ===
* DOFA: More compact, single-file approach to channel adaptation
* RAMEN: More complex, multi-file modular design with specialized utilities

Both use PyTorch's standard Vision Transformer components but implement them differently based on their core design goals - DOFA focuses on adaptability through dynamic layers, while RAMEN focuses on resolution controllability through explicit architectural parameters.

= scratch =

=== Contents ===
<pre>
1. DOFA Theory and Architecture Analysis
1.1 Core Design Principles
1.2 Key Technical Components
1.3 DOFA+ Enhancement
2. RAMEN Theory and Architecture Analysis
2.1 Core Design Principles
2.2 Key Technical Components
3. Comprehensive Architectural Comparison
3.1 Design Philosophy
3.2 Flexibility Mechanism
3.3 Adaptation Strategy
3.4 Training Approach
3.4.1 DOFA
3.4.2 RAMEN
3.5 Code Implementation
4. Core Architectural Differences
4.1 DOFA
4.2 RAMEN
5. Key Technical Differences
5.1 Input Handling
5.2 Training Approach
5.3 Evaluation Focus
6. Primary Contrasts
7. Core Architectural Contrasts
7.1 RAMEN's Approach: Resolution-Adjustable Multi-Modal Encoder
7.2 DOFA's Approach: Neuroplasticity-Inspired Multi-Modal Encoder
8. Key Technical Differences
8.1 Resolution Handling
8.2 Architecture Modularity
8.3 Training Flexibility
8.4 Data Handling
9. Design Philosophy
10. DOFA Encoder Architecture
10.1 Key Classes
10.2 Architectural Features
11. RAMEN Encoder Architecture
11.1 Key Classes
11.2 Architectural Features
12. Core Architectural Differences
12.1 1. Design Philosophy
12.2 2. Resolution Handling
12.3 3. Modularity
12.4 4. Training Approach
12.5 5. Code Structure
</pre>