DEV Community: Emmanuel Belo

🧠 Lessons Learned: Multi-Platform Intelligence Suite

Emmanuel Belo — Sat, 21 Feb 2026 10:31:48 +0000

This retrospective documents the development of a Multi-Platform Intelligence Suite — an autonomous OSINT python tool designed to transform high-noise social feeds into structured, geopolitical-style briefings, released on GitHub.

The application currently aggregates timelines from X (Twitter) and Bluesky, standardizing engagement metrics via Z-score normalization to ensure high-signal content is identified regardless of the host platform's user density.

The tool supports two AI backends:

Gemini (Google Cloud): Fast, high-quality, but costs API credits.
Ollama (Local): Runs entirely on your own hardware, free to use.

This document captures the real challenges I ran into, the decisions I made, and the insights I'd apply if starting over. It is written for someone who wants to build something similar.

1. API Costs: Discover, Measure, Then Mitigate

What happened: The X API is priced pay-per-request. $25 was loaded as credits and the tool was run for the first time on a real 24-hour timeline. The result: fetching ~800 posts cost approximately $4 in a single run.

That's a concrete, measurable signal. At that rate, iterating on the AI pipeline — running it 5-10 times to test different prompts, models, and architectures — would have burned through the entire $25 budget in API calls alone, producing nothing useful.

The immediate response was to ask the agent to implement a skip flag: --from-summary. Once a summary is fetched and saved to disk, all subsequent runs reuse it. The X API is never called again until you explicitly want fresh data.

A second flag, --intel-limit N, was added to cap the number of posts sent to the LLM for fast, cheap iteration on the AI components.

The lesson is not "plan for costs upfront." It's: measure your first real run, notice where money is being burned, and immediately build the escape hatch. On a pay-per-request API, the fetch layer and the intelligence layer should be independently executable from the start.

Takeaway: Two-stage pipelines (fetch → process) should always support running each stage independently. The moment you see a real cost, you can respond in minutes — if the architecture allows it.

2. The Value of Agent-Delegated Complexity

Several genuinely hard technical problems appeared during this project: OAuth 1.0a authentication (a 4-key scheme used by the X API), environment variable loading bugs, and API credential validation errors that produced opaque error messages. These are exactly the kinds of problems that would traditionally stop a non-developer cold.

They didn't stop the project. The agent diagnosed each issue, reprompted itself, tried fixes, validated them, and moved on — autonomously. From the user's perspective, these problems happened and were resolved without any manual intervention. No terminal commands to write. No .env syntax to understand. No OAuth documentation to read.

The real lesson here is not technical — it is about trust and scope.

Working with an agentic AI partner means you can delegate an entire category of problem — low-level debugging, configuration, environment management — and direct your own attention toward higher-level decisions: what to build, which model to use, what the output should look like.

This is a different kind of collaboration than using a search engine or a tutorial. The agent doesn't just give you the answer — it implements it, tests it, and moves on. The release of being able to trust that process was significant: it meant the pace of the project was set by decisions, not by debugging capacity.

Takeaway: The ceiling of what a non-developer can build is dramatically higher with an agentic AI partner — not because the technical problems go away, but because they no longer have to stop you.

3. Architecture Decision: Map-Reduce for Local Models

Context: A "context window" is the maximum amount of text a language model can process at once. A typical LLM context window holds ~8,000–32,000 tokens. An 800-post timeline easily exceeds that limit.

The problem: Feeding all 800+ posts to a local model in one prompt caused hallucinations, dropped posts, and incoherent summaries.

Solution — Map-Reduce:

Map: Split posts into small batches of 10. Ask the model to classify each post into one of 6 predefined categories.
Select: From each category, take only the top 15 posts by engagement score.
Draft: Generate a section summary for each category (90 posts total, well within any context window).
Reduce (Reflective Pass): Feed all 6 drafted sections back to the model and ask it to synthesize a single-paragraph Executive Summary — the model reflecting on its own work.

