Altitude and Feature Requests

As many others have pointed out, having an altitude / elevation data field in the geolocation Details would be SUPER helpful. This data is already present in many geo-tagged photos, so all iNat needs to do is add a data field to collect it. This is low-hanging fruit! TONS of biogeography value for so little work…

I’m starting a new topic because I don’t understand why the previous altitude / elevation feature requests were closed, and @tiwane suggested starting a General discussion.

Please correct me if I am off base or posting in the wrong place. As I said, all of the previous discussions have been closed, so I don’t know how to vote for this as a feature request or otherwise ask for more clarification.

Previous posts:
https://forum.inaturalist.org/t/altitude-on-observations/1476

https://forum.inaturalist.org/t/filter-by-elevation/5606

https://forum.inaturalist.org/t/you-can-now-access-elevation-and-other-details-from-macrostrat-for-an-observations-location/39066/11

@rupertclayton @aspidoscelis @johngarrett @mamestraconfigurata
@andrewgillespie @kiwifergus

13 Likes

Elevation is such a basic feature of the environment that I would like to see it captured for iNaturalist observations, whether it comes directly from geo-tagged photos or is added by the observer. Of course there is the issue that GPS equipment is notoriously bad at registering the elevation accurately. Probably better than no data, though.

6 Likes

It should be extractable from the map location.

Elevation sensors in GPS and in phones are not very accurate, so it’s of questionable use if pulling directly from the camera itself.

8 Likes

The issue I see is not knowing/not having the aptitude to carefully enter altitude. If I’m shooting with a camera that can’t record geolocation of any sort, I have to enter a circle of uncertainty when uploading, and elevation might vary in that area – what then? It’d be tedious to record with a phone app and manually enter for each point in which it changes.

Maybe this isn’t how it’d be implemented; it could be optional, or might work in some other way I’m not thinking of. That’s just the main issue I see us running into.

This DOES seem like a very useful field to have, though. Would sure be beneficial.

2 Likes

Maybe it could be an average for that circle? I also don’t have a way to record that info reliably in the field. I have been trying to make my circles smaller lately so there would be less elevation difference across a smaller circle.

I agree that it would be a very useful data point.

1 Like

I hike semi-regularly and I never know the numeric value of the elevation I observe things at. So for me it would not be an useful feature as I would basically never use it. I suspect there are many others like me.

4 Likes

As someone who does most of my observations while hiking, I generally have a sense of my elevation when hiking. My gps capture is pretty good on my phone and suspect elevation would be accurate within a hundred feet most of the time. The biggest issue would be species observed at a distance where location and elevation would need to be manually corrected.

My guess is that elevation data would be more accurate for some taxa (plants) than others (birds). I also suspect that the taxa where elevation is more likely to be correct with automatic collection are those where researchers might be most interested in elevation data, ie taxa that tend to not travel great distances on their own.

2 Likes

I keep a GPS track for geotagging my photos and I love having the elevation data as part of my photos’ metadata, but I think making them part of elevation data on iNat is not really worth the effort. As has been said by others, elevation data from GPS devices is considered to be fairly inaccurate, and to my knowledge it’s not easy to record, edit, and display that accuracy in a meaningful way like it is with lat/lon data. For areas with steep terrain (where I suspect elevation data would likely be most useful), this is an issue that could be compounded (and it’s also where I think GPS signals are also likely to be blocked or semi-blocked).

There are a ton of Elevation and Altitude Observation Fields (and those are just for English!), so anyone can enter these data to their observations if they like.

I’m not a GIS person at all, but my understanding is that anyone who really needs elevation data can export observations and use a GIS program to obtain the data and evaluate its accuracy. If someone knows how to do this, they can write up a piece for Tutorials.

I think the Macrostrat link is a good compromise for those who are interested in elevation data but are not into recording and entering it.

3 Likes

Thanks everyone! Because so many devices already record this data, and there are some good use cases for it, there should be a really good reason to not include it in iNat. I’m still trying to understand what that reason is…

Accuracy: Sure its not 100% accurate now, but devices are getting better all the time, so this doesn’t seem like a good long-term reason. Even right now, it can be pretty good. I looked at a handful of my iPhone photos, some taken without cell service (in canyons). The altitude field seems to be accurate to better than +/- 100 feet on all of them (based on Macrostrat).

Usefulness: I understand not everyone needs it, but for many people it could be more meaningful than lat/long! Consider this: in the Western U.S. (where I live), what data would you rather have: lat/long, or State/elevation? For me, knowing an observation is from ~8,000 feet in Arizona, is much more meaningful than knowing it is near 35.33, -111.65. Even seeing a point on a map is mostly just useful to guess elevation.

Thanks again for your feedback!

3 Likes

what are the specific contexts in which you would consume this information? are you just wanting to see it as another data point for identifying individual observations? are you trying to do some sort of analysis using a large set of observations?

