Guide to Installing GeoNode with an Integrated Application Part II

I recently installed GeoNode and integrated an application into it and thought I would share some notes on the process.
By the end of the guide you should have a fully functioning GeoNode installed including multiple client and Django application locally or on a server.

In part I of the blog I covered installing GeoNode onto Ubuntu 10.10 server and adding a client application. Part II covers using Django-schemata/South in the context of GeoNode and adding multiple Django applications to GeoNode.

Step 3: Adding a Django a Application

If you also have a Django application that you would like to integrate there are just a few steps needed.

First place a copy of the application somewhere on your server or local machine and then create a symlink of your Django application in /var/lib/geonode/src/GeoNodePy/geonode with a comment like:

ln -s /location/of/Django_app/ /var/lib/geonode/src/GeoNodePy/geonode/Django_app

Then let GeoNode know that there is a new Django application by editing the client build.xml

<property name="app.proxy.MYDJANGOAPP" value="http://localhost/MYDJANGOAPP/"/>

Next add your Django application to INSTALLED_APPS in /var/lib/geonode/src/GeoNodePy/geonode/settings.py:

INSTALLED_APPS = (
    'geonode.YOURDJANGOAPP',
    ....
)

You will then need to restart tomcat, apache, and postgres.

How are you feeling? Everything ok?  At this point you should be able to view your application at the IP address you used above or localhost.

For my application it does not end here, there’s more… I need GeoNode to handel database schema migrations. I will be adjusting tables and views frequently. I also need my geometry columns to be properly registered within geometry_columns in the database.

Django south and Django Schemata are a solution. This allows one to migrate database changes, it allows one to use multiple database schemas, and it registers the geometry columns.

Step 4: Adding a Django-Schemata & South

Install Django South. * note you need to install south from inside your GeoNode virtual environment, to do so run:

 source /var/lib/geonode/bin/activate

and then:

pip install South

You need to clone the Django-schemata github repository to your GeoNode server and the make a symlink to django_schemata/ directory from /var/lib/geonode/src/GeoNodePy/geonode

Now you’ve installed South system-wide, you’ll need to configure Django to use it. Doing so is simple; just edit your settings.pyand add to the end of INSTALLED_APPS:

'south'

and

'django_schemata'

Also in settings.py add to MIDDLEWARE_CLASSES:

'django_schemata.middleware.SchemataMiddleware'

In local_settings.py I have the following settings for the DATABASE:

DATABASES = {
      'default': {
            'ENGINE': 'django_schemata.postgresql_backend',
            'NAME': DATABASE_NAME,
            'USER': DATABASE_USER,
            'PASSWORD': DATABASE_PASSWORD,
            'HOST': DATABASE_HOST,
            'PORT': DATABASE_PORT,
        }
    }

Also add to local_settings.py:

SOUTH_DATABASE_ADAPTERS = {
   'default': 'south.db.postgresql_psycopg2',
}

To test and see if Django-Schemata and South are running correctly, and to set up your domains please refer to the schemata management commands
For more information:

At this point I am going to pass you along to other resources. You can find more information about GeoNode’s plans to use these tools here. You can learn more about how to setup and use Django-Schemat here at the project’s GitHub project repository, and in a nice blog written my colleague: PostgreSql schema support, PostGIS and Django. At this point I apologies for the limited documentation on the topic as we have been limited on time, here you can see some information about what was done on our specific application.

In summary you need to install Django South

Step 5: Adding multiple Django applications to GeoNode

With all of this in place you can now merge multiple Django application into one GeoNode environment, each one managing it’s own perspective database schema, while conglomerating all the required geometry columns into the public geometry_columns table.

First create a new Django app from your root Django project directory using django south with:

sudo python ./manage.py startapp YOURNEWDJANGOAPP

Add the new Django app to INSTALLED APPS in settings.py as we did above in step 3.

Then add the application to SCHEMATA_DOMAINS in /var/lib/geonode/src/GeoNodePy/geonode/local_settings.py this should look something like this:

SCHEMATA_DOMAINS = {
    '178.79.183.128': {
        'schema_name': 'gem',
    },
    '178.79.185.195': {
        'schema_name': 'ged',
    },
    'django': {
        'schema_name': 'public',
    },
}

Now add the symlink for the new Django application in /var/lib/geonode/src/GeoNodePy/geonode/

