Small but, in my opinion, cool update. If you click on “Details” under the map of an observation, you’ll now see an option to view the observation’s coordinates on Macrostrat, which will tell you the elevation of the location as well as other details such as geology and physiography.
For example, if I go to this observation and click on Details under the map, I’ll see the link:
FWIW, the folks who run Macrostrat are a lab at the University of Wisconsin (they also make Rockd and Flyover Country, two cool mobile apps using the same data). I’m sure they’re not made of time and money, but they have been responsive to my requests and suggestions in the past, so if you have any, they’ve asked that you file issues in their Github repo.
It was interesting to see how most of the fault lines cut off suddenly west of Los Gatos (CA USA). I guess different map blocks are in use? Don’t explain (it would be over my head)!
The elevation information isn’t brought into iNaturalist, it’s all on Macrostrat. We just give you a link that shows you Macrostrat’s information for the observation’s coordinates.
Also, if an observation on iNat has a large accuracy circle (or is obscured) you could be getting elevation data that is quite different from the actual 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.
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!
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 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.
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.