The "reflective pass" is a powerful general pattern: generate drafts, then ask the model to step back and synthesize. It consistently produces better summaries than one-shot attempts.

Takeaway: For large datasets, never attempt a single prompt. Classify first, then synthesize progressively.

4. Cloud-to-Local: Architectures Don't Scale Down

This is perhaps the most counterintuitive lesson of the entire project.

The natural assumption when adding local model support is: "I already have a Gemini prompt that works well — I'll reuse it with Ollama and swap the endpoint." This is wrong, and the failure is not gradual — it is qualitative.

In naval engineering, this problem has a name: similitude failure. When you build a scale model of a ship to test in a tank, the forces that dominate behavior are different at small scale. A full-size ship is dominated by wave drag and inertia. A small model in a tub is dominated by surface tension and viscosity. The same equations, the same shape — completely different governing physics. You can't just shrink the design.

The same principle applies to LLMs:

Failure Mode	Large Cloud Model (Gemini)	Small Local Model (Llama 3.2)
Context window	Effectively unlimited (1M+ tokens)	Very limited (~8K tokens)
Instruction fidelity	Reliably follows complex prompts	Drifts, invents, simplifies
Structured output	Stable with a well-written prompt	Needs strict enumeration of every valid output
Hallucination	Rare in classification tasks	Common if categories are not explicitly constrained
Single-pass summary	Works for 800+ posts	Fails; context is truncated or ignored

The dominant failure modes are qualitatively different, not just quantitatively worse. A single Gemini prompt breaks in a completely different way on Llama 3.2 than you'd expect from "a smaller, dumber version."

What this means in practice: Local model support is not a feature — it is a separate architecture. It requires:

Breaking large prompts into small, constrained steps (Map-Reduce)
Strict enumeration of all valid outputs in the prompt
A reflective synthesis pass instead of one-shot generation
Validation and fallback logic at every stage

Corollary — Define the Output Schema First: This lesson has an immediate practical implication. With two backends (Gemini and Ollama), each had its own system prompt written independently. The result: different category names, different heading structures, and incompatible report formats. The Gemini prompt used free-form topics; the Ollama pipeline used a fixed list of 6 categories. They couldn't be compared or combined.

The fix was to define the 6 categories centrally and update both prompts to reference them. In a multi-backend system, the output schema is the contract — treat it like an API. Writing prompts before agreeing on the schema causes messy retrofits.

5. Model Selection: VRAM is the Real Constraint

Context: VRAM (Video RAM) is the dedicated memory on your GPU. If a model fits entirely in VRAM, inference is extremely fast. If it doesn't, the system "spills" to regular RAM, which is 10-20x slower.

Model	Size	Fits in 4GB VRAM?	Time for 839 posts
Mistral 7B	4.4 GB	❌ (RAM spill)	~6.5 hours (estimated)
Llama 3.2 3B	2.0 GB	✅	~25 minutes
Gemini Flash	Cloud	N/A	~45 seconds

The hardware used for this benchmark: Intel 11th Gen i7, 16GB RAM, NVIDIA T500 (4GB VRAM) — a mobile workstation laptop several years old. Despite its age, Llama 3.2 ran entirely in its VRAM and processed the full 839-post dataset comfortably.

Trap: "Mistral-Small" sounds like a small model — it is actually 24B parameters (~14GB). The "Small" in Mistral's naming refers to it being small relative to their 123B flagship, not relative to a 7B base model.

Takeaway: For batch-heavy local pipelines, the largest model that fits completely in VRAM will outperform a "smarter" model that doesn't — often by an order of magnitude.

6. Prompt Engineering: Strictness Over Creativity

Challenge: Local models are prone to "category hallucination" — inventing category names not in the provided list (e.g. returning "Finance & Economy" instead of the defined "Economics & Markets"). This corrupts the Map-Reduce grouping step.

What worked:

