Mar 132011
 

I presented a poster about the Community Mapping project at HFOSS 2011, you can find the paper submission here OR you can read a copy of it below.  The tool has been launched, and is available for anyone to try out here: http://www.mymapper.org.  If you run into any bugs I suggest you report them on the GitHub issues page so I can take a look at them when time permits.

Abstract

Community groups have many interests in generating highly localized maps of events, key locations, and other important markers as part of their respective missions. Sharing similar objectives, community groups stand to benefit from using and sharing similar mapping tools well suited to the model of free open source software. We discuss the development and deployment of a Community Mapping tool initially planned for use in community groups in Troy, New York.

Introduction

The Community Mapping project was initially designed to help community groups in Troy, NY map locations of interest in support of a variety of different projects. Group members need a simple way to mark locations with additional metadata on a map, building overlays in a collaborate fashion.

To accomplish this goal, we built a web application based on Flagship Geo [6], a Ruby on Rails geographic data framework. Current focus of the project is on extending the application to other community groups as a hosted cloud application, providing a free software as a service-style offering.

Community Collaboration

Initial design discussions with a representative from a community group (conveniently, a professor at Rensselaer Polytechnic Institute) provided initial insight into the need for an application to quickly and easily build community maps for free. Local governments and affiliated organizations invest in software tools and integrated solutions to map data but many community groups,including those initially seeking this solution, do not have readily available access to commercial mapping products.

Recognizing the limited scope of an independent study, the Community Mapping project focused on providing a basic mapping solution that would quickly meet many of the needs of the local organization without requiring extensive training or time requirements from community volunteers. To accomplish this, the project was designed to be flexible, maximizing the use of general-use, optional fields. The software does not impose any validations or restrictions on what values can be used in the available fields except for the required latitude and longitude references. After an initial draft of the software and user interface was available, community group representatives were given a brief demonstration and asked for feedback.

The resulting conversations provided valuable clues into the different use cases the tool might have and also seemed to inspire additional projects that might be easier to tackle now that a simple mapping program was on the horizon. In addition to a discussion of the specifics of various projects that might benefit from the tool, the community members expressed a desire for several features like a need to print maps (an analog exchange this author regularly overlooks), and the ability to choose what maps are public or private. Continually iteration is underway to develop the identified features, at which point additional comments will be sought from the community groups.

Continual involvement of community members has been a key to developing a solution that would best serve their needs. By personally interacting with the community members planning to use the software, developers can gain extremely valuable insights into the problem the tool may be used to solve and better prioritize development efforts and focus on highly desired features.

Application Architecture

Community Mapping provides each mapping project the ability to plot points on a map using many different layers. Layers are used as a logical grouping of points within each project, and each point typically represents a distinct location or unique event on the map. In many projects using the initial software, the number of layers used on a map is relatively static and small in number, while the points being marked change often.

Layers

Each layer, unique to each project, is identified with a name, description, and graphical icon. These layers can be marked as hidden or visible on the project’s main map or can also be viewed individually (e.g seeing all the markers assigned to the “public benches” layer). The layer icon is displayed on the map as the graphical marker for each contained point., providing an easy visual clue to associate marker that belong to the same layer.

Points

Points represent distinct units of information on the map and can contain a variety of metadata useful to the specific project. Points are located on a map with a latitude and longitude, which can be looked up by geocoding an address if available. Address geocoding is provided by the Google Maps API [2], and is executed via AJAX when a user is creating a point. Each point is represented with the icon inherited from being assigned to a specific layer. Points are required to have a name and layer assigned but optionally can have a description, datetime, and address used for geocoding. Further work may add the ability to dynamically create additional data fields for points within a project.

Projects

To support multiple independent maps on a single instance of the software, layers are points and separated into projects. Each project represents one map, with an independent collection of layers and points. Projects include reference to a specific geographic location through an assigned a latitude and longitude to automatically center the map and provide a default point of reference when creating new points. While projects by default are public, they can also be set as private so only authenticated users with access can view the map.Each project can generate a static image of the map, suitable for use in presentations or printed material. In addition, projects can be exported as KML files [5] for offline display in software like Google Earth or for backup purposes. Future improvements may include the ability to import a KML file to a new project.

Software as a Service Offering

As the initial application was being developed, it became clear through the use cases mentioned by the community groups that this application was not serving the unique needs of a single community. Paired with it’s development as a Ruby on Rails web application, the Community Mapping project became an ideal candidate to be deployed and hosted in the cloud. Deployment in the cloud can greatly reduce the setup time and initial barrier of entry to organizations, especially those lacking technical expertise.

Given a budget of $0 and the lack of available production space for Ruby on Rails applications at Rensselaer Polytechnic Institute, the project has been hosted on Heroku through their free plan [3]. Static assets, such as the layer icons, are hosted on Amazon S3 [1] producing a monthly bill that can be paid in pocket change (e.g less than $1).

While the application enters a more public phase the cloud computing backend provides a great mechanism to scale if other community groups take interest in using the platform for local mapping. Significant use may increase the monthly cost to a noticeable amount, but that is a problem open source software solutions should like to have.

