A Java Public Participation GIS ... - University of Leeds · Internet GIS and the application of...

Tim Waters MSc GIS Dissertation 1

A Java Public Participation GIS Using a Spray CanTool for an Investigation on the Perception of Crime

in Leeds.

Timothy Waters

September 2002

A dissertation submitted in partial fulfillment of the requirements of the

Masters Degree in Geographical Information Systems of the University of

Leeds.


AbstractA Java web-based public participation GIS was developed using a spray-can tool, a

feature familiar from many graphics programs. Internet GIS and the application of

web-based public participation GIS are reviewed. The spray-can tool enables users to

spray areas of interest on map, with the ability to weight areas using the intensity of

the spray. Users can attach comments to their inputs. The research, design and

development of the system is described in detail. The system is applied to a study on

the perception of crime in Leeds. Background on fear of crime and previous public

perception studies are reviewed. The case-study’s results indicate that the composite

view of where in Leeds has the most crime matched official data quite well. Feedback

received was very positive, with people finding the system very easy and intuitive to

use. A discussion of the limitations of the system and recommendations for further

study is given.


Acknowledgements

The author wishes to thank his tutor, Dr Andy Evans for help and support throughout

the project, the user testers whose valuable comments and inputs helped shape and

refine the system, James Debenham for providing Leeds crime data and Leeds

Community Safety Partnership.


ContentsAbstract............................................................................................................................... 2

Acknowledgements ............................................................................................................. 3

List of Figures...................................................................................................................... 5

Chapter 1. Introduction........................................................................................................ 6

PART A: Background and Literature Review .................................................................. 7

Chapter 2. Internet GIS ....................................................................................................... 8

Chapter 3. Public Participation GIS ................................................................................... 12

Chapter 4. Web-based Public Participation GIS ................................................................ 13

Chapter 5. Key Issues of Web-based PPGIS ................................................................... 20

PART B: Software Development .................................................................................... 22

Chapter 6. Development Process..................................................................................... 22

Chapter 7. Requirement Specification ............................................................................... 24

Chapter 8. Research ....................................................................................................... 26

Chapter 9. Phase 1: Analysis. .......................................................................................... 32

Chapter 10. Phase 2: Design ........................................................................................... 39

Chapter 11. Phase 3: implementation .............................................................................. 52

Chapter 12. Phase 4: Testing.......................................................................................... 56

Chapter 13. Phase 5: Deployment................................................................................... 58

Chapter 14. Software Description and Process ................................................................ 59

PART C: Case Study ....................................................................................................... 65

Chapter 15. Application to a Study on Public Perception of Crime in Leeds ...................... 65

Chapter 16. Crime in Leeds.............................................................................................. 76

Chapter 17. Case Study. .................................................................................................. 80

PART D: Discussion and Conclusions .......................................................................... 90

Chapter 18. Discussion, Limitatations and Improvements ................................................ 90

Chapter 19. Conclusions .................................................................................................. 93

Bibliography ...................................................................................................................... 94

Appendices ....................................................................................................................... 97

Java Code Listings……………….99

Perl CGI Listings……………….. 134

Log Files…………………..…..… 139

Webpagses……………………... 144

JavaDocs…… …… ………. 164


List of FiguresFigure 2.1 HTML ImageMap : Asthma Occurrences 9Figure 2.2 Example of MapInfo’s MapXtreme IMS 10Figure 2.3 AutoDesk’s MapGuide Lite example 10Figure 2.4 Two Examples of ESRI’s – ArcIMS 11

Figure 3.1 Five Stage Ladder of Participation 12

Figure 4.1 Bradford Community Statistics GIS 15Figure 4.2 A Virtual Slaithwaite PPGIS 17Figure 4.3 Yorkshire Dales Woodland Online Decision System 18Figure 4.4 Online GIS for Chicago 19Figure 6.1 Waterfall Model with Iterations 22Figure 7.1 Use Case 1 25Figure 7.2 Use Case 2 26

Figure 8.1 Sources for research of different spray types 27Figure 8.2 Two Types of Spray 28Figure 8.2 Three Possible Vector Approaches 30Figure 8.3 Raster Data Model & density image 31

Figure 9.1 Conceptual UML 32Figure 9.2 Two Initial Types of Spray Distributions 37Figure 9.3 User Testing of Spray Types 39

Figure 10.1 UML Input Applet – Sprayer 40Figure 10.2 UML for Output Applet – QuerySpray 41Figure 10.3 Example of sum kernel operation 42Figure 10.4 Example of different kernel sizes. 43Figure 10.5 Example of sub-sampling to reduce file sizes 48Figure 10.6 Sorting Algorithm 50

Figure 14.1 screenshot of Sprayer GUI and Webpage 59Figure 14.2 Screenshot of QuerySpray GUI and WebPage. 62

Figure 15.1 Map of Fear in Warsaw, Poland. 70Figure 15.2 Los Angeles County. Fear and comfort 72Figure 15.3 Areas of Comfort and Areas of Fear. UBC 74

Figure 16.1 Levels of Crime by Type in Leeds 76Figure 16.2 Crime Rate per 1000 Population 77Figure 16.3 Domestic Burgularies 2000-2001 78Figure 16.4 Vehicle Crime 2000-2001 78

Figure 17.1 Input Page (with Sprayer applet) 81Figure 17.2 Results Page (with querySpray applet) 82Figure 17.3 Age Ranges 83Figure 17.4 Occupations 83Figure 17.3 Examples of User Spray Inputs 84Figure 17.4 Perceived Crime in Leeds and actual Crime 86Figure 17.5 Answers to Feedback Questions 88


Chapter 1. Introduction

Geographical information systems (GIS) can be used in facilitating public participation

in decision making processes (PPGIS). To some extent the increasing use of GIS by

more people invalidates the claim that GIS is an elitist technology (Pickles, 1995).

One of the key issues with using PPGIS is to be able to enter, store and process the

often qualitative, fuzzy, knowledge that the human mind has. Often this type of

information does not fit easily with traditional GIS data structures. This study seeks to

facilitate the capture of such fuzzy knowledge into the context of a PPGIS. Written in

Java, a system is developed whereby, using a spray-can tool (familiar from graphics

programs) and typing comments, a user can easily input such information. Two

applets and a website utilising Perl CGI scripts were written. Arithmetic raster and

image processing operations are used to capture a users input and make a composite

image of everyone’s inputs. The system is applied with a case-study on crime in

Leeds. By using the system, users can define the spatial extent of their chosen areas,

any differences with these areas, and comments attached to these areas. Users can

then view a composite map of everyone’s inputs and read comments.

This study is arranged into four parts and nineteen chapters.

The first part, Part A, gives a review and a background of Web-based GIS, Public

Participation and the role the Web-Based PPGIS can have. Several examples are

presented and key issues are examined.

Part B, describes the software development process, from defining the requirements,

through research, testing and deployment. Figures and UML diagrams help explain

the workings and main functions of the applets.

Part C, sees the system applied to an examination of the perception of crime in

Leeds, West Yorkshire, with studies on the perception and fear of crime reviewed.

The methodology of the case-study is presented, with results and a discussion

following.

In the light of the case-study and development process, Part D concludes the report

by reviewing the system, highlighting limitations and recommending improvements.


PART A: Background and Literature Review

With the rapid development of the Internet and the almost obligatory web-presence of

all major institutions and businesses, it was inevitable that GIS also moved onto the

web. Geographical data and maps have been present on the Internet for a while,

although these have generally been static. However, it is only relatively recently,

within the last 5 years, (and parallel with the establishment of major GIS players in the

Desktop PC market) that real “web-based GIS” have occurred. Web-based GIS

comes in many flavours, from static map servers, through to systems that allow some

spatial analysis to a fully functional GIS with scope for user input. Making GIS

available to so many people over the medium of the Internet to some extent

invalidates the claim that GIS is an elitist technology (Pickles, 1995). Taken a few

stages further, web-based GIS can be used in the public participation of decision

making process. These web-based Public Participation Geographical Information

Systems (PPGIS) have many advantages over traditional methods of public

participation.

These key themes and concepts behind the aim of this piece of research are explored

within this section. Chapter 2 briefly reviews Internet GIS. Chapter 3 gives an

overview of PPGIS. Slightly more attention is given in Chapter 4 with a look at Web-

based PPGIS, some examples, and an exploration of some issues relating to web-

based PPGIS.


Chapter 2. Internet GIS

The major software vendors of the desktop GIS scene have all produced packages for

the Internet. The most common of these are ESRI with its ArcIMS (Internet Map

Server), MapInfo has MapXtreme and AutoDesk with MapGuide. Other Internet GIS

systems are based on Java applets, such as the GeoTools (McGill, 2001) package,

whilst some utilize standard HTML imagemaps. Brandon (1997) provides a good

review of the various software packages and system designs, and provides a

comparison between different packages.

The various online-GIS have different levels of functionality. Some are simple map

viewers, with pan and zoom tools. Some allows the selection of features.

Some allows modification of different layers. Others allow simple spatial analysis

operations, like “how big is this area”, “how may people live there” etc. And some

allow the addition of data from the user.


Web-GIS Examples

An example using HTML image maps to display and query data is shown in Figure

2.1. It was created with the help of ArcView desktop GIS. Users can view maps at a

variety of scales, on a number of topics –in this case, asthma occurrences. When

users click on the points, or polygons, a HTML link opens up in a frame window.

An example of MapInfo’s MapXtreme Internet Map Server is displayed in Figure 2.2.

This example is taken from the Baseline Business Geographics website

(www.baselinegeo.com). The application allows the user to choose a map or different

regions. Users can navigate around the map, switch features on and off, search for

Figure 2.1 HTML ImageMap : Asthma Occurrenceshttp://www.crp.cornell.edu/projects/WebGIS_2000/Ironbound/maps/imagemapper/index.asp?dir=asthma occurrence


features and addressees, select by radius and retrieve attribute information about

selected features. Additional MapXtreme functions include geocoding, the creation of

thematic maps and the exporting of the final map as a JPEG.

An example of AutoDesk’s

MapGuide is presented in

Figure 2.3. Here a DWG

CAD map is used to guide

users around the map of a

building.

Users can perform simple

spatial analysis’s, turn layers

on or off.

Fig 2.2: Example of MapInfo’s MapXtreme IMS

Fig 2.3 AutoDesk’s MapGuide Lite example fromfromhttp://www.autodesk.co.uk/adsk/section/0,,960547-


An Example of ESRI’s ArcIMS is given in Figure 2.4. Fig2.4b displays a Java version

with querying, graphics (users can write and draw on map), gazette, and the ability to

turn layers on and off.

Fig 2.4: Two Examples of ESRI’s - ArcIMS


Chapter 3. Public Participation GIS

Levels of ParticipationAs Kingston (2002) points out that although there may be statutory requirement for

public participation in the planning process, it is usually limited to a fairly basic level of

participation. “This more often than not allows the public the right to know about what

is happening and a right to object but there is often very little participation in the real

decisions.” Kingston, 2002.

There are several levels of participation, Carver et al, (1998) developed an 5-stage

ladder representing the levels of involvement available; See Figure 3.1

Traditional public participation processes reach level 3 of the ladder. Web-based

PPGIS has the potential to reach the top.

.

Figure 3.1: Five Stage Ladder of Participation (Carver et al 1998)


Chapter 4. Web-based Public Participation GIS

Comparing Traditional and Web-Based Public ParticipationWithin the sphere of planning, some form of public participation has been present in

the UK since the 1940s. Participation, mainly in form of written objections, usually

occur in the later stages of the planning process. The British planning system is based

on the concept that the planning authority acts on behalf of the public in the publics

interest, contrasted with the US where participation is mainly concerned with resolving

conflict between private developers and the public (Chillingworth, 1993). Thus in the UK,

participative approaches to local planning occur, but they are not mandatory and

