Problems of the World Earthquake Database

of the U S Geological Survey

Many people may think that the World Earthquake Database of the National Earthquake Information Center (NEIC) of the U S Geological Survey (USGS) is perfect because USA is the most developed country in the world, and has a large seismic net covering the globe. I agreed with this view before, but have changed it due to two problems. In this essay, I will talk about the both problems and their effects on earthquake prediction. First, the database loses data sometimes; for example, it loses the 5.6 Turkey earthquake at 36.16N, 31.3E on June 1, 1997. Because of this loss, I had been in a dilemma to my prediction No. 23 and its related undoubted earthquake cloud for three years [1]. Second, its errors are puzzled. Although claiming an error table as the following, it lacks a standard to limit its systematic error like other databases [2]. Thus, this table is just an unproved statement. Table 1. The Unproved Error Table of the World Earthquake Database of the USGS

Rank	A	B	C	D
Error =< +/- degree	0.1	0.2	0.5	1

Moreover, the following example reveals that the data in Rank A have an error over 0.1. The two records in Table 2 were claimed in Rank A for the same earthquake. However, two intervals [27.12~27.32] and [27.40~27.60] lack an intersection. It is to say that no earthquake can satisfy its two longitude errors to both 27.22 and 27.50 less than 0.1 together. Thus, at least one longitude is not in Rank A. Table 2. At least One Longitude Is Not in Rank A

Order	Date	Time	Latitude (N)	Longitude (E)	Magnitude(ML)	Rank
Former	20010501	6:00	35.88	27.22	5.3	A
Latter	20010501	6:00	35.70	27.50	5.1	A

In addition, some data [3], [4], [5] demonstrate that vapor sources indicate impending epicenters exactly, so they can be hired as an assistant rule to check errors sometimes. Here is an example. Image 20000223 21:00 [6] showed two vapor sources: A at 37.8N, 37.2E, and B at 38.2N, 38.0E. On April 2, 2000 a couple of M4 earthquakes happened at A correctly; while another couple of M4 earthquakes occurred near B with a longitude error about 0.8 on May 7, 2000. I agree that the data on April 2 are in Rank A, but do not think that the data on May 7 are in Rank A, too. Table 3. The Longitude Errors of the Earthquakes on May 7, 2000 Are Over Rank A

Source	Latitude (N)	Longitude(E)	Earthquake Date	Latitude (N)	Longitude (E)	Magnitude(ML)	Rank
A	37.8	37.2	20000402	37.57	37.19	4.4	A
A	37.8	37.2	20000402	37.65	37.23	4.2	A
B	38.2	38.0	20000507	38.18	38.75	4.2	A
B	38.2	38.0	20000507	38.16	38.78	4.5	A

It is to say that predicting earthquakes takes a big additional risk. If one had predicted a couple of M4 earthquakes at Point B, he or she would have tolerated his or her fail due to a database problem. Fortunately, I did not predict earthquakes at Point B, but at Point A on February 28, 2000 very successfully. Within the special predicted area of 37~37.8N, and 36.8~37.2E, the two earthquakes were the only couple of magnitude equal to or bigger than 4 within 11 years at least. Moreover, within the special predicted time from March 25 to April 10, 2000, the two earthquakes were also the only couple in the area of 29~44N, and 31~48E, 637 times bigger than the predicted area. However, I feel nervous while looking at the data of Point B, and worry about if the same problem caused some failures of my predictions. Furthermore, the magnitudes of the database are unstable sometimes. For instance, the magnitude of the 7.6 Central America earthquake on January 13, 2001 increased from 5.6 to 7.6 gradually; while the 3.0 New York earthquake on June 25, 2002 dropped down from 4.0 to 3.0 suddenly. Moreover, it has different units, such as Mb, Mw, Ms, etc for the same magnitude, but those data are so different that their difference by two units changes from plus to minus sharply, for example, Table 4. Confused Magnitude Data by Different Unit

Date	Time	Latitude (N)	Longitude (E)	Mb	Ms	Mw	Location
19900620	21:00	36.96	49.41	6.4	7.7	7.4	Iran
19910408	1:25	4.09	127.93	5.6	4.1	5.1	Indonesia

Therefore, it is difficult to figure out a relationship between two units like 1 inch = 2.54 cm. Besides the above two problems, some announced magnitudes are incomparable sometimes. For example, the 6.1 Afghanistan earthquake on February 4, 1998 killed 4,000, and injured 16,000; while the 7.4 Afghanistan earthquake on March 3, 2002 killed 150. I remember that an American scientist referred the reason why the 6.1 earthquake had killed and injured so many people to a low level of the constructions on TV. However, I am confused by why under the same construction, the 7.4 earthquake killed far less people than the 6.1 earthquake had done. To figure out a possible reason, I measured the lengths of three earthquake clouds: the 6.1 Afghanistan cloud on January 1, 1998 [7], the 6.7 Mexico cloud on May 16, 1999 [8], and the 7.2 Turkey cloud on September 26, 1999 [9] as the following. Table 5. Length of Earthquake Cloud vs. Magnitude of Earthquake

