Here are a few things that have come up more than once from previous versions. Also, it's worth checking the online copy of this document, which will be updated over time.
If something isn't described here, check the cacti.log for errors. Weathermap usually produces a useful error message if there is a problem. Next, try setting Cacti's Log Level to DEBUG for 10 minutes, and then have a look in cacti.log. Don't forget to turn the Log Level back down again!
The answer is probably no, or at least not directly. In most cases, this is the result of a missing dependency, either PHP with no GD, or with an older version, or without PHP support, or without TrueColour support. I do try to extend weathermap to make these error messages more explanatory wherever possible, but ultimately, you need to get PHP working first.
Beware that on some systems you can have a working GD in your 'web' PHP (mod_php) and still have a non-working command-line PHP - Debian and derivatives (Ubuntu) can suffer from this.
Also be sure that the PHP you get from the command-line is the same installation as you expect - 'which php' and 'whereis php' will provide some *nix users with an idea that they are running the right one, as does 'php -m' and 'php -v' (is it the version you expect?). Also, some packaged PHP systems (MAMP, XAMPP, WAMP etc) have the module installed, but disabled by default. Check your php.ini to see if there is a commented-out line like 'extension=php_gd.dll'.
Check if this is still the case when Weathermap is the only plugin. If a plugin dies completely, it takes the poller and any remaining plugins with it. This appears to be a problem with some versions of 'Reports' in particular, where anything listed after Reports in the plugins list will not be run.
This is PHP telling you that a function that Weathermap requires is not available in your PHP installation. Usually, it's to do with either GD, or FreeType. It can be that you have those libraries, but not current enough versions, or versions compiled without particular options. For example, it's possible to have FreeType installed, GD installed, the php-gd module installed, but that the GD library wasn't compiled with FreeType support so they don't know how to talk to each other. This tends to be less of a problem on packaged systems than where you build your own libraries.
This is almost always a permissions problem. Look in your cacti.log for lines starting WEATHERMAP to see what is going wrong.
Is it about 8 times too big, by any chance? Historically, Weathermap was mainly used for SNMP Interface statistics, which use bytes-per-second counters ("octet counters" in SNMP-speak). Because of this, the standard RRD datasource plugin multiplies everything by 8, to get back to bits-per-second. New in 0.9, you can get the 'raw' value from an RRD file by using 'gauge:' as a prefix.
I have not seen this one myself, but a Chinese user has, and it seems that PHP doesn't always use your system timezone correctly. The fix is to edit php.ini to change date.timezone
It's a GD bug. It's documented here, and the reason it mainly affects Debian is that Debian links to the system GD (version 2.0.33) not the built-in PHP one (2.0.28ish). For whatever reason, the problems aren't present in the PHP GD library, which has a different alpha-blending implementation as far as I can see from the docs.
The bugs are apparently fixed in GD 2.0.34, which has been released and is in Debian unstable. Users report that upgrading to libgd2-xpm from unstable will fix this problem if you can't wait, or recompile PHP.
There are plenty of sources online. A good google search would be 'visio network icons'. Some to get you started:
You can create a NODE with no links and no label, but with an ICON. The ICON is your logo. You can also use this to embed images from somewhere else - even dynamically produced ones - how about MRTG graphs or RRD stripgraphs embedded in your map?
You can use the VIA keyword to make a link go around corners.:
See this article for more about parallel links.
See this article for more about parallel and aggregated links.
Adding the editor in 0.7 has made adding a new core weathermap into something that needs more consideration. Anything that dramatically changes how you make a map (like the LINK DEFAULT and NODE DEFAULT changes for 0.7) should mean a similarly big change in the editor. All the options should really be editable from the editor too. In reality, just getting the editor to run smoothly on more than one browser is sometimes painful, let alone re-tooling it to add new features. With that all said, there very likely will be a new version of the editor in 0.9, with drag & drop editing, and (more) complete support for all the new features since 0.6 (which is the version that the editor really was written for - it was written before I added new 0.7 features. D'oh!).
It depends. I have an internal idea of what I want weathermap to be like. I don't want it to feel (too much) like a small program with everyone's wishlist bolted on afterwards. If it seems like something that a number of people could use, and doesn't dramatically change the direction of the program (it won't get mail-reading capability anytime soon), then it stands a better chance. Things that take dozens of parameters to adjust something very subtle are less likely. Ultimately, it is a GPLed program though, so you can always add your own features! I try to keep a todo list on the website for current work-in-progress. Obviously, things that I want are always sensible and useful:-) .
Actually, this one isn't very frequent. If you do find yourself asking it, feel free to make a donation, or send a gift, though. However, I do like to hear from users anyway - it's nice to know that people do use this thing.