The City of Chicago has developed an automated system to facilitate the issuance of liquor licenses. Two ArcIMS applications were developed for this purpose: the "Moratorium Module" that determines whether an applicant address is restricted for certain types of liquor licenses; and the "Voter Notification Module" that automatically identifies all registered voters living within a fixed radius of the proposed license site and sends them a notification postcard. This new, automated system offers a number of advantages over the previous paper-based methodology including higher overall accuracy in identifying potentially affected voters and a dramatic reduction in the time required to carry out the licensing process.
Obtaining a license to sell liquor in the City of Chicago requires a two-part validation process. In the first step, City staff must determine whether a proposed licensed location falls within one of the many areas within the City that are restricted for various types of liquor sale by statute. In the event that an application passes these restriction checks, the City must then notify all registered voters within 250 feet of the proposed license location to offer them an opportunity to contest the license issuance. This process is inherently spatial in nature, in that the restrictions themselves can be described spatially as can the proximity of registered voters to any location in the City. In a recent project, staff from the City of Chicago Department of Business and Information Services in conjunction with Pangaea Information Technologies automated the issuance of liquor licenses in the City through the development and implementation of ArcIMS-based "GIS Liquor Modules."
The sale of liquor is restricted in many parts of the City of Chicago. Before the implementation of the GIS Liquor Modules application suite, when a liquor license applicant requested to know whether a proposed site was located in a restricted area, City personnel looked up the information in the City's ordinances dealing with liquor. A restriction in a ward reads like a legal description as follows:
Restriction 12:46 (meaning, 12th ward, the 46th restriction made in that ward): On Bross Avenue, from Western Boulevard to Artesian Avenue; and on Artesian Avenue, from Bross Avenue to 34th Street; and on 34th Street, from Western Boulevard to Artesian.
These ordinances are approximately 500 pages in length, and many restrictions are considerably more complex than the example provided above. Checking these restrictions was very time consuming because the document is not indexed, and once the staff found the correct ward for an application, they would need to read every restriction in the ward, as the restrictions are not organized by streets or neighborhoods within the wards. Checking these restrictions manually often required up to one hour to complete, typically while the client was sitting in the Department of Revenue waiting for a response from City staff. Considering that hundreds of applications are presented to the City each year, processing these license requests required considerable effort by Department staff.
There are also restrictions in the City referred to as "Vote Dry" areas, where the sale of liquor in an area is restricted after the passing of legislation in a general election. These areas, unlike the moratorium restrictions, apply to large blocks of land within the City (i.e.: a city block, portions of a precinct or ward, etc.). While these restrictions were typically easier to interpret and utilize in the manual restriction check process, the checks were similarly completed by using paper maps and a printed copy of the ordinance.
The restrictions themselves are dynamic in nature. New restrictions are proposed and passed every month, and license application staff previously did not have access to this information until passage and the subsequent printing of a new ordinance section or a memo with the new restrictions listed. One of the key components of this automation project, then, was to develop a semi-automated methodology for capturing this information as it is updated in the ordinance documentation, and making it immediately available to the liquor licensing system. This necessitated the development of the "Moratorium Update Application" that is described in more detail below.
Assuming that these moratorium checks determine that a proposed license location is not restricted, all voters living with in 250 feet of the location must be notified of the proposed site. The original process, shown in Figure 1 below, was extremely cumbersome, and required input and assistance from a number of City departments. Prior to the deployment of the GIS Liquor Modules, the applicant was required to take the following steps to complete the voter notification process:
Obviously, this process was extremely laborious, and would benefit greatly from automation of some or all components using GIS technology. The function of voter notification was previously semi-automated with a standalone ArcView 3.x application that had several drawbacks: 1) the system was not integrated with the City Integrated Revenue Information System (IRIS) that tracks all City business licenses, and could only be used by one person; 2) it only approximated the location of the site; (3) there was no ability to process an address range (i.e.: 14 - 18 E Jackson Blvd.); and 4) maintaining the data for the application was extremely cumbersome, so frequently, out-of-date voter information was used.
Figure 1 below summarizes the manual processes used for both moratorium restriction checks and voter notification in the City.
The overall goal of this project was to automate these processes using GIS technologies. To ensure the widest possible availability of the applications throughout the City IT enterprise, we chose to develop the applications using ArcIMS as the main server side component. All development was carried out using JSP and Java servlet technologies (using Tomcat and Apache application and web servers, respectively). The applications feature direct integration (via JDBC) with the Integrated Revenue Information System (IRIS), a large, complex Oracle Forms application used by the Department of Revenue to maintain all license information for the City. The system is also integrated with the City's mainframe computer (via FTP) which is used for the printing of notification postcards.
To address the issue of accessing the liquor restriction information in an efficient and timely manner, the restrictions were converted from the City's paper ordinances to digital formats so that they could be used by GIS software. Altogether nearly 10,000 ordinances were converted, and stored as three separate GIS layers. With these converted layers in place, we developed an ArcIMS application that would allow City staff to quickly and easily determine whether license applications fall in these restricted areas, and present this information to the applicants as required.
There are four basic processing steps involved in the program flow of the Moratorium Module:
This application processing logic was implemented in the Moratorium Module, which was developed using JSP and Java Servlets. The following screen shots provide an example showing the processing of a liquor license for an address in the City:
When the Moratorium Module is invoked from within IRIS, the user is presented with a web page that is pre-filled with data from the IRIS database. Alternatively, this license information can be entered into the web form by hand.
The site address is geocoded (shown in red above), and a map is displayed showing the surrounding region. In this instance, the license location lies within a "vote dry" zone (shown in yellow). Moratorium restrictions are also in force on the facing street (red dots). Schools are shown shaded in purple. Liquor licenses are not issued within 100 feet of a school.
The user is then able to select the most relevant license restriction (if any) that relate to the application, thus providing a reason for denial of the liquor license.
As a final step, if the user invoked the Moratorium Module through IRIS, the selected restriction information is updated in the IRIS database and displayed on the IRIS form for that particular business. The application supports any number of records describing results from moratorium checks to be inserted into the database.
An ArcView 8 application (the Moratorium Update Application) was developed to assist end users with maintaining the data. This application allows the Mayor's Liquor Commission staff to update restriction information as soon as it is passed by City Council. Department of Revenue staff who are reviewing the license applications for restrictions thus get the benefit of more immediate information.
The application is designed so that with little experience or training, novice ArcView users are able to easily update the moratorium restrictions in a short amount of time. All functionality of the program was developed using Visual Basic for Applications, and is accessible through a number of functions stored within an ArcMap document. This includes a simplified interface for searching for existing restrictions, making editing changes or inserting new ones, and for quality control purposes in terms of feature attribution.
There are four basic processing steps involved in the program flow of the Voter Notification Module:
This business logic was implemented in the VNM using a combination of JSP and Java Servlet coding. The following screens provide an example of the VNM in use for a sample address:
When the Voter Notification Module is invoked from the IRIS application, the user is presented with a web page containing pre-filled license data from the IRIS database.
The site address is located and displayed on the map (highlighted in red). The user must then select the buffer radius to be used for finding buildings. The value is set to default at the legal 250 feet, but the user is given the option to change this width if necessary.
A buffer around the geocoded building is created, and the buildings within or partially within the buffer are highlighted.
The user can then generate a report listing the voters living at the selected buildings. The report is available immediately so that it can be reviewed prior to sending notification cards. Previously, the report was generated on the mainframe, and users had to wait until the next day to see the list of voters being notified.
As a final step, the IRIS database is updated with a variety of information, including the number of voter notification cards printed and the buffer distance used in the building selection. Multiple runs of the voter notification process are supported.
With the new system in place, the Department of Revenue and the Mayor's Liquor License Commission have much more confidence that the list of registered voters to be notified is complete and accurate. In the past, the customary radius used for identifying registered voters was 350 feet, even though by ordinance, a radius for 250 feet was required. This was done because the previous method utilized somewhat inaccurate geocoding methods, and the City determined that because of this, a choice would be made towards over-notifying rather than under-notifying voters. However, increasing the number of voters notified increases paper and postage costs. With the new system, there is confidence that the list of identified voters is complete using the 250 feet radius and the City saves money.
Determining whether a proposed liquor establishment site fell within a moratorium or vote dry area used to be a very time consuming task. Each Business Services case managers had his/her own map and would manually find the proposed site on the map to determine if the site was located in a restricted area. If the site was located in the middle of the restricted area, the task was fairly straightforward. If the site was located on a boundary, the determination was more difficult to make and often resulted in phone calls to the Mayor's Liquor License Commission for verification. This could take up to a half hour to confirm the restriction and usually took place while the applicant was sitting in the office waiting for resolution. It was also time consuming to update each map whenever the moratorium or vote dry boundaries changed. The new system is updated with moratorium or vote dry changes in one place that all business users can access and the determination of whether or not a proposed site falls within a restricted area is performed within seconds.
More generally, the system has had a number of impacts on overall productivity for City staff, including the following:
In summary, the development and implementation of the City of Chicago's GIS Liquor Modules has provided a number of important benefits. By integrating a number of disparate enterprise systems and databases, the modules allow users to leverage the City's extensive enterprise GIS without requiring any significant training or understanding of the underlying technologies. This project was considered to be highly successful in that it used GIS to greatly improve business processes within a very large organization without requiring significant training or hardware / software procurement. The following is a partial list of the benefits that have been realized to date:
A number of City and contractor staff contributed to the development and deployment of the GIS Liquor Modules. We are grateful for their contributions, and would particularly like to recognize the following people and organizations.
Jerry Johnston
Vice President
Pangaea Information Technologies, Ltd.
14 E. Jackson Boulevard
Suite 1325
Chicago, Illinois 60604
Telephone: 312-986-9471
Fax: 312-986-9477
E-mail: jjohnston@pangaeatech.com
Kauser Razvi
GIS Project Director
Department of Business and Information Services
City of Chicago
E-mail: kravzi@cityofchicago.org
Anna Fan
GIS Application Developer
GIS Project Director
Department of Business and Information Services
City of Chicago
E-mail: afan@cityofchicago.org