Together with Tore Wig, I have a recent publication in Political Geography, where we show that the quality of local institutions is important in reducing the risk of local conflict violence.
The latest version of the PRIO-GRID is now available at grid.prio.org , featuring several new dimensions and types of data, making it one of the best standardized platforms for visualization and analysis of conflict data.
I have recently published a new spatial dataset, the PRIO-GRID. Primarily the dataset is targeting researchers working with armed conflict. However, the data are also useful for other types of research involving spatial data.
The PRIO-Grid data set is a spatio-temporal grid structure constructed to aid the compilation, management and analysis of spatial data within a time-consistent framework. It consists of quadratic grid cells that jointly cover all terrestrial areas of the world. Each grid cell contains cell-specific information on armed conflicts, socio-economic conditions, ethnic groups, physical attributes, climatic conditions and more. Please see the codebook for a complete overview of all the variables included in the PRIO-GRID dataset.
For more information and download, see:
Disclaimer: I am not sure if this is the quickest way of importing NetCDF files to PostGIS, but it works, and for me that is the most important. If you have any other suggestions for improvements, please post them in the comment field!
In my work we need to combine a lot of spatial data from diverse sources. This includes socio-economic, physical and climatic data. Our latest requirement is to be able to import NetCDF files containing climate model data into our PostGIS database. NetCDF (Network Common Data Format) is a multidimensional spatio-temporal data structure with the usual x, y spatial coordinates and a z coordinate or value in addition to the t variable which represents time since some start date.
Our approach is to read the NetCDF in Python using the Scipy.io NetCDF module. This makes it possible to read the NetCDF file into Python and then output it to PostGIS using the psycopg2 module.
In my daily work I use both vector and raster data and the combination of both. Often, I want to include raster data into our common vector grid. Hence, I often want averaged raster pixel values inside each of the grid cells in our vector grid.
To do this, we need to use both the vector and raster functionality in PostGIS.
In this example i want to calculate the average infant mortality rate pixel value inside each vector grid cell.
One query we use for this is:
SELECT gid, CAST(AVG(((foo.geomval).val)) AS decimal(9,3)) as avgimr FROM (SELECT p.gid, ST_Intersection(r.rast, p.cell) AS geomval FROM imrgrid2p5m r, priogrid_land p WHERE ST_Intersects(p.cell, r.rast)) AS foo WHERE (foo.geomval).val >=0 GROUP BY gid ORDER BY gid;
To explain, we select the vector grid cell’s gid, and the average of (foo.geomval).val FROM the Intersection of the infant mortality raster and the vector grid. Hence, the geomval is a list of each pixels intersection with the vector grid cell. This geomval contain both the actual geometry of this intersection and the value of the pixel. The we apply a where clause of where the cell and raster intersects since the raster is tiled. We also do not want to include negative values (missings) since infant mortality rate is not negative. Then we group the query by the grid cell’s gid since we are aggregating the average pixel value.
Lately I have been trying to find out why my raster decimal values are truncated to integer when polygonizing.
After some research I found out that this is a known bug (http://trac.osgeo.org/postgis/ticket/650), and the problem lies in the GDALPolygonize function. This function is used in PostGIS to convert raster to vector, and since this function do not support decimal values, the values are truncated to integers. Particularly problematic if you are working with a raster with pixel values between min 0 and max 1.
The solution is to use GDAL 1.9dev Subversion from trunk. Hence, you have to compile GDAL 1.9dev yourself, and then recompile PostGIS 2.0.0SVN to include GDAL 1.9dev.
Then, when querying raster to vector with values, you get the correct result.
The below query tests this by querying the average pixel values within a quadratic polygon of 0.5 x 0.5 decimal degree’s.
SELECT gid, AVG((foo.geomval).val)
FROM (SELECT p.gid, ST_Intersection(ST_SetSRID(p.cell,4326), ST_SetSRID(r.rast,4326), 1) AS geomval FROM mountain r, priogrid_land p
WHERE ST_Intersects(ST_SetSRID(p.cell,4326), ST_SetSRID(r.rast,4326),1)) AS foo
WHERE gid = 183230 AND (foo.geomval).val >= 0
GROUP BY gid
ORDER BY gid;
Ever wondered on what is the most appropriate way of backing up and restoring your precious PostGIS database? Or have you experienced errors when restoring your old database backup file?
The solution is, put simple: Do not store your data in the public schema in PostGreSQL!
Paul Ramsey explains more in detail on his blog:
I had to make some minimum bounding circles from a set of points in ArcGIS. After some searching i came across a very useful script by Dan Patterson. Actually it comes as a set of scripts in a toolbox. Ready to be imported into ArcGIS 9.3.
The toolbox has scripts for generating convex hull, minimum area bounding rectangle, minimum area circle and extent polygons.
You find it here.
Somewhat unfamiliar to me is the Natural Earth project, providing free raster and vector data of administrative borders, disputed areas, populated places, urban polygons and water boundaries in addition to much more.
Great for updated maps. For historical shapefiles. Check my post on the cShapes dataset.
From their website:
“We developed Natural Earth as a convenient resource for making custom maps. Unlike other map data intended for scientific analysis or military mapping, Natural Earth is designed to meet the needs of production cartographers using a variety of software applications. Maximum flexibility is a goal.”
Go to Natural Earth Website
Many within the GIS community working on global data are familiar with the Gridded Population of the World (GPW). This global gridded population estimate has now been more available through a web-service. This lets the user zoom around to investigate the data without having to download the rasterdata.
Additionally and more interesting are the population estimation service, that can be accessed through OGC, REST and SOAP interface to estimate the population within a drawn polygon.
One of the new mapping tools also released, based on the technology used by Google Maps, demonstrates the Population Estimation Service. It lets users select an area of interest by drawing a polygon on the map and submit the request to the service, and it displays the results. (CIESIN News)
The google map based Population Estimation Service can be accessed here.