I used the full screen browser mode because I didn’t want to show my browser’s tool bar and favorites, and to better illustrate the huge footer size compared to the whole screen. My remark was not limited to this mode.
The two biggest improvements by far for me would be:
On the “Map” view, be able to toggle whether to display the “latest observations” box which occupies a huge amount of the map view area; AND toggle the display of any markers showing observations. When I’m trying to zoom in on an area in the Borrego Desert portion of San Diego County, it is nearly impossible to see any feature of the map due to the density of the observations until one has really zoomed in. Right now, I just have to make an educated guess as to how to center the map on each zoom.
Be able to draw a polygon, or equivalent, to select the observations of interest. It is very time consuming to have to download a rectangular box worth of observations, and then filter the observations to the region of interest, which almost never is a rectangle in mountainous terrain.
I don’t understand the relationship of the different Observations pages, and can’t always remember in which one I can find which search fields, which is I suppose part of what is being rectified with this makeover of Explore.
But what i need more than anything is a page to go to where i can search by any parameter I have used in creating an Observation - ie field or ideally fields, field value or ideally values, tag or ideally tags, a keyword or group of characters in the given Place name (Locality name?) , or in the Description, and a Taxon (a choice of whether it is inclusive of Taxa below it or not would be great) - or Taxa.
Then - here’s where i ask for a pony - to be able to bulk edit any of those features.
And i don’t know if this is applicable to this thread as i don’t know if bulk editing is part of it, but if it is - the huge difficulty for me in selecting obs for bulk editing is that the low res thumbnails are not distinguishable and zooming doesn’t help. So if it were possible to either increase the resolution of the thumbnails, or to put a Checkbox-for-editing in the individual obs, I would be able to achieve a lot more with the exisiting features.
Thank you for this thread and sorry i still don’t know thelanguage of iNat well enough to be more coherent.
When I search for all genus Senna observations in a bounding box, the total count displayed is higher than the sum of the counts for all the tiles (species) displayed:
In this use case, the search filters the observations already reviewed, in order to show only the observations not yet reviewed. Only when I have finished reviewing all observations from all the above tiles (species), appears an extra tile (genus) to show all the remaining results that were hidden (but counted in the total):
Suggestion for the fix: always show as separate tiles all the other search results.
Display a tile for each taxon level between the species level and the level of the taxon being searched for. For instance, if we search for a family, there could be tiles for the family, all subfamilies (for observations with IDs only at that level), all genus and all species.
The current Explore page Species tab intentially shows “leaf” taxa, so this one isn’t a bug and I moved your comment here to the main brainstorming topic.
Yes, it’s a choice.
But then the total count displayed must be consistent with the tiles (species) displayed, that’s why I reported this as a bug.
2 posts were split to a new topic: Identify: How to mark all as unreviewed?
This topic is about inaturalist.org/explore, not the observation edit screen. Please start another topic if your proposal differs from the discussion topic here.
Please show only 2 digits after the decimal point for coordinates, this will make URLs much shorter and look better.
This will not make any real difference.
For instance, compare these 2 bounding boxes:
Moreover, remove the useless “&place_id=any” in the URL:
In a comment or an email, this would look better than:
It would also be easier to change manually the coordinates (since we cannot draw a bounding box on the map).
one minor thing. i’d like the parameters in the Explore page URL string to sync up with the parameters in the Get Observations endpoint in the v1 API (or whatever its successor is): https://api.inaturalist.org/v1/docs/#!/Observations/get_observations. specifically, i’ve noticed that if you don’t include the verifiable parameter in the Explore page URL, the page still does a search only for verifiable records. but if you do the same in Get Observations, you’ll pull back verifiable + nonverifiable records. in the end, i’d basically like to be able to take the URL parameter string from the Explore page and use it directly on Get Observations, or vice versa, and still get the same results.
this doesn’t make sense to me. if i’m working at high zooms, the more decimal places the better. i think shortening URLs is better accomplished with a URL shortening service.
At the equator:
360° = 36 000 km = 36 000 000 meters
0.0001° = 10 meters
10 meters should be enough, so OK for 4 digits after the decimal point?
i think 6 is better.
That seems about right. Map error is usually around that level anyway (unless you’re using exceptionally good ones – I have experience with high grade military maps and even those are a bit off)
Is there a GPS precise at the 10 centimeters level, in cameras?
What is the significance of finding an organism at a location, compared to 10 cm farther?
4 or 5 or 6 digits would be OK for the URL anyway. (I mean, to make it shorter).
Just for fun:
who knows what future tech will look like and be capable of? 6 decimal places is sort of where it doesn’t seem like it makes sense in today’s world. so i think that’s probably where it needs to be to allow for future possibilities.
When we take a picture, we are not on the organism.
It will be the same in the future.
Not always true.
Me and the organism share the same location…
yeah, please don’t do this. I zoom to inat observations on arcmap all the time and doing this would make that not work that well