ExtentMap Design V07

Extent Map Drawing Tool
Design
Prepared By: Philip Bailey and Colin Daniel

ESSA Technologies Ltd.
300 1765 West 8th Avenue, Vancouver BC V6J 5C6
Tel: (604) 733-2996 Fax: (604) 733-4657
5 March 2007 Version 7.0
Version 7.0
Extent Map Drawing Tool - Design
Content
1
Introduction................................................................................................................. 1
Client Layer ................................................................................................................ 3
Application Layer ....................................................................................................... 4
3.1
Accessing the System ......................................................................................... 6
3.2
Create New Extent Map...................................................................................... 7
3.3
Edit/Delete Existing Map.................................................................................. 13
3.4
Map Acceptance................................................................................................ 14
3.5
View Existing Map ........................................................................................... 16
3.6
Purging Old Maps ............................................................................................. 16
GeoCortex Editing Suite Integration ........................................................................ 18

4.1
IMF Toolbar...................................................................................................... 18
4.2
Editing suite Mode............................................................................................ 18
4.3
Map Layers ....................................................................................................... 18
4.4
Disabled Features.............................................................................................. 19
4.5
Coordinate Geometry........................................................................................ 22
4.6
Frames............................................................................................................... 22
Data Layer................................................................................................................. 23
Security ..................................................................................................................... 27
Outstanding Questions .............................................................................................. 29
Future Enhancements................................................................................................ 32
ii
Version 7.0
1 Introduction
This document describes the design for phase 1 development of an application to capture
the spatial extent of land use permits and water license maps in the Northwest Territories
(NWT). This design builds on the User Requirements document1 that was produced by
ESSA Technologies Ltd. (ESSA) for the Land Use Data Sharing Working Group (LUDS)
in January 2007. The User Requirements document also describes the phased
development approach of the application and how this first phase fits in to the overall
strategy.
Figure 1 illustrates the high level application architecture that was identified as part of the
User Requirements exercise. This design document takes this architecture and provides
more detail on each of the layers. The goal is to describe the features of the proposed
system in such detail as to a) get approval from the LUDS that the application will work
as required, and b) to facilitate resolving any outstanding questions that are needed to
develop the application. Screen mockups are used to present the intended design of the
key screens in the application. While these mockups are only conceptual at this stage, it is
important that any wording or design elements are worked out at this point and not left
until user acceptance testing.
This is a live document and will be continually refined throughout the design process to
always reflect the latest design. The following conventions are used to identify
outstanding issues or questions:
Issues assigned to ESSA Technologies are highlighted in yellow
Issues assigned to GeoCortex are highlighted in green
Issues assigned to GNWT Geomatics are highlighted in blue
Daniel, C.J. and P. Bailey. 2007. Identifying the Spatial Location of Land Use Permit and Water License
Applications in the NWT, User Needs Assessment. Final report prepared by ESSA Technologies Ltd.,
Vancouver, BC.
Version 7.0
Novice End Users
GIS Specialist End Users
Application Locator Portal

(web browser)
ESRI-compatible Software
(ArcGIS, AutoCAD etc)
Client Layer
Deployment Layer
Internet
Application Layer
Internet Server (Apache)
Application Locator User Interface

(HTML, JavaScript)
Internet Mapping Framework

GeoCortex Editing Suite
(Java)
Application Locator
Application Logic
(Java)
Map Configuration Files

(XML)
ArcIMS
Data Layer
Spatial Data
Spatial Data Store

(SDE Oracle)
Temporary Spatial Data

