A Study in the Development of Citizen Science based GIS Web Mapping Applications for use in Natural Resources Management during the Web 2.0 era. by Matthew Rahr

ovenforksqueeSecurity

Nov 3, 2013 (4 years and 1 month ago)

324 views

A Study in the Development of Citizen Science based
GIS
Web Mapping Applications for
use in Natural Resources Management during the Web 2.0 era.



by


Matthew Rahr













A Thesis
Submitted to the Faculty of the


SCHOOL OF
NATURAL RESOURCES AND THE ENVIRONMENT


In Partial Fulfillment of the Requirements

For the Degree of


MASTER OF SCIENCE

WITH A MAJOR IN
NATURAL RESOURCES


In the Graduate College


THE UNIVERSITY OF ARIZONA




2011


2



STATEMENT BY AUTHOR



This thesis has been submit
ted in partial fulfillment of
requirements for an
advanced degree at The University of Arizona and is deposited in the University Library
to be made available to borrowers under rules of the Library.



Brief quotations from this thesis are allowable without special permission,
provide
d that accurate acknowledgment of source is made. Requests for permission for
extended quotation from or reproduction of this manuscript in whole or in part may be
granted by the head of the major department or the Dean of the Graduate College when
in his

or her judgment the proposed use of the material is in the interests of scholarship.
In all other instances, however, permission must be obtained from the author.




SIGNED:












APPROVAL BY THESIS DIRECTOR

This thesis has been approved on the date shown below:














David Phillip Guertin, PhD




Date


Professor of
Watershed Science


3



ACKNOWLEDGEMENTS



4



DEDICATION



5



TA
BLE OF CONTENTS

Chapter 1:

INTRODUCTION

................................
................................
...........................

10

1.1 Summary of Applications

................................
................................
........................

13

1.2 Scientific Problem
................................
................................
................................
....

14

1.3 The Goal

................................
................................
................................
..................

14

Chapter 2:

YUMA
PIN MAPPING APPLICATION

................................
............................

15

2.1 Background
................................
................................
................................
..............

15

2.2 Problem

................................
................................
................................
...................

16

2.3 Objective and Design Specifications s

................................
................................
.....

18

2.4 Application Workflow
................................
................................
..............................

19

2.
5 Software Components
................................
................................
.............................

22

2.6 Application Development and Implementati on

................................
.....................

24

ArcIMS Architecture
................................
................................
................................
...

25

ArcIMS Development

................................
................................
................................
.

27

Web
-
Data Interface Development

................................
................................
............

33

Application Tier

................................
................................
................................
..........

35

Data Tier
................................
................................
................................
.....................

37

Presentation Tier

................................
................................
................................
.......

38

2.7 Conclusion

................................
................................
................................
...............

39

Chapter 3:

WHITEFLY MAPPER

................................
................................
.....................

43

3.1 Background
................................
................................
................................
..............

43

3.2 Problem

................................
................................
................................
...................

43

3.3 Objective and Design Specifications

................................
................................
.......

45

3.4 Application Workflow
................................
................................
..............................

45

Whitefly Map

................................
................................
................................
.............

47

CYSDV Map

................................
................................
................................
................

52

3.5 Software Compo
nents
................................
................................
.............................

53

3.6 Application Development and Implementati on

................................
.....................

54

6



TABLE OF CONTENTS
-

CONTINUED


ArcGIS Server Architecture

................................
................................
........................

55

Developing a Map Service

................................
................................
.........................

56

Silv
erlight Development

................................
................................
............................

57

Software Classes

................................
................................
................................
........

59

3.7 Conclusion

................................
................................
................................
...............

60

Chapter 4:

CONCLUSION

................................
................................
...............................

63

Chapter 5:

Works Cited

................................
................................
................................
.

67

APPEND
IX A


YUMA PINMAP INSTRUCTIONS

................................
................................
.

69

APPENDIX B


YUMA PINMAP APPLICATION CODE

................................
........................

84

PinmapDAO.cs

................................
................................
................................
...............

84

SystemProcessor.cs

................................
................................
................................
.......

89

Validator.
cs
................................
................................
................................
....................

91

SQLKeys.cs

................................
................................
................................
.....................

93

Login.aspx

................................
................................
................................
......................

94

Login.aspx.cs
................................
................................
................................
..................

95

Crop.cs

................................
................................
................................
...........................

97

Grower.cs

................................
................................
................................
......................

97

ArcIMS AXL Configu
ration File

................................
................................
......................

98

ArcIMS Parameter File (ArcIMSparam.js)

................................
................................
...

103

APPENDIX C


WHITEFLY TRACKER

................................
................................
...............

113

Index.html

................................
................................
................................
...................

113

MainPage.xaml

................................
................................
................................
............

115

MainPage
.xaml.cs
................................
................................
................................
........

116

WhiteFlyMap.xaml

................................
................................
................................
......

117

WhiteFlyMap.aspx.cs

................................
................................
................................
..

122

CYSDV.aspx

................................
................................
................................
..................

125

7



TABLE OF CONTENTS
-

CONTINUED


CYSDV.aspx.cs
................................
................................
................................
..............

128

Styles.xaml
................................
................................
................................
...................

131

ErrorWindow.aspx
................................
................................
................................
.......

136

ErrorWindow.aspx.cs

................................
................................
................................
..

137




8



LIST OF FIGURES

Figure 2.1: Yuma Seed Growers Pinmap located at the Yuma County Extension Office
circa 2001

................................
................................
................................
..........................

17

Figure 2.2: A successful password grants access to the pinning map

..............................

20

Figure 2.3: Detailed view of pins
................................
................................
.......................

21

Figure 2.4: Enter attribute information associated with pin

................................
............

22

Figure 2.5: ArcIMS Architecture
................................
................................
........................

27

Figure 2.6: Yuma Pin Symbology
.
................................
................................
......................

29

Figure 2.7: Yuma Pinmap Database Schema

.......................

Error! Bookmark not def
ined.

Figure 2.8: Summary of Mapping Architecture

................................
................................

34

Figure 3.1: Example of field
survey activity during February
.

................................
..........

44

Figure 3.2: The Whitefly Tracker Website
homepage.

................................
.....................

46

Figure 3.3: Whitefly Mapping Application
-

Main Window

................................
..............

47

Figure 3.4: View data by “Whtiefly Presence” or “Virus Diagnosis”

................................

48

Figure 3.5: Data shows presence in cultivated crop lands during summer months

........

49

Figure 3.6: Adjust Time Slider

................................
................................
...........................

49

Figure 3.7: Data shows migration movement into urban areas during winter months
...

50

Figure 3.8: Data located at the same location can be viewed by hovering over the
number. Results are then shown in on the spokes.

................................
.........................

51

Figure 3.9: Hovering over the specific spoke shows a detailed pop up of the particular
sample.

................................
................................
................................
..............................

51

Figure 3.10: 2008 CYSDV Presence Map

................................
................................
...........

52




9



ABSTRACT


Abstract must be limited to 150 words, and should be double spaced.



10



Chapter 1:

INTRODUCTION

Throughout the last decade, there has been a major evolution in the World Wide
Web. Prior to

the early 2000’s, the web was strictly a media to publish content. This
content
,

much like an edition of a book, remained static until the author actively posted
newer content. Users visiting the website were limited to passive viewing of the content
that

