iMMAP and ICARDA are named because this work is public. Every claim below points at a published document. Where a claim rests on my own account rather than a document, the sentence says "I".
MEL was over a year old when I started on it. I didn't build MEL. I helped build the parts that made it usable, and the web GIS that plugged into it.
A research platform is only as useful as the evidence it keeps attached to each number.
What are MEL and GeOC?
MEL is CGIAR's platform for Monitoring, Evaluation and Learning, and GeOC is a web GIS for Sustainable Land Management decisions that runs inside it. Users sign in with their MEL account and submit land-management data through MEL, as the GeOC User Guide documents.
The CGIAR Research Program on Dryland Systems built MEL in-house and launched it at the end of 2014, with Jalal Omary as its original developer, according to the MEL FAQ (August 2016). In 2016 it became shared infrastructure between ICARDA and CIP, and the MEL, CodeObia and iMMAP teams developed it together.
By February 2020, ICARDA reported that MEL held over 900 projects, 1,000 activities and 12,000 products, and credited it as "powered by CodeObia, iMMAP, DSpace and AWS" (ICARDA, 2020). I joined iMMAP in February 2016 as a Web Developer Officer, and from 2016 to 2018 I led a team of five on this work: four developers and me.
Which parts of MEL did I work on?
I worked on seven MEL modules between 2016 and 2018. Two carry documentary evidence with my name on it; the other five rest on my own account. The table says which is which.
| Module | What it does | Evidence |
|---|---|---|
| IP and Legal | Project Background, Foreground and Analysis pages | I wrote its section of the MEL design document, v2.9, October 2016 |
| SLM submission and approval | Forms and admin approval that bring GeOC data into MEL | Specified in the GeOC Installation Guide, which I co-authored |
| Reporting | Sync from MEL to its DSpace open-access repository | My account |
| Surveys | Gender, intellectual-property and capacity-development surveys | My account |
| Planning and Pre-Planning | Project and activity planning | My account |
| Overview map | The MEL overview page with its map | My account |
| Knowledge Sharing | Forum, technical-assistance chat, project pages | My account |
I also co-authored the 2016 MEL System Design & Architecture document and did its final compilation with Aya Mousa. Enrico Bonaiuti, ICARDA's MEL specialist, wrote its business-logic revision.
What problem was GeOC built to solve?
GeOC answers one question for dryland land management: where is a given practice appropriate, and what evidence supports that decision? The GeOC design paper by Le, Thomas and Bonaiuti (ICARDA, May 2017) argues that drylands vary so much that "uniform blanket" policies for Sustainable Land Management fail at scale.
The CGIAR Research Program on Dryland Systems started GeOC to replace the blanket with context. The GeOC User Guide describes a web-based GIS for defining, monitoring, assessing and co-creating knowledge on Sustainable Land Management options that match the social-ecological context, at global, regional and national scales.
The design paper gives GeOC a second job. It helps countries report on their Land Degradation Neutrality commitments under the UNCCD and Sustainable Development Goal 15. The project behind it ran from August 2016 to November 2017, funded by GIZ, with ICARDA as lead centre and iMMAP as a partner. The documents also spell the tool "GeCO".
What could users do with GeOC?
GeOC users could query Sustainable Land Management options by context in three ways, defined in the GeOC design paper (ICARDA, 2017): find options already used within a context they define, take one option and find places with a similar context, or evaluate land degradation or improvement by context to find gaps in reaching Land Degradation Neutrality.
In the browser, a user selected an area, read its contextual values, compared it with other contexts, and found options recorded under similar conditions. Every layer in the GeOC User Guide is a raster at 1-km resolution.
The context database covers the long-term trend in annual precipitation, an aridity index, land cover in ten classes aggregated from GlobCover, elevation, slope, seven soil-quality constraints, distance to water, roads and the district capital, population density and change, protected areas, and tenure security. A separate impact-outcome database holds NDVI-based productivity decline and improvement, rain-use efficiency, and the affected population.
Where did satellite and raster data come in?
The GeOC project's geospatial work drew on raster layers and satellite imagery, including high-resolution Google Earth imagery and MODIS and Landsat data. Three of GeOC's impact layers come from NDVI, and its land cover comes from GlobCover, per the GeOC User Guide (ICARDA, 2017). In GeOC the layers sit in PostGIS with raster support, and GeoServer serves them.
On the MEL side, I integrated Google Earth Engine so the platform could issue Earth Engine commands and render the resulting maps.
Getting the layers into shape was the unglamorous part of the job. They arrived from different projects, in different formats, with different words for the same thing. Someone had to decide which name won and rewrite the rest.
A satellite image shows what is on the ground. A decision-support tool has to show what that means for the next decision.
What was the stack?
MEL ran PHP on Zend Framework 1.12 with MySQL, and the GeOC web GIS ran Java 8 and Spring 4.3 on PostgreSQL 9.5 with PostGIS, hosted on AWS. Both are documented in the MEL System Design & Architecture document (2016) and the GeOC Installation Guide (iMMAP, October 2017).
| Layer | MEL | GeOC web GIS |
|---|---|---|
| Backend | PHP, Zend Framework 1.12 | Java 8, Spring 4.3 REST on Apache Tomcat 8.5 |
| Database | MySQL | PostgreSQL 9.5, PostGIS with raster and GDAL, pgRouting |
| Map serving | Google map on the overview page | GeoServer 2.9, ArcGIS Server |
| Frontend | jQuery, Metronic theme | Leaflet, OpenLayers, Mapbox |
| Repository | DSpace, open access | None |
| Hosting | CGNET server, Windows Server 2012 | AWS Ubuntu 16.04 instance |
The GeOC forms that live inside MEL used PHP on Zend Framework 1.12 with Metronic 4.7, and stored land-management metadata as JSON in MySQL. Today I would build the same split on Laravel and Next.js, the way yabasha.dev runs.
What was hard, and how did we fix it?
The hardest part of MEL and GeOC was not the map. It was making one system work for people with very different technical backgrounds, across several CGIAR centres, research programs and donors. That constraint shaped most of what we decided.
| Problem | What I did |
|---|---|
| Dirty data | Python scripts on pandas validated and cleaned data on import, on save and before processing, so bad rows stopped at the door |
| Slow spatial queries | Spatial indexes on the geometry columns, and queries rewritten so PostGIS actually used them |
| Reporting burden | Forms asked only for what mattered, with imports and prefilled fields doing the rest |
| Non-specialist users | Raster layers had to make sense to people who are not GIS specialists |
Validate data at ingestion, not at reporting time. A bad row caught on import costs a message; caught in a donor report, it costs trust.
The same rule runs through building production AI agents: check the shape before anything downstream trusts it.
Why does this still matter?
MEL and GeOC had the same engineering problem I work on now in RAG and agent systems: data arrives from many sources in many shapes, and it has to become interoperable without losing where it came from.
An answer is only useful if the evidence behind it travels with it.
In a regulated bank the same rule decides whether an agent's output survives review, which I wrote about in what actually works in enterprise banking. It is also why I trace every model call before I optimise one, as in cutting LLM API costs 60%.
A decision-support interface has to hide the complexity without hiding the reasoning.
In 2016 we called this data management. How much of your AI problem is a provenance problem you haven't named yet?
Sources and scope
- Mousa, A.; Ayyash, B.; Khan, M.; et al. (2016). Monitoring, Evaluation and Learning Platform: System Design & Architecture. CGIAR Research Program on Dryland Systems. I'm listed second of 12.
- Jaspe, J.; Ayyash, B.; Diwediga, B.; et al. (2017). GeOC Installation Guide. iMMAP. I'm listed second of 11.
- Fradi, F.; Jaspe, J.; Ayyash, B.; et al. (2017). GeOC User Guide. ICARDA.
- Le, Q.B.; Thomas, R.; Bonaiuti, E. (2017). GeOC: Designing the System and Use Cases. ICARDA.
- ICARDA (2020). MEL: Transforming Everyday Data Management.
- MEL: Frequently asked questions (August 2016). ResearchGate.
- Scope: iMMAP deployment to ICARDA, 2016 to 2018. Team size, module work beyond the two documented modules, the Earth Engine integration and the fixes in the table above are my own account.