4 APPLICATION DESIGN - Refractions Research

towerdevelopmentData Management

Dec 16, 2012 (4 years and 8 months ago)

268 views















S
S
y
y
s
s
t
t
e
e
m
m


D
D
e
e
s
s
i
i
g
g
n
n



Populations at Risk

Information Initiative



TOC:
March 18, 2013

The following individuals are authorized points of contact for information regarding the
contents of this report:

Technical Matters:

Lewis McCulloch


Humanitarian Assistance Unit, Department of State


Phone: (202) 203
-
7773



Gail Kucera


Swiftsure Spatial Systems Inc


Phone: (250) 477
-
4719


Project Matters:

Bill Clark


Rosettex Technology & Ventures Group


Phone: (703) 961
-
5331


This document was prepared for the National Technology Alliance under the Rosettex
Technology and Ventures Group Agreement NMA401
-
02
-
9
-
2001 with the National
Geospatial
-
Intelligence Agency (NGA).








DRAFT:
March 18, 2013

1

Table Of Contents

1

INTRODUCTION

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

2

1.1

Purpose

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

2

1.2

Assumptions

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

2

1.3

Other Documents

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

2

2

SYSTEM OVERVIEW

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

2

2.1

System Overview

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

2

2.2

System Objectives

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

4

2.3

Confirmation of Scope

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

4

2.4

System Constraints

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

5

2.5

Target Audience

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

5

2.6

Documentation

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

5

3

SYSTEM NETWORK COMPONENTS

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

6

3.1

Information Server (Refractions)

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

6

3.2

Information Server (Stone Environmental)

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

7

3.3

Security Policy and Data Access C
ontrol

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

8

4

APPLICATION DESIGN

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

8

4.1

Development Items

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

8

4.1.1

Demographic / Aid Model Server

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

9

4.1.2

Hurricane Model Server

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

10

4.1.3

Catalogue Browser

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

10

4.1.4

Area of Concern Tool

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

12

4.1.5

Thematic Legend Display

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

13

4.1.6

Demographic / Aid Model UI

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

13

4.1.7

Hurricane Model UI

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

14

4.1.8

Security UI

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

15

4.1.9

Security (DACS) Integration

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

15

4.2

Infrastructure Items

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

16

4.2.1

Non
-
Standard Data
Aggregation

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

16

4.3

Help System

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

16

5

TECHNICAL REQUIREMENTS

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

17

5.1

Software

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

17

5.2

Hardware

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

17

5.3

Communication

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

17

5.3.1

With the User

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

17

5.3.2

With OGC Servers

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

18

5.3.3

With Catalogue Server

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

18

5.3.4

With Model Servers

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

18

5.4

Performance

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

18

5.5

Operations & Support

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

19

5.6

Implementation

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

19









DRAFT:
March 18, 2013

2

1

INTRODUCTION

1.1

Purpose

The Populations at Risk system is a demonstration system that will show the
c
apabilities available using current standards based technology and available data
sources. The system will show how US Government policy makers and agencies
can use spatial and non
-
spatial data to better utilize and understand the size,
demographic charac
teristics, and spatial distribution of populations at risk in
various situations.

1.2

Assumptions

This design document is built on the following core assumptions:



Open Geospatial Consortium (OGC) standards will be used to provide web
mapping and web feature s
ervice throughout the system.



Client application design will use the uDig open source GIS platform.



Analysis functionality (in particular, hurricane affects and flood extents) to
be implemented is for demonstration purposes, and will is not expected to
be
scientifically valid.



That the final system will be used for demonstration and proof
-
of
-
concept
purposes.

1.3

Other Documents

The following document has already been prepared as part of the Population at
Risk initiative:



Requirements Definition, Capability Dem
onstration of Country Packages for
Populations at Risk Initiative, March 24, 2005

2

SYSTEM
OVERVIEW

2.1

System Overview

The Populations at Risk (
PatR
) system demonstration will include components of
a “service oriented architecture” (SOA) based primarily on Open

Geospatial
Consortium (OGC) standards.

SOA systems operate using a “publish, find, bind” paradigm:



Service providers “publish” information about their services in a registry;



Client applications “find” out about useful services by searching the
registry;
and









DRAFT:
March 18, 2013

3



Client applications “bind” to the services directly using metadata
information retrieved from the registry.


REGISTRY
APPLICATION
SERVICE
Bind
Find
Publish
REGISTRY
APPLICATION
SERVICE
Bind
Find
Publish