Providing the exact list of 6 category strings in the prompt with explicit instruction to use only these strings.
One-shot formatting: showing the model one example of the expected input/output pair.
Strict matching in the classification parser with a fallback to "unrecognised" rather than accepting approximate matches.

Takeaway: For structured classification tasks, suppress model creativity. Enumerate all valid outputs explicitly. Any ambiguity will be exploited.

7. Code Quality: SonarCloud as Your External Auditor

As a non-developer, you cannot assess the security or quality of code you didn't write. You can't spot a deeply nested function that will become impossible to maintain, or know when exception handling is done in a way that suppresses critical signals. You have to trust that the code is correct.

SonarCloud provides an independent, automated answer to that trust problem. Every time code was pushed to GitHub, SonarCloud ran a quality pass and flagged any issues — from structural complexity to unsafe exception handling patterns. No developer judgment required; the findings are plain-language, specific, and actionable.

The workflow that emerged was trivially simple:

Check the SonarCloud dashboard after a push.
Copy the flagged issue description.
Hand it directly to the coding agent: "Fix this SonarCloud warning."
The agent implements the fix, explains what changed, and pushes.

No major security issues were found. The warnings were structural — functions too complex to maintain easily, commented-out dividers mistaken for dead code, a try/except pattern that could suppress system signals. All were resolved quickly.

Takeaway: For non-developer-led projects, a CI/CD quality gate like SonarCloud is not optional — it is your independent code reviewer. It closes the gap between "the agent wrote code" and "the code is trustworthy."

8. Git Strategy: Branches for Architectural Changes

Challenge: During the shift to Map-Reduce, the codebase changed significantly — new modules, new data flow, new prompts. The temptation is to keep going until it "works" before committing. The result: a sprawling unstaged delta that's hard to reason about or partially revert.
The psychological trap: "I don't want to commit broken code." This causes delayed commits, which causes large messy commits, which causes reverting damage to be much worse.
What to do instead:

git checkout -b feature/map-reduce — protect main from the work-in-progress.
Commit each stable sub-component individually: the classifier function, the category selector, the section generator, then the assembler.
End-to-end doesn't need to work for each commit — only the piece you just wrote needs to be internally correct.
Merge to main only when the full pipeline is tested green.

Takeaway: A broken commit on a branch isn't broken code — it's a checkpoint. Use branches to make partial commits feel safe.

9. Beyond Vibe Coding: Agentic Technical Direction

When you build software entirely through conversational AI, the popular term is "vibe coding" — a process often characterized by low-context requests ("make an app that does X") and the blind acceptance of AI-generated code. This frequently results in unmaintainable architecture because the human doesn't actually understand the system.
This project demonstrated something fundamentally different: Agentic Technical Direction.
In this model, I acted as a Tech Lead or Technical Product Manager, not a typist:

Defining Architecture: I made the hard structural decisions ("Use Ollama for local inference," "Rank by engagement instead of X's proprietary algorithm," "Implement Map-Reduce to handle context windows").
Auditing & Verifying: I didn't accept the first draft. When presented with failure modes (hallucinations, VRAM spills, API costs) by the agentic AI, I defined the mitigation strategy (e.g., "Implement a --from-summary skip flag").
Enforcing Standards: I demanded external quality gates (SonarCloud), insisted on 90%+ test coverage, and enforced open-source standards (MIT licenses, CONTRIBUTING.md).
Documenting the Why: I framed the project as a cohesive product with a distinct point of view (Local Privacy, Deep Reading), rather than just a script. The AI agent wrote the code, but I designed the system. That is the future of software engineering.

10. Leveling Up: Skills for Agentic Technical Direction

Acting as a Technical Director for an AI agent requires a specific skill set that differs from traditional coding. Based on my workflow in this project, here are the key areas I need to develop for future agentic projects:

What to Learn: Git and Version Control

