swish-climate-impact-assessment

Reboot again

2018-11-02T00:00:00+00:00

Several years ago this was all created to assist the Climate Change and Health projects led by Tony McMichael out of NCEPH. But since then funding has been difficult to get for Climate Change research in Australia and much of the work on this project fell by the wayside.

Today we are pleased to announce that there is renewed interest in funding for climate change and health research, and especially in relation to health impact assessments (HIA).

So the SWISH website, tools and servers are all getting rebooted (again).

Stay tuned for more exciting news about our developments of data and tools to assist researchers to more quickly and effectively do health impact assessments for a range of environmental risk factors related to climate change, air pollution and the energy transition.

Reboot

2015-12-02T00:00:00+00:00

The SWISH project is going to move forward
The H used to stand for Health, but the scope of the project has grown and so now the H stands for ‘Holistic Climate Impact Assessments’.

Finishing Up

2013-10-26T00:00:00+00:00

The SWISH project is finishing up.
Ivan will add any future swishdbtoools or EWEDB content to his Open Notebook Science (ONS) blog
Keith got a new job
ANDS showed our video at eResearch 2013.

Cheers!

User testing report

2013-06-24T00:00:00+00:00

SWISH Kepler actors user testing.

We invited Peter Manger from the Fenner School at the ANU to be one of our test users. Peter has a background in simulation, modelling and software. He is a good example of someone proficient with data processing and analysis but with no previous exposure to SWISH tools.

How well did the user use SWISH?

Peter made his way through the tutorial, quicker than I expected for someone who had never used the software before.

During the testing two mistakes occurred

A missing an input link to an actor. When run the workflow reported an error, Peter quickly identified the omission himself and corrected it.
The identifier “Date” was used with a capital letters instead of “date”. When run Kepler reported an error message; however this problem was too subtle. Even after I pointed it out Peter was unclear as to why the error was occurring.

The images in the tutorial provided the necessary details to continue through the tutorial without encouraging Peter to notice and understand the accompanying text. The tutorial explains that the all links need to be connected for the workflow to run and the identifiers are the names of columns in the input data. Both of these points that directly explained the errors that occurred where overlooked.

Did the user complete the analysis they intended to do?

Yes!, Peter successfully assembled an operational workflow that ran and produced the correct result by following the tutorial.

Peter was then curious and started to ‘play’ with values in the heat index calculation. He lowered the maximum temperature limit and increased the min - max threshold to generate a greater number of ‘heat waves’.

What features did they find useful and what features did they have difficulty with or wish to see (and are subject to future improvement if there are available resources)?

Peter was able to quickly use the installer and update the software to the latest version of SWISH actors. Peter found the drag, drop and link nature of Kepler intuitive and usable. He was able to easily find all the actors needed by the tutorial. The actors used where clearly named and labelled, Peter found them simple to use.

The biggest problem is the handling of errors. The SWISH actors that use Stata report their own error messages. The SWISH actors that use R do not report any error messages other than the fact an error has occurred. General Kepler actors report the Java stack trace from where the error occurred in Kepler source code.

** None of these are useful to the user and could be improved. **

The error reported by the Stata based actors indicate the error that Stata had, but it is always a consequence of a problem located somewhere in the lead up to running Stata. The error messages require an intimate understanding of how SWISH operates to decode.

The R errors are completely opaque and provide no useful information.

General Kepler errors are also cryptic and not helpful.

Error handling for general Kepler actors is the responsibility of the developers of the actors and Kepler to manage. The SWISH Stata actors, although they perform their own error checking and reporting would improve the user experience dramatically by reporting more meaningful messages and solutions to the user. The SWISH R actors are completely lacking in any form of error handling and need to implement it within the R code its self.

Observations

Peter had trouble linking some actors together as the links ‘snap’ to other nearby links or port. Peter worked around this when necessary by dragging links the long way round to avoid connecting to the wrong place.

Peter did not run the workflow until the very end. This made finding errors more difficult.

Peter did not realise that by creating and using the workflow in the tutorial he was using the statistical software Stata.

The understanding Peter gained from the tutorial was mainly operational details of how to use Kepler.

Peters feedback

