• View
• Edit
• History
• Print

Google Map API for PmWiki Discussion Section

This space is for User-contributed commentary and notes regarding the Cookbook:GoogleMapAPI. Please include your name and a date along with your comment.

Note: The more recent version is discussed on the top. Discussions on older versions appear below. BenWilson May 22, 2006, at 04:47 PM

This page contains all past discussions.

Table of Contents

• Frequently Asked Questions about Google Map API
• Comments to v2.2.0pre2 Release (December XX, 2006)
• Comments to v2.2.0 Release (December XX, 2006)
• Comments to v2.1.2 Release (August 28, 2006)
• Comments to v2.1.0 Release (August 27, 2006)
• Comments to v2.0.1 Release (August 23, 2006)
• Comments to v2.0.0 Release (August 22, 2006)
• Comments to v1.3.0 Release (Due August 9, 2006)
• Comments to v1.2.0 Release (June 3, 2006)
• Comments to v1.1.0 Release (May 26, 2006)
• Comments to v1.0.3 Release (May 23, 2006)
• Comments to v1.0.2 Release (May 22, 2006 pm)
• Comments to v1.0.1 Release (May 22, 2006)
• Comments to v1.0 Release (May 17, 2006)

Frequently Asked Questions

Comments

Comments to v2.2.0pre2 Release (December, 2006)

• Bug - pushpins w/multiple maps on page (RussFink): if you put multiple maps on a page, and give text on the gma-point in the first map, clicking the point on the first map causes the text of the pushpin to appear on the second map, not the first. It seems like gma-point's text feature is ignoring the mapid.
  • This is a known defect. Glad I'm not the only one BenWilson February 08, 2007, at 11:20 AM.
