Authors:
Joakim Eilertsen
Espen M. Braaten
Jørgen Lie Pettersen
EQ-Forecast – Final report
Project report
Final Project
Number of ECTS: 15
Engineering field: Computer science
Project title:
Free accessible
Free access after:
Accessible after agreement
with the contractor
x
Date: 2005.05.30
EQ-Forecast
Number of pages: 76
Number of attachments: 3
Authors:
Councilor:
Joakim Eilertsen, Espen Braaten and Jørgen Lie Pettersen
Terje Samuelsen
Department / line:
Project code:
IT – Information Technology
H05D02
Produced in cooperation with:
Contact person at the contractor:
Time Research, USA
Marsha Adams
Extract:
Time Research, a small, privately financed research institute, has developed a detection
system which is used to predict earthquakes. Today, they manually create earthquake reports
from the data found by the detection system. There is a strong need for automation.
Time Research wanted us to automate the entire forecast process. We get all the information
out of generated database files, and use it to find the accuracy of the earthquake forecasts.
We do this by extracting tons of information, most importantly longitudes and latitudes,
from several renowned earthquake web sites, with daily updated earthquake readings. We
use this information to track and calculate the accuracy of every predicted quake. The end
result of this project is a continuously automatically updated research website with access to
all the forecast information, and forecast results.
This project is an important step forward for Time Research’s earthquake research, and we
hope it will aid the research in understanding earthquakes better.
3 indexing terms:
Electro Quake
Earthquake forecasts
Earthquakes
http://prosjektexpo.hiof.no/expo05/h05d02/
-2-
EQ-Forecast – Final report
Preface
The project, ”EQ-Forecast” was done over a time period of twelve weeks, 2005.03.14 - 2005.05.30
This is the primary project during our third and final year at Ostfold University College. We attend a
computer engineering course, our degree, when finishing the study; will be “Bachelor of computer
science”.
The project is made in co-operation with the research institute Time Research, which is located just
outside San Francisco, CA.
The reason we chose this project and found it interesting, were the fact that we like working on web
solutions, and making something to be used in earthquake research seemed like a fun challenge.
This report contains some technical terminology. This is necessary to describe the different functions of
the system solution. All though the terminology is explained, and a brief overview of abbreviations etc is
given near the end of the report, one should still note that this report is primarily written for the use of
researchers/system developers connected to Time Research. It is therefore also important to keep in
mind that the level of detail, when describing the system solution, in some parts of this report will be
deeper than conventional project reports.
Sarpsborg, Norway, 2005.05.30
Espen Braaten
Joakim Eilertsen
Jørgen Lie Pettersen
http://prosjektexpo.hiof.no/expo05/h05d02/
-3-
EQ-Forecast – Final report
Table of contents
1
PROJECT REPORT ....................................................................................................... 2
2
PREFACE .................................................................................................................... 3
3
TABLE OF CONTENTS .................................................................................................. 4
4
INTRODUCTION ......................................................................................................... 6
5
SITUATIONAL ANALYSIS ............................................................................................ 8
5.1
DESCRIPTION OF THE TECHNICAL EQUIPMENT ..................................................................... 12
6
REASONS FOR UPGRADING ...................................................................................... 13
7
PERFORMANCE SPECIFICATION ............................................................................... 14
7.1
7.2
8
FUNCTIONAL REQUIREMENTS ........................................................................................ 14
TECHNICAL REQUIREMENTS.......................................................................................... 15
SYSTEM SPECIFICATION .......................................................................................... 16
8.1
ABOUT THE LONGITUDE AND LATITUDE CALCULATIONS .......................................................... 16
8.2
SYSTEM OVERVIEW ................................................................................................... 18
8.2.1 Stage 1............................................................................................................ 19
8.2.2 Stage 2............................................................................................................ 19
8.2.3 Stage 3............................................................................................................ 20
8.2.4 Stage 4............................................................................................................ 20
8.2.5 Stage 5............................................................................................................ 20
8.3
THE PROGRAM SYSTEM ............................................................................................... 21
8.3.1 Program part 1 ................................................................................................. 22
8.3.2 Program part 2 ................................................................................................. 24
8.3.3 Program part 3 ................................................................................................. 29
9
THE EQ WEBSITE ...................................................................................................... 31
9.1
LOCAL FORECAST RESULTS .......................................................................................... 32
9.2
SEMI-FRINGE FORECAST RESULTS .................................................................................. 33
9.3
TRUE FRINGE FORECAST RESULTS .................................................................................. 34
9.4
WORLD WIDE EARTHQUAKE REPORT ................................................................................ 35
9.5
THE PRINT PAGE ...................................................................................................... 36
9.5.1 The printer friendly pages .................................................................................. 37
9.5.2 The PDF file ...................................................................................................... 38
9.6
THE LOGIN SYSTEM ................................................................................................... 39
9.6.1 New forecasts ................................................................................................... 42
9.6.2 Admin pages .................................................................................................... 43
9.6.2.1 User management ...................................................................................... 43
9.6.2.2 The user list .............................................................................................. 45
9.7
AUTOMATIC UPDATING ............................................................................................... 46
9.8
AUTOMATIC DELETION OF OLD FILES ............................................................................... 47
10 PROJECT SCHEME ..................................................................................................... 48
10.1
10.2
MILESTONES........................................................................................................... 48
THE RESPONSIBILITY DISTRIBUTION ............................................................................... 48
11 CONCLUSIONS ......................................................................................................... 49
11.1
BEYOND THE PROJECT – POTENTIAL IMPROVEMENTS ............................................................. 49
12 ABBREVIATIONS ...................................................................................................... 50
13 SOURCES .................................................................................................................. 51
http://prosjektexpo.hiof.no/expo05/h05d02/
-4-
EQ-Forecast – Final report
13.1
13.2
PERSONS............................................................................................................... 51
INTERNET SOURCES .................................................................................................. 51
14 PICTURE REFERENCES.............................................................................................. 52
15 APPENDIX ................................................................................................................ 53
15.1 ABOUT THE APPENDIX ................................................................................................ 54
15.2 APPENDIX INDEX ...................................................................................................... 55
15.3 USER MANUAL ........................................................................................................ 56
15.3.1
Apache and PHP 5 installation on UNIX systems ................................................ 56
15.3.1.1 Apache 1.3.x on UNIX systems .................................................................... 57
15.3.1.2 Installation Instructions (Apache Shared Module Version) for PHP: ................... 57
15.3.1.3 Installing PHP as a static object .................................................................... 59
15.3.1.4 Example commands for restarting Apache ..................................................... 60
15.3.2
Installing Python............................................................................................ 62
15.3.2.1 Platform variations ..................................................................................... 62
15.3.2.2 Splitting up the job ..................................................................................... 62
15.3.2.3 How building works .................................................................................... 63
15.3.2.4 How installation works ................................................................................ 63
15.3.2.5 Modifying Python’s search path .................................................................... 64
15.3.3
About the user database and MySQL ................................................................ 66
15.3.4
Changing the structure of the database file ....................................................... 67
15.4 DEBUG REPORT ....................................................................................................... 68
15.4.1
Program part 1 .............................................................................................. 68
15.4.2
Program part 2 .............................................................................................. 68
15.4.3
Program part 3 .............................................................................................. 69
15.4.4
EQ Forecast system CD-ROM and installation .................................................... 70
15.5 GANTT-CHART ......................................................................................................... 71
15.6 DETAILED MAP OF THE LOCAL FORECAST AREA .................................................................... 73
15.7 DETAILED MAP OF THE FRINGE AREAS .............................................................................. 74
15.8 APPENDIX PICTURE REFERENCES .................................................................................... 75
15.9 SOURCE CODE, SEE APPENDIX 2 AND 3............................................................................ 76
http://prosjektexpo.hiof.no/expo05/h05d02/
-5-
EQ-Forecast – Final report
Introduction
Time Research, a small, privately financed research institute, is located just outside of San Francisco,
CA. They have developed a detection system which is used to predict earthquakes. The subscribers of
this service get a notice of expected earthquakes every week.
This is a sample from one of the written reports that are sent to their subscribers.
Figure 1: Sample from an EQ written report.
The forecast report consists mainly of two parts; the local and fringe forecast results. The local forecast
report provides an overview of expected earthquakes in the primary ElectroQuake forecast region, which
is California, extending a little bit into Nevada, Mexico, and off the western coast. The second part, “the
fringe”, is an overview over earthquake predictions for larger quakes in the fringe area. Please see
Figure 4 and Figure 5, page 9 and 10, for a more in depth explanation of what defines the local and
fringe areas.
The detection system generates database files, which contain important information about the forecasted
earthquakes, such as their longitudes and latitudes, estimated dates of occurrence, and magnitudes.
The data from the database files are compared with data from occurred quakes, found on renowned
earthquake report web sites (Internet sources, page 51, for a list of the web sites). The longitudes and
latitudes from the database files are matched up with longitudes and latitudes from the web sites. If a
quake occurred at the predicted time in the predicted area, within a 25 mile radius, it is considered a
correct forecast.
http://prosjektexpo.hiof.no/expo05/h05d02/
-6-
EQ-Forecast – Final report
Time Research needed us to automate this entire forecast process. Our system gets all the information
out of the generated database files and information from the earthquake web sites, to find the accuracy
of the earthquake forecasts. The end result of this project is a continuously automatically updated
research website with access to all the forecast information, and forecast results. See Figure 8, page 18,
for a more detailed system overview.
http://prosjektexpo.hiof.no/expo05/h05d02/
-7-
EQ-Forecast – Final report
Situational analysis
Below you will find a description of how the EQ-Forecast system works today, before our automation.
Figure 2: The report system before this project.
As mentioned in the introduction, the way the report part of the system works now, is that Time
Research will send a report of the earthquake predictions to their subscribers once a week. The making
of the reports is today done manually. Today Time Research goes on the Internet and manually
compares research data from their earthquake predictions with earthquakes that occurred in the area
predicted.
The earthquake prediction equipment gathers research data and puts it into database files. The database
files consist of lines with information for each earthquake forecast. The most important information for
each forecast is the longitudes and latitudes of the predicted quake, together with the date when it is
measured to occur.
http://prosjektexpo.hiof.no/expo05/h05d02/
-8-
EQ-Forecast – Final report
Figure 3: An extraction from a database file.
What Time Research does nowadays is to manually look up each of these sets of longitudes and
latitudes, after the quake should have occurred, and check the accuracy of the forecast.
Their current report is in essence split in two halves: One half covering the “local Californian area”, and
the other covering forecasts for “the fringe”.
The local Californian area is mainly California, but it also extends a little bit into Nevada, Mexico and
off the Western Coast.
Figure 4: An overview of the local area.
http://prosjektexpo.hiof.no/expo05/h05d02/
-9-
EQ-Forecast – Final report
As you can see in Figure 4, page 9, the reason the local forecast area extends the Californian border
somewhat, is the fact that the map has been purposely defined in square degree sectors.
Because this is where the forecast coverage is the most accurate, this area is also known as the primary
forecast area. A forecast must hit within a 25 mile radius to be considered a success within the primary
forecast area.
For a larger, and more detailed, version of this map, see 1.25, Detailed map of the local forecast area,
page 73 in Appendix 1.
The fringe is a larger area around California, and the North Western USA. Everything outside of the
local Californian area, on this map, is defined as the fringe.
Figure 5: An overview of the fringe.
The map, Figure 5, defines larger areas south of Queen Charlotte Island, Vancouver Island and the
Seattle-Tacoma-Vancouver area. The red markings you see on the map signify the “semi-fringe” area.
They are far away from the main forecast area, but the system has some locating capability there.
However, the coverage is not as good as the primary forecasting area.
The system is expected to be more accurate in the "semi-fringe" areas than in the true-fringe (everything
outside of the forecast areas shown on the map). In the fringe areas, the system is capable of detecting,
but not accurately locating quakes. If the forecast hits within a 50 mile radius in the fringe, it is
considered a success.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 10 -
EQ-Forecast – Final report
For a larger and more detailed, version of this map, see Detailed map of the fringe areas, page 75 in
Appendix 1.
Every quake in the local and fringe forecast areas must have a magnitude of at least 3.0.
Every quake, outside the local and fringe areas, that is larger than 4.0 in fringe USA, and larger than 5.7
outside the USA is also registered. This is now done by manually gathering information from web sites
providing worldwide earthquake reports.
The EQ-system generates database files that contain the longitudes and latitudes of each predicted
earthquake area. These coordinates are manually compared with several web sites (Internet sources,
page 51, for a list of the web sites).
This is an example of information from a website that is used for comparison. It shows resent quakes in
the California district, with a magnitude of, or higher than, 3.0.
Figure 6: Example of information used for comparison.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 11 -
EQ-Forecast – Final report
1.1 Description of the technical equipment
We do not have access to the equipment used for the actual earthquake forecasting, but we will create a
program solution that is adjusted to this system. The nature of the technical equipment that locates the
earthquakes is confidential, and due to this we do not know much about the actual hardware. Nor do we
have access to the software that works the equipment.
What we do know, is that the technical equipment finds the longitudes and latitudes of the predicted
earthquake areas, and the methods used to find this is based on analysis of electromagnetic signals.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 12 -
EQ-Forecast – Final report
Reasons for upgrading
Time Research wanted to automate the forecast report process. Selected web sites had to be read
automatically, instead of having to manually compare the data. The information from the web sites had
to be compared with the database files. The results from this comparison then had to be presented on a
continuously updatable research website, where the data were presented, similar to the current written
report, only with daily updated information.
A complete web solution, with a strong focus on automation, was needed. The web solution made the
information more accessible, and it will help researchers save time.
Without this critical fix, the whole EQ-project would suffer from the fact that the researchers working
on it would have to dedicate much of their time to manually compare data.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 13 -
EQ-Forecast – Final report
Performance specification
This is a performance specification, translating the operational requirements into more technical
language that tells us, the developers, what is considered an acceptable product, and how we will
determine if the end product is acceptable.
1.2 Functional requirements
Function 1:
Extracting information from the database files.
A program that extracts longitudes and latitudes from the database files,
generated by Time Research’s EQ-system, and puts it into XML files.
Function 2:
Extracting information from selected web sites.
A program for extracting information from a selected group of web sites. The
data will be stored in XML files, similar to the data from the database files.
The full list of web sites used can be found at Internet sources, page 52.
Function 3:
Comparing the database files and the web site information.
Comparison of the information from the database files with the information
from the web sites. The point of this is to determine how near the forecast was
to the actual quake. We will do this by comparing the data, particularly the
longitudes and latitudes, from the two XML files created in Function 1 and 2.
Function 4:
Automatically generated reports online.
A web site holding continuously updated information. The information will be
available as either a downloadable document, or as presented on the web site.
It is also preferable to have printer friendly functionality.
Function 5:
An easy-to-read web site.
The online reports should focus on user-friendliness, and the earthquake
forecast results should be split up, and structured in such a way, that it is easy
to find.
Parts of the web site should require the user to log in.
Function 6:
An easy to use login system.
The login system should have two account types. Firstly the standard user
account, for viewing the forecasts for quakes that have not yet occurred.
Secondly, an administrative account with access to a special menu for creating
new accounts, deleting accounts and viewing user information etc.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 14 -
EQ-Forecast – Final report
1.3 Technical requirements
The technical requirements concern the server system and the web hosting company. For example how
and where the web and database files should be hosted, and what programming languages the server
must support.
This is an overview of the technical requirements:
Linux support:
The whole system is based on running on a UNIX system computer. At its present time, the system
is running on a Debian GNU/Linux 2.4 (‘woody’). We recommend using this version, but all versions of
Linux after this one works. Debian Linux can be found here http://www.debian.org/releases/
PHP 5 support:
The login system is programmed in PHP 5, a relatively new programming language. It is required that
the web server supports PHP 5.
PHP 5 can be downloaded from http://www.php.net/downloads.php
Please refer to 1.22.1 Apache and PHP 5 installation on UNIX systems, page 56 in Appendix 1, for
installation instructions, and more information about PHP 5.
MySQL support:
The login system also uses MySQL to make the login secure. Almost all professional login systems use
this. MySQL requires that the web server runs Apache.
Apache support:
Apache can be downloaded from http://www.apache.org/dyn/closer.cgi, and is a free web server tool
Please refer to 1.22.1.1 Apache 1.3.x on UNIX systems, page 57 in Appendix 1, for installation
instructions, and more information about Apache and MySQL
Python support:
The web server must have support for programs written in Python.
Python can be downloaded from http://www.python.org/download/
Please refer to 1.22.2 Installing Python, page 62 in Appendix 1, for installation instructions, and more
information about Python.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 15 -
EQ-Forecast – Final report
System specification
This is an overview of our system solution. It contains several different programs. We will look more
closely at the system in this section.
1.4 About the longitude and latitude calculations
The thing that was the most challenging part in this project was how we were going to solve the issue
with the longitude, latitude and distance calculations.
When looking at a map, see Figure 7, page 17, latitude lines run horizontally. Latitude lines are also
known as parallels, and they are an equal distance from each other. Each degree of latitude is
approximately 69 miles (111 km) apart; there is a variation due to the fact that the earth is not a perfect
sphere, but an oblate ellipsoid (slightly egg-shaped). Degrees of latitude are numbered from 0° to 90°
north and south. Zero degrees are the equator, the imaginary line which divides our planet into the
northern and southern hemispheres. 90° north is the North Pole and 90° south is the South Pole.
The vertical longitude lines are also known as meridians. They converge at the poles and are widest at
the equator (about 69 miles or 111 km apart). Zero degrees longitude is located at Greenwich, England.
The degrees continue 180° east and 180° west where they meet and form the International Date Line in
the Pacific Ocean.
To precisely locate points on the earth's surface, degrees of longitudes and latitudes have been divided
into minutes (') and seconds ("). There are 60 minutes in each degree. Each minute is divided into 60
seconds. Seconds can be further divided into tenths, hundredths, or even thousandths. For example, the
U.S. Capitol is located at 38° 53' 23" N, 77° 00' 27" W. 38 degrees, 53 minutes, and 23 seconds north of
the equator and 77 degrees, no minutes and 27 seconds west of the meridian passing through Greenwich,
England. There are a number of formats for the coordinates for the longitude and latitude. The one we
use in our system is the format, longitude: -114.8228, latitude: 32.8885. This is called the decimal
format.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 16 -
EQ-Forecast – Final report
Figure 7: Latitudes and longitudes.
When all that is known, we now have to take all of that into account, when constructing the code.
Because of the ellipsoid-problem, we had to make a distance algorithm that was accurate enough, and
took the ellipsoid-problem into account.
Please see Program part 3, page 29, for more information about the distance algorithm.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 17 -
EQ-Forecast – Final report
1.5 System overview
This diagram shows our system solution. This is a rough overview of how the different parts of the
system interact. We have divided the system process into 5 stages.
Figure 8: The system overview.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 18 -
EQ-Forecast – Final report
1.5.1 Stage 1
Figure 9: System overview: Stage 1
Firstly, in stage 1, there are two main programs:
1. A program extracts the forecast information from the data base files. This functionality is a part
of “Program part 1”. For more information about how exactly this works, please see chapter
8.3.1, Program part 1, page 22.
2. Another program extracts information from different web sites. The web sites contain earthquake
report data, from earthquakes that have already occurred.
For a full listing of the web sites use, please see Internet sources, page 51.
The website extraction program is a part of Program part 2. Please see Program part 2, page24.
1.5.2 Stage 2
Figure 10: System overview: Stage 2.
In stage 2, the information extracted from the programs in stage 1 is used to generate two separate XML
files. One XML file contains all the database file forecast data, and the other, all the web site earthquake
report data. This is done in Program part 1 and 2.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 19 -
EQ-Forecast – Final report
1.5.3 Stage 3
Figure 11: System overview: Stage 3.
In stage 3 is where the comparing takes place. The data from each of the XML files from the previous
stage are compared using the program part 3 program.
Mainly, the latitudes and longitudes are compared, and based on their values, calculations are made.
Please see Program part 3, page 29.
1.5.4 Stage 4
Figure 12: System overview: Stage 4.
Stage 4 of our system also happens in Program part 3. After having compared the data from the XML
files, and found the calculated values, the program displays the results on the web site.
The web site contains several different sections. Some require the user to log in.
For more information about the login system, please see The login system, page 39.
1.5.5 Stage 5
Figure 13: System overview: Stage 5.
The final stage in the system overview is the creation of a PDF file. The PDF is made in a separate
program that uses the information from the XML files. This file is downloadable from the web site, and
features all the forecast results displayed on the website.
For more information about the PDF file, please see The PDF file, page 38.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 20 -
EQ-Forecast – Final report
1.6 The program system
There are three main programs. Together they find the difference in miles, from an EQ-forecast, to its
corresponding quake. This is the basic functionality of the three programs:

Program part 1: Extracts dates, magnitudes, longitudes and latitudes from the database files, and
puts it into an XML file.

Program part 2: Extracts dates, magnitudes, longitudes and latitudes from web sites, and puts it
into an XML file.

Program part 3: Compares the dates, magnitudes, longitudes and latitudes from both XML files
and calculates the accuracy of the forecasts.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 21 -
EQ-Forecast – Final report
1.6.1 Program part 1
Figure 14: Program part 1.
Program part 1 consists mainly of a python program that extracts information from the database files
and puts it into an XML file. The database files must all be located within the same folder, on the web
server. The program takes all the information from each of the database files, and sorts them by date in
the XML file. Please look at Figure 3, page 6, for a detailed look at a database file.
This is how the XML file with data from the database files look like:
Figure 15: A sample from the XML file.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 22 -
EQ-Forecast – Final report
As you can see from Figure 15, at the preceding page, the XML basically holds this information:
-
date
magnitude
latitude
longitude
place
<element date=”when the quake is forecasted to occur”>
<mag>the magnitude of the quake</mag>
<latitude>the latitude of the quake</latitude>
<longitude>the longitude of the quake</longitude>
<place>the location of the quake</place>
</element>
The reason we use XML like this, is that it makes comparing the data (Program part 3) easier, and it’s
also easier to read through the raw XML file, for debugging, than reading through each database file.
Here’s how the Program part 1 is structured:
1.
Program part 1 - Structuring the database files
1.1 Reads all the database files
Reads the base files given by the EQ-System.
1.2 Extracts the data
Function that collects the longitudes, latitudes, magnitudes
and places from the database files.
1.3 Generates an XML file
Function that creates an XML file of the data collected.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 23 -
EQ-Forecast – Final report
1.6.2 Program part 2
Figure 16: Program part 2.
Once all the information is put into the XML file, program part 1’s job is at its end. The next step is
extracting the information from the web.
Program part 2 consists of several programs for extracting dates, magnitudes, longitudes, latitudes and
quake-locations, from a series of renowned earthquake report sites. The information extracted concerns
quakes that have already occurred, and we use this information for getting the accuracy of the forecasts
from the database files.
For a full list of the web sites that we extract quake-information from, please look at Internet sources,
page 51.
The reason there are several programs extracting information form the web sites, is the fact that the web
sites are structured radically different. Additionally, some web sites does not use RSS feed. We have to
use two different extraction techniques, one meant for the sites where the XML is available, and one
where it isn’t.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 24 -
EQ-Forecast – Final report
These are the techniques for RSS, and for non-RSS web sites:
For RSS-feed-supported web sites:
The sites that have available XML are much easier to extract information from. Because their
information is already structured, we don’t need as much code to extract it to our own XML.
Although the programs vary slightly, based on which web site they extract from, this is the basic
technique for extracting from RSS-feed supported XML-friendly web sites:
We use a python script that reads the URL given, reads the site and stores it locally in a folder we
specify. In this example the URL is: http://earthquake.usgs.gov/recenteqsww/catalogs/eqs7dayM2.5.xml. This is one of the sites that we collect our information from. In this case we store it in the
folder “xml”. Furthermore the given URL over, is the only web site that provides an XML document
over its earthquake data.
Figure 17: Usgov.com.
In Figure 17, you can see usgov.com earthquake statistics page. It looks like a usual HTML site, but if
you look at Figure 18, you’ll see the difference, its XML.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 25 -
EQ-Forecast – Final report
Figure 18: usgov XML.
At this screenshot you can see usgov.com’s XML, due to its RSS support.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 26 -
EQ-Forecast – Final report
Here’s how the program part for the RSS-feed-supported web sites is structured:
2.
Program part 2 - RSS-feed-supported web sites
2.1
Reading the URL:
A function that reads the URL that has been given.
2.2
Reads the XML page
Reads the entire XML page.
2.3
Stores the XML page
Stores the XML page in a folder specified by the user.
For non-RSS web sites:
The non-RSS web sites do not offer us a structure that is friendly in regards to extracting information
from it. We have to look at the source code of the web site, and adjust our programs so that it will read
specific characters in the code, extracting the information that way. This is a little more complex than
what we do with sites that have XML available.
This is basically how we extract from web sites that do not offer XML documents:
We have to collect the data from standard HTML sites. What we do first is the same method used for the
sites that offer XML documents. We use a script that reads the URL we put in. Then it reads the entire
page and stores it in a folder we specify. In this case we store all our HTML pages in the folder “sites”.
After that is done for all the pages those we need to collect data from, we need to look at the code for
each individual site.
We have to find specific characters in the code that we can use to extract the data we need. We have to
find something in the code that never changes. An example from one of our scripts is that we use a line
in the text called “/recenteqsUS/Maps”. Every line in the HTML code that holds the information about
magnitude, longitude, latitude and place has this text in its line. So now the script collects each of these
lines from the HTML code and strips of unnecessary code that we don’t need.
After that is done the script puts the collected data in an XML document. The explanation above is just
one example on how we extract and transform the data to a XML document. For each site that we collect
data from we use the same method, but each site looks different, so for every site that we collect data
from we look for different characters that we can use.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 27 -
EQ-Forecast – Final report
Here’s how the program part for the non-RSS-web sites is structured:
2.
Program part 2 - non-RSS web sites
2.1
Reads the URL
A function that reads the URL given by the user.
2.2
Reads and stores the html page
Function for reading and storing HTML pages.
2.3
Web site XML extraction
Extracts longitudes, latitudes and dates of the
occurred quakes from the HTML pages.
2.4
Generates an XML file
Function that creates an XML file of the data
collected.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 28 -
EQ-Forecast – Final report
1.6.3 Program part 3
Figure 19: Program part 3.
The third program part consists of programs comparing the two XML files, so we can display the
accuracy of the Electro Quake forecasts.
The programs fetch the dates from today’s occurred quakes from the Program part 2 XML, and
compare them with the occurred quakes from the Program part 1 XML.
If the dates match, the longitudes and latitudes of each quake are compared. If the occurred quake is
within 21 mile radius of a forecast, the forecasted quake and that occurred quake is considered a success,
and the accuracy of the forecast (amount of miles, location etc) is put into a table on the website.
The quake does not always have to occur on exactly the date given, to be considered a success. A quake
that occurs any time within plus or minus three days is considered a success. This is what Time
Research calls the “shadow”. We analyze the earthquakes by having a continuous “shadow” of + and – 3
days.
The way we find how many miles each forecasted quake is from an occurred quake, is through our
longitude and latitude distancing algorithm. The algorithm works like this:
The distance function:
function distance($lat1, $lon1, $lat2, $lon2, $unit) {
$theta = $lon1 - $lon2;
$dist = sin(deg2rad($lat1)) * sin(deg2rad($lat2)) + cos(deg2rad($lat1))
* cos(deg2rad($lat2)) * cos(deg2rad($theta));
$dist = acos($dist);
$dist = rad2deg($dist);
$miles = $dist * 60 * 1.1515;
$unit = strtoupper($unit);
}
lat1, lon1 = Latitude and Longitude of point 1 (in decimal degrees). lat2, lon2 = Latitude and Longitude
of point 2 (also in decimal degrees).
http://prosjektexpo.hiof.no/expo05/h05d02/
- 29 -
EQ-Forecast – Final report
As you can see, the distance is calculated through sinus and cosine degrees and radians. Our program
uses the commonly accepted method of distance calculation. Through our testing of the algorithm we
have found it has an error margin of approximately 0 – 1%. Please see Program part 3, page 69 in
Appendix 1, for more information about the testing of the algorithm.
Essentially, here’s how Program part 3 is structured:
3.
Program part 3 – distance calculator
3.1
The distance function:
function distance($lat1, $lon1, $lat2, $lon2, $unit){}
The method of calculating the distance in miles.
3.2
Database-file XML extraction
Extracts longitudes, latitudes and dates of the forecasted
quakes from the database-XML file. Then puts the values
into tables.
3.3
Website XML extraction
Extracts longitudes, latitudes and dates of the occurred
quakes from the web site XML files.
3.4
Comparing the data
Compares the data from the database files and web sites
and finds various values. Like in which forecast area
the quake occurred, and whether or not the forecast for
each quake can be considered a success.
3.5
Printing
Prints the data to tables on the web site, and a .doc’
downloadable document.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 30 -
EQ-Forecast – Final report
The EQ website
This section describes what can be found on the EQ research web site.
The EQ web site is the end product of this project, and contains several sections. What follows is an
overview of the special sections and functions available on the EQ research web site.
1.
2.
3.
4.
5.
6.
7.
8.
Local forecast results
Semi-fringe forecast results
Fringe forecast results
Worldwide earthquake report
The print page
The login system
New forecasts (for the normal and admin user)
Admin pages
For easy testing purposes, the complete web-solution is available at http://dio.hiof.no/~eq.
Admin login:
username: user1
login: 12
Normal user login:
username: user2
login: 2xQWpk3
http://prosjektexpo.hiof.no/expo05/h05d02/
- 31 -
EQ-Forecast – Final report
1.7 Local forecast results
The local forecast results section contains the results from the forecasts which were forecasted to occur
last week. The forecast results are displayed in a table, split in various parts, depicting the accuracy of
the forecasts.
This is an example of how the table on the web site is structured. Please note that these values are
fictional. They are only meant as an example of how the table looks at the web site.
Figure 20: Local forecast results example.
Explanation of the table values:
Date: The date the quake occurred.
Mag: The magnitude of the quake.
Actual location: Where the quake actually occurred.
Nearest forecast area: The area where the forecasted quake was forecasted to occur. This area is
always the nearest forecasted area to where the quake actually occurred.
0-20 miles: If the quake occurred within 20 miles of the forecast, the amount of miles the quake was
from the forecast is displayed here.
21-30 miles: Similarly, if the quake occurred within 21-30 miles of the forecast, the amount of miles the
quake was from the forecast is displayed here.
31-99 miles: Finally, if the quake was occurred within 31-99 miles away from the forecast, the amount
of miles is displayed here.
If you look at the last results in this example, you can see there are several hits for “San Juan Bautista”.
Some times there will be several quakes following each other in one area. The system will print out each
separate quake. The reason we know they are separate quakes is that the web XML file will only contain
separate quake-values, since we recreate the XML files every day.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 32 -
EQ-Forecast – Final report
1.8 Semi-fringe forecast results
The semi-fringe forecast results sections contain the results of last week semi-fringe forecasts. The
results are put into a table, where one can easily examine the accuracy of the measurements.
This is an example of how the table on the website is structured. Please note that these values are
fictional, they are only meant as an example of how the table looks on the website.
Figure 21: Semi-fringe forecast results example.
Explanation of the table values:
Date: The date of when the quake occurred.
Mag: The magnitude of the quake.
Actual location: Where the quake actually occurred.
Nearest forecast area: The area where the forecasted quake was forecasted to occur. This area is
always the nearest forecasted area to where the quake actually occurred.
0-30 miles: If the quake occurred within 30 miles of the forecast, the amount of miles the quake was
from the forecast is displayed here.
31-50 miles: Similarly, if the quake occurred within 31-50 miles of the forecast, the amount of miles the
quake was from the forecast is displayed here.
51-99 miles: Finally, if the quake was occurred within 51-99 miles away from the forecast, the amount
of miles is displayed here.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 33 -
EQ-Forecast – Final report
1.9 True fringe forecast results
The true fringe forecast results sections contain the results of last week true fringe forecasts. The results
are put into a table, where one can easily examine the accuracy of the measurements.
This is an example of how the table on the website is structured. Please note that these values are
fictional, they are only meant as an example of how the table looks on the website.
Figure 22: True fringe forecast results example.
Explanation of the table values:
Date: The date of when the quake occurred.
Mag: The magnitude of the quake.
Actual location: Where the quake actually occurred.
Nearest forecast area: The area where the forecasted quake was forecasted to occur. This area is
always the nearest forecasted area to where the quake actually occurred.
0-30 miles: If the quake occurred within 30 miles of the forecast, the amount of miles the quake was
from the forecast is displayed here.
31-50 miles: Similarly, if the quake occurred within 31-50 miles of the forecast, the amount of miles the
quake was from the forecast is displayed here.
51-99 miles: Finally, if the quake was occurred within 51-99 miles away from the forecast, the amount
of miles is displayed here.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 34 -
EQ-Forecast – Final report
1.10 World wide earthquake report
The worldwide report displays recent earthquakes that have occurred from around the world. Only larger
quakes are displayed.
This is an example of how the worldwide report table looks on the website.
Figure 23: Worldwide report example.
Explanation of the table values:
Date: The date when the quake occurred.
Mag: The magnitude of the quake.
Location: Where the quake occurred.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 35 -
EQ-Forecast – Final report
1.11 The print page
The print page features a printer friendly page, where every table is put together for easy printing. There
is also a downloadable PDF document available. The PDF is automatically updated, and you will always
be able to download the very latest forecast results.
Figure 24: The print page.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 36 -
EQ-Forecast – Final report
1.11.1
The printer friendly pages
Each of the forecast areas has their own printer friendly page, which can be found in the print section of
the web site. Here one can also open a printer friendly worldwide earthquake report.
The printer friendly pages pop up in a smaller window. In this new window there is print functionality,
and the data is displayed printer friendly. In this example we see the printer friendly local forecast pop
up.
Figure 25: Printer friendly local forecast.
If you click the printer button, you will open the windows print dialogue. Here you can alter the number
of pages you wish to print etc.
Figure 26: Windows print dialogue.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 37 -
EQ-Forecast – Final report
1.11.2
The PDF file
The PDF file contains all the recent earthquake forecast data, from all the different forecast areas, sorted
by area. The PDF file can be found on the print page.
This is how the data presented in the PDF file looks. This is an example of how the local forecast results
data looks. The PDF also contains semi-fringe and true-fringe data.
Figure 27: PDF file forecast data.
The PDF file is automatically generated from the latest research data, using the program
forecastdata.php.
The code which generates the PDF file uses the library fpdf.php. This is an open source library for
making PDF files. All the necessary files are included in the ElectroQuake forecast system CD-ROM,
but it may also be downloaded from http://www.fpdf.org/.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 38 -
EQ-Forecast – Final report
1.12 The login system
I you click ‘login’ on the EQ research web site; you are brought to the login page. If you log in here, you
will get new options depending on your user level.
There are two user levels: The normal user and the administrative user.
The normal user:
In addition to the normal sections of the web site, the normal user, when logged in, will have access to
the forecasts for the next few days. That is, forecasts which has not yet occurred. This new option will
appear on a new menu bar under the normal menu bar, once logged in.
Figure 28: The menu when not logged in.
Figure 29: The normal user menu, when logged in.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 39 -
EQ-Forecast – Final report
The administrative user:
In addition to the normal sections, and the normal user sections, the administrative user will also be able
to create new accounts and delete old ones. The administrative user can also access a list of all users,
with their names and e-mails.
Figure 30: The administrative user menu, when logged in.
The login system uses PHP 5 and MySQL technology. The login system itself, written in php 5,
communicates with a MySQL database. For more information about PHP 5, and MySQL/Apache, see
User Manual, page 56.
The login program system consists mainly of four files.
-
login.php
index.php
functions.php
userMenu.php
login.php:
The login.php file is the actual page where you login. Functions from functions.php and index.php are
used to access the MySQL database.
In login.php there is a form, in which the user inputs his username and password. When the user logs in,
“value” is set to “1”.
Figure 31: Login screen.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 40 -
EQ-Forecast – Final report
index.php:
The index file contains the code which creates the user objects and sessions. This is basically how the
login process works:
1.
2.
3.
4.
5.
6.
7.
Starts a session
Create objects
Sets up MySQL user access
Checks if the user is logged in
Grants status depending on user type
Continuously checks the user type and login status
Saves and updates.
functions.php:
The functions.php file contains two functions.
-
generatePasswd: Generates a password with random characters.
userExistance: Checks if a user exists.
The generatePasswd function makes sure the generated password contains different types of characters;
2 uppercase letters, 2 numbers and 3 lowercase letters. This is done to ensure that the password is
secure. MD5 encryption is used in the user database, where the passwords are stored.
The userExistance function is used in the index.php to check whether a user really exists in the database.
userMenu.php:
This file contains code that creates the special normal user, admin user and menu bars, when logged in.
The user level determines the type of menu that is loaded. The user type is fetched from the database
with MySQL in index.php.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 41 -
EQ-Forecast – Final report
1.12.1
New forecasts
If a user logs into the web system he will have access to the new forecasts section. Both the
administrative and normal users have access to this section.
Figure 32: New forecast section.
The new forecast page contains the forecast data for quakes that haven’t occurred yet. In the example
above, only one such forecast is present.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 42 -
EQ-Forecast – Final report
1.12.2
Admin pages
The administrative user has access to two sections which the other users don’t.
1. User management
2. The user list
1.12.2.1 User management
In the user management section the admin user may add new users, or delete old ones.
Figure 33: User management.
Adding users:
To add a user you must make sure the “Add user” radio button is selected. Then type in the username,
first name, surname and e-mail. After you’ve typed in the personal information, select the radio button
which describes which user type you want the new user to be. Normal user or admin. Check the confirm,
and submit to submit the changes you’ve made into the user database. A e-mail will be sent to the new
user’s mail containing the username and password.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 43 -
EQ-Forecast – Final report
How this is done in the code:
In userManagement.php the information you enter on the web site is submitted via a form. The
information is handled in index.php. Look for “User Management Script”.
This happens next:
if($_POST['userMng']){
if($userLevel == 1){ // If user is admin continue from here.
if($_POST['confirm']){
if($_POST['action'] == "addUser"){
The userManaging script in code.php is of course much larger, but if you look at these first lines you
can see how it basically works.
If the user posts the information in userManagement.php’s form, the code triggers. The code checks if
the admin who is creating the user really is an administrative user. If this is confirmed, and the confirm
radio button was selected, the code goes on to add the user.
Deleting users:
To delete a user, the admin must select the “Delete user” radio button, then select the user he/she wishes
to remove from the drop down menu. To delete, check the confirm checkbox, and click submit.
How this is done in the code:
The submitted information from the form in userManagement.php for deleting users is handled in
index.php.
else if($_POST['action'] == "delUser"){
if(mysql_query("delete from users where
username='".$_POST['editUserID']."'", $mysqlAccess)){
echo "user is deleted";
If the admin select the “Delete user” radio button, the “else if …” is invoked. The program simply
deletes the users from the user database where the username matches the user specified.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 44 -
EQ-Forecast – Final report
1.12.2.2 The user list
The user list is another section, which only the admin can access. The user list section is basically a list
of all the registered users on the EQ-system.
Here can administrators fetch users e-mails, usernames and real names. This is useful if, for some
reason, an administrator needs to contact a user.
Figure 34: User list.
In the code, this is done with an SQL query to the user database.
$result = mysql_query("select sname, fname, username, email from users order by sname asc",
$mysqlAccess);
while($row = mysql_fetch_row($result)){
$i = 0;
$tmp=false;
foreach($row as $field){
$tmp[$i++] = $field;
}
$sname = $tmp[0];
$fname = $tmp[1];
$uname = $tmp[2];
$eMail = $tmp[3];
http://prosjektexpo.hiof.no/expo05/h05d02/
- 45 -
EQ-Forecast – Final report
1.13 Automatic updating
We use a function that keeps the system up to date. By that we mean we have a service that runs the
programs that collects and makes the XML documents. This service is called crontab. Crontab is a
function in Linux. It is a service, and can be programmed to run at any time. In our system crontab is
scheduled to run all of the programs that collect XML and HTML web documents. It also runs all the
programs that convert the HTML pages to XML documents, and the program that reads and generates
an XML document for the database files.
Crontab is a function that is located in every UNIX distribution, so it doesn’t need additional install
packages. How the system works now is that the files that is automatically updated is updated once a
day, and it should also be that way in the future. Because that is how the program is built up now. The
crontab runs the files that are put in its list every day at 06.30 AM. The reason we need to run the files
every day, is that the XML files from the web needs to be updated every day.
Crontab is normally found under /etc/cron.daily/, here in the folder the root user of the system needs to
create a text file. The contents of the text file should be the specified path to the script that needs to be
run daily. If you look at Figure 35, this is how the crontab file should look like if the system is going to
work properly.
Figure 35: Crontab file.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 46 -
EQ-Forecast – Final report
1.14 Automatic deletion of old files
The automatic deletion of old files is a small program that deletes files specified by the user. In the
system today the program deletes XML files when they have become over 7 days old. The days can be
adjusted by the user.
This program is needed because a new XML file is generated each day, with a different date for each
file. So without this program the amount of data would be very large in a very short time, because the
XML file contains large amounts of data, and that would cause storage problems.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 47 -
EQ-Forecast – Final report
Project scheme
Here you can see how the work was distributed amongst the project members, and how we planned
ahead during the pre-project period.
1.15 Milestones
See the Gantt-chart in the Appendix 1, page 71 and 72.
1.16 The responsibility distribution
The responsibility distribution
Project title: EQ-Forecast
Members:
Task/Activity
Preproject report
1
Develop EQ homepage
2
2.1 Collect data from data base files
2.2 Collect data from web sites
2.3 Compare the data
2.4 Generate tables from xml to web
2.5 Make the web page printable
2.6 Develop login system
2.7 Debuging of the system
Systems development report
3
Final report
4
Expo
5
5.1 Make presentation to EXPO
5.2 Presentation at EXPO
Espen Braaten
Dato:14.03.05 - 03.06.05
Joakim Eilertsen Jørgen Lie Pettersen
P
P
RP
RP
RP
P
P
P
P
RP
P
P
P
P
RP
RP
RP
P
P
P
P
P
P
P
P
P
RP
P
RP
RP
RP
RP
P
RP
P
RP
Figure 36: The division of work.
Description of the codes:
R - Responsible
P - Performed by
http://prosjektexpo.hiof.no/expo05/h05d02/
- 48 -
EQ-Forecast – Final report
Conclusions
We feel our work on the EQ system, and the outcome of the project, is a great boon to the continuing
research of earthquakes at Time Research. With this automated system, they needn’t spend such
amounts of time gathering and comparing research data. Researchers may simply log on to the EQ
research web site and get instant access to all the new forecasts and forecast results.
1.17 Beyond the project – potential improvements
This section describes what could be done to improve the efficiency of the EQ program system, if
someone were to take this project further. Some improvements could be made.
If you look at the code that converts HTML pages to XML documents, Program part 2, page 24, this
code can be made more effective. We have not had the time to improve the code in every way. The code
can be adjusted so it can handle more errors, and if the specified HTML pages that we collect data from
changes form the status that there in today, the scripts also needs to be changed. The thing is that the
code we use in order to collect data is build up in a way that we look for specific characters in the
HTML source page that never change. So if the HTML pages change, new code has to be implemented.
The second improvement that could be done would to include an automatically updated map of the
forecast areas. The map could show where and when earthquakes occurred.
Another improvement is the hit percent for quakes in the local forecast table. The hit percent is a number
which holds the hit count for every quake that’s in for example the 0-20 miles column in the local
forecast page. This would be a pointer to see how well the EQ-forecast system worked. This is a
potential improvement that could be implemented.
Some improvements in the login system can also be made. The system today only allows the user admin
to add new users. This means that a potential improvement could be that a user signup page could be
made. Also if some information about the user should change, for example their email address, only the
admin can change this. So an improvement would be that a normal user can change there personal
information, and change passwords themselves.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 49 -
EQ-Forecast – Final report
Abbreviations
Abbreviation
Stands for
CGI
Common Gateway Interface
A technology used in web servers.
MD5
Message-Digest algorithm 5
A widely-used cryptographic hash
function with a 128-bit hash value.
DLL
Dynamic Link Library
A Microsoft Windows binary application
library file format.
URL
Uniform Resource Locator
A standardized address for resources on
the Internet.
RSS
Rich Site Summary
A technique for giving users access to
their XML files.
ISAPI
Internet Service Application
Programming Interface
Microsoft's collection of Windows-based
network services.
HTML
HyperText Markup Language
A mark up language designed for the
creation of web pages and other
information viewable in a browser.
XML
Extensible Markup Language
Its primary purpose is to facilitate the
sharing of data across different systems
connected via the Internet.
PHP
Hypertext Preprocessor
A popular open-source programming
language used primarily for developing
server-side applications and dynamic web
content, and more recently, other
software.
PDF
Portable Document Format
Is a file format developed for representing
documents in a manner that is
independent of the original application
software, hardware, and operating system
used to create those documents.
http://prosjektexpo.hiof.no/expo05/h05d02/
Is
- 50 -
EQ-Forecast – Final report
Sources
1.18 Persons
These are persons that have contributed to the completion of this project:
-
Terje Samuelsen. Our project councilor.
Marsha Adams. Co-employer, has helped us a great deal, by providing much information.
Erling P. Strand. Co-employer, has provided us with information and support.
Ted M. Sørlie. Helped us with MySQL and PHP 5 support.
Jostein Bratlie. For help with the login system.
Jostein Skaar. Helped us with python support.
Kenneth F. Johansen. Provided PHP support.
John E. Simensen. For information around longitudes and latitudes.
Audun Vaaler. For help with XML handling.
Per-Olav Rusaas. For Linux assistance.
1.19 Internet sources
These are the web sites that we extract information from, for comparing with the database files:
-
http://earthquake.usgs.gov/recenteqsUS/Quakes/quakes_big.html
http://neic.usgs.gov/neis/bulletin/bulletin.html
http://earthquake.usgs.gov/recenteqsww/
http://www.geophys.washington.edu/SEIS/PNSN/HOOD/hoodrec_eqs.html
http://www.geophys.washington.edu/SEIS/PNSN/RAINIER/rainrec_eqs.html
http://www.ess.washington.edu/SEIS/PNSN/BAKER/bakerrec_eqs.html
http://www.geophys.washington.edu/SEIS/PNSN/SISTERS/sistersrec_eqs.html
http://www.geophys.washington.edu/recenteqs/Maps/Mount_St._Helens.html
http://www.pgc.nrcan.gc.ca/seismo/recent/bc.50evt.list.html
These are other web sites that we used to complete this project:
-
http://www.w3schools.com/php/default.asp (PHP)
http://no.php.net/file (PHP)
http://nationalatlas.gov/natlas/Natlasstart.asp (Interactive map)
http://www.realestate3d.com/gps/latlong.htm (Lats and longs of US cities, for testing)
http://www.wcrl.ars.usda.gov/cec/java/lat-long.htm (Mile calculations)
http://prosjektexpo.hiof.no/expo05/h05d02/
- 51 -
EQ-Forecast – Final report
Picture references
Figure 1: Sample from an EQ written report. ............................................................................................. 6
Figure 2: The report system before this project. ......................................................................................... 8
Figure 3: An extraction from a database file. ............................................................................................. 9
Figure 4: An overview of the local area...................................................................................................... 9
Figure 5: An overview of the fringe. ........................................................................................................ 10
Figure 6: Example of information used for comparison. .......................................................................... 11
Figure 7: Latitudes and longitudes. ........................................................................................................... 17
Figure 8: The system overview. ................................................................................................................ 18
Figure 9: System overview: Stage 1 ......................................................................................................... 19
Figure 10: System overview: Stage 2. ...................................................................................................... 19
Figure 11: System overview: Stage 3. ...................................................................................................... 20
Figure 12: System overview: Stage 4. ...................................................................................................... 20
Figure 13: System overview: Stage 5. ...................................................................................................... 20
Figure 14: Program part 1. ........................................................................................................................ 22
Figure 15: A sample from the XML file. .................................................................................................. 22
Figure 16: Program part 2. ........................................................................................................................ 24
Figure 17: Usgov.com. .............................................................................................................................. 25
Figure 18: usgov XML.............................................................................................................................. 26
Figure 19: Program part 3. ........................................................................................................................ 29
Figure 20: Local forecast results example. ............................................................................................... 32
Figure 21: Semi-fringe forecast results example. ..................................................................................... 33
Figure 22: True fringe forecast results example. ...................................................................................... 34
Figure 23: Worldwide report example. ..................................................................................................... 35
Figure 24: The print page. ......................................................................................................................... 36
Figure 25: Printer friendly local forecast. ................................................................................................. 37
Figure 26: Windows print dialogue. ......................................................................................................... 37
Figure 27: PDF file forecast data. ............................................................................................................. 38
Figure 28: The menu when not logged in. ................................................................................................ 39
Figure 29: The normal user menu, when logged in. ................................................................................. 39
Figure 30: The administrative user menu, when logged in. ...................................................................... 40
Figure 31: Login screen. ........................................................................................................................... 40
Figure 32: New forecast section. .............................................................................................................. 42
Figure 33: User management. ................................................................................................................... 43
Figure 34: User list.................................................................................................................................... 45
Figure 35: Crontab file. ............................................................................................................................. 46
Figure 36: The division of work. .............................................................................................................. 48
http://prosjektexpo.hiof.no/expo05/h05d02/
- 52 -
EQ-Forecast – Final report
Appendix
Authors:
Joakim Eilertsen
Espen M. Braaten
Jørgen Lie Pettersen
http://prosjektexpo.hiof.no/expo05/h05d02/
- 53 -
EQ-Forecast – Final report
13
1.20 About the appendix
This appendix is a part of the EQ-Forecast project. Here you will find various enclosures to the Project
report.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 54 -
EQ-Forecast – Final report
1.21 Appendix index
15 APPENDIX ................................................................................................................ 53
15.1 ABOUT THE APPENDIX ................................................................................................ 54
15.2 APPENDIX INDEX ...................................................................................................... 55
15.3 USER MANUAL ........................................................................................................ 56
15.3.1
Apache and PHP 5 installation on UNIX systems ................................................ 56
15.3.1.1 Apache 1.3.x on UNIX systems .................................................................... 57
15.3.1.2 Installation Instructions (Apache Shared Module Version) for PHP: ................... 57
15.3.1.3 Installing PHP as a static object .................................................................... 59
15.3.1.4 Example commands for restarting Apache ..................................................... 60
15.3.2
Installing Python............................................................................................ 62
15.3.2.1 Platform variations ..................................................................................... 62
15.3.2.2 Splitting up the job ..................................................................................... 62
15.3.2.3 How building works .................................................................................... 63
15.3.2.4 How installation works ................................................................................ 63
15.3.2.5 Modifying Python’s search path .................................................................... 64
15.3.3
About the user database and MySQL ................................................................ 66
15.3.4
Changing the structure of the database file ....................................................... 67
15.4 DEBUG REPORT ....................................................................................................... 68
15.4.1
Program part 1 .............................................................................................. 68
15.4.2
Program part 2 .............................................................................................. 68
15.4.3
Program part 3 .............................................................................................. 69
15.4.4
EQ Forecast system CD-ROM and installation .................................................... 70
15.5 GANTT-CHART ......................................................................................................... 71
15.6 DETAILED MAP OF THE LOCAL FORECAST AREA .................................................................... 73
15.7 DETAILED MAP OF THE FRINGE AREAS .............................................................................. 74
15.8 APPENDIX PICTURE REFERENCES .................................................................................... 75
15.9 SOURCE CODE SEE APPENDIX 2 AND 3............................................................................. 76
http://prosjektexpo.hiof.no/expo05/h05d02/
- 55 -
EQ-Forecast – Final report
1.22 User Manual
1.22.1 Apache and PHP 5 installation on UNIX systems
This section will guide you through the general configuration and installation of PHP on UNIX systems.
There are several ways to install PHP for the UNIX platform, either with a compile and configure
process, or through various pre-packaged methods. This documentation is mainly focused around the
process of compiling and configuring PHP. Many UNIX like systems have some sort of package
installation system. This can assist in setting up a standard configuration, but if you need to have a
different set of features (such as a secure server, or a different database driver), you may need to build
PHP and/or your web server. If you are unfamiliar with building and compiling your own software, it is
worth checking to see whether somebody has already built a packaged version of PHP with the features
you need.
Prerequisite knowledge and software for compiling:






Basic Unix skills (being able to operate "make", and a C compiler)
An ANSI C compiler
flex: Version 2.5.4
bison: Version 1.28 (preferred), 1.35, or 1.75
A web server
Any module specific components (such as gd, PDF libs, etc.)
The initial PHP setup and configuration process is controlled by the use of the command line options of
the configure script. You could get a list of all available options along with short explanations running
./configure --help. Our manual documents the different options separately. You will find the core
options at http://uk.php.net/manual/en/configure.php. The different extension specific options are
described on the reference pages.
When PHP is configured, you are ready to build the module and/or executables. The command make
should take care of this.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 56 -
EQ-Forecast – Final report
1.22.1.1 Apache 1.3.x on UNIX systems
This section contains notes and hints specific to Apache installs of PHP on UNIX platforms.
You can select arguments to add to the configure on line 10 below, from the list of core configure
options at http://uk.php.net/manual/en/configure.php, and from extension specific options described at
the respective places in the manual. The version numbers have been omitted here, to ensure the
instructions are not incorrect. You will need to replace the 'xxx' here with the correct values from your
files.
1.22.1.2 Installation Instructions (Apache Shared Module Version) for PHP:
1.
2.
3.
4.
5.
6.
7.
8.
9.
gunzip apache_xxx.tar.gz
tar -xvf apache_xxx.tar
gunzip php-xxx.tar.gz
tar -xvf php-xxx.tar
cd apache_xxx
./configure --prefix=/www --enable-module=so
make
make install
cd ../php-xxx
10. Now, configure your PHP. This is where you customize your PHP
with various options, like which extensions will be enabled. Do a
./configure --help for a list of available options. In our example
we'll do a simple configure with Apache 1 and MySQL support. Your
path to apxs may differ from our example.
./configure --with-mysql --with-apxs=/www/bin/apxs
11. make
12. make install
If you decide to change your configure options after installation,
you only need to repeat the last three steps. You only need to
restart apache for the new module to take effect. A recompile of
Apache is not needed.
Note that unless told otherwise, 'make install' will also install PEAR,
various PHP tools such as phpize, install the PHP CLI, and more.
13. Setup your php.ini file:
cp php.ini-dist /usr/local/lib/php.ini
You may edit your .ini file to set PHP options. If you prefer your
php.ini in another location, use --with-config-file-path=/some/path in
step 10.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 57 -
EQ-Forecast – Final report
If you instead choose php.ini-recommended, be certain to read the list
of changes within, as they affect how PHP behaves.
14. Edit your httpd.conf to load the PHP module. The path on the right hand
side of the LoadModule statement must point to the path of the PHP
module on your system. The make install from above may have already
added this for you, but be sure to check.
For PHP 4:
LoadModule php4_module libexec/libphp4.so
For PHP 5:
LoadModule php5_module libexec/libphp5.so
15. And in the AddModule section of httpd.conf, somewhere under the
ClearModuleList, add this:
For PHP 4:
AddModule mod_php4.c
For PHP 5:
AddModule mod_php5.c
16. Tell Apache to parse certain extensions as PHP. For example,
let's have Apache parse the .php extension as PHP. You could
have any extension(s) parse as PHP by simply adding more, with
each separated by a space. We'll add .phtml to demonstrate.
AddType application/x-httpd-php .php .phtml
It's also common to setup the .phps extension to show highlighted PHP
source, this can be done with:
AddType application/x-httpd-php-source .phps
17. Use your normal procedure for starting the Apache server. (You must
stop and restart the server, not just cause the server to reload by
using a HUP or USR1 signal.)
http://prosjektexpo.hiof.no/expo05/h05d02/
- 58 -
EQ-Forecast – Final report
1.22.1.3 Installing PHP as a static object
Instead of the above procedure, alternatively, you may install PHP as a static object.
1.
2.
3.
4.
gunzip -c apache_1.3.x.tar.gz | tar xf cd apache_1.3.x
./configure
cd ..
5.
6.
7.
8.
9.
gunzip -c php-4.x.y.tar.gz | tar xf cd php-4.x.y
./configure --with-mysql --with-apache=../apache_1.3.x
make
make install
10. cd ../apache_1.3.x
11. ./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a
(The above line is correct! Yes, we know libphp4.a does not exist at this
stage. It isn't supposed to. It will be created.)
12. make
(you should now have an httpd binary which you can copy to your Apache bin dir if
it is your first install then you need to "make install" as well)
13. cd ../php-4.x.y
14. cp php.ini-dist /usr/local/lib/php.ini
15. You can edit /usr/local/lib/php.ini file to set PHP options.
Edit your httpd.conf or srm.conf file and add:
AddType application/x-httpd-php .php
Depending on your Apache install and UNIX variant, there are many possible ways to stop and restart
the server. Below are some typical lines used in restarting the server, for different Apache/UNIX
installations. You should replace /path/to/ with the path to these applications on your systems.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 59 -
EQ-Forecast – Final report
1.22.1.4 Example commands for restarting Apache
1. Several Linux and SysV variants:
/etc/rc.d/init.d/httpd restart
2. Using apachectl scripts:
/path/to/apachectl stop
/path/to/apachectl start
3. httpdctl and httpsdctl (Using OpenSSL), similar to apachectl:
/path/to/httpsdctl stop
/path/to/httpsdctl start
4. Using mod_ssl, or another SSL server, you may want to manually
stop and start:
/path/to/apachectl stop
/path/to/apachectl startssl
The locations of the apachectl and http(s)dctl binaries often vary. If your system has locate or whereis or
which commands, these can assist you in finding your server control programs.
Different examples of compiling PHP for apache are as follows:
./configure --with-apxs --with-pgsql
This will create a libphp4.so shared library that is loaded into Apache using a LoadModule line in
Apache's httpd.conf file. The PostgreSQL support is embedded into this libphp4.so library.
./configure --with-apxs --with-pgsql=shared
This will create a libphp4.so shared library for Apache, but it will also create a pgsql.so shared library
that is loaded into PHP either by using the extension directive in php.ini file or by loading it explicitly in
a script using the dl() function, http://uk.php.net/manual/en/function.dl.php.
./configure --with-apache=/path/to/apache_source --with-pgsql
This will create a libmodphp4.a library, a mod_php4.c and some accompanying files and copy this into
the src/modules/php4 directory in the Apache source tree. Then you compile Apache using --activatemodule=src/modules/php4/libphp4.a and the Apache build system will create libphp4.a and link it
statically into the httpd binary. The PostgreSQL support is included directly into this httpd binary, so the
final result here is a single httpd binary that includes all of Apache and all of PHP.
./configure --with-apache=/path/to/apache_source --with-pgsql=shared
Same as before, except instead of including PostgreSQL support directly into the final httpd you will get
a pgsql.so shared library that you can load into PHP from either the php.ini file or directly using dl().
http://prosjektexpo.hiof.no/expo05/h05d02/
- 60 -
EQ-Forecast – Final report
When choosing to build PHP in different ways, you should consider the advantages and drawbacks of
each method. Building as a shared object will mean that you can compile apache separately, and don't
have to recompile everything as you add to, or change, PHP. Building PHP into apache (static method)
means that PHP will load and run faster.
Note: Apache's default httpd.conf currently ships with a section that looks like this:
User nobody
Group "#-1"
Unless you change that to "Group nogroup" or something like that ("Group daemon" is also very
common) PHP will not be able to open files.
Note: Make sure you specify the installed version of apxs when using --with-apxs=/path/to/apxs. You
must NOT use the apxs version that is in the apache sources, but the one that is actually installed on
your system.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 61 -
EQ-Forecast – Final report
1.22.2
Installing Python
Installing Python on a UNIX platform is usually done with one simple command:
python setup.py install
1.22.2.1 Platform variations
You should always run the setup command from the distribution root directory, i.e. the top-level
subdirectory that the module source distribution unpacks into. For example, if you've just downloaded a
module source distribution foo-1.0.tar.gz onto a UNIX system, the normal thing to do is:
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install
On Windows, you'd probably download foo-1.0.zip. If you downloaded the archive file to C:\Temp, then
it would unpack into C:\Temp\foo-1.0. You can use either an archive manipulator with a graphical user
interface (such as WinZip) or a command-line tool (such as unzip or pkunzip) to unpack the archive.
Then, open a command prompt window (``DOS box''), and run:
cd c:\Temp\foo-1.0
python setup.py install
1.22.2.2 Splitting up the job
Running setup.py install builds and installs all modules in one run. If you prefer to work incrementally,
especially useful if you want to customize the build process, or if things are going wrong, you can use
the setup script to do one thing at a time. This is particularly helpful when the build and install will be
done by different users, for example, you might want to build a module distribution and hand it off to a
system administrator for installation (or do it yourself, with super-user privileges).
For example, you can build everything in one step, and then install everything in a second step, by
invoking the setup script twice:
python setup.py build
python setup.py install
If you do this, you will notice that running the install command first runs the build command, which in
this case, quickly notices that it has nothing to do, since everything in the build directory is up to date.
You may not need this ability to break things down often if all you do is install modules downloaded off
the 'net, but it's very handy for more advanced tasks. If you get into distributing your own Python
modules and extensions, you'll run lots of individual Distutils commands on their own.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 62 -
EQ-Forecast – Final report
1.22.2.3 How building works
As implied above, the build command is responsible for putting the files to install into a build directory.
By default, this is build under the distribution root; if you're excessively concerned with speed, or want
to keep the source tree pristine, you can change the build directory with the build-base option. For
example:
python setup.py build --build-base=/tmp/pybuild/foo-1.0
The default layout for the build tree is as follows:
--- build/ --- lib/
or
--- build/ --- lib.<plat>/
temp.<plat>/
where <plat> expands to a brief description of the current OS/hardware platform and Python version.
The first form, with just a lib directory, is used for “pure module distributions'', that is, module
distributions that include only pure Python modules. If a module distribution contains any extensions
(modules written in C/C++), then the second form, with two <plat> directories, is used. In that case, the
temp.plat directory holds temporary files generated by the compile/link process that don't actually get
installed. In case, the lib (or lib.plat) directory contains all Python modules (pure Python and extensions)
that will be installed.
In the future, more directories will be added to handle Python scripts, documentation, binary
executables, and whatever else is needed to handle the job of installing Python modules and
applications.
1.22.2.4 How installation works
After the build command runs (whether you run it explicitly, or the install command does it for you), the
work of the install command is relatively simple: all it has to do is copy everything under build/lib (or
build/lib.plat) to your chosen installation directory.
If you don't choose an installation directory, i.e., if you just run setup.py, install then the install
command installs to the standard location for third-party Python modules. This location varies by
platform and by how you built/installed Python itself. On UNIX (and Mac OS X, which is also UNIXbased), it also depends on whether the module distribution being installed is pure Python or contains
extensions (“non-pure”):
Platform
Standard installation location
UNIX (pure) prefix/lib/python2.4/sitepackages
UNIX (non- execpure)
prefix/lib/python2.4/sitepackages
http://prosjektexpo.hiof.no/expo05/h05d02/
Default value
/usr/local/lib/python2.4/sitepackages
/usr/local/lib/python2.4/sitepackages
Notes
(1)
(1)
- 63 -
EQ-Forecast – Final report
Platform
Windows
Standard installation location
prefix
Default value
C:\Python
Notes
(2)
Notes:
(1)
Most Linux distributions include Python as a standard part of the system, so prefix and execprefix are usually both/usr on Linux. If you build Python yourself on Linux (or any UNIX-like
system), the default prefix and exec-prefix are /usr/local.
(2)
The default installation directory on Windows was C:\Program Files\Python under Python
1.6a1, 1.5.2, and earlier.
Prefix and exec-prefix stand for the directories that Python is installed to, and where it finds its libraries
at run-time. They are always the same under Windows, and very often the same under UNIX and Mac
OS X. You can find out what your Python installation uses for prefix and exec-prefix by running Python
in interactive mode and typing a few simple commands. Under UNIX, just type python at the shell
prompt. Under Windows, choose Start > Programs > Python 2.4 > Python (command line). Once the
interpreter is started, you type Python code at the prompt. For example, on my Linux system, I type the
three Python statements shown below, and get the output as shown, to find out my prefix and execprefix:
Python 2.4 (#26, Aug 7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'
1.22.2.5
Modifying Python’s search path
When the Python interpreter executes an import statement, it searches for both Python code and
extension modules along a search path. A default value for the path is configured into the Python binary
when the interpreter is built. You can determine the path by importing the sys module and printing the
value of sys.path.
$ python
Python 2.2 (#11, Oct 3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type ``help'', ``copyright'', ``credits'' or ``license'' for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
'/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages']
>>>
http://prosjektexpo.hiof.no/expo05/h05d02/
- 64 -
EQ-Forecast – Final report
The null string in sys.path represents the current working directory.
The expected convention for locally installed packages is to put them in the .../site-packages/ directory,
but you may want to install Python modules into some arbitrary directory. For example, your site may
have a convention of keeping all software related to the web server under /www. Add-on Python
modules might then belong in /www/python, and in order to import them, this directory must be added to
sys.path. There are several different ways to add the directory.
The most convenient way is to add a path configuration file to a directory that's already on Python's
path, usually to the .../site-packages/ directory. Path configuration files have an extension of .pth, and
each line must contain a single path that will be appended to sys.path. (Because the new paths are
appended to sys.path, modules in the added directories will not override standard modules. This means
you can't use this mechanism for installing fixed versions of standard modules.)
Paths can be absolute or relative, in which case they're relative to the directory containing the .pth file.
Any directories added to the search path will be scanned in turn for .pth files.
A slightly less convenient way is to edit the site.py file in Python's standard library, and modify sys.path.
site.py is automatically imported when the Python interpreter is executed, unless the -S switch is
supplied to suppress this behavior. So you could simply edit site.py and add two lines to it:
import sys
sys.path.append('/www/python/')
However, if you reinstall the same major version of Python (perhaps when upgrading from 2.2 to 2.2.2,
for example) site.py will be overwritten by the stock version. You'd have to remember that it was
modified and save a copy before doing the installation.
There are two environment variables that can modify sys.path. PYTHONHOME sets an alternate value
for the prefix of the Python installation. For example, if PYTHONHOME is set to "/www/python", the
search path will be set to ['', '/www/python/lib/python2.2/', '/www/python/lib/python2.3/plat-linux2', ...].
The PYTHONPATH variable can be set to a list of paths that will be added to the beginning of sys.path.
For example, if PYTHONPATH is set to "/www/python:/opt/py", the search path will begin with
['/www/python', '/opt/py']. (Note that directories must exist in order to be added to sys.path; the site
module removes paths that don't exist.)
Finally, sys.path is just a regular Python list, so any Python application can modify it by adding or
removing entries.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 65 -
EQ-Forecast – Final report
1.22.3
About the user database and MySQL
MySQL is needed for the user database. We took the choice to use mysql since this is the easiest and
simplest database you can use, and a key part of the Linux system. Mysql is a server database tool that
can be downloaded from http://www.mysql.com/downloads/mysql/4.0.html. The system today works as
follows; a database is created for the system. Then to manage the database we have chosen to use the
program PHPmyadmin tool. This is a tool for easy and effective configuration of the database.
PHPmyadmin can be downloaded from the following link
http://www.phpmyadmin.net/home_page/downloads.php.
Then we created a users table with these fields shown in Figure 37. These fields are necessary in order
for the login system to work.
The user database “users.frm” is available on the CD-ROM, under the folder “eqdb”. This file can be
imported into any database system tool. This must be done to make the solution work.
Appendix figure 1: Screenshot of the user database.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 66 -
EQ-Forecast – Final report
1.22.4 Changing the structure of the database file
As mentioned in the Debug Report, page 688, the database files must have a special structure to be read
correctly.
The structure of the database files nowadays:
Appendix figure 2: A part of a database file.
At line 51-56 in www\cgi-bin\file2xml.py, you’ll find:
Appendix figure 3: The code that finds the variable.
The numbers indicates where the variables are located in the line, and must be changed to correspond
with a new database file structure. “[10:18]” means from 10 and including 17.
At line 58-64, you’ll find:
Appendix figure 4: The code that ignores the first line.
This code omits the first line from the XML file. It takes the characters from 10 and including 17, from
the first line, and tries to put them into an integer variable. As you can see in Appendix figure 2, these
characters are “ETHOD AA”. They are letters, not numbers, and they can’t be parsed. The first line will
consequently be ignored. This code must therefore be deleted if the first line shall be emitted in the
XML file. If you want to edit more lines in the database file that shall be omitted, you just have to be
aware of that the characters from 10 and including 17 involve at least one letter.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 67 -
EQ-Forecast – Final report
1.23 Debug Report
In this debug report we first present what comes in and out, that is, what information is read into the
programs, and what the consequences of the input are. We also explain what would happen if the input
is faulty.
1.23.1 Program part 1
To see what program part 1 does, take a look at page 22.
In: The database file:
Appendix figure 5: A part of a database file.
Out: Puts the database values into an XML file, and sorts them.
Consequences:
 If the database files are made without the first line, the second line will be omitted from the
XML file, since we skip the fist line.

The lines must have this structure:
o 3 characters, 1 space, 5 characters, 1 space, 8 characters, 4 spaces, 5 characters, 1 space, 6
characters, 1 space, 5 characters, 1 space, 14 characters, 4 spaces, 3 characters, 1 space
and 1-30 characters. All characters can be replaced by spaces.
If the correct structure is ignored, the output will be wrong, dependent of how the new structure is. If
there is desirable to change the structure, there is no problem to change the source code, so that you will
get the correct output. See Changing the structure of the database file, page 67.
1.23.2 Program part 2
Web sites with RSS feed:
To see what Program part 2 does, take a look at page 24.
In: XML file from www.earthquake.usgov.com.
Out: Storing of the XML file.
Consequences: We won’t get any information if:
 the URL’s to the web sites change
http://prosjektexpo.hiof.no/expo05/h05d02/
- 68 -
EQ-Forecast – Final report
Web sites without RSS feed:
In: Information from different web sites.
Out: Storing of the selected information in an XML file.
Consequences: We won’t get any information if:
 the URL’s to the web sites change
 the tag names at the web sites change
 the word the program searches for changes
 the website contains characters that our codec doesn’t support
1.23.3 Program part 3
To see what Program part 3 does, take a look at page 29.
In: The database and website XML files.
Out: Tables on the website with information on the accuracy of Electro Quake. A downloadable .doc
document containing the same information.
Consequences: As long as the inputted XML files are correct, the output of Program part 3 will be
good. However, we have found that the distancing algorithm has a margin of error at approximately
0.1-1%.
We tested the distancing algorithm like this:
We chose two points on the US west coast, within the fringe area, and with a reasonably length of
distance between them. The points were South East in California (32° 53′ 51" N - 114° 49′ 17" W), and
North West in Washington (48° 13′ 01" N - 124° 32′ 25" W). We found their degrees of latitude and
longitude at http://www.nationalatlas.com. We then compared our function with a function at:
http://www.wcrl.ars.usda.gov/cec/java/lat-long.htm. The result; the margin of error, was about 0,1%.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 69 -
EQ-Forecast – Final report
1.23.4 EQ Forecast system CD-ROM and installation
All the files in the ElectroQuake forecast system will be available on a CD-ROM. You must copy the
files on the CD into you web server space.
The file config.php in the control catalog is very useful, because it provides you with a fast an easy
configuration, so it works on your server.
You still need to setup the user database file, and the server needs to have MySQL support. This is
easily done by loading the user database “users.frm” into your database managing tool. We use
phpadmin, which is included on the CD-ROM.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 70 -
EQ-Forecast – Final report
1.24 Gantt-chart
Appendix figure 6: The Gant-chart – part one.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 71 -
EQ-Forecast – Final report
Appendix figure 7: The Gant-chart – part two.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 72 -
EQ-Forecast – Final report
1.25 Detailed map of the local forecast area
Appendix figure 8: Map of the local forecast area.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 73 -
EQ-Forecast – Final report
1.26 Detailed map of the fringe areas
Appendix figure 9: Map of the fringe areas.
http://prosjektexpo.hiof.no/expo05/h05d02/
- 74 -
EQ-Forecast – Final report
1.27 Appendix picture references
Appendix figure 1: Screenshot of the user database. ................................................................................ 66
Appendix figure 2: A part of a database file. ............................................................................................ 67
Appendix figure 3: The code that finds the variable................................................................................. 67
Appendix figure 4: The code that ignores the first line. ........................................................................... 67
Appendix figure 5: A part of a database file. ............................................................................................ 68
Appendix figure 6: The Gant-chart – part one. ......................................................................................... 71
Appendix figure 7: The Gant-chart – part two.......................................................................................... 72
Appendix figure 8: Map of the local forecast area. .................................................................................. 73
Appendix figure 9: Map of the fringe areas. ............................................................................................. 74
http://prosjektexpo.hiof.no/expo05/h05d02/
- 75 -
EQ-Forecast – Final report
1.28 Source code
This is a list over all the source code. See Appendix 2 and 3 if you want to look at the code.
Index.php
Default.css
Localf.php
Login.php
Main.php
Newforecasts.php
Print.php
About.php
Aboutus.php
Printerfriendlylocal.php
Printerfriendlysfringe.php
Printerfriendlytfringe.php
Printerfriendlyworld.php
Semifringe.php
Truefringe.php
Userlist.php
Usermanagement.php
Worldwide.php
Forecastdata.php
Fpdf.php
Menu.php
Usermenu.php
Config.php
Functions.php
Createxmlhead.py
Del_xml_files.py
Fil2xml.py
File.py
Gethtml_britishCol.py
Gethtml_mtSites.py
Gethtml_usgov.py
Getxmlfile_usgov.py
Html2xml.py
Html2xml_3sisters.py
Html2xml_britishCol.py
Html2xml_mtBAKER.py
Html2xml_mtHOOD.py
Html2xml_mtRAINIER.py
Html2xml_mtStHelens.py
USWorldXml_to_xml.py
Top.php
Valid.php
Bottom.php
http://prosjektexpo.hiof.no/expo05/h05d02/
number of pages 6
number of pages 6
number of pages 7
number of pages 1
number of pages 1
number of pages 2
number of pages 2
number of pages 1
number of pages 1
number of pages 7
number of pages 7
number of pages 7
number of pages 1
number of pages 7
number of pages 7
number of pages 1
number of pages 3
number of pages 1
number of pages 12
number of pages 26
number of pages 1
number of pages 1
number of pages 1
number of pages 2
number of pages 2
number of pages 2
number of pages 3
number of pages 1
number of pages 1
number of pages 2
number of pages 2
number of pages 1
number of pages 3
number of pages 3
number of pages 3
number of pages 3
number of pages 3
number of pages 3
number of pages 3
number of pages 3
number of pages 1
number of pages 1
number of pages 1
- 76 -