Atlas_Requirements_draft – Yukon Planning Atlas

Context Navigation

Yukon Atlas - Draft Requirements Document

Draft requirements based on Proposal, Contract and discussions between YLUPC and DMSG

General

Description

application will accommodate several types of users
spatial data and application functionality made available will depend on the type of user
an administrative interface will be used to manage users and groups
Spatial operators and reporting will be included in the mapping application

Limitations

All editing of features will be done outside of this application.
This application will not be real-time resource reporting.
Resource data will be updated by the individual groups at their own discretion.
This application will not be a data warehouse. The CSW will host most of the base layers.

Design Constraints

The interface must be kept simple and non-technical.
- %ORANGE%NS: This constraint may be seen as a usability requirement but it is not testable as is. I don't know exactly where the team is at with respect to the GUI approval. Does the designer approach in page 14 corresponds to what the client needs? Are they any restrictions in the number of tabs to use? Can dropdown list be used?%ENDCOLOR%
The application won't use non-proprietary technologies.
The YLUPC needs a web-enabled application.
The application must adhere to CGDI (Canadian Geospatial Data Infrastructure) standards.

Functional Requirements

User Login / Authentication

application needs to be user aware and provide certain spatial operations to authenticated users only
application will include a “user management” interface for administrators, to manage users' information. It will allow the administrator to:
- Add and remove users
- Add and modify users' profile information
- Set username and passwords and reset the users' passwords
- Create groups of users, and allow users to be added and removed from groups
- Assign specific data layers to groups

User Classes and Privileges (FW in consultation with !JeffH)

Administrator
- can modify and extract data
- full access to site
Registered User
- cannot modify data
- can extract data
- can view data they are authorized to
Unregistered User
- cannot extract or modify data
- cannot view any secure data

%I%Discussion notes%I%

from discussions !JeffH also wants the user management interface allow for grouping of users
to "assign specific data layers to groups" the plan is to use <nop>MapServer?<nop>'s new include ability for mapfile contents
- each layer will be a separate .map file
- a mapfile template will exist, without any layers
- each time a user logs-in the map template will be populated on-the-fly with the layer includes
- symbology can also be included
from discussions with !JeffH, the interface should allow for data to be published to a specific group, or public, or not to publish at all
!JeffH created a use-case scenario document for each type of user.
- from !JeffH: "The use-case document is my attempt to describe the site function in simple terms. Does this make any sense to you, and if so, does it sound like we're on the same songsheet?"
- from 11/17/06 meeting, !JeffH mentioned that the atlas of South Australia is a great example of this user-selecting theme/area before viewing full maps
idea is to create a matrix of types of users and their access to all possible layers
from 12/03/06 meeting:
- %H% Does https cause a performance hit?
  - %GREEN%FW: HTTPS will have a performance impact according to our developers. There is a server hit oviously, but a browser behaves differently too. One point of concern is that nothing will get cached by the browser, so repeated elements like images will be requested multiple times, and reloading the page will request everything too. Also it seems that different browsers may handle https pages diferently. Aparently Safari, the leading Mac browser behaves horribly with https. I think we should discuss what the requirement would be, and if using HTTPS is really meets the requirement. %ENDCOLOR%
  - %BLUE%JH: The requirement is that user authentication be verified for allowing access to the advanced features, including upload. It should be sufficient to prevent direct access to 'advanced' pages unless authentication has taken place (using global or session vars?). There are no 'secure' transactions that would justify the performance hit from HTTPS. There is no need to encrypt data (or queries) for security or privacy reasons. If data are that sensitive, they don't belong on a public web anyway. %ENDCOLOR%