Storage (Shapefiles)
Figure 1 - The Extent Map Drawing Tool architecture. The yellow boxes
represent new components that are required and that do not already exist
in the SDW.
Version 7.0
2 Client Layer
The application will be accessed by users through a web browser. The following client
layer design specifications apply:
o It will be compatible with the following browsers that are already supported by
the IMF and ArcIMS:
o Internet Explorer 6
o Internet Explorer 7
o Firefox 2
o The application will not require any custom software on the client computer.
There will be no code, components or linked applications that the user is required
to install in order to use the application.
o The application will accommodate user displays at 800x600 pixels or finer
resolution.
o The title of the application will be shown in the title bar of the browser. The title
will be:
Land Use Permit and Water License Applications
o The application will be accessed through the HTTP protocol and not through the
secure HTTPS protocol.
Version 7.0
3 Application Layer
The Application Layer is responsible for the user interface and software code that takes
the user inputs and executes the appropriate commands. Figure 2 illustrates all the use
cases the pathways that the user can take through the application user interface. This
type of illustration is a useful way of understanding how a piece of software will work
from the users perspective.
In Figure 2, the blue boxes represent proposed screens. The words on arrows between the
boxes represent actions that the user takes (e.g. clicking the Cancel button). The grey
boxes are code blocks that the user will not actually see, but which execute commands in
the background to create, save and delete information in the database. The WS
acronym refers to the Welcome Screen.
The Application layer combines several technologies working together. The screens
without maps will be developed as JSP web pages while the screens containing maps will
be customized GeoCortex IMF map layouts that use the GeoCortex Editing Suite to
enable the user to digitize shapes on the screen. Section 4 describes the Editing Suite
customization required to make it work in this application.
Each of the main pathways; create, edit and view and acceptance are described in the sub
sections below.
Version 7.0
Figure 2 Application Layer Use Case Diagram.
Version 7.0
3.1 Accessing the System

The application will be accessed via hyperlinks located in several NWT web sites.
Clicking one of these hyperlinks will take the user to the Welcome Screen that is the
starting point for performing the main tasks in the system (Figure 3). Future versions of
the application can be enhanced with additional tasks on this Welcome Screen (i.e.
creating site plan maps).
Figure 3 Welcome Screen.
The View Existing Map pathway is the only one of the four that users can perform
without being logged into the system. When users click View Existing Map they are
taken to a screen where they look up an extent map (Figure 12) and then to the extent
map itself once they have found one.
Pathway
User not
logged in
Logged in users
Any user
Regulatory
Officers
Create New Extent Map
Edit/Delete Existing Map
View Existing Map
Version 7.0
Map Acceptance
Clicking on any of the other three pathways takes the user to the Login Screen where they
will enter their user name and password (Figure 4). If a user does not possess an account
they will need to go through the existing SDW process to obtain one (see Section 0 on
Security). If a user attempts to login but they fail, they will return to the Login screen
with a warning message explaining that they should check their user credentials and try
again.
Figure 4 Login Screen.
3.2 Create New Extent Map

The first option from the Welcome Screen is to create a new extent map. The process of
creating an extent map is, at the highest level, a three step process. First the user will
enter some basic attribute information that is used to track and classify the extent map.
Second, the user will define the map in one of two ways either by providing coordinates
or by digitizing the extent of their application on an interactive map in the web browser.
The third and final step is to submit the map, after which the user receives a Confirmation
Number that they attach to their land user permit or water license application.
When a user chooses to create an extent map they will need to provide a small number of
attributes (Figure 5). It is imperative that the number and complexity of the attributes is
kept to a minimum so as not to discourage users from completing the process. Moreover,
the attributes should not duplicate any information that is also recorded on the paper
application form and already captured in the related application database. Such attributes
will become available in the next phase of development when the extent map and
application database are linked.
There will not be any constraints on the attributes. Users will be able to enter multiple
extent maps with the same title and development type etc.
Version 7.0
Figure 5 entering the attributes when creating an extent map. Note that the
application number is only visible if the user is a Regulatory Officer.
The extent map attributes are validated and then the user is asked how they wish to define
the map (Figure 6). If they wish to define it using coordinates they can enter the latitude
and longitude values on this screen. The coordinates are entered as degrees and minutes
(as specified in the Mackenzie Valley Resource Management Act) but the controls
possess some intelligence so that they can accommodate decimal values (this intelligence
may have to wait for future versions). Positive longitude values will automatically be
negated to reflect that the NWT is in the Western Hemisphere. When the user clicks
Next the editing suite is invoked and the editing suite generates the GIS features using
the coordinates in the underlying SDE layer and then displaying a map already zoomed to
the shapes.
The default will be to draw the map.
If they want to draw the map they simply click Next and are taken to an interactive
map display (Figure 7) where they can draw points, lines or polygons on the screen. Note
that the heads-up digitizing mockups are provisional until ESSA works with
GeoCortex to confirm how to customize the interactive map display features. The
goal is to make the map extremely basic and easy to understand. Only the most basic IMF
map tools (zoom and pan) will be made available so as to avoid confusion. A help icon
on the toolbar will display basic help and editing instructions. The goal is to enable
GNWT to update the help text without having to change any code in the application.
Version 7.0
Dave Taylor of GNWT will provide the underlying map service that defines the base map
layers displayed. This makes it easy in the future to also customize which map layers
displayed without the need to change any code in the application.
Users digitize shapes on the map using the standard GeoCortex Editing Suite
functionality (Figure 8). They can create one or more points, lines or polygons. Clicking
Cancel, Back or Next during this process asks the user to confirm before they
leave this screen.
When the user has finished defining the map they are asked if they want to submit the
map or save it and submit it at another time (Figure 9). The intention is to allow users to
pause if they do not have all the necessary information and save their work. Users that
submit their map are provided with a unique Confirmation Number that is then written on
their land use permit or water license application form (Figure 10). The number is unique
across all maps (i.e. it is totally unique not only for users and proponents, but also for any
potential future uses of the drawing tool). No two maps will ever possess the same
Confirmation Number.
Figure 6 Map Definition.
Version 7.0
Figure 7 Heads-up digitizing of the extent map (exact layout of screen to be

determined).
10
Version 7.0
Figure 8 Heads-up digitizing of the map.
Figure 9 Map submission.
When the user has submitted the map they are presented with a summary view that
contains both the map itself and the attributes. They can choose to print the map for
11
Version 7.0
inclusion in their application, in which case a new window appears with similar contents
but without any of the user interface graphics on the screen (Figure 11).
Figure 10 Final view of the extent map, with the ability to print it. Note that
the application number only appears if it is not NULL.
12
Version 7.0
Figure 11 Printing the map.
3.3 Edit/Delete Existing Map