procedural participation is still viewed as the main mechanism for public participation.

(Haklay and Harrison, 2002).

The traditional method of public participation in the UK planning process and the

advantages of the use of the Internet has been discussed by Kingston et.al (2000), and

are summarised below.

The main disadvantages of the traditional method include:

� Meetings are held at specific times, often in the evening. This can exclude groups

of people for whom the evening is inconvenient.

� Meetings are held in one location, and people have to travel. Transport costs in

time and money can be high, especially for those in rural area with cars. People

from outside of the area, but with a vested interest in the process are unable to

participate.

� A vocal minority or pressure group may dominate meetings. They are often in a

confrontational atmosphere. Less vocal people or groups may be dominated by the

more vocal.

� Meetings are often highly structures, with a visible (possible intimidating) authority

controlling proceedings. People have to “learn the language” of meetings before

they are can participate fully.

� The language used can be very technical.


In contrast the use of the web-based PPGIS brings several advantages:

� The system and background information can be accessed at any time, day or

night.

� The system is not geographically constrained. It can be accessed anywhere with

access to a computer – at work, school, libraries, Internet cafes. People living

outside of the area can also participate.

� People can express their views in a relatively anonymous and non-confrontational

manner. There can be no “shouting down” by vocal groups.

� Generally more unstructured, the consultation process can be tailored for the

public and not the authority.

� Whilst it may be required that complex concepts be understood for a properly

informed decision, an online system can be used to convey this information to help

educate users, in their own time, and terms.

GIS as an Elitist TechnologyIn John Pickles’s book Ground Truth (1995) he explored the nature of GIS and

society. He stated that “the development and application of GIS have rarely been

treated as having serious political and social implications”, with a criticism that the use

of GIS by those with power can be used to effectively keep those power-relationships

in place. In other words, GIS is an elitist anti-democratic technology.

Ghose (2001) comments that this is because of “the technological complexity and

cost”. It is likely that this is also an effect of the emergent nature of GIS – as the

technology becomes more prevalent, its user base, and technological complexity

would be broadened. If knowledge is power, keeping the information with an elite

does nothing to help the “digital divide” - the divide between those with knowledge

and those without. Indeed it is with these criticisms that several PPGIS studies have

emerged, to bring about an empowerment and betterment for marginalized

communities.


The sharing of information is to be welcomed. Indeed as Ghose (2001) points out, “the

inclusion of residents in information gathering, policy study and policy formation hardly

requires argument – it benefits agencies just as much as residents by making them

partners rather than adversaries.” Thus it is in the policy-makers interest to encourage

and adopt PPGIS, regardless of actual political will on the streets”. The use of the

Internet can only make this adoption easier. It may also increase people’s involvement

in local decisions and democracy.

Examples of Web-based PPGISFour examples web-based PPGIS are given:

Bradford Community Statistics Project, http://www.bcsp-web.org/ has a GIS where

users have access to local information, the ability to browse and zoom etc, all

Figure 4.1 Bradford Community Statistics GIS


standard web-GIS tools. What makes the system participatory is the ability for the

user to draw areas with the mouse and access statistics relating to the area.

Registered users can save these areas and access them later. It also allows feedback

on the areas to be sent. It was set up using AutoDesk. Figure 4.1 show a screenshot

of it in use.

