CISN Display System Change-List

Revised 5/3/05

Priority Items

1. Changes to the CISN Account Registration/Management Pages

1.1. Tool to retrieve username/password account information for registered users

1.1.1. Tool should allow a user to submit their e-mail address to the CISN Account Management pages to a link under the http://www.cisn.org/software/login/index.php called “Password Recovery”. Submission of an email address will trigger a query in the Master DB to SELECT, FROM the ‘user’ table for the ‘login’ name and ‘password’ WHERE the submitted address matches the ‘email’ field. Once recovered the automated action will continue and send the address holder the login information.

1.1.1.1.I don’t know if this is an issue, but the one-way password encryption might be something ISTI will need to modify, or get rid of, to allow the recovery tool to work?

1.1.1.2.We may consider logging these occurrences somewhere, even though they do not require CISN admin intervention?

1.1.2. Another approach is to provide central and local-Admins a means of resetting a given user account. This action will send them a new username/password to their email account. I prefer the first approach (1.1.1), but this may be easier to implement if the method already exists.

1.2. ISTI reports this has been fixed. I’ll remove it once everyone has had a look.

1.2.1. Remedy to prevent ‘ACTIVE’ status accounts from being reset when another user in the same group (reg-code) has their account changed to ‘DISABLED’.

1.3. Allow OPOC (Organizational Point of Contact) to edit the following items under “Edit Your Profile”:

1.3.1. Organizational URL

1.3.2. Organization Name.

1.4. ISTI informs me that this has already been implemented; I still need to check.

1.4.1. Currently the local Admin’s account in treated differently from other personal user accounts; this change should allow local-Admins to log into the CISN Display and connect to the messaging service.

1.5. Require all users registering to enter their email address twice

1.5.1. Submittal not only triggers a check against email/login entries in the Master DB, but should first perform a client-side check to confirm e-mail entries are a perfect match. If they fail the sanity-check, the fields are cleared and user is requested to reenter their email addresses again. Only a valid check between the two entries should prompt the PHP scripts to check the existing DB entries for duplicate e-mails.

1.6. Provide tool to CISN Management Admins to purge disabled registrants.

1.6.1. A query of the DB reveals some accounts that have been ‘disabled’, or in some cases the account status has been in a ‘validate’ state for several months; indicating that the user may have submitted a bogus email (this is evident for many accounts).

2. Changes to the CISN Display client

2.1. Provide for a “T” symbol signifying a ‘tsunami message’ in the “Earthquake List” column.

2.1.1. This will be similar to the “S” symbol that precedes a ShakeMap product; the “T” will alert users that there’s been a Tsunami message posted by NOAA. The “T” symbol will take precedence over the “S” in the earthquake list.

2.1.2. We will be asking the Tsunami message generators to reformat their text so a user can quickly determine whether the message is a null bulletin or a true Tsunami alert. We would like to move to an XML format as EIDS is implemented

2.1.3. Receipt of a tsunami “warning” should activate an audible (and visual?) alarm that can only be cleared by clicking on a prominent (flashing?) “tsunami button”. Clicking the button opens a web browser to the Tsunami bulletin URL.

2.1.4. A text message should also be available for distribution via the QWEmailer as a tsunami warning short-message for pagers/mobile phones. This may require parsing of the original Web-page message down to its key components (this will be easier once its in XML), or alternatively we could work with NOAA to make an abbreviated message available at a sister URL?

2.1.5. Ensure that the ‘Previous/Next event with ShakeMap’ keyboard shortcut still works when an event has both Tsunami and ShakeMap products associated with it.

3. Changes on the QuakeWatch server

3.1. Support for weekly statistic report to ‘cdadmin@cisn.org’ administrator

3.1.1. Weekly reports could contain a breakdown of daily-usage numbers for each QWServer (how may clients were connected), what peak CPU usage was for each day, etc…

Secondary Change List – Items will require additional discussion

1. Changes to CISN Display Client

1.1. Improved GIS support for ‘Raster’ layers (gifs, jpgs, tiffs, etc.)

1.1.1. This would allow the import of graphically-richer GIS layers depicting topography, annual foliage, shaded relief and other geographic and man made features. Currently the CISN Display only supports vector-based layers consisting of points, lines and fill colors

1.2. Develop additional GIS layers for major metropolitan areas of the country (the USGS will likely contribute this effort)

1.2.1.1.This effort would be in concert, or follow task 1.1 above. This might be accomplished by hiring/contracting a GIS programmer to develop new layers targeted for large population centers and other areas with an increased earthquake risk.