Users will be able to login and edit any maps for which they have not yet received a
Confirmation Number; they will only be able to edit maps that they have created
themselves (i.e. not the maps of other users) and they will not be able to edit maps that
have been accepted. From the Welcome Screen users need to identify the map that they
want to edit from a list of all the maps that they have started but not submitted (Figure
12). They will select the map they want to work on and click Next. Ideally the column
titles in this table can be clicked to sort the list of maps accordingly. This list contains any
maps that were created by the current user and have a status of Preliminary or Map
Rejected.
The next screen will depend on how they chose to define the map when it was first
created. If they chose to define it using coordinates then they are taken to Figure 6,
already populated with the coordinates entered earlier. They will be taken to Figure 7 if
they have already drawn some features on a map.
In other words, once the user has identified the map they wish to edit, they are essentially
on the same pathway through the application as they were when they first created the
map.
On Figure 12 the user can also select one or more maps that are not submitted and delete
them permanently.
13
Version 7.0
Figure 12 Selecting an Existing Map to Edit.
3.4 Map Acceptance

The map acceptance process is only available to users who are members of the regulatory
officer groups (see Section 0). Users who do not have permission to accept extent maps
can click on the button on the welcome screen, but are warned that they cannot perform
this action after they login and their user group is identified.
Reviewers will first see a screen where they can enter a confirmation or application
number to lookup any extent map in the database (Figure 13). When they find the map
they are looking for they will see a screen that summarizes the extent map (Figure 14).
Once the reviewer has reviewed the extent map attributes and spatial extent they can
either accept or reject the map. Accepted maps become public and are visible to all users
of the system. At this time the regulatory officer can also provide the application number
if it is not already known.
Future versions may be able to track information about the regulatory officer who accepts
the map, as well as some comments etc.
Rejected maps are given a status of Map Rejected. They will then appear in the users
list of editable maps shown in Figure 12.
14
Version 7.0
Figure 13 Extent map lookup.
15
Version 7.0
Figure 14 Extent Map Acceptance.
3.5 View Existing Map

Viewing maps is intended for anyone to access the system and retrieve any extent map
that has been accepted by a regulatory officer. Users do not need an account and therefore
do not need to be logged in to access this feature.
Note that only accepted maps can be viewed in this way. Users wishing to maps they are
still working on (i.e. with no Confirmation Number), or maps that are submitted but as
yet not accepted, need to login to see them.
The first step in viewing a map is to locate it using either the Confirmation Number, or
the application number if one has been entered by a Reviewer (Figure 13). If the map is
found, it will appear in a display similar to Figure 14.
3.6 Purging Old Maps

There is a risk that the system will become bloated by out of date extent maps that are
never completed fully or submitted. To avoid this problem, old maps will be deleted on a
16
Version 7.0
customizable schedule. A CRON script that deletes extent maps that possess a status of
Preliminary and that have not been modified in the last X days, where X is a
customizable value (in the header of the script or some other convenient location). The
system administrator will then be able to schedule this job on the server at a schedule of
their choosing, or run the CRON script manually whenever they deem it necessary.
17
Version 7.0
4 GeoCortex Editing Suite Integration
The GeoCortex IMF and Editing Suite will be used to provide interactive maps in the
application. There following customization issues are involved:
4.1 IMF Toolbar