instead of trying to apply an elevation model yourself, you can also get the data via various APIs, assuming you have good coordinates to start with. theoretically, someone could write a browser extension that would get this information and display it on the observation detail page on the fly, but i’m not sure how useful that would be for most people.

1 Like

I strongly disagree. Maybe for very specific, very cursory glances it is more convenient. But from a data perspective this is not true. As others have noted, elevation can be retrieved from lat/long. The opposite is not true. So much info can be derived from lat/long, such as slope, elevation, climate, political geography, etc. Many of these vary greatly even at the same elevation.

2 Likes

I don’t value elevation data for my personal use of iNat, but I can speak a bit to potential research use. In my experience, elevation data uploaded by users to iNat would be of little to no use to researchers. The accuracy in elevation data from devices is very variable, based on device, topography, location, weather, and many other factors (more so than positional accuracy). Ad hoc, field-collected elevation data are going to be difficult to work with, as they aren’t produced by a standardized process and will have a lot of noise. The folks I know that do generate field collected elevation data use highly precise, dedicated units that almost no one is using on iNat or they have a grant that gives them a good chunk of money to create a DEM via LIDAR or some other process.

What researchers interested in elevation are much more likely to do is to use GPS locations to extract an elevation value from a DEM or similar. In areas with good DEMs, accuracy is likely to be higher than from a user-based device and just as importantly, will be created via a standardized, reproducible process.

Lastly, even if iNat did store and allow export of user generated elevation data, it would only be available for a limited subset of observations. If researchers wanted to use this elevation data, they would need to either restrict their analysis to only those observations with elevation (reducing sample size and creating bias) or use the coordinates of observations without elevation data to generate estimates of elevation as above. In which case, they would probably just do this for all points to be consistent, and ignore the user-generated elevation data.

In short, while there are probably some niche cases where user-generated elevation data might be useful for research, in most cases this data would not be useful.

6 Likes

I absolutely agree. I usually use a track generated by a free app on a very ordinary Android phone to geolocate my photos, not infrequently in narrow valleys and gorges where satellite reception is often not optimal, but checking the altitude subsequently against a reliable DEM shows it to be well within the +/- 100 foot tolerance cited by @conorflynn.
And as @pisum says, I imagine it wouldn’t be that technically difficult to :

If accuracy and reliability are the only obstacle, then I believe these “good coordinates to start with” should be the real cause of concern, rather than the altitude itself. And yet, the location is not only freely displayed but (rightly) obligatory for all observations.

One specific context is when IDing plants (but not only), where the altitude is often at least as important as the geographic location. Sure it may not be 100% accurate, but anyone aware enough to know it can be a determining factor in an ID is also going to be aware of the accuracy issue and make the necessary allowance. Of course it can always be extrapolated from Macrostat, but even one click more can slow things down when trying to keep up with the IDing.
I quite get it that serious researchers are probably going to want to re-generate the altitude information for the sake of conformity, but when available, is that a good reason for not displaying it on the observation page in the “Details” section under the map, perhaps with an “accuracy disclaimer”?

1 Like

in the Identify screen, the map view does also provide a terrain overlay with elevation lines that you could use to judge elevation.

the reason is that you have to make a lot of changes just to collect and make this data available.

I confess I have a very hazy idea of what might be needed technically and I do quite understand that it may just not be worth the effort. But, just as an example, all my photos are geolocated and have an altitude recorded with the standard (?) GPSAltitude exif tag. I don’t usually use my cellphone for photos, but I’ve just taken a test photo with the geotagging activated and I find that, together with the coordinates, the altitude has again been saved with the GPSAltitude tag. I realise this may not be the case for everyone and that the accuracy of the data may be questionable, but would it really be so difficult to simply have iNat import and display the data recorded in the GPSAltitude tag where available?
It may not be perfect, or standardised, or useful to everyone, but it does seem such a pity to lose this information if it could be made readily available just by importing another metadata field? But perhaps it just isn’t that simple… I do wish I understood these things better!
For a time, I did actually copy the altitude automatically into the caption metadata field where it was imported on upload into the notes. I stopped because I realised it seemed I was the only one concerned, but maybe I’ll start again.

I would like to see better support for elevation data in iNat. To discuss the issue productively, I think we need to distinguish between user-supplied and derived elevation data. I think iNat should treat these mostly separately.

Derived elevation data would use a digital elevation model to determine the likely elevation. iNat would send the latitude, longitude and horizonal accuracy as inputs and receive values such as elevation_derived and elevation_accuracy_derived as outputs, likely storing them as secondary data in the observation in the same way as geographical administrative regions are calculated and stored.

This derived elevation data would in principle be possible to obtain for all observations with location data, but iNat might choose to only add this data for observations with better horizontal (or vertical) accuracy than some limit.

These fields would not be editable, but if the user adjusted the location, iNat would peform a new lookup and update the elevation fields.