A Virtual Slaithwaite, (http://www.ccg.leeds.ac.uk/slaithwaite/) developed by the

School of Geography, University Of Leeds, with a Java package called GeoTools,

gives residents a map of their village (figure 4.2). Users can view information by

clicking on the shapes, and add comments regarding that feature. Comments can be

added to the map, and users can view the map of the village with people’s comments

on it.

Another example developed by the School of Geography, University Of Leeds, is

designed to enable people to participate in where in the Yorkshire Dales new

woodland should be planted (Figure 4.3) Users go through fourteen pages, setting

various constraints and weights for factors such as “proximity to existing woodland”.

Each page is presented with detailed information and links to more technical

background information. At the end, users see the composite map of their choices,

and are able to alter parameters again.


Fig 4.2 A Virtual Slaithwaite PPGIShttp://www.ccg.leeds.ac.uk/slaithwaite/)


Fig 4.3 Yorkshire Dales Woodland Online Decision System


Al-Kodmany (2001) describes a system for investigating people’s view on the

neighbourhood of Pilson, Chicago using a PPGIS (fig. 4.4). Users can say if they liked or

disliked a particular neighbourhood block. This enabled planners to identify areas for

improvement.

It is within this context of using web-GIS with tools that facilitate user input, that web-GIS

have been used in public participation processes (Web-based PPGIS). Indeed the

applets and system of this study has been designed especially for user input in a public

participation environment.

Figure 4.4 Online GIS for Chicago incorporating aerial photography and

requesting user feedback from Al-Kodmany (2001)


Chapter 5. Key Issues of Web-based PPGIS

Public Perception, Mental Maps and PPGISCinderby (1999) describes a PPGIS within the Namaqualand area (Northern Cape,

South Africa). It used perceptual or mental maps within a GIS. By overlaying peoples’

mental maps of the local conditions, differing perceptions of the importance or varying

access rights to resources and potential areas of conflict were detected.

Perceptual maps contain information unobtainable from other sources. This can provide

insight into the varying perceptions of a resource by different sectors in a community.

“For example, an area of average grazing land was found to have physical conditions

that should have classified it as good grazing according to a satellite assessment.

However, the mental maps showed the area to be perceived as prone to jackal attacks

on livestock. This factor had reduced its attractiveness to the herders. This type of

information is unavailable on traditional spatial data sets.” Cinderby (1999)

A potential problem pointed out was, in order to facilitate mental maps in a GIS, some

kind of geo-referenced base map has to be utilized. This technique may force a certain

view of the world on the surveyed group. Constraining people in this way may reduce or

restrict what they would discuss if they had been given a blank sheet to draw on

(Cinderby, 1999).

One of the main key points with PPGIS involves the access to technology. Dubbed the

“Digital Divide”, there is a risk of isolating those people without access to computers or

the Internet. There is also the question of the need for users to have appropriate IT skills

or even understand rudimentary GIS techniques. Other key points in the success of a

web-based PPGIS is the design of the system, related to Human-Computer Interface

(HCI) studies, the design of the GIS and its supporting web-site can make all the

difference. Should maps be simplified? What level of detail should be used in the maps?

How much labeling should there be on the maps? Another key issue with PPGIS is the

establishment of trust. If users do not trust the hosting body, or are skeptical about the

use that their input is going to have, it can jeopardize the worth of the study. People want

to be able to make sure that their input is going to be used to make real changes.


Conclusion for the sectionIn this section, a review of Internet GIS has been presented. Public-Participation GIS

has been introduced and the use of the Internet and Web PPGIS have been examined.

Some systems have different levels of user participation. Some key issues relating to the

operation of a Web-GIS have been covered. The concepts and issues presented in the

preceding section will be discussed with relevance to the system of this study in an

application looking at peoples perception of crime in Leeds, West Yorkshire (see Part C).

The development, research and design of the code for this system is explored in the

next section.


PART B: Software DevelopmentChapter 6. Development Process

Classical software development models include the Waterfall Model, where after each

phase is completed (Analysis, design, testing etc), the work would “spill” over into the

next phase. I used a variant of this: the Waterfall Model with Iterations and some

Forward Looking Steps, outlined in Figure 6.1 (Horstman, 2000)

Th

e

mo

del

allo

ws

the

dev

elo

pm

ent

pro

ces

s to

flo

w

ahead, but also to correct errors, (through iterations), at all stages. It also has small

steps into the next phase. The model provides a clear structure for the development and

description of the development of the system in this report.

The development process described in the following sections should not be viewed as

absolutely temporally linear, as iterations refine and amend previous stages. However, in

software development, so long as the trend if for later iterations to produce fewer

changes than earlier iterations, iterations should be viewed as part of the normal

Analysis

Testing

Implementation

Design

Deployment

1st Prototype

System Prototype

Unit Testing

Figure 6.1: Waterfall Model with Iterations and Small Forward Steps, adaptedfrom Horstmann, C. (2000)

Research

Requirements


development process (Grand, 1998). The structure for writing the requirements and use

cases have been developed from Grand’s book, Design Patterns in Java (1998).


Chapter 7. Requirement Specification

Prior to the conceptual phase, a Requirements Specification was produced. Specifying

the requirements at this early stage gives an overall vision for the development process

and made explicit the main actions required. The requirements were:

1. A web-based public participation GIS system whereby, through the use of a“spray-can”, users can specify areas of interest onto a map.

a. Users should be able to change intensities or density of spraying.b. Users should be able to input different areas if necessary

2. Users can attach comments to their inputs.

3. There should also be some form of composite map where users can viewthe results of all users.

a. All comments should also be able to be viewed.b. Sprayed inputs and comments should be linked when click on output

map.c. Comments should be sorted according to density.


Figure 7.1 Use Case 1

Essential Use CasesA use case describes the pattern of events that occur during a certain time between the

system and “actors”. Actors are generally human: users, system administrators, etc.

Two main “high-level” use cases were developed. High level use cases help define the

specifications without requiring knowledge about how it should work. Use cases can also

help in building up a more object-orientated design of the system, as will be described in

a later section.

Use case 1:Use case: User input

Actor: Member of public

Purpose: Show areas of importance

Synopsis: User sprays on map areas and/or types comments. System records

data.

Fulfils: Requirements 1, 2.

This use case is also displayed as a diagram (Fig. 7.1) Here a user interacts with the

system, spraying on a given map. The system records the spraying and any comments.

The system also needs to save these to produce a composite map for later.

Use case 2: Results query

Actor: Member of public

Purpose: To see composite map of all inputs


Figure 7.2: Use Case 2

Synopsis: User views composite map and by clicking views comments.

Fulfils: Requirements 3, 3a, 3b.

Figure 7.2 displays this use case. Here a user can view a composite map of all users.

The system provides the composite map. They can also view comments typed by

previous users by clicking on the relevant areas of the map.

The above two use cases give the most common and essential uses of the system.

When looked at with the specifications, some requirements, for example that users

should be able to alter the density of their inputs, or that the system should sort

comments based on relative densities, are not included in the use cases. This is

because these are lower level use cases, and will be explored in later sections.

In this section, the requirements of the system were given, together with some initial

high-level use cases. The next section concerns itself with the background research and

the concept of the system.

Chapter 8. Research


Some applications that

were looked at that had a

spray-can or airbrush tool

included Adobe

PhotoShop 5.5, MS Paint,

and some simple web-

based sketchpads. (Fig

8.1) They all had different

characteristics. Some

sprayed the same

random dots at each click

– some rotated between 4

different types of dot

patterns. Some applications, as we shall see, used a more even way of spraying, as

opposed to the speckled spraying. Some sprayed paint as a square, circular or irregular

pattern. Some (like PhotoShop) sprayed paint that grew outwards as one sprayed, whilst

most remained constrained to an area. In terms of action, some did not continue

spraying when the mouse was down, but not dragging, others when the mouse was

dragged but not stationary. These differences were explored and tested within Java to

find the best one and is explored in a later section.

Spray intensities:There are two main types of spray, as illustrated using the Adobe PhotoShop airbrush

tool (Fig 8.2). The “normal” type where paint is sprayed evenly over the background, and

where adding more paint to an area changes the saturation of the pixels to form an

image with different intensities.

The second type (a more traditional spray occurring in MS Paint ) “dissolve” is where

each spray paints an area with random dots over the background. Adding more paint to

an area fills in the gaps, making the image appear darker.

Figure 8.1 Some of the sources for research of different

spray types: PhotoShop, MS Paint, Spray types, other


Figure 8.2: Two Types of Spray

1:“Normal”

2. “Dissolve”

It can also be seen that the normal type has a measure of intensity built into the pixels of

the image itself. The “dissolve” method, whilst appearing to contain information about the

intensities, does not. Each pixel is either paint or background – further processing would

need to be done to convert this Boolean image to an image of intensities.

Visually, and practically, the second, speckled method seemed more easier to control in

spraying, as it seems as if the eye is able to evaluate relative intensities with varying

numbers of dots on a background easier. Thus this second type was chosen for user

input with an algorithm to change these values into a density image after inputting.


DATA MODELFrom the requirements, the system must be able to record a users spraying, and also

facilitate the change in intensities. When a user holds down the mouse button, the spray

paints more - it increases in intensity. A data model should therefore be able to record

both the spatial extent and any variation in intensities.

Traditional GIS data models include the vector and raster data models. A vector data

model “represents space as a series of discrete entity-defined point, line or polygon units

which are geographically referenced.” (Burrough and McDonnell, 1998) The raster data

model is composed of a regular tessellation or grid of cells (or pixels). These grid cells

each have a value that represents a particular attribute.

The vector data model was examined for its suitability. A “Point” could represent each

drop of paint. Intensities could then be calculated by how many points were in each area

(Fig 8.2a). Alternatively, a polygon could be created around the perimeter of the defined

areas, with attribute information representing the intensities (Fig 8.2b). In a complex map

of varying intensities, there would be many polygons overlaying each other. Another

vector method, commonly used by some Vector-based graphics programs is the use of a

“path” – a variation of an arc or line, (Fig 8.2c). A path would be able to record where

the user has clicked and dragged the mouse, spraying on the map. At spaced intervals

along this path, intensities as a function of time or speed (slower mouse movements

increase intensities) would be recorded. This would be spaced at intervals of time or

distance, similar to “stream mode” found on map digitising software.

Fig 8.2: Three Possible Vector Approaches


Another possible data model was looked at. This, field-orientated approach is outlined in

a paper by Laurini and Pariente (1996) “Towards a Field-orientated Language: First

Specifications”. They outline a methodology for utilizing object-orientation to represent

continuous fields (such as temperature, rainfall, wind speed etc). Zones are crisp entities

defined by boundaries polygons, and contain a number of sample points that enable the

interpolation of the continuous field, the objects can also contain lines that represent

discontinuities or barriers.

For this application, using the field-orientated approach, each sprayed area would be

given a boundary (polygon) and a number of points inside that polygon that represented

the intensity at that point. When reconstituting the saved area, a interpolation method

would be employed that takes into account edge effects. The third data model examined

was the raster data model. Ideally suited for continuous fields, for example the change in

intensities in a sprayed area, the raster model uses pixels value as attribute values.

Since the whole area is recorded, each pixel has a spatial reference. By spraying onto a

map using one colour, another grid of intensities can be created by calculating the

number of cells painted per unit area.

The raster data model has a long history of use in the GIS and image processing

domains, with well-documented algorithms for performing arithmetic operations and

transformations. It was therefore favoured for this application. The choice of the raster

data model was also facilitated by the support of JAVA for images.

Whilst it would be possible to design a system based on the other data models, and

indeed the field-orientated design is most attractive, the raster / image data model

provides the easiest and simplest method. Also, because the applets are designed as

part of a public participation GIS, it is vital that the inner workings of the system are

easily explained and transparent.


Figure 8.3 Raster Data Model, and counting pixels to produce densityimage


Chapter 9. Phase 1: Analysis.

This phase was mainly concerned with writing a conceptual UML diagram, identifying

likely operations that were to be performed, and sketching on paper a GUI layout. From

the essential use cases and requirements, a simple conceptual UML diagram was

produced (Fig 9.1). The final UML class diagrams (Fig 10.1 and 10.2) can be seen in the

next chapter.

Figure 9.1 conceptual UML

This basic conceptual UML assisted in identifying operations and challenges in the

system. One of the fundamental features of the above diagram is that there are two

“systems”; there would be two applets – one for inputting data and one for querying the

results. Whilst it would be possible to combine both functions in one applet, the use

cases and the diagram make plain the need to separate these roles.

Another key point in the conceptual UML is that there would be a great deal of storing

and retrieving data to and from the web-server or wherever the files are kept. Another

two mechanisms within the system, identified at this stage are the conversion to a

density image and the sorting of comments. Within this Analysis stage, the main issues

investigated included the transfer to and from the server of files and the actual spray can

tool – its shape, feel, characteristics and implementation. Image processing techniques

for the generation of a density / intensity image were also investigated during this phase.


File Transfer – Networking

Applets downloaded over the Internet are only permitted to communicate with the server

it was downloaded from. These built in security limitations are designed to protect people

from malicious applets that could in theory be loaded through a firewall. Taking these

limitations in hand then, any communication with remote servers on other machines

would only be possible through a proxy server on the original webserver. However, this

was not necessary for the design of this system, as it was sufficient and easier to handle

files within the same web-server that the applet originated from.

There are a few frameworks for communicating with the server. One method uses

TCP/IP or UDP “sockets”. One example of an Internet client-server is the combination of

a Web Browser (Client) and a Web Server (e.g. HTTP) which use the HyperText

Transport Protocol (HTTP) to exchange data with each other. The server opens a port,

and listens to requests. The client sends requests to that port, and the server responds

appropriately.

The Java API contains a number of classes designed for communication over the

Internet. The java.net package contains classes for Socket programming with classes

that represent Internet Addresses and Uniform Resource Locators (URL).

Socket programming is conceptually similar to programming with files: you open a

connection to a socket, you read and/or write to it using streams of bytes and when

finished you close the connection.

One method for networking would be to establish a Java server class or servlet on the

server, which when initialized, opens a specified port and listens for client

communications to this. The server can then save and access the requested files from

the server drive itself, and sendj them to the applet.

The installation of the Java server class requires permissions from the web-hosting

company and in some cases a special server framework to be established. The class

files also have to be compiled on the server itself. Unfortunately, native Java servers are


not favoured amongst web-hosting companies, and this method of communication had

to be dropped.

Communicating through CGI ScriptsBecause of the restrictions of my web-server, another course had to be taken – through

the use of CGI scripts. The Common Gateway Interface (CGI) has long been used with

HTML forms sending parameters such as name, address etc and receiving results (such

as a thank you page or an acknowledgment email) from CGI scripts running on the

server.

There are two methods of interacting with CGI scripts, the GET and POST methods, and

the java.net package contains classes for using them. For the GET method, a web

browser sends parameters as a CGI query string appended to the URL; such as

http://www.domainname.com/cgi-bin/form.pl?Name=tim&Surname=Waters

Accessing a CGI script using the GET method is relatively straightforward. A new URL is

declared with a string containing the hostname and query string and then a

URLConnection is opened.

url = new URL(“http://www.domainname.com/cgi-bin/form.pl?Name=tim&Surname=Waters “);URLConnection urlC = url.openConnection();

The GET method’s advantages are that it can send form data, or a string of text in one

go. The disadvantages are that, generally, the maximum length of the query string is 1K.

As will be seen in the Case Study, CGI scripts, written in Perl, utilizing the GET method

were used for parsing the profile and feedback forms, but most used the POST method.

For larger amounts of data, the POST method is preferred. Here the client sends

parameters or data to the server as a data block. The data to be sent has to be written to

the output stream of the URLConnection object:

URL url = new URL(“http://www.domainname.com/cgi-bin/form.pl”);


urlC = url.openConnection(); urlC.setDoOutput(true);

DataOutputStream dos = new DataOutputStream(urlC.getOutputStream());

dos.writeBytes(“Name=tim&Surname=Waters “);

dos.writeBytes(“\r\n”);

Then, after using either the POST method successfully, you can read any results sent

back by the CGI script using an input stream as shown here:

int oneChar; InputStream is = urlC.getInputStream();

while ((oneChar=is.read()) != -1)

System.out.print((char)oneChar);

Changing the code above to send text strings is easy. Dos.writeBytes(StringText).

The CGI script can then read and parse the text and save it into a file, or just read and

save directly into an image file. If these files are saved in directories on the web-server

that are able to be read by browsers (and hence applets), they can be accessed from

these directories by creating a URL object and an associated input stream object and

reading in from there.:

URL idurl = new URL(getCodeBase()+”/logs/ddd.log”);

InputStream is = idurl.openStream();

Image files can be easily loaded using standard image loading procedures, well

documented in the APIs.

Spray Can Tool development

From the initial background research into different spray types, it was identified that the

spray action should be similar to the MS Paint action, in that the rate at which the spray

paint falls on the canvas should be constant, whether the cursor is moving or stationary.


An algorithm was developed and the final code is given in the box below.

It draws a one pixel line onto the graphics object of a component.

It relies on two random numbers, one (toyah) to determine the x position of the dot

(tempx), and another (toyah2) to work out the y position of the dot, which is calculated

using tempx and the size of the spray. The spray has the appearance of a uniformly

distributed spray.

To enable continuous spraying during different mouse events (mouse pressed and

mouse dragged) the use of a thread was employed. This thread controlled the spraying,

the mouse events requested that the thread keep going or in the case of a mouse

released event, to stop.

An attempt was made to compare this uniform spray with one approaching where the

paint was distributed in a normally distributed manner.

A magnified example of the two types of sprays is shown in Figure 9.2 (the spray sizes

are the same).

// where x and y are the positions of the mouse when clicked or dragged

for (int i=0; i<spraySize; i++){

double toyah = (Math.random()-0.5)*2; // get random number from +1 to -1

double toyah2 = (Math.random()-0.5)*2; // get another random number from +1 to -1

// define random x determined by spraysize

int tempx = (x + (int) (((spraySize))*toyah));

// modify pythagorous theorum here, so that using the generated value of x

// tempx and the real x, and the spraySize value (limits size of spray)

int tempy = (y + (int) (toyah2 * Math.sqrt( ((spraySize) * (spraySize))- ((x - tempx)*(x - tempx)) ) ));


Figure 9.2 Two Initial Types of Spray Distributions


FIRST PROTOTYESince the whole system was based upon the effective working of the spray tool –a

prototype applet was developed to test various spraying actions on a panel, with a

simple red rectangle as a “map”.

User testing was performed on a working model of the two sprays. The users were

asked to firstly become comfortable with the use of the spraying action, and then to

spray within a red box on the panel, making one corner darker. Figure 9.3 shows some

of the results of the testing.

Users preferred the uniformly distributed spray, as it was “cleaner and neater and easier

to paint light areas”. The graded spray was “harder to paint areas of light” because it was

distributed more towards the centre. It was noted that it was easier to define an edge

better with the uniformly distributed spray, even though both sprays were constrained to

the circle defined by the SpraySize variable. The speed or rate at which the paint is

applied was also commented upon. About 30 milliseconds between each droplet of

spray proved to be a comfortable rate.

Lessons LearntDifferent ways of communicating with server. The CGI method, whilst possibly not being

the best way, would be the most common and sometimes the only viable method of

communicating between an applet and its source web-server.

Importance of user testing and prototyping at each stage of development process and

getting feedback from people on the look, feel and workings of the applet.


Chapter10.Phase2:

Design

Wit

Figure 9.3 User Testing of Spray Types

Acme

«acme»Image Encoder

«acme»GIF Encoder

extends

DensityOp-densityImage: Image-pg: PixelGrabber+...+process()+getDensityImage(): Image

ImageArray-array: String []-size: int-index: int-id: int-entry: String+...+ImageArray(size:int): <<const>>+addItem(valueInt:int,index:int)+getEntry(index2:int): String+sendArray()+readArray()

Sender-id: int+...+sendImage(sendingImage:Image,id:Int)+sendText(text:String,name:String)

SprayPanel-runthread: Thread-spraySize: int-gc: Graphics-osGC: Graphics-osImage: Image-mapImage: Image+...+comeAlive()+clearitup()+getSprayGraphics()+spray()+setSpraySize()+...()

Sprayer-userImage: Image-smallerImage: image-imageArray: ImageArray-pixels: int []+...+getID(): int+processArray()+submitAction()+init()+...()

«acme»IntHashTable

«text file»

[ id log ]

«text file»

[comments log]«gif file»

[ image id.gif ]

sends array Webserver

Figure 10.1 UML Input Applet - Sprayer


hin the second phase, the methods and classes of the applets were written and tested. It

became apparent from the requirements and use case that two applets would be

needed, one for input and one for output. UML class diagrams were written for each of

these. Figure 10.1 shows the UML for the input applet (Sprayer) and Figure 10.2 shows

the UML for the output applet (QuerySpray)


QuerySpray extends Applet-iTranPanel: ImageTranPanel-array: String []-commentHash: Hashtable-idv: Vector-queryHash, newQueryHash: Hashtable+init()+intComponents()+readData()+setupImage()+mouseClicked()+getEntry(index:int)+readArray()+readCommentsLog()+getArrayImage()+readIDLog()

ImageTranPanel+image: Image+gc: Graphics+...+setMapImage()+setDisplayImage()+...()

QSortAlgorthim+Sort(b[]:String,a[]:string)-...()

BlurOp+avgimpixels+avgimgpixels+...+getBlurImage(img:Image,width, height, kSize:int): Image

«serialized»

[imageArray]

«textfile»

[idLog]

«textfile»

[CommentLog]

webserver

awt.Panel

Figure 10.2 UML for Output Applet - QuerySpray


DENSITY IMAGEWith a working spray action, the first mechanism to be developed is the conversion of

the binary spray image to an image or map of density. To this end, the DensityOp class

was developed. It was based upon a common image processing operation -that of using

a convolution filter over an image. The convolution filter samples an area around a pixel,

and uses the values of the pixels in this area to determine the central pixel value.

The process involves using a PixelGrabber to convert an image into an array, and then

cycling through the array, adding up the number of pixels with “paint” in them. The new

pixel at the centre of the kernel is calculated by the sum of these.

Thus in figure 10.3, with four pixels containing paint, the value calculated for the central

pixel is four (also see figure 8.3). From 8.3 it can be seen that the pixels at the edge of

the image are excluded from the analysis. In the case of the applets, this led to a dark

border around the user images.

1 0 1

0 1 0

1 0 0

4

Figure 10.3 example of sum kernel operation


Because of the relatively widespread way in which the dots appear on the panel,

different kernel sizes were experimented with. Figure 10.4 shows attempts using

different kernel sizes.

Figure 10.4 Example of different kernel sizes.

a

b

c


The 3x3 kernel was a bit too small to take into account the spread of the pixels. Also,

smaller kernels limited the number of different shades or intensities – since for 3x3 there

could only be up to 9 different values. The 5x5 kernel still had some gaps, and a

noticeable blocky appearance. A good compromise was reached with a 9x9 kernel. The

advantage of using a larger kernel is that it gives a much larger range of density values.

Using the same kind of operation, a BlurOp was also written to blur density images

before saving. This was created with a static method, so that a BlurOp object need not

be created separately. I also incorporated a way to increase or decrease the kernel size,

by specifying a kernel size as an int of values, 1, 3, 5 or 7. Initially the BlurOp was used

to process density images before saving them, however later the class was mainly used

primarily for smoothing the composite results map.

Image Encoding & CompressionIn order for the applet to be able to save images as a file suitable for viewing or

downloading later, it was decided to save them as GIFs. The Acme GIFEncoder

package available from http://www.acme.com/java/ (1998, Poskanzer) was used. This

package, highly recommended and used by the Java community, is free, and performs

very well.

Composite ImageThe requirements specified that the system should be able to store in a users input and

display a composite map of everyone’s input. The creation of a composite map proved to

be one of the toughest challenges in the design phase.

One mechanism included the creation of an average image. The applet would create a

density image, get the current average image, add them together, and divide by two.

However, it soon became apparent, that whilst sort-of being a record of everyone’s

inputs, it put too much emphasis on later additions to the average image, to be useful.

Since the applet could save each users input as a GIF file, another method looked at

loading up all the user GIFs available, arithmetically summing them and dividing by the


number of images loaded. This worked ok for a small number of images, but for more

than a dozen, the applet was very slow. By increasing the number of images to be

loaded also increased the chances that one of the images may not have been loaded

properly.

However, this method could be applied appropriately using a server-side process. After

the image is uploaded, and received by the server, the server could do the processing

“in the back-ground” so to speak, and when ready send it to the applet. A server, being a

dedicated computer, can often process things faster. However, as explained before, this

option was not available for me, unless I used a Perl CGI script, with an image-

processing library.

The final mechanism looked at involved using an array of Strings. The array is the same

size as the image, and records the pixel value as an int string. The applet would load in

the array, and append to it the values of the users density image.

Image ArrayThus a possible entry in the String array could be “100, 255,255, 24, 56, 45, 123”

Variations looked at included add the unique id of each spraying to each value, thus “1,

100, 2, 255, 3, 255, 4, 24…”.

Since some of the user images are blank, this method could be adapted, so that for

blank areas (ie, pixel vajlue of 255), “1, 100, 4, 24, 5, 56” no entry would be required.

However the first simpler format was used, as it was easier to add entries and parse the

strings when reading them. Also there was little noticeable difference in file size between

the first format and the one with no blank areas – File sizes are discussed later.

Serialization of ArrayIf a class “implements Serializable”, it is able to save objects within that class to a file.

Thus the string array with the ImageArray was serialized. This greatly facilitated the

saving and loading of the array, as it by-passed converting the array to a text file, and

reading the text file back in, string parsing it into an array etc.


Compression of ArrayIt quickly became apparent that even with the addition of one or two images to the array,

the physical size would be much too large for efficient saving, retrieval and processing.

The time taken to load in 900K worth of array is much too long for most users on a dial-

up modem, and the amount of memory space taken by such a large object could also

pose a problem.

For example:

Array no compression: 859K

Array with GZIP: 67K

Array with GZIP and shrunk 14K

There was a distinct need to compress the array prior to saving it to the server.

Thankfully, the java.util.zip has a number of classes that facilitate writing compressed

data to output streams. I used GZIPOutputStream:

GZIPOutputStream gzip = new GZIPOutputStream(urlC.getOutputStream());

ObjectOutputStream bos = new ObjectOutputStream(gzip);

Now the size was smaller from around 900K to 67K. Quite a compression ratio!

However 67K was still quite large, and this would grow as more users entered their

inputs.

Sub-Sampling – ShrinkingConceptually, a spraying is fuzzy and vague. By shrinking the original image by a factor

of 5, the image array would also be reduced by 5 times. Then in the output

applet, the image could be re-inflated by the same factor and smoothed. Within Java, the

java.awt.image.AreaAveragingScaleFilter was used:

ImageFilter shrinker = new

AreaAveragingScaleFilter(userImage.getWidth(this)/5,userImage.getWidth(this)/5);

ImageProducer ipsource = new FilteredImageSource(userImage.getSource(), shrinker);


Then the image array was comprised using this shrunken image. Comparing the un-

shrunk and shrunk images, there was no noticeable visible difference in output when re-

inflated. However, in terms of file size, the image array was reduced from 67K to 14K, a

considerable saving. Figure 10.5 shows the effects of sub-sampling the composite

image

The benefits of reducing the size of the image was also used when saving user images

too, saving disk space on the web-server, processing and image load / save times.


Figure 10.5 Example of sub-sampling to reduce file sizes.

(a)This is the original image

(b) This is the image reduced by 5X

(c) Image re-inflated (By 5X)

(d) Re-inflated image blurred

d

c

b

a


Output Applet

The Results applet had to be able to read in the serialized array, and convert the entries

in the array into a composite image. It had also to read in the comments text file, and join

the comments to the image, so that when a user clicked at a particular point of the map,

comments are displayed for those users that specified that area.

The composite image was simply made by StringTokenizing the array, parsing the array

entries to ints, and then creating an average for each entry.

Then, using AreaAveragingScaleFilter, the image was re-inflated to its original size. The

java docs for AreaAveragingScaleFilter say that it “produces smoother results than the

nearest neighbor algorithm”, this means that the resulting enlarged image would not

have a jagged or stepped appearance, characteristic when using the nearest neighbour

algorithm. Using the BlurOp class, the image was smoothed to improve its appearance.

Matching the comments with the composite map proved to be an interesting challenge.

Fig 10.6 outlines the procedure. Hashtables are used to store the relevant files, and

match the comments with the values.


The actual sorting class, QsortAlgorthim is a very slightly modified version of the

QsortAlgorithm class provided with the Java JDK in the Demos sortDemo package. It is

primarily modified to take in an array of String and an array of ints.

Figure 10.6 Sorting Algorithm

Comment LogImage Array23,144,78, 25528, 178, 50, 25565, 234, 90, 230

HashtableKey: idValue:StringCommentHash

Array int[]23, 144,78, 255

HashtableKey: id, Value,:pixelvalueQueryHash

For a particularpixel coordinate

SortingAlgorithmSortsQueryHash’sId and value intosorted array

Use sorted array askeys inCommentHashComments Sorted andDisplayed

ID log1,2,3,4

Vectoridv

1, 232, 1443, 784, 255

1, 233, 782, 1444, 255

1, aaa3, ccc2, bbb(4, ddd)

1, aaa2, bbb3, ccc4, ddd


System prototype – step forwardsThe system prototype was developed that tested the input and output (Sprayer and

QuerySpray) and the saving and interaction with CGI scripts. It was during this stage,

that many of the aforementioned solutions were developed, tested and refined upon.

The background map for example, was increased in size from 300 x 300 pixels to 400x

400 pixels, and simple GUIs were developed that. A Sender Class was written to

manage the sending of images and text files to the CGI scripts.

Issues with Netscape 4.7 Browser became apparent at this stage, and are explored fully

in the next stage. With the Java plug-in the input applet did not crash, but without it, the

applet crashed the whole application.

HTML pages tying in the two applets were developed, and during the next phase re-

written.

Lessons Learnt – Iterations Back

It is possible that there are more efficient ways for the compression, storage of the

image array. Possibly, instead of an array of strings, they could be written in byte format.

The handling of the comment and id logs and the image array to sort and display the

comments for a particular area could be done more efficiently, however the current

method allows future developments to edit out entries.


Chapter 11. Phase 3: implementation

During the implementation stage, the whole system was built up, around the application

of a Study of Peoples Perceptions of Crime in Leeds.

HTML WebPages were written for profile information to be recorded at the beginning,

and some feedback questions to be answered at the end. These HTML forms use the

CGI GET method with two Perl scripts. These Perl scripts were altered from the

Woodland Online Decision Support System (WOODS, 2002) and customized for my

purposes. Customizations included using CGI.pm instead of CGI-lib.pl, altering file

paths, and changing HTML outputs.

The GUI was designed using Forte for Java’s form editor and the Absolute Layout. This

layout was favoured over GridBag as it facilitated the addition and removal of various

components. The applet, being fixed in the web-page did not need to be re-sizeable.

In addition to the Clear and Send buttons, a Help button was incorporated in the applet

that opened a HTML page with help, instructions and FAQs in another browser window.

Three CheckBoxes were also added to let the user choose the size of the spray (small,

medium, or large).

It was during this stage that some of the optimizations of the Design Stage were

developed. This included the shrinking of the image before saving it. Since a record of

each person’s sprayings was desired, it was decided that it would be better just to send

the small version.


UNIT TESTINGEach applet was tested separately and together. The whole system was examined and

seen if it worked as a whole. The following obvious bugs were found in relation to the

Netscape browser.

BUGSDuring the implementation phase, the two applets were tested in Internet Explorer and

Netscape. There were several problems with Netscape, some of which were commonly

experienced by other developers, and are summarised below.

1. In Netscape, with no plugin, PixelGrabber or MemoryImageSource did not work

with off screen images. Thus there was no image saved when a users spraying

was converted to a user image and added to the image array. This was a

Netscape specific problem and also only occurred with Windows NT where the

number of colours was set to True Color.

Solution: The solution to this would be to use the Java plugin or make sure users

turned their colours down if using Windows NT.

2. Netscape 4.7 has two methods for facilitating web viewing. The use of an internal

proxy server and the use of a cache.

a. The proxy server would save files onto the users hard drive and at a later

date, when the user revisited that site or requested those files, it would

access them from that store.

b. Cache: Netscape has a memory and File Cache, similar in operation to the

proxy, this keeps a more temporary copy of files.

c. What happens is that the files that the applet reads does not come from

the webserver, but are read from users hard drive or their computer

memory. Thus the applets are responding to an older version. What this

can cause is an id log like this: “1, 2, 3, 4, 5, 3, 3, 3,4,5”, thus making

things a bit confusing!


Solution: The solution to this would be to get the user to manually turn the proxy

option off in the options>>advanced menu within Netscape. And before using, to

clear the memory and disc cache.

Note:

The actual web-pages can (and were) marked “do not cache” by incorporating a

special META tag in the header. However the files from the web-server,

requested by the applet, via the browser are given normal header files.

A special Java server or servlet could be designed so that it send a “no cache”

header before sending the files in response to a request for them. Alternatively, it

could be possible to make a CGI script to send data to the applet, with these

headers, so that the browser does not cache them.

The disadvantage in this is the added technical knowledge of setting this up and

the use of CGI scripts as a proxy, instead of accessing the files directly.

3. One of the major problems, and as yet not totally identified, caused the Netscape

browser to crash. A user could use the input applet on Netscape with no problem.

It would send the data off. But if he or she tried to go back to the input page, and

send some more data, the browser would crash. It seemed to be crashing just

after the serialized array was read back in. However, using the plug-in corrected

the bug.

a. Possible reasons could include memory cache. The applet reads in data

that is already stored, or the applet reads in data from the cache instead of

the webserver.

b. A possible work-around could be to use a text-file or compressed file

instead of serialization

c. If the input applet was just restricted to a “one-use only” the applet could

be used.

Notes: Using the plugin could be the only way to solve this, unless the problem

lies with the serialized, compressed image array.


These bugs form a considerable stumbling block within the terms of public

participation GIS, as it excludes those with the Netscape Browser in its use.

Originally it was decided that the plugin should be recommended for use with

Netscape, but although this stabilized the applet and browser, it did not fix the

problem with the cached files.

Future work therefore is therefore needed to stop the files being cached, and or to

identify the point at which the browser crashes.

At the current stage of development, the input applet is classed as not being

suitable for use with Netscape, but the results applet works fine with this browser.


Chapter 12. Phase 4: Testing

Within context of the application of the applets to a study of crime in Leeds (covered in

more detail in a later section) the applets and whole PPGIS system was tested.

About 6 people participated in the user testing. Testers used the system and commented

on the workings, spelling mistakes and overall usability and asked to give any

comments.

Some supervision was undertaken with a couple of testers to see how they use the

applet, and see how easy it was for them. Conceptually, the idea is a very simple one,

and one that was easy to grasp. Some uncertainty was given to how to use the facility to

give variable densities to the spraying.

One person said that the system did not make itself clear that his inputs were going to

be viewed by others and that a composite map was to be made from it. Lots of spelling

mistakes were found in the help and background files.

It was noticed that some used the comments box in the input applet to comment on the

system itself.

These suggestions were acted upon. Supporting webpages, help pages and

documentation were spell checked and re-written to make explicit some instructions and

the nature of the system. An animated GIF was produced to illustrate some of the

potential spraying that the tool could do. I was conscious that this animation could bias

people in their choice of locations, yet I believed it necessary for people to see what

would be acceptable.

A user on a Pentium I machine and 33K dial-up internet connection was asked to time

how long things took to load, send and appear on screen. It was found that the loading

took just less than 3 minutes and the sending took about 8 minutes before the thanks

page arrived. The results page loaded within 3 minutes. To decrease loading times, the

classes were packaged into compressed jar files.


Another issue raised was flickering experienced when the applets loaded, or if the

screen was covered and the uncovered. This related to the way the components were

painting. In the case of QuerySpray the panel re-painted the composite map, the

background and the frame, one by one, in that order On a slow computer this flashing

was very noticeable. It flashed for several seconds. The solution to this was to

implement double buffering. Drawing everything to an off-screen image and then

drawing only that image when updating the panel eliminated the flicker. This double-

buffering was implemented in both the SprayPanel and the ImageTranPanel classes.

The user on the dial-up, slower computer expressed a need for some kind of progress

report. This very useful feature was accommodated by utilizing an existing label. By

changing the font, and colour and text of the label nine times, two types of progress

reports were given: a “PROCESSING Data…Please wait (2 / 3)” between the image

processing, density making phases and a “SENDING DATA…Please wait (2 / 5)” label in

between the various sending operations.

With these issues addressed and web-site re-designed, the system could be applied to

the study of where in Leeds do people think has more crime.


Chapter 13. Phase 5: Deployment

This phase, when the applets went online in the case study was also spent tidying up the

code, commenting it fully, and creating javadocs.

The deployment phase was also spent making the code more portable. Absolute URLs

pointing to my website e.g. “http://www.cycletouer.com/applets/logs/aaa.tim” were

changed to relative ones using getCodebase() wherever possible e.g.

“getCodeBase()+”logs/aaa.tim””. Developers may still need to alter some of the source

code to deploy the applets on their system

Whilst the case study went ahead, the comments log was examined frequently for any

bad language or joke answers, and edited carefully. The feedback responses log was

also looked at and where appropriate changes made.

The development process as outlined in Figure 6.1 provided a structure for the design of

the software. Iterations were made to past phases as better ways of doing things or bugs

were discovered and small steps into the next phase helped concentrate areas of work.

Although some of the technical details have already been covered, the code is now

explained in detail, using the Use Cases as a framework.


Chapter 14. Software Description and Process

The generated Javadocs (see Appendices) can explain the main functions of the

software, and to a large extent the previous section outlined some of the main functions

of the applets. This section, then uses the Use Cases and UML as a framework to

explore the software, what it does and how.

Input Applet –

SprayerWith the Init() method the applet initializes the GUI, as shown in Figure 14.1, and calls

the setupImages() method to load in the background map image to the SprayPanel. The

Help button loads the specified help file in a new browser window, and clear clears both

the SprayPanel and the Comment Box. The checkboxes change the setSpraySize()

methods in SprayPanel. SprayPanel handles the main spray tool, drawing on an

Figure 14.1 screenshot of Sprayer GUI and Webpage


onscreen and two offscreen images (one for the further processing and one for double

buffering).

The user clicks and drags on the SprayPanel, and the SprayPanel keeps the users

sprayings in an offscreen image (osImage). The user types comments in the comments

box.

When the user clicks on the “Send everything!” button, several things happen within the

submitAction() method of Sprayer.

1) The user is assigned an ID, through a call to getID(). The getID() method checks to

see if the id log file (ddd.log) exists, if it doesn’t the applet assumes that the user is

the first and gives the ID as 1. If it does exist, the log file is read and each line is

read. The last line containing the previous users ID is added to by one to make the

new user ID.

2) The osImage, offscreen spray image is got from the SprayPanel.

3) This osImage image is processed using the DensityOp to produce the userImage,

which is the densityImage.

4) The userImage is shrunk using ImageFilter, ImageProducer and

