Deloitte Consulting works hand-in-hand with our clients to create the most viable solution possible for the client’s needs. In order to do so, Deloitte Consulting develops a GIS team comprising of Deloitte Consulting practitioners and client personnel. This team is responsible for all the GIS work involved at the client site. Deloitte Consulting will initially lead the effort and incorporate all the necessary tools and knowledge while gradually transferring those tools and knowledge to the client. At the end of the engagement, the client will be able to self-sustain their GIS work. The GIS team will be responsible for taking mapping requests, managing the resources allocated to those requests, and completing all the necessary steps to include the map in the "production" environment.

In order for the group to take mapping requests, the GIS Team needs to incorporate two formal request structures. The first form is accepting requests from user workgroups. Workgroups are generally created in technical environments to test the inclusion of new data into a system, to take user requests, and develop applications. Workgroups tend to focus on their area of specialty and are capable of generating GIS requests based on their own data. A less formal method of gathering requirements will come from this group, where GIS team members will illicit mapping requests from workgroup members.

A more formal method of procuring GIS requests is the creation of a Data Processing Service Request (DPSR). Variations of DPSRs exist in every IT department of organizations, but the essential functionality is for a person or department to generate a request for technical/informational service. DPSRs can be implemented over the Local Area Network (LAN) as a web form, submitted directly to the servicing department in question, or exist as a verbal commitment later described on paper. An existing DPSR can easily be adapted to fit the needs of the GIS team. This document formalizes the structure of requests for GIS services because the author of the DPSR must collate a certain amount of information in the format required by the DPSR and the form implies ownership of the GIS services provided.

A second responsibility of the GIS team is the management of resources allocated to GIS service requests. Ideally, GIS resources are devoted to tasks that add the greatest value to the organization. Deloitte Consulting has found through extensive project experience that the best model to follow when devoting GIS resources is the 10/30/60 framework. The framework attempts to categorize the types of requests to the GIS team, generated by user workgroups, into three categories: Ad Hoc, Static, and Dynamic. Furthermore, the framework guides the GIS Team’s devotion of resources based on the types of projects undertaken, the amount of data involved in creating the projects, and the number of users of the final maps.

Ad Hoc requests are those requests where the type of project fulfills a limited need because the business question the map answers is limited in scope, the amount of data utilized in the map is often small, and the number of users specified on the DPSR is low. The number of maps generated by these requests is lower than other request types (usually only one map). Also, the maps created should be less functional in nature; these maps would require less effort to develop, are usually not refreshed with new data, and are not entered into the data warehouse environment. These types of requests should require only 10% of the GIS Team’s resources.

Static requests are those requests where the type of project fulfills a larger need with a wider scope, the amount of data utilized in the map is larger than Ad Hoc requests, and the number of users specified on the DPSR is higher than Ad Hoc requests. The number of maps generated by these requests is higher than Ad Hoc requests. Also, the maps created have moderate functionality since their use is a static view of data; these maps require more effort than Ad Hoc requests to develop, are usually minimally refreshed with new data, and are entered into the data warehouse development area and possibly the production area. These types of requests should require up to 30% of the GIS Team’s resources.

Dynamic requests are those requests where the type of project fulfills the largest need with the widest scope, the largest amount of data is utilized in the map, and has the largest number of users specified on the DPSR for the organization. These types of requests will generate the most maps of the three types. Also, these maps will have the most advanced functionality since their use is a dynamic view of the organization’s data; these maps require the most effort to develop, are refreshed with current data on a regular schedule, and are entered into the data warehouse development area and then migrated to the production area.

The third responsibility of the GIS team is to move the map to the production environment. Technical projects often develop two logical environments into their work plan. The environments are almost identical in every way, but their uses differ widely. Often, technical staff will store these environments on different servers in order to reduce conflict between applications. The two logical environments are the development (or staging area) and the production environment.

