Merge branch 'main' into geospatialexplorerguide

Author: JanssenBrm

.gitignore

@@ -11,4 +11,7 @@ venv*
 **/.ipynb_checkpoints
 **/figure-docx
 **.docx
-.vscode
+.vscode
+package-lock.json
+package.json
+node_modules

.markdownlint.yaml

@@ -7,3 +7,5 @@ line-length:
 
 MD024:
   siblings_only: true
+MD033:
+  no-inline-html: false

.markdownlintignore

@@ -2,3 +2,4 @@ interoperability/algohosting.md
 interoperability/algohostingenv.md
 interoperability/geospatial_explorer.qmd
 interoperability/businessmodel.md
+interoperability/datahosting.md

_quarto.yml

@@ -32,19 +32,22 @@ website:
             text: Using openEO service
           - href: propagation/platforms.md
       - href: instantiation/index.md
-        text: Project Tools
+        text: Project Environments
         contents:
           - href: instantiation/usecases.qmd
             text: Use Cases
+          - href: instantiation/customisation.md
+          - href: instantiation/accessibility.md
           - href: instantiation/geospatial_explorer.md
           - href: instantiation/project_portal.md
-          - href: instantiation/user_workspace.md
-          - href: instantiation/ide.md
+          - href: instantiation/app_code_server.md
+          - href: instantiation/app_jupyterlab.md
+          - href: instantiation/app_qgis.md
           - href: instantiation/catalog.qmd
           - href: instantiation/documentation.qmd
           - href: instantiation/forum.md
       - href: propagation/index.qmd
-        text: Algorithm Services
+        text: Algorithm Support
         contents:
           - href: propagation/ondemandservices.qmd
           - href: propagation/usecases.md
@@ -84,6 +87,7 @@ website:
           - href: interoperability/definitions.qmd
           - href: propagation/service_development.qmd
           - href: interoperability/algohosting.md
+          - href: interoperability/datahosting.md
           - href: interoperability/algohostingenv.md
           - href: interoperability/geospatial_explorer.qmd
           - href: interoperability/businessmodel.md

css/components/_tables.scss

@@ -25,3 +25,17 @@ th {
   background-color: var(--greylight) !important;
   color: var(--darkblue) !important;
 }
+
+
+table.requirements {
+  td, th {
+    padding: .5rem;
+    vertical-align: top;
+  }
+  td:first-child{
+    min-width: 150px;
+  }
+  td:nth-child(2){
+    width: 40%;
+  }
+}

eo_service_usage/openeo_usage.md

@@ -2,13 +2,13 @@
 title: openEO based services
 ---
 