The Challenge: The fastest way out of bad AI-generated code is not asking the AI to fix it, but simply reverting to the last known good state. If I don't control the version timeline, the AI controls me.
The Skill: Master the difference between the working directory, staging area, and commits. Learn to ruthlessly use feature branches (git checkout -b new-experiment) so the main branch stays pristine until I explicitly approve the agent's work.

What to Improve: The Skill of "Scaffolding"

The Challenge: AI models struggle with "big bang" integration where everything is built at once, but they are incredible at filling in the blanks.
The Skill: Practice "Data-First" building. Before asking the agent to write a processing pipeline, manually define exactly what the input data and desired output data look like. Write empty function signatures (stubs) with clear docstrings, and let the AI fill in the logic.

What to Study: Fundamentals of Software Architecture

The Challenge: Without structural guidance, an AI will take the path of least resistance, resulting in giant, monolithic files holding thousands of lines of spaghetti code.
The Skill: Learn the vocabulary of system design to direct the agent on how files should interact. Understand "Separation of Concerns" (e.g., splitting fetching, ranking, and rendering) and "Dependency Injection" (which allowed us to easily swap between Gemini and Ollama).

The Superpower to Cultivate: The "Stop and Inspect" Reflex

The Strength: My best moments in this project occurred when development was paused to inspect failures. When SonarCloud flagged complexity, I had the agent refactor it. When a $4 API cost was observed, I had the agent build a bypass flag.
The Lesson: Many developers let AI tools generate code until the system collapses under its own weight. The reflex to inspect output, measure costs, and refactor messes before adding the next feature is exactly what makes a great Technical Director.

11. Conclusion: Learning by Doing with an AI Partner

This project started as a focused utility and became a hands-on education in local AI orchestration, Python engineering, API management, CI/CD quality gates, and system design.

The most important meta-lesson: complex, real work is the best teacher. Passively reading about Map-Reduce, VRAM constraints, and OAuth authentication doesn't produce the same understanding as hitting those walls directly and solving through them.

Working with an agentic AI partner compressed that learning dramatically — not by removing the problems, but by making it possible to actually encounter and solve them faster than you could alone.

The barriers to running your own local AI pipeline, writing production-quality Python, and shipping to GitHub with automated tests — are lower than they appear. You just need to start.

And the trend is clear: the models that ran efficiently today on older laptop hardware would have required a high-end server just a few years ago. As quantization and architecture efficiency improve, the "VRAM constraint" will keep relaxing. A 3B model in 2026 already does things a 13B model from 2023 struggled with. The intelligence-per-gigabyte ratio is rising fast — and it will keep rising.

Securing AI in Software Development: the Lethal Trifecta

Emmanuel Belo — Wed, 05 Nov 2025 09:46:05 +0000

AI assistants are transforming how software is developed. They help automate tasks, accelerate coding, and improve quality, but they also introduce new security challenges. Understanding and managing these risks is essential to ensure AI systems operate safely. Secure AI development involves identifying where vulnerabilities arise, limiting exposure to sensitive data, and ensuring AI tools cannot be misused or manipulated.

What is the Lethal Trifecta?

A concept developed by Simon Willison that identifies three conditions that make AI systems particularly risky when they occur together. When all three conditions are present, an AI system becomes significantly more dangerous.

The Three Conditions

Exposure to untrusted content: Including hidden malicious instructions or incorrect information.
Access to private data: Including secret keys, tokens, passwords, and proprietary information.
Ability to externally communicate: The capability to send data outside a closed system.

The Risk

When all three conditions exist simultaneously, an AI assistant can:

Receive malicious commands from untrusted content
Extract or use private data
Send that data elsewhere or use it to attack systems

Risk Mitigation Strategies

The primary recommendation is to remove at least one of the three conditions.
If removal isn't possible, constrain what you can control.
Implement additional risk reduction measures when the trifecta cannot be fully broken.

Diving into the 2024 Francophone QGIS Meetings

Emmanuel Belo — Thu, 28 Mar 2024 16:40:13 +0000

