Three Applications of V.3 Google Maps: Just for Display of Data, or Analysis as Well?

A question about the analytical capability of Google maps is answered for three examples of pin maps, and polyline and polygon maps that are computer-programmed with the third version of the Google maps application. One map reads XML data stored on the home server, whereas another downloads its data from an online fusion table, and the third includes pre-programmed data. Each map permits users to query mashup layers after the map has loaded. However, an analytical capability comparable to GIS should require users to have access to their data for analysis with their own functions while the map is loading. The technical constraint of asynchronous loading of data for Google maps is illustrated for each map. In conclusion, only one map has an analytical capability that is achieved by means of deprecated synchronous loading of data.


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.

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; serverside 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 dur-ing 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.

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 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.

Classified Quantities or Qualities Pin Map
My second pin map uses coloured pins to display classified quantities or qualities of observations at pre-geocoded 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   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  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.

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 represents 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.  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.comand at http://explorables.cmucreatelab.org/explorables/world-top-incomes-database/) have circumvented this second 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.ing 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.

Figure 1 .
Figure 1.Fixed points of interest on small-area pin map.

Figure 2 .
Figure 2. Dragged and dropped point of interest on pin map.

Figure 3 .
Figure 3. Displayed client's location included on pin map.

Figure 4 .
Figure 4. Introductory options for pin maps of overall exterior housing qualities.

Figure 5 .
Figure 5. Information window including static street view panorama image.

Figure 6 .
Figure 6.Dynamic street view panorama from information window.

Figure 7 .
Figure 7. Introductory options for choropleth map of DA census data.

Figure 8 .
Figure 8. Choropleth map of selected variable's DA census data.
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,