2.1.1.  Objectives

WP 1 focuses on identifying, documenting, and evaluating representative workflows that demonstrate the open-science principles of reproducibility, transparency, and interoperability. The purpose is to collect a diverse set of scientific workflows that can serve as test cases for the OSPD-2025 demonstrator and provide the metadata basis for reuse and cross-platform execution in later work packages.

Each workflow is described using common metadata elements.

The objective is to ensure each workflow can be referenced, discovered, and reused as part of a persistent demonstrator.

2.1.2.  Activities

Several “champion” workflows were proposed, documented, and refined by participating partners. Each workflow entry includes a short description, input and output definitions, processing steps, and references to associated repositories.

Current workflows under WP 1 as as follows.

These workflows cover a broad range of environmental applications—hydrology, cryosphere, marine risk, ecosystem monitoring, and coastal hazards—and collectively represent the core demonstrator use cases for OSPD 2025.

2.1.3.  Results

Each workflow entry includes structured descriptions of inputs, parameters, and outputs, along with repository references and draft STAC schemas describing example datasets. These materials provided the primary input for ontology alignment activities under WP 2 and for cross-platform workflow reuse experiments conducted in WP 3.

2.1.4.  Challenges and Next Steps

WP 1 highlighted several recurring challenges related to workflow description and discovery.

In particular, significant variation was observed in how workflows describe their inputs, outputs, and configuration parameters. While STAC provides a common foundation for dataset description, additional conventions or supporting artefacts were often required to document workflow-specific parameters and processing assumptions.

These observations directly informed the development of the Open Science Ontology in WP 2 and the identification of reusable specification patterns addressed through the OGC Open Science Building Blocks in WP 4.

2.2.1.  Objectives

WP 2 aims to define a minimum common ontology to represent workflows, parameters, datasets, and execution environments in a machine-interpretable manner. The ontology provides the semantic foundation linking workflow metadata (from WP 1) with platform capabilities and provenance information, enabling workflows to be described, shared, and executed consistently across participating systems.

The ontology design aligns with established standards and vocabularies, including:

Together, these foundations form a minimal, extensible model connecting workflows (“what is done”), parameters (“how it is configured”), and platforms (“where it runs”).

Additional ontologies required to address more specific concepts were reviewed and, where necessary, incorporated as modular extensions.

2.2.2.  Activities

The work focused on defining the ontology’s core structure and selecting reference models to ensure interoperability with existing community standards.

Given the use of STAC and the associated OGC API – Records and Features models, existing Building Blocks linking these to DCAT, GeoJSON, and GeoSPARQL provided a suitable baseline.

This baseline is compatible with a wide range of external communities such as EU Data Spaces.

PROV-O was adopted as the primary model for describing provenance, building on existing tooling and prior work aligning it with CWL schemas. However, it was observed that CWL, while precise, is too fine-grained for general ontology-driven workflow description due to the complexity of its schema structures.

As a result, an intermediate-complexity model was identified as necessary to describe workflows at a level suitable for discovery, reuse, and execution comparison. The wf4ever ontologies (wfdesc.owl and wfprov.owl) were therefore selected and evaluated for this purpose.

Elements from the wf4ever ontologies and the Common Core Ontologies (CCO) were reviewed and reused where appropriate to establish semantic alignment with existing OGC and FAIR data initiatives.

The resulting conceptual model includes the following workflow-specific components:

The ontology adopts a black-box execution model, in which workflows are described through their inputs, outputs, and provenance, without requiring disclosure of internal logic. Data inputs and outputs are described using STAC schemas, extended where necessary to support domain-specific parameters and metadata.

This abstract model can be augmented incrementally, allowing additional detail to be introduced through modular extensions and profiles as required by specific application domains.

2.2.3.  Results (to date)

WP 2 delivered an initial ontology framework connecting workflow descriptions, parameters, datasets, and execution activities across multiple platforms.

Figure 1

Preliminary mappings demonstrate that workflow metadata from platforms such as GEP and EarthCODE can be harmonized using PROV-O relationships combined with CWL and EarthCODE concepts. A first JSON-LD representation was implemented and tested for integration with the OGC Open Science Building Blocks and STAC-based workflow descriptors.

The evaluation confirmed the relevance of the wf4ever model for describing workflows and provenance at an intermediate level of detail, with cwlprov providing additional execution-specific information where required.