This week, the Camptocamp team had the privilege of participating in the 2024 Francophone QGIS Meetings in Grenoble, a key event for the QGIS user and developer community. As a Gold Sponsor and an IT service provider specializing in open source solutions, Camptocamp not only supported this event but also actively contributed to its success through enriching presentations and fruitful exchanges.

Contributions from the Camptocamp Team

During the event, our collaborators, Arnaud Morvan, Julien Waddle, Moritz Krimse and Alexian Masson, shared their expertise through various activities:

Arnaud delved into debugging methods for QGIS running in Docker containers, aiming to simplify the development process for the community.
Julien shared his experience of Mergin Maps with the audience, highlighting tips for maximizing efficiency in the field with QGIS.
Moritz and Alexian explored improvements for many-to-many relationships in QGIS and assessed the integration of QGIS with Qt 6, respectively.

Three Highlights

3D Innovation: The discussion on integrating SFCGAL into QGIS for 3D computing has opened up new perspectives for handling complex spatial data.
Enhancing UX in QGIS Modeler: Proposals to improve the user experience in the QGIS modeler aim to make it as intuitive and efficient as market-leading solutions.
Security within the QGIS Project: The initiative to bolster security within the QGIS project highlights the importance placed on the reliability and safety of open source infrastructures.

Camptocamp

This participation underscores Camptocamp's commitment to the continuous improvement of QGIS and the open source geospatial ecosystem. We firmly believe in the added value of free and open solutions to meet contemporary geospatial challenges.

Camptocamp stands out in the IT landscape for its commitment to open source technologies, especially in the geospatial domain. Our expertise ranges from designing innovative Geographic Information Systems (GIS) to implementing customized solutions based on QGIS, thus meeting the specific needs of our clients.

If you're looking to leverage our expertise in open source geospatial solutions and customized Geographic Information Systems, don't hesitate to contact Camptocamp. Our team is ready to assist you in realizing your most ambitious projects by providing innovative and sustainable solutions.

GeoServer 2.25

Emmanuel Belo — Tue, 26 Mar 2024 08:23:56 +0000

GeoServer, a key tool in the geospatial data management sector, facilitates the sharing and editing of geospatial information via web services, complying with Open Geospatial Consortium (OGC) standards. Camptocamp has consistently supported the GeoServer project, emphasizing the value of open-source solutions in geospatial technologies. This post outlines the recent updates to GeoServer, notably the release of GeoServer 2.25 and the development of GeoServer-Cloud.

GeoServer 2.25 Update

The latest stable release of GeoServer, version 2.25, brings forth updates that enhance its functionality and security for production use. Developed alongside GeoTools 31.0 and GeoWebCache 1.25.0, this version introduces necessary security fixes and configuration optimizations. These updates are intended to improve the management and handling of geospatial data for users relying on GeoServer in their operational environments.

On GeoServer-Cloud

In addition to ongoing improvements to GeoServer, Camptocamp has led the initiative to develop GeoServer-Cloud. This project reconfigures GeoServer’s traditional structure into a cloud-compatible format, utilizing a microservices architecture. The intent behind GeoServer-Cloud is to accommodate the needs of those requiring scalable and resilient geospatial data management solutions within a cloud-native framework. It aims to simplify the deployment, scaling, and maintenance of geospatial services.

Camptocamp’s Role in Cloud-Native Deployments

Camptocamp’s involvement with GeoServer extends to contributions and deployments, making us a knowledgeable entity in integrating geospatial technologies within cloud-native platforms. Our expertise covers both the enhancement of GeoServer and the adaptation of GeoServer-Cloud, aimed at maximizing the benefits of these technologies for our clients. From performance improvements and security assurance to facilitating cloud migrations, Camptocamp offers tailored consulting services.

Consulting Services for GeoServer and GeoServer-Cloud

Organizations interested in leveraging GeoServer 2.25’s features or transitioning to GeoServer-Cloud may find Camptocamp’s consulting services beneficial. Our team is prepared to support projects from the planning stage through to full deployment, ensuring a smooth integration of these technologies into existing infrastructures.

