Online tools facilities for historical earthquake data investigation

Table of Contents

Online macroseismic databases
Background experience with the Italian Macroseismic Database
Macroseismic data structure
Required functionalities
Development and technical details
2008 update
Final users feedback
Gazetteer management tool
Gazetteer structure
Required functionalities
Development and technical details
Conclusion and future development

In our working group at the INGV, Istituto Nazionale di Geofisica e Vulcanologia, Sezione di Milano-Pavia we have to deal with the geographical representation and manipulation of data describing the macroseismic effects of historical earthquakes.

We first collect and store scientific papers and documents, called Studies, supplying such data covering a thousand years of earthquakes, then a record for each collected item is added to our earthquake inventory.

It often happens that a single earthquake is being studied by multiple Studies, so the second step is to make connection between already collected items and analyze the differences.

The third step is to extract from each Study the distribution in time and space of the effects of the described earthquakes. In this way each collected Study item produce the so called "intensity distribution" of an earthquake: a list of places cited, each with a degree scale of effect (for example the EMS98 [Grünthal et al., 1998] or Modified Mercalli scale). The whole collection of observed intensities become the so called "Macroseismic Intensity Database".

The fourth and last part is to sum all the retrieved data in calculated parameters, creating the so called "Earthquake Parametric Catalogue", a catalogue in which each entry represents a single earthquake with a series of parameters describing the event such as the number of observations, the maximum observed intensity, the epicentre coordinates, the calculated epicentral intensity and magnitude.

This process is extremely time consuming and often not much rewarding in term of research papers but is the fundamental input piece of the general seismic hazard assessment process.

The working group is involved with European Community research projects and shares the entire research process among researcher spread in different countries. We are also an Italian public financed research institute and we do have to spread knowledge to the Italian public.

The working group is involved in two major project:

The goal of both projects is to make historical earthquake intensity data available to the public in digital form. In Europe data are still collected and archived in isolation by many of the seismological observatories, with varying criteria and degrees of commitment. So far we have completed the time-span 1000-1600 for the whole European region, and for Italy we cover until the year 2006.

In Europe only a three countries already have a consistent, available set of historical earthquake data, interpreted in terms of macroseismic "IDP", Intensity Data-Points: Italy with DBMI04, France with SISFRANCE [Scotti et al., 2004], and Switzerland with ECOS [Swiss Seismological Service, 2002]. In other areas, scattered data are available on paper, though the coordinates of the data-points are not easily obtainable and the place-names are missing in many cases. Homogenisation and consistent documentation of many studies and data across Europe is missing.

This is in stark contrast with the corresponding situation in the USA, where the centralised Earthquake Intensity Database provides more than 150,000 IDP data for over 23,000 damaging events after 1638, with the whole data set freely available on the Internet. Also in South America the CERESIS [Giesecke et al., 2004] published on the Internet a unified Earthquake Intensity Database.

A series of software facilities were planned to achieve our mentioned projects goals and here we presents two of them:

  • an historical earthquake intensity database web mapping tool;

  • a gazetteer management tool.

In both tools we found that SVG demonstrate an extreme flexible simplicity.

The working group has faced the needs for web-mapping publication back in 1997 with the first Italian Macroseismic Database called DOM4.1 [Monachesi and Stucchi, 1997]. At that time the words "web-mapping" or "web-GIS" still had to be invented and every solution had to be built from scratch. It is enough to have a look at the Wikipedia "Web mapping" entry to see how well in advance the implementation was. Figure 1 shows how this early attempt looks like: a frameset and table based lightweight website offer the possibility to retrieve earthquake macroseismic maps intuitively.

Maps are simple bitmapped GIFs with an html map: each macroseismic intensity point is clickable. Neither zoom nor pan tool were possible at that time.

In 2004 a new Seismic Hazard Map of Italy [MPS Working Group, 2004] has been released by a task force in collaboration with the Italian Civil Protection Department that produced an amount of new or updated data, such as a new version of the Italian Parametric Earthquake Catalogue CPTI04 [CPTI04 Working Group, 2004] and the new historical earthquake intensity database DBMI04.