Figure 1: Conceptual diagram of a

service oriented architecture.


The
PatR

system will be implementing a number of components of the service

oriented architecture.



The
PatR
client application will be a desktop application that integrates
support for OGC Web Map Services, OGC Web Feature Services, and
catalogue services.



The
PatR

catalogue will be a data file assembled by subject area exper
ts to
bring as much potential data into an integrated spatial context as possible.



The
PatR

services will be a mix of OGC services specifically set up by
Refractions for the
PatR

application, OGC services run by Stone
Environmental to share model and oth
er data, and third party OGC services
that provide other useful information (weather, satellite information, base
mapping, etc).









DRAFT:
March 18, 2013

4

PatR
Catalogue
PatR
Application
(uDig)
PatR
WMS
PatR
Models
Stone WMS
Other WMS
Bind
Find
Publish
PatR
Catalogue
PatR
Application
(uDig)
PatR
WMS
PatR
Models
Stone WMS
Other WMS
Bind
Find
Publish

Figure 1: Diagram of the
PatR


service oriented architecture.


2.2

System Objectives

The objectives of the Populations at Risk sy
stem are:



Support data sharing and collaboration in humanitarian planning and
demographic analysis through a unified interface to social and
environmental information.



Provide unified access to a diverse collection of spatial information through,

o

A unified

search process that combines queries to multiple metadata
services into a single search form and result set;

o

A unified data viewing environment that combines map information
from multiple web mapping and modeling services into a single map
display.



Provid
e standards based access to spatial data through,

o

Usage of Open Geospatial Consortium (OGC) standards, such as
Web Map Server, Web Feature Server, GML, and others;

o

Simple client/server access to model results and services.

2.3

Confirmation of Scope

The
PatR

sy
stem will provide a client application and demonstration servers for
use of HUI and others in demonstration of the capabilities of a distributed
architecture for making use of demographic information and analysis:



The system will use OGC standards where ap
plicable;



The system will use open source components where suitable;









DRAFT:
March 18, 2013

5



The client component will be built with the uDig open source GIS platform;



The client component will interact with standard WMS and WFS servers,
local Shape file data, a remote SOAP catal
ogue, and the
PatR

catalogue;



The WMS server component will be implemented with the Mapserver open
source WMS;



The WFS server component will be implemented with the GeoServer open
source WFS;



The model server component will be implemented with Perl, Postg
reSQL
and any other open source tools necessary to provide a compelling
demonstration.

2.4

System Constraints



The
PatR

client software will be deployed as a Java application, using a
unified one
-
click installer package. Minimum system requirements:

o

256Mb RAM

o

Windows NT/2000/XP or Linux or OS/X 10.4

o

1Ghz CPU



The
PatR

servers will be deployed on a Linux operating system. The
PatR

servers will initially be deployed on hardware operated by Refractions
Research.

2.5

Target Audience

This following project staff membe
rs are responsible for reviewing and approving
this document:



Gail Kucera, Swiftsure Spatial Systems



Lewis McCulloch, Humanitarian Assistance Unit, Department of State

This document will be used by the project implementation team to guide
implementation a
nd delivery of the
PatR
system.

2.6

Documentation

Supporting documentation for this project includes:



OGC Web Map Server Specifications (Versions 1.0, 1.1.0, 1.1.1, 1.3.0).
Open Geospatial Consortium.
www.opengeo
spatial.org



OGC Web Feature Server Specification (Version 1.0). Open Geospatial
Consortium.
www.opengeospatial.org



OWS Common Recommendation Paper (Version 0.3.0 [04
-
016r3]). Open
Geospatial Consortium.
www.opengeospatial.org









DRAFT:
March 18, 2013

6

3

SYSTEM
NETWORK
COMPONENT
S


The PatR system will follow a generic service oriented architecture, as described in
the summary above.

The diagram of specific expected servers and services for

the PatR system is as
follows:

Stone
Environmental
WMS Server

Model Results

Mali Data
Refractions
Research
WMS Server

Harvested Data
(Weather, News)

Harvested Data
(FEWS, NOAA)

Mali Data

Haiti Data

Mozambique Data
WFS Server

Analyst Areas

Population Areas

Population Points
Model Servers

Hurricane Affect

Flood Affect

Demographic /
Aid Summary
Refractions
Research
Catalogue