• Associative GmaKey patch (RussFink): Google binds your API key to your domain name, such that if you have multiple domains registered for your site, you need to have multiple API keys. In my case, I have www.finalscoretrivia.com and www.finalscoreohio.com pointing to the same set of pages. By default, the GmaKey contains only one key, and thus only one domain is "registered." The users using the unregistered domain to view the page won't see the map.
  
  I fixed this by making GmaKey an associative array. The following patch will do it (use the patch program. If you don't know what that is, perhaps the maintainer will upload a patched version.)

 
--- gma-2.2.0-pre2.php.ORIG     Thu Feb  1 11:24:05 2007
+++ gma-2.2.0-pre2.php  Thu Feb  1 11:26:52 2007
@@ -212,11 +212,12 @@
 }
 function gmaAddressLookup($a) {
     global $GmaKey;
+    $_gmakey = $GmaKey[$_SERVER['HTTP_HOST']];
     $res = false;
     $url = sprintf(
             'http://maps.google.com/maps/geo?&q=%s&output=csv&key=%s',
             rawurlencode($a),
-            $GmaKey
+            $_gmakey
            );
     $coords = array();
     if($res = file_get_contents($url)) {
@@ -231,12 +232,13 @@
   global $GmaEnable, $GmaVersion, $GmaScript;
   global $GmaMaps, $GmaPoints, $GmaLines;
   global $GmaKey, $GmaDebugMsg, $GmaDefaults;
+  $_gmakey = $GmaKey[$_SERVER['HTTP_HOST']];

   GmaDoIEFix();
   $HTMLHeaderFmt[]
      =  '<style type=\'text/css\'>v:* { behavior:url(#default#VML); }</style>'
        ."\n<script src='http://maps.google.com/maps?file=api&v=2&key="
-       .$GmaKey."' type='text/javascript'></script>";
+       .$_gmakey."' type='text/javascript'></script>";
   $HTMLHeaderFmt[]
      =  "\n<script language='javascript' src='\$FarmPubDirUrl/scripts/gmaJs.js'
>"
        ."</script>\n";

Usage: in config.php, change $GmaKey = 'abcde...'; to $GmaKey['mydomain.com'] = 'abcde...';. NOTE, the patch above distinguishes between "www.mydomain.com" and "mydomain.com" but Google does not, so you need to copy the key from the first into the second (just use two lines of identical key)... Either that, or the maintainer can do the Php trickery to strip off the "www." portion and just use 'mydomain.com'.

• Change Per Bram's suggestion, using a GMA link scrolls the web page to the top of the map.
  I hope you didn't use the code I send you.....
• The get_browser function is rather expensive, would it harm to always include the vml-schema?
• I installed this version to see if the link anomaly I detailed below had been altered (afraid it still seems to have the same problem) but also found I had to revert to the previous v2.1.2 release as I discovered that the Info Window operation had been lost (but realise this may be because it's a dev). I found that the Info Window didn't open when the link was clicked, or when the marker was clicked. Des December 15, 2006, at 10:34 AM
• When we specify text, how to tell the engine where do we want a line break to occur?. Maybe even have it formatted to something similar like this?

ASSOCIATION HQ
No 1234, Cold Road
15054 Alaska

-> Thanks hua Jan 09, 2007

• Answer - you can embed <br> in your text and it will work. RussFink

Comments to v2.2.0 Release (December XX, 2006)

A new release is in the works.

Feature Plan:

• Address lookup support (Ready for 2.2.0-pre2) BenWilson December 10, 2006, at 11:56 PM
• Multiple map support (Almost ready for 2.2.0-pre1) BenWilson December 09, 2006, at 12:04 PM
• Map Float (Ready for 2.2.0-pre1) BenWilson December 09, 2006, at 11:31 AM
• Icon support
• Link to wiki pages

Comments to v2.1.2 Release (August 28, 2006)

• Thanks for this great script. Is it possible to load the markers from an external xml/txt file? I'd like the same, non-editable map to appear on a number of pages so this would clear up clutter. The rest of the page is editable, though. Thanx Bets October 17, 2006
  • Just a thought (since I haven't tried it with a map yet): Create the common map on a read-only page in your wiki, using the usual gma options, then use the Include other pages? directive to place it on any page where you want this common map to appear Des October 17, 2006, at 07:28 PM
  • Try putting the map markup in the group header or footer. That should do the trick. BenWilson December 10, 2006, at 11:56 PM
• Using gma v2.1.2 with PmWiki v2.1.22 and all I get is a blank space with text above and below where the map should be? I've editted the skin tmpl file to include <html$GmaIEFix> as recommended in the third line, which was just <html>. Prior line is <!DOCTYPE html PUBLIC.... Thanx Steve September 13, 2006
  • Check your skin/template has the correct format at the foot. If you have an earier one created prior to v2.1.16 and not yet updated, it will not have the latest skin variables included, which must be added manually (HTMLFooter is the important one here, and must appear immediately before the </body> line). The last lines of the template file must be:

  <!--HTMLFooter-->
  </body>
  </html>
  

  • The <html$GmaIEFix> entry is (I believe) only needed if you are plotting lines, and has no effect on the map.
    You can check the operation of HTMLFooter by looking at the page-source. If there is no Google Map code visible at the foot of the page-source, then it is missing or incorrect. Des September 14, 2006, at 12:30 PM

• Thanks for this update (I couldn't download v2.1.1). I added some lines and found the vml wasn't being added in IE this morning and had been trying to work out what I was doing wrong with $GmaIEFix (since adding the vml manually to the template worked fine. Now working great in IE and Fx (apart from the odd phantom link text noted below in v2.0.1). Des August 28, 2006, at 07:45 AM

I looked a bit closer at the links that caused the wiki to create the strange links and found the following seem to define the typical conditions:

• Case 1 is one of the original links that highlighted the behaviour.
• Case 2 is the same link, but with the space removed - no change.
• Case 3 is the same link, but reduced to the first letter pair and number - no change.
• Case 4 is the same link, but reduced to the letter pair - it operates normally.
• Case 5 is the single letter, just to complete the pattern.

In the first 3 cases, the text to the right of the arrow opens the map point, while the text to the left is dead, although it has the visual appearance and behaviour of a live link. The map point link does not link back to the text link.

It is case sensitive. Repeating the same test, but with the leading upper case 'A' replaced by a lower case 'a' does NOT show the same anomaly.

Case 3 and Case 4 differ in that Case 3 is triggering the wiki to introduce an extra, unwanted wikiword class:

<p class='vspace'><a name='<span class='wikiword'>AS5</span>'></a><a href='javascript:makeGmalink(map,2);'>
<span class='wikiword'>AS5</span></a>

<p class='vspace'><a name='AS'></a><a href='javascript:makeGmalink(map,3);'>AS</a>

Now I'm getting a little lost, as I have wikiwords disabled, and allow only the double square bracket method for producing a wikilink. Feel as if I'm missing something very obvious. Des August 28, 2006, at 11:21 AM

Des, is this still an issue with the v2.2.0? BenWilson December 10, 2006, at 11:56 PM

Comments to v2.1.0 Release (August 26, 2006)

• Superb, users should note they will have to add the new <!--HTMLFooter--> line to their existing templates (and remove their older $GmaScript or $GmaJS lines) when updating to PmWiki 2.1.16. features.
  Directions working nicely too, even if Google does suggest some strange routes to places we know well :-).

Comments to v2.0.1 Release (August 23, 2006)

• Removed my comment regarding gma-link problems after discovering my difficulties were caused by the format of my existing test page. This had obscured the appearance of the link, and stopped the text anchoring from functioning correctly. Used properly, it works as expected. I also found it works happily when used as an entry inside a table. Thanks. Des August 25, 2006, at 08:00 PM
• Found a possible bug in the use of the link option, where certain combinations of characters appear to cause the code to generate spurious, nonsense links in the wikitext. Best seen where it appeared on the page I was updating, when odd link text began to appear. See for example the link text that appears for Larkfield following the normal links generated for Cardross and Kilmalid just below the map on this research page for AA batteries on the Clyde. If you look at the table at the bottom of this page, there are many more similar examples for other linked points on the map. Des August 25, 2006, at 08:41 PM
• Installation info: "Configure the Skin" states: "$GmaScript and $GmaIEFix are needed", but just fix IE probs. This is not the full story. FireFox wouldn't display more than grey w/o 'em. :))) Next thing: "Two variables must be embedded in the PmWiki skins". Would be helpful, to state this ought to be done in the each's .tmpl file. ;) Third thing: Only v.2.0.1's release notes state "$PubDirUrl changed to $FarmPubDirUrl". Since I use my second field with gmap, I had to extract the archive's cookbook part to the field and the pub/scripts part into the farm. Would be nice to mention that. My suggestion would be to keep it together :)
  • With v2.0.1 the location of pub/scripts was corrected so that ALL the gma files are installed in the farm. None of the files should now need to be installed in the local (or field) directories. Des August 26, 2006, at 05:53 PM
• Function: I recreated the new entire google map example (thanks for that!) and everything worked well. Besides the links. They strangely show up just below the gmap frame as new, artificial text links or anchors. How do I link to places / existing anchors upon the same page and how do I link to other pages in my wiki? Do I have to enable text-anchoring? How? Did I screw up somewhere? http://reise.selbst-doku.de/Afrika/Simbabwe The page can be edited by you, to make it work :) Next thing: Please remove 'Directions' links again. ;) Thanks for the cool, new code! :)
  • The link will appear wherever in the text you place it. See your example page where I placed Link3 ABOVE your gma-map declaration. The list of points doesn't have to appear in a list after the gma-map declaration. Des August 26, 2006, at 05:53 PM
    • Hi Des, thanks so much much the help(!) Now I grasp the concept. ;) It's somewhat limited to the current page, but nonethelss - the bidirectional connection between Gmap link and textual link is very cool. :) I just hope to be able to freely link to any page, somewhen ;)
  • I doubt you will be able to use existing links on your pages, or to other pages, as the gma recipe creates the code for page links and places them as it builds each page when it is viewed. New functions would need to be added to provide facilities like that (and that's not my department :-) ). Des August 26, 2006, at 05:53 PM
• Demonstration: I suggest to place a working gmap example on the release or the comment page, to show off the features and provide a guaranteed working example. Axel August 26, 2006, at 11:41 PM
  • The demo would only work if Pm? installed the gma recipe in this wiki, and there was a valid key registered for the PmWiki domain. Des August 26, 2006, at 05:53 PM

Comments to v2.0.0 Release (August 22, 2006)

1. Seem to have caught most of the mods needed to update to the new v2 recipe, but still find that the JavaScript directory /public/scripts has to be installed locally for each wiki in the farm. Installing in the farm's /public/scripts directory results only in a grey box (with the Google logo and 'Terms of service') where the map should be.
   • Fixed by v2.0.1 Des
2. Is there any plan to allow the Directions option to be omitted by option from the InfoWindow? This is useless in the UK (and I assume anywhere outside the US) and only leads to a Google map announcing it can't calculate driving directions? Des August 22, 2006, at 01:30 PM
3. Can you define the proper syntax or give an example for defining entries for the $GmaDefaults array please? I assume something like $GmaDefaults['width']='100%'; but I'm having no luck with that or the possible syntax variations. Des
   • Works fine after v2.0.1 update Des
4. The zoom option doesn't seem to have any effect. The map always scales to show the all the points regardless of the zoom value I enter.
   • Fixed by v2.0.1 Des

• I intended to upgrade from 1.2.0 to 2.0.0 on the second field of my farm. G-Key is present for the field, old version works well for the field. Uploaded complete package into field's directory structure. Edited local config.php, commented old stuff and introduced $GmaKey = 'ABQIXXXXXXXXXXXXXXXGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHkdw2ut_Rw'; and include_once('cookbook/GoogleMapAPI/gma-2.0.0.php'); Google tells me, the key is valid for a different site. Which is nonsense ;) Any ideas? :) Thanks, Axel
  • I had the same, but it was my fault as I'd missed the spelling of $GmapKey changing to $GmaKey. When I fixed this, the error message went away. Sounds obvious, but maybe a typo. I ALWAYS copy & paste the key from the working version, just in case. Des August 22, 2006, at 07:03 PM

Comments to v1.3.0 Release (Due August 9, 2006)

This version was released and pulled back. I plan on re-releasing as soon as I finish re-organizing the code. Features include HelgeLarsen?'s introduction of polyline and the ability to have multiple info windows (those word bubbles that appear over the marker). I'd like to have markers with such bubbles be a different color as a visual que.

The reorganization is a move to OO. The goal is to make the code easier to understand without undue experimentation.

I re-released the code after retooling and moving more of the functionality into a javascript library. This prompted a move toward v.2.0.0. BenWilson August 14, 2006, at 08:24 PM

• (With v1.3.1 patch) Manually installed since using a hosted server, creating new sub-directories etc. by hand. I don't think I missed anything, and am using (:gmap zom=12:) alone, with (:gmapoint lat lon msg :) to add the markers. The new recipe seems to be running ok up to a point, then failing. What I get is the infamous grey box, of the correct size, where the map should be, but the only content is the 'Powered by' Google logo in the bottom left corner, and the Terms of Use link in the bottom right corner.
  I haven't the opportunity to look at the revised code for a little while, so is there anything obvious I should tackle first that I may be doing wrong? Des August 15, 2006, at 05:15 PM
  • Tracked down the source of this problem: While the simpler versions prior to v1.3.0 work in a WikiFarm, the later versions are not currently fully compatible with this mode of use, and require a little local customisation.
    Specifically, the new structure that adds the directory /pub/scripts for the gmaJs.js file is not found in the core PmWiki installation, but is being fetched from the local /pub/scripts directory for the individual field. Adding this new directory and the gmaJs.js file to the field appeared to restore full operation of the revised v1.3.1 recipe Des August 16, 2006, at 08:18 PM

Comments to v1.2.0 Release (June 3, 2006)

I added ZIP Code support. Once I figure out how to add international support, I shall. This is more an issue of finding the right conversion file. BenWilson June 03, 2006, at 05:07 PM

I encountered a problem while using the Google Map API on a wiki which sets 'Locale' => 'de_DE' via XLPage in config.php. The GMap-API seems to get confused about values for latitude ('lat') and longitude ('lon') when defining fractional numbers as in lat=54.09.
The solution (pointed out by Pm per e-mail) was: "The locale setting is causing periods to change to commas. After the call to XLPage(), try restoring the locale back to the standard dot [both lines in config.php, Bartolin]:

Bartolin June 07, 2006, at 10:53 AM

Problems in NotSoSimple Skin

The Google Map API works very well together with the Pmwiki, Soma Skin. But I encountered a problem together with the NotSoSimple Skin. The map is only static. It is not possible to use the interactive buttons. What could be wrong? Only a problem of IE ... MaBen June 20, 2006

• NotSoSimple Skin (don't work with IE): Link as soon I change the skin to PmWiki skin it works ...
• Soma Skin (same WikiFarm Inst.): Link
  • Both IE and Firefox have same problem for me viewing map in NotSoSimple, and both are similar. Soma example is fine in both browsers.
    *** I only have problems in IE (6.0.2900), not Firefox (1.5.0.5). Rather interestingly, using the buttons in IE worked for about a second after the page loaded or was loading, and only THEN stopped working. -- Neurophyre, 3 Aug 2006
    • After noticing IE reporting an error, I clicked it. It's pretty unhelpful, but it says:

      Line: 78
      Char: 57
      Error: 'null' is null or not an object
      Code: 0
      URL: http://www.bendler.homelinux.org/?n=Main.MyCoord 

      I'm still trying to determine exactly what script this error is in. -- Neurophyre, 3 Aug 2006
      • I can't even find a script with a Line 78, Character 57. Dumping the source of http://www.bendler.homelinux.org/?n=Main.MyCoord yields a line 78 that is the first line of the NotSoSimple Javascript block in the head section, but it doesn't even have 57 characters in it. I downloaded the raw Google Maps script from the URL embedded in the file and it doesn't have a single line break, hence no Line 78. I'm stumped. --Neuro
      • This is one of the difficulties with Javascript debugging if you're not an 'expert'. When a problem is reported as you describe, then it is being generated in an external script other than yours. For example, there could be an obscure problem arising in the Javascript of the Google Map API and the combination of the skin and the recipe - almost impossible to determine. Unfortunately the error listed is very common, and can arise from something as simple a ; being omitted from a line ending. IE is known to be less tolerant than Firefox of Javascript errors like this in executing scripts - I've written applications using the map API that won't even show a map on a page in IE, let alone markers, yet they run perfectly in Firefox.
        I've had a look at the source, and it seems as expected - I did however notice the overview map in the bottom right doesn't appear in IE. I suggest disabling it in the configuration to see if it makes any difference to the problem. You could experiment similarly with other options to see if any have an effect. Des August 04, 2006, at 04:42 AM

Axel July 17, 2006, at 12:43 PM Hi, really, really nice to have Google maps working inside PmWiki. Since I intend to create a travel-wiki, this comes more than handy, saves more than just a few minutes of extra work. GREAT DONE, THANK YOU :) So, now for the small prob. ;) I placed two markers on the map, but three show up, and only one message is displayed. The last. Take a look: http://reise.selbst-doku.de/Afrika/S%fcdafrika The page is editable, so you can peek at the source ;) So, I hope this can be solved, since the site would really benefit from it. Thaks again, Axel ;)

• You have 3 markers because the the initial (:gmap:) call also places a marker at the lat/lon specified. Additional markers can be placed after the initial one by using gpoint. Just use a marker lat/lon in the initial (:gmap:) call.
• You have [option] inside your calls, it should be removed. From the documentation, it only shows you can include options.
• The recipe does not currently have any handling for multiple info windows on markers - only the msg string for the last marker to be placed can be shown. Multiple messages would require more advanced click event handling, not yet written. Des July 17, 2006, at 12:16 PM
  • I removed the [option] remark, removed all but one intentionally created marker and tried to close and open it's bubble. It's closed, but can't be openend again. I suppose another click handling issue, right? :) Since I depend quite heavyly on this dynamic marker text feature. Any plans on integrating it? Thanks so much for your help here and above :) Axel ;)
    • You are correct, until click-handling is added, only the last messages shows, and when closed, it cannot be re-opened. There is a simple amendment for the recipe versions earlier than v1.2 that allow the single point (:gmap:) to be clicked open and closed, but it doesn't work with v1.2 due to the more advanced coding. Don't know if Ben is working on it, and I've been a bit to busy on my own site to play with it, although I need it badly too, I really should. Des July 19, 2006, at 07:30 AM
    • Axel If you are following this discussion, then I have added event handling to multiple markers placed by (:gmapoint:), so messages can be opened and closed on each marker. There are some minor issues with the update and existing users which need Ben's oversight, so I've mailed him, and posted here to let you know they're possible. Des July 23, 2006, at 12:37 PM
      • Hi Des, I'd really like to be able to dynamically 'use' several markers. They could effectively link to a real plethora of sub pages. So I do have v 1.20 and I do have a valid page. Here's the link again: http://reise.selbst-doku.de/Afrika/S%fcdafrika The markers don't work, though, and only the last info bubble is displayed. Klicking the markers or placing a link in the text didn't produce any outcome at all. Status line reports something about a javascript void function. Am I doing something wrong here? :) All right, I hope you don't mind if I add a small suggestion here: I'd suggest to use wiki pages, instead of the original html for the text inside the info bubbles. So editing them just requires some wiki schmiki instead of shifting to html. Could be helpful for joe wikiuser ;) Thanks for your help, Des! :) Axel
      • Sorry if I wasn't clear. I have the multiple marker code functional within my own wiki only. v1.2 as downloaded here is the current public (development) release from Ben and does not have click handling, and has a small bug/feature that means the gmap line adds an extra marker, as well as those placed with gmapoint. You can see the functional code working here http://www.secretscotland.org.uk/index.php/Secrets/AuchenreochDecoy (there's a map you can try in the Sandbox there) and here http://www.butewiki.de-soft.co.uk/index.php/Bute/HovercraftService
        • Hi Des, two really nice wikis you do have there! ;) Even though I'd be the one, fooled into dropping my bombs off target, weren't I? :))) However, I - finally - ;) grasp you shfted the php to suit your needs and made it work. Could you provide it to me besides the official paths, just for some say targeting practice on my side ;) That'll blow me away. Thanks in Advance
        • :) Thanks, it was finding the cratering near the decoy that motivated me - all my maps only needed single points before that, now they all seem to invite multipes. Hope I got your email correct, sadly my German doesn't match your English and it took a bit of hunting to find it. Des July 29, 2006, at 08:03 AM
          • Hi Des, thank you for the hunting and for the sending! ;) But - my own email server takes an outtime. Could you forward the mail to nada(at)nowhere.net? Thanks so much again, Des! I'll right back after I tested it in my wiki ;) Axel July 31, 2006, at 00:03 PM
          • Sent to new email, so should be with you soon. (MailForm allows easy contact without exposing your email) Des July 30, 2006, at 09:12 PM
            • Hi Des, thanks so much for your patience. I got into my mail account again an found your mail ;) I'll be back to you shortly ;) Axel July 31, 2006, at 02:03 PM
            • Des, everything works as a charm right now. 8) I will of course closely follow the further development of this plugin, but for now, my site really can be used. Thanks again for your kind help! :) Axel July 31, 2006, at 10:16 PM
      • I doubt the infowindow text will be allowed to come from a wiki page, 2 reasons. Firstly, it makes the option harder to use than just adding some text in gmapoint. Secondly, it would need safeguards against trying to load a huge page, meaning height/width option etc. etc. To build html into an infowindow, you should really be developing a proper Google API based map, with data stored in XML or similar. Ben may disagree, but I think that complexity would be outside the scope of a simple method of embedding a Google map in a wiki page Des July 28, 2006, at 08:34 PM
        • Hmmm, the max char count should be ok to check, don't you think? :) In my eyes, a wiki page based approach would be more consistent and simple to a user. I'd to explain longitude/latitude, I'd to explain html, but I'd easily provide a separate wiki page, ev. supported by it's own template as a bubble text. That would encourage our joe wikiuser to use this plugin. ;) Plus, if info bubbles are parsed, they could contain wiki style links to subpages(!) That'd really benefit PmWiki further than a intentionally simple but hence limited aproach, I hope ;)Axel July 31, 2006, at 02:14 PM
        • With regard to the idea of using a wiki page to supply the infoWindow text, can I ask if I have the correct idea? As a simple example, would your proposal mean that a marker would be specified with something like
          (:gmapoint lat=55.535635 lon=-5.547656 msg=[[MarkerPage]]:)
          where MarkerPage would be a wiki page holding the infoWindow content? Des August 01, 2006, at 09:51 PM

          • Yes, you're right again, Des. :) It might be wise to use a special group to store them. That could help to keep things neat and tidy, and allow for a special gmappoint template used for their base. :) Secondly, the use of parsed wiki pages als info box texts allows for wiki style links from the gmap info box into the wiki. This seems most beneficial to me ;) ;)Axel Aug 2, 2006, at 01:50 PM