AreaAveragingScaleFilter, and a smallerImage is created.

5) A Sender object is created, and the smallerImage is sent to the server. Sender uses

Acme’s GIFEncoder to encode the image into GIF format.

6) The user ID and any text from the comment box is then sent to the server (ccc.log)

via the Sender object.


7) The user ID is sent via Sender to the CGI script where the new ID is appended to the

end of the file.

8) ProcessArray() is then called. A new ImageArray object is formed here – and the

existing ImageArray is loaded from the server at this point. The pixels of the

smallerImage are grabbed, and the value for the red band and the index of the pixel

array is passed into the ImageArray object using ImageArray.addItem(int r, int y).

This method in ImageArray adds to a specified index in the array, the pixel value.

This then is converted to a string and concatenated to the end of the original value.

Then ImageArray.sendArray() is called. This, again makes use of a CGI script to

send the serialized and GZIP compressed object to the webserver.

9) Finally, Sprayer calls clearAction(), mimicking the action of the clear button, to clear

the SprayPanel, any offscreen images and to clear the comment box, ready to start

again.


Output AppletQuerySpray’s GUI is shown in Figure 14.2

The init() method calls initComponents() to initialize the GUI and readData(). ReadData()

itself calls readArray(), setupImage, readIDlog and readCommentsLog.