The following tools will appear on the IMF toolbar throughout the application:
Toolbar Icon
Description
Zoom in (standard IMF)
Zoom out (standard IMF)
Pan (standard IMF)
Zoom to the outer boundary of the current
spatial extent map
Help a HTML pop up window will appear.
4.2 Editing suite Mode

The Editing Suite will be used in Feature Editing Mode. This does not require any
version control or user level security. The editing suite changes the shapes directly in the
base table.
4.3 Map Layers

When a user is digitizing a map in Figure 8 they will see map information from two
sources. They will see the underlying map service of background layers that appears
under every map in the application. They will also see the shapes for the extent map that
they are editing (and not the shapes for ANY OTHER extent map). This requires that the
user interface pass the IMF map the Confirmation Number for the current extent map and
this is used to display the three extent map layers (points, lines and polygons) and filter it
for records only with the current extent map ID.
The non-IMF screens will launch the IMF map using the following URL parameter to
display a specific map. So the URL will take the following syntax:
http://.........ca/imf.jsp?mapid=45637364&type=view
18
Version 7.0
Table 1 IMF parameters.
URL
parameter
Possible
values
Description
mapid
0 and
positive
integers
The extent map that should be displayed in the

IMF. The IMF will filter the three editable layers
for this ID and zoom to the extent of all the
features. If a value of zero is passed then the user
is looking up a map and the extent of the IMF
should default to the Northwest Territories.
type
view, edit
What is being performed in the IMF. If a value of

view is passed then the right data frame should
contain the lookup page (Figure 13 and Figure
14). If a value of edit is passed then the editing
suite should be displayed.
shapetype
point,
rectangle
The shape type, as text, to be generated by the

coordinates passed. If point is passed then only
x1 and y1 are used. If a value of rectangle is
passed then both sets of coordinates are used.
x1
Double
Longitude coordinate in decimal degrees of the

first point (this value will be negative to indicate
the western hemisphere)
y1
Double
Latitude coordinate in decimal degrees of the first

point (this value will be positive to indicate the
northern hemisphere)
x2
Double
Longitude coordinate in decimal degrees of the

second point (this value will be negative to
indicate the western hemisphere)
y2
Double
Latitude coordinate in decimal degrees of the

second point (this value will be positive to indicate
the northern hemisphere)
4.4 Disabled Features

The following GeoCortex IMF and Editing Suite features are not required in this
application and will be removed so as to keep the user interface as easy to understand as
possible.
1. The application will take care of login and so the login features for the editing
suite (shown below) should be hidden and not used.
19
Version 7.0
Figure 15 GeoCortex Editing Suite Login is not needed.
2. The editing suite provides more powerful editing features than are required by this
application. The items circled in red in the following figure should be hidden in
this application.
20
Version 7.0
Figure 16 GeoCortex Editing Suite Features that are not needed (circled in
red).
3. Attribute Editing is not required in the editing workflow because this will already
be handled by other screens (Figure 5). The screen below is therefore not needed
and should not appear after a feature is created.
21
Version 7.0
Figure 17 GeoCortex Editing Suite attribute screen is not needed.
4.5 Coordinate Geometry

Figure 6 illustrates how the user will define the extent map if they wish to use coordinate
geometry (COGO) rather than on-screen digitizing. So that these shapes get added to the
spatial database as shapes, the user interface will call the editing suite and pass the
coordinates. The editing suite will then create the necessary features in the spatial
database with the Confirmation Number.
The values entered by the user in Figure 6 will be passed to the IMF using the URL
parameters specified in Table 1.
4.6 Frames
ESSA will develop the title bar of the application as a separate JSP page that resides
within a frameset. Both IMF and non-IMF pages will use this title page and it will be
called titleframe.jsp. ESSA will provide Geocortex with the full URL for this
page.
22
Version 7.0
5 Data Layer
The attributes and spatial extents of maps will be stored in the Oracle database that
underlies the GNWT SDW. The following tables below describe the information
requirements of this application and need to be discussed with both GNWT and
GeoCortex to fully understand how they will be integrated into the existing database.
The Shape_Length and Shape_Area fields are auto-generated feature class fields and are
optional. If they are not created in SDE by default then they are not needed.
Figure 18 Database Schema.
23
Version 7.0
Table 2 Extent Map Attributes.