The use of JSON-LD for semantically annotating schema-based Building Blocks required the introduction of schema-specific ontologies. While these ontologies focus on structural elements, they were successfully used to support metadata generation and validation activities, including experiments with AI-assisted metadata formulation conducted under WP 4.

Metadata profiles required to describe workflows were aligned through a common mapping between OGC API – Records, STAC, and DCAT.

This alignment was validated through the publication of workflow, experiment, and product records in EarthCODE-compatible catalogues using existing OGC API – Records implementations, without requiring platform-specific modifications.

Overall, participants agreed that the ontology framework provides a necessary foundation for interoperable workflow description. At the same time, the work identified several areas requiring further investigation, including:

2.2.4.  Challenges and Next Steps

WP 2 confirmed that a minimal, modular ontology is both feasible and appropriate for supporting open-science workflow interoperability.

The black-box execution model proved effective for enabling workflow discovery and reuse without imposing constraints on internal implementation. At the same time, the experiments highlighted the limits of current provenance and schema mappings when attempting to capture execution context and platform-specific behavior in a consistent manner.

Further work is required to formalize profile constraints, extend validation rules, and strengthen alignment with evolving OGC components, particularly the Workflow Building Blocks and related STAC extensions.

2.3.1.  Objectives

WP 3 aims to validate the interoperability and reproducibility of scientific workflows across multiple computing platforms. The objective is to demonstrate that workflows described with standardized metadata, ontology elements, and reusable components can be executed in different environments while maintaining consistency in configuration, provenance, and results. This Work Package provides the practical validation layer of OSPD 2025, linking the workflow discovery and semantic modelling activities of WP 1 and WP 2 with the specification-oriented work carried out under WP 4.

2.3.2.  Activities

Workflow reuse experiments in WP 3 follow a collaborative approach involving three complementary roles:

Each workflow selected for WP 3 follows a structured testing approach:

This approach supports a transition from isolated, platform-specific workflow executions towards interoperable and reusable workflow descriptions.

2.3.3.  Results

By late 2025, several workflow reuse experiments have been carried out across participating platforms, including GEP, EarthCODE, and other OSPD environments. These experiments demonstrate that workflows described using shared metadata and reusable components can be prepared and executed on multiple infrastructures with limited adaptation. In particular, workflows and associated metadata were reused across EarthCODE-based environments and other OSPD platforms without requiring changes to the underlying platform implementations.

The reuse activities also provided practical validation of the Open Science Building Blocks, confirming their applicability while revealing areas requiring further refinement. In particular, workflow descriptions, parameter handling, and execution interfaces could be applied consistently, whereas the capture and interpretation of provenance information varied across platforms.

Detailed examples of workflow reuse experiments and validation results are provided in the annexes to this report.

2.3.4.  Challenges and Next Steps

The workflow reuse experiments confirm the feasibility of using common descriptions and interfaces to support interoperability across heterogeneous platforms. They also highlight several recurring challenges that are relevant for future refinement.

A key observation concerns provenance capture because, while existing provenance models provide a useful foundation, the experiments showed that execution context, runtime environment, and platform-specific behavior are not yet consistently captured in a way that fully supports traceability and reproducibility across platforms.

Another observation relates to the flexibility of current schema definitions: while permissive schemas support early experimentation, they can also lead to divergent interpretations during validation. This indicates the need for clearer constraints, profiles, or conventions to support more robust and predictable interoperability.

Overall, WP 3 demonstrates the value of the Open Science Persistent Demonstrator as a practical testbed for open science interoperability. The findings from the reuse experiments provide concrete technical feedback that informs subsequent refinement of workflow descriptions, provenance approaches, and reusable specification components, as further documented in the annexes and in the OSPD 2025 Building Blocks Report.

2.4.1.  Objectives

WP 4 develops and validates a set of OGC Workflow Building Blocks, modular, schema-driven components that define how workflows and experiments can be described, shared, and reused in an interoperable manner. These Building Blocks act as interoperability contracts, specifying the structure of APIs, schemas, and metadata elements used to represent scientific workflows across multiple systems. Their purpose is to consolidate the descriptive and execution models produced in WP 1–WP 3 into reusable technical assets aligned with broader OGC standards.

2.4.2.  Activities

The Open Science Building Blocks developed under WP 4 are maintained in the public OGC Incubator registry at https://ogcincubator.github.io/bblocks-openscience/. The registry provides machine-readable schemas, example encodings, and accompanying documentation.