then run (within your GeoNode virtual environment) in /var/lib/geonode/src/GeoNodePy/geonode:

python ./manage.py schemamigration YOURNEWAPPIP --initial
export DJANGO_SCHEMATA_DOMAIN=YOURNEWAPPIP
python ./manage.py migrate_schemata YOURNEWAPPNAME # add "--fake" depending on weather sync db has been used

If you have made it this far, congrats! You should now have fully functioning GeoNode that has multiple Django applications, all of which are maintaining their perspective database schemas.

Hope this helps and happy GeoNoding

OpenQuake Release 0.4.6

The excitement for a new release of OpenQuake has been tremendous and today we proudly announce to the community the 0.4.6 release of OpenQuake.

It’s important to stress though that OpenQuake is still alpha software; it is not complete. However in recent months OpenQuake has reached a point where it is starting to offer some early adopters through OATS accounts a view to the capabilities that are being developed within the tool.

Another noteworthy item to mention is the release of the OpenQuake book

Below is a list of items that have been worked on in this release of OpenQuake.

OQ 0.4.5 bugs

Critical Priority
Oenquake error on gemsuns cluster – long calculation
Ubuntu packages for libjhdf4-java+libjhdf5-java and h5py are conflicting and causing weird crashes
Some GMPEs in OpenSHA-lite are not available from OpenQuake
Make IA and RSD valid parameters for INTENSITY_MEASURE_TYPE
Mean hazard curves are calculated even if COMPUTE_MEAN_HAZARD_CURVE = false
Error when using intensity_measure_type = RSD
Our software provides no reliable indication of progress
Rename the risk deterministic event-based calculator

High Priority
FE tool – Django API to join features (Part I)
Add disaggregation calculator mixin class
Add celery task for disaggregation matrix computation
FE tool – python fault source computation
Blackbox test(s) for Disaggregation calculator
Write Disaggregation NRML/XML
Celery comes to a halt after approx. 8500 tasks
Add NFS ‘base_dir’ to openquake.cfg
Disagg calculator is missing two site params
Disaggregation calculator does not sample inside of the logic tree sample loop
UHS core calculator (Java)
Create sample UHS ‘demo’ files
UHS additions to job & params DB tables, object models, param definitions
UHS config param validation
Benefit-cost ratio calculator blueprint review
FE tool – generate a fault source polygon
Celery task queues are not deleted
upgrade to kombu-1.4.3 breaks supervisor
Use @task(ignore_result=True) for all hazard tasks
We need to interleave curve computation and serialization
Circular import in java.py and utils/__init__.py

Medium Priority
FE tool – Django API to join features (part II)
FE tool – fault section join API client integration
FE tool – fault join API client integration
FE tool – fault source polygon
FE tool – enable clickablefeatures pluging for trace layer
Revisit binary disaggregation matrix result structure
Job config param enhancements
Use one form for disaggregation result types
FE tool – add scale bar to the UI
FE tool – generate sample shapefiles for the uploader
Extract_subsets() is the only task function without job_id
FE tool – The FE tool needs a fault source trace table to house the simplified fault source mulilinestring
Update rabbitmq-server and python-celery on the gemsun cluster
Progress indicator counters must be reset at job start time
Simplify clonky utils.task code
Execute() and release_curve_data_from_kvs() should not return kvs key purged in production
HAZARD_BLOCK_SIZE should move from config.gem to openquake.cfg
Release_curve_data_from_kvs() lacks a test
Broken kvs purge tests (jenkins failure)
FE tool – fix feature editor on the trace layer
FE tool – test the trace and site-observation shapefile uploader
FE tool – refresh trace layer when new features are added
FE tool – style line types
FE tool – create a new server and deploy a GeoNode for the tool
FE tool – change the order of the accordion
FE tool – migrate project to FE domain

OQ 0.4.6 bugs

Critical Priority
Replace the attribute VFReference for Taxonomy in vulnerability and exposure model
Openquake error on gemsuns cluster – long calculation
Ubuntu packages for libjhdf4-java+libjhdf5-java and h5py are conflicting and causing weird crashes
Some GMPEs in OpenSHA-lite are not available from OpenQuake
Make IA and RSD valid parameters for INTENSITY_MEASURE_TYPE
Mean hazard curves are calculated even if COMPUTE_MEAN_HAZARD_CURVE = false
Error when using intensity_measure_type = RSD
Our software provides no reliable indication of progress
Rename the risk deterministic event-based calculator

