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, @pascallike and other geopython mentors.
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, @pascallike and other geopython mentors.
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 dataset. 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.
GIGS tests data are published as text files, which are in turn parsed for producing JUnit tests. Those JUnit tests can be executed directly by the build system of a Java library, or can be executed by a graphical runner illustrated below:
GIGS tests are organized in series, the main ones being 2000, 3000 and 5000. Series 2000 is about creating geodetic objects from user definitions. Series 3000 is about creating geodetic objects from EPSG codes. Series 5000 is about performing coordinate operations. Currently only series 2000 and 3000 have been converted to JUnit tests. The most interesting series, namely 5000, needs to be implemented. 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 GIGSGeoAPI branch or clone, then merged by a pull request when completed.
Mentors for this project: @desruisseaux
Standard interfaces in the org.opengis packages were initiated at OGC in 2000.
GeoTools joined the effort 2 or 3 years later as one contributor among others,
then left the effort about 6 years later.
After their departure from the GeoAPI project,
GeoTools forked a milestone of GeoAPI in a state of work in progress,
then added their own developments on top of it.
The milestone forked by GeoTools was not an OGC release.
The only releases (as parts of larger standards before GeoAPI 3)
approved by OGC were 1.0, 2.0, 3.0.0, 3.0.1 and 3.0.2.
The GeoAPI history is explained in more details, with links to archives,
here.
GeoAPI is open source. Consequently forks are allowed by the license.
But ethic requires that forks change their package names for avoiding conflicts with the original project.
GeoTools has not done such renaming and uses the org.opengis name in a way that conflict with OGC standard.
Given that OpenGIS® is a registered OGC trademark and can legally not be used without OGC authorization,
GeoTools must either comply with OGC standard or rename their fork.
There is three possible strategies:
- Cut all links to GeoAPI: rename
org.opengispackages with a search-and-replace. - Gradual transition: comply with standard, and keep untouched for now the
org.opengispackages not yet in conflict with an approved OGC standard. - Immediate transition: comply with standard and rename the other
org.opengispackages.
Option 1 is easiest. Option 2 is the less disruptive one for users. Option 3 is not significantly easier or more difficult than 2. Any of those options can probably be completed during the code sprint by any volunteer. The result can be put on a branch with all GeoTools JUnit tests passing. At this point the conflict is technically resolved. The GeoTools project may want to take this opportunity for adding some refactoring of their own, but this would be an extra task not strictly part of the conflict resolution task.
If option 2 or 3 is selected and if GeoTools wants to participate to the definition of interfaces in org.opengis packages,
they are welcome to join the OGC GeoAPI Standard Working Group.
Mentors for this project: @desruisseaux, preferably together with a GeoTools volunteer if any.
The internal design of map projection implementations in Apache SIS makes them well suited to vectorization. In particular, Apache SIS does an effort for separating the linear parts from the non-linear parts of map projection formulas. The result is a larger fraction of map projection formulas handled by affine transform matrices, which are one of the most typical targets for vectorization, and a smaller non-linear kernel. We would welcome volunteer for experimenting the application of Java new vector API to coordinate operations in Apache SIS. Because vector API is still an incubating feature on the Java platform, that work would be done on an Apache SIS branch or clone.
Mentors for this project: @desruisseaux
Apache Spatial Information System (SIS) provides metadata, referencing services and some raster support with 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. The How to page can be used as a starting point, and should be expanded with new use cases.
Mentors for this project: @desruisseaux
The GeoStyler is based on multiple parsers to translate between different style formats.
As mapbox-styles are officialy supported by the OGC API – Styles the geostyler-mapbox-parser will increase in importance. The difficulty is that the conceptual approach of the geostyler-style is layer based like in SLD, OpenLayers, QGIS, etc. The mapbox-style on the other hand is map based and so the geostyler-mapbox-parser lacks some essential features that are needed to realize a seemless translation.
The goal of this project is to reevaluate the currently used concepts and identify missing features and add them if possible.
Mentors for this project: @kaivolland, @jansule.