Each Building Block defines a well-scoped specification component that can be combined with others to create complete workflow descriptions. The Building Blocks developed in OSPD 2025 focus on the following areas:

The Building Blocks follow a schema-driven approach, reusing existing OGC and external standards wherever possible. Semantic descriptions are inferred and refined based on validated workflow examples derived from reuse experiments conducted under WP 3.

Validated examples were used iteratively to refine schema structures and populate the registry. Tutorials and worked examples illustrate how Building Blocks can be composed and tested within the shared environment.

2.4.3.  Results

By October 2025, initial Building Blocks for Application, ApplicationPackage, Parameter, and Platform were drafted and published in the OGC Incubator registry. These Building Blocks demonstrate how workflow descriptions from participating platforms can be aligned to a common schema structure.

A consistent JSON Schema pattern was established, enabling validation of metadata examples derived from workflows documented in WP 1 and executed across platforms in WP 3. The Building Blocks were applied in practice to support workflow description, validation, and reuse activities within OSPD 2025.

The detailed definition, structure, and validation of the Building Blocks are documented in the Open Science Persistent Demonstrator (OSPD) 2025 Building Blocks Report (OGC 25-044).

2.4.4.  Challenges and Next Steps

WP 4 confirmed that the Building Blocks approach provides a practical and scalable mechanism for formalizing reusable workflow specification components.

At the same time, the work highlighted the need to carefully balance flexibility and validation. While permissive schemas support early experimentation across heterogeneous platforms, clearer constraints and profiles will be required to support more predictable interoperability. Validation activities also highlighted differences in schema support and validation behavior across platform implementations, reinforcing the need for incremental adoption and profiling of Building Blocks.

The experience gained under WP 4 provides a concrete foundation for future OGC Best Practice and standardization activities related to open-science workflow interoperability.

3.2.1.  Platform description

CS Group is involved as platform operator and delivers a dynamic and evolving research environment and an orchestrator that fulfills several key requirements: reproducibility, efficiency, interoperability, transparency, performance and scalability, monitoring and diagnostics, open standards and sharing.

AntFlow is a lightweight, standards-based orchestration platform developed by CS GROUP to streamline scientific workflow deployment and execution.

AntFlow follows a Git-first approach: workflows are packaged as OGC Earth Observation Application Packages (EOAP) stored in GitLab and are discovered automatically (based on repository metadata) and parsed at runtime. From these EOAP descriptors (graph CWL), AntFlow generates OGC API Processes process descriptions and submission schemas on-the-fly, so processes become available without custom service development and evolve as the underlying Git repositories are updated.

The platform is designed for standards compliance and interoperability, leveraging CWL, EOAP best practices, OGC API Processes, and STAC conventions for describing inputs/outputs. This architecture ensures reproducibility through version-controlled workflow definitions and efficient execution by optimizing resource allocation across heterogeneous computing environments. AntFlow supports deployment on hybrid platforms including cloud infrastructures, High-Performance Computing (HPC) systems, and local machines, enabling workflows to be executed where computational resources are most appropriate and cost-effective.

3.2.2.  Technology Stack

AntFlow is a new development built on open standards including:

AntFlow exposes the available processes through a standard OGC API Processes interface (e.g., process listing and execution endpoints). This API can be consumed by any OGC API Processes compliant client.

Jobs can be executed on heterogeneous backends (cloud/Kubernetes, HPC, or even local machine) through a distributed client-server architecture. The platform leverages open-source CWL runners including cwltool (the standard CWL implementation), Calrissian (for Cloud infrastructures), and Toil (work in progress) as execution backends. Runner client components automatically register with the server, advertise their computational capabilities (such as GPU availability, memory capacity), and claim matching jobs from the server.

In addition, AntFlow provides an ergonomic web interface built on top of the same standardized API. The UI generates process launch forms on-the-fly and adapts controls to the declared input schemas, including datetime picker, numerical range and EOAP standardized bounding box inputs (interactive map widget).

Access control is aligned with Git hosting permissions (users can only see and execute processes from repositories they can access). Process versions can be pinned to Git references (branch, tag, or commit), and a single repository can host multiple EOAPs that are discovered automatically.

3.2.3.  Prerequisites

Before accessing AntFlow, ensure you have:

