Smathermather's Weblog

Remote Sensing, GIS, Ecology, and Oddball Techniques

Archive for November, 2014

Landscape Position using GDAL — PT 3

Posted by smathermather on November 25, 2014

More landscape position pictures — just showing riparianess. See also

https://smathermather.wordpress.com/2014/11/22/landscape-position-using-gdal/

and

https://smathermather.wordpress.com/2014/11/24/landscape-position-using-gdal-pt-2/

valleyz3 valleyz2 valleyz1 valleyz

Map tiles by Stamen Design, under CC BY 3.0. Data by OpenStreetMap, under ODbL

Posted in Analysis, Ecology, GDAL, Landscape Position, Other, POV-Ray | Tagged: , , , , , , , , , , | Leave a Comment »

Landscape Position using GDAL — PT 2

Posted by smathermather on November 24, 2014

Just pretty pics today of estimated riparianess. If you prefer a bit of code, see previous post https://smathermather.wordpress.com/2014/11/22/landscape-position-using-gdal/

valleys_improved valleys_improved_1 valleys_improved_2 valleys_improved_3 valleys_improved_3.1 valleys_improved_4 valleys_improved_5

Posted in Analysis, Ecology, GDAL, Landscape Position, Other, POV-Ray | Tagged: , , , , , , , , , , | 4 Comments »

Landscape Position using GDAL

Posted by smathermather on November 22, 2014

Hat tip again to Seth Fitzsimmons. I’ve been looking for a good, easy to use smoothing algorithm for rasters. Preferably something so easy, I don’t even need to write a little python, and so efficient I can run it on 30GB+ datasets and have it complete before I get distracted again by the next shiny project (a few hours).

Seth’s solution? Downsample to a low resolution using GDAL, then sample back up to a higher resolution in order to smooth the raster. My innovation to his approach? Use Lanczos resampling to keep location static, and get a great smooth model:

Unsmoothed DEM

Unsmoothed DEM

Smoothed DEM

Smoothed DEM

Code to do this in gdal follows. “-tr” sets our resamping resolution, “-r lanczos” sets our resampling algorithm, and the “-co” flags are not strictly necessary, but I’ve got a 30GB dataset, so it helps to chop up the inside of the TIFF in little squares to optimize subsequent processing.

gdalwarp -tr 50 50 -srcnodata "0 -32767" -r lanczos  -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" oh_leap_dem.tif oh_leap_dem_50.tif
gdalwarp -tr 10 50 -srcnodata "0 -32767" -r lanczos  -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" oh_leap_dem_50.tif oh_leap_dem_10-50.tif

At first this excited me for cartographic reasons. We can use this to simplify contours, and then use simplified contours at different zoom levels for maps:

But, we can also use this for analyses. For example, if we difference these smoothed images with our original digital elevation model, we get a measurement of local elevation difference, the first step in establishing where valleys, ridges, and other land forms are.

# Resample to lower resolution
gdalwarp -tr 328.0523587211646 328.0523587211646 -srcnodata "0 -32767" -r lanczos  -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" oh_leap_dem.tif oh_leap_dem_328.tif
# Upsample again to get nicely smoothed data
gdalwarp -tr 3.048293887897243 3.048293887897243 -srcnodata "0 -32767" -r lanczos  -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" oh_leap_dem_328.tif oh_leap_dem_3-328.tif
# Merge two datasets together into single image as separate bands to ensure they are the same dimensions
# (gdal_calc, as a wrapper for numpy requires this)
gdal_merge -separate -o oh_leap_dem_3-328_m.tif oh_leap_dem.tif oh_leap_dem_3-328.tif
# And now we'll use gdal_calc to difference our elevation model with the smoothed one to get relative elevation 
gdal_calc -A oh_leap_dem_3-328_m.tif -B oh_leap_dem_3-328_m.tif --A_band=1 --B_band=2 --outfile=oh_leap_dem_lp_328.tif --calc="A-B"

