Since this is unlikely to be fixed anytime soon and the revamping will most likely take ages, I’ve gone ahead and installed the Stylus extension on my browser and created a code sheet that loads based on this rule:
When hovering the elapsed date in the bottom right corner of an observation card (e.g. “13d“) a tooltip is shown with the exact date. This is indeed very useful, however that date is unformatted and as such quite difficult to read (e.g. 2026-01-06T11:12:00+01:00)
It got buried in this thread (post 389) but I want to plug a fantastic website created @wy_bio here called iNat Explorer which covers most of the requests here, and maybe even some you hadn’t asked for yet!
I created a quick example of how it will help me, searching California for 2 species of oak (dark and light blue) and their hybrid (green) so that I could identify areas where there are likely hybrids, but which haven’t yet been identified or are under-counted:
You can also get much more granular, and make selections from a seemingly endless set of filters, allowing me to determine which wild oaks I had not already reviewed in CA that had ID disagreements and were also tagged with the observation field “possible hybrid” and to then sort by number of “faves” so that I could review any compelling oak hybrid observations that get buried in the growing pile of indeterminate genus/section level.
The UI takes a little getting used to at first, but the learning curve is pretty quick, and once you get used to it, there’s so much functionality in terms of filters and combinations you can apply.
I can’t really overstate how useful I’ve found the site, so if you’re looking for a function, check it out (click on ‘Filters’ to get started), and don’t forget to leave feedback on the forum post where the developer has asked and responded to feedback over time.
I didn’t see this in the topic by searching for “gps” or “latitude”, but it would be nice to be able to paste in decimal degree lat/lon into the location box to zoom into that area on the map (question was raised here):
– the point in both cases is some gauge of community activity on the observation. This would allow more targeted searches, either for observations that haven’t gotten much attention, or potentially for those that have gotten a lot of attention. (Though existing search by faves/disagreements is pretty good for surfacing observations with a lot of a specific kind of attention.)
Often while looking at a map of observations I would like to cross-reference against other online maps, but right now the only way to get lat/lon coords of a point on the map is to find an observation made there, open it, click “details”, and then you can see the coordinates. It would be super convenient if, for instance, right-clicking anywhere on the map opened a little pop-up with the coordinates and clicking them saved it to your clipboard (i.e., what Google maps and other platforms support). This would also remove the need for there to be an observation exactly at the point of interest.
Feature request details:
This is what it looks like Google maps. Inat wouldn’t need all the other options though, just the coordinates.
Yes, I agree, it should be easier to obtain the GPS coordinates of a point on the map, and right-clicking is the way to do it since other apps do it that way. It might be easier (to implement) if the request focused on the pin, as opposed to an arbitrary point. Currently if you right-click a pin, nothing happens. That seems to be the right place to expose the GPS coordinates of the observation (at least).
The observation search page currently features a Google Maps display mode, but I would like to see a Street View function added to this screen.
Specifically, the idea is that when an observation point is selected—either by clicking its marker or hovering over it in the observation list—Street View imagery for the location closest to those coordinates would be displayed. This would allow users to check the surrounding environment and, if Street View imagery exists for those specific coordinates, potentially view the observed subject itself.
Regarding plants in particular, Street View allows users to toggle the display across a timeline, offering the benefit of observing changes in the plant’s condition over time.
I believe that incorporating this kind of Street View integration into the redesigned search page would make it much easier to understand the geographical context surrounding observation points.
I would appreciate your consideration of this proposal.
You can also verify the effectiveness of the Street View display function—which is synchronized with the observation points on Google Maps—at the following URL.
You are assuming that a) most observations are made in areas where Street View is available (e.g. not in green spaces) and b) the location circle of most observations is small enough that this view will show the location where the organism was seen (not, say, the houses two or three streets away).
I don’t really see what value this adds, given that Street View is going to be largely showing settlements and thus organisms that are adapted to living alongside humans; an aerial map will also provide this habitat information.
Plants that are large enough to be seen from Street View are likely to be trees/bushes planted by people, and thus not the focus of iNaturalist.
to be fair, street view is sometimes available in places like parks in big cities, where a lot of observations are made. even though might be nice to have, i’m not sure what value it offers though, especially when implemented on the web observation detail screen (as opposed to, say, the upload screen).
i suspect that if iNaturalist wanted to implement this feature, they would have implemented long ago. although iNaturalist gets some mapping services provided for free by Google, it’s unclear whether street view would be one of those services, and if not it’s unclear why iNat would want to pay to provide that sort of service for its users.
I wonder if there might be unintended consequences with the street view idea. Might it make people less likely to post, or at least more likely to hide their geolocation, if they thought people might then be looking at images of their personal property? I realise that street view is already out there, and if people wanted to manually cross-reference it they could. But it’s not the same as having this information readily available on screen.
That is a very valid point.
I also believe that features involving privacy need to be handled with great care.
Regarding privacy-sensitive elements, the default setting should be private, ensuring nothing is displayed without the user’s permission.
I believe the system should be designed so that information is only made public when the user deems it necessary and decides to share it.
For the Street View feature in question, this could be implemented by including a UI element—such as a checkbox—on the observation data editing screen that allows the user to enable the display of Street View imagery for that observation point in search results.
Incidentally, it appears to be safe on iNaturalist, as the observation images displayed there have had personal information—such as latitude and longitude—stripped from them.
Feature Overview Video
Acer buergerianum Observation Record