Peter knew that Kepler was existing software but was unclear what part of the exercise corresponded to SWISH project. His suggestion was to package all the actors available in a SWISH subgroup of some kind.

Peter liked the images, and found the progression from individual small steps at the start of the tutorial to boarder instructions at the end made sense.

Kepler common tasks

2013-06-07T00:00:00+00:00

Kepler common tasks

This tutorial documents some of the tasks that frequently occur when using Kepler. It is not a sequential series of steps, but a collection of independent operations.

Start Kepler

Kepler can be started using the start menu. You can open the application or open it via the command line. Using the command line can sometimes display extra information useful in debugging workflows and is the way we recommended starting Kepler. To make it easier there is a shortcut installed with the SWISH tools.

The command line window while Kepler is running

Main window

Search and components panel on the left, canvas on the right, play buttons and menus at the top.

Search for actor or director

Searching is the easiest way to quickly find the part you are looking for. Type in the name and press enter.

Add actor to workflow

Drag and drop using the cursor

Link actors together

Links pass values around the workflow and sequence execution. To link actors use the cursor, click on a port arrow on one actor and drag to the port arrow on another actor.

Save

Save using the file menu

Rename workflow

You will be prompted when saving to give a name, but can also change it afterwards.

Change actor or director values

Double click on the actor and the values that can be changed appear. To keep changes click the commit button. Eg the constant value actor

Animate at runtime

Turning this on will display what actor the workflow is up to when running. This given an indication of where a running workflow is up to.

Execute a workflow

Like a VCR press the play button.

Display value

Use the Display actor to view values on screen. The actor can be connected to any other actor. It is useful for debugging and inspecting the results through the workflow.

Move the canvas view

Use the mouse to move the part of the canvas displayed

Actors not linked error

Usually, all actors need to be connected in a complete sequence. This includes actors in sub-modules which can be misleading and tricky to find.

Rename actor

Actors can be given titles. This can help document the workflow or set the name of an actor to export.

Director missing

This happens to everyone!

Export actor

Actors can be saved and then reused in other workflows.

Developing new tools with Kepler workflows

2013-06-05T00:00:00+00:00

Developing new tools with Kepler workflows

If you can’t get an actor from the core Kepler actors or our SWISH actor contributions then you have two choices:

assemble current actors into a new ‘composite’ actor or
develop a R/python/matlab/stata function to be a new actor.

If you go for option 2 therefore you have to develop your function to work with other Kepler actors. There are a few tricks to doing this. This post will show several different approaches available to develop a new Kepler R actor.

1 identify R function

There is probably an R function that does what you want. If not start writing one. If it is a really simple case of just using a current R function with simple input/output requirements you can write it straight into the Rexpression actor and add some ports… however anything more than a couple of lines can get buggy quickly, and this is not a good place to be debugging code.

2 write function in a script

Then , test/debug in an IDE like emacs, Rstudio or eclipse; and then deploy to Rexpression actor in workflow

3 source() your script from kepler

Similar to 2 but rather than copy the code to the actor just add

source('path/to/script.R')

to the actor.

4 write a package

Similar to 2 and 3 but the function is written to a package and then this is loaded with

require(MyPackage)
outputPortValue <- myFunction(inputPortValue, otherArgument)
outputPortValue

You can then publish this on GitHub or CRAN, or even just send as a zip or tar to your collaborators.

5 add this to MyWorkflows

if you have the R code or package details in the actor save this by right clicking on the actor and save it to your kepler directory under MyWorkflows. This means it will be available whenever you open Kepler.

6 If it is really awesome contribute it to SWISH

Take a fork of the swish-kepler-actors GitHub repo and add your actor and tests to the simpleInstaller/Actors folder. Then send a pull request to the SWISH maintainers and these will then be incorporated into our one-click installer.

test gislibrary with SLA concordance

2013-06-03T00:00:00+00:00

Testing the GIS library from R, Calculate a SLA concordance

In this post we will use the swish R/PostGIS tools to manipulate spatial data on a remote GIS server (to calculate a SLA concordance) and extract the result to our local client machine. Clink here for the R script.

