ENVO and environmental APIs

[pbuttigieg]

Stemming from #1556 (comment), this discussion will explore how to crosslink ENVO content into APIs or other services which identify environments.

From @ben-norton:

Hello Everyone, First, I created an API endpoint that returns several land cover classification systems along with the administrative divisions from a latitude and longitude coordinates. Here are several examples (you can replace the lat and long values with anything you want). GBIF (Copenhagen) https://geoapis.io/api/v1/services/geography/land-cover/point?lat=55.7026&lon=12.5596 Smithsonian Museum of Natural History https://geoapis.io/api/v1/services/geography/land-cover/point?lat=38.8913&lon=-77.0261 Saguaro National Park West, Arizona https://geoapis.io/api/v1/services/geography/land-cover/point?lat=32.2912&lon=-111.1531 Nepal https://geoapis.io/api/v1/services/geography/land-cover/point?lat=28.4116&lon=84.1227 Hawaii https://geoapis.io/api/v1/services/geography/land-cover/point?lat=19.5317&lon=-155.2354

I've been working off and on with various land cover classifications for more than two decades. This subject is challenging, far more challenging than I realized when I first dove into the subject. A couple notes.

1. One of the most important aspects is spatial resolution, which is characterized in two ways.
   A. The resolution of the sensor on the remote sensing device (includes both airborne and satellite-based)
   B. The number of bands a spectral device measures. LandSat 9 has 10. ASTER has 255.
   Here, researchers develop a way to partition spectra into categories, which are labeled using some sort of ecoregion/biome category. This is very different from what you are attempting to accomplish here. (By the way, several excellent definitions are being proposed here.). I would be hesitant to go with a current scheme based on spectra rather than concepts. This is the work those projects need to better label their categories.
2. You can deduce many of the differences by reviewing the spatial resolution. This is usually buried in the methods.
3. The TEOW has a complicated background. Depending on where you look, several organizations are accredited with it. In brief, two organizations did the same activity in two ways and then published it under different names. This became abundantly clear when attempting to source each of the land cover classification systems in the API I created.
4. Uvardy was published in 1975. I'm skeptical of any system that divided the Earth's ecosystems into 193 categories in 1975. I think it was noteworthy for being the first of its kind and paved the way for future classification systems, but that is all.
5. pbuttigieg I think you explained the problem of continuity between systems very well. timalamenciak your followup is excellent. I don't think think you can map them. They weren't created with the rigors of ontologies in mind.
6. Koeppen Climate Classification is very good. I would split off climate and leave it to Koeppen. https://en.wikipedia.org/wiki/K%C3%B6ppen_climate_classification

For what it's worth, here's my recommendation. After reading through this issue, you all are clearly talented at semantics. I would put the existing system aside and define the terms as you see fit. This is the type of exercise that needs to take place. Let those systems map to you, rather than the other way around.

And

Also, the API queries spatial datasets in a PostGIS database. The datasets were preserved in their original state upon download. I changed column names, but didn't alter the source data in any way. They were downloaded as GDB or Shapefile > Loaded into PostgreSQL/PostGIS, then queried directly using the function:
ST_CONTAINS(geom, ST_TRANSFORM(ST_GEOMETRYFROMTEXT('POINT(".$lon." ".$lat.")', 4326),4326))
The GBIF endpoint returns a Marine Ecoregion. That doesn't make a lot of sense, but it's how the data is distributed.

[cmungall]

I'm very interested in this topic. In NMDC we have a shim layer that allows you to query NASA DAAC databases via the ORNL API and get back MIxS standardized properties like elevation, and qualitative terms for soil type and land cover mapped to ENVO: https://github.com/microbiomedata/geoloc-tools We use this for metadata augmentation and validation. I would like to come up with a common schema for the payload from environmental APIs like this. The idea is to provide mapped terms with full provenance about any mappings used (SSSOM-level), resolution, method, etc

…

On Wed, Dec 11, 2024 at 2:34 AM Pier Luigi Buttigieg < ***@***.***> wrote: Stemming from #1556 (comment) <#1556 (comment)>, this discussion will explore how to crosslink ENVO content into APIs or other services which identify environments. From @ben-norton <https://github.com/ben-norton>: Hello Everyone, First, I created an API endpoint that returns several land cover classification systems along with the administrative divisions from a latitude and longitude coordinates. Here are several examples (you can replace the lat and long values with anything you want). GBIF (Copenhagen) https://geoapis.io/api/v1/services/geography/land-cover/point?lat=55.7026&lon=12.5596 Smithsonian Museum of Natural History https://geoapis.io/api/v1/services/geography/land-cover/point?lat=38.8913&lon=-77.0261 Saguaro National Park West, Arizona https://geoapis.io/api/v1/services/geography/land-cover/point?lat=32.2912&lon=-111.1531 Nepal https://geoapis.io/api/v1/services/geography/land-cover/point?lat=28.4116&lon=84.1227 Hawaii https://geoapis.io/api/v1/services/geography/land-cover/point?lat=19.5317&lon=-155.2354 I've been working off and on with various land cover classifications for more than two decades. This subject is challenging, far more challenging than I realized when I first dove into the subject. A couple notes. 1. One of the most important aspects is spatial resolution, which is characterized in two ways. A. The resolution of the sensor on the remote sensing device (includes both airborne and satellite-based) B. The number of bands a spectral device measures. LandSat 9 has 10. ASTER has 255. Here, researchers develop a way to partition spectra into categories, which are labeled using some sort of ecoregion/biome category. This is very different from what you are attempting to accomplish here. (By the way, several excellent definitions are being proposed here.). I would be hesitant to go with a current scheme based on spectra rather than concepts. This is the work those projects need to better label their categories. 2. You can deduce many of the differences by reviewing the spatial resolution. This is usually buried in the methods. 3. The TEOW has a complicated background. Depending on where you look, several organizations are accredited with it. In brief, two organizations did the same activity in two ways and then published it under different names. This became abundantly clear when attempting to source each of the land cover classification systems in the API I created. 4. Uvardy was published in 1975. I'm skeptical of any system that divided the Earth's ecosystems into 193 categories in 1975. I think it was noteworthy for being the first of its kind and paved the way for future classification systems, but that is all. 5. pbuttigieg <https://github.com/pbuttigieg> I think you explained the problem of continuity between systems very well. timalamenciak <https://github.com/timalamenciak> your followup is excellent. I don't think think you can map them. They weren't created with the rigors of ontologies in mind. 6. Koeppen Climate Classification is very good. I would split off climate and leave it to Koeppen. https://en.wikipedia.org/wiki/K%C3%B6ppen_climate_classification For what it's worth, here's my recommendation. After reading through this issue, you all are clearly talented at semantics. I would put the existing system aside and define the terms as you see fit. This is the type of exercise that needs to take place. Let those systems map to you, rather than the other way around. — Reply to this email directly, view it on GitHub <#1570>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOKJVSCAYSHY6PHOKQ32FAINFAVCNFSM6AAAAABTNE4YTGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGY2TMOJQG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ben-norton]

@cmungall I couldn't agree more. My API was quickly created as a proof of concept with little attention to standardization. I've since rewritten it to make progress toward standardization. See https://geoapis.io/api/v1/services/geography/land-cover/point?lat=35&lon=-80

It's still far from ideal, but better.

[ben-norton]

I wrote a basic frontend to the API.
https://interactives.geoapis.io/app/

[timalamenciak]

This is incredible work. It would be great if such an API could be used to auto-fill a dataframe based on long/lat columns.