The design process of the second generation web mapping site for distributing the updated Intensity Database was started in 2003. Back in 2003 the web mapping technology attempts were greatly enhancing the user experience possibilities and both the commercial products and the open source world started to introduce promising products.

Existing Intensity Earthquake Databases published on the Internet were using different web-mapping software solutions:

Both solutions are "WMS", Web Map Service "OGC", Open Geospatial Consortium compliant: a client software collect the user requests and calls a server that generate and sends back bitmapped maps.

We tested both software and selected none of them: they were over powered, over complicated for our purposes; huge computational power from the server-side point of view, uneasy customisation of the layout interface and web-accessibility make us deciding to internally develop our own solution. Apart from the developing point of view, resulting maps with both MapServer and ArcIMS are simple bitmaps and once downloaded the offline use is very limited: no high printing quality and no interaction is possible.

During the initial software solution investigation we encounter SVG and with very little effort we were able to produce:

  • high quality graphic, resolution independent both on video and on printer;

  • interactive maps with zoom and pan with just few line of easy-to-do scripting;

  • "clever" maps: once the SVG maps has been created it is self sustained, no further remote server calls are needed anymore;

  • hight accessibility potential, being SVG obejcts XML based;

Dealing with "clever" and self-sustained maps may not appear important today, but in our opinion is the warranty that in the future (we are talking about years) we will still be able to browse into our file archives without loosing information or loss of funcionalities. From our point-of-view external resources based solutions, such as WMS services are, may cause archiving problems in long terms.

In 2003 the SVG choice were looking promising and after years we still are happy with it.

The macroseismic intensity data-points in DBMI04 are 58926 related to 1024 earthquakes out of 2550 listed in the CPTI04 catalogue, for which an intensity distribution has been assessed. A IDP is identified by: the place name, its geographical coordinates, and the macroseismic intensity assessed according to a macroseismic intensity scale.

The 58926 intensity data-points in the database are supplied by different studies that used different formats with regards to: name standards, coordinates rounding, etc.

Thus implementing a homogeneous database required:

  1. referring the macroseismic observations to places listed in a unique and standard reference directory;

  2. correcting possible mistakes in the georeferencing of the IDP, deriving mostly from the original association of an observation coming from the primary source to a place with the same name but different geographical location.

The homogenization process might imply modification from what the original Study reports, therefore DBMI04 always reports two series of information: the original and the revised version. Out of the 58926 input records, over a thousand of IDP geo-referencing were modified.

The web-mapping tool helped the process thanks to its quick use.

The continuous feedback from end-users helped finding bugs and implementing new features. The system was tested both locally and remotely, being the working group distributed all around Italy.

The website workflow scheme is as follow:

Being the lightweight footprint one of the main goals on both the server-side and the client-side we decided to cache every generated file on the file-system: this process decreases dramatically the computing power needed on the web server. On the client side SVG maps don't need any remote call, being every further user map interaction (zoom, pan, place search) directly done by the browser JavaScript engine.

The pre-caching include the bitmapped DEM, that is created in ESRI ArcMAP from SRTM public data exported as a GeoTIFF file. Internal PHP code directly encode into the SVG file the bitmap by using geographical information stored in the TFW file.

Other than speeding up the user experience, pre-generated SVG maps can be putted in a cd-rom and offline consultation is possible using only javascript.

In the early developing process we didn't cache files, and users lamented a lack of responsiveness between the earthquake selection and the browser displaying the map. An extensive check were done to identify factors that influence the visualisation speed on the client side:

  1. map generation on the server, later solved with a cached pre-generation of maps;

  2. map file transferring time, solved with a GZIP compression of the SVG file;

  3. the complete DEM, Digital Elevation Model of Italy was too big so we decided to crop it on the area of interest; for a potential later offline use of the SVG map we also decided to encode the DEM bitmap binary data directly into the code;

  4. client hardware configuration: the SVG file is completely managed by the client computer, its CPU and its RAM must be up-to-date. We guarantee a satisfying use of the system starting from a CPU clocked at least at 1Ghz and a system equipped with a minimum RAM size of 512Mb;

  5. client software configuration: we found that SVG enabled browsers are faster on the Microsoft Windows operating system; Apple OSX browser does appear a bit slower. Linux based browsers showed both a lack of stability and slowness but Mozilla Firefox is promising.