PatR
Catalogue
PatR
Client Application
Analyst Area Tool
Hurricane Model Client
Flood Model Client
Demographic Model Client
Aid Model Client
WMS Client
PatR
Catalogue Browser
WFS Client
Global Catalogue Search
Stone
Environmental
WMS Server

Model Results

Mali Data
Refractions
Research
WMS Server

Harvested Data
(Weather, News)

Harvested Data
(FEWS, NOAA)

Mali Data

Haiti Data

Mozambique Data
WFS Server

Analyst Areas

Population Areas

Population Points
Model Servers

Hurricane Affect

Flood Affect

Demographic /
Aid Summary
Refractions
Research
Catalogue

PatR
Catalogue
PatR
Client Application
Analyst Area Tool
Hurricane Model Client
Flood Model Client
Demographic Model Client
Aid Model Client
WMS Client
PatR
Catalogue Browser
WFS Client
Global Catalogue Search



3.1

Information Server (Refractions)

The Refractions information server will run multiple services in support of the PatR
application:



WMS Services to publish PatR data

o

provided by HUI

o

harvested from FEWS

o

harvested from NOAA









DRAFT:
March 18, 2013

7

o

harvested from news sites.



WFS Services to hold PatR data

o

from the Analyst Area tool on the client application

o

from the demographic data provided by HUI

o

from the demographic data found at other sites.



Model Servers to demonstrate the concept of distribute
d analysis

o

for weather events

o

for demographic summaries.

The Refractions information server will use:



UMN Mapserver to provide WMS services;



Geoserver to provde WFS services;



Perl/PostgreSQL to emulate model services.

The Refractions information server wil
l be part of the security federation with the
Stone Environmental information server, using the DACS security model. (
Note:
DACS implementation depends on software development currently under way,
schedules may not allow full implementation.)

Tasks:

1.

Insta
ll PostgreSQL/PostGIS and create database instance for all PatR data.

2.

Install Geoserver, install Mapserver.

3.

Install data harvesting and population scripts on server.

4.

Upload HUI data and install Mapserver map files to provide WMS access.

5.

Upload population d
ata to database, and configure Geoserver to provide
WFS access.

6.

Install the model servers and upload data to support them to the database.

7.

Test all server components against PatR client software.

3.2

Information
Server (Stone Environmental)

The Stone informati
on server will run WMS services in support of the PatR
application:



WMS Services to publish Stone data

o

model results and maps

o

data from Mali and other countries.

The Stone information server will use:



UMN Mapserver to provide WMS services.

The Stone inform
ation server will be part of the security federation with the
Refractions Research information server, using the DACS security model. (
Note:








DRAFT:
March 18, 2013

8

DACS implementation depends on software development currently under way,
schedules may not allow full implementati
on.)

Tasks:

1.

Install Mapserver.

2.

Configure Mapserver with map files do display Stone model results and
extra data.

3.

Test server components against PatR client software.

3.3

Security Policy and
Data Access Control

Security and data access control will be provided
using:



DACS distributed access control systems, if development of a Java client
for DACS is complete in time for integration with the PatR client
application; or,



HTTP Basic authentication, otherwise.

The DACS system requires that all site participating in

the distributed access
system be part of a “federation” defined by a shared internet domain, and that all
communication between clients and servers be over SSL when engaged in DACS
transactions.

For example, in the National Forest Information System, the
DACS federation
nodes are “pfc.nfis.org” and “ottawa.nfis.org” and “yukon.nfis.org”. For the PatR
system, two nodes will be needed immediately: one for the Stone information
server and one for the Refractions information server.

Tasks:

1.

Choose a DACS feder
ation for the PatR system (e.g. patr.org)

2.

Register the DACS federation with a DNS registrar.

3.

Set up DNS entries for refractions.patr.org and stone.patr.org, and direct
these entries at the Refractions and Stone servers respectively.

4.

Register SSL certificat
es for refractions.patr.org and stone.patr.org and
supply these certificates to Refractions and Stone for server set up.

5.

Install the DACS server components at Refractions and Stone.

6.

Install the SSL certificates at Refractions and Stone.

7.

Create Refractions
and Stone users, and test DACS protection.

4

APPLICATION DESIGN

4.1

Development Items

The following items have been broken up by functional categories to aid in the
parallel development process necessary to delivery the PatR demonstration on








DRAFT:
March 18, 2013

9

