More landscape position pictures — just showing riparianess. See also
Posted by smathermather on November 25, 2014
More landscape position pictures — just showing riparianess. See also
Posted in Analysis, Ecology, GDAL, Landscape Position, Other, POV-Ray | Tagged: Analysis, DEM, Digital Surface Model, Ecological Land Type, Ecological Modeling, FOSS, GDAL, LiDAR, Technical, Topographic Classification, Topographic Position | Leave a Comment »
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/
Posted in Analysis, Ecology, GDAL, Landscape Position, Other, POV-Ray | Tagged: Analysis, DEM, Digital Surface Model, Ecological Land Type, Ecological Modeling, FOSS, GDAL, LiDAR, Technical, Topographic Classification, Topographic Position | 4 Comments »
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:
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:
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: Analysis, DEM, Digital Surface Model, Ecological Land Type, Ecological Modeling, FOSS, GDAL, LiDAR, Technical, Topographic Classification, Topographic Position | 2 Comments »
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?
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.
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?
“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 by smathermather on November 9, 2014
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.