3.2.4.  How to Access AntFlow

3.3.1.  Platform description

The EOX platform named EOxHub Workspaces provides a cloud-based platform environment that supports interactive analysis, workflow orchestration, and reproducible research for OSPD. It is built on open standards and open-source components, enabling scientists, developers, and platform operators to design, execute, and share workflows in a secure and scalable environment.

At its core, EOxHub Workspaces integrate JupyterLab for interactive development and exploration, and Argo Workflows for scalable, containerized execution of complex workflows, including support for parameterized inputs and reproducible outputs with the pygeoapi layer for exposing the Algorithm as a Service.

EOxHub Workspaces emphasize discoverability, interoperability, and reproducibility. Workflows are described and published as OGC API Records and STAC via the Open Science Catalogue (OSC, part of EarthCODE initiative), ensuring that execution environments and results are consistently documented and openly accessible.

3.3.2.  Technology Stack

Here is a summary of key features that are available with EOxHub Workspaces in OSPD.2:

3.3.3.  How to access

In the scope of OSPD, there is one dedicated workspace made available at https://workspace.deside.hub-ovh.eox.at/ using the deside namespace for experiments and attempts to reproduce the workflows.

3.4.1.  Platform Description

This OpenAPI showcases the EOEPCA Application Deployment and Execution Service (ADES) building block. Based initially on the ZOO-Project, the ADES is now an integral part of it, operating under the code name ZOO-Project-DRU.

The ZOO-Project is an open-source processing platform created in 2008 and announced in 2009 at the FOSS4G conference in Sydney, Australia. Released under MIT/X11 license, it provides a generic processing platform to facilitate communication between your existing software and libraries.

3.4.2.  Technology Stack

OGC API — Processes

The OGC API — Processes — Part 1: Core standard defines how a server implementation provides access to executable processes through a Web API and the capability to invoke them from a client application.

3.4.3.  How to access

Authentication To use parts of this API, authentication with an OpenID Connect Provider is required. For this demonstration, we will use a Keycloak instance. Endpoints that require authentication are marked with an open lock icon on the right. To authenticate, please press the button, then a window appears, as shown below.

Figure 2 — Window to set client_id and authenticate

From there, use the following client_id: ‘zoo-project’ in the section OpenIDAuth (OAuth2,implicit) from the available authorizations. The login interface shown below allows the authentication.

Figure 3

By clicking on the ‘OGC GitLab’ or ‘ORCID’ button depending on the type of user’s account, the process will continue. Once authenticated, the endpoint or any other secured endpoint will be used. In other cases, the user should get an exception response with a 401 status code.

3.5.1.  Platform Description

The Hartis OSPD Platform is a multi-user execution environment designed to bridge interactive scientific analysis with scalable, reproducible workflow orchestration.

3.5.2.  Technology Stack

Hybrid Interactive-Batch Execution System using:

3.5.3.  How to Access

3.6.1.  Platform description

Institute for Geospatial Understanding through Integrative Discovery Environment (I-GUIDE) is a National Science Foundation (NSF) funded institute that seeks to enable transformative discovery and innovation to tackle fundamental societal challenges by harnessing the large diversity of geospatial data being collected and managed by various organizations. With “geospatial data-on-demand” as its central theme, the I-GUIDE platform enables seamless integration of advanced cyberinfrastructure and cyberGIS capabilities to empower users to undertake computationally reproducible and data-intensive geospatial analytics at scale. The foundational unit of data on the platform is a knowledge element. Knowledge elements encompass datasets, codes, computational notebooks, learning modules, and research papers.

As part of OGC-OSPD, the I-GUIDE Platform demonstrated reproducibility of the Mangrove Biomass Estimation workflow hosted at https://github.com/starling-foundries/KindGrove

3.6.2.  Technology Stack

The I-GUIDE Platform consists of the following major components:

3.6.3.  How to access

The platform itself is accessible at https://platform.i-guide.io/ Specifically the OSPD-25 related knowledge element can be accessed at https://platform.i-guide.io/notebooks/e4cbbc02-b826-408d-84f3-a937bf34436f

3.7.1.  Platform description

Terradue participates in OSPD 2025 as a platform operator through the Geohazards Exploitation Platform (GEP). GEP is an operational open-science platform designed to support the exploitation of Earth Observation data for geohazards research, risk assessment, and monitoring applications.