High Priority
FE tool – Django API to join features (Part I)
Add disaggregation calculator mixin class
Add celery task for disaggregation matrix computation
FE tool – python fault source computation
Blackbox test(s) for Disaggregation calculator
Write Disaggregation NRML/XML
Celery comes to a halt after approx. 8500 tasks
Add NFS ‘base_dir’ to openquake.cfg
Disagg calculator is missing two site params
Disaggregation calculator does not sample inside of the logic tree sample loop
UHS core calculator (Java)
Create sample UHS ‘demo’ files
UHS additions to job & params DB tables, object models, param definitions
UHS config param validation
Benefit-cost ratio calculator blueprint review
FE tool – generate a fault source polygon
Celery task queues are not deleted
Upgrade to kombu-1.4.3 breaks supervisor
Use @task(ignore_result=True) for all hazard tasks
We need to interleave curve computation and serialization
Circular import in java.py and utils/__init__.py
Package celery-2.4
Package kombu-1.4.3
python-oq is missing the python-h5py dependency
The broken demos need to be excluded from the 0.4.6 python
Package
postinst fails to change permissions for /var/lib/openquake in python-oq

Medium Priority
FE tool – Django API to join features (part II)
FE tool – fault section join API client integration
FE tool – fault join API client integration
FE tool – fault source polygon
FE tool – enable clickablefeatures pluging for trace layer
Revisit binary disaggregation matrix result structure
Job config param enhancements
Use one form for disaggregation result types
FE tool – add scale bar to the UI
FE tool – generate sample shapefiles for the uploader
Extract_subsets() is the only task function without job_id
FE tool – The FE tool needs a fault source trace table to house the simplified fault source mulilinestring
Update rabbitmq-server and python-celery on the gemsun cluster
Progress indicator counters must be reset at job start time
Simplify clonky utils.task code
Execute() and release_curve_data_from_kvs() should not return kvs key purged in production
HAZARD_BLOCK_SIZE should move from config.gem to openquake.cfg
Release_curve_data_from_kvs() lacks a test
Broken kvs purge tests (jenkins failure)
FE tool – fix feature editor on the trace layer
FE tool – test the trace and site-observation shapefile uploader
FE tool – refresh trace layer when new features are added
FE tool – style line types
FE tool – create a new server and deploy a GeoNode for the tool
FE tool – change the order of the accordion
FE tool – migrate project to FE domain
Package the 0.4.6 rev of openshalite
Package the 0.4.6 rev of openquake (python)
Package the 0.4.6 rev of openquake (java)
Create /var/lib/openquake if needed

Showcasing Alpha Software Via The Cloud

In recent months our project; OpenQuake (alpha) has become available to the general public via GitHub. This application still needs a user interface, but for now it can be used from the terminal command prompt.
Because this application has many dependencies and is still being developed, a packaged installer of the application is only available for the Ubuntu operating system. In spite of these limitations we wanted to still expose the tool to the general public.
To do this we tuned to Cloud technology.
We chose Linode as our Cloud provider. We created a VPS (virtual private server) with 1Gb or RAM, four cores, and 40 GB of disk space.
We named our new service OATS: OpenQuake Alpha Testing Service.The OATS setup is fairly simple. OpenQuake uses Celery and Redis so the server required some custom configurations to allow users to all share the same Celery daemon instance. Then we made a little script that creates user accounts:

#!/bin/bash

