SIGNIFICANT BITS

by Sean N. Henderson

DACS.ORG BUSINESS

Those interested in getting involved more deeply with DACS.ORG should contact one of the board members before the end of November. Between the board and officers, there will be at least 2-3 volunteer positions to be filled in the next six months.

We would also like to begin promoting immediately our December meeting with futurist John Patrick. As members, we should do all we can to make this a standing room only event. John Patrick's presentation to our group is typically our most highly attended event of the year. However, we are keen not to take this for granted and therefore request all DACS members to personally talk this up with friends and colleagues.

President Rob Limbaugh has a resource in place to begin managing on a quarterly basis some operational and back end goals of the board. The results will be self evident over time, but the net effect is that all matters related to membership will be more integrated. DACS offerings will become even more of a value.

MAPPING AND MASHUPS

This past month, I learned about geocoding, mashups, and mapping. The project at work was to put some of our deliverables, typically given in a spreadsheet format (E.g., a listing of our client's customers), in a format with some more wow-factor. My boss had just read about the number of people and businesses doing “mashups” ( http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid) ) and said, “go forth and mash!”

For those who have used CGI on a UNIX/Linux platform, screen-scraping was the tactic of choice for creating new pages from others. Many have maintained sites over the years where the page layout wasn't useful. They have used a screen-scraping tool to take a publicly available web page to reorganize the data and/or combine it with other data into a page that was more useful for an intended audience. For instance, I ran a music events page over the years, and I would let contributors know that if they posted their content on site A, then they'd get double exposure because it would also get screen-scraped and slightly reformatted into the more narrowly focused music events site. I don't see why this is so revolutionary because this was the original intent of the World Wide Web – the pages were made up of markup from one server with links and/or content pulled from another. The UNIX command 'wget' is what us old-schoolers used in the pre-mashup era.

Today, this combining of content is more official and the hooks into it are more exposed with less hacking needed to get it right. With XML, RSS, and various exposed APIs from Google and others, combining content is more straightforward and, what is more important, intended. Screen-scraping got sort of a bad rap over the years because it came to be associated with using others' content in a way beyond what they intended. Using currently available mashup tools, there is no such restriction and content providers intend for it to be, and are happy when it is used in this manner.

DETAILS, DETAILS

The map project started out strictly using Google Maps API. My object-oriented coding is still quite lacking, so I found this hard to use. Also, given that our data was not financial, I tried looking for something to run on our own servers. The application I found for that was MapServer, which is open-source. We were shy on boxes at work, and having attended Rob Limbaugh's Virtual Computing SIG, I knew that there was such a thing as a virtual appliance that I could load and discard at will. My search proved this correct and I soon located the MapServer appliance and fired it up under VMware.

Alas, MapServer had a steep learning curve and wasn't in keeping with the whole “mashup” idea my boss had where there was an implied timeliness to doing these things. A friend gave me a hint about something called GmapEZ. Wow! This was the ticket. In less than two days I had a mashup application working and spent the rest of the time tweaking the style and layout without having to worry about the linkup between our application server and GmapEZ. In addition, we maintained our data security because we only passed geocoded longitude and latitude, and not any client-identifiable data. That came from our end. If someone randomly happened onto the map page, it would merely show our company's location on a map with our logo and slogan. (Use of Google Maps API requires that the page be publicly accessible unless one spends the $$ for the enterprise edition of the API.)

WHAT IS GMAPEZ?

GmapEZ provides a DHTML interface to the Google Maps API. This is great for someone like me who didn't want to roll their own object-oriented code. How it works is that inside the DIV tag in the HTML (in our case CFML), the geocoded items get listed as links and between the A tags the type of marker (pushpin, et al.) and color is specified. That's it. When the page is loaded, a provided bit of Javascript sends the links listed in the DIV to the Google Maps API in a way it understands, then returns a map!

There are a couple of things to keep in mind here. It is still required to have a Google Maps API key. Also, Google Maps API only does the USA and parts of Canada and Mexico. The key is tied to the production server, so it's not possible to test on a development box unless the development box is publicly accessible and has a dedicated URL.

The other thing is that your data has to be geocoded! This turned out to be a real trick since our client's customer data was all over the place in terms of address information. Eventually, I went with just geocoding only addresses that had city, state and country info. Trying to include street address info was neither needed for this project nor possible with any predictable results.

GEOCODING

Geocoding is the process of getting longitude and latitude information. The site I found that did this the best and easiest was GPSvisualizer.com, which uses a combination of Google, Yahoo and other sources to put it together. More information can be had on their site and it was a big help.

Happy mashing.