• The point at the center coordinate is in version 1.2.1 (August 4, 2006) optional, and controlled by default variable $EnableGmapCenterAsPoint or markup option cpoint in (:gmap lat=55.535635 lon=-5.547656 cpoint=y/n:) HelgeLarsen? August 04, 2006, at 02:42 PM

Ansgar? July 18, 2006 Hello, I tried to give the (:gmap:)-Markup the msg-Option, but no message was displayed. So I tried an additional (:gmapoint:). This worked though the map now was centered, according to the new point. Is there a possibility to draw only a map with (:gmap:) and add one or more markers with (:gmapoint:)?

• If you only require a single point with a message, just use the the earlier v1.0.3 version. It does not have the (:gmapoint:) multiple point development, so doesn't suffer the bug that prevent the message displaying if only (:gmap:) is used. Des July 19, 2006, at 07:30 AM
• The automatic ajustment of the center coordinate is in version 1.2.1 (August 4, 2006) optional, and controlled by default variable $EnableGmapCalculatedCenter or markup option ccalc in (:gmap lat=55.535635 lon=-5.547656 ccalc=y/n:) HelgeLarsen? August 04, 2006, at 02:46 PM

Comments to v1.1.0 Release (May 26, 2006)

Per user request, I'm trying to add multiple point capability. BenWilson May 26, 2006, at 01:40 PM