was created for them. There was no interactivity. Then, in the mid 2000’s a new
platfor
m, considered “Web 2.0”
evolved
,

allowing users to do more than just retrieve
information. Users could generate their own content, share that content with others,
allo
w viewers to interact with the content, and collaborate with others at any time,
from any place. Applications that leveraged this new technology emerged, such as social
networking sites, blogs, wikis, photo and video sharing sites. People with similar
inte
rests could form virtual communities to share ideas online.


“Web 2.0” applications depend on users’ content. In essence, the application
only needs to provide a platform to allow users to add and manage their contributions.
The real value is in the data
generated by the user. A good example of this is Facebook
(
www.facebook.com
).
Facebook’s success is dependent on its user
-
base and the
information people share. If users neglect to participate, the application loses
value and
eventually fails. The key to enticing users is to provide a clean, easy
-
to
-
use interface for
content management. One could argue that competing social networking sites such as
Friendster and Myspace lost
its

user
-
base to Facebook for these reason
s

(Gillette, 2011)
.

11



Other factors remain such as the assurance that the data is secure, privacy can be
controlled, and that the data provided does not get used for unintended purposes.

Another key element to the success of the

“Web 2.0” evolution aligned with the
evolution of mobile devices and mobile internet. Cell phone technology has improved to
the point where adding new content to web
-
based applications is easy and convenient.
Twitter is an excellent example of merging Web

2.0 and mobile devices. Twitter
provides the ability for users to post a short message to their twitter page through their
cell phones via SMS text messaging or data (IP based) network. As network providers
improved their data network, other web applicati
ons that depended on the bandwidth,
such as Facebook and Flickr, developed applications that interfaced with their websites.
No longer did users have to wait to get in front of a computer to post new content.

Many of today’s mobile devices include
Global
Positioning Systems (
GPS
)
, which
some argue is a crucial element to

the next evolution in Web 3.0
(Lucier, 2009)
.
A GPS
enabled mobile device allows users to associate a location with the contributed content,
also known as “geo
-
tagging”. Photos and videos taken from cell phones are
automatically tagged with a
location

can be quickly added to an online map. Messages
po
sted from Twitter can also be tagged. The ability to know where an observation takes
place and
simultaneously

disseminated in real time promotes a wide variety of social
benefits. Examples include search and rescue efforts, natural disaster response,
repor
ting of social injustices and environmental disasters,

and

organizing political rallies.

12



Amid the evolution in the Web, scientists recognized that “Web 2.0” technology
could be leveraged in their research. Hardware and software
-
based tools were already
av
ailable for fellow scientists to capture data, (
e.g.

sensors, measurement tools). But
these tools had traditionally been
confined

to
a lab or controlled space. Remotely
sensed data allowed for greater freedom of data capture, and the Internet greatly
impro
ved on the distribution of remote sensors, but the area being observed was still
fixed. The general public, as a data collection tool, had not been considered. The
“public” is well distributed and is attuned to identifying observations. With the addition
a
nd wide
-
spread adoption of social media
,

along with mobile devices, the technology
used to report data is familiar. Any person with an internet connection and a willingness
to participate could be a sensor and contribute their observations.

The concept of

“Web
-
as
-
participation
-
platform” touches on every facet of
science
-
based web development, from formal instruction, through rese
arch, to
extension

(Hutchinson, 2009)
.

Web
-
based applications, based on the same principles of
Web 2
.0, became more prevalent. Applications such as rainlog.org

(SAHRA, 2011)

and
projectnoah.org

(Networked Organisms, 2011)

completely relied on data from the
public. Soon the term “citizen scientist”

was coined, referring to anyone who
contributes and provides data
through

public driven applications. Throughout my
graduate and professional career, I’ve developed a range of citizen science based
applications, utilizing different technologies, software platforms, database structures,
13



but with the same common goal: Give the pub
lic the ability to contribute location
-
aware
data and observations
.

In this paper I

describe
two

major examples of citizen science based applications
that I have developed. These applications range from early 2000’s to work that is still in
development (20
11) that
highlights

the evolution shifts in the technology that they were
built on.

1.1 Summary of Applications



Yuma Pinmap


The Yuma Pinmap is an online mapping web application that
allows users to digitally
map

the locations of varying crops in the ag
ricultural
valley of Yuma, AZ. Each

year, companies that manufacture and sell produce
seeds contract with local land owners and growers in
Yuma

to produce the
company’s seeds. The Yuma Pinmap allows the growers to map their farm’s
location

and
identify

the

type of crops that are grown there
. Each
location

contains a digital marker, which

represents a
contract

between a

seed company
and a local land owner/grower. By knowing these locations, growers can
maintain

a safe

distance
-
buffer

between cross
-
pollinatin
g crops, which can ruin
the quality of the crop.
Developed in 2001
, the
Pinmap

uses ArcIMS and ASP.Net
technologies to run a peer
-
driven data sharing application
.

Is the application still
being
used
.


14





Arizona Whitefly Tracker


Silverlight API

and
Campus Enterprise GIS


ESRI
mapping API’s, multiple clients

expand

1.2
Scientific Problem

By identifying changes in the evolution in citizen science based

mapping

applications, including their strengths and weaknesses, a
long with changes in
technology,
wh
at are the best practices
for

d
eveloping these applications?


1.3
The Goal

By investigating the strengths and pitfalls of evolving citizen science based
mapping
applications, I can develop a better understanding of what works, and
incorporate these design

and development patterns into our next
-
generation
applications
.

Design elements that will be examined include:



Three
-
Tier Programming Pattern



Internet Mapping Technologies
: ArcIMS
vs.

ArcGIS Server



Distributed Server Architecture



HTML and
JavaScript

best

practices



SOAP
vs.

REST software architecture



Microsoft Silverlight technology



Cultural and other non
-
technical issues affecting the adoption of technology


15



Chapter 2:

YUMA PIN MAPPING APPLICATION

2.1 Background

Yuma
, Arizona

is located in the Southwest corner of
Arizona
,
near the A
rizona
-
California state Border,

which is separated by the Colorado River. Due to
its

proximity to
the Colorado River, Yuma is known for having rich, deep and fertile river bottom soils.
Water from the river provides 175,000 acres or irri
gable land.
Yuma’s

warm climate
allows for a 350 day growing season, with sunshine 95% of the year

(Greater Yuma
Economic Development Corporation, 2009)
. Because of these favorable conditions,
Arizona ranks 2
nd

nationally in
it
s

production of cantaloupe & honeydew melons, head &
leaf lettuce, spinach, br
occoli, cauliflower and lemons

(United States Department of
Agriculture, 2010)
. D
uring winter months,
Yuma
produces over 90%
of leafy greens for
the
nation
(Boriss & Brunke, 2005)
.
Yuma is the top agricultural area in Arizona for
growing vegetables and melon
species
.

Yuma

is

also a major agricultural hub for
the production of

vegetable
seeds
. That
is, growers grow plants f
or the pure purpose of
seed harvesting
. The

vegetable seed
season in Yuma is
relatively short, but Yuma growers
are able to start production during
winter months, much earlier than other locations in the U
nited
S
tates
, which are forced
to start in the spring. Since Yuma seeds are available on the market earlier than seed
growers from elsewhere, Yuma growers have a distinct
advantage in the market
.
Because of this, seed companies from all over the world look to Yuma to
pair with local
growers to help grow their particular company’s variety of seed.

16



2.2
Problem

