How to refresh map to show observations?

Often when I filter data in Explore view the page loads, but the observations do not show up as red squares or pegs on the map - the map is empty, despite there being many observations selected.

Is there a way to force display of the localities? Refreshing does not seem to work, nor does slightly altering the filter.

It’s beause it’s loading so slowly if there’re many observations (if that’s the case for you), what helps me is to click on “search on the map” button while viewing the whole world, for some reason it does load pretty quick.

1 Like

This is not just a problem of too many observations. I for example see this problem almost every time I click “show observations” or “show yours” from a species page, even if it’s just one observation - but the problem almost never occurs to me from “explore” - so when it occurs, i just go to “explore” and filter the given species manually. But the OP says it happens to them when filtering in explore - so there is probably a more complex underlying issue.

Maybe it is, because now when I restarted router even explore page with only filtered plants is loading for me, slowly, but it does even on zoom levels, while 2 days ago even Mallard page wouldn’t load at all until triggered with this button I mentioned, maybe @pisum could give us an insight of what to do to find out the root of the problem?

sometimes if you force a hard refresh of a given page, you can get it to display the expected results again. you can do a hard refresh in your browser by pressing Ctrl + F5 in Windows or Shift + Command + R in MacOS.

if a hard refresh doesn’t seem to do anything, then there’s probably something else going on. the only good way to troubleshoot this via the forum is if you can provide a screenshot of what shows up in your browser’s console and network monitor screens. this may vary by browser, but in Chrome, you can get this by selecting More Tools > Developer Tools…, and then selecting the Network / Console tabs. in those tabs, you’ll want to focus on anything that shows up in red as an error. in the Network tab, it helps to limit items to Fetch/XHR instead of All.

below are some screenshots of what my screens look like. i don’t see any issues right now. so there are no errors shown in the screens.



1 Like


this one is consistent in not showing:

In Chrome and Windows: Ctrl-F5 is not helping

I did the tools fetch thing and got this:

I dont see any error that I can detect, but the observations have not uploaded onto the map.

If I hover over the list, the observation flag does display - so the points must be loaded: they are just not displaying.

when the accuracy value is too high, iNaturalist considers the observation unmappable and will not display it on the Explore page map. i forget what the the threshold value is for making it unmappable, but i think 100000m is above that threshold.

It would be nice to know that value please.

But here it is not diplaying for 1000m

Curiously, I have found a way of fixing it:

It appears to be related to the place “southern Africa”

if I change the place in the filter to “South Africa” then the squares do display.
and then it works if I change the filter back to “southern Africa”

But then if I click enter on the except same url in the url box, it refreshes without the squares.

in the url:
click enter - no localities displayed
click filter box change the place to South Africa click update search - does display localities on map
click filter box change the place to southern Africa click update search - does display localities on map
click on the url box and press Enter - no localities displayed - despite it being the same url.

The issue seems to be:

  • It works from the filter box
  • it does not work if you enter the url in the url box and hit enter

Indeed: using the above technique:
acc_above=100,000 is unmappable but acc_above=10,000 is mappable.

pity - I wanted the map for a talk

  • many thanks
1 Like

mappable is defined as no larger than the diagonal of the obscuration rectangle (which is .2 degrees by .2 degrees), so at the latitude of South Africa, mappable goes up to about 29000 m, and always includes obscured observations.

I wasn’t able to reproduce your display issue, even with the lower accuracy observations.

1 Like

it’s still possible to export the coordinates of the >100000m set of observations (since there are only a few thousand), and then map those manually in ArcGIS / ArcGIS Online or QGIS or something like that. if you don’t mind resulting map being a snapshot in time, as opposed to a real-time view, then that should be a reasonable option.

if you need some details on how to achieve this, just let me know.

If the obs are slow loading, sometimes it helps speed things up if you zoom in a lot, then zoom out a little.

Thanks. I use ARCMAP, but for a quicksnaphot for a talk, it is hardly worth it.

I think my issue has changed. Why do the urls not show observations, whereas the filter does? Sending urls to answer questions and show issues is so convenient. But when the observations dont display - it becomes pointless.

if you’re asking why iNat chooses not to map certain observations, i suspect the answer is that the Explore page map visualizes coordinates but not accuracy. so someone made the call that, without the context of accuracy values, it was better to not visualize coordinates that have large positional accuracy values than to visualize a point that may not be a good reflection of the actual location of the observation.


Thanks: but that is not the problem I am asking about here.
I can live with observations with acc>100000 not displaying. I agree with the philosophy - as a back end user, I would have been happy with 10000!

But the issue here is that the urls are not working, for exactly the same options as the filters, for values that should be displaying. That should not be the case.

if you’re talking about:

i can’t reproduce this problem, and it’s not just me:

if you want someone to troubleshoot this, it will be helpful to add some screenshots, i think.


ok. there are cases where if you just refresh the Explore page, say, 10 times, 1 or 2 out the 10 times, the map will fail to zoom into the extent of the observations, and the markers will fail to display.

it sort of looks like a timing thing to me. if the page is loaded before it makes the API request to GET /observations, it won’t have the boundaries for the extent of the observations – so it won’t know how far to zoom in, and i assume that if it doesn’t perform the zoom step, then it also fails to look for the markers. (note in the screenshot below, the highlighted request begins after the red line.)

that said, if it is a timing thing, then probably it also requires general systemwide slowness to consistently trigger the issue. right now, if you can usually resolve the issue by refreshing the page once or twice.

i sort of think you should log this as a separate bug report if you really want someone to try to fix the problem.

a note for developers: it may be worth noting that when the page does zoom in and get markers successfully, it actually seems to be issuing 2 /places/nearby requests, which seems unnecessary and probably should be fixed. (actually, the places nearby request probably doesn’t need to occur until you click the places nearby button, i would think.)

I am getting quite a lot of GET failures. Most especially with editing Projects.

Unlike you: if I refresh the Explore page 10 times from the url bar, I get markers failing to display 10 out of 10.
From the Explore Page Filters, the markers display 9 out of 10, and refreshing usually fixes it.

not exactly sure what you’re describing here, but it sounds like a different kind of problem that may deserve a separate bug report. in that bug report, you’ll at least want to include some screenshots of what you’re seeing so that others can attempt to reproduce.

i can’t reproduce this, and i can’t see how this could be the case. if you can consistently reproduce the problem, it might help to detail exactly what you’re doing here.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.