Description
EXTENT_MAP_ID (PK)
NUMBER(10)
Confirmation Number of the map that the user writes on

their application. Each map automatically gets a unique ID
and it could only be shown to the user after the map is
submitted.
This field has an associated trigger and sequence to auto
increment.
USER_NAME
VARCHAR2(1
0)
The SDW username of the person who created the map.
PROPONENT_NAME
VARCHAR2(5
0)
Proponent name (may be the first and last name or the

name of a corporation).
DEV_TYPE_ID (FK)
NUMBER(10)
The ID of the development type associated with the map
NOTES
VARCHAR2(4
000)
The users notes or comments describing the map.
TITLE
VARCHAR2(2
55)
The name or title of the application.
DATE_TIME_CREATED
DATE
The date and time that the map was created. Defaults to the
current date and time.
DATE_TIME_SUBMITTED
DATE
Date & time the user completes the extent map & clicks
submit.
DATE_TIME_MODIFIED
DATE
Last date that the extent map was modified. This will
updated when the map is created, submitted, edited or
rejected. It is this field that is used to identify old maps that
should be deleted.
DATE_TIME_ACCEPTED
DATE
The date and time that the map was approved. NULL value
means map has not been reviewed.
ACCEPTED_BY
VARCHAR2(1
0)
The identifier of the regulatory officer who accepted the

map.
APPLICATION_ID (FK)
VARCHAR(25
5)
The ID of the application in the separate database. For this

phase of development this ID will be entered by the
reviewer
BOARD_ID (FK)
NUMBER(10)
The ID of the land and water board that the extent map is
associated with.
STATUS_ID (FK)
NUMBER(10)
The status of the map. This defaults to the ID of the status

value for Preliminary.
COORD_1_X_DEGREE
S
NUMBER(3,7)
Longitude degrees coordinate of the Northwestern corner

of the extent map if the user defines the map by a pair of
coordinates forming a rectangle, or a single point.
COORD_1_X_MINUTE
S
NUMBER(3,7)
Longitude minutes coordinate of the Northwestern corner

coordinates forming a rectangle, or a single point
COORD_1_X_SECOND
S
NUMBER(3,7)
Longitude seconds coordinate of the Northwestern corner

coordinates forming a rectangle, or a single point. Defaults
NULL
Data Type
Index*
Field Name
24
Version 7.0
to zero
COORD_1_Y_DEGREE
S
NUMBER(3,7)
Latitude degrees coordinate of the Northwestern corner of

the extent map if the user defines the map by a pair of
COORD_1_Y_MINUTE
S
NUMBER(3,7)
Latitude minutes coordinate of the Northwestern corner of

COORD_1_Y_SECOND
S
NUMBER(3,7)
Latitude seconds coordinate of the Northwestern corner of

coordinates forming a rectangle, or a single point. Defaults
to zero
COORD_2_X_DEGREE
S
NUMBER(3,7)
Longitude degrees coordinate of the Southeastern corner of

coordinates forming a rectangle. Null if defining a single
point
COORD_2_X_MINUTE
S
NUMBER(3,7)
Longitude minutes coordinate of the Southeastern corner

point
COORD_2_X_SECOND
S
NUMBER(3,7)
Longitude seconds coordinate of the southeastern corner of

point. Defaults to zero
COORD_2_Y_DEGREE
S
NUMBER(3,7)
Latitude degrees coordinate of the Southeastern corner of

point
COORD_2_Y_MINUTE
S
NUMBER(3,7)
Latitude minutes coordinate of the Southeastern corner of

point
COORD_2_Y_SECOND
S
NUMBER(3,7)
Latitude seconds coordinate of the Southeastern corner of

coordinates forming a rectangle. Defaults to zero. Null if
defining a single point
NW_CORNER_LAT
NUMBER(3,7)
The latitude of the northwest corner of the envelope that

encompasses the extent map
NW_CORNER_LONG
NUMBER(3,7)
The longitude of the northwest corner of the envelope that

SE_CORNER_LAT
NUMBER(3,7)
The latitude of the southwest corner of the envelope that

SE_CORNER_LONG
NUMBER(3,7)
The longitude of the southeast corner of the envelope that

Indexing:
U = Unique index
I = non-unique index
Each extent map will have one development type associated with it. These will be
defined in a separate lookup table.
25
Version 7.0
Table 3 Application Development Types.