time. Note that ite
ms referenced as “servers” are functional servers, not
necessarily individual physical servers. The servers will be deployed primarily on
the single physical Refractions server used for the demonstration.

4.1.1

Demographic / Aid Model Server

4.1.1.1

Summary

The Demogra
phic/Aid Server provides the application with a mechanism for
performing demographic queries using location and area criteria.

Queries against the service fall into two categories. The first is a simple
demographic summary for a specified area. The second

is a prediction of the
amount of aid for a specified area. The amount aid is derived from the
demographic summary of the region of interest.

4.1.1.2

Inputs

One or more polygons, encoded as Well Known Text, which define areas of
concern.

4.1.1.3

Outputs

An XML document co
ntaining a summary of the demographic information
pertaining to the specified input polygon.

4.1.1.4

Tasks

1.

Inventory population data available and load data into database.

2.

Define output XML schema and coordinate with PatR application builders.

3.

Write processing scr
ipts to calculate outputs based on inputs.

4.

Test scripts and coordinate with PatR client builders to integrate into client
workflow.

4.1.1.5

Capabilities Not Implemented

An idea demographic server would serve as a repository for the best current
knowledge of demogr
aphic information world wide, and could be used by multiple
applications as a source of “best current knowledge” for the purposes of a large
number of planning and research purposes.

The PatR demographic / aid model server will be acting as a proof
-
of
-
conc
ept, so
the following potential capabilities will not be implemented:



The server demographic results will be based on best available data for the
PatR demonstration, but will not necessarily be scientifically validated.



The server aid estimates will be bas
ed on some very simple calculations of
population and required supplies, but will not be a working aid calculation
model.



The server will generate summaries using vector inputs (census polygons
and settlements points) and will not be summarizing raster inp
uts at this
time.









DRAFT:
March 18, 2013

10



The server will not include a maintenance or data upload functionality. A
true demographic server would be updateable by researches, and would
have editable metadata as well as support for commenting.

4.1.2

Hurricane Model Server

4.1.2.1

Summary

The H
urricane Server provides the application with a mechanism for isolating
regions that may be potentially affected by a hurricane.

Queries against the service are made in terms of location and area. In response to
a query the service performs an analysis ba
sed on meteorological data in the
specified region to calculate the regions of concern.

4.1.2.2

Inputs

A polygon, encoded as Well Known Text, which defines an area of concern.

4.1.2.3

Outputs

A set of polygons, encoded as Well Known Text, each of which define an area of
p
otential danger.

4.1.2.4

Tasks

1.

Inventory relevant data available and compile into working directory.

2.

Research tools available to provide example model of impact. Raster
modeling tools and DEM models.

3.

Write processing scripts to calculate outputs based on inputs.

4.

Test scripts and coordinate with PatR client builders to integrate into client
workflow.

4.1.2.5

Capabilities Not Implemented

The PatR hurricane (and flood) model server will not be running a “real” validated
scientific model. Rather, it will be demonstrating the

concept of “distributed
intelligence”. Weather and other physical models are best formulated and
maintained by domain experts. In a distributed system, decision support tools
(like the PatR demonstration) do not contain models themselves, the use models

maintained and validated by scientific experts in other organizations.

The PatR hurricane model server will ingest simple inputs, perform some simple
calculations, potentially using elevation and terrain information to produce an
imaginary “area of impact
” and return simple outputs for display and use in the
PatR application.

4.1.3

Catalogue Browser

4.1.3.1

Summary

Analysis data is grouped into a number of discrete categories. Examples include
Terrain information such as elevation and water data; Infrastructure informat
ion
such as roads and rail data; and Demographic information such as population and








DRAFT:
March 18, 2013

11

age data. In addition to a category, each datum has an associated location and
time.

This data is available via the local catalog. The catalogue browser provides a
hierarch
ical view of the catalog to facilitate the quick browsing of data relevant to
the current analysis.

4.1.3.2

Screen Design

<Screen shot of the catalogue UI:


Tree with category entries, and some leaf nodes


Metadata panel with detailed information on selected lea
f


Text search input area at the top of the UI>

4.1.3.3

Data Format

The catalogue browser will ingest an XML document in order to form the tree and
have access to information about the data available for the PatR application. The
application will ingest and form
at the catalogue tree at start
-
up time only.

Because the data is transferred as an XML document it will be possible to deploy
the PatR catalogue as: a local XML file; an remote XML file accessed over HTTP;
or, a virtual remote XML file accessed over HTTP,
but constructed on the fly from
database records.

