Three Applications of V.3 Google Maps: Just for Display of Data, or Analysis as Well? ()
1. Introduction
The present study answers a question about the analytical capabilities of three computer-programmed maps that use the third version (V.3) of the Google maps application. These three maps are examples of V.3 pin maps, and polyline and polygon (choropleth) maps in the literature. One simple type of pin map employs a pin as a locational marker, whereas a second type employs different-coloured pins to describe classified quantities or qualities at discrete locations (cf. [1] [2] ). Polyline maps show linear, geodesic or street-network connections between locations (cf. [3] ). Polygon maps are enclosed polylines to identify areas of interest (cf. [4] ) and to display classified quantities for those areas in the form of a choropleth map (cf. [5] [6] ). In preparation for answering the question about three maps’ analytical capabilities, theoretical and practical issues in the literature are first reviewed about use of V.2 and V.3 Google maps for data-display and analytical purposes.
The history of development of Google maps (http://en.wikipedia.org/wiki/Google_Maps) is described in the literature, as well as their AJAX method of asynchronous loading from the server (http://en.wikipedia.org/wiki/Ajax_(programming)), and the application’s features in comparison with those of its competitors (as of June 2014: http://en.wikipedia.org/wiki/Comparison_of_web_map_services) (e.g., [7] - [10] ). Google released the production version of its basically-rewritten V.3 JavaScript map application interface in mid-2010, after individuals had been able to code and display their own data since 2005 on the V.1 and V.2 applications via the internet. The V.3 application is free for non-commercial use, and without the need for a personal key, as documented at https://developers.google.com/maps/documentation/javascript/reference. Examples of V.3 computer code are available from http://developers.google.com/maps/documentation/javascript/examples/ and other developers such as http://geocodezip.com; and coding questions may be posted and answered at https://stackoverflow.com/search?q=google+maps+v.3.
2. The Question of Analytical Capability
Initial theoretical commentary on digital online mapping, especially with Google maps and Google Earth, was about proprietary products not only causing the demise of cartography as a human skill [11] , but also skewing map users’ perceptions of the world as one for business (e.g., [12] [13] ), while making them think this world included them [14] . Commentators however also acknowledged users’ potentials for subverting those products’ business purposes when they programmed applications for displaying their own data in so-called mashups (e.g., [15] [16] ). Recent academic applications of V.3 Google maps for the “public” include those for finding and sharing information about locations [17] , recording environmental conditions [18] , and displaying land parcels for mortgage loans [19] .
Google’s rewritten V.3 maps application answered much of the initial technical commentary about V.1 and V.2 maps, including their slow rendering on the computer screen, and awkward access to such features as geocoding [20] . From a technical point of view for my maps, upgrades from V.2 to V.3 include standardisation of map options via object literals; simpler access to features such as geocoding and street view panoramas; server- side processing of queries of data in online fusion tables; and speed of rendering on the screen after asynchronous loading of only required parts of the map application [20] . The third version itself however could not address continuing external issues of speed of display of tiles for zoomed maps (e.g., [4] ), and accuracy of geocoded locations (e.g., [21] ). Moreover, the third version itself may still not have transformed the mapping application from a method for visualization of geographic data into one for analysis as well.
Another author has coincidentally explored this question of whether new online digital mapping technologies, such as Google Earth, may be useful for more than display of already-analysed data [22] . He has however concluded that, “geobrowsers [such as Google Earth]… are very different from typical GIS applications. They have none of the analytic, modelling, and inferential power of GIS, and while oriented to visualisation are nevertheless very limited in what can be visualised, because of their insistence on content that is inherently visual” ([22] p. 40). He has concluded this even after acknowledging the “mashup… as a graphical rather than topological overlay… allows two- and three-dimensional structures to be superimposed on the Google Earth base using scripts written in the interface language KML” ([22] p. 35).
He subsequently has reiterated a similar conclusion, “of almost complete lack of the kinds of analytic capabilities [in Google Earth] that are abundant in a GIS” ([23] p. 92), in an advocacy for professional geographers as distinct from so-called neogeographers (e.g., [24] [25] ). He thus implied professional geographers could not or would not use geobrowsers if they wished “to develop new generalisations and theories, to test theories by comparing their predictions to observations, and to possess the sophisticated analytic tools needed to reveal insights that are not immediately apparent” ([23] p. 92). His conclusion, in short, is a more stringent criterion for analytical capability than in another earlier study with the conclusion that, “Google Maps mashups [V.1] model has put into public practice the notion that an accessible, agile, adaptable GIS can be built that accepts direct, local, even vernacular public input and, in turn, puts out usable, unique, localized and important results” ([16] p. 197).
The inference is therefore that analysis and modelling of data in V.3 Google maps should progress beyond users’ superimposing data in additional KML layers or fusion table layers on maps, and querying their data in those mashup layers. Users should ideally be able to analyse and model their data with their own functions during map program execution for dynamic display of results either on a map or in its legend. In practice, however, users who plan on analysing and modelling their data may encounter two technical constraints of the V.3 map application.
The first of these related constraints is users’ inaccessibility to raw data especially in fusion tables at the same time as those data are being mapped. The second is that their alternative utilization of asynchronous applications with call back functions to the server will produce leads and lags in program execution. These lags and leads may culminate in results being due for display before analyses are finished. In light of these technical constraints, the remainder of the present study answers why one of my V.3 Google map applications has analytical capability, whereas two do not have this capability.
3. Two Pin Map Examples
3.1. Points of Interest Pin Map
My first pin map is deliberately for display purposes, with graphical push pins for fixed points of interest from cached longitude and latitude coordinates, and/or variable locations including that of the client based upon automatically geocoded coordinates: e.g., screen shot in Figure 1, and online at http://web2.uwindsor.ca/courses/sociology/phipps/courses/np/indvillslides.html#IndVillmap. Note an opaque polygon connects three-or-more points of interest (as in Figure 1), whereas a double-headed-arrow straight line connects two points, and a single point only has a push pin.
The primary viewport of this first pin map, similarly to my other maps, is operationally created in a (640px by 480px) container inside its own inline frame within a longer JavaScript-programmed webpage document. A newly-created map reloads this frame with cleared memory. A map is recentred and redrawn for its particular data. None of these maps utilize third party extensions of Google map applications, and so, these are not reviewed.
In addition to the pin map’s primary viewport zoomed in around the points of interest, a secondary smaller
Figure 1. Fixed points of interest on small-area pin map.
map displays the zoomed-out region of those points centred on the same location. This secondary map’s viewport also moves in unison with the primary map when the client drags a push pin; and vice versa when he or she drags the smaller map’s icon. A dragged-and-dropped point of interest in a new location automatically produces a new information window after geocoding its street address (Figure 2). A hovered mouse over any point of interest opens an information window with the street address, longitude and latitude coordinates, and static northward street view panorama.
The display of each static street view panorama image illustrates a recurring limitation of independent calls to the Google server (documented at https://developers.google.com/maps/documentation/streetview/index). The asynchronous loading of the street view image occurs after map loading is complete, and the returned image may have a momentary delay in its display in an information window. Similar asynchronous geocoding of points (documented at https://developers.google.com/maps/documentation/geocoding/) requires a call back function with results from the server, and so, a point’s returned coordinates may lag behind execution of computer code until a map is fully loaded. Geocoding of single points after a map has fully loaded can be triggered by a listened-for event such as a mouse click or mouse hover. Note the use in this map of Google’s geocoder for a moved point’s coordinates, and the HTML 5 Geolocation geocoding application for those of a client’s own location (documented at http://www.w3schools.com/html/html5_geolocation.asp). The client’s location is superimposed if he or she enables this, although this will probably cause the map to overly pan and zoom in order to display updated boundaries including that point (Figure 3). The V.3 map’s display of this location plus its static street view panorama represents a visible upgrading from V.2.
3.2. Classified Quantities or Qualities Pin Map
My second pin map uses coloured pins to display classified quantities or qualities of observations at pre-geo- coded street addresses: e.g., screen shot in Figure 4, and online at
http://web2.uwindsor.ca/courses/sociology/phipps/courses/bqmss/uhq2013maps.html#Uhqmap. One set of optional pin maps in Figure 4 are of the classified overall exterior quality percentages of approximately 800
Figure 2. Dragged and dropped point of interest on pin map.
Figure 3. Displayed client’s location included on pin map.
Figure 4. Introductory options for pin maps of overall exterior housing qualities.
houses in a neighbourhood. Another set of options are of the same houses’ three to five nominal conditions of selected attributes. A V.3 upgrade (explained below) is in the map legend where numbers of houses with classified overall exterior qualities, or attribute conditions, are totalled during program execution, as opposed to being pre-analysed and cached in V.2 (e.g., [26] ). In other words, this second V.3 pin map has potential analytical capability that so far is demonstrated by the legend’s calculations.
Operationally, pre-geocoded houses’ data are loaded with either a synchronous or an asynchronous XMLHttpRequest object from external XML datafiles on the home server. Almost instantaneous display of pins for up to 800 houses represents a significant upgrade over V.2, in which pins might have appeared sequentially on the screen in one browser, or in their classes in another. Also new is clicking on a pin to open a descriptive information window that displays the same type of static street view panorama as in my first pin map example (Figure 5). Clicking on this image in an information window opens an appropriately-rotated dynamic street view panorama of the house (Figure 6). This map may be recognized as simulating a proprietary Google map, though without all the links to nearby businesses etc. Instead, my map has a right panel enabling visualization of observations by location or time.
As already mentioned, the dynamically-written map legend in Figure 5 and Figure 6 displays the numbers of houses with classified “below normal”, “normal”, and “above normal” overall exterior qualities after totalling them during program execution. Each house’s overall exterior quality is classified during program execution in terms of its percentage on the original calculated interval scale from (−100)% for poorest overall exterior quality, through zero for normal quality, to 100% for best quality.
This and other potential analyses of houses’ data during map loading are enabled by the use of a synchronous version of the aforementioned XMLHttpRequest object (documented at
http://www.w3schools.com/xml/xml_http.asp). Note however this synchronous request is not recommended as it
Figure 5. Information window including static street view panorama image.
Figure 6. Dynamic street view panorama from information window.
might “freeze the entire browser” ([27] p. 500); and it has been deprecated as of June 2014 (documented at http://xhr.spec.whatwg.org/). The recommended alternative is an asynchronous request for the houses’ datafile. This however does not receive its callback from the server in time for dynamically writing the legend during map loading, and so, pre-analysed subtotals of houses are cached for writing the legend.
A corresponding map legend for each house attribute, such as shingles condition, displays subtotals of houses with five or three nominal conditions, regardless of whether these are dynamically calculated or pre-analysed and cached. Five is coincidentally one more than the currently permitted maximum number of display “styles” in a fusion table application, where this is explained in the next section. This second pin map has thus continued the same as V.2 to load data from external XML datafiles, and to classify houses’ data with its own functions, instead of upgrading to the fusion table application.
4. Choropleth Map Example
My final map is a choropleth map of data for Metropolitan Windsor’s dissemination areas (DAs) from the 2006 and 2011 Canadian censuses: e.g., screen shot in Figure 7, and online at http://web2.uwindsor.ca/courses/sociology/phipps/courses/is/windea11maps.html#Windsormap. This map repre- sents a significant upgrade over my V.2 map as a display of similar data—though less so as an analysis of those data.
First, the V.3 basemap is Statistics Canada’s shape file of Metropolitan Windsor’s DA digital boundaries that has been uploaded to an online fusion table via the Shape Escape application (documented at
http://www.shpescape.com/). In contrast, my V.2 map only included the smoothed boundaries of 42 DAs for Windsor’s older-urban neighbourhoods. Metropolitan Windsor has approximately 650 DAs in the 2011 census,
Figure 7. Introductory options for choropleth map of DA census data.
with all except 13 having the same boundaries as in 2006 after a few larger DAs were subdivided. Dissemination areas are the smallest geographical areas for which Statistics Canada distributes summary data from the quinquennial Canadian census (described at http://en.wikipedia.org/wiki/Census_geographic_units_of_Canada#Dissemination_areas).
Second, the V.3 map has options for mapping five variables’ classified counts, percentages, or dollar amounts in either 2006 or 2011 census year for all active DAs (Figure 8). These variables’ Census data or Household Survey data from Statistics Canada are also read from the same online fusion table as the DA boundaries. The result is an almost-instantaneous choropleth map of a selected variable’s data for Metropolitan Windsor’s DAs. Clicking on a DA opens an information window containing the DA’s identifier and its datum for the selected variable. Computer animation of time series of these DA maps is now planned owing to the speed of the fusion table application.
Server-side processing of DAs’ data loaded into a fusion table is behind the speed of rendering each choropleth map on the screen. Each DA’s count for a variable, its percentage, or its dollar amount is classified and styled in accordance with coded parameters in the fusion table application (documented at https://developers.google.com/fusiontables/). On the one hand, the fusion table application produces a much faster map than would be achieved with data loaded from external files on the home server. On the other hand, however, the legend of the map from the fusion table application requires DAs’ summary counts to be analysed and cached prior to program execution.
An aforementioned limitation of the fusion table application is only having five display styles for classifying DAs’ data including a default style. Another more serious limitation is not having access to DAs’ raw data or their classified data for any other purpose than mapping with the fusion table application while the map is loading. Other developers (such as at http://www.geocodezip.com and at
http://explorables.cmucreatelab.org/explorables/world-top-incomes-database/) have circumvented this second
Figure 8. Choropleth map of selected variable’s DA census data.
limitation by executing asynchronous queries of fusion table data with Google’s Visualization application or Fusion Table application, respectively (documented at https://developers.google.com/maps/documentation/javascript/visualization, and
https://developers.google.com/fusiontables/). However, similarly to aforementioned asynchronous calls to the server, these queries lag behind program execution, and so, results cannot be displayed until after loading a map. Furthermore, the Visualization application only queries the first 500 rows of a fusion table, and so, it would not analyse approximately 150 DAs’ data for a selected variable.
5. Conclusions
Three examples of V.3 Google pin maps and polygon (choropleth) maps have been described and reviewed especially in terms of whether they are just for display of data, or analysis as well. Even though each pin map and polygon map permitted users’ querying observations displayed on map layers after these had loaded, the analysis and modelling of data should progress beyond these queries even if beginning with them. In particular, analysis and modelling were assumed to require users’ having functional access to their raw data during map loading for display of results on the map or in the legend.
The first pin map is a deliberate example for display purposes, whereas the second pin map with coloured pins for quantities or qualities of observations’ classified data has demonstrated potential for analysing and modelling those data on the map and/or in the legend. However, this second pin map’s potential analytical capability is precariously based upon the programming of an unrecommended and deprecated synchronous request for observations’ data from the home server, even though it works well in this application. In comparison, the third map as an example of a choropleth map analyses observations’ data in a fusion table via coded parameters during map loading. This map illustrates the power of V.3 Google maps for producing a map of hundreds of classified observations. It however also illustrates the limitation of asynchronous instantiation of the map application. This third map currently does not have comparable analytical and modelling capability of a typical GIS, even though it may have the processing speed of one.