Comments to v1.0.3 Release (May 23, 2006)

I've received several comments and questions about sizing. This has been an issue from the beginning. Therefore, this release should finally put to rest those issues. While it is a minor feature release, it really is a minor bug fix in that it gives the administrator and the user a quick-and-easy way of setting the height and width without having to edit the Skin's CSS, editing the recipe file, or adding any special CSS elsewhere. BenWilson May 23, 2006, at 10:14 AM

Comments to v1.0.2 Release (May 22, 2006 - pm)

Des picked up a couple mistakes I made early this morning. BenWilson May 22, 2006, at 05:36 PM

Comments to v1.0.1 Release (May 22, 2006)

I hope the issues raised in v.1.0 fade. Please email me if there are any problems. My address is in the copyright statement. Also, I appreciate suggested improvements. I'm not sure if this will become the Swiss Army knife of Google Map API. BenWilson May 22, 2006, at 03:02 AM

• Thank you for the improved new revision! The new Releease works perfectly inside the soma skin. But integrated into the gemini skin there is a problem. The width of the map is 0. In the v1.01 it worked properly. Is there a naming conflict with the CSS of gemini skin? MaBen May 22, 2006.
  • No. I failed to mention the need to set the size as this recipe v.1.0 did not. I preferred to leave total accountability to the admin then. Now I've relieved the burden so you at least have a solution while you go back and tweak. BenWilson May 22, 2006, at 04:40 PM
  • I have an intermediate solution: I changed $HTMLStylesFmt['gmap_api'] = 'div#map{ height: 400px; width:100%;}'; to with:600px
    • You don't need to. If you manage your Skin a little differently, you can manage the size via your Skin. See below. BenWilson May 22, 2006, at 04:40 PM
  • It would be great if the size of the map could be adjustet to a specific size.
    • You can. In your skin <!--HeaderText--> is probably below your CSS links. Move that reference above your CSS. This means your CSS declaration will take precedence over PmWiki's defaults. This means that $HTMLStylesFMT[] values defer to your Skin's value. So, if you move the above mentioned reference above your CSS, then define the size you want in the Skin's CSS, then you can configure the size on your own.BenWilson May 22, 2006, at 04:40 PM
    • Provided <!--HeaderText--> is correctly positioned above the CSS links, you can tweak the skin's CSS without editing the skin.css file. See SkinGuidelines? which explains that if you place a file named local.css in pub/local as in pub/css/local.css then any css changes contained there will take precedence over the skin style sheet without the need to edit it explicity. --Des May 22, 2006, at 05:13 PM
    • Thank you very much for your hint. Yes the local CSS values works perfectly. MaBen May 23, 2006
    • My question regarding size adjustments was to have different map sizes on one web site. MaBen May 23, 2006