Initial implementation will be against a local XML file, but remote HTTP XML file
will be a simple configuration change. Catalogue data can be stored in a remote
database for online access if there is time

for the implementation at the end of the
project.

This design will allow new information to be added to the catalogue very easily in
a central location.

4.1.3.4

Tasks

1.

Define the XML format for the catalogue browser input.

2.

Write a user interface “view” to render

the catalogue data as a tree.

3.

Add context menus to the user interface “view” so that folders and leafs
have actions (“add to map”, “zoom to extent”, “open country package”,
etc).

4.

Integrate catalogue data structure with uDig application structure (adapt
ca
talogue structures to IGeoResource).

4.1.3.5

Capabilities Not Implemented



The catalogue browser interface could potentially provide a means of editing
the contents of a remote catalogue. For example, right click in a folder and
“Create New Folder” or “Create New
Data Entry”; enter information in a
dialogue, and the information is uploaded to the catalogue server; now your
new entry is available to all PatR users.



The catalogue browser could potentially make use of an advanced catalogue
system like the OGC Catalogu
e for the Web ebRIM profile. Implementation
effort would be high, but then the network protocols and formats would be








DRAFT:
March 18, 2013

12

standard. We have chosen a simple custom format to speed up
implementation for the PatR demonstration.

4.1.4

Area of Concern Tool

4.1.4.1

Summary

Quer
ies made against external services are made in terms of an “area of concern”.
An area of concern is hand delineated by the user using a specific user interface
tool. Once created, the area of concern becomes a feature in the workspace and
part of the data
model.

Along with a delineation tool, the user interface provides a specific view which can
be used to browse, filter, and supply meta data for a specific area of concern.

An area of concern is stored as a Feature and persisted in a remote WFS
Datastore.

4.1.4.2

S
creen Design

<Two screen shots:


The map edit panel and tool bar above, with the tool selected, and a


polygon being digitized on the screen.


The layer manager, with a right
-
click context menu for the


area of concern layer exposed. >

4.1.4.3

GML Schema

The

area of concern tool will create a standard layer of polygon features, that will
be stored in a standard OGC Web Feature Server. Using a WFS will allow multiple
PatR client applications to view and edit the same feature set simultaneous,
creating a simpl
e “common operating picture” using standard components.

The GML schema will be designed early in the process and implemented in the
WFS. The schema will include:



Geometry (Polygon)



Created By (User Name)



Created Time (Time Stamp)



Category (Enumerated Type
)



Description (Free Form Text)



URL (Associated Link)



Attachment (Associated File)

4.1.4.4

Tasks

1.

Define the GML schema for the “Area of Concer” feature type.

2.

Test persistence of the “Area of Concern” feature type against a test WFS
instance.

3.

Write user interface fo
r the “Area of Concert”. Custom context menu,
custom tool binding, RCP feature packaging, dialogues for attachments
and attribute editing.

4.

Test user interface and ensure usability.









DRAFT:
March 18, 2013

13

4.1.4.5

Capabilities Not Implemented



It is possible for a data capture tool to cap
ture points, lines or polygons. In
order to keep the implementation simple, we will restrict the demonstration
tool to just capturing polygons.



In full “common operating picture” systems, real time data is often updated in
real time on the screen as chang
es occur. The demonstration system will
update when the screen is re
-
drawn but will not update automatically when
data in the central system changes.

4.1.5

Thematic Legend Display

4.1.5.1

Summary

Theming allows an observer to make inferences about a data set based so
lely on
its visual appearance on a map. For instance, if an analyst is viewing polygon
data representing administrative boundaries for a particular country, it is desirable
to have the polygons colored according to the population. This way at a glance
th
e analyst can tell approximately how many people are in a particular region
without having to use a query tool.

A Thematic Legend Display summarizes the categories, or themes that have been
applied to a particular data set. For our administrative boundary

example, the
legend would contain a mapping from color to population interval. The legend is
located on the map itself.

The uDig application already supports thematic rendering of data via the standard
OGC Styled Layer Descriptor (SLD) system. It does n
ot currently have a means to
expose the associated legends to the end user for easy viewing. This task will add
legend component to uDig. Depending on time available, the legend will be
either: an acetate within the map view; integrated into the layer ma
nager.

4.1.5.2

Screen Design(s)

<Two screen shots:


The acetate legend in a map window.