1. readArray() loads the serialized array from the webserver (/logs/aaa.tim) into a

String array array.

2. setupImage() loads the background mapImage, and calls the getArrayImage

method to create the composite image, enlarges this and blurs it a bit, before

sending it to the ImageTranPanel for display.

Figure 14.2 Screenshot of QuerySpray GUI and WebPage.


3. The getArrayImage uses the String array, stringTokenises each entry, and

calculates the average at each index, putting this into a new int array to create the

new composite image.

4. readIDlog, reads the ID text file (ddd.log) adding each id on each line of the file

into a Vector (idv).

5. readCommentsLog() loads in the comment text file, (ccc.log) and puts each users

inputs into a Hashtable using the first token (id) as the key and the second token

(comments) as the value.

After all this, the composite image is displayed and the user can click on the map and

read the comments. When the user clicks, the mouseClicked method transforms the

image coordinates to the equivalent (5 times smaller) imageArray index, it then calls

getEntry with the value of this index.

1. getEntry(), one of the most complex methods in QuerySpray starts by using the

passed in index value to tokenize and parse the string array at that index, filling

up an new array of ints (intArray).

2. A Hashtable is created (queryHash), where the ID from idv is the key and the

value is made up of the intArray.

3. To facilitate sorting of the comments, the elements and keys of queryHash are

enumerated, and a put into a String array (str_tbl) and int array (int_tbl).

4. These two arrays are passed into QsortAlgorthm’s sort() method. The keys (Ids)

are now sorted based upon the values (pixel values).


5. Running through the sorted str_tbl[], the corresponding comment is displayed, if

the value is under 255 (i.e. there was actually something sprayed) and if there

was a comment written.

The text area is then filled with comments for that area sorted so that darker or more

dense inputs are top of the list.

Code Listings, JavaDocs, CGI scripts, and HTML webpages

The full source code and generated javaDocs can be found in the Appendices.

Where appropriate, inline comments and commented-out debugging code have been left

in, to facilitate future developments. CGI scripts and HTML webpages can also be found

in the appendices.


PART C: Case StudyChapter 15. Application to a Study on Public Perception of Crime in

Leeds

IntroductionThe system developed in the previous sections was applied to a study on peoples

perception of crime in Leeds, West Yorkshire. In studies of people’s perception of crime,

it is often remarked that people’s perception of crime does not match official crime

records. A web-site was set up with the applets, background information, instructions

and help-pages. Users filled in a profile form at the beginning and a feedback form at the

end. This gave information about the types of people using the system, and what they

thought of it. Participants were asked to specify the areas in Leeds that they though had

the most crime. Users sprayed an area or area on a map of Leeds, typed in comments

and submitted them, they were then able to read other peoples inputs and comments.

A literature review giving background information on the perception and fear of crime is

given, outlining the characteristics and causes of the fear of crime. This is followed by a

short study of crime in Leeds. The aims and methodology of the case study are then

given, followed by the presentation of results. A discussion of the results is given, and

