Olivia Guyot

This presentation is the follow up of the datahub paradigm presented last year: The confluence of geo data and open data. This time we will look at the metadata edition and maintenance aspect. Writing metadata to describe a dataset is an essential part of managing a catalog. Each record in a catalog has been written, or at the very least enriched, by actual humans. GeoNetwork is a very widely used open-source metadata catalog; as such, it offers powerful tools in this regard: custom edition forms, batch editing, templates, custom XSL processing, advanced edition in XML, etc. Despite all these features, authoring metadata is often felt as a difficult process, involving complex actions, convoluted validity rules and an intricate knowledge of metadata schemas like ISO19139. Our vision for this new metadata editor can be summed up in three phrases: - Make metadata accessible to everyone - Forget about metadata schemas - Build your own editor This editor is made to feed content into your Datahub. Whether you want to describe open data, geo data or anything else, the editor will make it simple for you! Come and discover the concepts behind the scenes.

None

Other people: Gravin Florent

OpenLayers is a powerful web-mapping library, and it has been around for quite a while. Far from being stuck in a past state where it offered most features anyone could expect, the community of contributors and maintainers are continuously pushing it forward, rethinking orientations and taking in new trends. Be it cloud-native formats, emerging standards or drastic performance improvements, more and more innovations are becoming parts of OpenLayers feature set. This talk will give you an overview of the past few years of development, and show in how many incredibly useful ways OpenLayers can be used nowadays. We will also discover the exciting developments that are shaping up for the future, and how all this is being made possible.

None

In the OGC world, you have a catalog to look for metadata/datasets, and the OGC API Features to fetch the data, paginate, filter and so on. The use cases have evolved since then and data consumers expect more complete abilities from their data catalogs. Nowadays we want to analyze, understand and reuse our datasets and providing such tools is a great way to encourage data owners to share and open their warehouse. A data API could then offer: Full text search on data points Data fetching, paging, sorting and filtering Data analytics, aggregation, computation Data joining And those operations should perform in an optimized and scalable manner. It's what GeoNetwork has offered for decades now, and GeoNetwork is taking the move to opendata to address all those use cases. You might have heard about columnar formats, and columnar vector formats such as Arrow, Parquet… After an introduction of the context and the expectation of a well shaped data API, we’ll present different approaches and types of flow architectures - Warehouse formats - Static files (parquet) - Index - Databases (PostGIS, Cytus) - Api models and implementation - OGC API Features limitation - Duck DB - Pure SQL And compare the different stack in terms of efficiency depending on various use cases. The final goal is to provide an API which serves search, analytics and dataviz purposes.

None

Other people: Gravin Florent