Comments to v1.0 Release (May 17, 2006)

like to truncate this comments list. In the alternative, I would like to set up a comments page. However, to provide catch-up, I would like to leave this up for a few weeks. This should give site admins a chance to read. FWIW, I started using this recipe about a year ago, but the code was a little embarassing. I tried to clean it up, but it is obvious from the v.1.0 input that there were a few glaring mistakes. In retrospect, I might have released it as v.0.1 until the initial shake out. I applogize for any inconvenience or lost hair. BenWilson May 22, 2006, at 03:02 AM

The Google Map is only as big as its container. The default container had no size. The result is no map apart from those controls unconcerned with size. So, size does matter. I corrected this issue but obviously cannot view in all posible contexts. I appreciate your patience in this matter. BenWilson May 22, 2006, at 03:02 AM

• "By default, the map will assume the size of its container." Google Map Documentation BenWilson May 22, 2006, at 01:02 AM

check the page so quickly. BenWilson May 22, 2006, at 03:02 AM

• Superb to see this arrive in PmWiki. A few bugs to wring out, however v1.0 is always so blessed.
  1. Entry in config.php should be $GmapKey rather then $GmapCert
  2. GmapJS entry in config.php must be properly formatted with line termination or initialisation will abort
     $GmapJS (leave blank) needs to be entered e.g. Gmap = " "
     • $GmapJS defaults to ' ', as does $GmapCert.
  3. Any textual content on the page causes (:gmap:) to be ignored
     • This is probably the CSS issue as I have text on sites that use this recipe BenWilson May 22, 2006, at 12:26 AM
  4. The instructions included in gmap_api-1.0.php omit to mention the inclusion of $GmapCert in the template header
     • appologies. I removed the need for this incusion in v.1.0.1 BenWilson May 22, 2006, at 03:02 AM
  5. I amended the page with the above and added a config.php sample --Des May 17, 2006, at 06:30 PM