The development environment is a staging area for all new applications and data. Application development requests are processed first in the development environment. This environment possesses an identical structure to the production environment so that developers may test new applications and data without disruption of the normal services in production. Application development and testing may include load balancing, customizing user interfaces, stress testing, and incorporating new data into a previous production unit. No end users have access to the development environment.

The production environment is the final area for all tested applications and data. Finalized applications are stored in the production environment after the appropriate user group signs off on the application or data. End users have access based on their user class to the production environment.

In order to develop the most robust and capable applications GIS development must follow an iterative process. Iteration allows the developers to explore the user’s requirements and culminate those requests into a working application. The ultimate goal of any GIS development project in the Health and Human Services area is to create the most useful application possible that benefits the largest amount of people. In order to attain this goal the GIS development team must follow five phase when approaching a new GIS project.

Strategy is the first phase in the GIS Mapping Solutions Project. The strategy phase determines the scope of work that the project will undertake and defines the goals needed to guarantee success of the project. When the scope and goals are properly defined at the onset of the project the final outcome of the process will better represent the needs of the users. This phase would determine the audience of the mapping solution, the interaction the user group would have with the application, and the means of access for users.

Design is the second phase in the GIS Mapping Solutions Project. Here, the GIS team will determine the detailed user requirements and begin creating the initial view of a mapping solution that meets the requirements. Detailed user requirements are obtained through interaction with user workgroups, but might also come from commonly used documents, frequently used web pages, and internal operational programs. The initial design serves as a high-level guide to the mapping application that will be developed and involves the input from multiple user types.

Develop is the third phase in the GIS Mapping Solutions Project. In this phase the developers will create a fully functional mapping solution that the users will test. This map should adhere to the designs developed in the previous phase.

Deploy is the fourth phase in the GIS Mapping Solutions Project. After developing the mapping solution, the GIS Team will deploy the mapping solution over the internet through a GIS portal communication medium. This portal will give access to the proper user group while providing the necessary functionality determined in the initial phases.

Manage is the fifth phase in the GIS Mapping Solutions Project. In managing the mapping solution the GIS Team can identify any issues that surface through implementation. Training on the mapping solution also comes out of this phase as increased numbers of users interact with the map. Also, the GIS Team will monitor the system for potential enhancements and any change in requirements through interactions with greater technology and the user workgroups. Iteration occurs at every step in the process as the requirements change and the necessary functionality changes.

The examples below are necessary components of any GIS project. The two documents set a generic work plan for each mapping project given to the GIS Team. Also, a phased timeline describes the implementation of GIS initiatives in an organization.

The Pennsylvania Spatial Data Access (PASDA) is Pennsylvania’s official geospatial information clearinghouse and the Commonwealth’s node on the NSDI. The Pennsylvania Geospatial Information Council (PAGIC) is an organization established by a Memorandum of Agreement on June 10, 1999, between the Commonwealth of Pennsylvania agencies, boards and commissions, the Legislative Office of Research Liaison, and participating partners consisting of statewide associations and nonprofit organizations. The Federal Geographic Data Committee (FGDC) coordinates the development of the NSDI that encompasses policies, standards, and procedures for organizations to cooperatively produce and share geographic data. The 17 federal agencies that make up the FGDC are developing the NSDI in cooperation with organizations from state, local and tribal governments, the academic community, and the private sector.

Currently, there are a few States with laws surrounding the realm of GIS. As an example, the State of Texas has very specific laws on GIS information about projection, about metadata, and about map presentation. The State of Pennsylvania has defined several similar laws about GIS information and Deloitte Consulting is committed to following those standards where they exist.

However, there are instances where Deloitte Consulting is assigned to State GIS projects that either do not have standards in place or are not aware that standards exist. In these cases it is imperative that Deloitte Consulting inform the client of the current standards or discuss the creation of standards in the Strategy phase. All shape files used for the mapping projects were projected in the recommended projects as suggested by these governing bodies. Also, metadata collection was based on standards developed by the FGDC.