user feedback evaluated.


Review on CrimeThis section gives the background to crime and in particular the fear of crime, what it is,

what causes it and possible solutions. Since this case study seeks to map people’s

perceptions of crime, a short review of some previous studies is given. This is followed

by a discussion of the characteristics of Leeds, and a summary of a recent study

comparing actual crime levels and peoples perceptions of crime change in Leeds.

The Geography of Crime and the Perception of Crime.

“There can be little doubt that crime constitutes a major perceived problem for the urban

dwellers of Western Society” Herbert (1982).

The geographical study of crime deals with, amongst others, where crime occurs, where

criminals live, the influence on place on crime and the influence of the police and political

powers. This case study is mainly concerned with where in Leeds, people think has the

worst crime, why they think that and where in fact it does occur, with an examination of

the reasons for any disparity. Although the question posed in this case study was not

“where are you most fearful” but “where do you think has the most crime”, it is likely that

the two give the same results. An examination of the fear of crime is therefore essential.

Susan Smith (1989) summarises fear of crime:

“It is generally agreed that fear connotes more than simply awareness about crime, and

more than concern about the problem of local deviance. …Rather, fear is a state of

constant or intermittent anxiety: its effects reach beyond the prudent management of risk

to impinge on public morale, individual well-being and the quality of social life.”

Garofalo (1981) connects fear of crime with the environment; “an emotional reaction

characterised by a sense of danger and anxiety…produced by the threat of physical

harm…elicited by perceived cues in the environment that relate to some aspect of crime”


Fear of crime is a real social problem. A Home Office Working Party report stated “fear

of crime will grow unless unchecked. As an issue of social concern, it has to be taken

seriously as … crime prevention and reduction” (Home Office 1989).

Many studies on the fear of crime repeat the same tune, that the map of fear does not

match the map of actual crime. Evans (1989) commented “although fears of being

victimised are widely held and influence behaviour in space, they are out of proportion to

real levels of risk”, and Williams and Dickinson (1993) note that whilst many people have

high levels of anxiety with regards to crime “most people have never been a victim nor a

witness to crime!”. Herbert (1982) writes

“It is the fear, often exaggerated, of victimisation which creates most of the

stress… The police actually witness and discover very few offences, citizen

vigilante groups have disbanded out of the frustration of seeing nothing to report;

crime prevention should focus on its passive role of allying fear as well as on its

active role as a deterrent to offenders.”

So whilst the fear of crime may have little relationship with actual crime figure, it is still a

real social problem, and one worthy of study.

Box et al, 1998, summarises the effects that the fear of crime has on society.

� It fractures the sense of community and neighbourhood, and makes some places

into “no-go” areas.

� Fear leads to more wealthy people protecting themselves or moving from the

area, this may lead to crime being displaced onto those already suffering from

other social, environmental and economic hardships.

� It reduces the appeal of liberal political policies towards the penal system, leading

to more incarceration and punishment.

� It could lead to people being disillusioned with the criminal justice system, with a

feeling of helplessness. This could lead to vigilante groups or even lynch mobs.

� When people are afraid, they change their habits. They tend to stay at home

more, in surroundings that they have made safer. When they go out they avoid


“dangerous” activities like taking public transport, walking down a certain road,

being near certain “types of people” etc.

� For people fearing victimisation at any time, a journey outside the home, (or even

within it – re: the increase in Panic Rooms in the US) is “like walking through a

minefield”

The sense of fear tends to be biased towards certain social groups. Box et al (1998) and

the British Crime Survey show that the elderly, women and minorities have the most

anxiety regarding crime. Interestingly the statistics indicate that these groups actually are

the least likely to experience violent crime.

Thus tackling the fear of crime could be more important than cutting actual levels,

however the factors behind the social problem of fear, and solutions to these may be

much more of a challenge. Some of the influences on the fear of crime include:

� Mass media. Williams and Dickinson (1993) examined the relationship between

newspaper reporting and the fear of crime. They found a significant positive

relationship between the amount of space devoted to crime (particularly violent)

and fear of crime. They note that broadsheets report fewer articles about crime

and in a less sensationalist fashion. They conclude; ”crime reporting in the news

media has been a focus of concern because of the assumption that the salience

given to certain types of crime, notably those involving sex or violence, creates a

distorted picture of reality which is reflected in the beliefs of news consumers.”

� Direct experience of crime.

� Interpersonal communication about another’s experience. Urban myths and

gossip between people all help to spread information (and misinformation).

� Environmental conditions: Litter, graffiti, noise, dereliction, abandoned cars.

� Incivilities: Drunks, gangs of youth etc.

� Confidence in the Police and authorities.

� Perceived seriousness of offences.

� Labelling and reputation of areas.


There seems to be a threshold level where the level of anxiety cannot fall, but must keep

on rising. Box et al (1998) discusses the attitude of those with direct experience of

victimisation. They found that most previous victims had lower levels of fear of crime

than those surrounding them. The authors gave possible reasons including that those

individuals may now take more precautions and be more “in control”. They might have

been able to “neutralise” the negative experience – the experience has become not that

important. Time also “atrophies” experience, making it less powerful.

However, they found that for some and /or in certain areas, the victim has an increasing

amount of fear: “it is perhaps that much harder for victims to take what they perceive as

effective precautions against an environment of constant danger and threat, or maybe

neutralisation is prevented or forgetfulness denied by repeated encounters with

disturbing environmental clues.” (Box et. al., 1998)


Mapping the Fear of Crime and Peoples Perceptions of SafetyAs already mentioned, this case study looks at people’s perception of where crime is in

Leeds. Most studies that map the perception of crime include some participative

process, where respondents are asked their views. There follows a review of some

studies at various spatial scales and using different methodologies that have attempted

to map the fear of crime.

PolandS.P. Bartnicki (1989) studied crime in Poland. Twelve neighbourhoods were chosen, in

areas classed as “safe” or “dangerous” on the assumption that residents would have

different views on crime, as they come from different environments. Four hundred 19 to

24 year olds were asked what they thought of the other neighbourhoods, whether they

felt safe in their neighbourhoods and if they thought crime was rising in their area.

Figure 15.1 shows the map of

fear for the 12 neighbourhoods.

He found that the perceived

level of crime did not match the real pattern of crime rates. The results indicated that

people tended to view crime as a problem in “other” places. Although people believed

Figure 15.1 Map of Fear in Warsaw, Poland.From Barnicki, 1989


that crime was rising in the whole of Poland, and within Warsaw too, it was not rising in

their own neighbourhood. This was the case in all but one neighbourhood, and that was

generally known as the worst area for crime. People recognised a fear of crime, but at a

distance.

Los AngelesMatei et. Al. 2001, examined the fear and misperception of crime in Los Angeles County,

USA. They used GIS to process 215 mental maps from a survey of seven ethnically

marked residential communities of Los Angeles. The study accepted the assumption that

perceptions of crime were inaccurate, and instead looked at how “peoples participation

in various media / communication infrastructures influence their misperception” and if

fear was colour coded, as LA has a complex and sometimes volatile ethnicity mixture.

(Matei et. Al. 2001)

Participants were mailed instructions, a map, coloured markers and a SAE for return.

Respondents were asked to use colour on the map in the following manner:

Black: their own neighbourhood.

Green: areas where they felt comfortable

Orange: areas where they feel somewhat but not completely comfortable

Red: the areas where they feel uncomfortable or fear

Blue: areas they do not know

The returned maps were digitised into ArcView as polygons and then converted to a

raster surface. This facilitated arithmetic operations such as the creation of a composite

map by averaging. The composite map (albeit reproduced in monochrome) is shown

here in Figure 15.2


The study re-confirmed the initial thoughts that crime is misperceived. They found that

most respondents “feel slightly more comfortable in areas with higher crime rates”. This

is reflected in the composite map (Fig 15.2) with dark boundaries represent the areas

where the respondents live have been given high comfort ratings, despite the fact that

that have “a higher level of crime victimization likelihood than the rest of the county”.

They noted therefore that the respondents overestimated comfort, relative to crime, in

the areas where they live.

They conclude, “People tend to perceive their own community as more secure while

constantly projecting fear into the neighbour’s backyard, especially where people of

other ethnicity live”. They comment that the co-presence of Black and Hispanic

populations increases fear. This may be a reflection of racial imagery, and the

perceptions from gang action between these two groups

Of interest was the over estimation of peoples comfort in their own neighbourhood,

compared to others. This echoes the findings of Bartnicki, (1989) explored above. One

observation could be that the crime level of an area does not by default make that area

uncomfortable; rather, there are other issues. Perhaps some areas have a “bad feel”.

Fig 15.2 Los Angeles County. Fear(dark) and comfort (light) AreasFrom Matei et al, 2001


University of British Columbia

The department for Health, Safety and Environment of the University of British Colombia

undertook a study to look at campus safety (UBC, 2000). Some of the aims of the study

was to determine the areas of campus that needed to be made safer, to evaluate areas

that have already been completed to see if users feel comfortable, and to receive input

as to how the university can make students feel safer on campus.

The survey contained a mapping component. Users were given a map and asked to

draw an “X” to specify areas of fear and an “O” to specify areas of comfort, together with

a description as to why they felt fear or comfort at particular places.

746 survey maps were completed, and the analysis involved overlaying a transparency

over the maps and counting how may X’s and O’s occurred within each grid square. A

composite map was produced (see Figure 15.3) although there was no mention of the

use of GIS.


Figure 15.3 Areas of Comfort and Areas of Fear. From Personal SecurityMapping Survey University of British Colombia, (2000.)


The composite map (Figure 15.3) clearly identified areas of fear and comfort. The study

highlighted that it was at night that people felt most apprehensive, with a

recommendation for more lighting to be installed. Whilst no data or information was

given as to actual incidents, the areas of fear commonly were isolated and enclosed,

dark, had few security patrols.

Some of these examples have brought up some suggestions for future research into the

spray-can GIS, and are discussed in a later section.

From an exploration of past studies on public perception of crime, the next section

examines the case of Leeds itself.


Chapter 16. Crime in Leeds

The data used in this analysis of the crime in Leeds comes from West Yorkshire Police

via the School of Geography. (Clarke et.al. 2001, Debenham, 2001).

The types of crime in Leeds

0

5000

10000

15000

20000

25000

30000

Violent C

rime

Sexual

Offe

nces

Robber

y

Burglar

y Dwell

ing

Burglar

y Other

Vehicl

e Crim

e

Other Thef

t & H

andlin

g

Fraud &

Forgery

Criminal

Damage

Drugs

Others

1998/19991999/20002000/2001

Figure 16.1 Levels of Crime by Type in Leeds 1998/1999 – 2000/2001From Clarke et.al 2001.

The types of crime in Leeds and the change over time is highlighted in Figure 16.1. In

2000/2001 burgularies accounted for 23.7% of all crime, whilst vehicle crime accounted

for 26.1%.. the total number of incidents for Leeds in 2000/2001 was 156 crimes per

1000 people. (Clarke et.al, 2001)


Geography of Crime In Leeds

Figure 16.2 shows a map of crimes per 1000 people at ward level for Leeds.

From figure 16.2, it can be seen tha there is a concentration in the central areas of

leeds, with the City and Holbeck ward having the highest rate. This is due to the

influence of the city centre. Headingley and University wards also came out as having

high crime rates. The types of crime also varies geographically, Figure 16.3 shows the

distribution of domestic burlgualries and Figure 16.4, vehicle crime.

North

Wetherby

Barwick and Kippax

Halton

Rothwell

Otley and Wharfedale

Aireborough

Morley South

Wortley

Middleton

Morley North

Horsforth

Whinmoor

Garforth and Swillington

Roundhay

Cookridge

Pudsey North

Hunslet

Bramley

Armley

Richmond HillPudsey South

Weetwood

Kirkstall

City and Holbeck