• Additional info
  Using in PmWiki 2.1.5 with monobook skin. In Firefox, the initial display appears ok, but when panning, the content/map keeps changing height, occasionally reducing to zero and vanishing. Similar in IE6, but the page footer stays stationary on top of the map, which also appears full page width.
  Unfortunately I can't really try it outside monobook, as there's custom styling applied over and above the defaults that would render other skins useless. This is the test page though:- http://www.secretscotland.org.uk/index.php/Secrets/AMapTest
  Probably worth mentioning that the initial map displayed in the monobook/Firefox setup shows less than the bottom half of the map. The centre is located somewhere above the displayed page, in the area of the banner. This may be due to local styling of the skin, as I move my page content down to avoid the banner, but checking this specifically would be a bit 'involved', so I'm just reporting the effect for now. --Des May 17, 2006, at 06:55 PM
  • I have the same problem with soma skin and IE7 --MaBen May 19, 2006
  • I opine this is fixed with the CSS correction. I suppose I really should have imposed style? I thought discretion was better but I seem to have caused some irritation.BenWilson May 22, 2006, at 12:26 AM
• API Version compliance revision
  • I was looking to see why the zoom appears to be fixed ($GmapZom was having no effect) and it seems that none of the code is currently compliant with API V2, and will stop working when API V1 is turned off in a few weeks.
  • The map is being created with Gmap rather than Gmap2.
  • centerAndZoom has been used rather than the new setCenter.
  • Gpoint has been used (this is now a pixel setting) and GLatLng() must be used where latitude and longitude are being passed. Note that the relative order of latitude and longitude are reversed to their natural order in the new setting: GLatLng(lat,lng).
  • In centerAndZoom the zoom was fixed at 4, rather than replaced by its variable. Changing the 4 to %zom fixed this.
  • I made the above changes to the downloaded recipe, and they all function under API V2.
  • I amended the Status of the current recipe to Development as it is currently not stable or V2 compliant. --Des May 17, 2006, at 08:09 PM