Prior to the growing season, seed companies hire growers in Yuma to grow their
specific variety of seed. There are many factors involved when a seed company choos
es
a grower; costs, available acreage, harvesting capabilities
, etc
.
However, the

production
of a pure and successful seed also requires the prevention
of
cross
-
pollination
between

compatible crops. Therefore, seed companies must also consider what seeds a
re being
produced in neighboring farms.

For example, if a grower partners with a seed company
to produce broccoli, and the neighboring grower agrees to grow
cauliflower
, both
companies’ seeds are at risk of producing a cross
-
bred seed that is unfavorable
in the
market.

Coordinating and tracking the partnership of seed companies and growers is a
necessity for all stakeholders. Historically, this coordination was accomplished by
placing an 8 x 12 foot map of the growing area on a wall of the Yuma County Ext
ension
Office. The map allowed participating growers and seed company representatives to
locate their fields on the map and mark them with colored pins, coded for each crop and
each participant

[Figure 2.1]
.

A registry was also made available to document t
he work
accomplished on the map. It allowed the Cooperative Extension to keep a current
mailing list of the participants, and inform the participants about the evolution of t
he
pinning map during the year.

17



On a routine basis (sometimes multiple times a day
), seed growers would drive
to the Office and place pins on the map to stake claims on where they intended to
produce seed crops
.
The system was entirely self
-
enforced with no outside monitoring
.
.


Figure
2
.
1
: Yuma Seed Growers Pinmap located at the Yuma County Extension Office
circa 2001

use the same font as text.

Although this was a successful system, it did have some difficulties. Because the
map was physical, pi
ns could be inadvertently moved,
fall off t
he map or “disappear”.
Sometimes pins would “float” to discourage competing seed companies from staking
claim to neighboring areas.

Sometimes data associated with dates and timing of pin
18



placement
w
as

not accurate. Moreover, most of the participants had to

drive more than
an hour to get to the map, with several traveling from
other states or countries. Travel
time was a severe handicap for participants who did not have convenient access to the
paper map because, during some periods, it was worthwhile to vis
it the map several
times a day. Those who had staked prior claims removed pins from the map, opening up
planting possibilitie
s in congested areas.

2.3
Objective

and Design
Spec
ifications

A new
,

digital
,

pinmap was created to solve
eight

major shortfalls with the wall map
.

They are as follows:

1.

Make the map available online, so that stakeholders can access the map from
anywhere without having to physically drive to the Yuma County Extension
Office.

2.

Assist stakeholders in maintaining isolat
ion areas necessary to prevent cross
-
pollination in seed crops.

3.

Make the map secure, so that only stakeholders can
view

the online map
.

4.

Allow seed company representatives to add, move, or delete pins to the online
map once a contract has been negotiated w
ith a grower.

5.

Prev
ent stakeholders from pinning a field if a claim has

been previously made.
This is in order to prevent cross
-
pollination
.

19



6.

Create geospatial measuring and buffer tools that allow stakeholders to
determine cross
-
pollination areas.

7.

Maintain
a historical record of each pin, with a time and date, to dispute claim
rights and pin movements

8.

Th
e
Pinmap

does not
try

to enforce isolation. The application only provides
information and tools to assist stakeholders.

It is the stakeholders’ responsibilit
y
to maintain seed separation.

2.4 Application Workflow

The new online
Pinmap

has a straight
-
forward workflow.

1.

The user
visits the online
Pinmap

portal
by going to
http://cals.arizona.edu/minu/pinmap/

2.

The user selects
the link to

the current map, or historical maps from previous
years
.

3.

The user is prompted for a username and password. This password is shared by
all stakeholders and allows
the user

to only view and query the map and its data

[
Figure
2
.
2
]
.

This prevents non
-
stakeholders from viewing the location of seed
companies’ claims.

20




Figure
2
.
2
: A successful password grants access to the pinning map

4.

The user zooms to the field
in which he/she wishes to stake an isolation claim.

[
Figure
2
.
3
]

21




Figure
2
.
3
: Detailed view of pins

5.

The user selects the pinning tool from the toolbar, and then clicks on the desired
fi
eld.

6.

A new login page appears, asking for the seed company
’s

password. This unique
password is created for each seed company
.

7.

A new page shows the data entry page. This page is used to attribute the pin. It
contains the seed company, the grower, the township, range, section, and UTM
coordinates, a pin
-
id,
the type of crop, the amount of acres planted, and the

t
imestamp

[
Figure
2
.
4
]
.

22




Figure
2
.
4
: Enter attribute information associated with pin

8.

The “Submit Data” button is clicked. A pin is added to the map, and
is symbolized
by two

colors: one for the seed compan
y, another for the crop type.

Other workflows exist for navigating the map, querying the pins, and measuring and
buffering distances between pins to determine isolation areas.
See Appendix

A

for
detailed ins
tructions.

2.5
Softwa
re Components

The Yuma Pinmap required
six

major components:

1.

Database
:
Microsoft SQL Server 2005

is

used
as the primary database to store
both the geographic attribute information for the pins (coordinates) and the
related user attribute information (crop type, seed co
mpany, etc
.
).
Microsoft
23



SQL Server 2005
does

not contain a native geographic data

type to store points,
lines or polygons. Therefore, ESRI ArcSDE was installed within
SQL Server

to
enable the storage of GIS data within the database.
The result is
termed

a
s an
“SDE
G
eodatabase”.

2.

Geographic Information System:
ESRI
ArcI
nfo

9.3

is

used
as the GIS toolset
to
perform the necessary topology checks between isolation areas
to create pins
derived from

the mapping service and
insert them into
the geodatabase.

3.

Internet Mapping
Server: ArcIMS provides a platform for delivering raster and
vector GIS data across the Internet. It allows the user to view and query the pins,
provide clickable base layers and background imagery, within a map that can be
zoomed or panne
d interactively. The user need
s

nothing more than a web
browser.

4.

Java Servlet Engine
: A java servlet engine is required by ArcIMS to pass XML
requests
and responses
between the web browser and the
ArcIMS application
server.

5.

Web Server
: Microsoft IIS is u
sed to deliver

the

web pages and images

created by
ArcIMS and send them
to the web browser via HTML, and to support ASP.Net, a
server
-
side scripting language used to generate dynamic web content and
provide an interface to the geodatabase.

6.


ASP.Net
web
ser
vice

that deliver
s

data input from the user’s web session to the
database.

24



2.6
Application

Development and Implementation

Development of t
he Yuma Pinmap
began

in 2000
. At that time, online mapping
and the delivery of geographic information was a budding
part

of the Internet
(American
Documentation Institute, American Chemical Society. Division of Chemical Literature,
American Society for Information Science, Special Libraries Association, 1998)
.
Some of
the

most popular

onlin
e mapping resources at that time
included

MapQuest
(
http://mapquest.com
), released in 1996, which provided navigation road maps and
turn
-
by
-
turn directions, and TerraServerUSA, released in 1998, which delivered black
and

white aerial imagery of the United States. Neither service
provided

a mechanism for
utilizing

their data

in a
3
rd

party

application
, known as a mashup
. The first mapping
mashup conventions

provided by

Google and Bing would be
developed

5 years later.

Initially, our development team in the College of Agriculture and Life Sciences
utilized a static, non
-
zoomable Landsat image of Yuma, AZ as the map
’s