No specific components of the application require use of a cloud computing vendor to host the application. The dependencies are all publicly available open source libraries all of which can be setup locally on a Linux server or equivalent platform.

Technical Challenges

The initial demonstration of the prototype tool got off to a rough start at the community group meeting. Wi-Fi access was not available, and the presentation of the web based application had to be carried out on the group’s desktop computer running Microsoft Windows XP. During this demonstration in Internet Explorer 6 [4] several previously unseen bugs were exposed. Web application development, while much easier to maintain and standardize across platforms than traditional distribute and install desktop applications, is still not a completely standardized platform. Given the unknown resources of community groups, extra effort needs to be taken for the web-based application to be compatible with as many devices as possible, with particular attention paid to older hardware running outdated web browsers.

Conclusions

A final public release of the Community Mapping project is scheduled for December 2010 / January 2011. This initial public offering aims to adequately satisfy the needs of the local community groups that have participated in its development, but the application likely has uses far beyond that. Though a software as a service style offering, any community group can try out the tool to see what additional value it provides to their organization at no additional expense.

Acknowledgement

The author would like to thank Sean O’Sullivan ’85, RCOS, Dr. Mukkai S. Krishnamoorthy, Dr. Ken Rose, and the Troy Weed and Seed Program.

References

[1] Amazon Simple Storage Service. Retrieved December 17, 2010, from Amazon Web Services: http://aws.amazon.com/s3/.
[2] Google Maps Geocoding. Retrieved December 17, 2010 from Google Maps JavaScript API V3: http://code.google.com/apis/maps/documentation/javascript/services.html#Geocoding
[3] Heroku Pricing. Retrieved December 18, 2010, from Heroku: http://heroku.com/pricing.
[4] Internet Explorer 6 Death. Retrieved December 18, 2010: http://www.ie6death.com/
[5] KML Standards, 2008. Retrieved December 10, 2010, from Open Geospatial Consortium: http://www.opengeospatial.org/standards/kml.
[6] MICHALSKI, Brian. Flagship Geo, 2010. Retrieved December 18, 2010 from Github: https://github.com/bamnet/flagship_geo/

Think FOSS, Act Locally:HFOSS in the Local Community, Humanitarian Free and Open Source Software (HFOSS) Symposium March 09th 2011 CC: BY SA Copyright Brian Michalski, Humanitarian FOSS Project 2011.

Mar 132011
 

I found myself on a plane a few days ago and was hoping to do some work on a few of my Ruby on Rails projects, primarily some polishing of the the Community Mapping project I’m launching later this week.  Here are a few tips / tricks to developing in Ruby on Rails without internet access:

  1. Clone / Pull / Update the code for your application locally.  I do almost all of my development on remote servers so it’s rare I have the latest of anything on my hard drive.  git clone / git pull is a must to make this happen.  If you don’t have your SCM tool installed (like git, svn, hg. etc) you need to do this ASAP.
  2. Bundle. Bundler helps maintain the dependencies in your applications plugins / libraries but to do that is usually needs to download libraries from the internet unless you have them installed locally.  If you’re short on time (i.e. waiting to board the airplane) I would run bundle install from the app that has the most libraries associated with it.  Bundler will reuse things that are already installed and if you’re lucky many of your applications share common libraries.  The more wifi time you have the more applications you should bundle before you try and do it offline.
  3. Try and find any useful wiki / documentation pages that aren’t generated from source code.  These pages are likely going to include examples of implementations and features not associated with a particularly function.  In my case, I know there is a wiki page on Github that describes a “best approach” to the problem I’m having right now, but I can’t get to that in the airplane.  I tend to have the most trouble with jQuery-based documentation… when ever I need to know the syntax for a function like $.ajax I just google it.  Not possible on an airplane.  Instead of waiting til I land to quickly fire up wifi before dashing to my connecting flight (that’s my current plan), I could have been smart and downloaded the documentation first.  http://www.jqapi.com/ or http://docs.jquery.com/Alternative_Resources may be worth exploring.
  4. Don’t worry about the framework / gem documentation, at least not the function-by-function style documentation that is generated automatically.  You can regenerate it on your own if you need to.  The Ruby on Rails documentation can be generated by running `rake doc:rails` from your application directory.  You’ll find the output in your apps doc/api directory.  If you need documentation for a gem your system might already have it.  Run `gem server` to start a server with information about your gems.  If the rdoc link isn’t working for the gem you’re interested in fear not, you generate it most of the time using `gem rdoc gemname`.  I needed the documentation for CanCan so I ran `gem rdoc cancan` and presto, the server was able to point me to some moderately useful information.
  5. Hack it if you have to.  If you forget step 3 and step 4 didn’t help, you can probably write some really sloppy code to do what you’re trying to.  If you can’t (or don’t want to) write some junky code perhaps you can simulate it.  For example, I don’t know the exact call I need to figure out if I want to give the user access or not, but knowing that it will return true or false lets me very easily simulate what will happen in the rest of my application.
  6. Write lots of comments.  You’re flying in an airplane.  For all you know the baby crying behind you could be effecting your normal coding practices, it’s not going to be very easy to get back in the same mindset again so you should document what you’re doing extensively.  This applies extra if you have to use step 5.

Best of luck with your offline development, and safe travels.