Seismic Observations in SOS
: Patrick Noble
: Alex Kmoch (email@example.com
), Carsten Hollmann (firstname.lastname@example.org
) and Simon Jirka (email@example.com
My name is Patrick Noble. I am a 3rd year Computer Engineering student at California Polytechnic State University, San Luis Obispo. Born and raised in Long Beach, Ca, I moved up here for school and have been immensly enjoying the open space and clean air of central California. I had no programming experience to speak of upon entering college, so my computer engineering journey has been quite challenging as well as stimulating. At this point, my real world experience has came from personal experimentation and a job working on Flex UI design for Tapestry Solutions
. My other academic passion lies in the study of Geology. I began a minor in the subject my second year, and so far it has proved to peak my interest in areas of Seismology
. I hope that I can use my experience in Geology and software to find a niche that I can enjoy working within, and benifit both fields.
Original Project Idea
: This project idea popped up on the mailing list recently, and might need to be precised any time soon. I see a client-side (sensor web client) and server-side component (52N SOS 4.0.0) so far. The aim is to load, serve and visualise seismic data, which could be found in different places (USGS, GeoNet
... refrerences/links?) and in different formats. Seismic sensors deliver primary data. Earthquakes are located based on the input of the seismic sensors. Please investigate on accessible seismic data sources, e.g. from USGS, GeoNet
or the German GFZ institute in Postdam. Please also have a look on some NZ GeoNet
resources (here and here). I had a look at the QuakeML
definitions, and it seems it can be used for eartquakes in terms of events as well as generic seismic data (but it is not a GML application schema, only GPS coordinates in lon-lat).
However, we want to translate that into OGC SOS interoperability space. For the server-side of things, an alternative DAO could be implemented that sources seismic data from e.g. USGS and serves them as standard SOS/O&M. This includes further challenges, intelligent caching for example. Secondary an alternative output encoding, like QuakeML
(also look here and here), could be implemented for the SOS server. Is there possibly a "SOS profile" appropriate?
For the client-side, intelligence about seismic data (conceptual) and the encoding is necessary and might be implemented in the sensor web client, to visualise seismic data. So it would be good, if you brought a good portion of Java and XML knowledge. Expected results
: We will have to make the seismic data available through the SOS server, the output may be O&M or even QuakeML
and then a client wants to visualise things (earthquakes as point features and/or seismographs as a time-series plots). I think altogether might a bit too much (although depends on your programming skills and motivation)
Community and Code License: Sensor Web, GPL or Apache