You can now access elevation and other details from Macrostrat for an observation's location

[rupertclayton]

@cthawley

@rupertclayton

What do iNat staff think about the idea of automatically adding an elevation field to records when they are created or edited?

I think that this would be pretty complex. The macrostrat data (as I understand it) is derived from multiple sources and varies in quality, so error in elevation would also vary depending on location on Earth.

It would be fine to focus on a simple implementation rather than implementing every feature and solving every edge case.

If Macrostrat can’t easily generate a vertical error estimate or if such an estimate would be unreasonably noisy, then let’s not attempt it.

If we feel that elevation would be meaningless for iNat records with large horizontal uncertainty, let’s only request an elevation for iNat records with horizontal accuracy better than a certain value.

@cthawley

I guess my point is, this might be useful for informal filtering, but I definitely wouldn’t want to publish data like this as a definitive field for download or to GBIF unless they were systematically quality tested with a transparent methodology.

I totally agree. It wouldn’t be appropriate to publish this derived data to other platforms.

@cthawley

I think data generation like this is also somewhat philosophically different from how iNat usually works which is that data is user-generated (or comes from user devices)*. The elevation data would be machine-generated which just seems to be quite different to me.

I would see this as data enhancement and interpretation, much like the way places work right now. I take a photo; my phone tags it with lat/long coordinates; I upload it to iNat; but iNat adds the context of the city, county, state, country, plus a bunch of user-created geographic boundaries. All of those are searchable secondary data.

A lookup-derived elevation field can operate much the same way (whether via Macrostrat or another source). It’s secondary data that is useful within iNat to find and filter observations, but we shouldn’t present it as being primary data.

This raises the issue of primary elevation data that may be present in an uploaded image (e.g. from EXIF) or hypothetically added by the observer if such a field were available. If iNat’s schema was extended to support such data, I feel that it should be stored independently from any secondary elevation data derived from a lookup. In the event that iNat reaches a point where both types of data exist, a future iNat search might query both fields. E.g. “Find Plantae observations in Kern County, CA where the elevation (either reported or calculated) is between 750 and 2500 m.”

Importantly, the usefulness of this data is not greatly compromised by some inaccuracy. If my search pulls in a plant that was really observed at 2689 m, I’m only slightly inconvenienced. If we display an elevation graph that uses slightly noisy data, the overall value of knowing the general elevation range for a species is still there.

The general concept of adding elevation data is one that has been proposed here earlier.

Feature requests:

https://forum.inaturalist.org/t/altitude-on-observations/1476/5
https://forum.inaturalist.org/t/filter-by-elevation/5606
https://forum.inaturalist.org/t/add-a-link-to-google-earth-for-altitude-information/37680

Forum discussions:

https://forum.inaturalist.org/t/how-to-determine-the-altitude-of-an-observation/16458
https://forum.inaturalist.org/t/an-optimized-workflow-to-determine-the-altitude-of-an-observation/17465