Many geoscientists utilize a desktop GIS that consumes spatial data in a variety of formats - both proprietary and open-source. Many of these formats are standalone files that rely on an internal database structure that can be joined with other data layers for multivariate analyses (e.g. - ESRI shapefiles and Google KML files). Others are full-blown relational databases that offer increased performance, compression capabilities, spatial indexing, and fewer naming and size limitations (e.g. - ESRI Geodatabases and Oracle Spatial or DataBlades extensions). Given the variety of options and diversity of stakeholders - from different engineering firms to state surveys to planning commissions and more - interoperability is often an incredible challenge. Utilizing a flexible and open-source relational database allows users to enter the post GIS world described by Paul Ramsey (2011). A point where multivariate spatial analyses are possible within a spatially-enabled database without the need for a traditional GIS desktop visualization. PostGIS is a spatial extension for the PostgresSQL database that offers a viable solution for many interoperability issues while offering increased performance, flexible database management and the power of complex relational queries using Structure Query Language (SQL). PostGIS can be used on individual computers, accessed from a single intranet-based server and more recently using cloud solutions such as CartoDB and Amazon’s Relational Database Services. Migrating public datasets from proprietary formats into a more flexible open-access database not only better serves all stakeholders but offers improved performance, more advanced (and faster) queries and multi-version concurrency control (MVCC), which often is not available in standard GIS software packages. The availability of ready-to-use out of the box installations will likely facilitate this migration and result in increase use of this incredibly powerful spatial extension.

1. ENVISIONING A GEOLOGIC DATABASE
UTOPIA: IS LIFE IN A POST GIS – OR
POSTGIS – WORLD ANY BETTER?
John Van Hoesen
Associate Professor, Green Mountain College
http://j-vh.me/PMwRrN

2. http://j-vh.me/PMFqmn
- Thierry Gregorius

3. COMPLAINTS
• Proliferation of data formats
• Interoperability
• Conversion tools
• Multitude of data sources
• Complexity of interfaces
• Required add-ons
• Lack of flexible data models
• Analytical tools for ‘messy’ data
*.shp, *.kml, *.csv, *.tab,
*.asc, *gdb, *.e00, *.geojson
etc
FME, GDAL, GeoKettle

6. http://j-vh.me/PMIyyG
http://j-vh.me/1jcAqUP

7. http://j-vh.me/OulkfG

8. “How many wells terminate in a
specific bedrock type, are
within 1,000 meters of a
specific fault plane and have a
yield of > 50gpm”

9. http://j-vh.me/1gyvRfJ

14. CREATE VIEW vt_well_buffer AS
SELECT id, ST_BUFFER(geom, 100) AS geom
FROM public.”Wells”;

15. CartoDB:
http://vanhoesenj.cartodb.com/api/v2/sql?q=SELECT * FROM gsa
PGSQL2SHP:
pgsql2shp -f <path to new shapefile> -g <geometry column name>
-h <hostname> -U <username> “<query>"
RASTER2PGSQL:
raster2pgsql raster_options_go_here raster_file
someschema.sometable > out.sql
SPIT or Database Manager:
Export directly

16. http://j-vh.me/1gyutcZ

18. http://j-vh.me/1enz84Z

19. http://j-vh.me/1imPY4P

20. QUESTIONS?