User-supplied elevation data for an observation would include data manually entered by the user and also data supplied by a GPS device. As @tiwane indicates, such data already exists in iNat through a bunch of Elevation and Altitude Observation Fields, but haphazardly. Standardizing the way this data is stored, e.g. in fields such as elevation_user and elevation_accuracy_user, would allow it to be queried much more reliably.

I accept all the arguments that people have made about researchers’ doing their own DEM calculations for any substantial work. That’s not how I envisage this info being used. I want to use it to filter iNat observations for the purposes of identification, and for that I really need the elevation to be something I can query in an iNat search. (To be clear, the ability to link from an observation to Macrostrat is great, but isn’t something that can be used in an iNat search.)

I think there could be a default search logic to combine both types of elevation data (if available). So my search might include the string &min_elevation=1000&max_elevation=1500&elevation_accuracy<200 and iNat would interpret that to search user-supplied elevation data in preference and derived elevation data where that isn’t available.

If I wanted to only search derived data I could search for &min_elevation_derived=1000&max_elevation_derived=1500&elevation_accuracy_derived<200.

I’m not sure what it would cost iNat to obtain and maintain an appropriate elevation model, but for now I’ll assume that’s not prohibitive. Adding two fields of derived data to the majority of observations would seem (to me) to be achievable over time.

If this functionality was implemented, I can see a bunch of “use cases” that would not otherwise be practical:

  • Search coarsely IDed observations within geographic and elevation boundaries to add identifications for particular species. For example, there are 330,000 observations of plants in Mexico ID’ed to family level or coarser, and I’m not likely to trawl through all of those looking to ID a species such as Cirsium nivale, but if I could add &min_elevation=3300 to my search and reduce the pool to say 5,000 observations, my work would be much more efficient.

  • Find wild observations more effectively. Right now, I can choose to include or exclude captive/cultivated observations in my search. But lots of people in cities upload photos of cultivated plants without checking the corresponding box. There are also wild observations with missing dates that are marked casual. In mountainous areas elevation provides a useful filter to exclude most cultivated observations. I could set a search filter to exclude observations from below the upper limit of urban areas (in the valleys) and still see observations from higher elevations nearby that are more likely wild.

  • Find misidentifications and location issues For example, Sisyrinchium conzattii has been found between 3300 and 3600 m. With searchable elevation data I could quickly see if iNat users have observed that plant above or below those elevations. If so, are the IDs correct? Are the locations correct?

  • Find range extensions. Continuing the Sisyrinchium conzattii example, maybe I come across several observations showing this plant growing at 3000 m and others at 4000 m. I confirm the identifications, and it seems clear that the locations are correct. Then it seems this plant really does grow above and below the range where it has previously been recorded. Certainly, more work might be needed to precisely document the location and elevation, but iNat allowed me to identify this broader range quite easily. Doing the same by exporting data is always going to be a lot slower.

9 Likes

Thinking more about this, I remember that I got my start in the natural sciences in botany. In the herbarium, voucher specimen always had a location and an elevation, and not some fancy DEM elevation, but just whatever the Topo map said, and later on, whatever the Garmin said. I learned about the flora of whole mountain ranges based on those elevations….

It’s strange not to see that in iNat, but maybe that’s my background speaking. After all, here we are 10 years in!

I understand if this is a big change to the data it’s probably not going to happen (soon). Lots of other priorities. In the meantime, I’m getting used to clicking through to Macrostat, and learning some geology along the way.

Here’s a random page from a biogeography book, it shows an interesting pattern of elevation and latitude. Someday I may have to figure out how to intersect iNat data with a DEM….

2 Likes

I think you may be right here. I too come from a botany background and altitude data is just such an intrinsic part of IDing or studying a plant that in the beginning I took it for granted that it would also be an important part of an iNat observation… to then be rather surprised to learn that not only it wasn’t, but couldn’t even be automatically imported when available. That’s when I started adding my own elevation data in the notes section of my observations. I stopped because no-one seemed particularly interested, but maybe I’ll start again after reading this post.
Edit: Just to show what I mean, I’ve just uploaded an observation with the elevation imported automatically from the caption metadata field. Not to everyone’s taste, but using Lightroom (or similar), it’s just a couple of clicks away and maybe for some organisms it could be useful (not this one obviously).

1 Like

I support the numerous interests to dispose information of altitude, so well to get useful information or to develop modelling or to detect mistakes or false identifications. Digital elevation model allows to get an altitude directly from the location (coordinates) and is already used. For example, the (free) DEM model used by the Biolovision citizen science Websites gives for any record the altitude. I could check it for plants (orchids) that this is highly accurate in France except for a few (very few) areas in the Alpes mountains. It works technically in Europe (but also for the Websites for records located in the Lesser Antilles, Indian Ocean, South America,…). It allowed to detect location errors for some species because located at an impossible altitude (ecologically).

3 Likes

@Lynkos - with Lightroom you can automatically copy the GPS Altitude field to the Title for a batch of photos? So then when you upload, it shows in the Notes?