Cloud Date	Length (km)	Earthquake Date	Location	Magnitude
19980101	350 (1)	19980204	Afghanistan	6.1
19990516	270 (2)	19990615	Mexico	6.7
19990926	430 (3)	19991112	Turkey	7.2

Since the longer an earthquake cloud, the bigger its related earthquake, the Afghanistan earthquake on February 4, 1998 should have a magnitude about 7. Then, it becomes harmonious with why the earthquake killed and injured so many people. This problem affects my predictions a lot because I suppose both the database and my predictions only to have an error 0.1 each, or 0.2 together. Furthermore, I predict a magnitude by comparing the size of an earthquake cloud with those of formers, whose magnitudes are in the database. Therefore, uncertain magnitudes can induce either a failure, or a large increase of the probability of a prediction. Third, the database occasionally offers some wrong report, for example, it reported a 6.6 earthquake in Southern California on July 10, 2002[10], but withdraws the report later due to no such earthquake. This evidence implies that the related measuring system of the database may need a big development. In summary, I revealed two main problems, a data loss problem and an uncertain error problem, of the World Earthquake Database of the USGS. The both problems can make a correct prediction fail, and stimulate a large increase of the probability of a prediction. Therefore, it is necessary to show our readers those problems. To avoid a possible misunderstanding, I would like to add that showing the problems above does not mean that the database is very ugly. I think that the database has done many great works, and is better than many others. For example, it reports many data, in which the number of magnitude more than 3.5 reaches about 8,500 a year from 1990 to 2000, which is tough. Moreover, it has created mapped data, such as the 4.3 San Fernando, California earthquake on January 14, 2001 [11], the 4.1 Hollister, California earthquake on July 2, 2001 [12], and so on. Those mapped data are very useful on understanding earthquake phenomena [4], [5]. It also offers many excellent data, such as the data of the couple of M4 Turkey earthquakes at Point A on April 2, 2000, the 4.1 Hollister earthquake on July 2, 2001, the 4.3 San Fernando earthquake on January 14, 2001, and so on. Finally, I would like to remind our readers to notice the database problems above, and their effects to my predictions. Since no one knows how many data the database loses, and how big its errors indeed are, I have no idea to check both my Kuril IS. and New York earthquake predictions because I believe that the both should be correct. Pushed by my belief, I checked the database, and found the above problems. I really hope that the USGS would like to solve those problems, which not only obstruct the development of earthquake prediction, but also affect other studies, linking to the data. In addition, those problems are not proportional with the honor of the USGS itself.

Calculations of the Lengths of Three Earthquake Clouds

(1) The 6.1 Afghanistan earthquake cloud. First, measure the lengths of both the cloud and the diameter of the globe [7] by a rule, and obtain 7 mm and 248 mm correspondingly. Then, measure the lengths of both the distance between (30N, 70E) and (40N,70E), and the diameter in this image [13], and get 30 mm and 338 mm respectively. Since the distance between (30N, 70E) and (40N, 70E) is 1,100 km on the ground, the length of the cloud can be calculated by the following formula: Cloud Length = 7x338x1100/(248x30)=350. km. (2) The 6.7 Mexico earthquake cloud. Measure the length of the longer cloud, and the length of the boundary between Arizona and New Mexico [8], and catch 15 mm and 34 mm coordinately. Figure out the kilometer number of the boundary, 110x5.55 km, by looking for the latitude difference, 5.55 degree, from a map. Then calculate Cloud Length = 15x5.55x110/34=269. km. (3) The 7.2 Turkey earthquake cloud. Measure the lengths of both the cloud and the distance between (40N, 50E) and (40N, 60E) [9], and find 25 mm and 49 mm in order. As long as the distance between (40N, 50E) and (40N, 60E) on the ground equals 850 km, Cloud Length = 25x850/49=434. km.

References

My Prediction No. 23 Is Correct on August 2, 2000 Earthquake Database Problems on May 15, 2001 Image 20000130 3:00 A group of Taiwan epicenters at geoeruptions exactly Image 20010103 5:00. The 4.3 San Fernando epicenter at the pinpointed dot on 1/14/2001 exactly Image 20010320 15:30. The 4.1 Hollister epicenter at "E" on 7/2/2001 exactly Image 20000223 21:00 Two Turkey geoeruptions Image 19980101 7:32. The 6.1 Afghanistan earthquake cloud Image 19990516 17:00. The 6.7 Mexico earthquake cloud Image 19990926. 12:00. The 7.2 Turkey earthquake cloud A withdrawn report by the USGS The 4.3 San Fernando, California earthquake on 1/14/2001, an excellent report by the USGS The 4.1 Hollister, California earthquake on 7/2/2001, an excellent report by the USGS Image 20020301 0:00. A partner for measuring the length of the 6.1 Afghanistan earthquake cloud

Home | Introduction | Publication & News | Predictions | New Predictions | Essays | Links | Contact

Sign Our Guestbook View Our Guestbook

Updated: August 11, 2002 | Webmaster