GEP provides a persistent environment where scientific workflows can be deployed, executed, and validated close to the data. It supports reproducible research by combining standardized workflow descriptions, containerized execution environments, and structured metadata publication aligned with OGC standards.

Within OSPD 2025, GEP is used as a demonstrator platform to:

The platform is operated by Terradue and builds on experience gained from previous ESA and OGC initiatives, including the development and operation of Thematic Exploitation Platforms.

3.7.2.  Technology Stack

The Geohazards Exploitation Platform relies on a modular, standards-based technology stack, including:

This stack enables workflows executed on GEP to be described and registered in a manner compatible with other OSPD platforms, supporting interoperability and reuse.

3.7.3.  Role in OSPD 2025

In the context of OSPD 2025, GEP acts as both:

Workflows executed on GEP contribute execution examples, provenance information, and metadata records that are used to validate the Open Science Ontology and the OGC Open Science Building Blocks. The platform also provides feedback on practical aspects such as parameter handling, data access patterns, and execution constraints, helping to ensure that the proposed standards remain applicable to real-world operational environments.

3.7.4.  How to Access

Access to GEP within the scope of OSPD 2025 is provided through dedicated workflow descriptors and repositories. Selected workflows are packaged as Application Packages and made available through public version-controlled repositories, where execution descriptors and examples can be inspected and reused.

Access details, including workflow references and execution endpoints, are provided to OSPD participants as part of the demonstrator activities and are subject to platform usage policies at the platform web site https://geohazards-tep.eu/

3.8.1.  Platform description

Telespazio UK leads the delivery of the ESA EarthCODE ecosystem of platforms and also leads the delivery for ESA’s EOEPCA (Earth Observation Exploitation Platform Common Architecture). EarthCODE is ESA’s strategic initiative to bring its vision of a FAIR and Open approach in EO science, applications and industry, and of a sustainable open innovation ecosystem. It integrates:

1) the Open Science Catalogue, making it effortless to discover novel research outcomes from ESA Science Clusters activities; 2) access to commercial platform services; and 3) a wealth of community resources and tools that help maintain data and research quality.

The Open Science Catalogue has been used by OSPD to publish Workflow and Experiment metadata. In addition, the EOX Platform that is integrated into the EarthCODE portal has been used by OSPD to deploy and demonstrate existing workflows. Complementary to EarthCODE, the overall objective of EOEPCA is to evolve, develop, and operate the generic standards and interoperable software building blocks (software components) enabling consolidation and harmonization of federated EO cloud and platform offerings that can support common utilization domains of the EO Science, R&D, and applications community. As a result of this, the EOEPCA Demo Platform has been used by OSPD to deploy and demonstrate existing workflows.

3.8.2.  Technology Stack

The EarthCODE and EOEPCA technology stack currently applicable to OSPD includes:

3.8.3.  How to access

The EarthCODE ecosystem of Platforms provides access to a number of resources to support FAIR Open Science.

This includes the ESA Open Science Catalogue (live instance) which can be used to publish approved research. OSPD has made use of the ESA Open Science Catalogue (staging instance) which can be used to publish experiments and workflows for the purpose of OSPD. The EarthCODE ecosystem includes EOX’s EOxHub Platform and Terradue Srl Platform along with others. Access to the EarthCODE commercial platform services can be gained using ESA Nor Sponsorship NoR Network of Resources.

The EOEPCA Demo Platform was used by OSPD to demonstrate executing a workflow, as an OGC Application Package, on an available platform before attempting to reproduce this experiment on another platform, EOXHub Workspaces. The EOEPCA Demo Platform is accessed by teams further developing and experimenting with EOEPCA.

3.9.1.  Platform description

The OGC Rainbow is envisioned as a knowledge graph reference holding the ontologies and building blocks instrumental to sharing knowledge in the geospatial domain, and specifically in the case of the OSPD: open science.

The OGC Rainbow eventually needs to become capable of housing and presenting all aspects of reference objects (ontologies, vocabularies, etc.), specialist objects (Building Blocks, OGC Standards), and instances of certain things needed for demo — e.g. instances of workflows represented using this project’s WF ontologies.