Field Name
Data Type
Index*
NULL
Description
DEV_TYPE_ID (PK)
NUMBER(10)
The unique identifier of the development type.

This field has an associated trigger and sequence to auto
increment.
NAME
VARCHAR2(50)
The name of the development type that is displayed in

the user interface.
IS_ACTIVE
CHAR(1)
Determines if the development type is active and still

available for new extent maps in the user interface. 0
indicates that the development type is inactive and any
other value indicates that it is active.
0 = False
1 = True
Each map has one status associated with it. When a map is first created the status will
default to Preliminary. When the user submits the map it will be changed to
Submitted and then when the regulatory officer accepts the map the status is changed to
Map Accepted. If the regulatory officer rejects the map the status is changed to Map
Rejected. The CRON job that searches and deletes old maps only deletes those that have
a status of Preliminary or Map Rejected. If the user deletes the map all traces of the
map will be deleted permanently from the database.
Table 4 Extent Map Status Types.
Field Name
Data Type
Index*
NULL
Description
STATUS_TYPE_ID
NUMBER(10)
The unique identifier of the status type.

This field has an associated trigger and sequence to
auto increment.
The name of the status type.
(PK)
NAME
VARCHAR2(50)
The following table will store the different land and water boards. It is a lookup table for
the main extent map table. Note that several of the board names include punctuation that
will need to be handled both by the SQL that retrieves the data and the HTML that
displays them.
Field Name
Data Type
Index*
NULL
Description
BOARD_ID (PK)
NUMBER(10)
The unique identifier of the status type.

This field has an associated trigger and sequence to
auto increment.
NAME
VARCHAR2(50)
The name of the status type.
26
Version 7.0
6 Security
The application will use the existing SDW security model to manage user accounts and
logins. The SDW currently has several different levels of access. Each level possesses an
incremental number of map layers beyond those available to users who visit the site and
dont ever login using an account.
An Oracle database is used to track user accounts. The SDW system administrator
receives an email when each account is created. If the user is a government employee or
requires access to the additional map layers, the system administrator associates the user
to one or more groups thereby granting them access to additional map layers.
The extent map application will leverage this security model. The login screen (Figure 4)
will possess a link to create an account and this will take users to the SDW page for
creating accounts. How will users return to the system after they have created an
account?
The basic SDW account will suffice for all users to create, edit and submit extent maps.
Regulatory officers and anyone else responsible for accepting maps will need to be put in
a special user Group manually by the system administrator. There will be one group for
each board. The groups will follow the existing naming convention and called:
Board
User Group
Mackenzie Valley Land and Water Board
MVLWB_RO
Gwich'in Land and Water Board
GLWB_RO
Sahtu Land and Water Board
SLWB_RO
Wekezhi Land and Water Board
WLWB_RO
Inuvialuit Land Administration
ILWB_RO
Only users who are logged in and members of one of these groups will have access to the
Review button on the Welcome Screen (Figure 3).
Logging out of the system will remove the cookie. This will allow different people to
login to the system from a shared computer (i.e. non-computer users who are perhaps
accessing the system from a public library etc).
From a technical perspective, logging into the system places a cookie on the users
computer that expires after two weeks (so that the user doesnt have to login repeatedly if
27
Version 7.0
they come revisit the system). There are existing JSP pages that determine which groups
the user belongs to. The code demonstrates how to call these JSP functions:

<% if (gspSecurity.checkClearance("MAP_INTERNAL")) { %>
This background colour denotes content that is only visible to Dave
 <% } %>
<% if (gspSecurity.checkClearance("Development")) { %>
This background colour denotes content that is only visible to Geomatics
 <% } %>
<% if (gspSecurity.checkClearance("MAP_ENRITI")) { %>
This background colour denotes content that is only visible to ENR/ITI
 <% } %>
<% if (gspSecurity.checkClearance("MAP_GNWT")) { %> 
This background colour denotes content that is only visible to GNWT
 <% } %>
