Google has provided a platform for users to create their own maps. It is called Google Maps Engine. It allows the user to overlay data on Google base maps (you have a choice between nine different maps.) The user can upload a .CSV file of data, can use the Google search bar to find locations, or just drop a pin onto the map using the mouse. It also has a line tool that can create both lines and polygons. When the map is complete, the user can export the map to a KML file, embed the map (as long as it is made public through the Share option, or print it. Overall, Google Maps Engine is a nice little program for those with little to no mapping skills.
My first experience using this program was mapping the locations of the 1st Michigan Calvary regiment in the years 1864-1866. The data was taken from the National Parks Service website. The location data was not very clean. It was a paragraph of text with location names and dates. No coordinates were given, either lat/long or UTM, for the sites. My task was to interpret the data, clean it up and map the movements of the Calvary regiment. The end product can be seen below:
Base Map: I decided to use a base map that had softer colors. The whole purpose of the base map is to be a reference but not to overpower your data layers. I liked that this layer had state boundaries, city labels and a good contrast between land and water. While I didn’t really want roads on my base map, I felt that this layer handled them in way that kept them from “taking over” the base map.
Layers: The data I was going to be overlaying needed to be split into multiple layers. This would provide a nice way to organize the data for the user. I decided to use each layer as a year. For this map then, there would be three different layers. One issue with this organizational method is that the majority of locations come from 1864. For my map I have 37 points in 1864, 11 points in 1865, and one point in 1866. That means that 2/3rds of my points are all in one layer. However, I felt that dividing any other way (by campaign, by season, by region, or by creating multiple maps) would create larger issues that would have to be addressed.
Points, Lines, and Polygons: The entirety of my data layer are points. It was pretty clear that the data I retrieved from NPS was not specific enough to employ polygons as representations on the map. It was difficult enough to find these different locations let alone the area of each engagement. I also did not use lines on my maps, though this decision as not as apparent from the data. At various points, the source data does give some directional information in the Calvary’s movements. In this way a line could be used to make connections between the locations. However, I felt that the lines would be more confusing than helpful. The only control over the lines that user has (beyond actually drawing it) is the color and line weight. Thus the line would not be able to convey directionality of movement, which was a problem for me. If Google provided a larger toolbox for editing the line, then I might have included them in my map.
Symbology: As I was dividing the data into layers depending on the year, I knew that I wanted to differentiate between these points on the map. I decided the the use of color would best highlight the chronological difference rather than a change in the icon. Using a different icon for different years would confuse the end user as they would assume that a different icon probably means a different event more than a different year. I opted out of the default “marker” symbol and chose a simple circle. I originally chose a specialized marker from the “Disaster” section but Google does not allow you to change the color of special markers thus limiting my choices to the standard five icon shapes. Each year/layer got its own color. 1864 is a shade of red, 1865 is a shade of blue, and 1866 is a dark grey. As the base map has softer colors, I chose the softer colors for the icons. I felt the stronger colors were too harsh of a contrast on the map.
Labels: Google Maps Engine allows the user to label the points, lines, and or polygons. The user can choose what column from their data table they would like to label each point with. I “named” each point by its recorded name from the NPS data and then included a field for “Date” and “Campaign.” I didn’t include the campaign for every point but for some I did. Labeling is a great way of providing quick access to information about the data layer. However, the data points were so close together than labeling them would create a mess of words across the map. I mitigated this by allowing the end user to see the name of each point on the side menu bar. In addition, I reordered the list of locations by date and made note of it in the title of each layer. For example, my 1864 layer is called “1864 (Chronologically.) Then all 37 data points can be seen in chronological order. The end user can then click on any one location and have the map pan to the point on the map, and pop up the informational menu that contains the specific date.
Limits: While Google Maps Engine is a great program for a novice cartographer, I found myself getting frustrated with how limited the tools were. This was most noticeable for me on the cartographic design side. In all aspects of aesthetics, the user is limited in how design their map. For instance, I found myself relegated to use their predetermined color palette instead of controlling the HSV or RGB values. IN addition to the design, the data table (in GIS it is called the attribute table/fields) was a very controlled environment. I couldn’t manipulate each field nearly as easily as I would have been able to in ArcGIS. Ultimately, Google is providing a great tool for those who want to make maps and don’t have experience. Yet, I could have designed a much better base map and data layers using GIS software.
Reveal and Conceal/Conclusion: For the end user, my map is showing the various movements of the 1st Michigan Calvary regiment. From this map, they can glean the overall involvement in the war of that regiment, where that regiment was during these years, the winding down of the war in 1865 and the continuing assignments of the regiment to Fort Leavenworth and the District of Utah. However, the map is lacking in transparency. With most end users, they take the geographic location represented on the map as the actual location of that event. This presents a problem as some locations were listed as “Near Kearneysville” or Hanovertown (which doesn’t exist anymore.) For some of these points, I chose to leave them out as I felt that I could not adequately represent the data by adding a point to the map. In this way, the original data does not provide specific and clear locations for the cartographer to use. Without a section of text explaining that to the end user, assumptions will be made that the map is showing a highly accurate depiction of the regiments locations. The map is also not illustrating the extent of the involvement by the regiment. While the 1st Michigan Calvary was present at Cold Harbor, the end user does not know how involved in the fighting they were as well as the importance of that regiment in the battle. Again, the end user is left to assume the level of engagement that regiment undertook at each location. Ultimately, this map is incomplete in its representation of the data without a narrative. A written narrative would supplement this map well and provide clarification on various issues that the map, in its current state, could not provide.
However, with additional research and design, the map could be both a strong visualization and strong narrative by, for example, better using the data table and having a stronger design component.
