I've been prototyping some new ideas to get us thinking about the roadmap for the campus map. A working demo is at http://maps-dev.ucsc.edu. The notes link below talks about the technology stack; Drupal, Gmap and Location modules were evaluated in the first round and later eliminated. I've landed on the OpenLayers and Geo modules for the type of requirements we need to meet.
I've been tracking some of the tests and tasks as I go along. Reference notes are at http://maps-dev.ucsc.edu/content/maps-notes and http://maps-dev.ucsc.edu/content/design-notes and http://maps-dev.ucsc.edu/content/design-questions-discussion.
In general Drupal and mapping make a great stack that has a lot of potential. In later versions, I expect that we'll do proximity searches and come up with other data that can add value. I also hope to turn on the geoRSS features and let people pull data out of the site to mash with other sites.
Problem/Opportunity
The basic problem we're facing is that the existing campus map web site is several years old and needs a refresh. The rise of google maps, google earth and other technologies is providing an opportunity to take the best of our existing two dimensional graphics and combine or mashup the best of google mapping data (geolocation, etc.).
Some of the notes, I've been tracking on are located at http://maps-dev.ucsc.edu/content/maps-notes
Other challenges for our campus is that we don't have our buildings addressed. The campus has the address of 1156 High St., but the individual buildings do not (yet) have individual addresses. Add to that we didn't have street names for many roads until a month ago! Without an authoratative source for building geocoding information, we're kind of making it up as we go along. With this in mind, we'll make use of the Geo module over time as buildings get addresses. In the meantime, we're making use of OpenLayers Well Known Text (WKT) field to lay in latitude/longitude points for the items we want to mark on our map.
Roadmap
What we'll be working on in is a definition of what we'd want to include in the next generation. This might include the images from the existing map, the addition of data fields for latitude and longitude, overlay information (parking lots + number of spaces, by type [A, B, C, M], buildings, shuttle routes, etc.).
Work Breakdown
We are forecasting the need that we'll probably need to bring some Drupal/mapping help to work on the development or custom module creation to close any gaps between the modules. It could also turn out that we need some javascript/jquery expertise to work on UX issues. More on this as the requirements evolve.
Evaluation 1 - gMap/Location
Installing the gMap and Location modules that are part of the mapadelic suite was pretty straightforward. There are several good tutorials and screencasts as reference.
I've installed the following modules based on the tutorial at, http://www.drupaltherapy.com/gmap
- Gmap
- Gmap Addons
- Location
- CCK
- Views
I added the third party javascript file, egeoxml.js to the gmaps_addons/gmap_overlay/thirdparty directory so that the overlay module can read a KML file and place points on (over) our existing points. This would be useful in creating a Parking layer or a information booth layer or a cafe (food) layer.
One of the apparent limitations of the modules is that in reading a local KML file, we are only able to use a default placemarker. Ideally, we'd use a "P" for parking, "I" for info, a house for housing, etc. Not sure if this is a configuration issue or a KML validity issue.
Some of the issues I ran into with this module configuration were that I couldn't easily configure to get a detail level that I was after. My design pattern was to work at zoom level 15 and for detail, to center a view of the building at a zoom level of 21. I was able to create some different views that met our requirements (taxonomy based, etc.).
The ability to toggle overlays was another design requirement. I couldn't easily get this done using this setup.
Evaluation 2 - Google Maps Tools
I installed the Google Maps Tools module http://drupal.org/project/gmaps after reading that it was a full featured and more actively maintained module. It has a lot of really great features, but there aren't a lot of tutorials and examples out there to assist a new map maker. This feels like it should work, but it was too complicated. So, we moved onward.
Evaluation 3 - OpenLayers
The OpenLayers module and associated tutorials got me up and working in an hour or so. I got the added bonus of a LayerSwitcher that toggles basemaps and overlay layers as part of the UI. There's a lot to this interface and it works well for my purpose.
After working with OpenLayers and OpenLayers+ for a few months, I can say that this combination has met our needs and has been very stable. As we near the end of our initial development, we're beginning to load test and tune. My intent is to serve the site from a higher performance using PressFlow and Mercury. That work is being configured in March of 2011.
Next Steps
As the campus moves forward in its way-finding work, more of our buildings will become addressable. This will lead to opportunities for geotagging. As our data gets better, our Google experience also gets better. Other ideas we're pondering is how to provide additional web services of map information to other web sites, creating custom maps (http://tilemill.com) and applications on the academic side of the house for data visualization.