28
Version 7.0
7 Outstanding Questions
This section captures the outstanding questions that need resolution. Some of them are
trivial and deal with items such as the aesthetic of the application, while others are
fundamental and deal with the underlying database and IMF installations.
1. The application will be accessed via HTML hyperlinks from existing web sites.
Which sites will possess these links?
a. Spatial Data Warehouse (Dave Taylor)
b. Mackenzie Valley Land and Water Board (Rob Dobson)
c. Gwich'in Land and Water Board
d. Sahtu Land and Water Board
2. What will be the domain URL of the application? An example of the existing SDW
is: http://maps.gnwtgeomatics.nt.ca/MOXI/imf.jsp?site=bm_lam_p
Answer supplied on 12 Feb 2007 by Dave Taylor. MOXI is an Apache context used
for the IMF. We can create a new context for this application if it is needed. The
portal is in its own context *.ca/portal (this has the security). Philip to think about
Apache contexts or potentially having a separate domain, to enhance the feeling of
ownership by different boards.
3. The word review has specific connotations in the context of NWT land permits and
water licenses. Consider renaming the entire review pathway in this system as
map confirmation. What is really being performed is a confirmation by the
regulatory officer that the map is accurate and complete before it is then distributed to
the reviewers for the formal review process. Calling the regulatory officer process a
confirmation might avoid confusion?
Answer February 15, 2007. Dave Taylor and Colin Daniel agree.
Update February 28, 2007. Colin and Philip The action of the regulatory officer is
to make the map public. It has nothing to do with the generation of the confirmation
number and so the use of the word confirmation in this process is confusing. Reword
the regulatory officer process as map clearance as if they are clearing it to
become public.
Update March 2, 2007. LUDS agree that Accept/Reject will be used.
4. What are the attributes that we need for an application:
29
Version 7.0
a. Proponents name (it might not be the current user creating it)
b. Application title
c. Date created
d. Date submitted
e. Development type
f. Notes
Update March 2, 2007. LUDS agree that this list is a good starting point.
5. What is the listed of development types that are needed? The following list was taken
from the user requirements document and obtained originally from the GNWT
Natural Heritage Centre:
Forest
Geotechnical investigation
Mining and Mining
Exploration
Miscellaneous
Oil & Gas Exploration
Quarry
Research Projects
Tourism, & Lodges
Traditional Use & Residence
Transportation Corridor
Unknown
March 2 2007. Rob Dobson to send a list of development types that are used in the
application database.
6. Which server-side scripting languages are installed in the deployment environment?
Does the deployment web environment have PHP on it, or just JSP and Tomcat?
Answer supplied on 12 February 2007 by Dave Taylor. Use JSP.
7. Should the application have a visible affiliation to one or more organizations? Should
it have the logo of GNWT, INAC or one or more land and water boards? If so, can we
get a web quality graphic of the relevant organizations?
Answer supplied on 12 February 2007 by Dave Taylor. Remove logo from title bar
and have partner logos on login (and welcome?) screen. Keep generic.
8. How can we have multiple people digitizing shapes in a map without them
seeing/editing the shapes of other users? Does each user need a personal map layer?
9. What happens to maps that are left incomplete? How about every day a process
deletes all incomplete maps that are more than 60 days old?
30
Version 7.0
Answer supplied on 12 February 2007 by Dave Taylor. Use a CRON job that
performs the database command. Dave Taylor can schedule this job at the desired
frequency or run it manually as desired. What are the database user credentials for
this job?
10. Which layers do we want switched on by default during on screen digitizing. Need to
complete the table below with the names of the relevant SDW layers.
Answer supplied on 12 February 2007 by Dave Taylor. Leave this to Dave Taylor to
define the background map service. Dave to provide the map service name.
11. What happens to rejected maps? Do they get deleted from the system, or left and just
flagged as deleted.
Answer supplied on 12 February 2007 by Philip Bailey. See Section 3.5).
12. What format should the confirmation number be?
Non-padded incremental integer: 1, 2, 3
Padded incremental integer: 000001, 000002, 000003
Prefixed number (the prefix could identify the board/agency): EM000001,

