We have installed the “Mapping” module version 1.0.2 in Omeka S 1.3.0. After that, we have used it to locate 215802 items importing them through CSVImport module. Then we immediately realized that the whole installation was almost unresponsive. What it is more, each time we click on Resource Templates, an error is returned (PHP memory exhausted).
The only workaround or temporary fix is to deactivate the Mapping module. After doing that, Omeka is responsive and we no longer have performance problems. Any hint on how to use Mapping module for large collections while not loosing performance ?
Hi, I haven’t used Mapping module yet, but am very familiar with Google Maps implementations. There is a concept of “marker clustering” which is not built into the Google Maps display API (and btw are you familiar with their new API pricing?). Sometimes it is built into plugins, modules, and extensions, but in my experience not often because it is an extra layer that many users don’t need if they are dealing with <100 markers.
My guess is that the plugin is trying to display all 200,000 markers at once. This actually becomes primarily a browser / local computer issue, in that the browser can not render that many points on the Google Maps overlay.
I helped Jane Addams Papers resolve this by advising on marker clustering, which their theme developer (hi Anneliese!) implemented. You can see what clustering looks like here:
https://digital.janeaddams.ramapo.edu/geolocation/map/show
Do you have IT or PHP/Javascript programmer resources available to you? It requires some customization to implement, unless the plugin developer has already incorporated it into their plugin code. I’ll see if I have time to check out the Mapping module for Omeka Classic today - or maybe someone else will comment.
If you end up needing assistance in implementation, feel free to contact me at bakelaar@rutgers.edu.
That’s unfortunate but not all that surprising. During development we did apply caching in an attempt to alleviate performance issues such as what you’re experiencing, but we never benchmarked for items running into the hundreds of thousands. I’ve opened an issue on GitHub and hope to address it sometime soon. You may have to disable the module until we can find a fix.
Hey Jim, just to clarify for my own knowledge, was it caching (of the 100k records output as KML, rather than doing on-the-fly construction from the database on each request) or clustering (only displaying a certain number of markers per zoom level)?
I’m not sure yet. I suspect caching since the entire installation is experiencing a performance slowdown, not just a few select pages where clustering would be initialized. I think the module is caching mapping data too eagerly, and on pages where it shouldn’t touch. We’re looking into it.
Yeah it’s exceedingly unlikely, given the symptoms reported, that clustering or really anything about the actual display of the map would be related here.
On a somewhat tangential note, I want to note that the current Geolocation for Omeka Classic actually does have clustering support built in, though this wasn’t the case on earlier versions. S’s Mapping module, what’s being discussed here, is rather different in several ways, of course.
1 Like
Thank you to all you for your comments and support:
@jimsafley for openning the issue on GitHub.
@benbakelaar for his example, though it is based on Omeka Classic (nor Omeka S). And we need to geolocalize all isolated items, not clustered.
And finally @jflatnes for his useful words that summarizes the problem (and I totally agree with). So I’ll wait for a possible solution to the issue Ito be announced here.
A new release of the Mapping module (v1.1.1) includes a change that fixes the “PHP memory exhausted” error on the resource template browse page. As for the general slowdown you’re experiencing, are you sure deactivating the module improves performance? I’m not sure how Mapping can be responsible for an installation-wide slowdown, but concede that it’s possible.
Just to clarify my prior comments, I was not sure if the module/plugin supported clustering at all, and my remote suggestion/diagnosis was that if 100k markers were trying to be rendered on a single embedded map, this would surely crash.
Sounds like 1) Omeka Classic module DOES have clustering built in, and 2) Omeka-S does it differently (so conceivably, never outputs 100k markers to be rendered, but not through clustering).
My comments did not apply to a system-wide slowdown on other pages outside of the map embed page 
I agree with Jim it’s not likely it would impact installation across the board.
One remote possibility that I recently encountered is that certain JS includes that are coming from outside the main server (jquery, something in the theme, even something in the plugin) could be having a delay in loading due to - many factors. It’s easy to diagnose with the “Inspect / Developer Tools” feature in any browser. The “Network” view in Firefox or Chrome, for instance, will let you view each individual file object being loaded, and whether it was successful. If you need help finding or interpreting this, feel free to post a URL and me or someone else knowledgeable can take a look!
First of all, sorry for the delay in my response (I had to remake my entire item set because I recovered it from a previous database backup and I was testing later its behaviour with new Mapping module release).
@jimsafley Mapping module version 1.1.1 works like a charm! All problems have been removed.
@benbakelaar thank you for your interest, but I think now it’s going all well and I don’t need any extra help by you.
However I’ll explain you what the maps work in my case: I have an item set with some metadata for each item. Among the fields of metadata of each item there’s a map (a map for every item) which geolocalizes the item (only one point, not a cluster of them).
I imagine you are talking about only one map which geolocalize a cluster of points (one per object or item), but that isn’t the case here.
Besides, there are internal differences between plugins in Omeka Classic and modules in Omeka S, so we cannot extrapolate conclusions from one side to the other.
1 Like