base layer. The
team created an HTML image map to give the map some interactivity. The

HTML

image
map cre
ated an invisible

lattice of 40
acre polygons

over the Landsat image
. Each
polygon
in the image map
contained a hard
-
coded URL, which linked to a server
-
side
Perl/CGI script, along with a querystring identifying the id of the particular polygon.

This
scrip
t would take the id of the querystring and match it to an id in a database, where
more information about the polygon could be captured (
eg:

what crop is growing, which
seed company is using it, etc
.
).

25



Because of the map’s lack of zooming o
r panning, the pr
oject was deemed
un
adoptable by the stakeholders. Later t
hat year, ESR
I
released ArcIMS 3.0, a web map
server that provided a way for programmers to create multi
-
layere
d maps, server them
across the I
nternet, and provide tools for zooming, panning, and que
rying the data. It
was determined that by leveraging ArcIMS 3.0, the
Pinmap

would meet the
stakeholders requirements.

ArcIMS Architecture

Application Server:

The main software piece of the ArcIMS
platform

is the appli
cation
server, which handles
the spatial related operations, including mapping, zooming,
querying,
and
buffering.

Developers begin by
building a configuration file (known as an
AXL file) that contains a list of the spatial
layers

used in the online map. This
configuration file contain
s the

file

location of each spatial layer (a shapefile or feature
class in a geodatabase), the
order of the spatial layers
,

and how each layer should be
cartographically symbolized. The configuration file is saved and registered
with the
application server

for use by connector applications. The application server is a stateless
machine
, meaning the server does not track the client’s mapping session. (In simpler
web applications, a client’s “state” can be managed using cookies). T
herefore a map
service is al
ways in the same state (layer visibility, layer order, layer representation, etc
.
)
as when it is defined in the configuration file. The result of this design is
that
a

web
bro
wser

must define a new
state
each time the user pans, zooms, or hides/shows a
lay
er
.

E
ach request contains parameters identifying the bounding XY coordinate
s

of the
26



map and the layers that require map display. These parameters and other
communication between the application server and clients are composed in ArcXML, an
ESRI flavored ve
rsion of XML
, via the Simple Object Access Protocol (SOAP). SOAP
provides a messaging framework
between the client and the application server
.

The
application server exposes three public servers to requesting clients; they are extract,
feature, and image.
An extract server responds to a request by creating a Zip file
containing shapefiles, and makes it available for download. The feature server responds
to a request by delivering a binary stream of data to the requesting client. The image
server responds to

a request by creating an image file that can

be displayed in a web
browser.

Connector:
The default connector for ArcIMS is the Java servlet connector. The servlet
passes ArcXML requests from a calling application, usually a web browser, onto the
applicati
on server and returns the ArcXML response. The servlet connector is not able to
process or modify the request/
responses;

it simply acts as a conduit. All clients to the
servlet connector must be able to compose and parse valid ArcXML requests and
response
s
. [
Figure
2
.
5
]

HTML Viewer:
The HTML Viewer is provided with ArcIMS and consists of almost 10,000
lines of JavaScript code that are able to construct and parse ArcXML requests and
responses. From the user’s point of view, it provides

the user
-
interface for displaying
27



and interacting with the map. It also provides many of the familiar map tools that allow
users to interact with geospa
tial data within a web browser.


Figure
2
.
5
: ArcIMS
Architecture.

A web browser makes requests to the web server via the
internet. The web server hands the request to the ArcIMS connector, which provides a
conduit to the ArcIMS Application Server. The Application Server provides the
mechanisms to perform sp
atial operations against the registered data store and returns
the results back to the web server via the ArcIMS connector. The response is sent back to
the web browser. Image courtesy of ESRI
[http://help.arcgis.com/en/arcims/10.0/mainhelp/topics/images/a
rch_overview1.gif]

ArcIMS Development

The first step in creating an ArcI
MS map service is to create an AXL

configuration

file. The AXL file contains information about the spatial layers that are
utilized

in

the
28



map service: where
they

are

located, how they

should ordered, how they should be
symbolized, etc. The Yuma Pinmap
uses

the following layers:

Base Map Layers

1.

Satellite Imagery (raster)

2.

Township and Range (polylines)

3.

Sections (polylines)

4.

Streets (lines)

Operational Layers

5.

Previous Year Crops (point)

6.

Se
ed Companies (point)

7.

Crops (point)

8.

Invisible Grid (polygons)

A “pin” layer is actually composed of two layers, Seed Companies and Crops.
Each layer
is represented by

the same feature class in the geodatabase. However, the
seed company layer is symbolized differently than the crop layer. The seed company
lay
er has a unique color
for

each seed company. Similarly, the crop layer also has a
unique color assigned to each c
rop. The
seed company

layer, however, has a larger
radius. When the two layers are
placed

on top of each other
,

the result
ing symbol

shows
a small colored point in the middl
e, representing the crop type
, with a larger colored
ring

surrounding

it, represent
ing the seed company

[
Figure
2
.
6
].

29





Figure
2
.
6
: Inner circle (blue) represents a particular
crop type
. The outer circle (red)
represents a particular
seed company.

The last layer,
the Invisible Grid, is a carry
-
over from the previous version

of the
Pinmap

(CGI/Perl)

and is the key to making
the
Pinmap

editable. The
Invisible Grid

is
made up of 10 acre
,

square
polygons and is drawn transparently over the map. Each
polygon
acts as a g
rower’s field, or portion of a field, much like a
land parcel in a city.
When a pin is added to the map, it is placed at the center of the nearest polygon and is
assigned the “owner” of that parcel. Only one pin can exist within a grid parcel. If a user
at
tempts to place a pin where the parcel already contains a pin, the user is prompted to
pin somewhere else. This workflow helps prevent users from overlapping pins, and
therefore, helps maintain isolation distances between cross
-
pollinating crops.

Within th
e GIS, the Invisible Grid layer
contains attribute information
for each

polygon, including

a unique grid_id and URL field.
The URL field is composed of a set of
variables containing the grid_id, and the UTM X and Y coordinate of the center of the
polygon.
These variables are constructed together to form a
n

HTML querystring.

The
querystring will be used later to capture the user’s
coordinates when creating a pin
.

A
querystring is formatted as such:

?variable=value

30



Where the following characters are reserved:

? (Question Mark) This identifies the beginning of the query string and must be
placed between the link and the contents of the query string.

&

(Ampersand) This
character
is used to add additional variable/value data in the
query string and is used before

each addition variable/value pair.

=


(Equals) This separates the variable from the value assigned to that variable

An example of a polygon’s URL field:

http://gisweb.calsnet.arizona.edu/PinForm.aspx
?

grid_id=28664&x=177825&y=3624140

HTML Viewer

The confi
guration file is used to create

a map s
ervice. The map service is
compiled into the Application Server memory, and is ready to accept ArcXML requests
from the web server. The ArcIMS software comes with an out
-
of
-
the
-
box HTML website
that is configurable to

point to a known Map Service.

Each tool is pre
-
configured to send
the proper ArcXML to the map service, and parse the response.

The Yuma Pinmap uses
this out
-
of
-
the
-
box website, but contains some important modifications.
Among these
modifications is

the
P
in
T
ool, which when enabled, will

initiate the pinning process.
Specifically, the tool

look
s

for a URL field
in a defined layer
and
loads the URL into a new
browser window.
The Yuma Pinmap’s pin tool is

