Hey everyone, missed this thread. It's been busy over at Proof and we haven't been able to maintain fmMaps like we'd want to. It's definitely got some internal issues we've all discovered as it's been out in the wild and gotten more usage. It's also got some dependencies I'd love to get rid of if/when I get some cycles to put to it.
I'd say the biggest issue right now is the dependence on PEAR::DB. I did this originally thinking it would be valuable to have an abstraction layer between the code and the database (MySQL), but have realized subsequently that the built-in MySQL API (
http://us3.php.net/manual/en/book.mysql.php) would have been easier and had better compatibility across different installs (some hosted sites won't allow PEAR to be installed, etc). We've also got some PHP v4/v5 issues -- I'd love to make it 100% ready-to-go with the latest version of PHP.
This project started as something that might have been a fully supported product, but the Google TOS at the time (
https://developers.google.com/maps/terms) didn't look too friendly upon charging fees. Read through section "9.1 Free, Public Accessibility to Your Maps API Implementation." in particular -- I think you consultants/in house folks are probably OK given you charge for
your services and not the maps API in particular. The product was essentially canceled and there are some vestigial bits hanging around, including incomplete documentation. I doubt those will ever get completed.
We use fmMaps for our clients to pretty good success (not withstanding some odd international geocoding that definitely occurs). We're torn between improving fmMaps, which is certainly a possibility, or switching over to static mapping (
http://gmaps-samples.googlecode.com/svn/trunk/simplewizard/makestaticmap.html) or perhaps something else altogether. If we do come up with a better solution, we'll be sure to share the news.
I'm happy keeping this thread open if folks have other questions or comments.
Cheers,
Mike