The Department of Public Welfare for the State of Pennsylvania began creating a Data Warehouse five years ago after realizing that a central repository for welfare information was a necessity. After the creation of that warehouse the State realized that to analyze that information they would need several tools. One of those tools is GIS. Deloitte Consulting found Data Warehouses to be a natural starting point for developing GIS tools for several reasons.

In order to fully understand the methodology Deloitte Consulting used to develop and deploy GIS tools there is a need to describe the framework of the warehouse developed at DPW. Figure X below, diagrams the current environment at the DPW. Included in the diagram are applications not directly associated with GIS, but play a factor in the overall systems design.

Deloitte Consulting’s approach to GIS is evolving with the creation of Enterprise Data Warehouses. Data Warehouses lend themselves well to GIS and Deloitte Consulting found that State clients naturally progressed to a maturity level where they were comfortable with their warehouse and willing to view data in maps. However, Deloitte Consulting does not feel that State governments are compelled to develop an entire Data Warehouse to pursue their GIS efforts. Essentially, any State agency that has a centralized repository of spatial data can implement E-Government GIS solutions.

Integration with the EDW serves as a major boost to GIS development at the DPW. The EDW establishes the initial standards on data quality from every program office that requests a map. These standards reduce the effort on the part of the GIS team to secure data and verify that the information is correct. Two components of the EDW environment lend to a reduced time frame in creating GIS solutions to business questions. These two components combine to generate all the data necessary for developing a mapping solution. The first component is the Development-Production environment currently existing at the DPW. The second component is the user workgroups developed for each Program Office at DPW.

An essential portion of integrating GIS into the Public Sector is the use of geocoding software to maximize the effectiveness of stored address information in the warehouse or another central information repository. Integration of the geocoding software into the Enterprise Data Warehouse operating environment involves individuals that understand the data as well as the proper tools to geocode address information. The DPW team implemented the following strategy for maintaining the accuracy of geocoded address data elements:

HOUSE NUMBER – required information

STREET NUMBER – required information

STREET NAME – required information

ZIP CODE – required information

ZIP+ 4 – relaxed data

The first map described in this paper is the Childcare provider map. The Office of Income Maintenance attended their user group meeting and approached Deloitte Consulting with the task of developing a map that displayed the relative concentrations of Childcare providers in a County view and a Zip code view, while providing the address of these providers as additional information. The GIS development team determined that the views were possible in the same map as scale dependent layers and that ASP pages could be utilized to extract the addresses directly from the warehouse. Set upon the task, the development team began piecing together the location of the data in the warehouse from the workgroup.

The second map described in this paper is the Employment and Training Program (ETP) map. After presentation of the Childcare Provider map, OIM approached Deloitte Consulting with the ETP project. Similar to the Childcare Providers map, the ETP project was concerned with the location of several sites across the State of Pennsylvania. The proposed ETP map would display the relative concentrations of ETP sites in a County view while providing the address of these providers as additional information. The GIS development team determined that ASP pages could be utilized to extract the addresses directly from the warehouse.

The third map described in this paper is Personal Care Homes (PCH) map. The PCH Map represents DPWs maturity in utilizing GIS tools. Similar to the Childcare Providers and ETP map, the PCH project is concerned with the location of several sites across the State of Pennsylvania. The proposed PCH map would display the relative locations of PCH sites across the State. However, the PCH map utilizes two new technologies incorporated to the EDW environment.

The first technology is the Geocoding Software that accepts the address information for Personal Care Homes in the State as input and outputs the geocoded location of the data. The second technology is RouteMap IMS as a mapping tool. RouteMap provides a standard view of data on a map, an ability to find the address and locations of certain data points on the map, and the ability to route between these data points and other addresses on the map.