configure
d to
use the Invisible Grid
31



layer’s URL
field, which contains the proper variables to pass to the web service via the
querystring.

Database

Microsoft SQL Server 2005 is a relational database that houses
both the spatial
data (pins, streets, sections) and non
-
spatial data (growers, seed companies
, passwords,
etc). Because SQL Server 2005
is not natively equipped to

store geographic data, an
added database component is needed. ArcSDE is a database add
-
on that teaches a non
-
spatial database, such as SQL Server, how to store and query spatial data. S
QL Server,
like most RDBMS, can handle transactions from multiple users simultaneously. Since the
web application could potentially have multiple users
creating pins at the same time, a
n

enterprise
-
level

RDBMS
is

needed

to handle these multiple transaction
s. Alternatively, if
the spatial data
were

stored as stand
-
alone shapefiles, the
data

would be
file
-
locked by
ArcIMS, preventing users from
adding and removing pins.



32



The database consists of the

following

primary

tables [
Error! Reference source not
found.
].





Figure
2
.
7
: Yuma Pinmap Database
Schema

33



Web
-
Data Interface Development

ArcIMS, by default, does not include a method for adding and removing data via
the map. This functionality, along with the ability to prevent users from editing each
other’s data,
requires

additional programming.

ASP.Net is a web framework developed
by Mic
rosoft. The web
framework is designed to support
the development of dynamic
websites, web applications and services. The framework aims to alleviate the overhead
associated with common activiti
es performed in Web development
(Web App
lication
Framework)
.

The Yuma Pinmap's custom functionality is written using a common
programming pattern known as three
-
tier architecture pattern. The three
-
tier pattern
separates the user interface,
business

logic, and data operations cleanly from e
ach
other. This approach allows the
application’s parts to be more
flexible

and
reusable
. By
breaking up an application into tiers, modifications can be made to a specific tier,
without the need to r
ewrite the entire application.
The three
-
tier pattern
als
o
makes
software debugging and quality control easier to manage {need reference}.

The

first tier, commonly called the

Presentation Tier
,

contains the code needed
to display the user interface. This includes the HTML markup and cascading style sheets
(CSS) that make up the application's look
-
and
-
feel, and the HTML input controls (text
boxes, drop down lists, radio buttons, check boxes, etc
) that captures the users' data.
The Presentation Tier may also contain pre
-
load

or initialization

methods that populate
34



the input controls before the webpage is displayed to the user. When the user submits
an action (
e.g.

clicks the "Submit" button), the

collected data in the Presentation Tier is
passed to the Application Tier. The Application Tier contains code that performs logical
operations to the data before it is stored in the database. For example, data validation
methods are commonly found in the
Application Tier. The Application Tier can also
include operations that control the application’s functionality, such as re
-
direct the user
to particular parts of the application, based on the application's workflow. For example,
if the user submits a user
name and password, the Application Tier would check for the
correct password,
and then

direct the user to the secured part of the application, or
back to the login screen. The Data Tier is responsible for interfacing the application to
the database. The ma
jority of the Data Tier's functions

is to
perform

CRUD operations:
(C)reate ,(R)etrieve, (U)pdate, and (D)
elete data in the database.
[
Figure
2
.
8
]


Figure
2
.
8
: Summary of Mapping
Architecture

35



Application Classes

The Yuma Pinmap contains a number of user interfaces and code classes that allow the
user to login, add attribute information to a new pin
,

remove an existing pin
, all while
checking and maintaining user/pin
permissions
. Th
e user interface is activated once a
user has clicked on the map

using the Pinning tool
. This
click
action passes the
querystring that contains the Grid ID and X/Y coordinates to the web application's
PinForm class.

Application Tier

PinForm.aspx.cs
:
Befor
e the data is added to the map, the PinForm class
deter
mines if
the user is logged into the system. Only authenticated users should be able to add pins
to the map.

If the user is not logged in, the c
ode

will redirect the user to the Login.aspx
page. If the

user is logged in

(from a previous pinning session)
, the class wi
ll proceed
through a series of I
f
-
T
hen statements:

1.

The querystring is passed to the PinForm class.

2.

From the grid_id va
riable in the querystring, the
class checks to see if the
Invisible G
ri
d contains a pin.

o

If so, the class will check the ownership of the pin.



If the user owns the pin, the class will redirect the u
ser to the
RemovePin.aspx page in the Application Tier.

36





If the pin belongs to another user, the class will notify the user via
t
he PinE
xists.aspx page in the Application Tier.

o

If the gri
d does not contain a pin,
the Pin
Form.aspx
page

will display in
the web browser
, where the user can enter information about the pin,
including the crop type, grower, acreage, etc. [
Figure
2
.
4
]

After the user has
submitted the

attribute
data

about the pin
, the PinForm cla
ss
will validate the input data and save it to an in
-
memory Pin class. This information is
passed to the
System
Processor class
.

SystemProcessor.cs
: This class accepts a Pin object (created in the previous class)
as a
parameter and launches a command line GIS tool

on the web server

called ArcInfo. Like
most command line tools, ArcInfo can be automated via a script
ing language
, called A
rc
M
acro Langua
ge (AML)
.
Using the XY coordinates from the Pin object, the AML script
will create a temporary ESRI point coverage, add attribute fields, and assign the
attribute data to the fields. After the coverage is created, a separate command line
executable,
cov2sd
e
,
is executed, which appends

the single point to a Pins feature class
in the SQL Server enterprise geodatabase.

cov2sde

-
o

append

-
l

pins, shape


-
f

D:
\
WebRoot
\
yuma_pinmap_demo
\
yuma_arc_scripts
\
pin_%id%, point


-
a

all



i

gisweb_sde


-
s

gisweb.calsnet.arizona.edu


-
D

yuma_pinmap


-
u

yumadba


-
p

***********


37



Validator.cs
:

This class has a number of data validation methods that is used by the
PinForm class to ensure the quality of the data
and
before it is saved to the
geodatabase. The c
lass contains the following methods:



validateQueryString

(NameValueCollection)



validatePin (Pin)



validateCompletedPin (Pin)



pinExists (string grid_id)



isOwnerOfPin (string passwd, string grid_id)

Data Tier

PinmapDAO.cs
: The PinmapDAO class acts as a broker

between the Application Tier and
the underlying database. It contains a number of specialized methods for
retrieving and
editing

the data:



getSeedCompanyByPasswd

(string

passwd)



g
etGrowersBySeedCompany

(int

seedcoID)



getCropByID

(string

crop_id)



getCrops()



getExistingPins

(string

grid_id)



getMaxObjectIdByGridId

(string

grid_id)



getPinByGridIdAndPasswd

(string

passwd,

string

grid_id)



getDataSet

(string

sql)

38





removePinById

(string

grid_id)



insertPinByObjectId

(Pin

pin)



CloseConnection()

Presentation
Tier

The Presentation Tier contains the dy
n
a
m
ically generated pages seen by the user during
the process of placing a pin.



Login.aspx: The login screen that collects and submits the seed company
password. A cookie is saved to the user’s browser.



PinForm.asp
x: The Pin Creation Form [
Figure
2
.
4
].



RemovePin.aspx: A page that allows the user to edit the attributes or remove the
pin.



Success.aspx: A page that notifies the user that the pin has been successfully
created.



PinExists.aspx. A scr
een notifying the user that a pin exists and to try pinning
another location.