Prez (https://github.com/rdflib/prez) is the underlying system that is used by the OGC Rainbow to host its knowledge graph in an API- and user-friendly way.

The details of the specific improvements made by KurrawongAI to Prez and the OGC Rainbow software in the scope of this project are listed in the annex in OGC 25-044, Open Science Persistent Demonstrator (OSPD) 2025 Building Blocks Report.

3.9.2.  How to access

4.1.1.  Challenges

The reproducibility attempts carried out during the project revealed a number of challenges that hampered the execution of workflows. The mitigation of these challenges is an important step towards cross-platform reproducibility.

4.1.2.  Computational Environment

Problems related to the computational environment are among the most common and complex challenges when it comes to reproducibility. This has also proven to be true in this project. For instance, the specification of libraries (or packages) and their versions was not always complete resulting in deviating computational environments created on the different platforms. Also, the kernels sometimes addressed the needs of a particular workflow. It was not clear how to configure it on another platform and if a differently configured kernel is actually a problem. The implications are equally complex: impeded executability caused by missing libraries or deviating outputs caused by deviating library versions.

4.1.3.  Documentation

Issues related to the documentation comprised two aspects: How to-guiding steps and documentation specifying the workflows themselves. While the steps to run the workflows were not always clear from the beginning, their description improved significantly after contacting the corresponding workflow providers and platform operators. However, this is probably specific to projects such as OSPD where the participants received dedicated funding and less common in “typical” research projects where documentation is perceived as an additional task and burden.

Each workflow came with inputs such as input datasets and parameters and produced some outputs such as tables or images. While the provision of inputs ensures executability, they were not clearly specified making it difficult to understand how the inputs need to be like and what is needed or possible when using other datasets (“replication”). In addition, it was not clear if the generated outputs were correct as there were no outputs to compare with (example results). The idea of using building blocks to specify inputs and outputs can greatly mitigate these issues.

4.1.4.  Accessibility

In some cases, the execution of workflows was only possible for users having an academic account. It was required to assign the same privileges to users not having such an account. This can limit reusability by a larger number of people. In other cases, credentials were required from third-party providers, which might become a problem if they apply similar or further restrictions.

4.1.5.  Platform Limitations

Challenges also apply to the platforms themselves. For instance, because of missing job states and log messages it was not always clear why a workflow execution failed or took longer. It is not easy to anticipate such issues as a workflow developer and address them beforehand. Hence, this and the aforementioned issues should be seen as lessons learned.

4.1.6.  Roadmap

{
  "id": "polarwarp",
  "type": "Feature",
  "conformsTo": [
    "http://www.opengis.net/spec/ogcapi-records-1/1.0/req/record-core",
    "https://stac-extensions.github.io/application/v0.1.0/schema.json",
    "https://raw.githubusercontent.com/EOEPCA/metadata-profile/refs/heads/1.0/schemas/application-type-argo-workflow"
  ],
  "properties": {
    "type": "workflow",
    "application:type": "argo-workflow",
    "application:container": true,
    "application:language": "Python",
  },
  "links": [
    {
      "rel": "vcs",
      "title": "Git source repository",
      "href": "https://github.com/gtif-cerulean/polarwarp.git",
      "vcs:type": "git",
      "vcs:branch": "main"
    },
    {
      "rel": "application",
      "title": "Polarwarp workflow",
      "href": "https://github.com/gtif-cerulean/polarwarp/blob/main/workflow.yml",
      "type": "application/x-argo-workflow-yaml",
      "application:type": "argo-workflow",
      "application:container": true,
      "application:language": "Python",
      "argo-workflow:": {
        "requirements": [
          {
            "temp_storage": "10GB"
          }
        ]
      }
    },
    {
      "rel": "application-originating-platform",
      "title": "EOxHub Workspaces",
      "href": "https://workspace.cif.hub-otc.eox.at/",
      "type": "text/html",
      "application:platform_supports": [
        "argo-workflow"
      ],
      "application:preferred_app": "argo"
    },
    {
      "rel": "related",
      "href": "https://harshness-map.gtif.eox.at/processes/execute-polarwarp-gcps",
      "type": "text/html",
      "title": "Trigger workflow via API provided by pygeoapi"
    }
  ]
}

$comment: >-
  Lat and Lon are actually not Latitude and Longitude but coordinates in arctic projection (EPSG:3413)
parameters:
  lon_min: 796454.0390764615
  lat_min: -2364879.127844905
  lon_max: 916915.4324799285
  lat_max: -2245914.126716489
  date: 2025-02-25
  num_gcps: 4