Open Standards and Open Source Software Code Sprint: Mentored Projects
Please add here information about your proposed projects.
pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML.
pygeoapi supports publishing vector data as OGC API Features, using a series of providers, one of them being the document database MongoDB.
The MongoDB section on the pygeoapi documentation helps users to configure pygeoapi, in order to use this provider. Currently, this section is very minimal. Here are some suggestions to improve this section:
- Add one sentence description of MongoDB (see other providers like OGCR as an example).
- Add any other information you may think it is relevant for people attempting to use this driver - for instance, how they can convert a GeoJSON into a format that is digestible by MongoDB.
In order to gain an understanding of how to use MongoDB as a backend provider for features in pygeoapi, you may try to run it first. This is a docker-composition to help you with that. If something does not work as expected, please fill an issue on the pygeoapi issue tracker
If you want, here is another example of how-to use pygeoapi with a MongoDB provider. You can read more about it, in this blog post.
An issue for this project was created here. If you plan to work on it, please assign yourself to the issue, so that others know you're working on it.
When you're ready, you can update the documentation with a Pull Request. The pygeoapi project thanks for your contribution!
Mentors for this project: @doublebyte1
This docker-composition provides an example of how-to use pygeoapi with the MongoDB provider, for publishing collections as OGC API Features. The example still uses MongoDB 5.03, although Mongo 6 was released more than one year ago.
It would be useful to test if the example still works with mongo 6. If it does, we should upgrade the tag of the docker image. If it doesn't, then we should at least create an issue to investigate it further.
An issue for this project was created here. If you plan to work on it, please assign yourself to the issue, so that others know you're working on it.
When you're ready, you can update the docker-composition with a Pull Request. The pygeoapi project thanks for your contribution!
Mentors for this project: @doublebyte1
GeoAPI 3.0 is an OGC standard published in 2011 and updated in 2017 and 2023.
GeoAPI defines Java interfaces in org.opengis packages
for performing tasks related to metadata and referencing services in an implementation independent way.
Known implementations are
Apache Spatial Information System (SIS) and
JNI binding for PROJ.
The GIGS test suite, described below, is an example of GeoAPI usage.
On the GeoAPI 4.0-SNAPSHOT development branch, GeoAPI contains experimental Python interfaces in opengis modules.
The Python interfaces cover approximately the same services than Java interfaces, namely metadata and referencing.
Those interfaces are implemented by a small proof of concept using GDAL.
This work is still in progress.
Having the same standard available in both Java and Python makes possible to expand GeoAPI interoperability across programming languages.
It is possible for a Python developer to invoke a GeoAPI method implemented in Java, and conversely.
This bidirectional interoperability is implemented by the geoapi-java-python module,
which provides a bridge between arbitrary GeoAPI implementations in both languages.
This bridge frees developers from the need to care themselves about the other language.
Developers of a Java library do not need to think about Python, and
Developers of a Python library do not need to think about Java.
The geoapi-java-python module will handle automatically the interoperability between those two programming languages
for the services covered by GeoAPI interfaces.
The geoapi-java-python module is currently implemented using Java Native Interfaces (JNI).
Consequently, this module contains C/C++ code which must be compiled and bundled together with the Java and Python code.
This is troublesome because while Java and Python and platform independent, C/C++ is not.
Distributing native code together with a Java application is difficult.
Fortunately latest Java versions provide a new mechanism which frees us from this constraint:
the Panama project.
The Foreign Function & Memory API is available as a
preview feature in Java versions 19, 20 and 21.
Tutorials are available here and
here for examples.
The proposed mentored work is to replace JNI by Panama in the GeoAPI Java-Python module, even if Panama is still a preview feature on Java platforms. If you would like to work on this task, please assign yourself or post a comment on the GitHub issue. The work would be done on a GeoAPI branch or clone, then merged by a pull request when completed.
Mentors for this project: @desruisseaux
The Geospatial Integrity of Geoscience Software (GIGS) tests are published by the International Association of Oil & Gas Producers (IOGP) Geomatics Committee. This is the same committee that publishes the EPSG geodetic database. The GIGS tests are available in a form that can be executed by Java software through the OGC GeoAPI 3.0.2 standard interfaces. Known implementations capable to run GIGS tests are Apache Spatial Information System (SIS) and JNI binding for PROJ. We propose mentoring for projects which would like to implement GeoAPI interfaces and/or execute GIGS tests. Volunteer for completing GIGS tests are also welcome.
Apache Spatial Information System (SIS) provides metadata, referencing services and some raster support we a strong focus on OGC/ISO standards. We propose mentoring for projects wanting to use (or try to use) Apache SIS for their referencing services or for exploiting geospatial data from TIFF or netCDF files.