In 2026, we are calling for both research and implementation proposals to further develop, improve and implement the approach of Digital Twins as a Service.
Geonovum is offering several smaller testbeds in 2026. A summary of the practicalities of the 2026 testbed can be found on this page, as well as recordings of information sessions and minutes of Q&A's.
The technical results of the previous testbeds are available at Github.
Testbed nLDT Phase 2: Processes
What sets a Digital Twin of the Physical Living Environment apart from a regular GIS or BI environment are the processes – such as calculations and analyses – and the use of agentic AI. Think of simulating, predicting and determining KPIs, enabling policy makers to make well-informed decisions. Throughout this process, the human always remains ultimately responsible.
Open, proven, and standards-based processes – accessible via APIs – make it possible to incorporate calculations and analyses into automated workflows.
The goal of this testbed is to encourage the adoption of uniform, interoperable standards for digital twins, based on the nLDT architecture (data, processes and visualization). The focus is on interoperable processes.
A distinction is made between: Adoption topics (based on proven and mature API specifications) and Research topics (aimed at identifying and removing obstacles to interoperability).
More information and a detailed explanation about the five implementation topics of Testbed Phase 2 can be found in the tender document hereafter.
- Adoption topic #1: Implement and validate OGC API Processes service
- Adoption topic #2: Complete and validate an existing OGC API Processes service
- Adoption topic #3: Implement and validate OGC API Processes client
- Research topic #4: App-Store / Recipes
- Research topic #5: Implement export & import of Web 3D Context Document
Download the full invitation to tender
Who can participate?
The tender is open to private and public parties, and to combinations of parties (consortia). In the case of a consortium, there is one party who acts as the contact point and contractor on behalf of the consortium for the tender with Geonovum.
On Tuesday, July 7th the testbed tender document is published on our website. Questions about the tender can only be asked by sending an e-mail to info@geonovum.nl, addressed to Bart de Lathouwer, coordinator of the testbed. These questions and our answers will also be published on the Geonovum website.
Timeline
7 July Call to tender open to send in proposals
16 July Information call (online) Register here
14 August Tender submission deadline
17-18 August Selection of parties
19-20 August Announcement of winners
20 August Kick off meeting at Geonovum in Amersfoort
28 September Open testbed session 1/2 day (Plugfest no 2)
27 October Open testbed session 1/2 day (Plugfest no 3)
3 November End of testbed and final presentation
23 November Final presentation of all participants (public & online)
How to apply?
Your tender must be submitted by sending an e-mail to info@geonovum.nl, addressed to Friso Penninga, director of Geonovum (deadline for submitting is Friday, August 14, 2026).
The tender is to be written in English and must at least contain:
- The implementation topic or topics you are applying for;
- Motivation for the implementation topic or – topics you are applying for;
- Plan of approach for each addressed implementation topic (maximum of four pages per implementation topic);
- References (including e.g. publications, projects, blogs, code on GitHub) and curriculum vitae for performers of the research, showing enough relevant knowledge and experience;
- An indication of the in-kind investment;
- Statement of agreement with the publication of the research results and deliverables under a CC/by license.
Download the full invitation to tender
Questions and Answers information session
On Thursday, July 16 we organised an information session. The following questions were discussed.
- Can you explain a bit more the Appstore idea. Is this a new Appstore specifically for DTaaS? Is the realization of this Appstore a follow up project or is this Appstore something that already exists or needs to be created for this testbed?
No, the concept of an Appstore can be used in many contexts. An Appstore is a catalog. There are multiple catalogues as output from the testbed from previous year. We are not looking for another Appstore, you can use one of the existing catalogs (DMI, OUP, PPB, Triply) but they must provide an answer in DCAT and support API Records.
- Could you explain in more detail how participants are supposed to work together?
You can group as a bunch of companies and respond to the call as one organization or you can group later. We encourage collaboration between the different parties and will also organize two Plugfests where all participants of the testbed come together.
- Topic #4: For what specifically are participants expected to establish technical specifications (is it just the metadata extensions)?
The participants are expected to establish the metadata for a recipe (not a service). There was a pointer to an inspirational source for what a recipe could look like what nearly came down to decoration of a recipe and then a directed acyclical graph. The answer we are looking for is how to represent that (there are multiple ways). The choice of the orchestrator was a topic in previous testbed, the graph executor could be CWL, Arazzo or any other.
- Are the existing nLDT-AppStore/Cook/CookBook repositories normative starting points?
No, they are there for inspiration.
- Should topic #4 proposals extend their architecture and formats or may applicants propose a substantially different recipe model and execution architecture?
You are free to solve the answer as you want. Applicants may propose a substantially different recipe model and execution architecture. This is a research topic and therefore we would like to learn from the market and how the Appstore cookbook should look like. We appreciate a separation of concern between an Appstore (catalog), which makes a reference to a recipe, and that the recipe itself sits in a web service, aka a cookbook. The recipe itself needs to be executed. These three columns in the sequence diagram need to be maintained. You are free to deviate from this, but integration into OGC API processes needs to be guaranteed.
- What is the minimum expected deliverable for a "recipe" in topic #4?
That is the metadata for a recipe, a cookbook service and a cook service (what the recipe ‘looks like’ schema).
- How will the applicant-provided use cases and in-kind contributions be assessed (requirements for the use case)?
We expect you to implement use cases which are relevant to Digital Twins.
- What distinguishes topic #1 and #2? What minimum functionality must exist for an application to qualify as "completing an existing OGC API processes service" under topic #2 rather than implementing a new service under topic #1?
In topic #1 you are new to API processes (no trace yet to an API process) and in topic #2 you already have a partial API processes implementation and would like to complete it. The goal is to have as many API process supported calculation modules on the market as possible so that we can populate the Appstore.
- Section 6.2 states the client must be implemented "in your visualization software." Does the visualization component need to be an existing commercial product, or is a client built on an open-source viewer framework (e.g., a web viewer we maintain) equally acceptable?
We believe they are equally acceptable. Our preference is that the software is offered to the market and that we have a client that is used.
- Should the client support secure endpoints (API keys / OAuth2 / OpenID Connect) or can we assume open endpoints for the testbed?
The security has been left aside for the moment and will be picked up later (when Dataspaces mature).
- Is the DMI Appstore the same as the PDX Appstore?
Yes, it is the same. You can use any Appstore or any catalog. We want to see federating catalogues rolling up or federating themselves in the future.
- Can you maybe explain what's smart and what's not smart to do in terms of being in several consortia and making different proposals?
The more variety you can bring in a consortia, the better. You can only make one proposal to the tender except if you apply for one of the research topics (topic #4 or topic #5) and it makes sense to combine it with one of the adoption topics. In that case, we might be able to make an exception.
- If we produce a closed source software (for implementing API processes) and someone else applies with it that implements the API processes, does this still fall within the scope?
Yes, because we don't want you to give away all your IP. This is an exception that we make on our normal applications where we would like to see how things are implemented and that could be used for inspiration. We do ask for your explanation on how the software performs. We want to accelerate the use of API processes in already existing processes.
- Do you advise collaboration for topics #1 and topics #2?
Yes, the more collaboration we see between the various topics, the better. That is one of the benefits of being interoperable. We want to create an open and safe environment within the testbed. All participants, the active and the passive ones (observers), should feel comfortable when sharing results. All information in any of the (future) meetings will be treated respectfully.
- What do you require for topic #1 for getting it done via processes? Do you need a business motivation to make it explicit?
We stimulate to fund a well-motivated existing calculation module above a new one. If there is an existing customer base, where the API processes are added on to, we can see more interoperability in the market.
- How much interest do you expect in the different topics in terms of applications?
We expect many applications for topics #1, #2 and #3. We think that the research topics #4 and #5 will be a bit more difficult, which could be that we will receive less applications here.
- What do you exactly mean by dissemination licenses and lasting effect of outreach beyond geo community?
We want to stimulate organizations that do not use API processes yet but would benefit from using the OGC standards. We would like to see your positive impact here, which we call geo-enabling.
- Do you select one or more applicants per topic?
We do fund multiple times, see page 4 of the tender document for the exact number of awards per topic.
About Digital Twin as a Service
Digital Twin as a Service is an activity under Zicht op Nederland of the Ministry of Housing and Spatial Planning. In Digital Twin as a Service, we are working on an architecture that allows you to build a digital twin in a modular and scalable way. We work out the standards and agreements required for this in testbeds. We do this together with companies, knowledge institutions and government organisations.
Why 'as a service?'
A digital twin is a powerful tool for visualizing, analyzing and assessing issues about our living environment. With Digital Twin as a Service, we are working on a modular system for building digital twins. This makes it easier to use a digital twin throughout the policy cycle, for different issues, and across different departments and organisations.
The concept explained in one minute
In this animation we explain the concept (watch original animation at https://youtu.be/fIGH3GIDGW8?si=iiifZ6MAnYQ84WRx)
External video URL