So, if we want a good proxy for riparian zones, we can use a technique like this, instead of buffering our streams and rivers a fixed distance (in this case, I’ve used 4 different distances:

Map of landscape position estimated valleys in Cuyahoga County, Ohio

Map of landscape position estimated valleys in Cuyahoga County, Ohio

Pretty snazzy riparian finder. It seems to also find upland headwater wetlands (most of them historic and drained for Cuyahoga County). I am now running on 4 million acres of Ohio at a 10ft (~3 meter) resolution. It’s that efficient.

Addendum: It also finds escarpment edges, like the Portage Escarpment in the above, so it is a mix of a few landforms. Darn handy nonetheless.

Posted in Analysis, Ecology, GDAL, Landscape Position, Other, POV-Ray | Tagged: , , , , , , , , , , | 2 Comments »

Quick (and likely apocryphal) post on versioning and databases

Posted by smathermather on November 15, 2014

This is a quick blog post about technologies that I don’t know well… so please comment if you know better. GeoGig and dat are great tools for addressing versioning in data, so what’s the difference?

Screen shot of GeoGig website

GeoGig is built on Java and meant for any “simple features” geometry (points, lines, polygons).

It’s strength is that it is built from the ground up to handle geometries well, going beyond CRUD functions to specifically address geospatial problems in versioning. Think of it as git for geospatial data.

There’s a hosted version in pre-release from BoundlessGeo called Versio and meant to be the GitHub for geospatial data. You can run your local version from http://geogig.org/

From the website:

“Users are able to import raw geospatial data (currently from Shapefiles, PostGIS or SpatiaLite) in to (sic) a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories.”

—————————————————————————
Ok, so how about dat?

Screen shot of dat website

dat is built on javascript, meant to do streaming data and some other cool features and does CRUD versioning. Think of it as git for data built by web people. Therefore, it “defines an API for reading, writing and syncing datasets”, as opposed to a repository into which one would import data.

“Dat is an open source project that provides a streaming interface between every file format and data storage backend.”

A cursory look indicates it will work for geospatial data, but effectively as blobs, with no special handling for changes within features like GeoGig. But, it does what GeoGig does not, and that is to make datasets automatically syncable.

Like all projects, each has its strengths. Choose your project wisely.

Posted in dat, Database, GeoGig, git, Versio | Tagged: , , , , | 9 Comments »

ICCM — International Conference of Crisis Mappers

Posted by smathermather on November 9, 2014

Screen shot of Crisis Mappers landing page

Screen shot of Crisis Mappers landing page

The mark of a great conference is one that not only is well run and orchestrated, interesting from a content perspective, and full of bright minds, but also one that experiments with elements of interactions to maximize the value delivered to attendees. By these measures, the International Conference of Crisis Mappers (ICCM) succeeds. Normally, I struggle with the call to attend sessions vs. the conference hallway conversations which can be of such great value. ICCM provided enough context and structure for enjoying both, plus a number of other participatory structures in which to interact with and learn from other ICCM attendees.

For attending ICCM, I had plans to only hallway chat about http://OpenDroneMap.org, in order to get a measure of the culture and needs, and also of the interest for such a project from digital humanitarians in an effort to get enough interest to begin to garnish users and contributors. Thanks to some last minute slots opening up, and on the kind recommendation of Jen Ziemke, I was able to show OpenDroneMap at the Tech & Analysis Fair at Google at the start of the conference and also do a well attended deep dive session on Saturday. In each, I got great questions and recommendations, did a brainstorming session on use in the deep dive session, and had a thoroughly great time.

More later, but I will end with this — if you like technology, have empathy and a desire to apply empathetic design, development, and sweat equity to humanitarian needs, then get signed up at http://crisismappers.net, become a participant in HOT, join the Standby Task Force, and / or all the other work done by digital humanitarians, and make your way to Boston next year for the next ICCM.

Bravo, all.

Posted in 3D, International Conference of Crisis Mappers, OpenDroneMap | Tagged: , , | Leave a Comment »