1.3. Support for ‘isochron’ GIS layers from Tsunami message generators (this implementation will require endorsement and cooperation from NOAA)

1.3.1. Proposal to automatically download ‘isochron’ wave-front layers from the Web and plot on display when these files become available from NOAA.

1.3.2. Proposal to automatically download tsunami ‘run-up’ (inundation) contours when these files become available from NOAA.

1.3.3. Automatically remove from display old isochron/run-up layer if a new updated layer (hourly updates?) becomes available from the same event source.

1.4. Develop CISN Display Bug-Tracking tool

1.4.1. Tool could be either:

1.4.1.1. CD client based; hit a button and it sends all pertinent information (CD version (mapping engine, libraries), JAVA version, operating system, and the client’s config file), and emails it to a pre-defined email, or bug reporting site.

1.4.1.2. or, a Web-site a user access from a hyperlink on the client, and fills out their pertinent information, along with a brief summary of what happened during the failure/error. It might be similar to one that SCEC came up with at: http://epicenter.usc.edu/la3d/bT/input.html

1.5. Complete integration of QWEmailer into CISN Display

1.5.1. Implement QWEmailer functionality \ within CD (i.e., not as a simultaneously running program), Whether it launches with the QWEmailer could be a user-defined option. I think the important point is that the QWEmailer use the same messaging stream as the standard CD client and not spawn its own thread; presumably this also helps ensure there’s only one ‘storage’ folder for event information.

1.5.2. Make QWEmailer use the same alarm rules that CD uses, but with the added feature to send out email notification

1.5.3. Under CD Tools | Alarm Regions, the circles/polygons configuration window will include the option to a) flash screen, b) sound alarm, and c) send out email.

1.5.4. Under CD Tools, provide an option for Configure Email Notification. The user would configure the SMTP server and establish the list of potential email recipients as presently done in QWEmailer. When the user establishes an alarm region in CD with Tools/Alarm Regions, the program would detect if Notification had been configured and then provide an option for issuing email. It would be handy if a list of all potential email recipients could be presented at this step with check boxes (and perhaps a checkbox for "all" recipients). This would enable customization so that users could get different types of notification (i.e., for a given alarm region some would get long email, others nothing, etc).

1.6. Enhancements and Integration of “QW Event Viewer” into CISN Display

1.6.1. Similar to requirements above for QWEmailer; it would seem cleaner for the mailer to use the same messaging channel as the CD client, but perhaps ISTI can point out why this is not necessary for the Event Viewer.

1.6.2. Sort events by user-selectable window headings: user clicks on “Date/Time” heading and events are ordered with most recent event at bottom of list; clicking heading again sorts events in reverse time order. Other heading options would be “Magnitude”, “Depth”, “Event ID” and “Network Code” (others?).

1.6.3. Window “Location” heading will not sort, but offer option between “Lat/Long” coordinates and “City Reference” note (just like that seen in the “Information Panel” on the CD client). Clicking the “Location” heading will toggle the event list between the two formats above.

1.7. Implement authentication option in QWEmailer SMTP server (many institutions require this).

1.7.1. Also (?) implement SSL for outgoing SMTP server

1.8. Enable CD to associate two events from different networks when CD is started after events were distributed and the program recovers both events from server. Currently last event received appears to be shown by CD – not the authoritative version.

1.9. Enhanced ‘auto select’ behavior for events that generate a ShakeMap, or are above a given magnitude threshold.

1.9.1. Users running the CISN Display in a ‘statewide’, ‘national’ or ‘global’ view mode will have the option to have their display drill-down to a desirable scale (preset, but configurable) when a ShakeMap is downloaded, or for events above a given magnitude (M>5). Of course the user can manually override the view at any time by zooming in or out.

1.10. This is already available under View | Show Map Mouse-Over Tips. I’ll remove item once people agree its adequate.

1.11. Make one of the banner options “none”

1.12. Provide option to make scale bar in km or miles

1.13. Could you clarify this point a bit more; sounds like something I should better document in the User’s Guide.

1.14. World Lines file should be improved.

1.14.1. Note, relatively detailed state layers are available from the Dept. of Transportation statistics GIS site, but I generally did not use these files since they noticeably slowed the CISN Display down when re-centering/navigating the map. I can reassess these layers and also get some feedback on what others think. If they’re not adequate then I’d expect the USGS to provide an optional set of state layers a user can download, or maybe we can provide them as a standard distribution?