EM000002, EM000003 (Dave Taylor likes this)
Date and map unique (YYYYMMDD#): 200702011, 200702012, 200702013
Some other numbering scheme?
March 2, 2007. In the first version, the confirmation number will be a plain
integer. Future versions may incorporate some kind of text identifier that
associates the extent map with a board.
13. (Nick) Which JSP pages do we call/use for user security & access?
14. (Nick) Is the connection to the Oracle database done through an ODBC connection on
the web server, or is there a direct connection through code?
15. (Nick) Ask about username. How many characters?
16. (Nick) Where are the scripts that deal with security for logging on, and user
privileges?
31
Version 7.0
8 Future Enhancements
The following items are clarifications of features that are out of scope for this phase of
development. Further information the future development phases can be found in the
User Needs Assessment document.
i. This version will not include an online help system. The user interface described in
Section 3 will be minimalist and as straightforward to follow as possible. A
comprehensive help system can be developed for future versions, in any language that
is deemed necessary.
ii. This version will not enable users to change their password or manage their user
account in any way. It will use the existing SDW security approach and will not
include any additional security features.
iii. When a user does not possess an account and they are redirected to the SDW to create
one, this redirect could possess an argument that then returns the user to the
application once their account is created. This would require minor customization to
the SDW page that creates and account.
iv. Future versions will contain an argument in the URL for the application that identifies
how the user came to the application (i.e. if they came from the web site of the
MVLWB or GNWT). This will enable the application to be tailored with the visual
identity of a specific organization or tweaked with process-specific steps.
v. Users with special permissions will be able to share and edit maps. The goal is to
allow land and water board staff to enter maps on the behalf of proponents and
collectively work them through to submission.
vi. A regulatory officer at one of the boards could be notified with a daily email of all the
new extent maps that have been submitted.
vii. When the regulatory officer rejects a map, the person who created it receives an email
saying that it was set back to preliminary and will stay in system for 60 days.
viii. When a regulatory officer confirms a map it could be assigned an ID that
associates it with the land and water board with which the officer is affiliated. This
would allow filtering of extent maps by the board to which they are assigned.
ix. Have a link on the submitted extent map screen (Figure 10) that enables the user to
email the extent map application to them self.
32
Version 7.0
x. ESSA will investigate if it is possible to automatically populate certain fields in

Figure 5. It might be possible to determine the users first and last name from the
Security JSP routine (see Section 0). However, this is not a low priority feature.
xi. Users may want to see a list of layers that are in the map, together with their
symbology. We can add a legend type view for all IMF maps in future versions.
xii. Implement the IMF PDF capabilities to produce an 8.5x11 printout of the extent
map.
33

ExtentMap Design V07

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ExtentMap Design V07

Caricato da

Copyright:

Formati disponibili

Extent Map Drawing Tool

Prepared By: Philip Bailey and Colin Daniel

5 March 2007 Version 7.0

Extent Map Drawing Tool - Design

Client Layer ................................................................................................................ 3

Application Layer ....................................................................................................... 4

Accessing the System ......................................................................................... 6

Create New Extent Map...................................................................................... 7

Edit/Delete Existing Map.................................................................................. 13

View Existing Map ........................................................................................... 16

Purging Old Maps ............................................................................................. 16

GeoCortex Editing Suite Integration ........................................................................ 18

Editing suite Mode............................................................................................ 18

Map Layers ....................................................................................................... 18

Outstanding Questions .............................................................................................. 29

Extent Map Drawing Tool - Design

Issues assigned to ESSA Technologies are highlighted in yellow

Issues assigned to GeoCortex are highlighted in green

Issues assigned to GNWT Geomatics are highlighted in blue

Extent Map Drawing Tool - Design

Novice End Users

GIS Specialist End Users

Application Locator Portal

Application Locator User Interface

Internet Mapping Framework

Map Configuration Files

Spatial Data Store

Temporary Spatial Data

Extent Map Drawing Tool - Design

Extent Map Drawing Tool - Design

Extent Map Drawing Tool - Design

Figure 2 Application Layer Use Case Diagram.

Extent Map Drawing Tool - Design

3.1 Accessing the System

Figure 3 Welcome Screen.

Create New Extent Map

Edit/Delete Existing Map

View Existing Map

Extent Map Drawing Tool - Design

Figure 4 Login Screen.

3.2 Create New Extent Map

Extent Map Drawing Tool - Design

Extent Map Drawing Tool - Design

Figure 6 Map Definition.

Extent Map Drawing Tool - Design

Figure 7 Heads-up digitizing of the extent map (exact layout of screen to be

Extent Map Drawing Tool - Design

Figure 8 Heads-up digitizing of the map.

Figure 9 Map submission.

Extent Map Drawing Tool - Design

Extent Map Drawing Tool - Design

Figure 11 Printing the map.

3.3 Edit/Delete Existing Map

Extent Map Drawing Tool - Design

Figure 12 Selecting an Existing Map to Edit.

3.4 Map Acceptance

Extent Map Drawing Tool - Design

Figure 13 Extent map lookup.

Extent Map Drawing Tool - Design

Figure 14 Extent Map Acceptance.

3.5 View Existing Map

3.6 Purging Old Maps

Extent Map Drawing Tool - Design

Extent Map Drawing Tool - Design