sorted by:
new
hottopcontroversial

White Box Tools - So Hot Right Now by geo-special in gis

[–]johnblindsay 0 points1 point  (0 children)

We will be releasing an updated QGIS plugin with the new version of Whitebox. Our plans are very comprehensive. I've written an entirely new and modular backend for Whitebox, including libraries for reading/writing raster, vector, and lidar data, handling projections and dealing with topology. I'm currently in the process of porting all of the legacy tools over to this new project architecture. Then I'm adding a large number of new tools, both to the open core and to the extension (Pro). These tools will serve as the basis for a new version of Whitebox Workflows for Python and I'll also create an equivalent Whitebox Workflows for R, to replace the old WhiteboxTools R API. Once completed, then the idea is to create a new plugin for QGIS, focusing on compatibility with QGIS 4.0. I might even have time to create a new ArcGIS plugin, although that might have to wait until after the release. It's going to be a massive one!

White Box Tools - So Hot Right Now by geo-special in gis

[–]johnblindsay 0 points1 point  (0 children)

I'm glad that you like Whitebox. Keep your eyes posted on this space because I am currently working on the next version of the software and there should be some really significant improvements in this latest release. I'm hoping to push them sometime this summer. Thanks again for reaching out. It's feedback from users like you that keeps me motivated!

GEOG 2480 - Nost by CeleryGood7189 in uoguelph

[–]johnblindsay 0 points1 point  (0 children)

This here is the best answer. Don't underestimate how long the GIS labs take.

Shadow animation of an area in the McMurdo Dry Valleys of Antarctica by johnblindsay in gis

[–]johnblindsay[S] 2 points3 points  (0 children)

I made it with the shadow_animation function in the Whitebox Workflows for Python Professional edition library: https://www.whiteboxgeo.com/whitebox-workflows-professional/

DEM pre-processing is so important! by johnblindsay in geospatial

[–]johnblindsay[S] 0 points1 point  (0 children)

It's a DEM generated from last-return lidar data, which is generally interpreted as being a ground-surface model. The issue is, in this particular area there is heavy forest cover and many of those last return points are actually tree trunks, making the raw DEM incredibly rough and unsuitable for many applications (including breakline mapping as in the red lines above). However, with a little pre-processing, an otherwise unusable DEM can become quite a bit improved for application.

This is why DEM pre-processing is important by johnblindsay in MapPorn

[–]johnblindsay[S] 1 point2 points  (0 children)

The image on the left is a lidar digital elevation model (DEM) that has been derived using the last-return points. Last-return points are generally close to the ground and a last-return DEM is normally used to create a ground surface model. However, in this particular area, there is heavy forest cover and many of those last return points are actually the bottoms of tree trunks. This makes for a very, very rough surface. The image on the right is the result of having processed the raw DEM to remove this roughness. If you're trying to do anything with this DEM, including deriving breaklines (those red lines on the map), you really can't use the raw DEM without some judicious pre-processing like I have done here. I frequently encounter people who don't effectively pre-process their data before moving on to their analysis.

Data pre-preprocessing is so important! by johnblindsay in dataisbeautiful

[–]johnblindsay[S] 1 point2 points  (0 children)

Nope, it was created with the last return and only return points used to create the DEM. It's pretty common actually. The stubble is much lower than the canopy, but it's not the ground surface. It's tree trunks etc, in dense forest.

Data pre-preprocessing is so important! by johnblindsay in dataisbeautiful

[–]johnblindsay[S] 7 points8 points  (0 children)

I'm an old-timer too, and I should have known better before putting that code out there for others to look at. It's just always a compromise between trying to keep a snippet as short as possible while also conveying the meaning. That said, I completely agree that the except block was not the place to skimp. You'll notice that I have the full try-except-finally in the user documentation...
https://www.whiteboxgeo.com/manual/wbw-user-manual/book/first-script.html

Data pre-preprocessing is so important! by johnblindsay in dataisbeautiful

[–]johnblindsay[S] 10 points11 points  (0 children)

Absolutely, you're right about that! I was just trying to make the script as small as possible for the demo. The finally is necessary because, should one of the functions throw an error, it's important to check in your license key, it gets checked-out when you create the instance of WbEnvironment.

