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

What do iNat staff think about the idea of automatically adding an elevation field to records when they are created or edited? I’m thinking this would be a lightweight call to Macrostrat’s API. iNat would send the lat, long and maybe uncertainty radius to Macrostrat, which would return the elevation (and maybe a vertical uncertainty figure). Those one or two numbers would be stored in the iNat record and recalculated in the event of an edit.

The big benefit would be that Explore and Identify could use elevation as a parameter. That’s helpful in terms of Identify searches, especially in areas with variable topography. Western North America, the Andes, Alps and Himalaya are all areas where elevation range is big part of habitat suitability. And storing that data in iNat records would allow it to be graphed and reported like the phenology graphs do today.

I understand that there’s a big jump from “We can look up elevation via the UI” to “We added elevation data to 140m observations”, so it would be totally reasonable to progressively add in that data through whatever process is most efficient and only surface this to users once the data exists to back it up. But it does seems like a huge amount of value could be added through the addition of 140 million two- or four-byte integer fields.

Edited to add: Of course, private and obscured records should be excluded, and existing elevation data should be restricted if an observation is made private or obscured.

14 Likes

Awesome! I’m going to spread the word on this update (in my opinion pretty big!). There are going to be some folks who aren’t on the Forum much who will be very excited about the elevation, but especially about the convenient Lithology information!

2 Likes

That’s very cool, but I agree it would be nice to have that info saved for observations with occuracy less than specific number.

1 Like

The site doesn’t appear to be accessible in the country I’m in. Can’t tell if the server is blocked, or if the connection is just too slow for it to load.

I only use Chrome :)

Issue submitted.

Great feature!

I use Chrome as well and haven’t had an issue. It does pull a lot of data over the net if I move around/zoom a lot, but I expected that.

In terms of

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. Combined with the existence of (2D) error in position, calculating a meaningful error in elevation would be complex. I would think you’d need to actually have multiple calls for elevation to the area in a location’s accuracy circle, then a weighted average, or something along those lines. There’s also the issue that 2D accuracy isn’t well defined on iNat, is generated by different processes, and many observations lack accuracy entirely. Building a useful, consistent metric based on multiple noisy and/or ill-defined variables is very difficult. The actual methodology used would be important for users to understand and interpret the data.

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. Without a formal assessment of quality, the data could easily be erroneous and used incorrectly, leading to problems with data usage, distrust of iNat data, etc.

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.

*CV generated IDs could be considered here, but they still require a user to input them. The only “officially” machine-generated content I can really think of is automatic marking of some species in certain areas as cultivated via the DQA, but I may be missing others. This marking as cultivated is a conservative method as it actually prevents data export to GBIF by making observations casual.

1 Like

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.

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

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

5 Likes

This is very cool. Convenient timing, too, because I’ve been diving into geology rabbit holes lately.

3 Likes

Fantastic! I have been adding the elevation to my own observations for years using either a GPS unit or more recently from the elevation recorded on the camera phone. I made a custom Observation Field in Inaturalist called “elevation (m):”. Then I manually enter the elevation so that is is shown on each observation page. I tested using Macrostrat for about 20 of my own observations in Latin America including Costa Rica, Colombia, Ecuador and Peru, comparing against what I had recorded. Some were off by up to 100 meters but most of the readings in Macrostat were within just a few meters of the elevation I had recorded when taking the photos or from a GPS unit. I also review a lot of observations of Costaceae made by other people and I have had to enter the coordinates into Google Earth to get a rough idea of the elevation. Now it will be so much easier just to click on the Macrostat link!

4 Likes

That’s a bummer! Might be worth reaching out to Macrostrat and asking them about it.

By “small” I meant that technically I don’t think it was a heavy lift on our end, just adding some code to send to Macrostrat.

3 Likes

Access to things from Vietnam is always a bit of a hit or miss affair. If it’s not blocked, then the main internet cable connecting Vietnam to the rest of the world is ‘damaged’ (as they’re claiming now), but said ‘damage’ often conveniently happens around times of political ‘sensitivity’, and the excuses are sometimes hilarious… sharks attacking the cables being one of the more memorable ones from a few years back.

2 Likes

If you use the link be aware that you need to have ‘hardware acceleration’ active in your browser. It wasn’t in mine when I first opened the page. There are still issues if you have an old GPU but it does reduce the CPU load considerably if your GPU is active.

3 Likes

Oh, this is sooo nice! The altitude can change quite fast where I am, so it is a really nice feature.

3 Likes

Me: I don’t need any more apps on my phone.
The internet: https://rockd.org/

3 Likes

exactly - had to install it as well and now my phone constantly reminds me that I am running out of storage :grin:

I would find this to be very helpful on infrequent occasions—filtering observations by elevation isn’t something I want to do often, but on the occasions I do, the workflow involved in manually correlating observations with external elevation data is very inefficient.

From a pragmatic viewpoint, I think using the simplest implementation and putting an alert flag in the interface that links to something saying, “Here’s how we’re getting the elevation data. Estimating error isn’t feasible at the moment—there is error, but we don’t know how much. Caveat emptor!” would be perfectly reasonable. Maybe even assign every observation some default and very large uncertainty in data exports—something that would catch the eye of downstream data users enough to prompt them to check whether this is data they should be using. In other words, I think having data with these kinds of problems is fine if people are appropriately informed of the problems.

As mentioned above, I’ve encountered use cases where being able to filter by elevation would be very helpful, even if the elevation data were not at all reliable for serious downstream analysis—for instance, recently I was trying to aggregate all of my alpine observations in New Mexico to share with someone. In that context I don’t really care if it was at 12000 or 12500 feet because I could just filter for everything above 11000 feet and kick out the small number of non-alpine observations manually. And, for what it’s worth, most of these observations are associated with offline data that includes elevation from a meter-ish accuracy GPS—if I were doing anything more serious with elevation I’d be using that data or pulling it from the 1/3 arc-second USGS DEMs, there’s just not an efficient way for me to propagate that information to iNaturalist.

4 Likes

Also, for people interested in geologic maps for the US, NGMDB (ngmdb.usgs.gov) is another very useful resource, and probably a good complement to Macrostrat as the two are efficient for different things.

Thank you so much! Elevation is helpful for looking at altitude adaptations

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.