-APEx services that follow the [openEO](https://openeo.org/) standard are implemented as openEO processes.
+Context: use of APEx services that expose the [openEO](https://openeo.org/) interface standard, when implemented as openEO processes.
 
 
-Services can be executed through the tools that are provided by the different processing platforms.
-For OpenEO based services, there is an online user interface, web editor, Client Libraries (JavaScript, Python, R) and API.
+In general, services can be executed through the tools that are provided by the APEx supported platforms ("processing platforms" hereafter).
+For OpenEO based services, this is supported by an online user interface, web editor, Client Libraries (JavaScript, Python, R) and API.
 
-There are several ways to discover how a service can be executed. When publishing a service on the APEx, a service provider can choose to provide the following information in the service details:
+There are several ways to discover how a service can be executed. When publishing a service on the APEx Algorithm Services Catalogue, a service provider can choose to provide the following information in the service details:
 
 * An executable link which redirects the user to the user interface of the processing platform. If this is the case, an **Access app** button will appear when opening an EOplaza service.
 * Sample code in the service description on how to execute a service.

guides/file_formats.qmd

@@ -2,19 +2,19 @@
 title: File format recommendations
 ---
 
-Within the APEx interoperability and compliance guidelines, [PROV-REQ-01](../interoperability/algohosting.md) specifies
+Within the APEx interoperability and compliance guidelines, [DATA-REQ-01](../interoperability/datahosting.md) specifies
 the file formats that projects should use when publishing static data.
 The information on this page complement that requirement with more detailed recommendations on the use of these formats.
 Projects are encouraged to consult with the APEx team if they have a use case that does not fit within these guidelines.
 
-## Cloud Optimized GeoTIFF
+## Cloud Optimised GeoTIFF
 
-Cloud Optimized GeoTIFF (COG) is the most widely supported format for geospatial raster data, and also one of the most
+Cloud Optimised GeoTIFF (COG) is the most widely supported format for geospatial raster data, and also one of the most
 efficient in terms of access costs. It is recommended as the default option to consider when publishing static data products.
 When combined with STAC metadata, COG can produce self-describing, FAIR-compliant datasets that are easily consumable by
 various services.
 
-### Generating Cloud Optimized GeoTIFF
+### Generating Cloud Optimised GeoTIFF
 
 If you are not familiar with COG or GeoTIFF generation, it is recommended to format your GeoTIFF files using a recent version
 of GDAL to ensure that they are compliant:
@@ -23,33 +23,33 @@ of GDAL to ensure that they are compliant:
 gdal_translate world.tif world_webmerc_cog.tif -of COG
 ```
 
-### Organizing spatiotemporal multi-band datasets
+### Organising spatiotemporal multi-band datasets
 
 Many datasets have multiple bands (or 'variables'), or have a date associated with them.
-The general recommendation is to store a single band per GeoTIFF file, and to create STAC items with one asset per band.
-This layout is commonly used by many other datasets, and avoids complexities of multi-band GeoTIFF files, which can be
+The general recommendation is to store a single band per GeoTIFF file and to create STAC items with one asset per band.
+This layout is commonly used by many other datasets and avoids the complexities of multi-band GeoTIFF files, which can be
 challenging to use.
 
-An exepction to this are the 'RGB' style products, where three bands are used to represent a single image. In this case,
-creating a Cloud Optimized GeoTIFF with three bands is an option.
+An exception to this are the 'RGB' style products, where three bands are used to represent a single image. In this case,
+creating a Cloud Optimised GeoTIFF with three bands is an option.
 
 For associating time information, create one GeoTIFF per timestamp, and one STAC item per timestamp. The GeoTIFF format has
 not built-in support for conveying time information, but STAC metadata is supporting this very well.
 
-### Visualization in APEx Geospatial Explorer
+### Visualisation in APEx Geospatial Explorer
 
-To optimize visualization in the APEx Geospatial Explorer, additional guidelines have been established. Adhering to these
-guidelines will ensure that the data is effectively optimized for visualization on a map. Please refer to
+To optimise visualisation in the APEx Geospatial Explorer, additional guidelines have been established. Adhering to these
+guidelines will ensure that the data is effectively optimised for visualisation on a map. Please refer to
 [this page](../interoperability/geospatial_explorer.qmd#cloud-optimized-geotiff-cog) for more information.
 
 ## (Geo-)Zarr
 
 Zarr is a format that is gaining traction in the geospatial community, although it is not yet as widely supported as
-Cloud Optimized GeoTIFF.
-It's main advantage lies in its ability to store complex multi-dimensional datasets that go beyond a simple 4D
+Cloud Optimised GeoTIFF.
+Its main advantage lies in its ability to store complex multi-dimensional datasets that go beyond a simple 4D
 (x, y, time, bands) structure. Just like COG, Zarr allows for efficient cloud access.
 
-At time of writing, there are however these important caveats:
+At the time of writing, there are, however these important caveats:
 
 - GeoZarr aims to define how to store geospatial data in Zarr format, but this standard is not fully developed and lacks
   widespread tooling support.
@@ -62,5 +62,5 @@ At time of writing, there are however these important caveats:
 ## NetCDF
 
 NetCDF is a self-describing format with some properties similar to Zarr, but less optimised for cloud access. It can be useful
-for exchanging data cubes as single files through traditional methods. However it is less recommended for convenient
+for exchanging data cubes as single files through traditional methods. However, it is less recommended for convenient
 sharing of large datasets, for which either COG or Zarr provide better options.