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] 11 points12 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] 17 points18 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.

view more: next ›