Should your organization consider utilizing GeoServer or moving towards a cloud-native approach with GeoServer-Cloud, we encourage you to get in touch. Camptocamp is here to provide the necessary expertise and support.

For further information or to discuss your project, please visit our website or contact me. Camptocamp is committed to assisting you in achieving an effective and scalable geospatial data management system.

GeoParquet 1.0.0 is Here, and It's Changing the Geospatial Game

Emmanuel Belo — Thu, 21 Sep 2023 09:39:14 +0000

Introduction

The GeoParquet community has reached a significant milestone with the release of GeoParquet 1.0.0. With over 20 different libraries and tools already supporting the format and hundreds of gigabytes of public data available, GeoParquet is rapidly emerging as a standard for geospatial data. The 1.0.0 release marks a turning point, signifying a stable foundation that promises to impact both the geospatial and the broader data science community significantly. Let's explore what this means and why you should be excited.

What is GeoParquet, and Why Does it Matter?

GeoParquet aims to standardize the way geometries are encoded in the Apache Parquet format. One of the standout features of GeoParquet is its efficiency. Compared to traditional formats like shp, gpkg, or fgb, GeoParquet files are generally smaller. This is thanks to Parquet's default compression scheme. Furthermore, GeoParquet boasts impressive speed, a characteristic owed to its columnar architecture.
Not just another file format, GeoParquet has proven itself as a versatile and efficient option for geospatial data, making it ideal for cloud-native geospatial distribution and day-to-day operations in geospatial science.

Understanding GeoParquet's Immutability in Relation to Its Columnar Format

The columnar format is a cornerstone of GeoParquet's design, impacting how it stores and interacts with data. Its immutable characteristic is deeply intertwined with its columnar nature, offering unique advantages and insights into its design philosophy. Let’s examine this relationship in more detail.
Traditional row-based storage systems arrange data in consecutive rows, making them optimized for transactional operations. In contrast, columnar storage systems store data in columns. This means all values of a single attribute (or column) are stored together. This organization is particularly advantageous for analytical operations where typically only a subset of attributes are needed for a query.

Immutability in Columnar Systems

Efficient Compression: One of the benefits of columnar storage is its ability to achieve high compression rates. Data in a single column is often similar, lending itself well to compression. When data is immutable, compression algorithms can work more efficiently as the structure of the data remains consistent, and there's no need to accommodate potential in-place modifications.
Data Integrity and Consistency: Columnar systems, like GeoParquet, deal with large amounts of data. Immutability ensures that once written, the data remains consistent, reducing complexity and potential errors in concurrent read/write operations. There's no risk of reading partially updated columns, which can be crucial in analytical tasks where data accuracy is paramount.
Optimized Read Operations: The design of GeoParquet is inherently geared towards read-heavy operations typical in analytics. Immutability reinforces this by ensuring that the data structures optimized for reading aren't compromised with the overhead of handling in-place updates. Thus, query performance remains swift and efficient.
Simplified Data Versioning: In a world where tracking changes and data provenance is vital, immutability in a columnar system simplifies versioning. Instead of tracking changes within a file, new data writes result in new versions, making it easier to trace back through data history.

Integration with QGIS

Given that QGIS has now integrated GeoParquet visualization support for Windows and Linux users, it's essential to understand the workflow:

Users can effortlessly load and visualize GeoParquet data within QGIS.
While analysis and visualization are fully supported, any modifications or edits to the data will necessitate the creation of a new GeoParquet file, rather than altering the existing one.

For those accustomed to formats that support in-place edits, GeoParquet's approach might require a slight adjustment in workflow. However, the benefits of data consistency, integrity, and enhanced performance make it a worthy trade-off.

GeoParquet & The Cloud-Native Revolution