Error.aspx: A dynamically generated page that displays a message to the user in
the case of an application error.



Logout.aspx: End’s the user’s session. Removes the cookie from t
he client’s
brow
s
er.



39



2.7 Conclusion


The
first

release

of the

Yuma
Pinmap

was
initially
received
well
by the
stakeholders, mainly due to its success in addressing the

core

problems with the
existing

wall map
:

1)

Allow stakeholders to a
dd and edit pins to th
e map remotely without having to

drive to the Extension office.

2)

E
nforce isolation areas between cross
-
pollinating crops
.

3)

A
ssociate a timestamp with each pin to settle
claim
-
disputes between seed
companies.


ArcIMS
established
itself
as
a stable
mapping
platform
, especially during peak
loads at the beginning of the growing season. The use of
SOAP

as a transport
mechanism to send communication between the HTML viewer and the application
server
proved to be extremely insightful, especially since it wa
s a novel concept at the
time.
After the first growing season, a SOAP
-
based prototype application was developed
that allowed users to add pins from a text message sent from a user’s phone, allowing
users to stake claims in
a
field.
Stakeholders were furthe
r impressed with the
application

s ability to query and perform buffer operations.
Although
the Yuma Pinmap
was
a technical

success
,
there were a number of pitfalls that endangered the adoption
of the application.

40



Before the release of the Yuma Pinmap, man
y stakeholders had never used an
online, interactive web map. In fact, s
ome
stakeholders

had n
ever used a

web browser
,

and therefore,
presented

a steep

learning curve. The

biggest
challenge
users

faced

was
in
understanding the application’s user interface
(UI)
. The UI

resembled the interface
typically found
in GIS softw
are

packages. If the user, however, had never used a GIS
software package, the user interface was confusing and unintuitive.

Each time a layer
was toggled
on or off,
or a pin was added, the u
ser was required to
press

the “Refresh
Map” button. Auto
-
refreshing would have been a beneficial enhancement.
If the user
resized the browser window, the current map extent would reset to the initial small
-
scale view of Yuma, AZ. The mouse’s center scroll
wheel was unable to change zoom
levels. The use of ArcInfo to add pins to the map, while resourceful, was a slow process.
The pin creation process routine took 10 seconds or longer, causing some browsers to
timeout.
Some improvements were made to

the UI an
d the performance in

later
revisions of the application, but the initial UI issues set a negative precedent.




Despite the confusing UI and somewhat slow pinning process, the users were
able to learn the application’s tools and functions. Local
extension agents and I hosted a
series of technical training seminars. Prior to the first day of the growing season,
computers were set up in the

Yuma

Extension office
, loaded with the web application,
and

with staff
on
-
hand

to answer questions. A
dditional
ly, a

shadow copy of the
application,
populated

with test data
,

was created
so that users could practice the
41



pinning process prior to opening day. Cultural issues, as it turned out, proved to be a
greater and unforeseen challenge.

Security was a
major

con
cern among stakeholders. Many seed companies rely on
genetic engineering to create successful seed varieties. However, many public interest
groups oppose the use of genetically engineered food. Other groups believe that some
of the participating seed compa
nies have created an unfavorabl
e monopoly in the seed
market
(Gillam, 2010)
.

For these reasons, seed companies wanted to keep the location
of their growing efforts hidden from the general public.

In response, the
Pinmap

was
made

more secure by creating a series of passwords to add and edit data. Also, the

image

resolution of the aerial imagery was purposefully
made coarser so that
the
location of
farm buildings, equipment, and vehicles could not be
identified
.

Prior to the Yum
a Pinmap, the larger seed companies located near the Extension
Office had a distinct advantage when selecting a crop
-
site. Their close proximity to the
wall map allowed them to

frequently check the map and select crop locations faster and
with a

better
understanding of the competition
.

After the wall map was abandoned,

s
maller and more distantly located
seed companies

suddenly

became more powerful,
result
ing

in a shift of power among

producers. This

shift created push
-
back from the
larger companies,
alth
ough usually under some other guise
.

Another outcome of the online
Pinmap

was that

a flurry

o
f pinning

o
ccurred

i
n
the
hours

imme
diately followin
g the "opening bell" of the pin
ning season. Users would
42



attempt to place pins in desirable locations
only

seconds before an
other individual and
were more likely to "over pin" than on the paper map. Perhaps the most noteworthy
d
ifference associated with estab
lishing the onlin
e
Pinmap

is that it led to a de
crease

o
f
in
-
person

c
ommunication, which

m
ay have been
important for negotiations and self
-
enforcement. Prior to the electronic
Pinmap
, the pinning season would begin with most
of the participants
s
pending

a
ll day together

plac
ing their
initial claims on the paper
map.

These cultural events could not be addres
sed or replicated with the online version
of the Pinmap.
After

six growing seasons, the larger seed companies

eventually

used
their influence

to convince the rest of the producers to abandon the

web
-
based

Pinmap
.


43



Chapter 3:

WHITEFLY MAPPER

3.1 Background

Agriculture in South
-
central Arizona, specifically Maricopa and Pinal counties,
make up a large portion of the State’s agricultural production

(Arizona Farm Bureau,
2007)
. Commonly grown crops include members of the
Cucur
bitaceae

family
, including

melons, watermelon, and squash. Arizona’s dry and sunny conditions are ideal for
growing cucurbits. However, recent observations show an increase in cucurbit crop
losses due to a new introduction of exotic whiteflies and
subseque
ntly,
the plant viruses
they transmit.
The harmful viruses, known as whitefly
-
transmitted (WFT) viruses, affect
the color and taste of
cucurbit

crops
, leaving them unsatisfactory for sale in the
marketplace
. The most common occurring WFT viruses are
Squash

leaf curl, Squash mild
leaf curl, and Cucurbit leaf curl
, and a newly introduced
Cucurbit yellow stunting disorder
virus.

These

viruses
are capable of
infect
ing

plants spanning mul
tiple families, including
bean
, lettuce, and agronomic crops such as alfalfa.

3.2 Problem


Researchers know very little about where and when whiteflies occur in Arizona.
It’s understood

that in the desert
,

whiteflies over
-
season in uncultivated

(weeds)

as well
as cultivated
(crops)
h
osts, and disperse long distances using wind corridors to locate
new food sources. However, their temporal and spatial
patterns

have not been mapped
to aid
growers

in making well
-
timed management decisions.
Therefore
, many
growers

apply pesticides at the e
arliest possible time of whitefly arrival based on past years
44



experiences, even though dispersal may not occur for a month or more depending on
weather conditions, particularly rainfall and temperature swings
.

An information
-
sharing platform is needed in o
rder for growers and researchers to better understand
whitefly migration patterns,
in which
participants can post local observations of
whiteflies and plant
-
related symptoms of WFT viruses. By knowing where and when
observations are sighted, researchers ca
n match this empirical evidence with recorded
weather and climate conditions, proximity to hosts,
and the location of geographic
corridors to build a whitefly dispersal model. If this data can be entered into an online
GIS mapping application

over multiple

growing seasons
, growers can

look for
environmental
factors and
epidemiological patterns
that are conducive to the presence
of whiteflies, and

watch in real time when neighboring communities
report observations
of

whiteflies
, minimizing the amount of pest
icide
use. [
Figure
3
.
1
]