Querying by earthquake is done by both choosing the date on a list or by an interactive map.

Query by place, both by list in alphabetical order and by using an interactive map.

One of the problem that we faced was the used coordinate system. We chose the Universal Transverse Mercator (UTM) zone 32 based on the WGS84 ellipsoid for the whole Italian peninsula. The geographic coordinate conversion from latitude and longitude expressed in decimal degrees is done by internal code that uses equations USGS [Snyder, 1997] equations implemented in PHP.

Conversion of vector geographical elements in shapefile format to SVG code is done via the open source "shp2svg" utility (A. Neumann, 2007).

This year a new version of the historical earthquake intensity database will be published and we are currently updating the web-mapping tool SVG code generator.

The most common criticism to the DBMI04 website implementation has been the dependency to a dying plug-in: the Adobe SVG Viewer. Nowadays this condition is out of date: browser such as Mozilla Firefox, Opera and Webkit based browsers have an internal SVG interpreter. The only browser that still does not support natively SVG is Microsoft Explorer in which a plug-in is still needed and luckily a new plug-in is surfacing for Explorer: the Renesis Player Browser.

A revisione of our SVG generated code has been made and now zoom and pan function are possible in all browsers natively SVG aware. As a secondary results we found that responsiveness has increased as no time is spent on the client side loading the plug-in software: few seconds after the click and maps are flawlessly showed.

Another request to the old DBMI04 interactive maps was the missing scale bar which, for technical reasons was not implemented. We found this apparently easy-to-be-done request a quite tricky task because of the fact that SVG maps width and height are specified as a 100% of the available window frame area. We decided to invest time on solving this technical problem and now we have a working "overlay" layer which is not influenced by zoom, pan or the browser window resize.

The historical earthquake intensity database stores a list of observed effects reported in specific places. The 2008 version of the Italian intensity database contains around 15000 different places, mainly in Italy.

Working with such a variety is only possible using a focused and well structured Gazetteer [Hill L., 2006]. Given the absence of an official Gazetteer for Italy, the Working Group started compiling its own more than ten years ago. The starting point was an already existing Gazetteer that offered both a good quality geographical co-ordinate resolution and reliable place names.

After years of integrations the complexity of the Gazetteer became unwieldy. Crosscheck, entry search or updating became not easy.

We therefore decided to invest a short time developing a centralised software always up-to-date for the whole Working Group.

This article presents our successful experience using the SVG graphic language to solve very focused tasks. Starting from thinking the final user experience, the technical implementation just followed as an irrelevant (well, sort of) detail.

Of course our implementation has a series of limitations, all coming from the fact that the system cannot communicate with other server; the web-mapping tool for example can only output files (SVG maps with high quality printing resolution, bitmapped images, Google Maps kml files and Excel tables), but this is what the working group does need. WMS /OGS compliant solutions such as ArcIMS or MapServer have no plus valour in our daily job, and their customization comes with the price of complexity. Our implementation is fast, inexpensive and needs only software that is commonly available on research centre web servers (Apache and an geographically unaware database management system).

Our software solutions are not general purpose application, they are not meant to be flexible or easily adaptable to other purposes: we have very specific needs and we created very specific solutions. This is a very common practice in the scientific research world because of the extremely resource limitations both from the economic and from the human resource point of view. These tools are nothing else than small pieces inside the scientific core research, they are not meant to be sold to the public.

Entering an European Commission funded project forced us to generalize much more our implementation and a major revision is planned. European partners are asking us to deliver the web mapping software adapting it to their specific needs. One of the most requested feature is to output a complete static website: a series pre-generated html files that doesn't need any server side scripting language nor online database interaction; this request comes from the extremely restrictive research centres policies in terms of web server use.

An open source license is planned and documentation is in preparation.

Future development is concentrated on study and experimenting web-service based interfaces plugged into our online infrastructure.