Moortown

Beeston

Seacroft

University Burmantofts

HarehillsChapel Allerton

Headingley

Crime Rate 2000-2001Incidents / 1000 people

52.3551 - 61.154100

61.154101 - 102.342000

102.342001 - 143.890000

143.890001 - 225.805000

225.805001 - 371.122000

371.122001 - 923.451000 ±Figure 16.2 Crime Rate per 1000 Population for Leeds 2000/2001


North

Wetherby

Barwick and Kippax

Halton

Rothwell


Aireborough

Morley South

Wortley

Middleton

Morley North

Horsforth

Whinmoor


Roundhay

Cookridge

Pudsey North

Hunslet

Bramley

Armley


Weetwood

Kirkstall

City and Holbeck

Moortown

Beeston

Seacroft



Headingley

TotalDomestic Burglary

141- 198

198- 288

288- 410

410 - 550

550 - 750

750- 1117 ±Figure 16.3 Domestic Burgularies 2000-2001

North

Wetherby

Barwick and Kippax

Halton

Rothwell


Aireborough

Morley South

Wortley

Middleton

Morley North

Horsforth

Whinmoor


Roundhay

Cookridge

Pudsey North

Hunslet

Bramley

Armley


Weetwood

Kirkstall

City and Holbeck

Moortown

Beeston

Seacroft



Headingley

TotalVehicle Crime

252. - 342

342 - 565

565 - 787

787- 1291

1291 - 2138

2138 - 4342 ±Figure 16.4 Vehicle Crime 2000-2001


There are some differences in the spatial distribution in the different types of crime,

however there is still a central bias. For domestic burglary (Fig 16.3) the highest rates

are in the north west of the city centre, with the highest rates in the Kirkstall and

University Wards.

For Vehicle Crime, the highest numbers were concentrated in the city centre. This is

probably correlated with the large amount of car parks, and cars.

Whether people perceive different types crimes as more important than others is worthy

for further study, however this case study investigates where people think in Leeds has

the most crime. The next section details the methodology for the case study, this is

followed by an examination of the results and a comparison of participants views and the

“true” picture.


Chapter 17. Case Study.

MethodologyAn area of approximately 10km2 of Leeds, West Yorkshire was covered. A background

reference map was produced in ArcView and exported as a JPEG of dimensions

400x400 pixels for use in the applets.

A web-site was set up at www.ccg.leeds.ac.uk/crime and www.cycletourer.com/applets.

For about two weeks, the system was open for input. Emails were distributed amongst

students and staff members in the School of Geography, and amongst several external

agencies and persons. On the start page (for printouts of web-pages see Appendices)

there is an introduction and instructions for use, with an animated GIF showing possible

inputs and uses of the spray.

Clicking to continue, participants fill in a small profile form, in order to see what type of

people use the system. After this, the main applet (sprayer) starts (see fig 17.1) Users

are asked to spray on the map an area or areas that they think have the most crime in

Leeds. Users are advised to make use of the ability to spray different densities, and write

comments about why they chose the areas. Users could tell us three things; the spatial

extent of the areas they think have the most crime, any relative differences within the

area(s), their reasons why and any other comments. The system was designed so that

users could spray and write comments about one area, then send their inputs and spray

another area etc. However users seemed to prefer to spray all the areas at once, and

write about them all at one go.

Clicking on the “continue to results page” the user is presented with an intermediate

page, saying “thanks” and giving information about the processing of their inputs.


Figure 17.1 Input Page (with Sprayer applet)

The Results page (see Figure 17.2), provides users with a composite map of all

participants inputs. By clicking on a particular place on the map, comments are

displayed for those users who have sprayed that area, sorted by density. A percentage

number in brackets is given representing the density or weight given by this user.


After this page, the user is asked to fill in a feedback form, with six questions evaluating

the system and the opportunity to send comments about the system. The questions

asked are shown below, users were allowed to answer the question with 5 possible

responses ranging from agree to disagree:

i. The system was easy to use and understand

ii. This type of system should be used more widely for public

participation

iii. I would prefer to go to public meetings on crime in Leeds

iv. This is a good way of seeing what others think about where crime is

in Leeds

v. More detailed information would have made the system better

vi. I see no benefit in using this type of system for public participation.

Figure 17.2 Results Page (with querySpray applet)


Throughout the system, people were given links to help pages, FAQs, instructions and

background information on the real picture of crime and PPGIS.

ResultsOver fifty users took part in the study. From the profile form, it was found that 62% of

users were male and 37% were female. The majority of respondents lived within Leeds

(86%) with 13% of users living outside of Leeds.

The spread of age ranges is illustrated in Figure 17.3.

Most users were

in the 20-24 and

25-29 age

bracket, which is

unsurprising

considering that

students

comprised the

largest

occupation group

(see Fig. 17.4).

P ro f ile : A g e R a n g e s

0

5

1 0

1 5

2 0

2 5

2 0 -2 4 2 5 -2 9 3 0 -3 4 3 5 -3 9 4 0 -4 4 5 5 -5 9 6 0 -6 4

n u m b e r

Figure 17.3 Age Ranges

Profile: Occupations

0

5

10

15

20

25

30

35

40

Acade

mic/

Educa

tiona

l

Cleric

al/S

ecre

taria

l

Stude

nt

othe

r

Profe

ssio

nal/M

anag

erial

Num ber

Figure 17.4 Occupations


From the fifty users provided input, four of these spray inputs were voided. However two

of those still entered comments. Figure 17.3 shows a sample of some inputs. See the

appendices for a full catalog of user inputs. One can see that there is a great difference

between different users. These can be compared with the comments for some

