Node locations don't update anymore -- reduced to minor problem with revised nodes see comments

Impressive site: clearly you will need to maintain all manner of categorisation for all the types of information you hold on the map - good luck!

Now I was considering what would happen if there was an internal limit to the number of nodes - I once thought I saw some comment about the maximum number of nodes: but for the life of me there isn't a setting anywhere in the code that I could spot - so I must be mistaken.

Given my experience with the way the code works - it trawls through your location table and renders each location in turn by encoding an html page with all locations on it. There is one main reason why it would stop: a piece of data (just after Ecuador entry I think) may be corrupt - which blows the code gen out.

Look at your location table (or indeed your node table) and see that all lat and longs are legit and that basic data entry is correct for the locations and nodes.

That is the best I can suggest.

No problem - just post a zip of it if you can... (to help things along - which nodes are not showing on the map?)

What would be another way of testing it of course - would be do use taxonomy feeds to try out the process as well. Thats a pretty neat way of organising your content - although you location geographies which dont need taxonomy per se - as the map location is good - you do have a need to organise "activities" across the world in different marker schemes. Pop in to view Area Map on http://bm.vortext.org to see what I mean (its all done with macro lines which will help create special map nodes for specific areas if you like.) The code is much simpler - as well - and doesn't bloat your javascript load page.

One thing is still bothering me - it seems for one category of nodes (the red markers) - you have exactly 40 nodes - now I really think this is significant - and I will endeavour to try to spot where the hell I saw this limit in the code...

Steve

If you say its clean - its probably clean.

Firstly in what order are the nodes rendered? (I will find this out from the listing)
From the first question which is the node that should render next? (after all its the one that is failing - not the last entry)

You may for example see that a query that determines the order of rendering may find the select result has run out of records based on the query. If you simply delete an old record - then that wont make a difference to the list.

You certainly have tested the extent of lat and long across the globe - but what is the characteristic of the failed one?

Do also consider that the we are working with clusterer.js - which tends to group co-located nodes. My suspicion is that this may fail along the way if you have some pretty close (or indeed exact located nodes) - from what I have seen on previous posts.

Try disabling clusterer.js to see what happens.

I await the copy of locations. In the meantime I am going to track down the clusterer code to see if that is responsible.

Steve

I think I have mostly fixed this now. Note below for some problems with being version aware.

As for the database queries. The gmap.module itself is not directly responsible. How it works is it goes through every entry in the location table with a lat/long and for every entry it loads the node for that entry using the drupal function node_load. Then when the node is loaded it checks to see if the user is allowed to view it and if so puts it on the map.

I'm not sure how many queries are associated with a node_load(), it probably depends upon what modules you have loaded, but my guess is that this is where all of your mysql queries are coming from.

It could be excessively high if there are a lot of entries in the location table that are not associated with a visible node. For each entry it will do a node_load even if that node is not visible to that user, or if it is an earlier version of a node. (Now that I think about it, it will probably show the current entry multiple times for each time it was revised -- I will try and fix that)

The fix for the main problem is on http://cvs.drupal.org/viewcvs/drupal/contributions/modules/gmap/ I don't know when it will be available on http://drupal.org/node/33591/release, but it usually seems to take up to a day.

As for the revision problem of multiple entries, I'm not sure when I will get to that, but when I do I will mark this issue as "fixed"

You uploaded the summary page instead of the actual module.
Try
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/gm...

Andre,

I've had similar 'holy cow' moments at the number of queries when generating http://www.folkjam.org/map/us . If you are calling out to the gmap node locations display, don't. Roll your own. If you have already rolled your own, then I'll suggest a few optimizations.

The default gmap_location node display queries the database for all nodes with locative data, it calls node_load() once for each row, then passes that node into gmap_location_node_map().

Write your own page display that does essentially the same thing, then begin to tweak it.

You can get rid of the node_load() call if you build up the markers array yourself in a way that is similar to what gmap_location_node_map() does.

What I did was altery my original query to pull back the fields I needed for my map teasers, then I built the markers array for the gmap directly from that result set. I then had one query instead of hundreds.

Also, for caching you don't need to create an iframe. Since you are writing custom code to replace the default gmap node locations display, you can wrap it in caching logic. Read up on cache_set() and cache_get() in the Drupal API docs.

I hope that helps.

So long as you are willing to keep buliding map.hmtl by hand that solution works too. I agree with you that in general Drupal is very database intensive. Part of it is the degree to which database operations are hidden from the developer - the true 'cost' of an action is not always clear. The upside is speed of development. Drupal is an excellent development platform in part because of the abstrations that are partly at fault for the query load you are seeing.

I've taken to hand-tuning a lot of my sites, but we also put in quite a bit of custom glue logic for something like folkjam.org which makes it easy to optimize. A stock Drupal site with no customizations has fewer opportunities to optimize.

Re the other thread you asked about, I don't have an answer for making the forums less database chatty. I've not used them heavily enough to have run across that problem yet. The blockcache that was recommended to you on that thread is very helpful - but don't cache the menu. Sadly the menu is expensive to create, but caching it keeps it frozen in cache as it looked to the user who caused the cache operation. If that was you, then all of your anonymous users will see the menu as the admin sees it.

I am going to assume this is fixed or worked around.