The integrated legend in the layer manager. >

4.1.5.3

Tasks

1.

Write the acetate Legend map graphic for inclusion in the map window.
May have to integrate SLD styling and WMS legend sy
mbols.

2.

Add user interface elements to control the visibility of the Legend map
graphic.

4.1.6

Demographic / Aid Model UI

4.1.6.1

Summary

The Demographic / Aid Model UI is a front end to the Demographic / Aid Service.
Its responsibilities include providing the mechanism
to allow a user to generate a
query, as well as displaying the results of that query.









DRAFT:
March 18, 2013

14

Specifying a query requires integration with the Area of Concern Model in order to
generate the polygon for the query.

Integration with remote demographic/aid server requ
ires defining expected inputs
and outputs. HTTP POST with url
-
encoded values is the simplest track.

4.1.6.2

Screen Design

<One screen shot:


The dialogue that pops up before initiating the query to the server >

4.1.6.3

Tasks

1.

Define uDig data model for a “model server” f
or use with all client/server
model systems.

2.

Work with server deployer to define data model and communication
between client and server.

3.

Integrate server results into the “report view” that will show the results to
the end user.

4.

Add user interface elements

to expose the functionality to the end user
(menu entry to activate system, dialogue to fire off server request).

4.1.7

Hurricane Model UI

4.1.7.1

Summary

The Hurricane Model UI is a front end to the Hurricane Service. Its responsibilities
include providing the mechani
sm to allow a user to generate a query, as well as
displaying the results of that query.

Specifying a query requires integration with the Area of Concern Model in order to
generate the polygon for the query.

4.1.7.2

Screen Design

<One screen shot:


The dialogue t
hat pops up before initiating the query to the server >

4.1.7.3

Tasks

1.

Define uDig data model for a “model server” for use with all client/server
model systems.

2.

Work with server deployer to define data model and communication
between client and server.

3.

Integrate se
rver results into the “report view” that will show the results to
the end user.

4.

Add user interface elements to expose the functionality to the end user
(menu entry to activate system, dialogue to fire off server request).









DRAFT:
March 18, 2013

15

4.1.8

Security UI

4.1.8.1

Summary

Since all data

is assumed confidential by default, access control mechanisms are
required when accessing remote data. The Security UI is responsible for getting
authentication information from the user and creating the tokens used for server
authentication.

4.1.8.2

Screen Desig
n

<One screen shot:


The dialogue that pops up to gather username/passwords where needed. >

4.1.8.3

Tasks

1.

Set up test servers with Basic authentication.

2.

Add interactive dialogue user interface for getting user/password
information when a connection fails for auth
entication reasons.

4.1.9

Security (DACS) Integration

4.1.9.1

Summary

DACS (Distributed Access Control System) will allow the PatR application to
participate in a federation of trust, where multiple organizations share
information, providing subsets of information to di
fferent partners and users based

on trust levels.

There is currently no DACS support in the core software used for PatR, but
implementation of a Java client is ongoing. If schedules permit, DACS access
control will be integrated into the PatR system.

4.1.9.2

Scre
en Design

<One screen shot:


A preferences screen indicating the DACS federations the client is currently


authenticated with.>

4.1.9.3

Tasks

1.

Add core DACS capability to Java.

2.

Integrate DACS authentication with the core PatR software framework.

3.

Set up test DACS
servers for testingn of PatR integration.

4.

Create user interface components to expose the DACS information to the
end user.

5.

Create user interface components to gather user/password information
from end user when first accessing a DACS federation.









DRAFT:
March 18, 2013

16

4.2

Infrastruc
ture Items

4.2.1

Non
-
Standard Data Aggregation

4.2.1.1

Summary

The PatR system is intended to demonstrate the integration of data from multiple
sources in support of various demographic analyses. While there is much
standard GIS data available, and some interest data a
lready available view WMS
standards, there is still much data of high interest that is not available via
standard OGC interfaces.

This task will accumulate as much non
-
standard data as possible and publish it in
OGC standard ways for consumption in the Pat
R application. For example, NOAA
real time data, locust observations, FEWS predictions, online news information,
can all be harvested and re
-
published using OGC protocols.

4.2.1.2

Screen Design

<One screen shot:


Picture of NOAA long term rainfall forecast for A
frica, currently online only


as HTML page. >

4.2.1.3

Tasks

1.

For each data set of interest, determine if it is regularly updated, the
formats and projections of information.