%RED%JM: Mapfile includes currently only work with full paths, but I have bugged the MapServer developers about this and it will hopefully be fixed in the next few weeks ( http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1880) %ENDCOLOR%
%GREEN% FW: Assumption is that for the registered users group, all layers that are viewable are also extractable %ENDCOLOR%
%BLUE% JH: There may be layers for which no extraction will be permitted. %ENDCOLOR%
%GREEN%FW: Missing Requirements:
- Need to create groups and add users to them.
- Users can belong to more than one group
- Group privileges on a layer or map are additive. So if a user is part of two groups, and one of the groups has special access to certain layers, that user gains that access. %ENDCOLOR%
%GREEN%FW:Need to concider privileges on widgets. JeffH, Could you provide us with usecases, or the widgets you need privileges on? %ENDCOLOR%
%BLUE%JH: Data extraction is already covered, so this is my Xmas wish list... Would a custom summary report require its own tool? The Results pane would presumably display different tables/images based on the type of summary (see below):
- PrivelegedCEMonitorTool - Cumulative Effects Monitoring Tool:summarize linear disturbance (Total km of 'linear features'/km2 of ROI) and footprint (area of feature_specific_width_buffered linear features PLUS area of polygon land use features as % of ROI, by feature type), and current permit and application (point feature attributes) within ROI. This would be avilable to the DevelopmentAssessmentGroup? who would be informed about the risks in using dynamic, incomplete and potentially inaccurate information.
- PrivilegedBioSummaryTool?: Summarize Biophysical map (90m raster-30 classes) within ROI with optional (as inset?)classification by selected season/species (e.g. winter caribou 30 landscape types into 4 suitability classes) and optional landscape images for landscape types within ROI. This would be accessible to users in the WildlifeGroup?, who would be informed about the ethical use of such data.

Maybe the results pane for complex reports just shows links to PDF reports generated by the request?

PrivilegedMediaTool?: Process Media Upload (feature attribute linked to multimedia file upload (img or video)?) for each site within ROI (ie from a queryresult list). This would only be available on (selected?) layers available to the Group (e.g. Heritage layers of archealogical, cultural or protected sites; landscape images by the EcologistsGroup?).
RefreshCachedWMS: An administrators tool to regenerate the local cache from remote wms_servers.

Display / Navigation of Spatial Data

Zoomin with bounding box or point
Zoomout fixed on single click on button
Zoom to Extents
Pan (possibly both drag and pan n/s/e/w)
Legend with layer control (ability to turn on/off layers)
- including symbology on layer - all of symbols displayed on map
Recentre

Those navigation tools are what will be included in the 'unregistered users' suite of available tools.

%ORANGE%NS: Should we describe tools for other user classes? %ENDCOLOR%

%I%Discussion notes%I%

all are existing Chameleon widgets
from 11/27/06 meeting:
- for legend, basic interface would have "themes" displayed ("7 or less thematic groups"), whereas for the advanced interface the legend would have full layer management with a treeview
- some data layers will require a data sharing agreement to be displayed
  - could be discretely displayed in a frame

privileges

%GREEN%FW:Missing Requirements:
- Need to offer users "regions" to zoom to and "themes" or maps to view
- The themes available may depend on the region being viewed. JeffH, needs to provide the regions and themes, and provide any region dependant themes.
  - %RED%JM: JH to also provide associated spatial extents for all regions%ENDCOLOR%
- Map title needs to be dynamically created and contain region and theme.
- Need map size widget with small and large sizes to fit 800x600 and 1024x768 screen sizes%ENDCOLOR%
%RED%JM: Basic interface includes a point query widget%ENDCOLOR%

Summarize Spatial Data

Users can perform calculations: distance, area, sum, count, proximity and buffer.
- buffer
  - user would select feature first
  - allow users to generate buffer at defined distance
  - summarize results
  - %ORANGE%NS: Will the summarized results be of the same type as the selected feature? Based on what we said in the from 01/11/07 meeting it could be any types of feature on active layers. Is this correct?%ENDCOLOR%
  - %ORANGE%NS: Does a user will be able to select attributes to be displayed?%ENDCOLOR%

