CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
BUILDING A MOBILE WEB MAP FOR CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
A thesis submitted in partial fulfillment of the requirements For the degree of Master of Arts in Geography
By
Jorge Chen
May 2012
The thesis of Jorge Chen is approved:
_________________________________ Soheil Boroushaki, Ph.D.
____________ Date
_________________________________ James W. Craine, Ph.D.
____________ Date
_________________________________ Regan M. Maas, Ph.D., Chair
____________ Date
California State University, Northridge ii
Table of Contents Signature Page .................................................................................................................... ii List of Tables ..................................................................................................................... vi List of Figures ................................................................................................................... vii Abstract ................................................................................................................................x 1
2
Introduction ................................................................................................................. 1 1.1
Building the Mobile Web Map ........................................................................... 1
1.2
Maps and the College Landscape ....................................................................... 1
1.3
CSUN’s Current Online Maps ........................................................................... 3
Thesis Description .................................................................................................... 12 2.1
2.2
3
Thesis Overview ............................................................................................... 12 2.1.1
Purpose and Scope .............................................................................. 12
2.1.2
University Web Mapping Initiative .................................................... 12
2.1.3
Web Map and Mobile Web Map Benefits .......................................... 13
Foundational Concepts ..................................................................................... 15 2.2.1
Theoretical Concepts .......................................................................... 15
2.2.2
Technical Bases .................................................................................. 16
Development Process ................................................................................................ 19 3.1
3.2
Overview .......................................................................................................... 19 3.1.1
Work Breakdown Structure(WBS) ..................................................... 19
3.1.2
Program Evaluation and Review Technique (PERT) ......................... 21
Set Up Map Server ........................................................................................... 22 3.2.1
Background ......................................................................................... 22
3.2.2
Server Machine, Security, and Network Connection.......................... 22
iii
3.2.3 3.3
Web, GIS, and Database Servers ........................................................ 23
Create Geodatabase .......................................................................................... 24 3.3.1
Background ......................................................................................... 24
3.3.2
Data Model.......................................................................................... 25
3.3.3
Customization ..................................................................................... 25
3.4
Select Spatial Reference ................................................................................... 25
3.5
Survey Control Points ...................................................................................... 26 3.5.1
Surveying Options .............................................................................. 26
3.5.2
GNSS Background .............................................................................. 28
3.5.3
GNSS Equipment Selection ................................................................ 29
3.5.4
GPS Data Collection ........................................................................... 30
3.6
Import University Data ..................................................................................... 31
3.7
Create Spatial Features ..................................................................................... 34 3.7.1
Overview ............................................................................................. 34
3.7.2
Point and Line Feature Classes ........................................................... 34
3.7.3
Polygon Feature Classes ..................................................................... 35
3.8
Create Maps for Publication ............................................................................. 44
3.9
Create Map Service Definitions ....................................................................... 46
3.10 Publish Maps to the Map Server ...................................................................... 46 3.10.1 Service Name and Folder for Publication ........................................... 47 3.10.2 Map Capabilities ................................................................................. 47 3.10.3 Cache Settings ..................................................................................... 49 3.11 Create and Publish Campus Tour Content ....................................................... 51
iv
3.12 Create Web Service Access .............................................................................. 53 3.12.1 Representational State Transfer (REST) Overview ............................ 53 3.12.2 Map Service Access ............................................................................ 54 3.12.3 Social Media Access ........................................................................... 57 3.12.4 Campus Tour Map and Media Access ................................................ 57 3.13 Create User Interface ........................................................................................ 58 3.13.1 Overview ............................................................................................. 58 3.13.2 User Interface Design ......................................................................... 60 3.14 Launch the Map ................................................................................................ 67 4
Final Product ............................................................................................................. 68
5
In Context of the University Learning Environment ................................................ 73
6
Concluding Discussion ............................................................................................. 76
References ......................................................................................................................... 78 Appendix A: Web Map Hardware, Software, and Protocols ............................................ 82
v
List of Tables Table 1. University Data Sources. .................................................................................... 32 Table 2. Modifications Made to the Campus Basemap Template. ................................... 45 Table 3. Summary of Map Layers. ................................................................................... 56
vi
List of Figures Figure 1. View of the CSUN Campus Map Website (Existing). ........................................ 5 Figure 2. Static Maps for North and South Campus in GIF Format (Existing). ................. 5 Figure 3. Static Vicinity Map in GIF Format with Google Maps Links (Existing). .......... 6 Figure 4. Static Campus Map in PDF Format (Existing). .................................................. 7 Figure 5. IPad 2 View of Existing GIF Map. Clear text and graphics (see inset). ............. 8 Figure 6. IPad 2 View of Existing PDF Map. Clear text and graphics (see inset). ............ 8 Figure 7. Exhibit II 4G View of Existing GIF Map. Clear text and graphics in landscape view with slight pixelation in portrait view. However, text becomes illegible in both views due to the small size.................................................................................................. 9 Figure 8. Exhibit II 4G View of Existing PDF Map. Clear text and graphics in landscape view with moderate pixelation in portrait view. However, text becomes illegible in both views due to the small size.................................................................................................. 9 Figure 9. ZTE Avail View of Existing GIF Map. Clear text and graphics in landscape view and highly pixelated text in portrait view. However, text still becomes illegible in both views due to the small size. ...................................................................................... 10 Figure 10. ZTE Avail View of Existing PDF Map. Illegible text and pixelated graphics in both views. ........................................................................................................................ 10 Figure 11. Moderately difficult to navigate existing website via touch on the iPad 2. .... 11 Figure 12. Practically impossible to navigate existing website via touch on smartphones. ........................................................................................................................................... 11 Figure 13. Work Breakdown Structure for the CSUN Mobile Web Map. ....................... 20 Figure 14. PERT Diagram for the CSUN Mobile Web Map. ........................................... 21
vii
Figure 15. CSUN Web Map Server Setup. ....................................................................... 22 Figure 16. Results of ArcGIS Re-Projection Compared with Various Public Maps. Outlined polygons represent the transformed features. .................................................... 27 Figure 17. Comparison of Locational Accuracy of Public Aerial Imagery. ..................... 28 Figure 18. Trimble GeoXT. .............................................................................................. 29 Figure 19. Sample Aerial Photo Control Points and Data Collection............................... 30 Figure 20. Locations of Control Points and Measured Precision Levels. ......................... 33 Figure 21. Manual Selection of Sidewalk Boundaries (in Green) in Progress. ................ 36 Figure 22. Process for Creating Street and Landscape Features. ...................................... 37 Figure 23. Manual Identification of Street (in Purple) and Landscape (in Green) Features in Progress. ........................................................................................................................ 38 Figure 24. Process for Creating Building Features (1 of 2). ............................................. 39 Figure 25. Process for Creating Building Features (2 of 2) .............................................. 40 Figure 26. Process for Creating Sidewalks. ...................................................................... 41 Figure 27. Process for Creating Curbs. ............................................................................. 42 Figure 28. Process for Creating Gutters. ........................................................................... 43 Figure 29. Campus Map Database Connection Details. ................................................... 45 Figure 30. MSD Settings................................................................................................... 46 Figure 31. Publishing an MSD in ArcCatalog. ................................................................. 47 Figure 32. Specifying a Service Name and Folder. .......................................................... 48 Figure 33. Specifying Map Capabilities. .......................................................................... 48 Figure 34. Initial Map Cache Settings Window................................................................ 50 Figure 35. Selection of Online Tiling Scheme from “Load tiling scheme from” Button. 50
viii
Figure 36. Unmodified Map Cache Settings After Loading Online Tiling Scheme. ....... 51 Figure 37. Map for CSUN’s Official Self-Guided Tour. .................................................. 52 Figure 38. Minimum Code for Adding a Map Service. .................................................... 55 Figure 39. Adding a Layer to an Existing Map. ............................................................... 55 Figure 40. Adding a Layer to an Existing Map with Additional Parameters. .................. 55 Figure 41. Logo Design for the CSUN Mobile Web Map. ............................................... 62 Figure 42. User Interface Layout. ..................................................................................... 63 Figure 43. Concepts for Map Viewer and Basic Search/Navigation Pages. ..................... 64 Figure 44. Concepts for Options and About Pages. .......................................................... 65 Figure 45. Concepts for Tour and Media Viewers. .......................................................... 66 Figure 46. Web Map System ............................................................................................ 68 Figure 47. Views of All Eight Map Zoom Levels. ........................................................... 69 Figure 48. Main Mobile Web Map Pages. ........................................................................ 70 Figure 49. Campus Tour Map and Media Viewers........................................................... 71 Figure 50. Comparison of Existing Static Map and Mobile Web Map. ........................... 72
ix
ABSTRACT
BUILDING A MOBILE WEB MAP FOR CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
By Jorge Chen Master of Arts in Geography, Geographic Information Science
Maps form an integral part of any college campus whether in the form of map kiosks, maps in brochures and tour guides, maps on the college website, or even the mental maps in students’ minds as they navigate their way around campus. However, static campus maps become outdated as soon as they are published and mental maps require prior experience and can sometimes provide misleading information. Modern mobile web maps which have the abilities to provide real-time map updates, to locate users using satellite technology, and to incorporate social media services provide a compelling solution for overcoming these mapping challenges. This thesis involved the development of a comprehensive mobile web mapping system for California State University, Northridge and examined issues related to mobile map design, social media mashups, and the integration of web mapping into the overall context of the University environment. The project portion of this thesis delivered a comprehensive and fully functioning web mapping system complete with all necessary
x
components and a user interface for mobile devices. The written portion of this thesis documented the map concept and development framework, discussed concepts related to web mapping, and served as formal documentation for the web map itself. This thesis demonstrated the effectiveness and technical feasibility of implementing a mobile web map for CSUN and provided a foundational map for future web map development.
xi
1 1.1
INTRODUCTION
Building the Mobile Web Map In only two decades since the birth of the first modern web browser (Berners-Lee
2012) and nearly seven years after the launch of Google Maps (Google 2012), growing numbers of college campuses throughout the world have transformed their old static internet maps into dynamic interactive web maps. California State University, Northridge (CSUN) has also aspired to move beyond the age of static maps by creating a campus web map of its own. This thesis and its associated project served as one proposed prototype for such a web map. This thesis also took the web map concept one step further by building capabilities for mobile computing devices such as tablets and smartphones which have recently experienced widespread adoption among the general public and bring to realization the idea of universal computing. 1.2
Maps and the College Landscape Maps tell stories. Beyond their most primitive function as navigation devices,
maps re-present or repackage selected elements of the real world by transforming them into symbolic narratives that users can read, view, and experience (Turchi 2004). On a college campus, maps help establish the notion of a college as a distinct place by imbuing meaning to physical clusters of buildings, parking lots, fields, streets, and sidewalks and transforming them into distinct places that have meaning to an individual, similar to Tuan’s concept of space and place (Tuan 1996). This intimate relationship between college landscapes, maps, and sense of place can extend into any type of graphic media including those ubiquitous map kiosks and billboards found on college campuses throughout the world, paper maps in brochures and welcome packages, and static
1
electronic maps that can be downloaded from websites and printed on paper. Modern web maps bring this space-place relationship closer together through media mashups--which combine media content from various sources into one screen--as well as interactive capabilities. However, until recent times, these web maps could only operate on stationary desktop computers or bulky laptop computers, neither of which could in any practical way overcome the barrier between the virtual or cyber space (on the screen) and physical space (out in the “real world”). Recent advances in mobile computing devices—with their high resolution screens, powerful processors, geolocation capabilities, and persistent internet connections—have overcome this last great barrier and has opened up exciting new possibilities for mapping. Unlike desktop or laptop computers, mobile devices allow map users to take engaging interactive web maps with them anywhere they go and have in effect brought to fruition the idea of ubiquitous computing (Weiser 1991, Weiser 1998). A map user transiting through the physical space of a campus can now simultaneously view its graphical representation in cyberspace, with all the accompanying narrative information that can help transform physical space into a perceived place. When applied to campus maps, ubiquitous computing can simultaneously integrate the map user, the surrounding physical space, and spatial and non-spatial information delivered through the internet to shape a person’s sense of place. For example, a student sitting on the porch outside the CSUN Matador Bookstore (physical space) can pull up a mobile campus web map on an iPad tablet showing the student’s current location, descriptions of buildings in the surrounding area, video clips describing the 1994 Northridge Earthquake’s devastation at the Earthquake Garden site, a spatial
2
calendar of events for surrounding social events, and a map showing the ripeness status of oranges in the orange grove. All this can work together to integrate what that person sees in the surrounding physical world with their newly imbued meanings to form a sense of place. That pile of concrete and rebar in the corner transforms from rubble into a meaningful memorial to the devastating 1994 Northridge Earthquake, and the ripening oranges in the Orange Grove—out-of-sight and forgotten about for many months—turns the unassuming grove of trees into a meaningful social venue for the annual Food Forward Orange Grove Pick for local food banks. 1.3
CSUN’s Current Online Maps During the writing of this thesis, the CSUN website only contained static internet
maps and lacked any type of interactive web map as shown in Figures 1 to 4. The University’s online map offering consisted of two static map images in graphic interchange format (GIF), a static vicinity map in GIF format with text hyperlinks to Google Maps for driving directions, and a downloadable and printable map in the portable document format (PDF) file format. The CSUN maps website (http://www.csun.edu/maps) also contained a hyperlink to parking information (but no map), a broken hyperlink to a non-existent events map, and a hyperlink to the visitor information site which provided further links to a PDF campus tour guide. On a technical note, the University also lacked a complete set of spatial features that could be used in a web map and existing spatial features used a spatial reference (GCS NAD27) which was incompatible with public mapping programs such as Google Maps and Bing Maps. The suitability of these maps for use on mobile devices varied from functional to unusable depending on the screen resolution of the mobile device. Figures 5 to 12
3
provide examples of the campus map on three different mobile devices using three different operating systems (OS). These devices consisted of the Apple iPad 2 (tablet) with iOS 5.1, the Samsung Exhibit II 4G (smartphone) with Android 2.3.5, and the ZTE Avail (smartphone) with Android 2.3.5. The iPad 2 had 9.7 inch displays with a pixel density of 132 pixels per inch (PPI), the Samsung Exhibit II 4G had a 3.7 inch display with a pixel density of 252 PPI, and the ZTE Avail had a 3.5 inch display with a pixel density of 165 PPI. For comparison purposes, a standard 24 inch high definition (HD) desktop computer display with a 16:9 aspect ration (1080p) has a pixel density of about 92 PPI. While the higher pixel densities of mobile devices may initially seem impressive compared to a computer display, their small screen sizes significantly reduce the field-ofview and limit the amount of information that can be legibly displayed. The static maps on the CSUN website showed up reasonably well on the tablet displays with their larger screens, but their legibility and usability quickly diminished on the smartphones. Since hyperlinks on these maps were designed for high-precision mouse pointers, navigating the map website became extremely difficult on tablet and impossible on the smartphones. While all three tested devices had “pinch-to-zoom” capabilities to mitigate problems with the small displays, the pinching, panning, and selecting hyperlinks became cumbersome over many pages which ultimately degraded the user experience. Additionally, these maps lacked interactive capabilities such as adding thematic layers, geolocation, routing, or search functions.
4
Figure 1. View of the CSUN Campus Map Website (Existing).
Figure 2. Static Maps for North and South Campus in GIF Format (Existing).
5
Figure 3. Static Vicinity Map in GIF Format with Google Maps Links (Existing).
6
Figure 4. Static Campus Map in PDF Format (Existing).
7
Figure 5. IPad 2 View of Existing GIF Map. Clear text and graphics (see inset).
Figure 6. IPad 2 View of Existing PDF Map. Clear text and graphics (see inset).
8
Figure 7. Exhibit II 4G View of Existing GIF Map. Clear text and graphics in landscape view with slight pixilation in portrait view. However, text becomes illegible in both views due to the small size.
Figure 8. Exhibit II 4G View of Existing PDF Map. Clear text and graphics in landscape view with moderate pixilation in portrait view. However, text becomes illegible in both views due to the small size.
9
Figure 9. ZTE Avail View of Existing GIF Map. Clear text and graphics in landscape view and highly pixelated text in portrait view. However, text still becomes illegible in both views due to the small size.
Figure 10. ZTE Avail View of Existing PDF Map. Illegible text and pixelated graphics in both views.
10
Figure 11. Moderately difficult to navigate existing website via touch on the iPad 2.
Figure 12. Practically impossible to navigate existing website via touch on smartphones.
11
2 2.1 2.1.1
THESIS DESCRIPTION
Thesis Overview Purpose and Scope This thesis created a complete web mapping system with mobile capabilities for
CSUN and examined issues related to mobile map design, social media mashups, and the integration of web mapping into the overall context of the University environment. Since the University lacked any type of web map, one major component of this project involved the development of a foundational web mapping system which could be used as the baseline for web map applications (such as the mobile map included in this project) and future extensions to the web map dataset (such as the integration of floor plans, utilities, and parking information). The deliverables for this thesis included a complete web mapping system with all associated documentation including web map architecture and this written thesis. 2.1.2
University Web Mapping Initiative The mobile web map was developed on behalf of the Department of Geography
and served as a proof-of-concept web map prototype for the University. The Department of Geography provided web servers and all required GIS software for this project, and the CSUN Office of Graduate Studies provided funding for the purchase of an Apple iPad 2 tablet and a ZTE Avail smartphone for field tests. Both the tablet and phone were deemed property of the University and were returned to the Department of Geography upon completion of the project.
12
2.1.3
Web Map and Mobile Web Map Benefits Web mapping and mobile web mapping can offer many benefits to a college
campus. At the most practical level, a mobile web map can serve as a convenient navigation tool for map users (students, faculty, visitors, etc.) to find their way around campus. A mobile web map can also provide a variety of other services ranging from social media aggregation to serving as part of an emergency management system (Paolino et al. 2010). As the first implementation of a mobile web map for CSUN, this project provided basic mapping services tailored to mobile devices, geolocation services to allow users to find their location on campus, and building and department search services enabling the searching of building or department locations. More importantly, this project provided foundational groundwork for future development of the campus web map. A publicly accessible web map can also serve as a useful tool for research projects on campus. A web map can provide faculty and student researchers who are working on campus-related geographical studies with free access to high quality spatial campus data. For example, the web map would have served as an ideal data source for a recent CSUN graduate student project to develop a GPS enabled navigation system for the blind (Chandler 2011). The organic nature of the campus web map could also open up opportunities for cross-disciplinary work and interdepartmental collaboration. In the GPS project for the blind, the graduate students created substantial amounts of geospatial data which could have been combined with the campus web map to be made available for other researchers to use in the future.
13
As instruments of narration, maps can also serve as powerful tools for shaping people’s perceptions of CSUN and helping to instill a greater sense of community among various groups of people associated with the University. This shaping of perception can take place at many levels. Within the CSUN community, a well-designed interactive web map can help foster a greater sense of community among the students, faculty, and staff on campus, especially with the school’s reputation as a commuter campus. Geographically linked historical information can help provide CSUN members with a sense of historical context connecting the present with the past, social media can increase awareness of the unspoken thoughts and ideas of other members of the community, and spatial event calendars can facilitate student participation in events that encourage human-to-human interaction, all of which can work together to foster a greater sense of connectedness among the CSUN community. As the largest public education institution in the San Fernando Valley, CSUN also serves as a center-of-gravity for community events such as for the performing arts at the school’s Valley Performing Arts Center (VPAC). A web map can make it much easier for members of the SFV community to participate in these events by consolidating campus event schedules into one location and helping them find venue locations on a map. At the broadest level, a web map can enhance the campus’s image in the eyes of the general public. In the age of the internet, a school’s cyberspace presence can build lasting first impressions, especially among those who have never visited the campus. This would play a particularly important role for non-local student applicants and job seekers. A well-designed web map can highlight positive aspects of the campus while student
14
involvement in the map’s design can send a message that the campus is dedicated to innovation and fostering a collegial student-faculty environment. 2.2
Foundational Concepts The mobile web map was built on several important foundational concepts which
have been grouped under the headings of theoretical concepts and technical bases for the purposes of this discussion. Theoretical concepts can be seen as overarching principles that guided overall development while technical bases can be seen as actual technologies for implementing the theoretical concepts. 2.2.1
Theoretical Concepts Mobile mapping, spatial mashups, and volunteered geographic information (VGI)
formed the three core theoretical concepts behind this mobile web map project. Mobile mapping describes a relatively recent phenomenon in which mobile devices such as tablets and smartphones are used as mapping platforms which provide the advantages of portability and geolocation capabilities (i.e. the ability for a device to find its location anywhere in the world using GNSS satellites). However, development of mobile applications requires a different approach compared to desktop applications due to their smaller screen sizes (Kyrnin 2012), since user perceptions of maps with a wide field-ofview on a big screen do not always directly translate to smaller screens. These mobile web maps must be designed to communicate essential information through a small screen while also making it easy for users to interact with the map itself. Tsou described this process as providing a rich user experience (2011) while, from a cartographic perspective, research by Fabrikant, Hespanha, and Hegarty showed that visually salient design can influence map users’ viewing behavior and response times (2010).
15
The concept of mashups describes the combining of multiple internet data sources into one document, and one popular source of mashup data in recent years has been social media such as Facebook, Flickr, Twitter, and YouTube. Most of these social media services now include geolocation information which has made it possible to mash up geoenabled media posts. Placing social media posts in a spatial context and mashing them up with other social media opens up the possibility of finding patterns in social media that would not otherwise be readily apparent. It also makes it possible to apply social media in new and innovative ways that were not originally part of the social media design. Volunteered geographic information (VGI) formed the third underlying concept for development of the campus web map. Elwood, Goodchild, and Sui described VGI as ordinary citizens “using handheld devices to collect geographic information and contribute it to crowd-sourced data sets, using Web-based mapping interfaces to mark and annotate geographic features, or adding geographic location to photographs, text, and other media shared online” (2012). VGI falls under a larger phenomenon called user generated content (UGC) and crowdsourcing in which internet users—ordinary citizens—generate their own content on the internet to share with the rest of the world. Wikipedia serves as a prime example of a successful (non-spatial) UGC program. A highquality and robust campus web map can serve as an ideal platform for performing VGI research on campus as well as supporting a related process called participatory GIS (PGIS) in which the web map serves as an instrument of collaboration (Boroushaki 2010). 2.2.2
Technical Bases The technical bases of this project can be considered the enabling technologies
which made this mobile web map possible. These technologies included geographic
16
information systems, web communications technologies, and geolocation technologies. Bolstadt defined a geographic information system (GIS) as “a computer-based system to aid in the collection, maintenance, storage, analysis, output, and distribution of spatial data and information” (2008). For this project, the GIS consisted of the GIS web server, the GIS software, and the processes for creating, storing, and using the campus’s spatial data. The web communications component of the mobile web map used a client/server architecture comprised of a web server and client mobile devices which communicate with each other using standard internet protocols. These protocols include hypertext transfer protocol (HTTP), uniform resource locator (URL), hypertext markup language (HTML), and JavaScript Object Notation (JSON). (Fu and Sun 2011). When set up to allow interactive two-way communications, these technologies work together to form what has been called Web 2.0—a virtual collective intelligence network which allows anyone connected to the network to create and share information with others (O’Reilly 2005, O’Reilly and Battelle 2009). O’Reilly and Battelle provided the following description of Web 2.0: Chief among our insights was that "the network as platform" means far more than just offering old applications via the network ("software as a service"); it means building applications that literally get better the more people use them, harnessing network effects not only to acquire users, but also to learn from them and build on their contributions. (2009).
17
While the campus web map will start as a “software as service,” it will lay the groundwork for potential future developments of “network as platform” applications in mapping and mapping research. Finally, geolocation technologies used in this project used global navigation satellite system (GNSS) capabilities and, to a lesser extent, cell phone tower triangulation. GNSS uses signals from a constellation of navigation satellites in space to identify exact locations on earth in real time. Most navigation devices currently on the market use the United States Government’s Global Positioning System (GPS) satellite system (GPS.Gov 2012) although some devices are starting to incorporate other newly deployed GNSS systems developed by other countries. An alternative method of location tracking is through triangulation by estimating the distance of cellphones to the nearest cell phone towers. Mobile devices often fall back to cell tower triangulation when GNSS receivers fail to acquire a location from satellite signals; however, cell tower triangulation generally provide relatively inaccurate and inconsistent location information (Yang et al. 2010).
18
3 3.1
DEVELOPMENT PROCESS
Overview The development of this project followed a general project management
framework comprised of the five phases of initiation, planning, execution, monitoring and controlling, and closing as described in A Guide to the Project Management Body of Knowledge (PMBOK) (Project Management Institute 2008). Since the goal of this project was the rapid development of a prototype, it specifically emphasized initiation, planning, and execution while placing less emphasis on the last two phases of monitoring/controlling and closing. The initiation and planning stages involved developing the project concept and scope prior to executing any type of actual work. The project concept followed the project vision as described in earlier sections of this thesis: a campus web map for mobile devices with multimedia capabilities as demonstrated by a campus tour feature. This overall concept of a final product was disassembled into smaller sub-components using a work breakdown structure (WBS) which in turn formed the bases for identifying the actual processes required to build those sub-components. Organization of the processes for the execution phase used a technique called program evaluation review technique (PERT) diagramming or network diagramming. When these processes were implemented, they created the actual products embodied in the WBS, which when assembled together formed the final mobile web map. 3.1.1
Work Breakdown Structure(WBS) The PMBOK defined a work breakdown structure as a “deliverable-oriented
hierarchical decomposition of the work to be executed . . . to accomplish the project
19
objectives and create the required deliverables” (2008). In other words, the WBS consists of a tree-structured chart that progressively breaks down a project into smaller subcomponents from a single top element (representing a single project or system) to multiple bottom elements (representing smaller and smaller parts of the system). The WBS inherently captures deliverable products as opposed to processes (or actions) (Wikipedia 2012a). Once these sub-components have been identified, they can be used to identify and organize processes for construction of the project during the execution phase. Mobile Web Map
Web Map Server
Map Services
Mobile User Interface
Social Media Services
Web Server
Map Cache
Map Service Definitions (MSDs)
Social Media Content
Map Documents (MXD)
Campus Tour Social Media Services & Content
Campus Tour Map Service
Spatial Features
Aerial Photo
Map Cache, MSD, MXD, and Spatial Features
GIS Server
Database Server
Feature Points, Lines, and Polygons
Campus Tour Service
Figure 13. Work Breakdown Structure for the CSUN Mobile Web Map. Figure 13 shows the WBS for the CSUN Mobile Web Map project. Note that the WBS components (with their associated child elements) represent actual deliverables which can be developed independently of each other. For example, the mobile user interface (UI) can be developed as a generic UI template which can be used to plug in the map service, both of which can be developed independently of one another. These end-
20
state deliverables formed the basis for the sequencing and scheduling of tasks in the PERT based analysis. 3.1.2
Program Evaluation and Review Technique (PERT) The PERT diagram technique (also known as the network diagram technique) is
used to organize the sequence of events required to produce a deliverable product. Notably, the PERT diagram identifies processes and captures process dependencies (i.e. pre-requisite activities such as building the frame of a house before installing the roof) which can help organize and prioritize tasks. The path following the most important timesensitive dependencies becomes the critical path. Figure 14 shows the modified PERT diagram for this project. Since the project omitted scheduling and task duration information, the PERT diagram only captured processes and dependencies but not the critical path. The remainder of this chapter will provide in-depth coverage of each element of the PERT diagram shown in Figure 14 and constitutes the formal documentation for the mobile web map. Note that the numbers in Figure 14 correspond to their respective sections in this chapter. 3.11 Create/ Publish Campus Tour Content
Start
3.8 Create Maps for Publication (MXDs)
3.9 Create Map Service Definitions (MSDs) 3.10 Publish Maps to the Map Server
3.2 Set Up Map Server
3.3 Create Geodatabase
3.7 Create Spatial Features
3.4 Select Spatial Reference
3.5 Survey Control Points
3.6 Import University Data
Figure 14. PERT Diagram for the CSUN Mobile Web Map.
21
3.12 Create Web Service Access
Finish
3.13 Create User Interface
3.14 Launch Map
3.2 3.2.1
Set Up Map Server Background The map server served as the single most important component of this project.
Without a map server, map data cannot possibly be packaged and delivered over the network to the map user (Fu and Sun 2011). However, the term “map server” can be confusing and misleading because its vernacular form can refer to either a software-based server, an actual physical server machine, or both. For the purposes of this paper, the term map server will refer to the last definition of an entire mapping server comprised of all server software residing on a single physical machine. Therefore, the CSUN web map server consisted of a database server (software), GIS server (software), web server (software), and server machine (hardware) as graphically represented in Figure 15.
Figure 15. CSUN Web Map Server Setup. 3.2.2
Server Machine, Security, and Network Connection The Department of Geography provided the map server for this project which was
set up and administered by the department’s Information Technology Manager. The server machine used an Intel Xeon E5640 quad-core processor with 6 gigabytes of random access memory (RAM) and ran the Windows Server 2008 R2 Enterprise operating system. This server connected to the internet through the University’s local 22
area network and used the University’s Windows authentication system for system security and access rights. 3.2.3
Web, GIS, and Database Servers The map server ran Microsoft Internet Information Server (IIS) 7.5 as the web
server, Esri ArcGIS 10 Server Enterprise as the GIS server, and Microsoft SQL Server 2008 R2 Enterprise as the database server, all of which used Windows authentication for security and access rights. Esri ArcGIS Server provided the ability to publish maps (created using ArcMap) to the internet through the IIS web server. Since these maps only contained references to underlying GIS data, the GIS data themselves could exist in different locations from the map document and in any format recognized by ArcGIS software, such as shapefiles (.shp), personal geodatabases (.mdb), local geodatabases (.gdb), and enterprise databases. The web map used an enterprise database (Microsoft SQL Server 2008 R2 Enterprise Edition) to store the geospatial data due to SQL Server’s high-performance, high-reliability, and the ability to allow multiple users to simultaneously edit data. The ArcGIS Server connected to the SQL Server database through an interface program called ArcSDE (Spatial Data Engine), which physically created the spatial database in SQL Server and managed data communication between both programs. The department’s IT Manager used Esri’s “ArcSDE for Microsoft SQL Server Post Installation” program to create an empty geodatabase for the campus map which was later populated with actual campus feature data. This post-installation program performed all the necessary background processes required to properly set up a spatial database in SQL Server and, more importantly, authorized the use of the new geodatabase with Esri.
23
3.3 3.3.1
Create Geodatabase Background The geodatabase forms the foundation of any geographic information system. A
well-designed geodatabase will ensure that a GIS can properly capture spatial features and provide the mapping capabilities required for users’ mapping needs. Three goals associated with the design of the geodatabase for the CSUN web map included standardization, expandability, and robustness. Standardization facilitates the sharing of data with other database systems by establishing common semantics and ontologies which make it easier for these different database systems to communicate with each other. For example, the use of standardized fields for a buildings feature class can allow other organizations throughout the University to seamlessly link this data for their own purposes, such as to create map-enabled student schedules. Standardization also makes it easier, faster, and less expensive to expand geodatabase capabilities by leveraging economies of scale in geodatabase design. Instead of multiple agencies developing their own custom geodatabase designs, standardization enables agencies to pool their resources and collaborate in making a single common design they can all share. This common design would then allow these agencies to share upgrades and feature improvements with one another at relatively less cost compared to independent development. Finally, collaboratively developed databases can have the benefit of a more robust design because of increased scrutiny from multiple developers—popularly referred to as Linus’s Law in software development (Raymond 2001). Esri conveniently provides a forum for the collaborative development of geodatabases through the ArcGIS Data Models program.
24
3.3.2
Data Model The CSUN Web Map used an ArcGIS Data Model called the “Local Government”
data model (Esri 2012f) for the geodatabase design, with minor modifications which are documented in the next section. The Local Government model provided the framework for capturing and storing data on facilities and infrastructure features commonly found in municipalities—such as buildings, streets, landscaping, and light fixtures—and served as an ideal model for mapping a large university campus. Another major benefit of using this standard model is the availability of a growing list of map templates on ArcGIS.com which can be used off-the-shelf (with minor changes) to display CSUN’s campus map data. A copy of the extensive data dictionary for the unaltered Local Government data model has been attached to this thesis. 3.3.3
Customization The Local Government model provided fairly comprehensive coverage of all
features required for the web map. As a result, only four modifications were made: - Building (Feature Class): Added CONSTRUCTDATE (Alias: Date Constructed) and RENOVDATE (Alias: Date Last Renovated). - Trails (Feature Class): Added “ADA Compliant” attribute to denote the compliance of a sidewalk or trail with the Americans with Disabilities Act (ADA). - StreetFurnitureType (Domain): Added “recycle bin” and “map kiosk” values. 3.4
Select Spatial Reference The CSUN web map used a spatial reference of WGS84 Web Mercator (Auxiliary
Sphere) to make it compatible with Google Maps and Bing Maps, as well as other services such as OpenStreetMap, Twitter, and YouTube (Esri 2009b). However, attempts
25
to reproject existing University data from its native projection of NAD27 to WGS84 Web Mercator (Auxiliary Sphere)—using the various transformation methods in ArcGIS including NAD_1927_TO_WGS_1984_6 and NAD_1927_TO_WGS_1984_79_CONUS —produced unsatisfactory results. When compared to data from OSM, Google Maps, and Bing Maps, the transformed features showed unacceptable feature offsets of two to four meters at several locations (see Figure 16). Since Esri recommended spatial adjustment when re-projection fails (Esri 2012a), the author decided to forego re-projection due to the poor results and to manually adjust the data by using surveyed control points. 3.5 3.5.1
Survey Control Points Surveying Options Three options considered for determining the locations of control points included
the use of a professional land surveying crew, the use of a global navigation satellite system (GNSS) data collector, and the use of publicly available aerial imagery such as from Esri, Google, and Bing. This project lacked the financial resources and the time for performing a professional land survey which would have provided the most accurate and precise locations for the control points. Public aerial imagery provided a viable alternative; however, a lack of knowledge about these maps (i.e. their underlying control points, their accuracy, and rectification methods used) and inconsistent spatial locations made the exact locations of the control points questionable. Figure 17 shows three sample control point locations with slight inconsistencies, and review of a building feature near the Art and Design Center showed offsets of about one-half meter between zoom levels. As a result, this project used a GNSS data collector for collecting control point locations and aerial imagery for validating the results.
26
Figure 16. Results of ArcGIS Re-Projection Compared with Various Public Maps. Outlined polygons represent the transformed features.
27
Figure 17. Comparison of Locational Accuracy of Public Aerial Imagery. 3.5.2
GNSS Background GNSS uses signals from a constellation of navigation satellites orbiting in space
to determine exact locations on earth. The sole GNSS system that existed worldwide until recent times was the Global Positioning System (GPS) which is funded and operated by the United States Government. Due to its history and ubiquity, the term GPS has often been used to refer to the more generic GNSS capabilities of satellite-based geolocation and navigation.
28
3.5.3
GNSS Equipment Selection The United States Geological Survey (USGS) Global Positioning System
Committee categorizes GNSS data collection equipment into three different grades corresponding to their estimated levels of accuracy: commercial grade (also known as recreation grade; less than or equal to three meters horizontal accuracy), differential grade (sub-meter horizontal accuracy), and survey grade (sub-centimeter horizontal accuracy) (2012). Due to the unavailability of survey grade equipment, this project used the Geography Department’s differential grade GPS data collector which has the capability to provide sub-meter accuracy—sufficient for general web mapping applications. The data collector used for this project was an older model Trimble GeoExplorer 2003 Series GeoXT data collector (Figure 18), circa 2004, running Microsoft Pocket PC 2003 and relying solely on GPS satellite signals, which was the only GNSS existing at the time the unit was made. The actual data collection software consisted of Esri ArcPad used for displaying and recording shapefile data and Trimble GPSCorrect
Figure 18. Trimble GeoXT.
version 2.10 used for collecting real-time differential correction data. The GeoXT provided improved accuracy over recreation grade GPS collectors by using advanced algorithms for processing GPS satellite signals and by collecting real-time “H-Star” differential correction data (i.e. error data associated with known fixed GPS data collection stations located nearby) for improved post-processing accuracy.
29
3.5.4
GPS Data Collection The data collection strategy involved collecting data for nine known control
points which are physical “X” marks painted on road pavement (see Figure 19). Data collection also included points for various salient landmarks located throughout campus for quality assurance purposes. In order to facilitate finding the control points in the field,
Figure 19. Sample Aerial Photo Control Points and Data Collection. point locations using Google’s aerial photos. Additionally, estimated control point locations were created from Google’s aerial photos and stored in a shapefile. Both the
30
imagery and preliminary shapefile were then uploaded into the GeoXT, which was used as both a navigator and data collector. A second point shapefile was directly created in ArcPad to store the actual locations of the control points and landmark points. Both shapefiles and the aerial imagery used a geographic coordinate system of WGS84 since ArcPad did not recognize the projected coordinate system of WGS84 Web Mercator (Auxiliary Sphere). During actual data collection, the high-resolution imagery proved extremely helpful in locating control points in the field, especially at locations where the paint had faded on the pavement and at one location where a car had parked right on top of the control point. The field survey located and collected data for seven out of the original nine control points identified in the University’s AutoCAD file; the remaining two points could not be located in the field. This data was then post-processed using Trimble Pathfinder Office which corrected for known errors based on data the program downloaded for a base station located on CSUN. Figure 18 shows the locations for the nine original control points from the University’s AutoCAD file, the control points from field collection, and the accuracy estimates for the post-processed field data. 3.6
Import University Data Roughly ninety percent of the features in the web map were derived from data
provided by the University courtesy of Dr. Helen Cox, Department of Geography, and her research team at the CSUN Institute for Sustainability. The datasets used for the map consisted of a comprehensive site map in AutoCAD format created by the CSUN Physical Plant Management (PPM) office, a shapefile with various features derived from the AutoCAD file, a geodatabase feature class with limited building information (also
31
derived from the AutoCAD file), an aerial photo, and a non-spatial Microsoft Excel spreadsheet with building attribute data. Since all four spatial datasets used a GCS NAD27 projection and required manual re-projection to WGS84 Web Mercator (Auxiliary Sphere), each dataset was individually adjusted using the affine transformation method in the Spatial Adjustment tool in ArcMap (or georectification tool for the aerial photo) to match the seven collected control points. Table 1 summarizes the imported data
Building Shapes Building Points Building Names Streets Street Names Sidewalks Sidewalk Names Curbs Gutters Landscaping Pavement Markings Area Names Fences Streams Ponds
A/P A
Campus_Map.gdb / building_polyline
09033.dwg / polyline
Buildings2_020410.shp
sources and their contributions to the map.
P A/P A P
A/P A
A P A P P P D A D P P
A - Attribute Transfer; D - Direct Transfer; P - Processed Features Table 1. University Data Sources.
32
Figure 20. Locations of Control Points and Measured Precision Levels.
33
3.7 3.7.1
Create Spatial Features Overview Creating the spatial features for the web map involved processing the imported
University data to conform to the Local Government template; it also required creating new features in areas not covered by the University’s data. Table 1 provides a summary of University data sources selected for processing and the type of processing required. While point and line features easily transferred from the data source to the official web map geodatabase, polygon features required significantly more work. This project ended up re-creating all polygon features using the original AutoCAD file due to two problems in the original data sources. First, the polygon features in the AutoCAD file were largely unusable due to incomplete coverage of campus features; for instance, the polygon layer for sidewalks contained nearly no features. Second, the University’s data had multiple copies of the same spatial features stored in separate files, which made it difficult to validate data integrity and consolidate all that data into one location. A review of the data showed that the University’s original AutoCAD drawings offered the highest fidelity but transforming this data into spatial features would require a tedious process of manually generating polygons from line features, then transferring data attributes from the other spatial features to those new polygons. The source and processed data remained the property of the University and were not attached to this thesis; see the Department of Geography for access to this data. 3.7.2
Point and Line Feature Classes Table 1 shows point and line feature classes from the University’s data that were
directly transferred to the web map geodatabase.
34
3.7.3
Polygon Feature Classes A total of eight polygon feature classes were created from the University’s data
and consisted of buildings, sidewalks, gutters, curbs, streets, landscaping, streams, and ponds. All polygon features were derived from the re-projected AutoCAD polyline layer which was exported and saved as affine_all_polyline.dwg. Attribute data for these features came from the AutoCAD file, a buildings shapefile (buildings2_020410.shp), a buildings feature class (CampusImport.gdb / buildings_polygon / buildings), and a nonspatial spreadsheet (Facility_Report.xls). Note that CampusImport.gdb was originally named CampusMap.gdb; it was renamed in this project to prevent confusion with the final official web map geodatabase CampusMap stored in SQL Server. 1. Buildings. Figure 24 and Figure 25 provide flow charts showing the process used for creating the buildings features for the web map. All features were created from scratch using the original AutoCAD polyline layer following a two-phased process, which involved creating the polygon features from the AutoCAD polylines then using multiple data sources to assign attributes to those features. Building features were saved in the CampusMap / FacilitiesStreets / Building feature class. 2. Sidewalks, Curbs, and Gutters. Figure 26, Figure 27, and Figure 28 summarize the steps taken to create sidewalks, curbs, and gutters from the AutoCAD polyline source file. Sidewalk features exist as polygons under the “StreetPavements” feature class in the Local Government template. However, sidewalks in the AutoCAD file were discontinuous polylines with numerous breaks and missing sections. Creating sidewalk polygons from the AutoCAD data required a tedious process of manually selecting, removing, or adding lines in ArcMap that overlapped with sidewalk features using both
35
human judgment and aerial imagery as guides as shown in Figure 21. Once all sidewalk lines were identified, they were exported to AutoCAD for further processing before being imported back into ArcMap to create the final sidewalk polygons. The process for creating curbs and gutters followed the same general process for creating sidewalks, with minor modifications. All sidewalk, curb, and gutter features were save in the CampusMap / FacilitiesStreets / StreetPavement feature class with attribute values in the SURFUSE (alias: Use) field differentiating between each type.
Figure 21. Manual Selection of Sidewalk Boundaries (in Green) in Progress. 3. Streets and Landscaping. Since streets and landscaping occupy the majority of areas not occupied by buildings, sidewalks, curbs, and gutters, the process for creating these two types of features involved performing a simple spatial erase process over a blank polygon template and applying human judgment to assign either a street or landscape attribute to each feature. Figure 22 and Figure 23 show the process for creating
36
the streets and landscape features. Street features were saved in the CampusMap / FacilitiesStreets / StreetPavement feature class with a street attribute in the SURFUSE field and landscaping features were saved in the CampusMap / FacilitiesStreets / LandscapeArea feature class.
Figure 22. Process for Creating Street and Landscape Features.
37
Figure 23. Manual Identification of Street (in Purple) and Landscape (in Green) Features in Progress. 4. Streams and Ponds. Streams and ponds were manually created line-by-line from the AutoCAD polylines due to the low numbers of those features on campus. These features were saved in the CampusMap / ReferenceData / Waterbody feature class.
38
Figure 24. Process for Creating Building Features (1 of 2).
39
Process: Target: buildings2_020410.shp / Join Feature: building_polygon / Match Option (Closest) / Output: bldg_attrib_1.shp
15. Transfer Attributes Using Spatial Join (ArcToolbox)
Copy Building Attributes =>
8. Open buildings.dwg in ArcMap
4. Open buildings.dwg in AutoCAD
Create Building Features =>
Create Building Features
Input: buildings_copy_proj.shp
16. Add Features From Official Geodatabase
Note: Re-projection will not perfectly match buildings_copy_proj.shp to bldg_attrib_ 1.shp; spatial adjustment is required.
17. Spatially Adjust buildings_copy.shp
Process: Project Tool; Target: GCS NAD27; Output: building_copy_proj.shp; NAD_1927_TO_WGS_84_79_CONUS
13. Re-project buildings_copy.shp
12. Export Buildings Feature Class Process: Export buildings feature class to buildings_copy.shp and exit ArcMap. Output: buildings_copy.shp
Input: buildings_temp.shp Process: Check and edit all buildings, remove all non-University buildings.
10. Manually Edit Building Features
Process: (a) PEDIT / Multiple (Select All) / Join / Fuzz Distance = 2, (b) PEDIT / Multiple (Select All) / Close
6. Convert Polylines to True Polygons
Process: Select features with value of “Buildings” in the “Layer” using Select by Attribute.
2. Select All Buildings
Output: buildings_temp.shp
9. Export All Data to Shapefile Format
Process: (a) PEDIT / Multiple (Select All) / “Convert to polylines?” Y, (b) Modify / Design / Convert 3D to 2D Polylines
5. Convert All Lines to 2D Polylines
Input: affine_all_polyline.dwg
1. Open AutoCAD Polyline in ArcMap
Process: Target: bldg_attrib_1.shp / Join Feature: buildings_copy_proj.shp / Match Option (Closest) / Output: bldg_attrib_2.shp
18. Transfer Attributes Using Spatial Join (ArcToolbox)
Input: (1) buildings2_020410.shp (NAD27) and (2) sustain_map.gdb / buildings / building_polygon (NAD27)
14. Open New Map in ArcMap
Process: Select, copy, and paste buildings to CampusMap / FacilitiesStreets / Building then save edits.
11. Manually Copy Edited Buildings to Official Geodatabase
Output: buildings.dwg
7. Save buildings.dwg and Exit AutoCAD
Output: buildings.dwg
3. Export Selected Features to CAD .dwg Format
Section 2.9 (1 of 2)
Figure 25. Process for Creating Building Features (2 of 2)
40
24. Add Facility_Report.xls to ArcMap
23. Process “Facility_Report.xls” Data in Excel
Building Identifier = Fac_Num + Fac_Suffix Facility Site Identifier = “Northridge” Short Name of Building = Abrev, then manually edit by analyzing map Full Name of Building = Name, then manually edit by analyzing map Date Constructed => Compl_Date
Process: Field Calculator Field Mapping
30. Copy Attributes to Official Map
Transfer Attributes to Official Features =>
31. Save Official Map Data and Exit ArcMap
Do not save old map.
27. Create New Map in ArcMap
Input: Facility_Report.xls
Input: (1) bldg_attrib_2.shp, (2) CampusMap / FacilitiesStreets / Building; ignore re-projection warning.
Process: Target: bldg_attrib_1.shp / Join Feature: building_copy.shp / Match Option (Closest) / Output: bldg_attrib_2.shp
Process: Concatenate FacNum and FacSuffix (lower case) into new field named ID_2 in Microsoft Excel.
20. Add Features
19. Transfer Attributes Using Spatial Join (ArcToolbox)
Create Building Features
Input: (1) CampusMap / FacilitiesStreets / Building, (2) bldg_attrib_4.shp
28. Add Official Map Data and bldg_attrib_4.shp
Process: Join By Attribute Input: bldg_attrib_3.shp (ID_1), Facility_Report.xls (ID_2)
25. Join Attributes
Process: Join By Attribute Input: building (OBJECTID), bldg_attrib_ 2.shp (OBJECTID_1)
21. Join Attributes
Input: (1) Building (OBJECT_ID), (2) bldg_attrib_4.shp (Building_Identifier)
29. Join Attributes
Input: bldg_attrib_3.shp (Joined) Output: bldg_attrib_4.shp
26. Export Data
Input: building (Joined) Output: bldg_attrib_3.shp
22. Export Data
Section 2.9 (2 of 2)
Figure 26. Process for Creating Sidewalks.
41
21. Save Data and Exit ArcMap
Note: The previous step may not produce correct polygons; manually inspect all polygons and adjust incorrect features.
17. Manually Edit Polygons
Output: sidewalks_polygon.shp (Polygon) Projection: WGS84 Web Mercator (Auxiliary Sphere)
13. Create a Blank ShapeFile and Load in ArcMap
18. Save sidewalks_polygon.shp
Input: sidewalks.dwg / polyline
14. Add AutoCAD Sidewalks to ArcMap
Process: (a) PEDIT / Multiple (Select All) / “Convert to polylines?” Y, (b) Modify / Design / Convert 3D to 2D Polylines
10. Convert All Lines to 2D Polylines
9. Open Sidewalks AutoCAD File in AutoCAD
Input: sidewalks_draft.dwg
Process: Use aerial photo and good judgment.
6. Manually Delete All Non-Sidewalk Lines
Process: In Symbology, manually select values in the Layer field corresponding to features that border sidewalks.
2. Filter All Real Property Features
Input: sidwalks_draft.shp Process: Topology Toolbar / Planarize Lines
5. Split All Lines at Intersections
Input: affine_all_polyline.shp that was previously created.
1. Open AutoCAD Polyline Shapefile in ArcMap
Input: CampusMap / FacilitiesStreets / StreetPavement
19. Add Official Map Data
Input: sidewalks_polygon.shp Process: Draw a large polygon around all sidewalks.dwg features.
15. Draw a Blank Template
Process: (a) PEDIT / Multiple (Select All) / Join / Fuzz Distance = 2, (b) PEDIT / Multiple (Select All) / Close
11. Convert Polylines to True Polygons
Output: sidewalks_draft.dwg
7. Save Shapefile and Export to AutoCAD .dwg
Process: Change value of Layer for select features to “Base” using Field Calculator.
3. Flatten Sidewalk Features
Process: Select all features in sidewalks.dwg and paste into StreetPavement; in “Use” field assign value of “Sidewalk”.
20. Copy AutoCAD Sidewalks to StreetPavement
Process: Select all polyline features, select Split Polygons in the Topology Toolbar, adjust cluster tolerance as needed
16. Cookie Cut Sidewalks Out of the Blank Template
Output: sidewalks.dwg
12. Save sidewalks.dwg and Exit AutoCAD
8. Close ArcMap
Output: sidewalks_draft.shp
4. Export Data and Remove affine_all_polyline.shp
Figure 27. Process for Creating Curbs.
42
21. Save Data and Exit ArcMap
Note: The previous step may not produce correct polygons; manually inspect all polygons and adjust incorrect features.
17. Manually Edit Polygons
Output: curbs_polygon.shp (Polygon) Projection: WGS84 Web Mercator (Auxiliary Sphere)
13. Create a Blank ShapeFile and Load in ArcMap
Input: curbs_draft.dwg
18. Save curbs_polygon.shp
Input: curbs.dwg / polyline
14. Add AutoCAD Curbs to ArcMap
Process: (a) PEDIT / Multiple (Select All) / “Convert to polylines?” Y, (b) Modify / Design / Convert 3D to 2D Polylines
10. Convert All Lines to 2D Polylines
Process: Use aerial photo and good judgment.
Input: curbs_draft.shp Process: Topology Toolbar / Planarize Lines
9. Open Curbs AutoCAD File in AutoCAD
6. Manually Delete All Non-Curb Lines
Process: In Symbology, manually select values in the Layer field corresponding to features that border curbs.
2. Filter All Curb Features
5. Split All Lines at Intersections
Input: affine_all_polyline.shp that was previously created.
1. Open AutoCAD Polyline Shapefile in ArcMap
Input: CampusMap / FacilitiesStreets / StreetPavement
19. Add Official Map Data
Input: curbs_polygon.shp Process: Draw a large polygon around all curbs.dwg features.
15. Draw a Blank Template
Process: (a) PEDIT / Multiple (Select All) / Join / Fuzz Distance = 2, (b) PEDIT / Multiple (Select All) / Close
11. Convert Polylines to True Polygons
Output: curbs_draft.dwg
7. Save Shapefile and Export to AutoCAD .dwg
Process: Change value of Layer for select features to “Base” using Field Calculator.
3. Flatten Curb Features
Process: Select all features in sidewalks.dwg and paste into StreetPavement; in “Use” field assign value of “Curb”.
20. Copy AutoCAD Curbs to StreetPavement
Process: Select all polyline features, select Split Polygons in the Topology Toolbar, adjust cluster tolerance as needed
16. Cookie Cut Curbs Out of the Blank Template
Output: curbs.dwg
12. Save curbs.dwg and Exit AutoCAD
8. Close ArcMap
Output: curbs_draft.shp
4. Export Data and Remove affine_all_polyline.shp
Figure 28. Process for Creating Gutters.
43
21. Save Data and Exit ArcMap
Note: The previous step may not produce correct polygons; manually inspect all polygons and adjust incorrect features.
17. Manually Edit Polygons
Output: gutters_polygon.shp (Polygon) Projection: WGS84 Web Mercator (Auxiliary Sphere)
13. Create a Blank ShapeFile and Load in ArcMap
Input: gutters_draft.dwg
18. Save gutters_polygon.shp
Input: gutters.dwg / polyline
14. Add AutoCAD Gutters to ArcMap
Process: (a) PEDIT / Multiple (Select All) / “Convert to polylines?” Y, (b) Modify / Design / Convert 3D to 2D Polylines
10. Convert All Lines to 2D Polylines
Process: Use aerial photo and good judgment.
Input: gutters_draft.shp Process: Topology Toolbar / Planarize Lines
9. Open Gutters AutoCAD File in AutoCAD
6. Manually Delete All Non-Gutter Lines
Process: In Symbology, manually select values in the Layer field corresponding to features that border gutters.
2. Filter All Gutter Features
5. Split All Lines at Intersections
Input: affine_all_polyline.shp that was previously created.
1. Open AutoCAD Polyline Shapefile in ArcMap
Input: CampusMap / FacilitiesStreets / StreetPavement
19. Add Official Map Data
Input: gutters_polygon.shp Process: Draw a large polygon around all gutters.dwg features.
15. Draw a Blank Template
Process: (a) PEDIT / Multiple (Select All) / Join / Fuzz Distance = 2, (b) PEDIT / Multiple (Select All) / Close
11. Convert Polylines to True Polygons
Output: gutters_draft.dwg
7. Save Shapefile and Export to AutoCAD .dwg
Process: Change value of Layer for select features to “Base” using Field Calculator.
3. Flatten Gutter Features
Process: Select all features in sidewalks.dwg and paste into StreetPavement; in “Use” field assign value of “Gutter”.
20. Copy AutoCAD Curbs to StreetPavement
Process: Select all polyline features, select Split Polygons in the Topology Toolbar, adjust cluster tolerance as needed
16. Cookie Cut Gutters Out of the Blank Template
Output: gutters.dwg
12. Save gutters.dwg and Exit AutoCAD
8. Close ArcMap
Output: gutters_draft.shp
4. Export Data and Remove affine_all_polyline.shp
3.8
Create Maps for Publication Map creation in ArcGIS involves using the ArcMap program to create map
documents (.mxd files) which symbolize spatial and spatially-related data that are stored in various data files or databases. Two critical pieces of this .mxd document consist of the symbology and data connections. The symbology or graphic design aspect of the map requires the use of appropriate cartographic conventions to ensure that a map achieves its purpose (Tyner 2010) while the data connections are required for the ArcMap document to access the underlying spatial data. As mentioned earlier, one of the key benefits of using a standard geodatabase design resides in its ability to seamlessly integrate with maps created by other agencies which have also adopted the same standard design—a crowdsourcing of design in a sense. This project adopted a map template called the “Campus Basemap (ArcGIS 10)” created by the ArcGIS Local Government Team (Esri 2012d) for use with the Local Government data model. This general template contained numerous elements of map design such as symbol, color, and type selection for many key features such as buildings, streets, sidewalks, landscaping, and pavement markings. This template obviated the need to create map symbologies from scratch and provided an seventy-five percent design that could be customized to meet the needs of CSUN’s web map. Table 2 summarizes the modifications made to the generic template. The second key component of the ArcGIS map document is the data connection. ArcGIS provides two ways to directly connect to spatial data stored on database servers: ArcSDE service connections and direct connections. ArcSDE service connections use the ArcSDE program to help convey spatial data between ArcMap and the database, while
44
Map Template Feature Group Layers Labels
Symbology
Modification Added 1:18,000 scale Added Parking Labels Added Labels for Various POIs Added Street Labels Added Sidewalk Labels Modified Various Symbology for Site Amenities, Street Pavement, and Landscape Areas
Table 2. Modifications Made to the Campus Basemap Template. direct connections bypass ArcSDE and its spatial services (Esri 2012b). ArcSDE service connections can be created under either the “Database Servers” or “Database Connections” folder in ArcCatalog. Since “Database Servers” connections only work with personal and workgroup geodatabases (Esri 2012c), the “Database Connections” folder served as the connection method for this project since it supported an enterprise level database. Figure 25 shows the connection details for this project’s connection under the “Database Connections” folder. Note that this connection used Windows authentication for security, shown as “Account / Operating system authentication” in Figure 25.
Figure 29. Campus Map Database Connection Details.
45
3.9
Create Map Service Definitions While ArcMap .mxd files can be directly published to the map server, ArcGIS
provides an optimization service called the map service definition (MSD) which improves both the map performance and graphical display of maps in a web hosted environment. MSDs optimize both map loading times and display performance by checking for map errors prior to publication and by performing graphical adjustments to ensure features and typefaces correctly show up on user displays. MSDs are saved as separate files with the .msd file extension and Figure 30 shows the settings used in the MSD process. This project used .msd files—not .mxd files—for all map publications. It should be noted that the final hosted map services used static cached maps based on MSDs and not dynamically generated MSD maps. Under the map caching approach, MSDs provide benefits in helping to reduce the time it takes to create the static raster images and optimizing the graphic display of features in those images.
Figure 30. MSD Settings. 3.10 Publish Maps to the Map Server Map publication serves as the final step in making maps (MSDs) available as web services on the map server. Publishing a map involves the simple process of going to ArcCatalog, right-clicking on the MSD file for publication, and selecting the publish option (Figure 31), then specifying different parameters for the published map. Since this
46
project used a cached map approach, the map publication process required an additional step of setting up the map cache.
Figure 31. Publishing an MSD in ArcCatalog. 3.10.1 Service Name and Folder for Publication The first dialog box for map publication requires entry of a Service Name and a folder for publication. This project used the MSD file name minus the .msd file extension for the Service Name (e.g. basemap.msd becomes “basemap”) and published all map files to the “CampusMap” folder (see Figure 32). 3.10.2 Map Capabilities ArcGIS Server offers different mapping services with different mapping capabilities. Since this project had a limited scope to provide a basic map, only “Mapping” and “KML” capabilities were used, as shown in Figure 33. KML stands for keyhole markup language and represents a popular spatial data format used in Google Earth and other virtual globe applications. This project included KML capabilities as a convenience for more advanced map users; however, it was not required for the web map project itself.
47
Figure 32. Specifying a Service Name and Folder.
Figure 33. Specifying Map Capabilities.
48
3.10.3 Cache Settings Caching can improve map loading times by creating static raster images of the map, so when a client device loads a cached map, it actually loads an raster image (in formats such as JPG, PNG, and TIF) of the map. This eliminates the need for ArcGIS Server to re-draw a map every time the server receives a map request and can significantly improve performance (Esri 2007; Esri 2009a; especially under heavy load) since the server simply sends out a raster picture file of that map. Since map documents (.mxd) and MSDs can both be published as services, both formats can also be used for generating map caches. Two important parameters for map caching involve tile size and map scale. Map caching produces square image tiles with fixed dimensions that are measured in pixels. The web map used a tile size of 256 x 256 pixels to match the dimension of tiles used in Google Maps and Bing Maps. The number of map scales determines the number of map tiles that a server needs to generate, creating a need to balance an acceptable level of detail for the map with the demands placed on the server to create those tiles (either through on-demand caching or creating the entire cache at one time). The web map used scales that matched those in Google Maps and Bing Maps with scales ranging from 1:141 to 1:18,000. Generating the base map cache for the selected scales took about twenty-five minutes on the server without any other load. Specification of cache parameters is accomplished through the published map’s “Services” property in either ArcCatalog or ArcGIS Server Manager. Figure 34 to Figure 36 show the process for specifying caching properties in ArcCatalog. Note that the web map used preset caching parameters provided by ArcGIS Server to match those of
49
ArcGIS Online maps, Google Maps, and Bing Maps (Figure 35 and Figure 36). Unused scales were manually deleted from the scales list; this process is not shown in the figures.
Figure 34. Initial Map Cache Settings Window.
Figure 35. Selection of Online Tiling Scheme from “Load tiling scheme from” Button.
50
Figure 36. Unmodified Map Cache Settings After Loading Online Tiling Scheme. 3.11 Create and Publish Campus Tour Content The Campus Tour feature was created to demonstrate the use of mashups for creating a seamless and engaging mapping experience that used information from multiple sources (Fu and Sun 2011). This feature required adding a campus tour feature dataset and associated features in the geodatabase and incorporating social media services from Flickr and YouTube in the user interface. Actual content for the Campus Tour was
51
Figure 37. Map for CSUN’s Official Self-Guided Tour. based on the official CSUN online campus tour guide in PDF format (California State University, Northridge 2012) and supplemented with custom-made content. Conceptually, the idea behind this feature involved showing a walking path on the web map with points-of-interest (POIs) along the route, corresponding to the online campus tour guide as shown in Figure 37. Geolocation would allow users to follow their movement on the mobile web map and they could select POIs on screen to show corresponding information
52
such as pictures (included in the PDF guide) and videos (not included in the PDF guide). Creation and publication of the geodatabase information followed the same procedures outlined in Section 3.10. Creation of data on Flickr and YouTube followed each service’s respective process provided on their websites and are not covered in this paper. 3.12 Create Web Service Access The previous steps assembled digital spatial data and transformed them into digital maps for publication as cached services (on the server side of the client-server setup). The next step to making these maps available on client machines involved writing programming code for accessing those ArcGIS Server services. Since this project used a web application (or “web app”) framework, all code was written for web browsers using standard web browser language (discussed later in section 3.13). 3.12.1 Representational State Transfer (REST) Overview All services for the mobile web map—ArcGIS maps, Flickr, Twitter, and YouTube—used the Representational State Transfer (REST) communication architecture which loosely defines a standard convention for sending “requests” from client to server and receiving “responses” from server to client. In the REST architecture, the uniform resource locator (URL) address contains parameters for client requests which the server processes and replies with a response. For example, the REST address for the base map was set to http://seasnail.csun.edu/arcgis/rest/services/CampusMap/basemap/MapServer/. Though REST does not specify a response format, all services used for the web map received responses in the JavaScript Object Notation (JSON) format (Fu and Sun 2011).
53
3.12.2 Map Service Access Accessing map services on the client required use of the ArcGIS JavaScript Application Programming Interface (API) which was developed and provided free-ofcharge by Esri. ArcGIS JavaScript API version 2.8—the latest version as of this thesis— used the Dojo Toolkit as its programming framework (Esri 2012e), which made the process of requesting and displaying maps simple and straightforward for those with a rudimentary understanding of hypertext markup language (HTML) and JavaScript. Figure 38 shows an example of a code fragment for creating a basic ArcGIS JavaScript API map in HTML. Adding additional layers to the map simply involved defining those layers and adding them to the “map” object using the “map” object’s addLayers method, as shown by the example in Figure 39. Script Added to the HTML Head Section dojo.require(“esri.map”); /* Loads the Esri map module */ var map; /* Declare a variable for the map object */ /* Create a function that runs when the page is loaded; this must be called by */ /* dojo.addOnLoad for it to actually run. */ function initLoad() { /* Create new map object and attach to the element in the HTML */ /* with the id = mapDiv. The ArcGIS API will transform the empty */ /* into the map. */ map = new esri.Map(“mapDiv”); /* Create a new layer definition using ArcGISTileMapServiceLayer */ var baseLayer = new esri.layers.ArcGISTiledMapServiceLayer( “http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/ basemap/MapServer”); /* This next line adds the map layer (baseLayer) to the map object. */ /* The map object can contain multiple layers. */ map.addLayer(baseLayer); }
54
dojo.addOnLoad(initLoad); /* This line runs the code when the page is loaded. */
Code Added to the HTML Body Section
Figure 38. Minimum Code for Adding a Map Service. Script for Adding ADA Routes Layer to Map Object (which already contains a map) Note: This is added within the tags and launched with a function. var adaroutes = new esri.layers.ArcGISTiledMapServiceLayer("http://seasnail.csun.edu/ ArcGIS/rest/services/CampusMap/firehydrants/MapServer"); map.addLayer(adaroutes);
Figure 39. Adding a Layer to an Existing Map. The previous examples provided the minimum code required for adding a map to an HTML document. However, code for the mobile web map contained many more optional parameters and JavaScript coding to make the map functional, such as automatically adjusting screen size and controlling layer visibility. Figure 40 provides a basic example showing how to add optional layer parameters in the layer declaration statement, and Table 3 summarizes all the layers created for the mobile web map along with their REST URLs and parameters.
var adaroutes = new esri.layers.ArcGISTiledMapServiceLayer("http://seasnail.csun.edu/ ArcGIS/rest/services/CampusMap/firehydrants/MapServer", {id: “adaroutes”, visible: false}); map.addLayer(adaroutes);
Figure 40. Adding a Layer to an Existing Map with Additional Parameters.
55
Base Layer Map URL: http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/baselayer/MapServer Layer Type: Tiled Map Service Layer id ................................baselayer extent ..........................> logo ............................false navigationMode .........css-transforms fadeOnZoom ..............true infoWindow ...............a lod ..............................> Aerial Photo URL: http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/aerial/MapServer Layer Type: Tiled Map Service Layer id ..............aerial visible .......false Campus Tour (Points) URL: http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/campustour/MapServer/0 Layer Type: Feature Layer id ................................campustourpoints visible .........................false opacity ........................0.0 mode...........................esri.layers.FeatureLayer.MODE_ONDEMAND infoTemplate ..............template (object defined in the code) outFields .....................[“*”] Campus Tour (Lines) URL: http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/campustour/MapServer Layer Type: Tiled Map Service Layer id ..............campustour visible .......false Labels URL: http://seasnail.csun.edu/ArcGIS/rest/services/CampusMap/labels/MapServer Layer Type: Tiled Map Service Layer id ..............labels visible .......false Open Street Map Object: Esri’s OpenStreetMapLayer object id ..............baseOSM Table 3. Summary of Map Layers.
56
3.12.3 Social Media Access All three social media platforms used in the mobile web map—Flickr, Twitter, and YouTube—provided optional geolocation capabilities for their services and offered APIs for accessing their data. The geolocation capabilities made it possible to visualize photos, videos, and “tweets” on the mobile web map and was added to this project as a way to experiment with developing a mobile user interface for social media. Integrating social media services proved far more difficult than map services, because each social media service delivered its data using different JSON data structures and their APIs lacked the map display capabilities of the ArcGIS API. This made it necessary to decipher each service’s data structure (by reviewing their respective API documentation and JSON data file) and feeding this data into the ArcGIS API. The code for integrating social media services was entirely based on work by Mr. Sathya Prasad with the Applications Prototype Lab at Esri (2011). 3.12.4 Campus Tour Map and Media Access One of the main challenges of the campus tour was the storage and retrieval of multimedia for points of interest along the campus tour route. The project initially attempted to integrate multimedia data into the geodatabase by using a content management system (CMS) for storing media. However, several platforms evaluated for this project (DotNetNuke, OrchardCMS, and Joomla) lacked mature administrative features and were too cumbersome to use and administer. As a result, the CMS approach was abandoned and an alternative approach was taken to take advantage of social media services which can be integrated with web map data.
57
In addition to reducing the administrative burden associated with managing multimedia data, using the social media platforms presented the possibility of presenting multimedia content using alternative ontological (i.e. meaning) representations. For example, one view of a Flickr map can show pictures at their tagged locations (e.g. musicians in Cypress Hall preparing for a concert) while another view can show those same pictures at another location based on meanings associated with those pictures (e.g. the same pictures superimposed on the Valley Performing Arts Center for the actual concert). 3.13 Create User Interface 3.13.1 Overview Creating the user interface required two important design decisions. The first decision involved designing the mobile web map as either a web application (or “web app”) or a native application (or “native app”). The term native app describes a program written and compiled for a specific operating system such as Android, iOS, or Windows Phone. As platform-specific programs, native apps can directly link to a mobile device’s other programs and to private information stored on the device, such as phone logs and address books. On the other hand, the term web app describes programs written to work through web browsers. Since all modern mobile devices have at least one web browser, creating a single web app effectively makes it available for use on virtually all newer mobile devices. However, web browsers lack some of the more advanced data access capabilities of native apps due to heightened security restrictions on web browsers and differences in how different operating systems work. The mobile web map used the web
58
app approach since it was designed to reach a wide audience and did not need to access the advanced features of a mobile device. The second design decision involved the approach used for coding the web app program. The first option involved developing the web app using standard web programming components (namely hypertext markup language (HTML), cascading style sheets (CSS), and JavaScript) either through hard coding or using a WYSIWYG1 editor such as Adobe Dreamweaver. Standards for HTML and CSS are governed by the World Wide Web Consortium (W3C) (W3C 2012a), while standards for JavaScript—which is a variation of the ECMAScript2 language (Wikipedia 2012b)—are governed by ECMA International and the W3C (W3C 2012b). However, different web browsers provide different levels of support for different versions of HTML, CSS, and JavaScript which can present compatibility issues. Therefore, code written for one browser (e.g. Android 2.3.5 Gingerbread browser) may not work the same way on another browser (e.g. Apple iOS 5.1 Safari browser). The second option for coding the web app involved the use of JavaScript libraries which are JavaScript-based development platforms for creating dynamic websites (Wikipedia 2012c). JavaScript libraries provide a simplified approach to using JavaScript code and many modern versions have integrated other web technologies such as HTML and CSS into their frameworks resulting in a seamless all-in-one platform for building dynamic interactive websites. This project started off using HTML5 as the development platform (Pilgrim 2011; Kyrnin 2012) but eventually transitioned to using the JQuery and
1 2
What you see is what you get (WYSIWYG) Other variations of ECMAScript include Microsoft’s JScript and Adobe’s ActionScript
59
Dojo Toolkit libraries due to their ability to work consistently across different browsers. The web map used JQuery—along with its user interface (JQuery UI) and mobile (JQuery Mobile) variations—for the user interface design and Dojo for accessing services on ArcGIS Server (Esri 2012e; the ArcGIS JavaScript API was built using Dojo). 3.13.2 User Interface Design The user interface was designed with the objective of visually and functionally replicating the “look and feel” of a modern mobile application, such as the interfaces on Android, iPad, and iPhone. Creating a familiar interface can help make users feel more comfortable with using an application and reduce the time needed to gain proficiency in a program. This objective was achieved using the JQuery Mobile and UI libraries which used JavaScript and CSS to automatically style the mobile map’s web pages to look and function like native apps on a mobile device. Another user interface objective was balancing ease-of-use with functionality. Mobile devices have smaller displays than desktop computers, and users interact with mobile apps using imprecise touch interfaces instead of the very precise cursors in desktop apps. Figure 12 in the Introduction showed an example of how a website designed for a desktop web browser became unusable on a smartphone. Additionally, modern mobile devices have the computing power of low-end desktop computers making it possible for mobile maps to offer many of the more advanced features of their desktop counterparts. However, a feature-rich application would result in additional interface graphics (such as form fields and buttons) which could quickly fill up the small screen of a mobile device. This project resolved this dilemma by placing interface options in various “pop up” screens which users could access at the touch of a button on the main
60
screen. Functionally, these “pop up” screens were implemented as “pages” in the JQuery framework. Pages in JQuery appear as independent web pages on a web browser but physically reside together on the same HTML document. This single file format provided several advantages for the mobile map website when compared to using a multi-file website. First, consolidating all pages into a single document allowed for a more responsive (faster) website since it eliminated—or significantly reduced—the need for the web browser to manually load a web page each time it was opened. Instead, the single HTML document loaded all the pages, JQuery scripts, Dojo scripts, CSS files, ArcGIS Server map objects, and all other resources at one time and stored that information in the client device’s memory. This allowed the web app to quickly respond to user inputs without any noticeable delay and added to the “look and feel” of a native app. Second, using a single physical page eliminated the need for using cookies or other web tracking mechanism for keeping track of user preferences and selections. Multi-page websites often use cookies to keep track of user preferences (such as the layers selected on a map) as users navigate from page to page. The mobile web map used JQuery and Dojo to store and keep track of various preferences (e.g. layers to show on the map) as users navigated from page-to-page and eliminated the need for cookies. Finally, reducing the amount of network traffic generated by a mobile web site can reduce data consumption, and costs, for mobile users who have internet services that charge based on usage or have a set quota. Network traffic for the mobile web map consists of only an initial download of the single HTML file and requests/responses for REST services.
61
One other challenge for the mobile user interface was finding a way to efficiently display multiple copies of multimedia content. The Campus Tour and social media features of this project connected to Flickr, Twitter (social media only), and YouTube to download pictures, tweets, and videos (respectively) with associated content such as user name, title of the media, and description of the media. One picture with associated content could easily fill up a smartphone screen. The solution to this problem involved the use of a gallery which displayed the number of media items associated with a point on the map and allowed the user to scroll back-and-forth among those items. This feature used a modified version of on an open source JQuery media gallery plug-in called Tiny Carousel produced by Maarten Baijs (2011). Figure 41 to Figure 45 provide conceptual layouts for the user interface structure and contents. The full source code for the user interface has been provided as an attachment to this thesis.
Figure 41. Logo Design for the CSUN Mobile Web Map.
62
The entire mobile map “website” consisted of just one HTML document (index.html) divided up into multiple page views. The page views used the JQuery “pages” framework (in Dojo, these page views are called “views”).
The client downloads the entire website at one time then navigates the site by moving back and forth through the HTML document using JQuery.
Figure 42. User Interface Layout.
63
copyright 2012
Figure 43. Concepts for Map Viewer and Basic Search/Navigation Pages.
64
Figure 44. Concepts for Options and About Pages.
65
Figure 45. Concepts for Tour and Media Viewers.
66
3.14 Launch the Map Launching the map constituted the last process and involved publishing all the client side files to the IIS web server. As mentioned in section 3.2, this project’s web server resided on the same machine as ArcGIS Server and SQL Server database server. The web server was pre-configured to host websites from a specific physical directory and to automatically launch web pages with specific file names (such as index.html and default.html). Since the mobile web map’s entire “website” consisted of a single HTML file named index.html, launching the map simply involved creating a new directory called “CampusMap” and copying index.html with all supporting files (e.g. media files and CSS files) to that directory. The new directory name automatically mapped to the parent domain resulting in a URL of http://seasnail.csun.edu/CampusMap. Since the web server was pre-configured to automatically launch index.html files, users visiting http://seasnail.csun.edu/CampusMap will automatically see the map. (Using a non-default file name such as map.html—in the absence of any other default file—will prevent the user from accessing the map unless the full address of http://seasnail.csun.edu/ CampusMap/map.html is used.)
67
4
FINAL PRODUCT
The final product consisted of a fully functional web map server with all campus map data and a website with the client web map application. Figure 46 provides a graphical summary of the various components of the final mobile web map while Figure 47 to Figure 50 provide sample images of the final web map.
Figure 46. Web Map System
68
Level 1
Level 2
Level 3
Level 4
Level 5
Level 6
Level 7
Level 8
Figure 47. Views of All Eight Map Zoom Levels. 69
mapViewer
navigatePage
optionsPage
aboutPage
Figure 48. Main Mobile Web Map Pages.
70
Campus Tour (in mapViewer)
tourViewer
mediaViewer Figure 49. Campus Tour Map and Media Viewers.
71
Static Map (Existing)
Mobile Web Map
Figure 50. Comparison of Existing Static Map and Mobile Web Map.
72
5
IN CONTEXT OF THE UNIVERSITY LEARNING ENVIRONMENT The discussion of the mobile web map has thus far centered on socio-economic
and technical topics such as its influence on the humanistic perceptions of place, its utility as a marketing tool, and the details of its construction from beginning-to-end. As with many newer technologies, the mobile web map—and even just the idea of a mobile web map—probably even carries a certain novelty factor with its relatively new touch interface, the ability to display mashed up information, and its real-time “you are here” geolocation function that tracks the users’ location on the map. However, the web map (not just the mobile portion) may also represent one important step in a fundamental paradigm shift in the use and integration of geospatial information in the context of the university learning environment. In its agenda-setting decennial publication entitled Strategic Directions for the Geographical Sciences, the National Research Council (NRC) identified the critical importance of geospatial analysis in addressing some of society’s most pressing problems and even dedicated an entire chapter to volunteered geographic information (VGI) (2010). At the institutional level, the web map can foster data sharing and interdisciplinary collaboration which can have significant payoffs in large-scale research. In this matter, the NRC report noted, To date, most progress in the geographical sciences has been made through small, independent research initiatives that may be loosely coordinated, but often are not. . . . Yet as this report suggests, large-scale collaborations are important to address many geographical problems . . .
73
The payoffs to such collaborations can be large, but so are the obstacles to making them happen. It goes on to cite the Human Genome Project as an example of a successful large-scale, technologically-supported collaboration effort. While researchers at CSUN may or may not be involved in projects with the visibility and scope of the Human Genome Project, they do perform important work at the regional level and the web map can serve as an important tool of collaboration and data sharing for that type of work. The GPS project for the visually impaired (Chandler 2011) mentioned earlier in this paper serves as a prime example of research that could have benefitted from a campus web map. The web map as a web hosted service also provides cost advantages whereby the main costs are associated with the server side (e.g. server machine, software updates, data management, etc.) and users can use those services free-of-charge. As noted by Clarke (2011), Increasingly the infrastructure for science means the Internet, the Web, and the grid or cyberinfrastructure. . . . Fortunately they involve little by way of expense; indeed, open source software, grid computing, and open data mean that any geographer, anywhere in the world, can enjoy the same research infrastructure, at least in its basic form. At the student level, the web map can serve as an important educational tool (among many) that can influence how students see the world around them and bring awareness to maps as an important graphical communication medium. In another NRC publication entitled Learning to Think Spatially (2006), the NRC cited the familiar DNA double-helix structure produced by James Watson and Francis Crick in the 1950s—now seen as a foundational element of molecular biology—as a prime example of the power
74
of spatial thinking and representation. The integration of web mapping into student curriculum can help nurture or at least instill this way of thinking and equip students with another important problem solving tool. The web map can also popularize and extend powerful geospatial capabilities to a wide student audience beyond the enclaves of GIS specialists. As demonstrated in this project, the minimum knowledge required for harnessing the power of the campus web map involved some basic HTML and JavaScript knowledge and knowing the URL to the map server. This accessibility also has the power to overcome a real or perceived digital divide between the “haves” and “have nots” of digital technology (NRC 2010; Elwood, Goodchild, and Sui 2012) by making basic GIS capabilities available to all students at no cost. Finally, the web map can serve as a critical catalyst for extending thought development beyond mere technical utility to understanding the human implications of that technology. These human implications can involve concerns that impact other similar Web 2.0 technologies such as issues of privacy, the exacerbation of the digital divide, and other emerging ethical considerations that have risen in importance with this technology. On this matter, the 2010 NRC report stated, Strengthening and deepening geographical education is vital both to building a substantial coterie of geographical scientists who can pursue the kind of work outlined in this report and to promoting the informed, ethical, and sensitive use of geographical technologies in the broader community.
75
6
CONCLUDING DISCUSSION
This thesis successfully created a prototype mobile web map for California State University, Northridge and examined issues related to mobile map design, social media mashups, and the integration of web mapping into the overall context of the University learning environment. Since no web map existed at CSUN, a significant portion of this project focused on the development of the foundational elements of the map on both the server and client sides of the system. Server development consisted of the administrative setup of all components of the map server (i.e. the server machine, SQL Server Enterprise database, ArcGIS Server Enterprise, ArcSDE, and IIS web server), the implementation of Esri’s collaboratively developed “Local Government” data model in ArcGIS, the manual processing and uploading of spatial features for the entire campus into the data model, and the creation and publication of maps for use as map services. Development of the client side involved the creation of web service access to maps and social media using the Dojo JavaScript library and a mobile user interface (UI) using the JQuery JavaScript library. Once the foundational elements were completed, this project proceeded to explore issues of mobile UI design and social media mashups. An interactive campus tour with geolocation capabilities served as the test bed for the mobile UI design. The front end of the campus tour UI used pop-up screens and media carousels to optimize use of limited screen space, while the back end code enabled geolocation capabilities and combined (or mashed up) data from ArcGIS Server, Flickr, and YouTube using REST requests which delivered data in JSON format. Lessons learned from the campus tour experiment were
76
then transferred to provide social media mashup maps using Flickr, Twitter, and YouTube services. Beneath the veneer of the map’s novelty factor (which often accompanies newer technologies), the mobile web map holds significant value as an instrument of serious research. As an instrument of communication, the web map can serve as a powerful communication medium similar to many other non-spatial web media. At the socioeconomic level, the web map can facilitate social connections and shape people’s perceptions of place (e.g. the University) via information delivered in a spatial context. However, the web map can have important value in the context of the University learning environment. When a web map is viewed not as esoteric graphical or artistic instruments that exists for its own sake but as another tool in an effective communicator’s toolbox, it can help researchers more readily present information in a spatial context (easily and without specialized software) and facilitate research collaboration. The web map can also “speak” to a technically-literate generation of younger students who—as a group—may more easily grasp ideas such as “mash ups,” social media, VGI, and Web 2.0 and, in so doing, develop new frameworks or paradigms for solving many of today’s pressing problems. Finally, the web map can serve as a tool for helping to overcome the digital divide between the “haves” and “have nots” of students within a technologically advanced society by making basic spatial mapping capabilities available to all students. This web map was submitted as one prototype for consideration by the University for its official web map and will hopefully represent the starting point—not the final end product—for further web map development by students and faculty at California State University, Northridge.
77
REFERENCES Baijs, M. 2011. “Tiny Carousel.” Tiny Carousel Website. Accessed April 27, 2012. http://baijs.nl/tinycarousel/. Berners-Lee, Tim. 2012. “Frequently Asked Questions.” World Wide Web Consortium Website. Accessed April 25. http://www.w3.org/People/Berners-Lee/FAQ.html. Boroushaki, S. and J. Malczewski. 2010. Participatory GIS: A Web-based Collaborative GIS and Multicriteria Decision Analysis. URISA Journal. 22, no. 1: 23-32. http://www.urisa.org/files/journal22.1-web%20final.pdf. California State University, Northridge (CSUN). 2011. CSUN Campus Maps Website. Accessed 15 October. http://www.csun.edu/maps. ———. 2012. “The Self-Guided Tour Book.” Division of Student Affairs Website. Accessed May 9. http://www.csun.edu/outreach/pdfs/tourbook-online.pdf. Chandler, C. 2011. “CSUN GPS Project to Help Blind, Visually Impaired Navigate Campus.” CSUN Newsroom (blog). Nov. 9. Accessed April 26. http://blogs.csun.edu/news/2011/11/csun-gps/ Clarke, K. C. 2011. Exploring the Past and Future of our Planet: Not Bit-by-Bit but All at Once. The Professional Geographer 63, no. 3: 320-324. doi: 10.1080/ 00330124.2011.566512. Elwood, S., M. F. Goodchild, D. Z. Sui. 2012. Researching Volunteered Geographic Information: Spatial Data, Geographic Research, and New Social Practices. Annals of the Association of American Geographers 102, no. 3: 571-590. doi: 10.1080/00045608.2011.595657. Esri. 2002. Working with the Geodatabase: Powerful Multiuser Editing and Sophisticated Data Integrity. An Esri White Paper. ———. 2007. “Map caching for beginners.” ArcGIS Blog (blog). August 31. Accessed April 27, 2012. http://blogs.esri.com/esri/arcgis/2007/08/31/map-caching-forbeginners/. ———. 2009a. ArcGIS Server in Practice Series: Best Practices for Creating an ArcGIS Server Web Mapping Application for Municipal/Local Government. An Esri White Paper. ———. 2009b. “ArcGIS Online maps updated and migrated to Google Maps/Bing Maps tiling scheme.” ArcGIS Blog (blog). December 22. Accessed April 26, 2012. http://blogs.esri.com/esri/arcgis/2009/12/22/arcgis-online-maps-updated-andmigrated-to-google-maps-bing-maps-tiling-scheme/.
78
———. 2010. Introduction to ArcGIS Server. Redlands: Esri. ———. 2011. “DS2011: HTML 5: Not Just for Breakfast Anymore!” ArcGIS Resource Center Website. Accessed 19 October. http://resources.arcgis.com/gallery/video/ arcgis-server/details?entryID=CA2660FF-1422-2418-889D-1351E287F9D4. ———. 2012a. “Problem: ArcGIS Server features are not aligning with maps in Google Maps or Microsoft Virtual Earth (Article ID: 34749).” Esri Knowledge Base Technical Articles. Accessed April 26, 2012. http://support.esri.com/en/ knowledgebase/techarticles/detail/34749. ———. 2012b. “A quick tour of connections to ArcGIS geodatabases.” ArcGIS Resource Center Website. Accessed April 27. http://help.arcgis.com/en/ arcgisdesktop/10.0/help/index.html#/A_quick_tour_of_connections_to_ArcSDE_ geodatabases/002q00000030000000/. ———. 2012c. “What are database servers in ArcGIS?” ArcGIS Resource Center Website. Accessed April 27. http://help.arcgis.com/en/arcgisdesktop/10.0/help/ index.html#//003n0000004r000000. ———. 2012d. “Campus Basemap (ArcGIS 10).” ArcGIS.com Gallery Website. Accessed April 27. http://www.arcgis.com/home/item.html? id=0d9299ec726a4ea7b9c6c 1edb07a7483. ———. 2012e. “Working with Dojo.” ArcGIS API for JavaScript Website. Accessed May 1. http://help.arcgis.com/en/webapi/javascript/arcgis/help/jshelp_start.htm. ———. 2012f. “Local Government Data Model Data Dictionary.” ArcGIS Resource Center Website. Accessed May 8. http://help.arcgis.com/en/localgovernment/ datadictionary.html. ———. 2012g. “Local Government Data Model.” Esri Support Website. Accessed May 10. http://support.esri.com/en/downloads/datamodel/detail/33. Fabrikant, S. I., S. R. Hespanha, and M. Hegarty. 2010. Cognitively Inspired and Perceptually Salient Graphic Displays for Efficient Spatial Inference Making. Annals of the Association of American Geographers 100, no. 1: 13-29. doi: 10.1080/00045600903362378. Fu, P. and J. Sun. 2011. Web GIS Principles and Applications. Redlands: Esri Press. Google. 2012. “Our history in depth.” Google. Accessed April 25. http://www.google.com/about/company/history/
79
GPS.Gov. 2012. “What is GPS?” GPS.Gov Website. Accessed April 26. http://www.gps.gov/systems/gps/ Kyrnin, J. 2012. Sams Teach Yourself HTML5 Mobile Application Development in 24 Hours. Indianapolis: Pearson Education. National Research Council (NRC). 2006. Learning to think spatially: GIS as a support system in the K-12 curriculum. Washington, DC: National Academies Press. ———. 2010. Understanding the changing planet: Strategic directions for the geographical sciences. Washington, DC: National Academies Press. O’Reilly, T. 2005. “What is Web 2.0.” O’Reilly Website. Accessed April 26. http://oreilly.com/web2/archive/what-is-web-20.html. O’Reilly, T. and J. Battelle. 2009. “Web Squared: Web 2.0 Five Years On.” Web 2.0 Summit Website. Accessed April 26, 2012. http://www.web2summit.com/ web2009/public/schedule/detail/10194 Paolino, L., M. Romano, M. Sebillo, and G. Vitiello. 2010. Supporting the on-site emergency management through a visualisation technique for mobile devices. Journal of Location Based Service 4, no. 3-4: 222-239. doi:10.1080/ 17489725.2010.537282. Pilrim, M. 2011. “Dive Into HTML5.” Dive into HTML5 Website. Accessed 19. http://diveintohtml5.info/. Prasad, S. 2011. “Building a Mapping Application Start-to-Finish.” Slide presentation presented at the Esri International User Conference, San Diego, CA, July 2011. Project Management Institute. 2008. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Newtown Square: Project Management Institute. Raymond, E. S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol: O’Reilly. Tsou, M. H. 2011. Revisiting Web Cartography in the United States: the Rise of UserCentered Design. Cartography and Geographic Information Science 38, no. 3: 250-257. doi:10.1559115230406382250. Tuan, Y. 1996. “Space and Place: Humanistic Perspective.” In Human Geography: An Essential Anthology, edited by J. Agnew, D. N. Livingstone, and A. Rogers, 444457. Malden: Blackwell. Turchi, P. 2004. Maps of the imagination: the writer as cartographer. San Antonio: Trinity University Press.
80
Tyner, J. A. 2010. Principles of Map Design. New York: Guilford Press. United States Geological Survey Global Positioning System Committee. 2012. “USGS Global Positioning System.” United States Geological Survey Global Positioning System Committee website. Accessed April 26. http://water.usgs.gov/osw/gps/ index.html. W3C. 2012a. “HTML & CSS.” World Wide Web Consortium Website. Accessed May 1. http://www.w3.org/standards/webdesign/htmlcss. ———. 2012b. “JavaScript Web APIs.” World Wide Web Consortium Website. Accessed May 1. http://www.w3.org/standards/webdesign/script. Weiser, M. 1991. The Computer for the 21st Century. Mobile Computing and Communications Review 3, no. 3: 3-11. doi: 10.1145/329124.329126 (Reprinted from Scientific American. 265, no. 3:94-104.) ———. 1998. The Future of Ubiquitous Computing on Campus. Communications of the ACM 41, no. 1: 41-42. doi:10.1145/268092.268108. Wikipedia. 2012a. “Work Breakdown Structure.” Wikipedia: The Free Encyclopedia. Accessed April 26. http://en.wikipedia.org/wiki/Work_breakdown_ structure. ———. 2012b. “ECMAScript.” Wikipedia: The Free Encyclopedia. Accessed May 1. http://en.wikipedia.org/wiki/ECMAScript. ———. 2012c. “JavaScript Library.” Wikipedia: The Free Encyclopedia. Accessed May 1. http://en.wikipedia.org/wiki/JavaScript_library Yang, J., A. Varshavsky, H. Liu, Y. Chen, and M. Gruteser. 2010. Accuracy characterization of cell tower localization. Proceedings of the 12th ACM international conference on Ubiquitous computing (Ubicomp ’10). New York: ACM. doi: 10.1145/1864349.1864384.
81
APPENDIX A: WEB MAP HARDWARE, SOFTWARE, AND PROTOCOLS User Interface - HTML, CSS, JavaScript - JQuery - Dojo Map and Social Media Application Programming Interfaces (APIs) - Esri ArcGIS Map Server API - OpenStreetMap Server API - Flickr, Twitter, and YouTube APIs - All these APIs use the REST protocol and deliver data in JSON format Map Settings - Spatial Reference: WGS84 Web Mercator (Auxiliary Sphere) - Cached Tile Size: - Preset Scaling: Operational Web Map Server Hardware and Software Hardware - Intel Xeon E5640 64-bit quad-core processor with 6 GB RAM Software - Server Operating System: Windows Server 2008 R2 Enterprise - Web Server: Microsoft Internet Information Server (IIS) 7.5 - Database Server: Microsoft SQL Server 2008 R2 Enterprise - GIS Server: Esri ArcGIS 10 Server Enterprise with ArcSDE - Desktop GIS Software: Esri ArcGIS 10 Desktop (ArcInfo License) Development Platform Hardware Software Hardware - Intel Core i5 M460 64-bit processor with 8 GB RAM Software - Operating System: Windows 7 Professional (64-bit) - Database Server: SQL Server Express - Desktop GIS Software: Esri ArcGIS 10 Desktop (ArcInfo License) - Drafting Software: Autodesk AutoCAD 2012 Civil 3D - Web Authoring: Adobe Dreamweaver 5.5; Aptana Studio 2; Microsoft Notepad - Multimedia: Adobe Illustrator 5.1; Windows Movie Maker; Microsoft Expression 4 GPS Data Collection Data Collector - Hardware: Trimble GeoExplorer 2003 Series GeoXT data collector, circa about 2004 - Operating System: Microsoft Pocket PC 2003 - GIS Software: Esri ArcPad - Differential Correction Software: Trimble GPSCorrect version 2.10 - Trimble Pathfinder Office
82
