Hello mappers,
I have a proposal that I think will make the gmap module stronger, but I wanted to solicit other opinions before I start writing the patch.
I recently was working on two additional gmap functionalities for a client: the first was the ability to load KML files located at an offsite URL as overlays, and the other was a "click to add nodes" functionality so that users could add images by simply clicking on their locations on a gmap.
In both cases I started trying to build my functionality as add modules to gmap. This quickly broke down as I discovered the macro processing was hard coded and not easy to work with. Additionally, I attempted to modify the gmap module itself, but again working with the macro processing was such a headache that I abandoned that idea as well. Finally, I developed these tools as stand alone JavaScript additions, with not UI in Drupal. Not an optimal situation, but I had to get these features out in a reasonable time frame.
I've been thinking about my experience since then, and I have come to the following conclusion: the gmap macro hinders development of the gmap module and prevents additional module development. Therefore, it should be discontinued in favor of a simpler, UI and data model driven alternative, similar to Views.
Let's draw this out some more:
- The macro hurts the gmap module
- Benefits of the macro aside (I'll get to this in a moment), the significant parsing and manipulation of gmap text strings is a huge encumberance to gmap. Having to update that parsing logic from version to version, incorporating new data into the macro, and otherwise making the gmap module much longer and more cumbersome than necessary are productivity killers for the gmap module maintainers. I would argue that if we were able to present a UI and store the user's choices in the database, instead of in a text string, the module would be smaller, lighter and easier to maintain, freeing the maintainers to fix other bugs or code new features.
- The macro hurts other modules
- Adding functionality to the gmap module is hard because to get at that functionality, users have to specify settings in a text string and some code needs to parse that out. This makes extending the macro impossible for external modules. In an investigation of drupal-5 and HEAD branches, only 1 module out side of the gmap package requires gmap!. Clearly, developers are not combing gmaps with their data and tools. I believe the macro is to blame. Constrast this with views, where tons of modules either require views for their functionality or provide views hooks to add to views. This is the model I'd like for gmap.
- The macro hurts site admin productivity
- When macros are stored as text strings in the bodies of nodes, reuse is hindered. For example, if I create one macro and use it on node 1 and node 2, I now have two copies of the macro in existence. If I update the macro in node 1, node 2 remains the same. I would argue for a system where we use ids instead of text strings. If one changes the gmap attaches to an ID, all uses of the gmap would update.
- The future of drupal is fields not filters
- While filters certainly have their uses, the future of gmap is fields not filters. I would prefer to see gmap expose a CCK field that allows one to create maps (or use existing maps in the system). We could certainly still support filters, but we need to focus on fields more, and leave behind all the baggage of parsing and string handling if possible.
So what do I propose more specifically?
- End of life the macro. Let people know early that gmap will stop supporting the macro as of the 5.x-1.0 release. Perhaps earlier. Perhaps provide a tool that parses current macros and saves them in the new data model.M
- Copy as much of views' architecture in terms of allowing modules to add functionality to gmaps. Ie. forms for configuration, hooks to add and remove data, etc.
- Create a schema that normalizes as much data about the gmap as possible (e.g. name as a varchar, a serial ID column, etc). Store any thing else as serialized PHP in a text column.
- Provide a really simple filter of the form
[gmap 1234]
where 1234 is the id of the map. This will help ease people off of the macros - Pull out all the macro processing and revisit the gmap internal represenation. Make leaner and meaner
- Celebrate the dawn of a new gmap module ;-)
Thoughts? Votes for, against? I probably start on this idea soon, so registering you opinion would be appreciated.
Comments
Go for it
Gmaps needs splitting up and simplifying/refactoring. Mmmmm....gmapfield.module.
The DevSeed guys are doing some geocoding stuff -- http://www.developmentseed.org/blog/geocoding/geonames -- should try and work with them somehow, I haven't seen their stuff anywhere...
Anyone up for re-writing location from scratch :P ?
The recent work we've been
The recent work we've been doing w/ maps is mostly related to geocoding. The main take aways were that not just one geocoding service can do it all, at least not yet. Google cannot do anything in the UK and China for legal restrictions, while Yahoo is. There were a few instances where I found other city,country pairs passed to Google did not work, while they did with Yahoo. However, there were several cases where Yahoo put city,country pairs inside the US. This all made me realize a more robust geocoding option should do things like check that the returned lat/lon is at least within the range for the country you sent it, and if not, don't geocode, instead maybe failover to another geocoder to try. In some cases, people may also want the most accurate possible, so if that means sending a city/country returns nothing from one geocoder, trying again with just the country may be desirable, to at least get the data on the map to be corrected by a human later. Though in some cases a customized solution may be necessary to get what you want, I think there's also opportunity to build out geocoding options, and it could probably be separate from any other module, or at least easy to hook into. There were recent changes in the location module to include geonames as a geocoding option - at least a patch was rolled - but is anyone else working on building out geocoding in general along the lines above, or have any thoughts about that?
BTW, great work on gmap 5, bdragon.
Ian
Ian Ward
Development Seed
Twitter: @ianshward
nice proposal
i have only causally tried out gmaps so my opinion should n ot count for much. but i'll agree that gmaops was a beast when i looked into it. i did some tests on this groups.drupal.org site that users and groups could be shown on maps and concluded that the modules were not ready at that time. maybe others are concluding same, based on marc's research. so, my barely informed gut says that this is a good move. i'm also eager to hear from people with more knowledge about this.
promoted this post to home page.
Hell yes!
Yeah, I agree with this, as far as I can with the experience I've got...
I'm just about to start building a site that would be using this stuff, so it would be nice if you could flesh out some concrete plan of action based on your initial thoughts and the responses here. I would be willing to throw some bounty cash at it, although I can't afford much.
OT, are developers potentially putting themselves in a difficult situation by offering this module out as part of a commercial site development? I hope not, I've been talking about it for months, having spent some initial time looking at it and finding it "ok". Some of the existing behaviour seems pretty odd and idiosyncratic...
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
It works
It does work. Along with location, etc. Some folks just have really high standards :P
Don't get me wrong, there ARE issues with it, but you can get it working and it's just fine. I've never used the crazy macro, but rather the, you know, mapping pieces :P
Ok, cool.
Thanks for that info Boris, I just wanted to check that before I got into any major trouble!
It's kinda frustrating that there's no way of telling how functional modules are that don't have an official release, but I suppose that's the way the cookie crumbles... in this case I would probably have suggested the maintainers release it with a sub-1.0 version, but that's just my 2c.
When I've had another proper look at this module I'll try and remember to leave some more notes here if I find anything useful.
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
Sounds good to me
I'm up for anything to improve the gmap / location modules. Not something I can code myself, but I'd be willing to help test.
Michelle
Thumbs up from me too. I
Thumbs up from me too. I just got back from Where2.0 and with Google's vision of the Geoweb becoming a broadly supported vision, I think it would be great if more modules would connect to the location modules and Drupal become the premier geo-enabled open source content management framework.
Chris
Sure
Was contemplating this myself, actually.
My preferred method of doing maps at the moment is actually building the array in code, actually. Making a cck field would be pretty easy really, you could just persist the #settings array and it would pretty much take care of itself.
I've already put some work towards modularizing the structure (behavior flags, etc) and am moving the code towards "everything has a toggle in the interface somewhere."
It would be nice to generalize the "map defaults" form and use it for working on specific maps, possibly in combination with pieces of the current macro builder form.
BTW...
Thumbs up / much love to bdragon for biting the bullet and improving gmaps under D5 as much as it has. Get some help :P
Bdragon: +100
Totally. There are great things going on in gmaps (I love the handlers in the JS files -- like Drupal's hooks). I think moving to more hooks on the php side would be great as well.
Again, +100 to bdragon.
-m
Working on it
I'm hoping to take over as lead maintainer on gmap so I CAN get some help ;)
I will be working full time on Drupal mapping/geospatial related stuff this summer, so expect lots of new stuff coming down the pipes soon.
totally agreed... drupal needs mapping API
Macros for gmaps makes sense if you want to give users an easy way to create a custom map for a node, for example.
I tried to use the Gmaps.module for a site I built last year [http://map.thebeachloversbeach.com] but it proved totally un-customizable. I ended up manually outputing the googlemapsAPI javascript to add markers and custom icons to those markers using a custom view function.
Creating a $gmap object like a $view object would be great. I am imagining something like this:
$gmap = Object(
"markers" => array(
0 => object(
"point"=>array($lat,$lon),
"icon" => "blue",
"onclick" => "showInfoWindow"
),
),
"type" => "hybrid",
"size" => array(300,200),
"controls" => "large",
"center" => array(22.222,33.333),
);
I have a decent amount of experience with gmaps and wouldn't mind contributing to a rewrite of the module. I've been hating gmaps module for a long time, and it would be excellent to see a new solution.
g
Jon Pugh
Founder & CEO
THINKDROP
open source consulting
http://thinkdrop.net
macros - so 80's
I find it easier to load the arrays in code than to try to build the maco string. A forms UI would be nice to have. But what really adds value for me with the Views UI is the view metadata import/export functions. Without something like that, you still have the same problems with upgrades, production moves, module authors contributing map settings, etc.
I have two things to contribute in the gmap <> views integration area:
1. Passing the viewport from google maps to drupal as view filter parameters.
2. google maps consuming views output as JSON
This involves gmap javascript as will as views code.
How do you see this evolving with the Geo module?
Ahhh...geo!
Yeah, Geo is looking very interesting, and I haven't done a deep dive on it. But Location has always been a lame duck. Geo does the coordinates stuff....but none of the "address" stuff. And, of course, it doesn't do rendering. Gmap seems like it would be one of a number of plugins that render the information that is stored / gathered by geo.
geo
Boris, you're spot on correct. Geo does the spatial storage only and leaves the geocoding, address storage, and display to other modules. I think the location module could get a rebirth using geo for the data storage, postal.module for address storage, and creating a hook_geocode (which gmap for example could implement).
I've been working with
I've been working with Drupal and Google Maps API this semester as part of journalism grad project for OurTahoe.org called Places. The key feature for us was the ability move past a simple lat/long point to defining and comparing the overlap of polygons. The work I've been doing with Places so far has been front ended... a combination of custom code and custom content types in Drupal that duplicates the inserts to MySQL and PostgreSQL/PostGIS. I have some time this summer to "modularize" that work, but I wasn't sure how to do this so it would compatible with the other Drupal mapping projects. It looks like Geo might be what I'm looking for.
Is Geo intended to extended node with geo data with the geo_link table? What's the logic in doing that over including the nid in geo_field?
Geo
Wow. Everybody is talking about geo. And we haven't even really publicized it yet. :-)
I promise a longer post on this later, but the quick news is that geo is a replacement for location's data storage system (including extensive views integration). Geo will use postgis or mysql spatial if installed, and will fall back to CCK if not. The link stuff is about pulling in existing shape data tables and joining them (via views) to your nodes. E.g. "this node is about senate district 5, join it to the senate district 5 entry in my 'districts' table"
It already has some front end integration with gmap_views to display points (other shape data will be coming soon). Bdragon (gmap maintainer) is an active participant, which means that what geo needs for generalization in gmap will probably get in. :-)
It will probably get some integration with the postal module for the geocoding/storage feature of location.
Again, much more on this later. Time to code. :-)
Just a note, we ended up
Just a note, we ended up writing our own location module / api that works with CCK and has proximity searching. Wrote a custom google map module as well: http://www.mothersclick.com/groups
The result was something super lightweight, super fast, and super easy to implement.
However, it's not super flexible but we have some very strong components and it's working in a very high traffic area at the moment :-)
Partner at Detroit Venture Partners. Sold ParentsClick to A&E. Ex-Drupal dev. Cornell Engineering alum. Tech pioneer leading startup renaissance in Detroit.
Sounds like a good proposal to me
Sounds like a good proposal to me. I haven't had a chance recently to catch up on the Gmap improvements already in place for 5.x but making maps more reusable and easier to create would be great. Looking forward to checking out geo module too, it sounds very promising!
flexibility & taxonomy
I have been struggling with gmaps for awhile. In fact, at the moment gmaps has totally bombed on my sites. We run travel websites and I envision great thing for gmaps, showing locations of all the horse riding places in our area, pick a hotel and show the restuarants near by, and so on (I could list plenty.) I'm hoping that google maps starts doing driving directions. I would be happy to help as these are important to me.
Public participatory GIS
Allo
As a proto-academic looking to work on 'public participation GIS', I've been looking into using Drupal and Google Maps as an open, cheap (free) and re-useable public participation tool. So I'm keen to see where all this goes... is anyone else on this list in the UK? I keep on thinking that it would be good to get together at some point. (Though I'm actually in Oz until mid-October...)
Yeah! And: pointing out a particular problem with current Gmap
Yes, I found that the current incarnation of the Gmap Module in combination with the Location Module does some very odd things (at least for addresses based upon German postal codes). At first, I did not realize this was a problem until I found out that in fact, Gmap Module and Location Module only seem to hand over the German postal code to the Google Map Geocoder, which is really odd taking into consideration that a full German address was given in my setup -- IF it really uses the geocoder at all! Probably it just uses the German postal code database for geocoding...
So what happened was: the user entered an address (via the location module) or set his user profile address. Location Module in combination with the Gmap Module now rendered a map with placemarks.
All looked fine until you zoomed into the map which brought a not so nice surprise: the Google Map did not show the precise address but somehow the center of the particular German postal code's area. Well. Nice try. But not at all usable taking into consideration that especially in some more rural areas, a single post code can span quite a large area in Germany and the oddities get even worse for those damn "post box and company ZIPs" - these are specially dedicated post codes that do not describe a geographic area in Germany, but that are assigned either to postal boxes or to really large companies. If you entered e.g. their address ZDF-Straße 1, 55100 Mainz (which suffices to address a letter to the German public broadcaster ZDF), the Google Map would not find the ZDF TV center, even though "ZDF-Straße 1" as well as "Mainz" would suffice Google's geocoder, just because 55100 is not a "real" postal code describing the exact area but describing the company ZDF (the real postal code for Lerchenberg, Mainz, would in fact be 55127, however Gmap will not put the placemark on the terretory of ZDF but somewhat "next" to it as the broadcasting facilities and the administration buildings are not really in the precise "center" of 55127 - so bad luck.
So, while it is a nice idea of the Location module to use the German ZIP-code database, Gmap seems to ONLY look for the geodata from the Location Module's postal code database, no matter what else was entered, resulting in either wrong or completely wrong display of the map.
Maybe this hint could be useful for your project, Google's geocode in fact is quite good, so it should really be used, especially if the address was delivered by the location module.
I must admit that I am not completely into the Google geocoder's API, I tried to tweak the Gmap module to instead look for the REAL address from Location Module and use send that info over the Google's geocoder, but I did not succeed... (ok, I did a) not have a lot of time to spend on this, and b) it was not too vital, just a nice-to-have in that particular case).
So ANY improvement would be HIGHLY welcome!!!
Follow me on Twitter @panatlantica
Good idea
I would agree this is probably a good idea.
The macro concept was my first initial thoughts on using a google map in a node. (Insert a simple map with a marker on it into your text). I started to write a version of the module that used the mapthing module method of storing map information. However, I ran into some complications and ran out of time so it never got very far.
Good luck with it.
I stumbled over some helper classes...
...which might be worth having a look at - these are two PHP frameworks to more easily work with the Google Maps API:
I haven't had a closer look at them, but somehow the Phoogle seems to appeal more to me then the Solmetra Maps. I guess there are more PHP frameworks for the Google Map API... maybe use one or get inspired by one?! :-)
Follow me on Twitter @panatlantica
macro/filter has its place...
I've integrated gmap with my own node type for locating 4x4 trails. It works great. A nice benefit of the macros as opposed to fields, is that I can have 3 or 4 maps shown for one node. Also I can have a minimap in the teaser for some trails and not for others by customizing the 'break'.
If gmap gets refactored, let me know. I have written some simple distance calcs between two 'trails', both rhumb line
distance and great circle distance as well as a more generic parser supporting several lat/lon entry formats.
-John
-John
Simplepie and Geo data
Simplepie as added support for W3C WGS84 Basic Geo and GeoRSS.
Also the GeoRSS module seems to work it out.
Gmap Macro builds a node, is this possible
Hi,
Is it possible to build a map-node from the Gmap Macro, instead of having to copy-paste the macro-code into another node?
Off course the copy-paste method also gives a behaviour which is good for experienced users.
But for unexperienced users I think it will be better to have the normal create node experience, and than be able to make a "map-node" from the Gmap Macro.
Is this possible, did somebody allready made a map-node from the Gmap Macro?
Please respond.
Thanks,
Greetings,
Martijn
I also think this is great
I also think this is great idea!
The current macro concept would make some sense only, if the macro output would be in JSON format and gmap.js would be able to parse it directly...
The Ideal scenario would be to separate API completely from viewing widgets (why macro filter should have more prominent role than other GMap viewing add-ons like gmap_views and gmap_cck?) and from any extra addons (like google geocoding). The API itself then would only handle map array and all the rest would relay on hooks and add-ons. Furthermore, the data flow towards js could be solely in JSON format and the js could be rewritten based on jquery (see jquery plugins like jmaps for example).
Progress?
I see that this is sort of an older post. Has ther been any progress made with this?
I am building a site with gmap, views and location modules and I want to add a few, overlays and controls but this has caused me to hack the gmap.js file. It seems
I hope to see something real soon.
Evo/