4. map preview

[BerkvensNick]

The SWR Catalogue will display a map preview of a resource (dataset/knowledge/service/…) from the source graphic/WMS/…, if applicable.  https://github.com/soilwise-he/Soilwise-userstories/issues/20

Origin: D1.3 Repository architecture

• [x] map preview dataset
• [x] map preview knowledge
• [x] map preview service
• [ ] available from the source graphic
• [x] available from the source WMS

---

With acceptance criteria:

• Map Preview Dataset

• [ ] Users can search for datasets that have associated map previews.

• [ ] The search results include an indicator showing the availability of a map preview.

• [x] When a user selects a dataset with a map preview, a map is displayed alongside the dataset details.

• [ ] The map preview accurately represents the geospatial data associated with the dataset.

• [x] Users can zoom in and out, pan, and interact with the map preview.

• [x] Map layers can be toggled on and off for better data visualization.

• [ ] The map preview loads within 3 seconds after the dataset is selected.

• Map Preview Knowledge

• [ ] Users can search for knowledge sources that include a map preview.

• [ ] The search results indicate the presence of a map preview.

• [x] When a knowledge source with a map preview is selected, a map is displayed alongside the knowledge source details.

• [ ] The map accurately reflects the geospatial data referenced in the knowledge source.

• [x] Users can interact with the map (zoom, pan, toggle layers).

• [x] The map interface is intuitive and easy to use.

• [ ] The map preview loads within 3 seconds after the knowledge source is selected.

• Map Preview Service

• [ ] Users can search for services that offer a map preview.

• [ ] The search results clearly indicate the availability of a map preview.

• [x] When a service with a map preview is selected, a map is displayed alongside the service details.

• [ ] The map accurately represents the geospatial data or coverage area of the service.

• [x] Users can interact with the map (zoom, pan, toggle layers).

• [x] The map interface provides tools for better understanding the service area (e.g., markers, polygons).

• [ ] The map preview loads within 3 seconds after the service is selected.

• Available from the Source Graphic

• [ ] The platform supports integration with graphic sources (e.g., SVG, PNG) for map previews.

• [ ] Users can view map previews generated from source graphics accurately.

• [ ] Map previews from source graphics are clear and of high quality, without distortion.

• [ ] The graphic maintains its resolution and detail when zoomed in or out.

• [ ] The map preview from the source graphic loads within 3 seconds.

• Available from the Source WMS (Web Map Service)

• [x] The platform supports integration with WMS for map previews.

• [x] Users can view real-time map previews provided by WMS.

• [x] The WMS-based map preview includes standard functionalities such as layer selection, zooming, and panning.

• [ ] Users can access additional WMS features such as querying map layers for more information.

• [ ] The map preview from the WMS loads within 3 seconds.

• [ ] Real-time data from the WMS is updated promptly to reflect the latest information.

[pvgenuchten]

Available from the Source Graphic needs further clarification. Is it correct to assume that a png-preview is generated from for example a GeoTIFF. A workflow could be assumed, when the metadata is ingested, the GeoTiff is identified, a WMS service is set up for the GeoTiff and the metadata is enriched with a link to the WMS?

Alternative options:

• When a reference to GeoTiff is noticed, if the GeoTiff is a COG -> direct access to the COG is an option, if it is not a COG, a COG could be generated and the link added to the metadata
• Generate a png from any data file, and store the png as thumbnail (it displays a map, but the map is not georeferenced, so it can't be used in an interactive map.

[BerkvensNick]

@tomreznik do you have an answer for the higher question by Paul? It is related to the "available from the source graphic" in the requirement "A map preview of a resource (dataset/knowledge/service/…) will be available from the source graphic/WMS/…, if applicable." by JRC

[tomreznik]

Based on my experience, the majority of (meta)data providers follow one of these pathways:

1. Define a representative static PNG for data sets (resources in general) that are quite stable in terms of their content and visualisation.
2. A workflow, as described, e.g. through WMS. Then it could be as easy as WMS --> PNG or more complicated WMS --> GeoTIFF --> PNG.

For the first iteration, I propose to start with option 1. and work on option 2. as described by Paul.

[BerkvensNick]

@pvgenuchten a question raised during the cluster meeting Data & Knowledge:

LIAKOS Leonidas (JRC-ISPRA-EXT) (Neověřeno): If there are data in a repository (ie ESDAC), can SWR WMS be utilized to expose this data or does that mean an extra preprocessing step? I can imagine quite straigtforward way of WMS publication of ESDAC data preview once the SoilWise repository is integrated to the EUSO. We may elaborate on this during the upcoming scheduled JRC - SoilWise technical meeting.

[dluts]

@BerkvensNick it is not completely clear to me but it seems that person who asked the question assumes that the Soilwise respository will provide its own WMS service?

I think that all the above requirements do not necesitate the Soilwise respository to setup a WMS, rather the furnctionality counts on for example ESDAC providing its data through a publicly available WMS (or in the future maybe other view services)?

[pvgenuchten]

It is an interesting idea to use a dataset stored on esdac/zenodo/bonares as a source for a WMS service running on SoilWise infrastructure.

• Prior to that discussion we may need to understand if it is needed to use WMS, maybe similar functionality can be achieved by other mechanisms, such as direct access to the file (from the SoilWise website using javascript). • If indeed WMS (or an alternative api façade) does offer an enriched user experience, we have an option to interact with the remote source directly, or keep a (temporary) copy in the Soilwise infrastructure. • For WMS we then need some visualization rules, for it to display nicely (high=red, medium=yellow, low=green). User contribution (or AI generation) of style rules could be interesting here. • Also consider that the (novel) cloud optimised formats such as COG and GeoParquet are favourable for this use case, because only the requested section of the file is exchanged over the network. • Notice that platforms such as zenodo, dataverse, cordis may have protected their platforms for external applications to fetch data directly, this we will have to find out.

I expect Soilwise to come up with a series of recommendation on how to publish (spatial) data, and, if followed, users may expect a nice visualization of their data (not just within Soilwise, but in many places).