simple spatial boolean operations, such as:
- What proportions of the 'region of interest' are good/fair/poor caribou habitat?
- How much of the good quality caribou habitat (as of today) was burned within the last 20 years?
- How many cultural sites are located less than 20km from a wetland or river corridor?
- How many kms of seismic line were constructed in 1995-2005 through mesic conifer forest in the Chance Creek ecodistrict?
- %ORANGE%NS: Is it possible to list the possible operations? We said in the meeting that it can be addition and substraction of ROI.%ENDCOLOR%
- %ORANGE%NS: How a user will question the database? Will a user select a region of interest first and then will he select among a set of parameters (km, seismis line, caribou)? We talked in the meeting about pre-defined query.%ENDCOLOR%
- It is written in the progress report "For the basic interface, set queries with pre-processed results will be used. YLUPC will provide the results to be used. "
  - %ORANGE%NS: Do the pre-processed results will be also made available in the other interface?%ENDCOLOR%
  - %ORANGE%NS: How do a region of interest will be selected for the pre-processed results? Will a user have a list of regions to select in?%ENDCOLOR%

proximity
- e.g. What other features are within x meters of selected feature

%ORANGE%NS: Is the proximity functionality the same as the buffer one?%ENDCOLOR%

%S%Summary of raster cell values by area%S%
- user would specify a region of interest (rectilinear bounding box)
- statistics would be produced of the raster (e.g. DEM) for that area, and reported to the user

user would select the active layer(s), and depending on the type of layer certain operations would be available
- %ORANGE%NS: Can we list operations by layer type?%ENDCOLOR%

%I%Discussion notes%I%

Raster analysis package may be required for raster summary %X%
- options are:
  1. use canned queries with pre-processed results
  2. implement a GRASS SERVER in the backend to process the raster query (using v.rast.stats in GRASS>6.1 or by converting raster to vector or using GRASS and PHP)
  3. include a message that the result will be emailed to you at a later time...kinda thing
  4. implementing full raster analysis in a later contract
[:Atlas_Raster_Analysis_use_case:Raster Analysis use case] by !JeffH
another option is to use the PGCHIP driver for GDAL/PostGIS, to convert rasters into the Postgres CHIP format
- only "a few" functions exist for the CHIP datatype however
- PostGIS notes on raster support on their Wiki
- %RED%Proposed PostGIS SQL interface for PGRaster datatype%ENDCOLOR%
  - %RED%recent thread on !PostGIS list%ENDCOLOR%
another option is to allow user to extract smaller area for their own local analysis
!JeffH wants us to "explore" the options available for this, and that he is "ok with this not being a deliverable"
report from Assefa on GSC Coal raster "analysis":
- application allows users to extract area
- uses a php plugin to do basic stats on the pixels like min/max/area etc.
- from assefa: "anything deeper would require a raster package" like GRASS
from 11/27/06 meeting:
- all in agreement that GDAL functionality (including accessing its histogramming ability) will be sufficient, but other avenues (GRASS) should still be explored
- !JeffH: "simple is good"
%RED%The existing Chameleon GRASS widget execs GRASS commands through PHP.%ENDCOLOR%
- %RED%Another option is the use the grasslib library, and the python version of grasslib is called PyWPS%ENDCOLOR%
  - %RED%Company named Omniverdi has implemented !PyWPS in the backend of a kap-map application: http://devpywps.ominiverdi.org/trunk/web/embrio/raster/r_los/r_los_ka_map.php
  - downside of the grasslib route: requires development and more time investment (whereas straight execs through GRASS SERVER are more straight-forward, yet possibly slower)
  - %Q% Is there PHP bindings for grasslib yet?%ENDCOLOR%
