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.
