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

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

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

4 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

5 Data Layer................................................................................................................. 23

6 Security ..................................................................................................................... 27

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

8 Future Enhancements................................................................................................ 32

ii


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

1 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.

1


Spatial Data

Spatial Data Store(SDE Oracle)

ArcIMS

Internet Mapping Framework

Application Locator User Interface(HTML, JavaScript)

Map Configuration Files(XML)

Novice End Users

Application Locator Portal(web browser)

Client Layer

Deployment Layer

Application Layer

Application LocApplication Logic

(Java)

ator

Data Layer

Internet Server (Apache)

GeoCortex Editing Suite(Java)

Temporary Spatial DataStorage (Shapefiles)

ESRI-compati(ArcGI

ble SoftwareS, AutoCAD etc)

Internet

GIS Specialist End Users

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.

2


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.

3


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.

4


Figure 2 Application Layer Use Case Diagram.

5


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.

Logged in users Pathway User not logged in Any user Regulatory

Officers

Create New Extent Map 9 9 Edit/Delete Existing Map 9 9 View Existing Map 9 9 9

6


Map Acceptance 9

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.

7


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.

8


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.

9


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

10


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


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


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


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


Figure 13 Extent map lookup.

15


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


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


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


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


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


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


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


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


Table 2 Extent Map Attributes.

Field Name Data Type

Inde

x*

NU

LL

Description

EXTENT_MAP_ID (PK) NUMBER(10) U N 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(10)

I N The SDW username of the person who created the map.

PROPONENT_NAME VARCHAR2(50)

N Proponent name (may be the first and last name or the name of a corporation).

DEV_TYPE_ID (FK) NUMBER(10) I N The ID of the development type associated with the map

NOTES VARCHAR2(4000)

Y The users notes or comments describing the map.

TITLE VARCHAR2(255)

N The name or title of the application.

DATE_TIME_CREATED DATE I N The date and time that the map was created. Defaults to the current date and time.

DATE_TIME_SUBMITTED DATE I Y Date & time the user completes the extent map & clicks submit.

DATE_TIME_MODIFIED DATE I Y 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 I Y The date and time that the map was approved. NULL value means map has not been reviewed.

ACCEPTED_BY VARCHAR2(10)

I Y The identifier of the regulatory officer who accepted the map.

APPLICATION_ID (FK) VARCHAR(255)

I Y 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) I Y The ID of the land and water board that the extent map is associated with.

STATUS_ID (FK) NUMBER(10) I N The status of the map. This defaults to the ID of the status value for Preliminary.

COORD_1_X_DEGREES

NUMBER(3,7) Y 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_MINUTES

NUMBER(3,7) Y Longitude minutes 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_SECONDS

NUMBER(3,7) Y Longitude seconds 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. Defaults

24


to zero

COORD_1_Y_DEGREES

NUMBER(3,7) Y Latitude 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_Y_MINUTES

NUMBER(3,7) Y Latitude minutes 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_Y_SECONDS

NUMBER(3,7) Y Latitude seconds 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. Defaults to zero

COORD_2_X_DEGREES

NUMBER(3,7) Y Longitude degrees coordinate of the Southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Null if defining a single point

COORD_2_X_MINUTES

NUMBER(3,7) Y Longitude minutes coordinate of the Southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Null if defining a single point

COORD_2_X_SECONDS

NUMBER(3,7) Y Longitude seconds coordinate of the southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Null if defining a single point. Defaults to zero

COORD_2_Y_DEGREES

NUMBER(3,7) Y Latitude degrees coordinate of the Southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Null if defining a single point

COORD_2_Y_MINUTES

NUMBER(3,7) Y Latitude minutes coordinate of the Southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Null if defining a single point

COORD_2_Y_SECONDS

NUMBER(3,7) Y Latitude seconds coordinate of the Southeastern corner of the extent map if the user defines the map by a pair of coordinates forming a rectangle. Defaults to zero. Null if defining a single point

NW_CORNER_LAT NUMBER(3,7) Y The latitude of the northwest corner of the envelope that encompasses the extent map

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

SE_CORNER_LAT NUMBER(3,7) Y The latitude of the southwest corner of the envelope that encompasses the extent map

SE_CORNER_LONG NUMBER(3,7) Y The longitude of the southeast corner of the envelope that encompasses the extent map

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


Table 3 Application Development Types.

Field Name Data Type Index* NULL Description

DEV_TYPE_ID (PK) NUMBER(10) U N The unique identifier of the development type. This field has an associated trigger and sequence to auto increment.

NAME VARCHAR2(50) N The name of the development type that is displayed in the user interface.

IS_ACTIVE CHAR(1) 0 = False 1 = True

I N 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.

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.


STATUS_TYPE_ID (PK)

NUMBER(10) U N The unique identifier of the status type. This field has an associated trigger and sequence to auto increment.

NAME VARCHAR2(50) N The name of the status type.

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.


BOARD_ID (PK) NUMBER(10) U N The unique identifier of the status type. This field has an associated trigger and sequence to auto increment.

NAME VARCHAR2(50) N The name of the status type.

26


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


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:

This background colour denotes content that is only visible to Dave

This background colour denotes content that is only visible to Geomatics

This background colour denotes content that is only visible to ENR/ITI

This background colour denotes content that is only visible to GNWT

28


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


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


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


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


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

IntroductionClient LayerApplication LayerAccessing the SystemCreate New Extent MapEdit/Delete Existing MapMap AcceptanceView Existing MapPurging Old Maps

GeoCortex Editing Suite IntegrationIMF ToolbarEditing suite ModeMap LayersDisabled FeaturesCoordinate GeometryFrames

Data LayerSecurityOutstanding QuestionsFuture Enhancements

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /Unknown

/Description >>> setdistillerparams> setpagedevice

extentmap design v07

Documents

new extent map

map acceptance

map layers

extent map drawing tool

editdelete existing

view existing map

application layer

data layer