explanation for people’s choices (for example in Fig. 17.3, the image labelled 3500.gif

has the following comments “I have concentrated on speeding, burglary and street

crime”. However the main focus of the study is the composite or average view.

Figure 17.3 Examples of User Spray Inputs


The composite image is illustrated in Figure 17.4 (the “border” around the image was

removed using a graphics program), displayed with a stretch of 4 standard deviations,

and showing the crime rate for 2000/2001 per 1000 of the population. It can be seen,

that most participants thought that most crime was in the area of Hyde Park and Burley

areas, with concentrations also around Harehills and the City-Centre. To a lesser extent,

the area around Beeston, Armley and a swathe from the centre towards Chapel Allerton

were also selected.

The actual figures (see also fig 16.2) tie in quite well with the perceived view, with the

highest rate in the City and Holbeck ward, with University and Kirkstall Wards following

close behind.

It was noted that the concentrations of sprayings were centered around the points on the

map, labeling the neighbourhoods. Also, because the main student areas are in these

areas, and given the high proportion of students participating in the study, the composite

map could also display people’s knowledge of various areas.


Figure 17.4 Perceived Crime in Leeds and actual Crime Rate for 2000/2001Some comments are provided below, although the reader is directed to the online applet

to see how these vary with different areas. (See appendix for all comments)


� “chapeltown has a bad reputation hasnt it?”

� “Headingley/Hyde Park area marked for high burglary rates (claims about having themost burgled street in Britain etc.). Little London and Chapeltown (that’s what’smeant to be marked to North-east of Little London) have gang problems – have seenreports of shootings on local news. Have marked Beeston as I have heard from localpeople I have met that it’s a rough area. Harehills/Gipton has a lot of violent crimeand is a hotbed of racial tension. City centre has all the problems associated withany large city, muggings, shoplifting etc.”

� “Choices are made based on what I’ve ‘heard’ and from trying to find insurance forvarious locations in Leeds. Always been told that Harehills and Chapel Town arebad. Headingly just because of the vulnerability of students. Heard from insurancereport that LS2 9 has the most break and enters in the country.”

� “Headingley, students, mulitoccupation, so tempting for thieves. City centre, lot ofpickpocketing, some mugging. Other poor areas, less security, corner shopsvulnerable to crime, Crime on shops deflected from CBD by higher CBD premisessecurity. I’ve heard of cars being attacked whilst waiting at trafic lights on A64 yorkroad, but never seen this i drive a few times a week here. I still lock the car doorsafter dark while driving. Really didgy. ‘druggy’’ graffiti in Chapeltown terraced housesw of main road, Caribbean area. Dont know/hear of crime in better off areas”

� “Friend’s car got stolen in Hyde park so very aware of crime in that area. Only heardbad stuff about Beeston from friends living there, and from the media. My opinion isdefinitely dependent on other people’s perception’s as I haven’t ventured very farfrom Burley and the City Centre!!”

� “Wortley is very bad.”


Feedback on SystemAbout 27 users filled in the feedback form. Figure 17.5 summarizes the answers to the

questions. On the whole the answers were positive, with the strongest positive answers

were given to the question whether the system should be used more, and whether the

system was easy to understand.

The additional comments from the feedback form provided a very useful way for eliciting

user’s views. Twelve uses sent additional comments. Most were positive “well dones”. A

couple of users used this space to comment on the design of the system, pointing out

spelling mistakes, and layout issues. Many of the participants expressed an interest in

seeing how the output compares with the “real” picture. A couple of users wanted to

know if and how the inputs were to be used to target crime, or the fear of crime. One

user thought that the system should be specified to types of crime, instead of just

general areas with “most crime”.

Discussion of Case StudyThe results point out that the respondents’ view of where in Leeds has the most crime to

be quite accurate compared with actual crime figures. This may reflect the small sample

0% 20% 40% 60% 80% 100%

The system was easy to use and understand-

This type of system should be used morewidely for public participation

I would prefer to go to public meetings oncrime in Leeds

This is a good way of seeing what othersthink about where crime is in Leeds

More detailed information would have madethe system better

I see no benefit in using this type of systemfor public participation

agree

agree slightly

neither agree nordisagreedisagree slightly

disaggree

Figure 17.5 Answers to Feedback Questions


size, and the cross-section of people who used it. Since most users had a good

geographical knowledge, they perhaps had a more accurate view of crime in Leeds.

Because most users were students, the highlighting of the main student accommodation

areas could be a reflection of their knowledge. A few users mentioned that they were

only spraying about areas that they knew about. Some users did not know the situation

in some areas, and so did not spray that area. However, it could be a reflection that the

areas with the highest crime rates are known to the public, and that people do not

generally make gross mistakes in pointing out high crime areas – unlike the studies

mentioned in chapters 15 and 16, which assume that people misperceive crime.

It is thought that the system allowed some objectivity to enter into peoples thought

processes of where to spray. People were not asked to spray their own neighbourhoods

– and so an investigation of what people thought of their own area, compared with

others cannot be made.

The system proved very popular and received some positive feedback, with ease of use

being the most common comment. The importance of a good web-site and design of

supporting materials was important.

Further workAs mentioned earlier, it was noticed that people sprayed around the points that labeled

the map. This could mean that people didn’t actually know the extent of a particular area.

These points could “lead” people to spray in certain areas. It was noticed that Chapel

Town (a notorious area of Leeds) was not labelled on the map, and consequently, some

people may have sprayed around the nearby label Chapel Allerton (quite a difference

socially). Perhaps the removal of points, but keeping labels from the map might be wise

for future studies.

The applets could be adapted to so that users could spray different colours – perhaps

looking at different types of crimes, or areas of comfort and areas of fear.

Obtaining a good cross section of people, ages and experience of Leeds, is necessary

for a “public” exercise. Perhaps studies could be used for different neighbourhoods. I.e.

residents from Burley were asked to spray where they thought, and then compared to


residents from Seacroft. For this to work, there needs to be a stronger connection

between the profile page and the input page, or to develop separate pages depending

on which neighbourhood they lived in.

Conclusion of Case StudyOver 50 participants were asked to spray areas where they thought had the most crime

in Leeds. They used a new PPGIS using a spray-can tool, and were able to write

comments about why they chose the areas they did. The majority of users were under

34 years of age, and students or academics. The results indicate that the combined view

of all the participants of crime in Leeds matched official statistics quite well, with the

highest concentrations in the Hyde Park and University areas. This may reflect the fact

that most users were students, living in those areas.

Overall, the system got a positive feedback. Future improvements could involve looking

at how participants from different neighbourhoods and or different ages, occupations etc

affect the results. A better cross-section of people from all of Leeds would give a better

picture.

PART D: Discussion and ConclusionsChapter 18. Discussion, Limitatations and Improvements

The case study showed how the applets and system could be successfully applied, and

highlighted some possible changes. The following paragraphs outline some

improvements to the system. It must also be borne in mind that for some cases,

increasing the functionality may also increase the complexity of the system, and hence

may possibly decrease its ease of use.


The addition of a function in the Results applet, where a user can click on a comment

and that person’s input image could be displayed, could be useful in interrogating the

particular areas that go with each comment.

As mentioned above, and used by Matei et. al. (2001) the applet could be changed so

that users could use different colours to represent different things. For example different

colours for: areas where car crime is highest, areas safest at night, during the day, run

down areas etc. For an environmental application: areas that are polluted, beautiful,

noisy, smelly etc.

There may be a need to have a stronger connection with the profile page, so that the

user ID is also tied in with the profile. This would make the analysis of the results for

different groups of people easier. However, some people may not like inputting profile

information – it does to some extent invade upon ones anonymity, and if a user wants to

go back at a later date and enter another area, the requirement to fill in the profile form

again could be a seen as a hindrance.

A simple admin applet (AdminImage.java -see appendix for code) was developed to

facilitate the enlarging and saving of all the user images, and to get and save the current

composite image. This needs to be developed upon so that individual entries can be

removed from the system. For example in the case study, 4 users did not spray anything

on the Sprayer applet (or if they did, something went wrong), but two of these wrote

comments. The removal of their entries from the composite image array would also

entail the deletion of any comments they made. Perhaps some checking to see if users

have actually sprayed onto the panel before sending is required. The inclusion of blank

images has some effect on the average, however because the final image is an average,

the effect would be negligible. This also applies to “joke” entries. Although these were

not present in the case-study, one or two would, to some extent be literally

overshadowed by serious entries. The comments logs can be edited manually, although

it may be prudent to have some kind of censor to check for common swear words and

asterisk them out.


The borders around the composite map, created due to the edge effect of the kernel

operations, DensityOp and BlurOp, also needs to be addressed. I had to manually

remove the boundaries after downloading the image. Perhaps some form of cropping is

needed.

From the discussion in Chapter 5, some issues were brought up that relate to the design

of the map. How much information is needed? The case study highlighted a possible

bias caused by the placing of points for the labels. Should no labels be used at all? The

case-study assumed a level of knowledge about the layout of Leeds. The labels were

used to help people orient themselves. Perhaps neighbourhood boundaries should be

drawn in with a label in the middle of them.

On a more technical note, the applets need to be made more portable. The use of HTML

param tags to set up environment variables, for example the path to the CGI-bin

directory and the name of the background map. The applets layout type should be

changed in order to facilitate the use of different sized maps.

As the results applet has to load and process a lot of data before showing anything other

than a gray box in the browser window, and the time increases bit by bit as more people

use the system, a small progress form window would help reassure users that the applet

hasn’t crashed.

As explored in the design and development section (chapter 11), the bug with Netscape

proves a significant handicap for a system that is meant to encourage the public in

decision making processes – it excludes those users who can only use the Netscape

Browser. Whether the bug is in Netscape or in the applets is irrelevant, a workaround is

needed. The workaround may be a change from the string array that holds each user

input into a normal text file. However, the nature of Netscape’s cache, as described in

Chapter 11, may involve the use of CGI scripts with special headers to request and send

the files (instead of the normal web-server).

The use of server-side processing is encouraged, particularly for the creation of the

composite image. This needs to be researched in further detail, as there are perl image-

processing libraries available.


Chapter 19. Conclusions

Two applets and several Java classes were developed based on a spray-can tool. This

enabled an easier and more intuitive method for people to input spatial data, than using

traditional GIS techniques. The spray can tool can be used to define the spatial extent of

areas and any relative differences within and between areas, by changing the density of

the spraying. The system was developed for use in a web-based public participation

setting. A review of Internet GIS, and web-based Public Participation GIS (PPGIS) was

presented. The use of the Internet has several advantages over traditional public

participation techniques.

The software design and development process was described in detail, and followed the

software development model “Waterfall model with Iterations and Small Forward Steps”.

System requirements, use cases and UML were also produced. The software was

tested, and bugs were described. One major bug has meant that the system is not

currently stable with the Netscape Browser.

The system was applied in a case study looking at people’s perception of crime in

Leeds. Background studies on the perception and fear of crime were presented. The

case study was mainly concerned with there in Leeds people thought had the worst level

of crime, why they thought that, and where in fact it does occur. The results indicate that,

contrary to other studies, the perception of crime matched the actual crime statistics

quite well. User feedback was very positive.

Limitations and some future amendments to the system were reviewed, and include

plenty of scope for customization. Overall the Java system was successful, the spray-

can tool proved to be quite intuitive and easy to use, whist providing good quality

information.


Bibliography

Al-Kodmany Kheir 2001, Online tools for public participation Government InformationQuarterly 18 (2001) 329–341Bartnicki, S.P 1989 Crime in Poland: Trends, regional patterns and neighbourhoodawareness. In The Geography of Crime Edited by David J EvansAnd David T Herbert 1989 Routledge London.

Box, Steven, Hale, Chris, and Andrews, G. 1998 Explaining Fear of Crime Brit J.Criminology Vol 28 no 3 Summer 1988

Brandon, Plewe, 1997, GIS online : information retrieval, mapping, and the Internet.Santa Fe, NM : OnWord Press, 1997

Burrough & mcdonnell

Carver, S; Evans, A; Kingston, R; Turton, I. 1998. Geographical Information Systemson the World Wide Web: improving public participation in environmental decisionmaking. Paper presented at the European Association for the Study of Science andTechnology Conference, Lisbon, Portugal

Cinderby, Steve. 1999 Participatory Geographic Information Systems (GIS):The future of environmental GIS? International Journal for Environment and Pollution11 (1999) 304-15

Clarke, G. Debenham, J & Poole,R. 2001 An Analysis of Crime & Disorder in Leeds1997/98–2000/01 School of Geography, University of Leeds from:http://www.leedsinitiative.org/initiative_data.asp?initiative=communitySafety&viewMenu=activities&article=33

Craig, w. Harris, T.M, & Weiner, D. 2002 Community Participation and GeographicInformation Systems. Taylor & Francis, London.

Cullingworth, B., 1993, The Political Culture of Planning: American Land Use Planningin Comparative Perspective, London: Routledge

Debenham J., 2001, Comparing recorded crime levels with perceptions of crime, inAnalysis of Leeds Crime Audit, School of Geography, University of Leeds. Published onLeeds Community Saftety, www.leedsinitiative.org

Efford, N. 2001 Digital Image Processing: a Practical Introduction using Java.Addison-Wesley, Harlow.

Evans, D.J, & Herbert D.T 1989 The Geography of Crime Routledge London.


Garofalo 1981 The fear of Crime: Broadening out own perpspective Victimology, 2:242:53

Ghose, R. 2001 Use of information technology for community empowerment:transforming Geographic Information Systems into community informationsystems. Transactions in GIS 5(2) 141-163

Grand, M. 1998, Patterns in Java, Volume 1: A catalog of Reusable Design PatternsIllustrated with UML.

Haklay, M. E., & Harrison, C. 2002 Public Participation in the UK and the USA: Across cultural analysis 2002m presented at the 98th AAG Annual Meeting, LosAngeles, California, 19-23 March

Harris T.M., Weiner, D., Warner, T. and Levin R., 1995, Pursuing Social Goals ThroughParticipatory GIS: Redessing South Africa’s Historical Political Ecology, Pickels, J.(Ed.)Ground Truth: The Social Implications of geographic information systems , New York:Guilford Press. 196-222

Herbert D.T. 1982 The Geogrpahy of Urban Crime, Harlow, Longman

Home Office 1989 Standing Conference on Crime Prevention, Report of the WorkingGroup on Fear of Crime (11.12/89) London, HMSO)

Horstmann, C. 2000 Computing Concpets with Java 2 Essesentials (2nd ed) J. Wiley& sons, New York.

Kingston, R, Carver, S., Evans, A., Turton, I. 2000, Web-based Public ParticipationGeographical Information Systems: an Aid to Local Environmental Decision-MakingComputers, Environment and Urban Systems, 24 (2000) 109-125

Kingston 2002 The role of e-government and public participation in the planningprocess XVI AESOP CONGRESS VOLOS, GREECE JULY 10th –14th 2002

Laurini and Pariente 1996 “Towards a Field-orientated Language: First Specifications” inBurrough & Frank (eds) Geographi Objects with Indeterminate Boundaries, 1996, Taylor& Francis, London.

Matei, S., Ball-Rokeach, S, J. & Qiu, J.L 2001 Fear And Misperception Of LosAngeles Urban Space: A Spatial-Statistical Study Of Communication-ShapedMental Maps in Communication Research, Vol. 28 No. 4, August 2001 429-463

McGill, 2001 GeoTools Java GIS package from www.geotools.org

Pickels, J. (Ed.) 1989 Ground Truth: The Social Implications of geographic informationsystems , New York: Guilford Press.

Ploger John, 2001, Public Participation and the Art of Governance in Environment andPlanning B: Planning and Design 2001, vol 28, p219-241


Poskanze, J. 1998 The ACME java packages http://www.acme.com/java/

Sun Corp. Java 1.4 API documentationJava.sun.com online tutorials

University of British Columbia - 2000 - Personal Security Mapping Project: A jointproject for the Alma Mater Society & the Personal Security Coordinator’s OfficeWWW.SAFETY.UBC.CA

Williams , P. & Dickinson, J. 1993 Fear Of Crime: Read All About It?The Relationship Between Newspaper Crime Reporting And Fear Of Crime. BRITJORNAL OF CRIMINOLOGY VOL 33. NO1 WINTER 1993

Some Internet References:

A virtual slaithwaitehttp://www.ccg.leeds.ac.uk/slaithwaite/

woods Woodland Online Decision Support Systemhttp://www.ccg.leeds.ac.uk/dales/Baseline Geographicswww.baselinegeo.com

Networking with Javahttp://www.isavvix.com/community/pubs/javanet/index.shtml.This article was originally published in the Dr. Dobb's SourceBook, Sep/Oct 1996.Copyright © 2000 iSavvix corporation

Java Forums : java.sun.com


AppendicesContents

Java Code ListingsSprayer........................................................................................................................SprayPanel..................................................................................................................Sender.........................................................................................................................ImageArray..................................................................................................................DensityOp ...................................................................................................................QuerySpray .................................................................................................................QSortAlgorthim............................................................................................................ImageTranPanel..........................................................................................................BlurOp .........................................................................................................................

Perl CGI Code Listingstestarr.pl ......................................................................................................................testlog.pl......................................................................................................................imagesave.pl ...............................................................................................................sprayfeedback.pl .........................................................................................................profile.pl.......................................................................................................................

Log FilesComments Log............................................................................................................Feedback Log..............................................................................................................Profile Log ...................................................................................................................

WebPagesindex.html....................................................................................................................start.html .....................................................................................................................sprayer.html ................................................................................................................help.html......................................................................................................................info.html.......................................................................................................................thanks .thtml................................................................................................................queryspray.html...........................................................................................................feedback.html …………………………………………………………………………..

JavaDocs………………………………………………………………………………….. 164

A Java Public Participation GIS ... - University of Leeds · Internet GIS and the application of...

Documents

Transcript of A Java Public Participation GIS ... - University of Leeds · Internet GIS and the application of...