Figure
3
.
1
: Example of field survey activit
y during February. The yellow sticky trap,
shown in the center, is used to collect and count whiteflies
. Note the
abundance

of
weeds, some that are known to be whitefly and virus hosts.

45



3.3
Objective

and Design Spec
ifications


The purpose of this project is to develop a
web
-
based information system that
will enable

best integrated practices


for
the
management of whi
teflies and WFT plant
viruses.
The web
application will:

1.

Allow stakeholders to record observations of whiteflies and plants diagnosed
with WFT diseases.

2.

Produce an online map
showing

where and when these observations take place
.

3.

Allow users to in
teract
with the data; zoom, pan, and

query the observations by
plant
host

or

type of virus.

4.

Allow the user to click through historical observations to identify temporal and
spatial patterns.

5.

Identify
high concentrations of
Cucurbit Yellow

Stunting

Disorder Virus

(CYSDV)
outbreaks using a heat map.

3.4 Application Workflow


The data used to populate the GIS web
-
mapping application will come from
growers, UA Extension Agents, and volunteers. These stakeholders
are

given yellow
sticky traps [
Figure
3
.
1
] to be placed in cultivated and non
-
cultivated areas. The traps
are left in the f
i
e
l
d for a defined timeframe, and then retrieved to count the number of
whiteflies stuck to the trap. The numbers,
date
,

and GPS location

are submitted via the
web,
http://cals.arizona.edu/whiteflytracker

[
Figure
3
.
2
], or through email.

46




Figure
3
.
2
: The Whitefly Tracker Website homepage.
http://cals.arizona.edu/whiteflytracker

47




After the

data is uploaded to the site, the user clicks on the “Maps” link from the
top navigation toolbar. Two

online

maps are available for the user; the “Whitefl
y Map”
and the “CYSDV Heat Map”.

Whitefly Map

The Whitefly Map
shows

locations

where stakeholders observe

the presence of
whiteflies, or the location of plants suspected of
being infected with a

whitefly
transmitted virus.
When a user zooms in and hovers

over a single observation with the
cursor, an information box
appears
, containing more details about that particular

observation. Specifically, the information box displays the whitefly category (non
-
adult,
adult, or reproducing adult), a virus diagnosis
(if tested), the host type (cultivated or un
-
cultivated), the host name, and the date it was reported [
Figure
3
.
3
]
.


Figure
3
.
3
: Whitefly Mapping Application
-

Main Window

48



The
whitefly
observation points

can be symbolized to focus on the presence of
whiteflies
or

the virus diagnosis. Each symbolization method displays the points with
two, overlapping layers of symbols. The bottom layer contains a purple or green
circle
,
representing

the
host type

(
eg:

if the observation occurred in a cultivated or non
-
cultivated area
)
. The
host type
circle is
overlaid with

a

colored “X” symbol,

representing

the type of whitefly
;

or

a smaller colored circle, representing the
virus diagnosis
. A
legend box i
s
located
on the left sid
e

of the map and is updated when the user toggles
between the two symbolization methods

[
Figure
3
.
4
]
.





Figure
3
.
4
:
View data by “
Whitefly

Presence” or “Virus Diagnosis”. Legend updates
automatically.

The user is able to adjust the temporal range of the dataset using the time
-
slider
tool in the top right corner of the map

[
Figure
3
.
6
]
. This allows the user to visualize
the
data for a specific range (
e.g.
, 1 day, 3 months, 1 year), or to view data for a specific
4
9



season or year (
eg:

summer, 2008, etc)

[
Figure
3
.
6
]
. Once a temporal range is selected,
the user can create an animation of the data by cli
cking the play button. The
observation points will be shown only when the animation covers the

defined range of

time. Ultimately, the user can view whitefly migrations patterns over space
and

time

[
Figure
3
.
5
,
Figure
3
.
7
]
.

6/30/2008


9/30/2008
:
Gila River Indian Community


Figure
3
.
5
:
Data shows presence in cultivated crop lands during summer months


Figure
3
.
6
:
Adjust Time Slider

9/30/2008


12/30/2008
:
Gila River Indian Community

50




Figure
3
.
7
:
Data shows migration movement into urban areas during winter months


In many instances, observations were taken at

the same

place, (
e.g.
, pre
-
defined
survey points
) or collected in a small area, creating a cluster of points. Overlapping or
clustered observations are represented by a large red circle with a number in the center.
When the user hovers over the
number

with the cur
sor, the symbol will

expand and

add
additional observation points

in a concentric pattern
around the radius of the cluster,
connected by
spokes to the center of the symbol

[
Figure
3
.
8
]. Moving the cursor to

surrounding observation point
s

will show the information box

[
Figure
3
.
9
].

51




Figure
3
.
8
:
Data located at the same location can be viewed by hovering over the
number. Results are then sh
own in on the spokes.


Figure
3
.
9
:
Hovering over the specific spoke shows a detailed pop up of the particular
sample.

52



CYSDV Map


The us
er can switch between the Whitef
ly Map and CYSDV Map by toggling the
men
u bar in the top
-
right corner. Clicking on “CYSDV Map” loads a map

that shows the
location of

plants diagnosed with

Cucurbit Yellow Stunting Disorder Virus

(CYSDV)
.
Each
observati
on is marked with a red circle. Similarly to

the Whitefly Map, the user is able to
expan
d clusters by hovering over a symbol’s center
and display the information box by
hovering over individual samples. This map also contains a Heat Map layer
draped over
the observations, which allows the user to vi
sualize the CYSDV point density. Each time
the user zooms or pans, the heat map is recalculated to include or exclude points from
the previous map extent.


Figure
3
.
10
: 2008 CYSDV Presence Map

53



3.5 Software
Components

The Whit
e Mapping Application requires five

major components

1.

Data Store: An ESRI File Geodatabase is used as the primary
database to store
the Whitefly observations point data. File Geodatabases are composed of flat
files that live on a Windows
file system, and do not require an enterprise level
relational database.

2.

ArcGIS Server:

ArcGIS Server is a suite of server
-
based softw
are that allows
organizations to share GIS resources across an enterprise
and
the web. Multiple
types of clients, such as
GIS desktop software suites, 3D mapping software, web
applications,

and

mobile devices can connect to ArcGIS server and view GIS
maps, perform queries, execute geoprocessing and geocoding tasks, and edit
features.

3.

Web Server: Microsoft IIS is used to deli
ver the web services created by ArcGIS
Server and send them to the web browser via XML or
JavaScript

Object Notation
(JSON), and to support ASP.Net, a server
-
side scripting language used to
generate dynamic web content and provide an interface to the geoda
tabase.

4.

Microsoft Silverlight: Silverlight
4

is an application framework

used

for
developing rich internet applications

(
e.g.
,
applications that act and

feel like
desktop applications, but

run within a web browser
)
. A separate
downloadable
plugin

is requir
ed in order for Silverlight applications to run in the browser
.

54



5.

Silverlight Web
Application
:
The ArcGIS for Silverlight
Application Programmers
Interface (API) is provided by ESRI as a tool to integrate ArcGIS Server services in
a Silverlight
web
applicati
on. The API provides code libraries, classes, and
methods

needed

to develop mapping applications and provide functionality to
navigate, find attributes, identify features, an
d

query data.

3.6 Application Development and Implementation


Development of the W
hitefly Mapping Application began in 2010. At that time,
ESRI’s mapping API’s were focused heavily on using
JavaScript