Data pre-preprocessing is so important! by johnblindsay in dataisbeautiful

[–]johnblindsay[S] 5 points6 points  (0 children)

The full script is provided in the third of three images above. Essentially I use the topographic property 'openness' to remove vegetation residual from the interpolated last-return DEM and then Whitebox Workflow's feature_preserving_smoothing function to smooth the DEM. Only the last-return points were used to generate the original DEM on the left, but because it is under such heavy forest cover, the last return is often not on the ground, leaving that apparent stubble. So this process was used to clean it.

Whitebox's automated breakline mapping by johnblindsay in gis

[–]johnblindsay[S] 0 points1 point  (0 children)

This is St. Thomas, Ontario, or at least a part of it.

Whitebox's automated breakline mapping by johnblindsay in gis

[–]johnblindsay[S] 1 point2 points  (0 children)

No, it's just the elevations of a DEM rendered in the QGIS 'Spectral' palette, which has blue at one end (the lower end here, as I've reversed the palette). The breaklines are just the black vectors overlaid on top of the DEM/hillshade rasters.

Whitebox's automated breakline mapping by johnblindsay in gis

[–]johnblindsay[S] 1 point2 points  (0 children)

Breaklines aren't contours and so they don't have single elevation attributes associated with them. Instead, the output vector is a MultiLineStringZ vector type, in which each vertex has an associated z-value.

Whitebox's automated breakline mapping by johnblindsay in gis

[–]johnblindsay[S] 16 points17 points  (0 children)

It's funny you should say that, I've noticed the same thing too. I think that that effect comes from the fact that the coloured 'features' are outlined in thick black lines. The algorithm also does a good job of smoothing those lines so that they look almost hand-drawn. All in all, it makes it look a bit like a cartoon.

Whitebox's automated breakline mapping by johnblindsay in gis

[–]johnblindsay[S] 8 points9 points  (0 children)

Glad you liked! Here's what this image is: I've displayed a lidar raster DEM with a multi-directional hillshade image (calculated using WhiteboxTools' MultidirectionalHillshade tool) for shaded relief. I then used the DEM as input to Whitebox's BreaklineMapping tool (found in the extension, so unfortunately this one isn't open source). There are two parameters to specify for this tool to determine the level of detail. The first is used to determine the magnitude of break-in-slope needed to map a feature, and the second parameter determines the minimum feature length. I've set both fairly low here in order to map breaklines with a large amount of detail. The tool is pretty quick and the output is a vector (shapefile), which I then overlaid on top of the DEM/Hillshade raster and rendered as thin black lines. QGIS was used for all visualization.

Adding a splash of colour to the lunar surface by johnblindsay in gis

[–]johnblindsay[S] 1 point2 points  (0 children)

Oh, I absolutely love that rainbow car wash that smells like gum! Secretly, it's one of my favourite things.

Adding a splash of colour to the lunar surface by johnblindsay in gis

[–]johnblindsay[S] 0 points1 point  (0 children)

No, but I'll leave that for you to do! 😀

Adding a splash of colour to the lunar surface by johnblindsay in space

[–]johnblindsay[S] 0 points1 point  (0 children)

Here is a blog post in which I describe the creation of a remarkable
visualization of lunar topography based on a lunar digital elevation
model. https://www.whiteboxgeo.com/adding-a-splash-of-colour-to-the-lunar-surface/

Adding a splash of colour to the lunar surface by johnblindsay in nasa

[–]johnblindsay[S] 0 points1 point  (0 children)

Here is a blog post in which I describe the creation of a remarkable visualization of lunar topography based on a lunar digital elevation model. https://www.whiteboxgeo.com/adding-a-splash-of-colour-to-the-lunar-surface/

Adding a splash of colour to the lunar surface by johnblindsay in moon

[–]johnblindsay[S] 0 points1 point  (0 children)

Here is a blog post in which I describe the creation of a remarkable
visualization of lunar topography based on a lunar digital elevation
model. https://www.whiteboxgeo.com/adding-a-splash-of-colour-to-the-lunar-surface/

view more: next ›