if [ $# > 1 ]; then

adduser $1

pushd /usr/openquake
mkdir $1

cp -r /usr/openquake/openquake1/demos_12_10_11/ /usr/openquake/$1/demos_12_10_11/

chown $1: /usr/openquake/$1 -R

chmod 750 /home/$1

chmod 750 /usr/openquake/$1

echo "@$1   hard limit    maxlogins    1" >> /etc/security/limits.conf
fi

As you can see, each new user account is given a copy of the demos folder that contains sample models to run through OpenQuake. The script also sets user permissions, and session log-in limits.
Each user can then ssh into the server, run, manipulate demos and explore results. Users can also interface with input files and results via a sftp desktop applications.
We also setup a Google form that captures requests for accounts into a Google spreadsheet, so then I am notified by email every time someone requests an account. And we also made a users guide for the service.

Anyway, it’s just another use of the Cloud.

OpenQuake User Manual V_0.1 Published

Version 0.1 of the OpenQuake Manual has been published today. This manual provides users of OpenQuake the knowledge to configure OpenQuake, build input models for both Hazard and Risk and understand the various outputs. The manual provides step by step instruction on how to build an Input model with descriptions for each of the parameters. We plan to continue to update the manual over the coming weeks and months as the features set continues to expand.

The Manual is being drafted using the same open source practices as the source code of OpenQuake, i.e. using a distributed version control system on GitHub, where all the latex files are openly available. This allows the various contributors and authors of the manual to work together on the manual, without need to continuously exchange Word documents. Git then assures that all contributions are properly merged. We hope that in the near future, when other scientists and developers contribute to the source code of OpenQuake, they will also contribute to keeping the OpenQuake Manual up-to-date.

Download version 0.1 of the OpenQuake User Manual now.

Guide to Installing GeoNode with an Integrated Application Part I

After another Openquake.org site outage, I thought I better copy over this post…

I recently installed GeoNode and integrated an application into it and thought I would share some notes on the process.
By the end of the guide you should have a fully functioning GeoNode installed including multiple client and Django application locally or on a server.

Step 1: Install GeoNode onto Ubuntu 10.10 server

Before installing GeoNode, there was one dependency that was not included in the GeoNode package that added some python packages, to meet this requirement I first I ran:

sudo apt-get install python-software-properties

Installing GeoNode: OpenGeo has made great progress in recent months with the process of installing GeoNode, and now you can simply follow the three commands here to install GeoNode to your local machine or to a server.

Once GoeNode is installed please follow the required and recommended settings as needed on the Configuring GeoNode for Production.

Check that your GeoNode is working by opening your browser to http://YOURIPADDRESS, you should see the GeoNode welcome page.

Now that you have a working GeoNode it is likely that you are going to want to integrate an application into it. If you do not already have an application, a good place to start is with the readygxp which has been set up specifically to provide a simple reusable template for GeoExt/GXP applications bound for a servlet container.

Step 2: Adding a Client Application
Now for the nuts and bolts of this guide, integrating the client application into GeoNode.
If you have deployed GeoNode locally or on a server and if you have your own application or have used the readygxp this guide should help get it all set up.

I would recommend to place a copy of the client application onto the server or local machine. Then you will need to prepare your client application by setting up the application build.xml to reflect the new GeoNode IP address and project name. This is done by navigating to the root directory of the client application and editing the build.xml, your setting should look like:

<property name="app.proxy.geoserver" value="http://localhost/geoserver/"/>

You will need to create a .war file of your application, lets pretend it’s called application.war. From your client root directory run (don’t forget to first run git submodule init and git submodule update if needed and ant init (just the first time after cloning the application from github)):

ant static-war

Now copy the application.war to your GeoNode /var/lib/tomcat6/webapps path.

Next add the correct IP address to the /var/lib/geonode/src/GeoNodePy/geonode/local_settings.py:

 SITEURL = YOURIPADDRESS

If you have a SCHEMATA_DOMAINS defined in your local_settings.py, then you will also have to change it’s IP address

You will also need to add the project IP to /var/lib/tomcat6/webapps/geoserver/WEB-INF/web.xml:

GEONODE_BASE_URL

Add proxies for application in /etc/apache2/sites-available/geonode it should look something like this:

ProxyPass /YourApplication http://localhost:8080/YourApplication
ProxyPassReverse /YourApplication http://localhost:8080/YourApplication

**NOTE you also need to add a path to your additional applications to the first line of /etc/apache2/sites-available/geonode so that the customized applications can be found, in my case the path looks like this:

:/var/lib/geonode/src/GeoNodePy/geonode/


Add the ip address to /var/lib/geoserver/geonode-data/gs-data/printing/config.yaml under # the list of allowed hosts:

- !dnsMatch host: YOUIPADDRESS port: 80

If you use PGAdmin to view or manage your database and your GeoNode installation is on a remote server, optionally you can allow postgress to be accessed via ssh by adding ‘trust’ to /etc/postgresql/8.4/main/pg_hba.conf and restart postgres, my settings looked like this:

local all all trust # IPv4 local connections: host all all 127.0.0.1/32 
trust # IPv6 local connections: host all all ::1/128 trust

once this is done you can view the database via PGAdmin with this ssh string:

ssh -L5433:127.0.0.1:5432 user@YOUIPADDRESS

Then open PGAdmin and change the port to 5433

One more thing to note… when adding or removing layers in GeoServer, GeoNode is not aware of these changes. To make GeoNode aware of layer changes navigate to /var/lib/geonode/ directory you need to run:

source bin/activate

then:

django-admin.py updatelayers --settings=geonode.settings

If this command fails then if could be that you need to increase the time-out time in:
/var/lib/tomcat6/webapps/geoserver-geonode-dev/WEB-INF/classes/applicationSecurityContext.xml
This completes part I of this topic, please check out part II which covers:

  • Adding a Django a Application
  • Adding a Django-Schemata & South
  • Adding multiple Django applications to GeoNode

OpenQuake Release 0.4.4

As the momentum of the OpenQuake project continues to grow, another release is now available (v0.4.4) that includes many new features.

A significant addition to the schema for storing loss maps produced from the probabilistic event-based and classical PSHA-based risk calculators has been made. Since many assets might exist at the same location, it is necessary to store many asset instances in the same site. This means, a loss map can have many sites, and each site can have many assets. For each asset only two parameters are required: a loss value (absolute value of the loss) and the asset reference (the asset id from the exposure model).

This OpenQuake release also includes 14 new GMPEs (Ground Motion Prediction Equations).

A number of GMPEs (8) (implemented by Laurentiu Danciu, ETH Zurich, Switzerland) have been ported in the OpenSHA-lite codebase for the SHARE (http://www.share-eu.org/) project:

  • Atkinson and Boore 2003 (for PGA, SA)
  • Akkar and Bommer 2010 (for PGA, PGV, SA)
  • Cauzzi and Faccioli 2008 (for PGA, PGV, SA)
  • Campbell 2003 (for PGA, SA) (a version specific for the SHARE project has been also developed (Campbell_2003_SHARE) which is corrected for a Vs30=800 m/s and takes into account faulting style)
  • Lin and Lee 2008 (for PGA, SA)
  • Toro et al 2002 (a version specific for the SHARE project has been also developed (ToroEtAl_2002_SHARE) which is corrected for a Vs30=800 m/s and takes into account faulting style)
  • Youngs et al 1997 (for PGA, SA)
  • Zhao et al 2006 (for PGA, SA)

A number of GMPEs (6) (Implemented by John Douglas, BRGM Orlean, France) developed for Relative Significant Duration and Arias Intensity have been ported in the OpenSHA-lite codebase for the PERPETUATE (http://www.perpetuate.eu/) project:

  • Abrahamson and Silva 1996, (for Relative Significant Duration)
  • Bommer et al 2009, (for Relative Significan Duration)
  • Foulser-Piggot and Stafford 2011 (for Arias Intensity)
  • Kempton and Stewart 2006 (for Relative Significant Duration)
  • Stafford et al. 2009 (for Arias Intensity)
  • TravasarouEtAl 2003 (for Arias Intensity)

The code of the implemented GMPEs can be viewed at the following link: https://github.com/gem/OpenSHA/tree/master/java/org/opensha/sha/imr/attenRelImpl. Even if present in the OpenSHA-lite codebase, the GMPEs for Relative Significant Duration and Arias Intensity cannot be yet used by OpenQuake as some adaptions in the configuration file are required and they will be probably available in the next OQ release.

Also, a number of critical bugs have also been resolved with this new release (see list below), which has led to a much more stable performance of the risk calculators.

As usual, please report any bugs or errors to the developers mailing list or just come and say hello and maybe even share a story about your work and what you’ve done with OpenQuake. We’d love to hear from you.

Features for 0.4.4 release:

  • Validation on all job parameters
  • 10 new GMPEs
  • Design output/export format for PMFs in preparation for desegregation calculation

OQ 0.4.4 bugs

Critical Priority

High Priority

Medium Priority

Low Priority

 

OpenQuake Book V0.1 Published

Version 0.1 of the OpenQuake Book has been published today. This book aims to provide users of OpenQuake with a detailed description of the theoretical background of the algorithms used in the various hazard and risk calculators of OpenQuake, including a description of where OpenQuake relies on the source code of other projects such as OpenSHA. A distinction between the features that are currently supported and those that are on the road map for OpenQuake is also included. We plan to continue to update the book over the coming weeks and months.

The Book is being drafted using the same open source practices as the source code of OpenQuake, i.e. using a distributed version control system on GitHub, where all the latex files are openly available. This allows the various contributors and authors of the book to work contemporaneously on the Book, without needing to send back and forth Word documents, and Git makes sure that all contributions are properly merged. We hope that in the near future, when other scientists will contribute algorithms to the source code of OpenQuake, they will also contribute to keeping the OpenQuake Book up-to-date.

OpenQuake Release 0.4.3

We’ve done it again! Today OpenQuake is proud to announce it’s newest release which brings OpenQuake one step closer toward becoming the of state-of-the-art tool for earthquake risk assessment worldwide.

OpenQuake release 0.4.3 is loaded with new features and improvements and is the result of a very productive four week sprint!

As we reflect on this milestone, we should remember that OpenQuake is everyone’s project. Whether you are new to the project and report a bug or are a developer contributing code, you are part of a large and thriving community. Your work, and your funding, helps improve the software.

So the next time someone asks why one would pay for ‘free’ software, take a look at the list below. OpenQuake is yours—and your collaboration, contributions and funding makes it happen, thats something to be proud of.

Don’t forget to apply for an OpenQuake Alpha Testing Service (OATS) account to give OpenQuake a test drive.

Features for 0.4.3 release:

  • Engine can now perform computations on a set of sites
  • All OQ logs are linked to their respective job
  • Risk exposure importer from NRML to Database
  • New demos for testing out OpenQuake

OQ 0.4.3 bugs

Critical Priority

High Priority

Medium Priority

Low Priority

Wish List

 

 

OpenQuake Release 0.4.2

Another sprint, another OpenQuake release!
The list of OpenQuake features continues to grow, see whats new in this release.

Features for 0.4.2 release:

  • Optimization of the computation of the aggregate loss curve when running Probablistic Risk computations
  • DB serialization is now default, so you need –output_type=xml to produce XML output
  • Computation fails cleanly when there is a Java exception in a Celery task
  • Optimization of classical PSHA hazard jobs
  • Optimization of hazard curve KVS storage
  • All OQ results are now stored in the postgres database
  • Celery worker sends result message
  • Fixed redundant loss curve computation
  • Speed improvement to calculation of mean hazard curves
  • Hazard curves are stored more efficiently
  • OQ job status is capable of reporting failure from database
  • Database schema license has been updated
  • Celery automatic startup script

OQ 0.4.2 bug list

Critical

High

Medium

Low


OpenQuake is now available through the OpenQuake Alpha Testing Service (OATS)

Global Earthquake Model – Model Facility (GEM-MF) where OpenQuake is developed is excited to announce OpenQuake Alpha Testing Service! This new service provides members of the OpenQuake community an Internet based solution to access OpenQuake.
What is it:
OATS provides access to the most recent Alpha version of OpenQuake without any requirement of loading software onto their workstation or server. The GEM-MF updates OATS immediately after each development cycle, which generally lasts about 1 month. These updates provide new features and fixes to reported bugs.
Why is GEM-MF providing this service:
Many of our users are members of the earthquake community. They are interested in learning how OpenQuake can compute Hazard and Risk and produce results. We have had some of our users install OpenQuake on their computers, but this has in some cases taken lots of time and effort. Once up and running, OpenQuake is large and complex and it can consume a lot of computing resources. It is due to these issues that we created OATS to provide access to OpenQuake without the overhead of a local install while providing good performance and most importantly a positive experience.
How it works:
OpenQuake runs on the Unbuntu Server platform and is operated via a command line interface. We recommend the use of two pieces of common networking software to access OpenQuake. The first is a SSH client which provides the user with a command prompt to manage and run models through the OpenQuake engines. The second networking software is a SFTP client. SFTP enables the upload of configuration and model files and subsequent downloading of results post-processing.
Details about how to use the engine, install and configure these tool as well as some specific ‘brand name’ tools that we recommend using can be found here.

How to get an OATS account:
Members of the OpenQuake community can apply for an account to access OATS. When we grant an account we are hoping that the new user will work with the system and provide us feedback so that we can continue to improve OpenQuake.

Apply Now!