and Adobe Flash
technologies.

Microsoft Silverlight

was a relative newcomer in the
browser
-
plugin
market
. Microsoft released version 1.0 of Silverlight in 2007.
Because of
Silverlight’s

likeness to Flash, which was a more mature
and long standing
plugin

at the time of
Silverlight’s initial release
, adoption of Silverlight had

been slow

(Montalbano, 2009)
.
Silverlight received its greatest acceptance from the internet community during the
2008 Summer Olympics in
Beijing
. NBC, the American broadcasting company providing
television coverage, provided
2200

hours
of live streaming

and
on
-
demand video

of all
the Olympic sporting events

(Arrington, 2008)
. The video, however, required

viewers to
download and install

the Silverlight
browser
plugin, and therefore
Silverlight
received its
largest gain in market sh
are. Today,
sites

with large
user bases
,

such as msn.com and
Netflix video streaming services

use Silverlight.
Silverlight also

comes installed on every
version of Windows 7.
According to statowl.com, Microsoft Silverlight has a penetration
of
67.36% in Oc
tober, 2011

(Stat OWL, 2011)
. Due to Silverlight’s increased rates of
55



adoption and because of my familiarity with Microsoft web technologies, it was decided
to develop the Whitefly Mapping application
using

Silverlight

as a deve
lopment
framework
.

ArcGIS Server Architecture


ArcGIS Server is a collection of server components, each with a specific role in
delivering GIS Data.

For the sake of relevancy, I’m going to focus on the components
used for delivering mapping services.

GIS

Server



The GIS Server

is the main component of the ArcGIS Server infrastructure. It

hosts your
GIS resources, such as maps, and exposes them as services to client
applications. The server is composed of two distinct parts, the Server Object Manager
(SOM) and Server Object Containers (SOC). The SOM acts as the GIS Server’s main
manager daemon, brokering server resources between the clients and the SOC’s. Each
SOM connects to two or more SOC’s. The SOC represents a
n in
-
memory

container for
the code and

data needed to compose a map service.

Web Server



The web server hosts the web applications and services that use the
resources running on the ArcGIS Server. When a user interacts with a map, the user’s
browser interacts directly with the Web Server. It

stands as a communication port
between the user and the GIS Server.

Clients



Clients are applications that users utilize to interface with the GIS data. They
provide the
graphical user interface (
e.g.
, map display, toolbars, information windows,
56



etc)
to
aid the user in visualizing the data.
In most scenarios, ArcGIS Server relies on web
clients to give users interactivity with the mapping service. However, mobile phones,
desktop GIS software, 3D visualization software, non
-
spatial business applicatio
ns, e
tc
can also be considered

client
s
.

Example



Browser initiates a GIS action

1.

A Client pans or zooms the map.

2.

The request is sent to the Web Server

3.

The SOM passes request to a SOC.

4.

SOC generates a map image of the new viewing extent.

5.

SOC passes images for e
ach GIS layer in the map back to the SOM.

6.

The Web Server sends the images to the browser.

7.

The browser blends the images of each layer into one image.

Developing a Map Service

The process of creating a map service using ArcGIS Server is more streamlined
than its predecessor, ArcIMS.
ArcGIS Server allows users

to publish their ma
p
documents

directly

from
within the

ArcMap
desktop software, or via an administrative
web
interface
.
Before publishing

the map service
, the software analyze
s

the map
document to ensure the feature classes, d
ata models, layer symbology, and other
elements of the map will display efficiently on the web. Once published, the user can
further enhance performan
ce by creating a cached map service. A cached map service is
57



composed of a series of uniformly sized image tiles that span across the extent of the
map. Each zoom level of the map is scanned and
converted into a series of images
.

Each
image is a snapshot o
f the visible layers for that particular part of the map.

Once the
map service is
completely tiled
, the web application only needs to display the proper set
of pre
-
made images.

C
ached map services are

more efficient than

dynamic map
services, in which

the GIS server

is required

to
dynamically
create a new image for each
map extent.

However, since all the layers are “burned” into the image, it becomes

impossible for the

web application to
toggle

the visibility of

individual
layers
. This
drawback may not

be suitable for web applications that need that level of layer
interactivity.

Most
web
-
mapping applications are developed

using a com
bination of
cached map services

(to provide a basemap) and dynamic map services (
to showcase
layers that can be toggled o
n and off
)
.

ArcGIS Server provides a web interface to view and query the feature classes
within a map service. This
also
allows other web applications to digest the same data
found in the Whitefly Tracker website
.

The Whitefly Tracker mapping application
uses
cached map services provided by ESRI. These services produce an aerial and street
basemap, which help the user orientate their
location

on the map. The user
-
contributed
whitefly observation
data is
draped over the cached basemap, and is
exposed via a
dynamic map

service

Silverlight Development


58



The Whitefly Tracker website was developed using the same 3
-
tier programming
pattern that was used to develop the Yuma Pinmap (see Chapter 2.6). When
developing

Silverlight

applications
, the presentation tier is

written in an XML
-
based language
written by Microsoft called Extensible Application Markup Language (known as XAML).
ESRI provides a Silverlight API, which includes XAML
-
based controls, such as a map
control, or a legend control. For example a map can be
added to a page by adding the
following line of
XAML
code:

<
esri
:
Map

x
:
Name
="myMap"
Extent
="
-
114,

32.5,

111,

34.5">


</
esri
:
Map
>

Layers and data can be added to the map control by nesting XAML layer controls within
the map
control’s XAML code
.

<
esri
:
Map

x
:
Name
="myMap"
Extent
="
-
114,

32.5,

111,

34.5">



<
esri
:
FeatureLayer



ID
="Host

Type"



Url
="ht
tp://cals.arizona.edu
/whiteflytracker/whiteflymap/MapServer/2"



Visible
="True"



/esri:FeatureLayer>


</
esri
:
Map
>

By default, a layer’s symbology is inherited
from the symbology used in the
corresponding map document. However, the symbology can be programmatically
customized within the XAML code. The clustering capability used for showing
overlapping whitefly observations, for example, is interactive symbology

t
hat is

only
found in the Silverlight API, and therefore is declared in the web application’s XAML
code.

59



<
esri
:
FeatureLayer.Clusterer
>


<
esri
:
FlareClusterer

FlareBackground
="#99FF0000"



FlareForeground
="White"

MaximumFlareCount
="10"

Radius
="4"

/>

</
esr
i
:
FeatureLayer.Clusterer
>


The Application Tier, which provides the business logic and acts as a broker to
the Data Tier, is written in .Net compatible languages, such as C# and VB.Net. My
previous mapping applications, including the Yuma
Pinmap
, used C# t
o write the
Application Tier, and therefore, I was able to re
-
use the knowledge, and in some cases,
code from existing applications. Since the Whitefly Tracker application on
ly

displays
data,
rather than

allow users to add observations from the map
interface,

the
Application Tier does not need to perform any data validation functionality

or prep data
for the database
. Most of the
code
methods are used to aid in the visualization of the
data (
e.g.
, switching from a street base map to an aerial imagery

base map, generat
ing

a
new heat map,
add and remove whitefly observations

based on the time slider input).
Therefore, each view in the Presentation Tier has a corresponding cod
e class in the
Application Tier.

Software Classes



MainPage.xaml


Provides the

UI for the Header, Navigation Bar, and Border



MainPage.
xaml.
cs


Provides