The Route view shown in figure X allows the user to input addresses into the form and find the Quickest or Shortest routes between the addresses. A user may enter multiple addresses at one time and also may search for other data points added to the map. In the PCH map the user can search and add a start address, then search and add a PCH address, then search and add another address, and possibly search and add another PCH address. Next, the user can press the ‘Find Route’ button and the map will return a mapped route to take with the written directions.

The fourth map described in this paper is the ETP and Childcare Providers RouteMap IMS map. With the release of the newest version of RouteMap IMS came advancement in the capability of Health and Human Services mapping solutions. As seen in previous maps, ETP and Childcare Provider data were displayed in relative concentrations to their county or zip code, while links returned the actual addresses for those providers. Members of the user workgroup were anxious to give users in the community the ability to find the locations of these sites relative to their own address. RouteMap IMS 2.0 allows the capability to enter your own address as a start location, but also map a route to multiple stops from different geocoded data sets.

The ETP and Childcare Providers map gives Internet users (not only DPW Intranet users), the ability to locate their own address as well as the route, distance, time, and directions to multiple ETP sites and Childcare facilities. Also, the GIS Team began to experiment with customization of the RouteMap user interface because the team felt the user workgroups and GIS user population were maturing in their use of maps. The ETP and Childcare Providers map gives a customized view of the information, while retaining all the functionality of the previous maps.

The fifth map described in this paper is the OIM Philadelphia Information map. After the GIS Team developed the Childcare Providers map and the ETP Projects map, OIM users began to mature in their general GIS knowledge and use. On recommendation of the users, the GIS Team was asked to develop a map based on the welfare reimbursement programs of Cash, Food Stamps, and Medical Assistance. Each of these programs contains several sub-categories of information that define the distribution of welfare to recipients in the State of Pennsylvania.

The proposed map for OIM would display one the three programs with the user having the ability to change the measures on the map. The first map, shown in Figure 18 below shows the layout for Philadelphia County. In meeting with the user group and gathering requirements, the user group decided that two views of the data were necessary for the creation of this map. The views are explained in greater detail below.

The initial screen gives the user a choice of data views. On the left of the screen is a pull-down menu that allows the user to choose the view they desire; either Administrative District or Zip Code. Philadelphia County is the only view available so far, because of a large data migration issue. The workgroup decided that an initial view of Philadelphia would be beneficial until the GIS Team could resolve the data issue.

The first view is Administrative Districts as defined by OIM. The shapefile created for this view was developed from the initial zip code shape file on the Esri data CD. Initially, the Administrative Districts were only shown on paper and the shapefile used above needed to be developed.

This view contains three layers to view information based on the program the user wishes to view; Cash, Food Stamps, or Medical Assistance. On every layer there are five measures that change the relative concentrations for the associated Districts in Philadelphia County. These measures are the Number of Cases, the Number of Budgets, the Number of Recipients, the Benefit Issuances, and the Benefit Amount. This view is shown in Figure 19, below.

The second view is Zip Code view of the same area, namely Philadelphia County. The shapefile created for this view was taken from the zip code shape file on the Esri data CD. This view contains the same three layers as the Administrative Districts view and users can view information based on the program they wish; Cash, Food Stamps, or Medical Assistance. On every layer there are five measures that change the relative concentrations for the associated Zip Code in Philadelphia County. These measures are the Number of Cases, the Number of Budgets, the Number of Recipients, the Benefit Issuances, and the Benefit Amount. This view is shown in Figure 20, below.

Documentation is an essential component of the EDW E-government GIS tools. Accompanying the creation of every map are five documents that describe the steps taken to create that map. The documents developed include the Data Extraction Procedures, the Metadata Development, the Customization Documentation, the User Refresh Manual, and the Website Flow Diagram. The development of Documentation serves two main purposes for the Department of Public Welfare. These purposes include the ability to recreate a mapping solution in the event that the map is lost from the system and the transfer of knowledge from Deloitte Consulting practitioners to the client.