2.

Set up harvesting script to download the data on a regular basis.

3.

Set up WMS service to ex
pose the data via OGC standards.

4.

Add catalogue entries for this new data.

4.2.1.4

Capabilities Not Implemented

Ideally, third party information would already be available in WMS form, and
harvesting would not be required in order to get standards
-
based integration

working. Cooperating with third parties to show them how their data is used by
PatR and how they could use standards to expose their information to similar
applications may help improve the long term available of data to PatR.

4.3

Help System

The PatR applic
ation will include a “help” menu with access to the core application
framework help screens, and a specific PatR help screen, which shows the basic
PatR workflow for new users.

The new PatR user interface components (catalogue, area of concern tools) will
have specific entries in the help system.









DRAFT:
March 18, 2013

17

5

TECHNICAL REQUIREMENTS

5.1

Software

The PatR system will make use of the following software for deployment of the
demonstration infrastructure:



Linux Operating System



PostgreSQL Database Server (8.0.2)



PostGIS Spatial
Database Extension (1.0.0)



Apache Web Server (2.0.50)



Tomcat Application Server (4.1.30)



DACS Security System (1.4.1)



UMN Mapserver Web Mapping Server (4.4.2)



Geoserver Web Feature Server (1.3.0)



uDig GIS Application Framework (1.0.0)



Eclipse Rich Client P
latform (3.1)

5.2

Hardware

The PatR demonstration system will initially make use of existing hardware at
Refractions Research and Stone Environmental. If deployed elsewhere, the
following minimum hardware configuration will be required for deployment:

Server
Specifications:



2+GHz Server



512+Mb RAM



40+Gb Disk Storage



10+Mb Network Connectivity

Network Specifications:



1+Mb Internet Uplink

5.3

Communication

5.3.1

With the User

The user will use the PatR client application directly on his/her desktop.
Communication with th
e application will be via keyboard and mouse.









DRAFT:
March 18, 2013

18

5.3.2

With OGC Servers

The PatR application will communicate with remote OGC servers in order to
retrieve map and feature data for display to the end user.

Incoming Connections

N/A

Outgoing Connections

TCP Port 80

Line Protocol

HTTP

Content Standards

XML (OGC WMS 1.0, 1.1, 1.1.1), Image
Formats, GML


5.3.3

With Catalogue Server

The PatR application will communicate with a remote PatR catalogue server that
will return a PatR catalogue file for display in the PatR catalog
ue browser
interface.

Incoming Connections

N/A

Outgoing Connections

TCP Port 80

Line Protocol

HTTP

Content Standards

XML


5.3.4

With Model Servers

The PatR application will communicate with remote model servers (demographic,
hurricane, flood) to show the con
cept of remote model provision.

Incoming Connections

N/A

Outgoing Connections

TCP Port 80

Line Protocol

HTTP

Content Standards

OGC Well Known Text, HTTP Form Encoding (URL
Encoding)


5.4

Performance

The PatR system will operate within the following perfo
rmance parameters:


Minimum Expected
Concurrent Users

0

Off
-
hours and at other times the PatR system will
not be under any load.

Maximum Expected
Concurrent Users

5

During the demonstration period, the user
expected user community is small enough that
lik
ely concurrency is extremely low.









DRAFT:
March 18, 2013

19

Acceptable Response
Times

In general, the response time for a web
application should never exceed the amount of
time required for a user to switch their attention
to a different task or distraction. The PatR
application
will strive to maintain 15 seconds as a
general maximum response time.

Note:
Some PatR response times will be
conditioned by the response times of third party
servers outside control of the PatR application.
PatR may have very limited direct control of
re
sponse times in many operating modes.

Level of Acceptable
Service Interruptions

The PatR will initially be used for demonstration
and conceptual purposes, not for operational
business purposes, so some interruption, even
during business hours may be accep
table given:



The interruption is limited in time to a few
hours;



The interruption is rare; or



The interruption is scheduled in advance.


5.5

Operations & Support

<Fill in operations and support estimates for dedicated PatR machine and
maintenance. >

5.6

Implement
ation

The PatR application will be delivered along with the overall PatR system of
catalogue service, model servers, and WMS services. The only deployment tasks
will be the individual installation of the PatR client application for demonstration
purposes
by various staff. The PatR client application will be distributed as a one
-
click installation package that automatically installs the application and all
required components, and places an entry in the Start Menu.