%RED%from 12/07/06 meeting:
- all agreed that a single use-case will be selected by !JeffH for raster analysis, and the various options (GRASS, GDAL) will be examined closely for that use-case by the DMSG team, in the beginning of phase 2
- GRASS version to be used for the use-case is the latest release, 6.2.1 (released Dec 12th '06)%ENDCOLOR%
%GREEN%FW:This tool will likely need the ROI tool.%ENDCOLOR%
%GREEN%FW: We need the requirements and approach nailed down no later than January 22, 2007.%ENDCOLOR%
%RED%JM: Canned summaries would be in the basic interface. JH can I safely say that the YLUPC would provide the query and the results?%ENDCOLOR%
%BLUE%JH:Yes. I need an interface to generate query parameters and send results to a template. I also need an interface to functions for spatial data summary (e.g. GRASS, postGIS, Mapserver)%ENDCOLOR%

Locate/Filter?

Quickzoom – dropdown of regions (or other “jump-to” locations)
Filter based on attributes (similar to Chameleon's expression builder)
- %ORANGE%NS: Can we list the available filters?%ENDCOLOR%

%I%Discussion notes%I%

Quickzoom supported by Chameleon - see http://sapienza.mapsherpa.com/geoportal/ for an example
As new use cases are revealed, need to re-evaluate Filter construction tool functionality requirements
%GREEN%FW: Layer filtering is for the advanced interface, and consists of an expression builder type dialog. Need to define the fields needed for that form. %ENDCOLOR%
%GREEN%FW: We discussed potentially having precanned filters for the basic interface, but decided that textual links in the information area would be just as effective.%ENDCOLOR%
- %ORANGE%NS: Do a textual link will point to an image or what will a user see when he clicks on a link?%ENDCOLOR%

Report Attributes

Print query results.
Maptips for active layer. Can toggle maptips on or off.
Export map in PDF form.

%I%Discussion notes%I%

FW: %GREEN%If we are printing Query results, how do we perform a query? Is this a drilldown query tool?%ENDCOLOR%
%GREEN%FW: Yes, this refers to the drilldown query tool.%ENDCOLOR%
- JM: %RED%Good question. It seems we're missing an ROI (region-of-interest) tool that is used to specify the area for the spatial operators, and those results would then be printed.%ENDCOLOR%
- %GREEN%FW: The ROI tool is not needed for this requirement.%ENDCOLOR%
%GREEN%FW: "export map to PDF" refers to a print layout with a title and legend (or a defined template) in a PDF.%ENDCOLOR%
%ORANGE%NS: There is a mention about PostScript? in the use case #1. Will PostScript? be used for query results and PDF for map?%ENDCOLOR%

Base Map Data

Base Map data will be obtained from the Geomatics Yukon Corporate Spatial Warehouse (CSW). This warehouse will be based on ESRI SDE, and will be accessed by the public through OGC:WMS.
- Possible CSW layers include: rivers, roads, trails, lakes, cadastre, leases, licenses, permits, land use and development plans, flora/fauna inventories, and parks.
- If the SDE layers cannot be accessed directly from the CSW, the WMS requests must include SLDs.
  - %ORANGE%NS: I know we discussed this point in 01/11/07 meeting but I write it down here to not forget to update the progress report. Eventhough a SLD is specify in the WMS request, if the connection to the SDE is broken the shapes will not be available.%ENDCOLOR%
  - %ORANGE%NS: Is it how it works? A WMS server located at the CSW warehouse will give access to a database containing shapes. The connection type for each layer will be SDE. A WMS request will be sent to this WMS server.%ENDCOLOR%

Local base map data will be maintained by the YLUPC.
- !JeffH has created an AtlasDataSchema.
  - JM: %RED%The schema in fact appears to be separated into THEME, GROUP, SOURCE, LAYER. Am I correct !JeffH that source is included?%ENDCOLOR%
- from 11/27/06 meeting:
  - data schema doc will be used to generate lookup table in postgres
- %N% to be discussed: does YLUPC have any data style guides? (they already produce high quality print maps)
  - %RED%12/07/06 !JeffH sent message to Richard on list mentioning tracking design decisions in style guide document %ENDCOLOR%
- %ORANGE%NS: What is the difference between the base map data and the local base map data? Does the base map data contains all the basic layers? Does the local base map data contains the data uploaded by users?%ENDCOLOR%
  - %ORANGE%NS: From 01/11/07meeting we said that Geobase data will also be accessed. Data layer located on external server that does not change often may also be stored at the Yukon server. The administrator will be in charge to layer update.%ENDCOLOR%

%I%Discussion notes%I%

local YLUPC data will be stored in either shapefiles (for speed) or !PostGIS (for those needing spatial functionality)
from 11/27/06 meeting:
- serving atlas data through WMS is not part of this project
[:Atlas_datasources:Atlas Datasources]

Thematic Content

ability to cross-tabulate different datasets is required. Examples of thematic content required are:
- Areas of importance to caribou, moose and marten
- Location of important wetland and river complexes
- Potential for oil and gas development activity
- Important wildlife corridors
The atlas will contain value-added thematic data, that is maintained by the YLUPC.

%I%Discussion notes%I%

from discussions: datasets compared could be vector to raster, so a raster package could again be required (see comments in the "Summarize Spatial Data" section above)
Cross-tabulation and co-occurence for vector-to-vector coverages can be calculated using PostGIS functions
GDAL Library supports direct calculation of descriptive statistics on a layer-by-layer basis. Does not appeart to support cross-tabulation/image algebra out of the box. Scripting with GDAL primitives would be required.
%Q% For Jeff Hamm - Is a raster to vector conversion a possibility? - i.e. convert raster coverages of habititat to PostGIS polygons using a script - this would resolve data conversion issue related to using GRASS

Upload for Authorized

Authorized users would be able to upload spatial data. This will require a front-end interface to allow for loading of data into the relational database.
Supported data formats will need to be well defined. At present, .SHP and GML are envisioned.
- %ORANGE%NS: Is there any final decision beeing made on the format?%ENDCOLOR%
Constraints may include requirement for .PRJ file with .SHP - or must include Projection info with .SHP
Requires a minimum set of metadata elements
- %ORANGE%NS: It is written in the progress report that styling will be minimal. What type of styling will be allowed?%ENDCOLOR%

%I%Discussion notes%I%

from !JeffM: I think !JeffH mentioned that uploaded data does not get published directly
%PURPLE% PP: The assumption is that authorized users in this case are equivalent to registered users %ENDCOLOR% %Q%
%BLUE% JH: It should be possible for a registered user to upload data without the data becoming 'public' by default. Registered users may upload data, view personal data layers, and set personal layers as 'published' to become visible to other registered users. Non-registered users will only see predefined thematic maps. %ENDCOLOR%
FW: %GREEN%If a user adds a layer to the map via upload, do they also need to style the layer, select a column to label with, and style the labels. Can the styles be limited or predefined in some way? Do uploaded layers also need to be deletable?%ENDCOLOR%
%RED% JM: In terms of data layers, I would say that we follow the OGC OWS standards for layer metadata ( http://mapserver.gis.umn.edu/docs/howto/wms_server/#layer-object-metadata) and force the requirement of the following minimum metadata for each layer in the Atlas:
- ows_title - Name for the layer.
- ows_metadataurl_href - The URL to the layer's metadata.
- ows_metadataurl_type - The standard to which the metadata complies.
- ows_srs - The layer's EPSG projection.
- ows_abstract - Description of the layer.
in terms of uploading data, would this mean that we would have to allow the user to enter those metadata in the interface somehow?%ENDCOLOR%
%GREEN%FW: Missing requirements:
- User needs option to request layer be made public
- Need a way to limit size of uploadable files
- Do we need to limit total disk space allowed per user? %ENDCOLOR% %BLUE%JH:Yes. Possibly by providing a fixed sized repository for each user on registration?%ENDCOLOR%
- %GREEN%FW: Administrator needs to be informed via email when a file has been uploaded, especially if a request for upload has been made%ENDCOLOR%
%RED%JM: need a new widget for styling the layer when uploading
- tight constraints would be set on labelling (especially for lines/polys)
- would be minimal, since this was not factored into the original proposal %ENDCOLOR%

Data Extraction Tool

Certain layers would allow extraction.
- Users would define bounds for extraction.
- Possibly only YLUPC data would be available for extraction.
- Will include raster layers.

%I%Discussion notes%I%

from discussions <nop>JeffH<nop> says that some data may require a licensing warning to user, before extraction
from discussions, the extracted formats would be:
- SHP
- GML
- <nop>GeoTIFF<nop>
%GREEN%FW: User defines the area and selects the layer to extract from. For Bill: Does this require the ROI tools, or is the area selection built into the extract tool? %ENDCOLOR%

Add Local Content

Allow authorized users to point locally to spatial data
- possibly guide users to load data directly into a relational database
- or possibly have users load map context documents on their local machine
Add pointers on map (e.g. “my cabin”)

%I%Discussion notes%I%

from discussions: local data could be:
- GPS coords (possibly using GPSBabel)
- SHP format
- %PURPLE% GML 2.x
Minimum metadata requirement - including Projection in EPSG:xxxx. Constrained to 3-4 projections. Yukon Albers, Lambert CC, UTM (3 Zones), Lat/Long?.
Look at supporting well-formed WKT %ENDCOLOR%
from discussions: context support would essentially be UPLOAD and SAVE CONTEXT buttons in the map interface
from 11/27/06 meeting:
- all in agreement that for formats GPX and SHP should be supported, and GPS notes for GPX creation would be provided in a howto.
- it was noted that this functionality would only be in the advanced interface
%RED%GRASS has an import-using-GPSBabel command:%ENDCOLOR% v.in.gpsbabel (see also v.in.garmin)
FW: %GREEN%There is a MapNotes? widget that allows users to quickly add a point to the map by clicking the map. Is this desired, or are we only adding points by uploading data? MapNotes? creates a layer for the point, and the widget provides the ability to style the point and label. Currently the layer exists only in the session but it is not impossible to modify the widget to save it for the user. Once points are created do they need to be deleted individually? Does the entire MapNotes? layer need to be deleted?%ENDCOLOR%
%GREEN%FW: Adding points via upload (see upload requirements) also use mapnotes to make a scratch layer per user. %ENDCOLOR%

Provide Feedback

provide a form to allow users to provide feedback on the application.

Access to Non-spatial Information

Links will be provided to non-spatial data such as text/tabular data.
from 11/27/06 meeting:
- !JeffH wants "content sensitive info in the frame" when looking at a specific map

Multilingual

This is not a formal requirement, but should be kept in mind.

%I%Internal notes%I%

from discussions: international character support in <nop>MapServer?<nop> is required, and nothing further.

Nonfunctional Requirement

Operating Environment

The physical location of the application will be on the YLUPC server in Whitehorse. The reason for this is that most users are anticipated to be in the Yukon.
The hosting environment will be Apache, Linux, PHP, and <nop>PostgreSQL<nop>.
- Versions?
Web browsers supported are Internet Explorer 6.0, Firefox 1.0, and Safari ?.

Application Architecture

[:Application_architecture:Application Architecture] - diagram of software component interaction
[:Database_architecture:Database Architecture] - !PostgreSQL table structure
[:Filesystem_architecture:File System Architecture] - mapfile locations...

Documentation

End user application help must be provided.
Administrator's document is also required.
[:Documentation_plan:Documentation Plan]

Maintenance & Testing

YLUPC will maintain the site and provide training sessions to other Yukon planning groups.
DM Solutions will provide training to YLUPC on maintaining the application.
[:Qa_plan:Testing and QA Plan]

Security Concerns

application must accommodate control and access to authorized users.
Secure spatial data will be maintained in a relational database.

Usability

application should have reasonable response times.
Spatial operations must be limited by the user class (registered vs non-registered)
application will not require any special technical training to use.

%I%Internal notes%I%

!JeffH has said that for performance times, the critical test is the performance for local Yukon users, as opposed to performance in Ottawa or elsewhere
FW: %GREEN%The basic interface needs to be really basic if users are expected to just surf the site. The advanced interface may have components that users may need to read about before understanding. This could include extraction, filtering, uploading, and raster summaries.%ENDCOLOR%

Performance Constraints

Relying on outside data sources, such as the CSW and WMS, will hinder performance.
Users must have Internet access and a conventional web-browser to use the Atlas.

Design

[:Atlas_Design_draft:Draft Atlas Interface Design Document]
[:Admin_Design_draft:Draft Admin Interface Design Document]
[:Site_Design_draft:Draft Site Design Document]

Download in other formats:

Plain Text