At its core, cloud-native refers to a design approach in which applications are built, deployed, and operated at scale in cloud environments. These applications leverage cloud architectures, employ microservices, and are containerized, ensuring they are scalable, resilient, and easily maintainable.
In the geospatial domain, the introduction of GeoParquet as a preferred data format dovetails perfectly with cloud-native storage solutions.

Scalability: GeoParquet, with its compactness and optimized design, is well-suited for the vast storage capacities that cloud platforms offer. Users can store terabytes or even petabytes of geospatial data without worrying about physical infrastructure constraints.
Efficiency in Data Retrieval: Cloud-native storage systems, such as Amazon S3 or Google Cloud Storage, are designed for high-speed data retrieval. Given GeoParquet's columnar format, queries can efficiently fetch only the necessary columns, reducing I/O operations and costs in cloud environments.
Immutable Nature: GeoParquet's immutable characteristic aligns with the cloud's object storage model, where data objects are typically write-once and read-many. This match ensures data consistency, especially in distributed cloud environments.
Cost-effective: By combining GeoParquet's compression capabilities with cloud storage's often pay-as-you-go model, organizations can achieve cost savings both in storage space and data transfer.

What's Next for GeoParquet?

The 1.0.0 release is not the end but a new beginning. The format is now undergoing the rigorous Open Geospatial Consortium's standardization process. This ensures that GeoParquet will be globally recognized and adopted, further solidifying its status as the go-to option for geospatial data.

Discover Camptocamp's Expertise

If the journey to the cloud seems daunting, or if you're looking to optimize your existing cloud strategy, we have the perfect partner in mind. Camptocamp stands at the forefront of geospatial cloud solutions, bringing years of expertise and a passion for innovation. Their dedicated team of specialists is equipped to:

Guide Your Cloud Transition: From initial consultations to full-scale migrations, Camptocamp is your trusted partner in the cloud journey.
Optimize Geospatial Workflows: With a deep understanding of GeoParquet and other geospatial tools, they can help you harness the full power of geospatial data in the cloud.
Provide Tailored Solutions: Every organization is unique, and so are its cloud needs. Camptocamp crafts bespoke solutions that align with your specific goals and challenges.

social media bookmarks

Emmanuel Belo — Fri, 20 May 2022 15:04:00 +0000

Awards

swissgeol.ch Geospatial World Forum Award
- GWF linkedin
- Swisstopo linkedin

Events

2022

Lyon Métropole GIS day [FR]. Presenting open source GIS solutions: LinkedIn
GeoMapfish Users Group Meeting in Yverdon: LinkedIn

2021

IGN GeoCommun workshop in Paris, France Lindkedin

Open Source contributions

OpenLayers WebGL Vector renderer GitHub
Cloud Native GeoServer Project Donation GitHub

QGIS Hackfest

Emmanuel Belo — Fri, 20 May 2022 08:31:15 +0000

This year's QGIS contributors meeting will take place in Florence, Italy. QGIS has established itself as the leading Open Source GIS software. It includes a desktop application and a server part for streamlining map publication. The maps you prepare from your desktop are one click away from being published on the web as OGC webservices. QGIS provides an excellent open source alternative to ESRI ArcGIS Pro and benefits from a large and vivid community.

You can register here: 24th-Contributors-Meeting-in-Firenze

A QGIS Contributors Meeting is a volunteer-driven event where contributors to the QGIS project from around the world get together in a common space - usually a university campus. The event is normally three days in duration and we hold two such events each year. During these events, contributors to the QGIS project take the opportunity to plan their work, hold face-to-face discussions and present new improvements to the QGIS project that they have been working on.

FOSS4G Conference

Emmanuel Belo — Thu, 19 May 2022 16:06:08 +0000

This year's FOSS4G conference takes place in Florence, Italy and the early bird registration ends by June, 30. So make sure you get your ticket early enough!

Camptocamp supports the event with a sponsorship and many of our colleagues will participate in the event. We submitted multiple talks which got accepted by the program comitee. This will be the opportunity for you to get to know more about our solutions, projects and engagement in the open source communities. Watch out for the following talks:

