I have a feeling that Google Earth is copyrighted / not free to use. The only place I’ve seen Google Earth is… Google Earth. While Google maps can be used by organizations, companies?, and is quite widespread.
I believe this is the right spot but apologies if I have goofed up. Search and Explore seem interconnected so this seems right. I searched around and couldn’t find anyone who had asked for this.
Feature request: Search which excludes a list
We currently can search via a list (&list_id=XXXX) but the current exclusion options do not have a &without_list_id=XXXX option.
Use-case: I’m adding interesting/unique Observation Field floral IDs to insect observations. This mostly involves looking at 300 photos of bugs on sticks and moths on sheets for every one photo of a bug on a flower. For my sanity, I exclude super-common species like Apis melifera, Bombus impatiens, all Lepidoptera (the easiest way to filter moths), and others. I end up with an &without_taxon_id=a,b,c,d,e,f list that goes on and on. In order to update my exclusion search command, I have to build that csv of taxa IDs from scratch, because I don’t which number is which taxon. If I could exclude a list, I could get real precise about which species I want to avoid and reduce the bugs-on-sticks/moth-on-wall results I have to scroll through.
Thanks for considering!
Based on this conversation, can we have a toggle to turn off all observations, similar to the taxon page map?
This is only a very temporary solution though, which only works for one tab until it’s (even accidentally) refreshed, like you said.
It’s been almost 7 years since this was initially reported with no resolution, so I’ve opened a new bug report with a proposal that the iNat team could implement with minimal effort that doesn’t require the revamp of the entire page.
As many have already mentioned, using the map view on small screens (e.g. built-in laptop screen) works fine (see first screenshot below), however on larger screens the map itself doesn’t scale vertically and the controls and, more importantly, the list of observations are both centered on the map, instead of being aligned to the lateral edges of the window (see second screenshot below). This is a very poor use of screen space, especially for those working with external displays and higher resolutions.
I’ve seen similar posts from 2019 and again in 2023, so it really surprised me that to this day, almost 7 years after the original post, it still hasn’t been fixed.
Revamping this entire page has been on the roadmap for a long time but it is clearly a bottleneck for what could be a much better user experience. My suggestion is at least make some minor CSS changes to solve these issues with the current layout without affecting the DOM.
Proposed solution:
For example, fiddling a bit with developer tools I’ve noticed that the map itself is loaded inside an .obs-container element with a fixed height: 550px;. That height should not be fixed but instead be fluid and scale with the window height by subtracting the heights of the other elements above it (i.e. header/navbar, filters, stats) minus a bit of extra space to reveal some of the page footer so that the user can still scroll the page without the map hijacking the scroll function for zooming in/out. So its new height property would be:
height: calc(100vh - 57px - 109px - 75px - 100px);
Then the #obs element containing the list of observations should scale as well, so instead of the fixed height: 420px; it should also scale vertically. Unfortunately because of the nesting, giving it height: 100%; won’t work, so instead you can calculate it dynamically just like above, minus an extra 40px for the vertical margins around the map edges:
height: calc(100vh - 57px - 109px - 75px - 100px - 40px);
With these changes, the map and observation list will scale to any screen size (tested!).
Now the .container element has a fixed width: 1170px; which comes from Bootstrap, but it that can be overridden to width: 100%; so that the map controls and observation list can now shift to the sides of the map, making more working space.
Ideally the observation list wouldn’t become too wide on bigger screens, and I see that its parent element has the typical Boostrap classes col-xs-4 col-xs-offset-8 , but Bootstrap also offers other breakpoints, so for large or extra-large screens you could add col-xxl-2 col-xxl-offset-10.
With these suggested changes, here’s how the map view would look like on a 27” 4k display:
Oh, and changing that .container size to width: 100%; also improves the grid view, which can show significantly more observations per row, as shown in the before/after screenshots below:
As far as I know Bootstrap should already have .container-fluid class, but if the iNat version of Bootstrap is old, it can still be solved with CSS.
As explained here by @keirmorse, suggestion to add tiles for subspecies in the view “Species” of the Explore page.
No.
It is showing tiles for each leaf taxon. The parent taxa of each of the lower taxa are not represented separately.
Here’s a quote of the relevant part of my comment here that @jeanphilippeb linked to.
On the Explore page, there is a tab that lets you see the number of species for an area and each species has a total number as well. I’m not opposed to there being a species tab like this that ignores subspecies and varieties but there should also be one that includes all subspecies and varieties for the sake of both site navigation and a quick summary of that data. The current species-level bias of this page means that the only way to get a good idea of what taxa are in a particular area with a large number of observations is to do a data export. We shouldn’t have to do a data export to see a quick summary of what taxa occur in an area. I want to be able to easily see how many minimum-rank-taxa are in an area from the Explore page. I want to easily see how many of each of these taxa are in that area. I want to be able to easily click on a subspecies in that summary and be shown all the observations from that area that are IDed to subspecies. These are very basic data summary and quality control tools that should already be implemented on iNat.
To provide a very simplistic example of this problem just looking at a single species, check this search out of Eriogonum umbellatum. The explore page species tab summary only shows a singles species but this species has 40 different varieties on iNat, many of which will likely be changed to the species rank in the next decade. There should be a summary tab that shows the subspecies and varieties just the same way the current species tab shows the species. Showing just the species in the summary tab in this situation is about as useful as just showing the genus with no species when you are trying to see what species from a single genus are in an area.
To see counts of infrataxa without doing a data export, you can use https://jumear.github.io/stirfry/iNat_observations_taxonomy.
For example:
https://jumear.github.io/stirfry/iNat_observations_taxonomy?taxon_id=77040&place_id=14
I think the simplest solution to this would be making it so that hrank=subspecies works. Currently this link only shows species level which doesn’t make sense.
OK, thanks a lot for your attention! With this search result above, I expect a tile for “Class Magnoliopsida”, but there is none. A tile is displayed for “Class Magnoliopsida” only if I add lrank=class in the URL, but in that case I get lost the other tiles finer than “Class”:
So, my request is indeed to have all the tiles together, providing links to the 1470 observations, not more (no duplicates), not less (all observations can be reviewed, from the tiles).
Thanks for the trick, but this external page does not provide a link to the observations matching the different subspecies (as we have in iNat with the tiles for species). It shows the counts but does not allow to browse and review the observations.
I think this trick should not become a reason not to satisfy the request for tiles for subspecies.
I think this feature request describes what you’re looking for:
You’re welcome to make a PR to pisum’s repo to add the links.
What options would I have to select according to this feature request, in order to get (in one search) all the tiles I expect according to my request?
Ah, I should have read up further. Seeing your more detailed description now I don’t think it’s describing the same thing.
it’s easy enough to create links for counts at the exact taxon, but the tricky thing is creating links at non-leaf taxa for counts that include subtaxa, since it’s possible that the page is (effectively) filtering out some subtaxa. that’s the reason i never added links on that page. one compromise would be to create links only for true leaves (including down to subspecies, not “leaves” as iNaturalist defines them).
Maybe I’m misunderstanding you, but all true leaves have obs count = exact taxon obs count, so I would say just add links for the exact taxon and call it a day?