• Details of browser behaviour
  I've reviewed the actual symptom of the display in Firefox and IE6 when the map API is generated within PmWiki and offer the details below. Again, please note this is confined to monobook skin.
  It may be relevant to note that the 'Quick and Dirty' method I proposed on GoogleMaps?, where the map is placed on the PmWiki page by using IncludeUrl to include the map created on an external html page does not suffer this problem, and displays as expected. The code needs to be updated for V2 (I'll get to it soon), but this example illustrates the principle for the moment http://www.butewiki.de-soft.co.uk/index.php/Bute/MapOfBute
  • The solution is to set dimensions to the division statement, or upgrade to v.1.0.1. BenWilson May 22, 2006, at 12:26 AM
• IE6
  • Although the map controls conform to the PmWiki page content borders when placed, the Google map itself ignores this, and appears full width across the page, on top of everything except the PageFooter, which stays on top of the map, and doesn't move in response to panning. Panning the map produces changes to the displayed width/height/position in an apparently random manner.
• Firefox
  • As above, however in this case the PmWiki page content borders are obeyed, but function as a window on the underlying Google map, which is placed as if using the top left of the page as its origin, with only the area visible through the PmWiki page content area being seen. In this case, PageFooter honours changes in the display by remaining under the map as it changes height.
• Hope this helps someone figure out what's happening as the page is generated/updated. --Des May 19, 2006, at 04:01 PM
• Google API V2 note for May 20, 2006
  • Changes to API V2 for May 20 appear to have altered the behaviour such that the map detail no longer displayed. The recipe remains functional as the controls are still visible/placed (albeit stacked on top of each other), and clicking the coloured Powered by Google logo opens a Google map page, centred on the target LatLng value.
  • I've attached an updated version of the gmap_api-1.01.php script with the V2 amendment listed above --Des May 20, 2006, at 08:00 AM
    • Please heed the copyright statement in the code. I'm actively involved in the code effort, so I would not want us stepping on one-another's toes. I do appreciate your input. An odd effect of attending law school is that I tend to retain my copyrights. Consider it like version control. BenWilson May 22, 2006, at 02:34 AM
• Google API V2 behaviour
  • Today's current version of the API (2.51) and the preceding versions: 2.50a and 2.49, result in the display of the map controls only, with no map, as described above.
  • Versions 2.48, 2.47 and 2.46 display the map, albeit with the display problems summarised above. --Des May 21, 2006, at 07:33 AM
• Thank You
  • Just noted the revision and updated to the new script, both Firefox an IE6 are behaving nicely. As you probably noticed, locations could feature highly in my wiki, and having to do this with a method external to PmWiki just wasn't right. Having an internal method will be ideal as it simplifies the process (for users).
  • Great to see the new features already included e.g. overview already there.
  • Need to go play with new toys/options in config to get slider and map type buttons back, they've gone.
  • Did I say Thanks? --Des May 22, 2006, at 11:10 AM
• v.1.0.1 bugfix
  • Added map.addControl(new GMapTypeControl()); to restore missing Map Type selection buttons
  • Fix spelling bug crtl that was defeating parse line $cki = ($opt['ctrl']) ? $opt['ctrl']
  • Fix logic error in $map_controller_size = (strtolower($cki) == 'large') where == should have been !=
  • Uploaded a revised gmap_api-1.0.2a.php file, annotated for author review and approval
    • My apologies if I've stepped somewhere I shouldn't. I deliberately didn't add any notes regarding version to the page, or change the version available for download to readers. My intent in uploading an edited script was simply to avoid confusion with the interpretation of a written description, and the name/number choice is just to indicate which issue it came after. The numbers/letters chosen wouldn't be expected to arise in a proper versioning scheme (I hope). If there's a preferred way to pass script details, I'm happy to comply and avoid anything getting crossed or confused in future. I'm afraid I only spotted your nota after uploading the last, so apologies for possibly repeating the slip. --Des May 22, 2006, at 04:58 PM
      • No worries. We're all friends here. I know this script will receive a lot of interest and so I want to ensure consistency--even if I consistently break things. I appreciate your input. I don't normally have time to read this all the time, so emailing me would be faster. :-) BenWilson May 22, 2006, at 05:06 PM

Ben Wilson Maintained