TPS_Boundaries
The TPS_Boundaries map service was used in the Toronto Crimes Database Web application in order to allow users to focus the Web application on a specific TPS region. The development of this map service was relatively basic when compared to the two feature services which will be discussed later. Using ArcMap, each of the seventeen TPS divisions that were produced earlier using the erase tool were loaded into the map document as separate layers. Each layer was renamed to effectively display the name of the division which it represents. The layers were also each assigned a single symbol that used a black fill and a Gray 50% outline of 0.4 units. Each layer was subsequently assigned a 70% transparency. Once all of the division layers had been configured and stacked in the Table of Contents (TOC) in descending numerical order, an eighteenth layer was added that featured all of the TPS division boundaries. This final layer was moved to the bottom of the TOC and was assigned no fill, but was given a 1.0 unit thick black border. This layer provided context to users by allowing them to visualize all of the TPS boundaries at the same time, regardless of which specific division was currently selected. As a result of the data that was loaded into the map document based on the WGS 1984 Web Mercator Auxiliary Sphere projection, the dataframe was automatically assigned the same projection.
Using the Catalog window, the pre-established administrative connection to the envmaps2 ArcGIS server was activated. A new folder was created on the envmaps2 server titled CrimesDatabase and the
71
ArcGIS Server Properties window was accessed. From this window, the Data Store tab was selected and the local folder that contained the file geodatabase that had been used to store the TPS boundaries feature classes was added as a Registered Folder with the title ddata. Registering a local folder with ArcGIS Server prevented the server from creating duplicate copies of the data any time a new service was published. This feature was new in ArcGIS for Server 10.1 and helped to both hasten the publishing process and to limit the total amount of storage space that was required. The rationale behind ArcGIS Server creating a duplicate copy of data is to support working environments where multiple publishers have access to a single server instance and each publisher is working from a separate remote computer. In this scenario, data that was referenced in the published map document and stored on a remote computer would be compressed along with the map document, packaged, and transferred to the server. Upon arrival, the data and map document would then be unpackaged and placed into a streamlined folder structure in a directory, which the GIS server has uninterrupted access to.
Once the appropriate folder had been registered, the map document was saved and published from within ArcMap as a map service. Within the publishing wizard, the CrimesDatabase folder that had been created on the GIS server was used to store the map service. The service was assigned the name TPS_Boundaries and the Web Map Service (WMS), Web Feature Service (WFS), and Feature Access checkboxes were not checked as this service was intended to be used specifically with the ArcGIS API for JavaScript without a new for any editing capabilities. The service was set to draw dynamically, as opposed to as a cached map service. Although a cached map service would display faster and require less bandwidth to transfer, it would have inhibited the ability to turn layers on and off. This ability does exist with dynamic map services and was used within the Toronto Crimes Database Web application. Finally, the analyzer tool was used to ensure that the map service had been configured correctly for optimal performance. Unlike in earlier versions of ArcGIS Server, the analyzer in 10.1 is a mandatory step for publishing a map service. Once the analysis was complete, the map service was finally published.
72
The Instances_and_Comments feature service was used in the Toronto Crimes Database Web application and was an essential service that was used for collecting and displaying data. This feature service was also authored in ArcMap and incorporated two editable datasets. Within an empty map document, the citizen_comment dataset was added from the CDB database that was hosted on SQL Server. Once loaded into ArcMap, the layer’s name was updated to Citizen Comments and an editing session was run in order to populate the dataset with some randomized sample data. Upon saving and ending the editing session, the layer’s symbology was updated to support unique value categories based on the Importance field. A 10% simple hatch pattern was assigned to each of the three categories and a unique colour which represented the user’s perceived importance of the comment was assigned. When selecting the colours that would be used, the HSV characteristics of the colour were altered such that the colour possessed a high value percentage. Doing so allowed the features to stand out from the predominantly muted colour scheme of the accompanying basemaps.
Four group layers were then created within the dataframe and each were assigned a unique scale range dependency in which the data contained in the group layer could be displayed. The scale ranges of the group layers were designed to match the scale ranges that were used in a number of the various scale levels of the Topographic basemap. The crime_instances dataset from the database on SQL Server was then added to the map document and renamed to Crime Instances. The new layer was then seeded with randomized sample data. Once the dataset had been sufficiently populated with sample data, the layer’s symbology was updated to account for unique value categories that were based on the Type field. Each category was assigned a three-tiered symbol to visually represent the type of crime that was reported. Each symbol was circular in format and contained a large black circle that was overlaid with a slightly smaller coloured symbol. The top layer in each symbol contained a default character symbol that was available from the Esri Crime Analysis font set. Crime symbols were selected based on how effectively they could represent the reported crime. Doing so improved the symbol’s ability to stand out from the surrounding basemap, which used a predominantly muted colour scheme. Some symbols were used multiple times for
73
similar types of crimes, but were assigned different background colours. For instance, the symbol for Assault used the fist symbol with a bright yellow background, while the symbol for Assault with a Deadly Weapon used the same fist symbol but with a bright red background.
Once all the categories had been uniquely symbolized, the Crime Instances layer was copied four times within the document. The layers were evenly distributed into the group layers such that each group layer contained a single copy of the Crime Instances layer. The sizing of the symbology was then altered for each group layer so that depending on the group layer, the symbology ranged from 13 to 18 units. The desired effect was to create a map service where crime reports would vary in size depending on the scale of the map. If the map were viewed at the city level, then the crime reports would be smaller and less overlap would occur between neighbouring features; however, if the map was then zoomed-in and focused on a specific neighbourhood, the crime reports would be larger and easier to identify.
Feature templates were then created for both the Citizen Comments layer, as well as the multiple Crime Instances layers. This was done in order to ensure the overall accuracy of the data by limiting the number of input options that would be available to the user when reporting a crime instance or comment. Features that were declared as a feature template would be displayed along with their associated symbol and title when reporting data via the Toronto Crimes Database Web application. Once the symbology and feature templates had been finalized, the map document was then configured to be time-enabled based on the Date fields in both of the included datasets. Enabling time in the map document was done so that the Web application could be designed to visualize the temporal changes that occurred within the data. With a time-enabled map service, users could visualize crimes that occurred during a specific period of time, or view the changes that occurred in the criminal landscape of the city over time.
Before publishing the map document, the standard WGS 1984 Web Mercator Auxiliary Sphere projection was assigned to the dataframe. The SQL Server database was then assigned as a registered database on the envmaps2 GIS server in order to prevent the data from being duplicated. Finally, the
74
permissions for the SQL Database were edited such that the user envmaps2\arcgis had Read/Write permissions for the datasets that were used. This was an essential step in order to allow the GIS server to access and edit the datasets. Once these changes were made, the map document was saved and published to the CrimesDatabase folder on the envmaps2 GIS server. Within the publishing wizard, feature access was enabled and the options for creating, querying and updating data were selected. Once the map document had been analyzed for optimal performance, the document was then published.
Graffiti_edit
The Graffiti_edit feature service was used in the Graffiti Tagger Web application and was an essential service that was used for collecting and displaying data. This feature service was also produced using ArcMap and featured the attachments-enabled Graffiti dataset which was added from the CDB database that was hosted on SQL Server. Within a blank map document, the Graffiti dataset was added. To populate the dataset with data, actual geotagged graffiti reports were used. A total of 95 geotagged images of graffiti from across the City of Toronto were included. Images were taken by the author using a GPS-enabled Galaxy Nexus mobile phone and were subsequently transferred to the server via the remote PC. Once the images were stored locally on the server, the Geotagged Photos to Points tool was used in ArcMap to produce a point feature class that contained each of the graffiti images as attachments. The feature class was then altered to match the schema of the existing Graffiti dataset and the Append (Data Management) tool was used to append the records to the Graffiti dataset. Once appended, the geotagged images feature class was removed from the map document. To view the results of this process, see Figure 4.4 and Figure 4.5 below. This workflow stated above was only used by the author in order to initially seed the database. Application users would use a separate workflow that is described later in this thesis in order to upload and geotag their graffiti photos on an individual basis.
75
Figure 4.4 – Graffiti Photos viewed through Windows Explorer Data Source: James Lockyer-Cotter
Figure 4.5 – Graffiti Points Georeferenced and Stylized in ArcGIS 10.1 (Overlaid on Esri Gray Canvas Basemap)
76
Once the dataset had been populated with data, the layer’s single symbol symbology was updated to use a three-tiered symbol that was similar to those used in the Crime Instances layer. A large black circle was placed beneath a slightly smaller gray circle with a graffiti icon from the Esri Crime Analysis font set placed on top. The gray circle was used to denote uncategorized graffiti reports. It was hoped that with the participation of a professional gangs or graffiti analyst, reports could be updated retroactively to symbolize graffiti reports as either gang-related or not. Once the symbology had been updated, a feature template was created for the unconfirmed feature symbol and the map document was saved and published as a feature service. Within the publishing wizard, the CrimesDatabase folder on the envmaps2 GIS server was selected, and the option to allow feature access was enabled. In addition, the ability to create, delete, query and update features were all selected. Following the analysis for optimal performance, the feature service was then published. Once published, the ArcGIS Server Administrator Directory site was accessed over HTTPS at https://envmaps2.uwaterloo.ca/admin/admin. Within the services section, the Graffiti_edit feature service was selected and reconfigured to provide support for a number of common image file types and to limit the maximum image upload size to 5mb.