The great thing about PostGIS is that it is a standard relational database that also understands spatial data. We have developed an R package called swishdbtools to assist connecting to the Database from Kepler.

require(swishdbtools)
ch <- connect2postgres2("gislibrary")
# fill in the details, only required once as will save to your profile
dbGetQuery(ch, 
       "select t1.sla_id, t2.sla_code as s2, st_area(t1.geom)
       from abs_sla.nswsla91 t1 join abs_sla.nswsla01 t2 
       on t1.sla_id = 1 || substr(cast(t2.sla_code as text), 6,9);
       ")

Pretty cool huh? Spatial functions start with st and the generic name for the spatial data is geom or the_geom.

say we want to create a concordance file to map changes between SLA boundaries

I figured out a complicated SQL syntax to compute the intersecting geometries, then wrapped it up into an R function:

# make a temporary tablename, to avoid clobbering
temp_table <- swish_temptable("gislibrary")
temp_table <- paste("public", temp_table$table, sep = ".")


sql <- postgis_concordance(conn = ch, source_table = "abs_sla.nswsla91",
   source_zones_code = 'sla_id', target_table = "abs_sla.nswsla01",
   target_zones_code = "sla_code",
   into = temp_table, tolerance = 0.01,
   subset_target_table = "cast(sla_code as text) like '105%'", 
   eval = F) 
cat(sql)

Which gives the map

This shows the SLAs that existed in 2001 that were a smaller segment of their original SLA zone in 1991 (the red areas changed the most).

From the less pretty SQL

I just run the single line version

dbSendQuery(ch, sql)

if I don’t want to look at the ugly code

so now I can use QGIS to visualise this, or if on linux rgdal can access it direct

require(devtools) # windoze users need to install Rtools
install_github("gisviz", "ivanhanigan")
# otherwise download and install from http://ivanhanigan.github.io/gisviz/
require(gisviz)

# get pwd from store, or use pwd <- getPassword()
pwd <- get_passwordTable()
pwd <- pwd[which(pwd$V3 == "gislibrary"), "V5"]

shp <- readOGR2(hostip="130.56.60.77",user="gislibrary",
   db="gislibrary", layer=gsub("public.","",temp_table), p = pwd)
head(arrange(shp@data, prop_olap_src_segment_of_src_orig))
subset(shp@data, source_zone_code == 10750)[,c(1,4,6)]
# source_zone_code target_zone_code prop_olap_src_segment_of_src_orig
# 36            10750        105530751                         0.4791171
# 37            10750        105530752                         0.2455572
# 38            10750        105530753                         0.2726988
# save local copy
writeOGR(shp, "sydneyconc", "sydneyconc", driver="ESRI Shapefile")
# make default map
choropleth(stat="prop_olap_src_segment_of_src_orig", region.map=shp, scalebar = T, 
  probs = seq(0, 1, .2), invert.brew.pal= F, maptitle='Sydney SLA91-01 intersection')

and finally just clean up the temp file from the db

dbSendQuery(ch, paste("drop table ",temp_table,sep=""))

Ecologists studying farm dogs with radio tracking collars

2013-05-17T00:00:00+00:00

Extracting the weather for each location that a farm dog was observed

These data were collected by Linda Van Bommel and supplied to the SWISH project by Luciana Porfirio to use as a demonstration of how our tools might be used by researchers in other disciplines.

The locations are taken from radio tracking collars on farm dogs taken over 8 months, all in the same format (date, time, lat, lon) for a number of dogs. The coordinates are from a farm in Victoria.

Step one: modify the SWISH example

The previously written workflow used as a test case for the SWISH project was downloaded from this web page.

That workflow takes location names with unknown lat, longs and geocodes them using the GoogleMaps API. For this dataset we do know the lat, longs so the first step was to delete the superflous actor and replace it with one that gets the data from the source location at Google Docs/Spreadsheets.

This URL is highlighted in the image below.

Step two: Add some specific code to this analysis

For example we will want to look at the spatial distribution of these data so a simple map is generated and displayed in the imageJ actor. When the workflow is run the image below appears in a new window. This can then be refined into a publication quality map at a later time.

Step three: specify the dates required

The information required by the “R raster extract by day” actor needs to be changed to reflect the specific duration of this dataset.

Step four: include a new step to merge the output time-series data with the spatial data

The time series data is then extracted for each location, and every time point. That output does not include the lat,long data so this is merged by adding the “R merge” actor and specifying the files to merge. The result is shown below:

Step 5: assess data

In the above image we see that date.x is the date of the observation, date.y is the time the weather value was observed at that lat,long. For each location we now have the complete timeseries of weather data extracted from the EWEDB AWAP grids datastore.

Future work required: reformating data

As you can see this is almost what we want, but not quite. We now know the weather on each day for every location the dog visited. However what we really want will be the weather at the point the dog was at the same time the dog was there. To do this additional actors can be added to take the data generated so far and perform subsequent re-formatting steps so the data do match up the observations with the weather at their exact time point.

Automated processing of multiple datasets

Once the workflow is finalised the URL pointing at the Google Spreadsheets dataset can be changed to other farms, or indeed any datasets with lat, long values in Australia. If there is a large number of these a list of URLs could be fed into the workflow in a loop so that each dataset is processed in exactly the same way. In this manner many datasets can be accessed in a rigorous and transparent manner, and revisions can be easily incorporated as new datasets are aquired or new analysis plans are formulated.

Replication data and software

The data and software used in this tutorial are available from these links:

geocoder

2013-05-15T00:00:00+00:00

A exemplar workflow for geocoding locations

The geocoder workflow at this clink is an example that takes a list of locations and returns a shapefile with the latitude and longitudes, as well as a map.

As you can see when you open the KAR file, this workflow expects an XLSX file to be linked in the first actor.

list your locations

run the workflow to create an image

and a shapefile, stored in your temporary directory

AWAP grids vs station observations

2013-05-13T00:00:00+00:00

Comparing the gridded estimates to the observations

The EWEDB holds daily gridded data we downloaded from BoM. The size of this data collection is formidable (> 71,000 raster grids currently with 1980 to present, and set to grow significantly as we incoporate earlier decades).

We were faced with the choice to store data for more time points (days), at lower spatial resolution (less megabytes) or for less time points at higher spatial resolution (more megabytes). In the interest of deriving Extreme Weather Indices from the longest timeframe possible (to identify truly extreme observations from the full historical range) we decided to aggregate the original data from 5km pixels to 15kms squared pixels. This loss of spatial precision is compensated to some extent by the high spatial autocorrelation as displayed in the map of the recent heatwave in New South Wales, Australia, January 2013.

When we aggregate pixels of the grid there is more chance that the observed data will be different from the estimate at that location due to spatial smoothing. In this post we will compare the observations from BoM weather stations with the daily values for the grid cell they intersect.

There are 939 weather stations that have valid observations for all three temperature, vapour pressure (humidity) and rainfall in the 1990-2010 period we also hold the data for. To save a bit of time we’ll only do a 10 percent random sample (93) of these shown below.

Getting the values for each station from the grid pixel it lies on we can construct an artifical timeseries as shown.

Merging these estimates with the observed data we can compare them and derive some summary statistics such as the R-squared.

Max Temp

Min Temp

Rainfall

Vapour Pressure (humidity) 9am

Vapour Pressure (humidity) 3pm

Conclusions

The comparison presented here shows that the observations and AWAP gridded datasets that we have processed for storage in the EWEDB differ, due to the spatial smoothing that has occured in the processing undertaken for the EWEDB project.

Users are asked to bear this in mind when considering the appropriateness of these data for their specific application.

Set Up R for Kepler on MS Windows

2013-05-09T00:00:00+00:00

Install R 3.0

Even if you have The R Environment for Statistical Computing and Graphics installed we recommend you upgrade to version 3.0 because new packages from there will not work with R 2.15 etc.

Register R in the PATH so that Kepler can find it

This tutorial assumes windows 7 and a user without administrator privileges.

First download and install R to a location you can write to

It won’t be recognised on your PATH

Because you are not admin it will not be in your path. Check this by opening the terminal (Run > cmd) and then type R.

Go to the control panel and navigate to the set environment variables

make a new USER variable

Locate the appropriate R binaries

make the new variable called Path

Exit and restart the terminal and check that R is recognised

The End

Extract AWAP data for locations

2013-05-03T00:00:00+00:00

AWAP data

The AWAP data were found and extracted for a specific date in a previous post. This tutorial will demonstrate extracting data for a range of dates and locations.

See this page

Kaleen, ACT is a test case

In the attached example the study location is Kaleen, a suburb of Canberra.

Hello EWEDB (Simple Set Up the Swish Computer to connect to EWEDB)

2013-05-02T00:00:00+00:00

Hello EWEDB

This is a very simple workflow designed to install the swishdbtools R package and test the setup of your computer and the connection to the EWEDB.

Step 1

Download the “hello-ewedb.kar” workflow

Step 2

Run the workflow.

Step 3

Enter the details. When you run this it will download the R package and install it, along with its dependencies. It will then look for your PostGIS username and password, if it can’t find a valid username, password, database and server combination it will ask you to enter them.

You will have recieved a username and password when the Data Manager set up your account.

On MS Windows your details are now stored in this file or ~/.pgpass on Linux.

Step 3

Verify the test data “hello_ewedb” was written to the database, and read back out again, and removed afterward.

Extracting Weather Data from Grids

2013-04-26T00:00:00+00:00

Gridded weather Data

One of the cornerstone datasets in the EWEDB is the gridded weather data from the Australian Bureau of Meteorology. This post will describe a user extracting weather data for their study locations from overlaying the coordinates on a grid and returning the value of the pixels at that location for a specified date.

Step one: find the data

First log in to the Web Catalogue

Then Browse

Or Search

These data are discovered. Further information is available.

Step two: Create a Kepler Workflow

The Workflow in the image below:

gets a list of study locations in the towns.xlsx file (Notice that Wolongong is MISSPELT?)
subsets them to the places of interest
geocodes them using the google geocoder (which will return a fuzzy logic best match for the misspelt name - thanks Google!)
uploads the coordinate data (in latitude and longitude) to the EWEDB PostGIS server (after checking our saved password in the postgres.conf file)
tells the PostGIS data are a points vector datatype, and that the coordinates are in GDA 1994 projection system
extracts the pixel values for the raster named in the string constant (that we found from the catalogue)

The result

The result is a file extracted from the database to the local TEMP directory and the name is shown.

The user can then take these data for further work

Quality Control

An imporant point to note is that the coordinates retrieved from the GoogleMaps geocoder might not be correct. It is easy to check that the locations we just stored in the database are correct by viewing them in Quantum GIS (see this previous post for instructions on setting up Quantum GIS).

Thankfully these locations appear good (even the mis-spelt “Wolongong”).

A SWISH user test report

2013-04-19T00:00:00+00:00

A SWISH testimonial

Here is what a test user had to say about the EWEDB.

Steve McEachern is Deputy Director of the Australian Data Archive and senior research fellow with the Australian Demographic and Social Research Institute at the Australian National University.

The Scientific Workflow and Integration Software for Health (SWISH) provides an enviable collection of research tools for the conduct of heath and social science research. The starting point for SWISH is the integrated data catalogue, which provides an ideal access point for finding and exploring spatial data available through SWISH.

Once data are discovered, the researcher then has the capacity to readily access the relevant spatial data through the SWISH Extreme Weather Events database (EWEDB). The integration of the Postgres/PostGIS database and Geoserver web service for visualisation, along with the streamlined access to the spatial data through the Rstudio server environment, enable the integration of geospatial data with other survey and administrative data sources.

This integration capability allows us to easily bring together data sources that have not previously been considered in common, due to the level of knowledge required, covering multiple disciplines and research methods. In the example presented here, we provide a simple analysis of the distribution of drought across NSW in 2006, derived from Bureau of Meteorology data, and the vote for the Liberal Party in the same electorates in 2010, drawn from the Australian Electoral Commission election results website. The correlation between the level of drought in 2006 and voting behaviour in 2010 is then shown in the concluding figure.

The integration of the system with GitHub, the DDIIndex data catalogue and the SWISH data registry system also enable the research to be fully documented, published and then available for reanalysis, further demonstrating the potential of the system for supporting reproducible research. All of the analysis presented here is available through the project GitHub repository.

While the analysis is exploratory only, the use of the SWISH system shows the ease with which multiple data sources can be brought together, and hence to be able to answer more complex research questions, and at increasingly specific levels of geography. Using this system, researchers might then consider the effects of weather patterns on social phenomena, such as the relationship between seasonal weather patterns and depression within local government areas, or extreme weather events and social media use. I look forward to using this system further in future.

Dr. Steven McEachern
Deputy Director
Australian Data Archive
Australian National University
Ph. +61 2 6125 2200
http://www.ada.edu.au
28 September 2012

PostGIS utils on windows

2013-04-15T00:00:00+00:00

The SWISH EWEDB server is a postgres database with the PostGIS add-on. Some of our tools require that the local client computer has some postgres software, but we don’t need you to actually install anything. An easy way to get these tools to work (especially for windows users) is to:

1 download the zips from the links below:

http://www.enterprisedb.com/products-services-training/pgbindownload

http://download.osgeo.org/postgis/windows/pg92/postgis-pg92-binaries-2.0.2w64.zip

2 and unzip them, putting the files into:

C:\pgutils

A tutorial with screenshots to make use of the GIS features of the EWEDB will follow in the future.

Kepler Actors with R on Linux

2013-04-12T00:00:00+00:00

The design of the SWISH Kepler actors is to take files and create files.

If data is passed between actors then temporary files are created in the temporary directory after each actor completes, and are fed to the subsequent actors.

For the R actors, on windows this is achieved using the TEMP environment variable. On linux this might not exist.

This can be created by adding the following line to /usr/lib/R/etc/Rprofile.site

Sys.setenv(TEMP = "/tmp")

QuantumGIS and PostGIS

2013-04-09T00:00:00+00:00

Introduction

This post is explains how to get spatial data from a PostGIS server using QuantumGIS (QGIS).

Method

Open up QGIS “Add PostGIS Layers”.

Click “New” and enter the details as shown, if “Test” is OK then hit “OK”.

Note that the options to “only look in geometry_columns” and “use estimated metadata” may speed up communications from the server, but in some cases restrict access to the full list of available tables. Experiment with these settings by hitting “Edit” and modifying as suits.

PS The first time you set up the connection there will be a warning about saving your password. Take a moment to consider the risk this poses to data.

Select the layer(s) from this list.

Right click on the layer and select “Save as”.

Browse to the local folder to store the data in, and give the shapefile a name.

Conclusion

This is an appropriate method to download a single vector layer at a time. If a raster layer is needed or if a bulk download of many vector layers is desired, then other tools called “pgsql2shp” and “readGDAL” are more efficient. A future post will describe these methods, and SWISH Kepler Actors that we build to perform these tasks.

Australian Water Availability Grids tools

2013-03-21T00:00:00+00:00

A new SWISH R package to download and format gridded weather data from the Bureau of meteorology can be downloaded from downloaded from this page

SWISH Kepler Actors installer

2013-02-20T00:00:00+00:00

The SWISH Kepler Actors we have built enable users to include Stata programs (http://www.stata.com/) into Kepler workflow.

These actors currently work with Stata 12 in Windows environments.

We provide a installer that makes the SWISH Kepler Actors available for use in Kepler. It is fully described and can be downloaded from this page

To run the installer double click the “Install” shortcut, to remove use the “Uninstall” shortcut.

The installed actors appear in Kepler components panel located on the left of the main Kepler window. In Kepler the actors can be dragged and dropped onto the canvas, and linked to other actors to create workflows.

The source code for SWISH Kepler Actors is available at

https://github.com/swish-climate-impact-assessment/swish-kepler-actors

SWISH tools added

2012-12-18T00:00:00+00:00

Two tools have been added to the SWISH-Climate-Impact-Assessments project.

They are described and downloadable from this page

More documentation on the use of these tools in Climate Impact Assessment Workflows will follow soon.

Hutchinson Drought Index Fixed

2012-10-02T00:00:00+00:00

The Hutchinson Drought Index algorithm repository is set up to download data from an online dataset for use as an example.

Unfortunately the Bureau of Meteorology has recently changed the URLs for these datasets.

The code available from author Ivan Hanigan’s github account is now updated to account for these changes.

New analysis added - Drought and election results

2012-09-28T00:00:00+00:00

A new data analysis project has been added to SWISH.

In this analysis authors Steven McEachern and Ivan Hanigan explore the hypothesis that Australians are more likely to vote for conservative political parties during droughts.

To check out the Repo go to This Website https://github.com/ivanhanigan/aec_analysis to clone it.

High level system description now available

2012-09-27T00:00:00+00:00

The High Level System Description Document for the Scientific Workflow and Integration Software for Health (SWISH) project is now available.

The project is designed to support climate impact assessment on Human Health. SWISH tools will include methods to chain together tasks that perform operations in the domains of:

data acquisition,
data transformation,
mathematical operations,
graphing,
statistical analysis, and
output.

It will include both an operational web-based research platform as well as enhance traditional desktop client-side workflows, so that it boosts capacity without compromising expertise and trusted workflows. The software ecosystem is summarised in the image below, and fully described at this page Click Here

The first demonstration of the system will be the creation of an online validated Extreme Weather Events (EWE) database from historical data that can be queried repeatedly, easily and effectively.

This will be merged with Health, Population and Climate Change scenario data to project future health impacts; and the impact assessment will be able to be easily updated with future additional health, population and weather data; or new Climate Change model versions.

SWISH is funded by the Australian National Data Service

What Does Access Get You?

2012-09-26T00:00:00+00:00

Once you have applied for and been approved access you will be asked to fill out a Data Management Plan Checklist and then the relationship with the SWISH project is enshrined in a provision agreement.

Rstudio for analysis
The ddiindex catalogue for finding data
The PostGIS database = psql –h 115.146.94.209 –d ewedb –U username
The data registry is available for power users when contributing data

The geoserver is not restricted for analysts so you can just point QGIS WFS tool at this URL

Access is limited to a finite period and set to expire on a predetermined date, we can offer near-offline storage on our servers for a period and then archive to a data repository such as the Australian Data Archives.

Scheduled Downtime Sat 29 Sept

2012-09-18T00:00:00+00:00

The EWE-DB GIS server will be offline on Saturday 29th September for upgrades.

Data Management Plan and Softare Development Paradigm

2012-09-15T00:00:00+00:00

The Extreme Weather Events Database consists of two linked servers and a Github repository. The servers will be dedicated to two symbiotic systems for firstly storing and accessing the data, and second for analyses.

The first server is a GIS database.
The software stack will include:

A PostGIS server
geoserver

The second server will combine analytical software with a data registry and searchable catalogue.

Rstudio server
an Oracle Express APEX HTML Database
a DDIindex searchable data catalogue

All data and software available from our site are free or open source. This means any health scientist (academic, public servant, emergency aid worker or student), anywhere in the world can freely access these data and tools.
As it is open source development, and can be freely modified, it is hoped that with little modification this software could be used by others to enhance our understanding of the impact of Extreme Weather Events on Health, improve the speediness of action against impending threats, and increase our ability to adapt to or avoid the harmful consequences of Climate Change.

Hello World

2012-09-14T00:00:00+00:00

This is the Extreme Weather Events (EWE) database that accompanies the project ‘Scientific Workflow and Integration Software for Health - Climate Impacts Assessment’, or SWISH for short http://swish-climate-impact-assessment.blogspot.com.au/.

We are funded by the Australian National Data Service (ANDS).

The project is to build a Scientific Workflow System for Assessing and Projecting the Health Impacts of Extreme Weather Events.

About this site

This server hosts a PostGIS database with the results of the algorithms we develop to describe EWE.
The data are available for spatial and temporal queries - and download for integration with health data.

The project will probably result in a database with around 50GB of preprocessed extreme weather event data and some spatial data related to zones of the population census. The access will be restricted to bona fide researchers investigating links between extreme weather and human health. We envisage only a small number of researchers will be accessing these data.

Other uses of this site

This website can also server to host detailed explanations of the algorithms and tutorials on how to access the data.