Contributing to Geospatial Cloud Native Solutions
GeoMapFish Project status
MapFish Print Project status
Favoring Opensource Technologies for French Fire Brigades
GeoNetwork
GeoServer-cloud: Cloud Native GeoServer in production environments
2021 vector tiles R&D with baremaps
Implementation of the Chinese Postman Problem in the Valhalla Routing Engine
pgRouting optimization: from technical to functional
Datahub: the confluence of open data and geo data
ogc-client
swissgeol.ch - Geology in 3D: new features
The Carto 2 Project

and the following workshop:

geOrchestra

FOSS4G is the acronym for Free and Open Source Software for Geospatial. It is the annual recurring global event hosted by OSGeo, the non-profit organization that supports and promotes the collaborative development of free and open source geographic technologies and open geospatial dataFOSS4G is the annual conference of the OSGeo organisation

If you’d like to engage in a conversation on this topic, please connect, we’d be happy to help!

Cloud Native Geospatial

Emmanuel Belo — Thu, 19 May 2022 15:46:33 +0000

I participated with Camptocamp in the Cloud-Native Geospatial Outreach Event organized by the Open Geospatial Consortium in April 2022.

Cloud native solutions are currently a hot topic in the geospatial industry and Camptocamp is participating in the effort of bringing the open-source stack in the cloud. Camptocamp is one of the main open source service providers offering both geospatial and DevOps expertise to it's customers.

As a few examples you can have a look at:

The new cloud native version of Geoserver initiated by Camptocamp and donated to the community: Cloud Native Geoserver
GeoNetwork research and development initiatives to migrate to Elasticsearch, as a scalable metadata indexing system and the current software architecture migration to microservices: GeoNetwork Microservices
Our OGC API STAC implementation in Rust, a very modern and efficient programming language. We initiated this project during last year OGC API code sprint meeting: OGC API Rust Implementation
Custom vector tiles generation with Baremaps, a very performant and flexible solution to create your own vector tiles: Baremaps
And of course, the many geospatial projects we have been running in the cloud for years, leveraging the power of AWS, Azure, OVH, Deutsche Telekom Cloud and others for reliable and scalable operations.

In addition, our DevOps experts work tirelessly to automate and ease the provisioning and management of cloud servers and services. In this context we released a very interesting infrastructure as code management system, making your geospatial data infrastructure cloud agnostic and called the DevOps Stack.

If you’d like to engage in a conversation on this topic, please connect, we’d be happy to help!

DevOpsDays Conference

Emmanuel Belo — Thu, 19 May 2022 15:37:43 +0000

I participated with Camptocampto the international DevOpsDays Geneva conference 2022. The conference covers topics of interest to both Operations and Development, with a focus on Open Source, Agile and early Cloud Adoption.

In the Geospatial field, we are focusing on Agile software development, Open Source contributions and DevSecOps. These topics are nowadays the 3 pillars for executing successful innovative projects at scale.

At Camptocamp we develop and operate our solutions.

Our DevOps culture leverages cloud native workflows, being active in multiple countries with both sovereign cloud providers (OVHcloud, Scaleway, Exoscale, Deutsche Telekom Open Telekom Cloud) or the international market leaders (Amazon Web Services (AWS), Microsoft Cloud Azure, Google). It’s a real asset for our customers to deploy their massive geospatial data in the cloud and let us build scalable applications using highly robust services.

Speaking about open innovation and co-creation with our customers, the Software Development workflows align perfectly with our Infrastructure as Code approach of IT management. Provisioning, developing, improving and adapting rely on code changes and pull requests, for both the Operations and the Development. This unified model allows everyone to participate and speeds up processes, allowing agile software development to thrive.

If you’d like to engage in a conversation on this topic, please connect, we’d be happy to help!

Hello x/y/z!

Emmanuel Belo — Wed, 29 Apr 2020 11:52:31 +0000

Hello World!