Tom Kralidis
Tom Kralidis is with the Meteorological Service of Canada and longtime contributor to FOSS4G. He contributes to numerous projects in the Geopython ecosystem.
Tom is the co-chair of the OGC API - Records Standards Working Group, chair of the WMO Expert Team on Metadata, and serves on the OSGeo Board.
Sessions
Welcome to the Open Source Geospatial Foundation, proud hosts of FOSS4G, and advocate for free and open source geospatial software everywhere. This is a call out to open source software developers; please join OSGeo and help us help you!
Join OSGeo today:
- Even just listing your project on the osgeo.org website is a great first step. Help us promote your technology so users can discover and enjoy your software.
- The OSGeo “community program” gives project teams a chance to join the foundation with an emphasis on supporting innovation and new projects. The foundation provides some direct support, assistance along with endorsement and recognition from our board.
- For established projects please join our “incubation program” to be recognized for excellence and as a full OSGeo committee.
Unlike other foundations OSGeo does not require that you give up or transfer any Intellectual Property; we simply ask that you be spatial, open-source, and open to participation.
This presentation gives clear instructions on how to join OSGeo, and representatives from recent successful projects will be on hand to answer your questions.
The Web has an increasing number of web applications being developed to freely provide their information and is a hub for open data publishing. For this to happen as a self-sustained ecosystem, data must be findable, accessible, interoperable, and reusable to both humans and machines across the wider web. This session delves into Web Best Practices for publishing data using open source and standards-based solutions.
The geoconnex.us project is about providing technical infrastructure and guidance to create an open, community-contribution model for a knowledge graph linking hydrologic features in the United States as an implementation of Internet of Water principles. This knowledge graph can be leveraged to create a wide array of information products to answer innumerable water-related questions.
Implementation has two parts: persistently identified real world objects and organizational monitoring locations that collect data about them. Both must be published to the Web using persistent URIs and communicated with common linked data semantics in order for a knowledge graph to be constructed.
The Internet of Water Coalition supports the first part with a Permanent Identifier Service and reference hydrologic reference features (e.g. watersheds, monitoring locations, dams, bridges, etc.) within the US.
In support of the second part, geoconnex.us takes advantage of pygeoapi using the OGC API - Features standard to publish structured metadata resources about individual hydrologic objects and the data about them. pygeoapi supports extending this standard by incorporating domain-specific structured data into the HTML format at the feature level, and allowing for external HTTP URI identification. In addition, pygeoapi’s flexible plugin architecture enables for custom integration and processes. This means that individual features from various sources can have structured, standardized metadata harvested by search engines and assembled into a useful knowledge graph.
This spatial feature-based linked data architecture enables data interoperability between independent organizations who hold information about the same real world thing without centralizing data infrastructure - answering important questions like, “Who is collecting water data about my local stream and its tributaries?” or “What data do we have about water upstream and downstream of East Palestine, Pennsylvania?”
In January 2022, OSGeo and OGC signed a new and updated version of the Memorandum of Understanding (MoU) that aims to maximize the achievement of the mission and goals of the two organizations: promoting the use of Open Standards and Open source software within the geospatial developer community. Identifying open source technologies that could be used as Reference Implementations for OGC Standards and validating OGC compliance tests are examples of activities that can take place within the scope of the agreement.
More than one year after the agreement was signed and almost one year after it was introduced to the OSGeo community in a keynote at FOSS4G 2022, this presentation will summarize all activities accomplished and future plans, including the establishment of the OSGeo Standards Committee within OSGeo and the organisation of the 3rd joint code sprint, in Switzerland, together with the Apache Software Foundation.
The presentation will also reiterate the benefits of the new agreement, which allows OSGeo charter members to represent the priorities of OSGeo in the development of OGC Standards and supporting documents and services.
pycsw is an OGC CSW server implementation written in Python and is an official OSGeo Project. pycsw implements clause 10 HTTP protocol binding - Catalogue Services for the Web, CSW of the OpenGIS Catalogue Service Implementation Specification, version 3.0.0 and 2.0.2. pycsw allows for the publishing and discovery of geospatial metadata, providing a standards-based metadata and catalogue component of spatial data infrastructures. The project is certified OGC Compliant, and is an OGC Reference Implementation.
The project currently powers numerous high profile catalogues such as IOOS, NGDS, NOAA, US Department of State, US Department of Interior, geodata.gov.gr, Met Norway and WMO WOUDC. This session starts with a status report of the project, followed by an open question answer session to give a chance to users to interact with members of the pycsw project team. This session will cover how the project PSC operates, the current project roadmap, and recent enhancements focused on ESA's EOEPCA, Open Science Data Catalogue and OGC API - Records.
pygeoapi is an OGC API Reference Implementation. Implemented in Python, pygeoapi supports numerous OGC APIs via a core agnostic API, different web frameworks (Flask, Starlette, Django) and a fully integrated OpenAPI capability. Lightweight, easy to deploy and cloud-ready, pygeoapi's architecture facilitates publishing datasets and processes from multiple sources. The project also provides an extensible plugin framework, enabling developers to implement custom data adapters, filters and processes to meet their specific requirements and workflows. pygeoapi also supports the STAC specification in support of static data publishing.
pygeoapi has a significant install base around the world, with numerous projects in academia, government and industry deployments. The project is also an OGC API Reference Implementation, lowering the barrier to publishing geospatial data for all users.
This presentation will provide an update on the current status, latest developments in the project, including new core features and plugins. In addition, the presentation will highlight key projects using pygeoapi for geospatial data discovery, access and visualization.
Keeping (OGC) Geospatial Web Services up-and-running is best accommodated by continuous monitoring: not only downtime needs to be guarded,
but also whether the services are functioning correctly and do not suffer from performance and/or other Quality of Service (QoS) issues.
GeoHealthCheck (GHC) is an Open Source Python application for monitoring uptime and availability of OGC Web Services.
In this talk we will explain GHC basics, how it works, how you can use and even extend GHC (plugins).
There is an abundance of standard (HTTP) monitoring tools that may guard for general status and uptime of web services.
But OGC web services often have their own error, "Exception", reporting not caught by generic HTTP uptime
checkers. For example, an OGC Web Mapping Service (WMS) may provide an Exception as a valid XML response or
in a error message written "in-image", or an error may render a blank image.
A generic uptime checker may assume the service is functioning as from those requests and an HTTP status "200" is returned.
Other OGC services may have specific QoS issues not directly obvious. A successful and valid "OWS GetCapabilities" response may not
guarantee that individual services are functioning correctly. For example an OGC Web Feature Service (WFS) based on a dynamic database may
return zero Features on a GetFeature response caused by issues in an underlying database. Even standard HTTP checkers supporting "keywords"
may not detect all failure cases. Many OGC services will have multiple "layers" or feature types,
how to check them all?
What is needed is a form of semantic checking and reporting specific to OGC services!
GeoHealthCheck (GHC) is an Open Source (MIT) web-based framework through which OGC-based web services can be monitored. GHC is written in
Python (with Flask) under the umbrella of the GeoPython GitHub Organization. It is currently an OSGeo Community Project.
GHC consists of a web-UI through which OGC service endpoint URLs and their checks can be managed,
and monitoring-results can be inspected, plus a monitoring engine that executes scheduled "health-checks" on OGC service endpoints.
A database stores results, allowing for various forms of reporting.
GHC is extensible: a plugin-system is available for "Probes" to support an expanding number of
cases for OGC specific requests and -checks. Work is in progress to provide a GHC API for various integrations.
Info, sources, demo: https://geohealthcheck.org