The final phase in the creation of e-government solutions coupled with GIS technology is the implementation of a portal. Portals are traditionally defined as information delivery pages or websites. The portal perpetuates the dissemination of information regardless of format or type and integrates this data from multiple sources. Of course, there are many systems that allow for the integration of data, however, portals serve as a ‘one-stop’ delivery mechanism over a system independent medium; the Internet. The strength of a portal lies in the comprehensive integration of all the components in its delivery systems. This includes tools, applications, contents, and other interface features presented on the website.

The most poignant examples of portals in the marketplace are Excite, Yahoo, CNN, or MsNBC. Information from different sources on weather, news, stocks, and consumer products is accessible through a single location tailored to the users’ needs. Comparably, integrated search engines allow these portals to connect to more information sources in a seamless process, thus extending the users’ access from a single location. In the case of GeoSpatial portals such as GISCafe, Geocommunity, or TenLink, information portrayed to users is specific to the GIS industry. These portals include information on data sources, on white papers, on employment, on business news, and on many other areas.

However, portal technology depends heavily on the ability to traffic data into your website so users can use your applications. Accessing, retrieving, and displaying data over a GIS portal is even more dependent on the transfer of data from multiple sources in multiple formats. A technology has emerged in the marketplace that allows an efficient processing and storing of data, usable in all GIS tools. The eXtensible Markup Language (XML) is becoming the foundation for data transfer over the web, including applications in e-commerce. XML allows an organizations to defines the format and type of data they receive/transmit over a common connection while parsers associated with XML allow organizations to process data they receive.

Esri has taken a lead in adapting this technology to their current products. ArcIMS already possesses XML processing capabilities; in fact it is the heart of their current Internet Mapping Server software. AXL files are the Arc eXtensible Language files that describe the shapefiles used in an ArcIMS mapping. These files use properly coded XML tags to define all aspects of a shapefile and parts of its presentation including ramping color, ramping ranges, shapefile location, shapefile fields used, and much more. This link from ArcIMS to XML is the ridge that allows data to be taken from a source to a mapping to a portal.

Currently, E-government portals relay information about government business, including local town meetings, Department of Motor Vehicles Licensing forms, Internal Revenue Service taxing districts, and the proceedings of the last meeting of Congress. However, these portals could include urban planning maps, zoning regulation maps, location and direction to Childcare Providers in your area, concentration of Health Maintenance Organizations (HMOs) across your State, and much more. Portals will also include further interactive components that allow citizens to pay taxes, collect information on unemployment, and provide feedback to their local or state government entities. However, E-government portals with GIS components allow the dissemination of spatial information in addition to more common textual/content information. Maps provide a strong visual approach in providing effective information.

After carefully examining the mapping needs of different Program offices like the OCYFS, OMR, and OIM, it became clear to the GIS team to define and design the GIS portal for the Pennsylvania Department of Public Welfare that would encompass all the unique information delivery requirement of the different program offices.

OCYFS was primarily concerned in identifying day-care centers, licensing facilities such as retirement and nursing homes in order to determine optimum routes to and from a facility. The RouteMap application software would have to be integrated for this purpose within the portal. On the other hand, OIM spatial data requirement meant display through polygon thematic maps information on the disbursement of welfare funds by County and Region. OMR (Office of Mental Retardation) required maps that provided a percentage count on medical provides by region and county with the Commonwealth of Pennsylvania. Both these mapping applications required ArcIMS incorporation within the Portal.

The design of the portal would include assigning unique id (Identification Numbers - based on type of mapping project request and the Program Office) for each of the different program offices and making the data readily available after request are made through the use of DPSR (Data Processing Service Request). The DPSR forms would also be an integral part of this GIS portal, shown in Figure X below. Thus users from the respective Program Office’s will be able access their maps (created in either ArcIMS or RouteMap IMS) for any kind of data analysis, statistical evaluations, or preparing a general report. These reports could be created using different parameters and different spatial references (at the Regional, the County, or the State level).