An advanced geospatial data analysis platform

Overview

Bringing the power of Whitebox GAT to the world at large

This page is related to the stand-alone command-line program and Python scripting API for geospatial analysis, WhiteboxTools. If you are instead interested in the open-source GIS, Whitebox GAT, please see this link.

The official WhiteboxTools User Manual can be found at this link.

Contents

  1. Description
  2. Downloads and Installation
  3. Usage
  4. Available Tools
  5. Supported Data Formats
  6. Contributing
  7. License
  8. Reporting Bugs
  9. Known Issues
  10. Frequently Asked Questions

1 Description

WhiteboxTools is an advanced geospatial data analysis platform developed by Prof. John Lindsay (webpage; jblindsay) at the University of Guelph's Geomorphometry and Hydrogeomatics Research Group. WhiteboxTools can be used to perform common geographical information systems (GIS) analysis operations, such as cost-distance analysis, distance buffering, and raster reclassification. Remote sensing and image processing tasks include image enhancement (e.g. panchromatic sharpening, contrast adjustments), image mosaicing, numerous filtering operations, simple classification (k-means), and common image transformations. WhiteboxTools also contains advanced tooling for spatial hydrological analysis (e.g. flow-accumulation, watershed delineation, stream network analysis, sink removal), terrain analysis (e.g. common terrain indices such as slope, curvatures, wetness index, hillshading; hypsometric analysis; multi-scale topographic position analysis), and LiDAR data processing. LiDAR point clouds can be interrogated (LidarInfo, LidarHistogram), segmented, tiled and joined, analyized for outliers, interpolated to rasters (DEMs, intensity images), and ground-points can be classified or filtered. WhiteboxTools is not a cartographic or spatial data visualization package; instead it is meant to serve as an analytical backend for other data visualization software, mainly GIS.

Although WhiteboxTools is intended to serve as a source of plugin tools for the Whitebox GAT open-source GIS project, the tools contained in the library are stand-alone and can run outside of the larger Whitebox GAT project. See Usage for further details. There have been a large number of requests to call Whitebox GAT tools and functionality from outside of the Whitebox user-interface (e.g. from Python automation scripts). WhiteboxTools is intended to meet these usage requirements. Eventually most of the approximately 400 tools contained within Whitebox GAT will be ported to WhiteboxTools. In addition to separating the processing capabilities and the user-interface (and thereby reducing the reliance on Java), this migration should significantly improve processing efficiency. This is because Rust, the programming language used to develop WhiteboxTools, is generally faster than the equivalent Java code and because many of the WhiteboxTools functions are designed to process data in parallel wherever possible. In contrast, the older Java codebase included largely single-threaded applications.

The WhiteboxTools project is related to the GoSpatial project, which has similar goals but is designed using the Go programming language instead of Rust. WhiteboxTools has however superseded the GoSpatial project, having subsumed all of its functionality.

2 Downloads and Installation

Pre-compiled binaries

WhiteboxTools is a stand-alone executable command-line program with no actual installation. If you intend to use the Python programming interface for WhiteboxTools you will need to have Python 3 (or higher) installed. Pre-compiled binaries can be downloaded from the Geomorphometry and Hydrogeomatics Research Group software web site for various supported operating systems.

Building from source code

It is likely that WhiteboxTools will work on a wider variety of operating systems and architectures than the distributed binary files. If you do not find your operating system/architecture in the list of available WhiteboxTool binaries, then compilation from source code will be necessary. WhiteboxTools can be compiled from the source code with the following steps:

  1. Install the Rust compiler; Rustup is recommended for this purpose. Further instruction can be found at this link.

  2. Download the WhiteboxTools source code. To download the code, click the green Clone or download button on the GitHub repository site. Alternatively, if you have Git installed on your computer, you can use the following command to clone the repository, then skip to step 4.

>> git clone https://github.com/jblindsay/whitebox-tools.git
  1. Decompress the zipped download file.

  2. Open a terminal (command prompt) window and change the working directory to the whitebox-tools folder:

>> cd /path/to/folder/whitebox-tools/
  1. Finally, use the rust package manager Cargo, which will be installed along with Rust, to compile the executable:
>> cargo build --release

Depending on your system, the compilation may take several minutes. When completed, the compiled binary executable file will be contained within the whitebox-tools/target/release/ folder. Type ./whitebox_tools --help at the command prompt (after cd'ing to the containing folder) for information on how to run the executable from the terminal.

Be sure to follow the instructions for installing Rust carefully. In particular, if you are installing on MS Windows, you must have a linker installed prior to installing the Rust compiler (rustc). The Rust webpage recommends either the MS Visual C++ 2015 Build Tools or the GNU equivalent and offers details for each installation approach. You should also consider using RustUp to install the Rust compiler.

Using Docker image

For these who don't want to build from sources or can not use pre-build binaries there is also a Docker container that runs Whitebox Tools.

To build the image do:

  1. clone Whitebox Tools repository to your local system or download code archive from the GitHub

    git clone https://github.com/jblindsay/whitebox-tools.git
    
  2. Open a terminal (command prompt) window and change the working directory to the whitebox-tools folder

    cd /path/to/folder/whitebox-tools/
    
  3. Build container

    docker build -t whitebox-tools -f docker/whitebox-tools.dockerfile .
    
  4. Depending on your system, the build process may take several minutes. When completed, new image called whitebox-tool will be created.

To use container it is necessary to bind mount data directory into container as /data and then pass required command-line arguments, like below

docker run --rm -it -v "/path/to/data/directory/":/data whitebox-tools --run=IntegralImage -i=dem.tif -o=out.tif

3 Usage

WhiteboxTools is a command-line program and can be run either by calling it, with appropriate commands and arguments, from a terminal application, or, more conveniently, by calling it from a script. The following commands are recognized by the WhiteboxTools library:

Command Description
--cd, --wd Changes the working directory; used in conjunction with --run flag.
-h, --help Prints help information.
-l, --license Prints the whitebox-tools license.
--listtools Lists all available tools, with tool descriptions. Keywords may also be used, --listtools slope.
-r, --run Runs a tool; used in conjunction with --cd flag; -r="LidarInfo".
--toolbox Prints the toolbox associated with a tool; --toolbox=Slope.
--toolhelp Prints the help associated with a tool; --toolhelp="LidarInfo".
--toolparameters Prints the parameters (in json form) for a specific tool; --toolparameters="LidarInfo".
-v Verbose mode. Without this flag, tool outputs will not be printed.
--viewcode Opens the source code of a tool in a web browser; --viewcode="LidarInfo".
--version Prints the version information.

Generally, the Unix convention is that single-letter arguments (options) use a single hyphen (e.g. -h) while word-arguments (longer, more descriptive argument names) use double hyphen (e.g. --help). The same rule is used for passing arguments to tools as well. Use the --toolhelp argument to print information about a specific tool (e.g. --toolhelp=Clump). Tool names can be specified either using the snake_case or CamelCase convention (e.g. lidar_info or LidarInfo).

For examples of how to call functions and run tools from WhiteboxTools, see the whitebox_example.py Python script, which itself uses the whitebox_tools.py script as an interface for interacting with the executable file.

In addition to direct command-line and script-based interaction, a very basic user-interface called WB Runner can be used to call the tools within the WhiteboxTools executable file, providing the required tool arguments.

Example command prompt:

>>./whitebox_tools --wd='/Users/johnlindsay/Documents/data/' --run=DevFromMeanElev
--input='DEM clipped.dep' --output='DEV raster.dep' -v

Notice the quotation marks (single or double) used around directories and filenames, and string tool arguments in general. Use the '-v' flag (run in verbose mode) to force the tool print output to the command prompt. Please note that the whitebox_tools executable file must have permission to be executed; on some systems, this may require setting special permissions. The '>>' is shorthand for the command prompt and is not intended to be typed. Also, the above example uses the forward slash character (/), the directory path separator used on unix based systems. On Windows, users should use the back slash character (\) instead.

Example Python script:

The following script relies on the imported functions contained within the whitebox_tools.py script, included within the WhiteboxTools distribution folder, and can be run using Python 3. Please note that all of the scripts included with WhiteboxTools assumes the user system is configured with Python 3 and may not run as expected using Python 2.

import os
import sys
from whitebox_tools import WhiteboxTools

wbt = WhiteboxTools()

# If the WhiteboxTools executable file (whitbox_tools.exe) is not in the same
# directory as this script, its path will need to be set, e.g.:
wbt.set_whitebox_dir(os.path.dirname(
    os.path.abspath(__file__)) + "/target/release/")  # or simply wbt.exe_path = ...

# Set the working directory. This is the path to the folder containing the data,
# i.e. files sent to tools as input/output parameters. You don't need to set
# the working directory if you specify full path names as tool parameters.
wbt.work_dir = os.path.dirname(os.path.abspath(__file__)) + "/testdata/"

# Sets verbose mode (True or False). Most tools will suppress output (e.g. updating
# progress) when verbose mode is False. The default is True
# wbt.set_verbose_mode(False) # or simply, wbt.verbose = False

# The most convenient way to run a tool is to use its associated method, e.g.:
wbt.elev_percentile("DEM.tif", "output.tif", 15, 15)
# You may also provide an optional custom callback for processing output from the
# tool. If you don't provide a callback, and verbose is set to True, tool output
# will simply be printed to the standard output.

# Prints the whitebox-tools help...a listing of available commands
print(wbt.help())

# Prints the whitebox-tools license
print(wbt.license())

# Prints the whitebox-tools version
print("Version information: {}".format(wbt.version()))

# List all available tools in whitebox-tools
print(wbt.list_tools())

# Lists tools with 'lidar' or 'LAS' in tool name or description.
print(wbt.list_tools(['lidar', 'LAS']))

# Print the help for a specific tool.
print(wbt.tool_help("ElevPercentile"))
# Notice that tool names within WhiteboxTools.exe are CamelCase but
# you can also use snake_case here, e.g. print(wbt.tool_help("elev_percentile"))

WhiteboxTools Runner

There is a Python script contained within the WhiteboxTools directory called 'wb_runner.py'. This script is intended to provide a very basic user-interface for running the tools contained within the WhiteboxTools library. The user-interface uses Python's TkInter GUI library and is cross-platform. The user interface is currently experimental and is under heavy testing. Please report any issues that you experience in using it.

WhiteboxTools Runner user-interface

The WhiteboxTools Runner does not rely on the Whitebox GAT user interface at all and can therefore be used indepedent of the larger project. The script must be run from a directory that also contains the 'whitebox_tools.py' Python script and the 'whitebox_tools' executable file. There are plans to link tool help documentation in WhiteboxTools Runner.

4 Available Tools

Eventually most of Whitebox GAT's approximately 430 tools will be ported to WhiteboxTools, although this is an immense task. Support for vector data (Shapefile/GeoJSON) reading/writing and a topological analysis library (like the Java Topology Suite) will need to be added in order to port the tools involving vector spatial data. Opportunities to parallelize algorithms will be sought during porting. All new plugin tools will be added to Whitebox GAT using this library of functions.

The library currently contains more than 397 tools, which are each grouped based on their main function into one of the following categories: Data Tools, GIS Analysis, Hydrological Analysis, Image Analysis, LiDAR Analysis, Mathematical and Statistical Analysis, Stream Network Analysis, and Terrain Analysis. For a listing of available tools, complete with documentation and usage details, please see the WhiteboxTools User Manual.

To retrieve detailed information about a tool's input arguments and example usage, either use the --toolhelp command from the terminal, or the tool_help('tool_name') function from the whitebox_tools.py script.

5 Supported Data Formats

The WhiteboxTools library can currently support read/writing raster data in Whitebox GAT, GeoTIFF, ESRI (ArcGIS) ASCII and binary (.flt & .hdr), GRASS GIS, Idrisi, SAGA GIS (binary and ASCII), and Surfer 7 data formats. The library is primarily tested using Whitebox raster data sets and if you encounter issues when reading/writing data in other formats, you should report the issue. Please note that there are no plans to incorporate third-party libraries, like GDAL, in the project given the design goal of keeping a pure (or as close as possible) Rust codebase.

At present, there is limited ability in WhiteboxTools to read vector geospatial data. Support for Shapefile (and other common vector formats) will be enhanced within the library soon.

LiDAR data can be read/written in the common LAS data format. WhiteboxTools can read and write LAS files that have been compressed (zipped with a .zip extension) using the common DEFLATE algorithm. Note that only LAS file should be contained within a zipped archive file. The compressed LiDAR format LAZ and ESRI LiDAR format are not currently supported by the library. The following is an example of running a LiDAR tool using zipped input/output files:

>>./whitebox_tools -r=LidarTophatTransform -v --wd="/path/to/data/"
-i="input.las.zip" -o="output.las.zip" --radius=10.0

Note that the double extensions (.las.zip) in the above command are not necessary and are only used for convenience of keeping track of LiDAR data sets (i.e. .zip extensions work too). The extra work of decoding/encoding compressed files does add additional processing time, although the Rust compression library that is used is highly efficient and usually only adds a few seconds to tool run times. Zipping LAS files frequently results 40-60% smaller binary files, making the additional processing time worthwhile for larger LAS file data sets with massive storage requirements.

6 Contributing

If you would like to contribute to the project as a developer, follow these instructions to get started:

  1. Fork the larger Whitebox project (in which whitebox-tools exists) ( https://github.com/jblindsay/whitebox-geospatial-analysis-tools )
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create a new Pull Request

Unless explicitly stated otherwise, any contribution intentionally submitted for inclusion in the work shall be licensed as above without any additional terms or conditions.

If you would like to contribute financial support for the project, please contact John Lindsay. We also welcome contributions in the form of media exposure. If you have written an article or blog about WhiteboxTools please let us know about it.

7 License

The WhiteboxTools library is distributed under the MIT license, a permissive open-source (free software) license.

8 Reporting Bugs

WhiteboxTools is distributed as is and without warranty of suitability for application. If you encounter flaws with the software (i.e. bugs) please report the issue. Providing a detailed description of the conditions under which the bug occurred will help to identify the bug. Use the Issues tracker on GitHub to report issues with the software and to request feature enchancements. Please do not email Dr. Lindsay directly with bugs.

9 Known Issues

  • Given the extreme complexity of the GeoTIFF file format, and the fact that the project uses a custom, stand-alone GeoTIFF library, it is likely that some users will encounter limitations (e.g. the BigTIFF format is currently unsupported) or bugs.
  • There is limited support for reading, writing, or analyzing vector data yet. Plans include native support for the ESRI Shapefile format and possibly GeoJSON data.
  • The LAZ compressed LiDAR data format is currently unsupported although zipped LAS files (.zip) are.
  • File directories cannot contain apostrophes (', e.g. /John's data/) as they will be interpreted in the arguments array as single quoted strings.
  • The Python scripts included with WhiteboxTools require Python 3. They will not work with Python 2, which is frequently the default Python version installed on many systems.

10 Frequently Asked Questions

Do I need Whitebox GAT to use WhiteboxTools?

No you do not. You can call the tools contained within WhiteboxTools completely independent from the Whitebox GAT user interface using a Remote Procedure Call (RPC) approach. In fact, you can interact with the tools using Python scripting or directly, using a terminal application (command prompt). See Usage for further details.

How do I request a tool be added?

Eventually most of the tools in Whitebox GAT will be ported over to WhiteboxTools and all new tools will be added to this library as well. Naturally, this will take time. The order by which tools are ported is partly a function of ease of porting, existing infrastructure (i.e. raster and LiDAR tools will be ported first since their is currently no support in the library for vector I/O), and interest. If you are interested in making a tool a higher priority for porting, email John Lindsay.

Can WhiteboxTools be incorporated into other software and open-source GIS projects?

WhiteboxTools was developed with the open-source GIS Whitebox GAT in mind. That said, the tools can be accessed independently and so long as you abide by the terms of the MIT license, there is no reason why other software and GIS projects cannot use WhiteboxTools as well. In fact, this was one of the motivating factors for creating the library in the first place. Feel free to use WhiteboxTools as the geospatial analysis engine in your open-source software project.

What platforms does WhiteboxTools support?

WhiteboxTools is developed using the Rust programming language, which supports a wide variety of platforms including MS Windows, MacOS, and Linux operating systems and common chip architectures. Interestingly, Rust also supports mobile platforms, and WhiteboxTools should therefore be capable of targeting (although no testing has been completed in this regard to date). Nearly all development and testing of the software is currently carried out on MacOS and we cannot guarantee a bug-free performance on other platforms. In particularly, MS Windows is the most different from the other platforms and is therefore the most likely to encounter platform-specific bugs. If you encounter bugs in the software, please consider reporting an issue using the GitHub support for issue-tracking.

What are the system requirements?

The answer to this question depends strongly on the type of analysis and data that you intend to process. However, generally we find performance to be optimal with a recommended minimum of 8-16GB of memory (RAM), a modern multi-core processor (e.g. 64-bit i5 or i7), and an solid-state-drive (SSD). It is likely that WhiteboxTools will have satisfactory performance on lower-spec systems if smaller datasets are being processed. Because WhiteboxTools reads entire raster datasets into system memory (for optimal performance, and in recognition that modern systems have increasingly larger amounts of fast RAM), this tends to be the limiting factor for the upper-end of data size successfully processed by the library. 64-bit operating systems are recommended and extensive testing has not been carried out on 32-bit OSs. See "What platforms does WhiteboxTools support?" for further details on supported platforms.

Are pre-compiled executables of WhiteboxTools available?

Pre-compiled binaries for WhiteboxTools can be downloaded from the Geomorphometry and Hydrogeomatics Research Group software web site for various supported operating systems. If you need binaries for other operating systems/system architectures, you will need to compile the executable from source files. See Installation for details.

Why is WhiteboxTools programmed in Rust?

I spent a long time evaluating potential programming language for future development efforts for the Whitebox GAT project. My most important criterion for a language was that it compile to native code, rather than target the Java virtual machine (JVM). I have been keen to move Whitebox GAT away from Java because of some of the challenges that supporting the JVM has included for many Whitebox users. The language should be fast and productive--Java is already quite fast, but if I am going to change development languages, I would like a performance boost. Furthermore, given that many, though not all, of the algorithms used for geospatial analysis scale well with concurrent (parallel) implementations, I favoured languages that offered easy and safe concurrent programming. Although many would consider C/C++ for this work, I was looking for a modern and safe language. Fortunately, we are living through a renaissance period in programming language development and there are many newer languages that fit the bill nicely. Over the past two years, I considered each of Go, Rust, D, Nim, and Crystal for Whitebox development and ultimately decided on Rust. [See GoSpatial and lidario.]

Each of the languages I examined has its own advantages of disadvantages, so why Rust? It's a combination of factors that made it a compelling option for this project. Compared with many on the list, Rust is a mature language with a vibrant user community. Like C/C++, it's a high-performance and low-level language that allows for complete control of the system. However, Rust is also one of the safest languages, meaning that I can be confident that WhiteboxTools will not contain common bugs, such as memory use-after-release, memory leaks and race conditions within concurrent code. Importantly, and quite uniquely, this safety is achieved in the Rust language without the use of a garbage collector (automatic memory management). Garbage collectors can be great, but they do generally come with a certain efficiency trade-off that Rust does not have. The other main advantage of Rust's approach to memory management is that it allows for a level of interaction with scripting languages (e.g. Python) that is quite difficult to do in garbage collected languages. Although WhiteboxTools is currently set up to use an automation approach to interacting with Python code that calls it, I like the fact that I have the option to create a WhiteboxTools shared library.

Not everything with Rust is perfect however. It is still a very young language and there are many pieces still missing from its ecosystem. Furthermore, it is not the easiest language to learn, particularly for people who are inexperienced with programming. This may limit my ability to attract other programers to the Whitebox project, which would be unfortunate. However, overall, Rust was the best option for this particular application.

Do I need Rust installed on my computer to run WhiteboxTools?

No, you would only need Rust installed if you were compiling the WhiteboxTools codebase from source files.

How does WhiteboxTools' design philosophy differ?

Whitebox GAT is frequently praised for its consistent design and ease of use. Like Whitebox GAT, WhiteboxTools follows the convention of one tool for one function. For example, in WhiteboxTools assigning the links in a stream channel network their Horton, Strahler, Shreve, or Hack stream ordering numbers requires running separate tools (i.e. HortonStreamOrder, StrahlerStreamOrder, ShreveStreamMagnitude, and HackStreamOrder). By contrast, in GRASS GIS1 and ArcGIS single tools (i.e. the r.stream.order and Stream Order tools respectively) can be configured to output different channel ordering schemes. The WhiteboxTools design is intended to simplify the user experience and to make it easier to find the right tool for a task. With more specific tool names that are reflective of their specific purposes, users are not as reliant on reading help documentation to identify the tool for the task at hand. Similarly, it is not uncommon for tools in other GIS to have multiple outputs. For example, in GRASS GIS the r.slope.aspect tool can be configured to output slope, aspect, profile curvature, plan curvature, and several other common terrain surface derivatives. Based on the one tool for one function design approach of WhiteboxTools, multiple outputs are indicative that a tool should be split into different, more specific tools. Are you more likely to go to a tool named r.slope.aspect or TangentialCurvature when you want to create a tangential curvature raster from a DEM? If you're new to the software and are unfamiliar with it, probably the later is more obvious. The WhiteboxTools design approach also has the added benefit of simplifying the documentation for tools. The one downside to this design approach, however, is that it results (or will result) in a large number of tools, often with signifcant overlap in function.

1 NOTE: It's not my intent to criticize GRASS GIS, as I deeply respect the work that the GRASS developers have contributed. Rather, I am contrasting the consequences of WhiteboxTools' design philosophy to that of other GIS.

Comments
  • Autodetect executable path & use pythonic tool names.

    Autodetect executable path & use pythonic tool names.

    This PR does the following:

    1. Autodetect availability of whitebox_tools in path and set exe_path automatically
    2. Use pythonic tool names (i.e. snake_case) in all the python functions. i.e. wbt.tool_help('rescale_value_range') instead of wbt.tool_help('RescaleValueRange')
    3. wbt.list_tools() returns a dictionary of {tool_name: description} instead of a string.
    4. Associated fixes to keep wb_runner.py working.

    These changes ease usage from python and allow for installation of whitebox_tools as a python package that can be imported by other packages. I am also build conda packages (see https://github.com/conda-forge/whitebox_tools-feedstock/pull/1) which will allow for installation of whitebox-tools easily in python. I'm just repackaging the zip files available from your website and adding a setup.py and putting the executable in the correct location. This will allow us to install whitebox_tools within a conda python environment using:

    conda install -c conda-forge whitebox_tools

    opened by dharhas 22
  • Error using Lidar tools on LAZ file

    Error using Lidar tools on LAZ file

    Hello,

    I am currently trying to use the withebox LIDAR tools on my mac via the Gui (same error with Qgis), but i have a consistant error code, the 101 code.

    What I Did

    I am using Lidar data from the French national geographic institut, the file is under the .laz extension. I tried three different tools in withebox (lidarinfo, ClipLidarToPolygon, ClassifyBuldingLidar) and the same error code appears. The wired thing is that i downloaded a different set of lidar data from the same platform i downloaded the previous set and the error did no occur on that set even though i followed the same protocol. The two data sets are at two different geographic locations (300 km a part).

    I have attached the screenshot of the parameters and the error that occurs.

    Capture d’écran 2022-11-28 à 11 52 00 Capture d’écran 2022-11-28 à 11 52 14 Capture d’écran 2022-11-28 à 11 52 18

    Does anyone have an idea why this might happen ?

    bug 
    opened by mathiaschabal 17
  • Raster Calculator panics (Permission error)

    Raster Calculator panics (Permission error)

    In reference to #197 I experience the same issue with a dockerized Python install. For me the raster_calculator results in the same failure and backtrace. I find it a pity that the raster calculator doesn't work out of the box with a Python install and would hope the Python would get fixed.

    By the way, thanks for the great work on these tools!

    ./whitebox_tools --run="RasterCalculator" --wd="/opt/project/utils/waterbodies/workspace/breached" --statement="raster1" --output='raster2'
    
    thread 'main' panicked at 'failed to execute process: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', whitebox-tools-app/src/tools/mod.rs:1258:26
    stack backtrace:
    0:     0x5638694f19dc - std::backtrace_rs::backtrace::libunwind::trace::h7f0f727c679b121e
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
    1:     0x5638694f19dc - std::backtrace_rs::backtrace::trace_unsynchronized::h27b8207adc787597
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
    2:     0x5638694f19dc - std::sys_common::backtrace::_print_fmt::h18c4a15687f3f453
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:67:5
    3:     0x5638694f19dc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7077f94cc0b2a619
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:46:22
    4:     0x56386952fdaf - core::fmt::write::hd1fcbdc89ccede50
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/fmt/mod.rs:1096:17
    5:     0x5638694f11e6 - std::io::Write::write_fmt::h3030f95a96ab63e0
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/io/mod.rs:1568:15
    6:     0x563869506365 - std::sys_common::backtrace::_print::hce920b6e4ede72f2
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:49:5
    7:     0x563869506365 - std::sys_common::backtrace::print::h63694f3a744810f6
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:36:9
    8:     0x563869506365 - std::panicking::default_hook::{{closure}}::h2f22ad38e825d5e1
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:208:50
    9:     0x563869505f33 - std::panicking::default_hook::hc0998dccd7f968a3
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:225:9
    10:     0x563869506995 - std::panicking::rust_panic_with_hook::h618d5ded1dbe5ea3
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:591:17
    11:     0x5638694f21f7 - std::panicking::begin_panic_handler::{{closure}}::h64f3a351a9df3931
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:497:13
    12:     0x5638694f1b3c - std::sys_common::backtrace::__rust_end_short_backtrace::hf7a8c7450479e920
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:141:18
    13:     0x563869506542 - rust_begin_unwind
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:493:5
    14:     0x56386952fae1 - core::panicking::panic_fmt::hac8d59bba791921f
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/panicking.rs:92:14
    15:     0x56386952b583 - core::result::unwrap_failed::h386947b3c6c45634
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/result.rs:1284:5
    16:     0x563868c35345 - whitebox_tools::tools::ToolManager::run_tool::h324febd58ab9a2e8
    17:     0x563868906abf - whitebox_tools::run::hf0adb91db1a610a3
    18:     0x563868903e2a - whitebox_tools::main::h48bb4032c3c51024
    19:     0x5638691096f3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h9669996f076d0ae7
    20:     0x5638686f4dc9 - std::rt::lang_start::{{closure}}::h4d629acb5d2e5dbf
    21:     0x563869506d4a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hacf21ab16c4aa1f7
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/ops/function.rs:259:13
    22:     0x563869506d4a - std::panicking::try::do_call::h002bd74c4d814788
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:379:40
    23:     0x563869506d4a - std::panicking::try::hae0844c0aa736d3d
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:343:19
    24:     0x563869506d4a - std::panic::catch_unwind::hec4fe4ae39575e8f
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panic.rs:431:14
    25:     0x563869506d4a - std::rt::lang_start_internal::h024664467cde3297
    at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/rt.rs:51:25
    26:     0x563868907f02 - main
    27:     0x7f4f46d5d0b3 - __libc_start_main
    28:     0x5638686f4cda - _start
    29:                0x0 - <unknown>
    
    opened by geotom 16
  • Missed geometry type information in the parameters definition of some tools

    Missed geometry type information in the parameters definition of some tools

    Spotted this while looking at the extension toolset, some tools does not advertise expected geometry type (point, line…) in the --toolparameters output. For example, all core tools produce something like this

    "parameter_type":{"ExistingFile":{"Vector":"Polygon"}}
    

    several tools from the extension toolset produce output like this one (note missed geometry type part)

    'parameter_type': {'ExistingFile': 'Vector'}}
    

    At least AssessRoute and LowPointsOnHeadwaterDivides are affected.

    Not sure is this a bug or correct and expected behaviour.

    opened by alexbruy 13
  • VectorPolygonsToRaster issue

    VectorPolygonsToRaster issue

    • whitebox version: 0.9.0
    • Python version: 3.7.3
    • Operating System: Windows 10

    Description

    The whitebox tool "VectorPolygonsToRaster" return a different result compare to the Whitebox GAT -win tool "Vector polygons to raster" . The output .tif has gaps!!!

    What I Did

    from whitebox import WhiteboxTools
    
    # Set up the environment
    wbt = WhiteboxTools()
    data_dir = "/../whitebox_issue"
    wbt.work_dir = (data_dir) 
    
    i_vector = "poly.shp"
    fieldZ = "Value"
    out_raster = "poly2raster_PYTHON.tif"
    
    wbt.vector_polygons_to_raster(
        i=i_vector,
        output=out_raster,
        field=fieldZ,
        nodata=True,
        cell_size=1,
       # base=None,
       # callback=default_callback
    )
    

    Vector Polygons To Raster - GAT-win

    poly2raster_GAT-win poly2raster_PYTHON

    opened by mlavy 13
  • WBT v.2.0 binary issues

    WBT v.2.0 binary issues

    It seems there are some issues with the v2.0 binaries downloaded from https://www.whiteboxgeo.com/download-whiteboxtools. The Windows binary is missing the .exe file extension. Adding the .exe file extension manually does not seem to work. The Linux version works fine, but the version number still shows v1.5.0.

    Windows:

    Linux

    opened by giswqs 12
  • Status 101 with feature_preserving_smoothing on v1.2.0

    Status 101 with feature_preserving_smoothing on v1.2.0

    I'm having a problem similar to this issue resolved last year: https://github.com/giswqs/whiteboxR/issues/7 but I wasn't able to solve mine.

    Basically, when I try to use the wbt_feature_preserving_smoothing command on a raster in .tif format, I get the following result, with a warning message ending with 'status 101' :

    [2] "* Welcome to FeaturePreservingSmoothing *"
    [3] "*****************************************"
    [4] "Reading data..."
    [5] "thread 'main' panicked at 'called Option::unwrap() on a None value', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8\src\libcore\macros\mod.rs:15:40" [6] "note: run with RUST_BACKTRACE=1 environment variable to display a backtrace."
    attr(,"status") [1] 101

    Any ideas on what might be the problem? Thanks

    opened by samuelmonat 12
  • Add flow pointer raster as input or output for flow accumulation functions

    Add flow pointer raster as input or output for flow accumulation functions

    It would be nice to allow functions like d8_flow_accumulation, d_inf_flow_accumulation, rho8_flow_accumulation to either accept as input a flow pointer raster (like the ones generated by d8_pointer, d_inf_pointer, rho8_pointer) or give as output the flow pointer raster already computed internally. I don't want to use flow_accumulation_full_workflow (that produce both a flow pointer and a flow accumulation raster) as I prefer to do my own preprocesing of the DEM.

    I need both flow pointer and a flow accumulation raster as I run raster_streams_to_vector and it leads to compute two times the flow pointer raster instead of once.

    feature request 
    opened by jfbourdon 12
  • Memory allocation errors

    Memory allocation errors

    I'm experiencing out-of-memory errors while using some LiDAR processing tools with the Whitebox Tools Runner and I don't understand why. I’m using a computer running Windows 10 and 32 GB of RAM, I think this should be enough to run tools like Remove Off-Terrain Objects and Feature Preserving Smoothing on a LiDAR DEM covering 6000 squared kilometers with a resolution of 1 meters, or is it? I'm not sure what's the workaround here. Thanks!

    opened by samuelmonat 11
  • /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./whitebox_tools)

    /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./whitebox_tools)

    Hi,

    I just downloaded and installed the new WTB linux release and installed Python module via with pip.

    When I try to run a simple tool such as slope within a Python script :

    from WBT.whitebox_tools import WhiteboxTools wbt = WhiteboxTools()

    dem='/fs/site4/eccc/oth/nhs/ama007/LAKES/Veg_model_preprocess/hub/LKE/8SPP/processing/slopes/TIF/8SPP_GRID_32617_IGLD85_masked_proj.tif'

    slope='/fs/site4/eccc/oth/nhs/ama007/LAKES/Veg_model_preprocess/hub/LKE/8SPP/processing/slopes/TIF/slope.tif'

    wbt.slope( dem, slope, zfactor=1.0)

    or in a command:

    cmd=f'/fs/site4/eccc/oth/nhs/ama007/apps/.conda/envs/py36/lib/python3.6/site-packages/WBT/whitebox_tools --run="Slope" --dem={dem} --output={slope} --zfactor=1.0 --units=degrees -v'

    os.system(cmd)

    I get the following error message: ./whitebox_tools: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./whitebox_tools)

    Please note that before that I had some permission issues with the same commands which got solved by changing the WBT folder attributes

    Thanks for your great work!

    opened by eccc-Antoine 11
  • Memory limitations

    Memory limitations

    First off, I know that this is mentioned in the known issues. But I wasn't sure that the limitation was so big as it appears to be in my case. I have developed a workflow that uses whitebox tools to extract drainage lines from a DEM. It is admirably fast on the test data, but the memory usage means that we can't process what I would consider a moderately sized 2 GB DEM. We are running on a machine with 96 GB of RAM. This is far from our largest DEM - we have a 6 GB one that we would like to process soon.

    I'm raising this issue to check firstly whether this seems about right to you - should a 2 GB DEM require >96 GB of RAM to run raster processing tools? (if not, possibly we are doing something wrong in implementation). And if that is correct, do you know of anyone who has managed to get around these issues somehow? I've considered breaking the DEM into chunks, but that wouldn't make sense when it came to the flow accumulation stage.

    Any help you can provide would be greatly appreciated. Whitebox tools seems like a fantastic resource and it would be a huge bonus to my work if I could use them on larger datasets.

    opened by InsolublePancake 10
  • LIDAR Interpolation Methods output TIFF without CRS

    LIDAR Interpolation Methods output TIFF without CRS

    I've been using the example scripts provided here: https://jblindsay.github.io/wbt_book/tutorials/lidar.html#grid_lidar

    I've used the scripts under the headings "How do I convert a LiDAR point cloud into a raster?" and "I have many LAS/zLidar files and want to interpolate all of them at once". In both cases, whitebox tools outputs a TIFF that doesn't have a coordinate reference system associated with it.

    The LAS files are too big to upload but I got them here: https://noaa-nos-coastal-lidar-pds.s3.amazonaws.com/laz/geoid18/9003/index.html

    What am I doing wrong?

    opened by michelob23 1
  • RasterCalculator python implementation

    RasterCalculator python implementation "Unrecognized tool name"

    Running the following wbt.raster_calculator(output, statement="", ) gives this feedback and error:

       .\whitebox_tools.exe --run="RasterCalculator" --statement= --output='output.tif' -v --compress_rasters=False
      thread 'main' panicked at 'Unrecognized tool name RasterCalculator.', whitebox-tools-app\src\main.rs:72:21
       note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    

    I'm able to run the same tool/statement from the command line without issue. I'm able to run other python wbt functions without issue.

    Not sure if this is related to the documentation issue here.

    Many Thanks,

    opened by cefect 0
  • RasterStreamsToVector doesn't write .prj for output

    RasterStreamsToVector doesn't write .prj for output

    I have tried to extract vector streams from raster using WBT QGIS plugin, WBT from python API call, and from wb_runner. Every time output shapefile was not accompanied by .prj file.

    In the source code of the algorithm, the line that sets the projection is commented. That might be the issue

    https://github.com/jblindsay/whitebox-tools/blob/5e9aabd68a5fa4660e84ff798e0a06cfedb5a179/whitebox-tools-app/src/tools/stream_network_analysis/raster_streams_to_vector.rs#L255

    opened by glebpinigin 0
  • Negative flow path length

    Negative flow path length

    • whitebox version: 2.2.0
    • Python version: 3.10.8

    Description

    Hi, I’m trying to compute the flow length using the DownslopeFlowpathLength function (both in python and in the QGIS inteface). The tool seems to work, but I have negative lengths as results. Am I doing something wrong? Could you explain what the output represents? Thank you!

    What I Did

    wbt.downslope_flowpath_length(flow_dir_catch, flowlength_catch, esri_pntr=True)

    Python/QGIS result:

    image

    Expected result:

    image

    opened by ClaRizzo 0
  • BreachDepressionsLeastCost 4-cell connected

    BreachDepressionsLeastCost 4-cell connected

    Thanks for the awesome tool.

    My tests show that BreachDepressionsLeastCost uses 8-cell connectedness: image

    It would be awesome if there was an option for 4-cell to align with some hydrodynamic model behavior. In the meantime, if you have any alternates to suggest these would be appreciated.

    feature request 
    opened by cefect 2
Releases(v2.2.0)
  • v2.2.0(Oct 23, 2022)

    Note: Compiled binaries for Windows, macOS, and Linux can be found at: https://www.whiteboxgeo.com/download-whiteboxtools/

    Release Notes:

    • Added the TravellingSalesmanProblem tool for identifying short routes connecting multiple locations.
    • Added the HeatMap tool for performing kernel density estimation (KDE) from vector points.
    • Added the MultiplyOverlay tool.
    • Added the MaxUpslopeValue tool.
    • Added the ConditionedLatinHypercube tool for stratified random sampling (credit Dr. Dan Newman).
    • Added the HighPassBilateralFilter tool, useful for emphasizing image texture.
    • Fixed a bug with the DirectDecorrelationStretch tool.
    • Fixed a bug in the automatic install of the Whitebox extensions that affected Windows users.
    • Fixed a bug with the persistence of the compress_rasters parameter. Python users were unable to turn off the compress flag previously.
    • Added the option to set and get the maximum number of processors (--max_procs flag) used by WBT in the Whitebox Python API.
    • Added the option to output average point density and nominal point spacing to the LidarInfo tool.
    • Updated the ClassifyOverlapPoints and FlightlineOverlap tools to use information contained within the Point Source ID property, rather than a hard-coded time difference threshold previously used.
    • Fixed an issue that affected many tools when input rasters use either NaN or Inf as NoData values.
    • Fixed an issue with the way that NoData values are handled during the euclidean distance transform that impacted the EuclideanDistance, EuclideanAllocation, BufferRaster, and ElevationAboveStreamEuclidean tools.
    • Fixed a bug with the LidarInfo tool that occurred when the user did not specify the mandatory output parameter along with a non LAS input file.
    • Fixed a bug with the Truncate tool; the output image was always integer, and therefore it did not work as expected when using more than zero significant digits.
    • Fixed a bug with the ConstructVectorTIN tool that resulted in an error when no field data are used.
    • Modified the code for writing to the settings.json file so that rather than issuing an error when the app doesn't have write permission, it simply prints a warning and carries on.
    • Fixed bugs in the Geomorphons tool (submitted by Dr. Dan Newman).
    • Fixed a bug with the writing of PolyLineZ vectors.
    • Updated the Hillshade, MultidirectionalHillshade, and RelativeAspect tools to use the more robust 5x5 3rd order bivariate polynomial method of Florinsky (2016) for rectangular grid DEMs, and the 3x3 method, also described by Florinsky (2016), for DEMs in geographic coordinates. This is a large improvement in accuracy for calculating these surface morphology parameters on geographic coordinates compared with the 'z-conversion fudge factor' method used previously.
    • Added support for Apple Silicon; you can now download WhiteboxTools binaries compiled on an M1 Mac.
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Aug 30, 2021)

    The most important feature in this release is the addition of support for reading and writing the LAZ compressed LiDAR format for all of the LiDAR tools in WBT.

    • Added the RasterCalculator tool for performing complex mathematical operations on input rasters.
    • Added the ConditionalEvaluation tool for performing an if-then-else operation on an input raster.
    • Added the EdgeContamination tool to identify grid cells for which the upslope area extends beyond the data extent.
    • Added the ExposureTowardsWind tool.
    • Added the QuinnFlowAccumulation tool to perform a Quinn et al. (1995) flow accumulation operation.
    • Added the QinFlowAccumulation tool to perform a Qin et al. (2007) flow accumulation operation.
    • Added the Rho8FlowAccumulation tool to perform a Fairfield and Leymarie (1991) flow accumulation operation.
    • LidarHistogram now allows a GPS time parameter, which can be useful for determining the number of flightlines in a LiDAR tile.
    • Fixed a bug with the Resample tool that created an artifact when resampling to resolutions less than one meter.
    • Fixed a bug that prevented plugin tools from being discovered by the open-core when run from the command line on PATH when the working directory was something other than WBT.
    • Fixed several bugs in the ContoursFromPoints tool.
    • Fixed the z_factor calculation for large-extent DEMs in geographic coordinates for the geomorphometric shape metric tools, e.g., slope, aspect, hillshade, and curvatures. The new approach calculates a different z_factor conversion value for each row in the raster, rather than using a single value based on the raster mid-point latitude. This should help improve the accuracy of these shape indices on large-extent rasters in geographic coordinate systems.
    • Fixed several bugs in the Isobasins and D8FlowAccumulation tool.
    • The NewRasterFromBase tool now accepts a vector base file (and grid cell size) as well as a raster.
    • The WhiteboxTools User Manual has had a refresh and is now hosted at: https://www.whiteboxgeo.com/manual/wbt_book/intro.html.
    • We have added numerous tools to the WhiteboxTools Extensions.
    Source code(tar.gz)
    Source code(zip)
  • 1.5.0(Jun 6, 2021)

    Version 1.5.0 (31-05-2021)

    • This release does not include very many new tools. Despite this, this is probably one of the largest releases yet. We have made extensive changes to the codebase, improving functionality in many significant ways. Therefore, we're very excited to announce the release of v1.5.
    • Probably the most exciting change is the introduction of plugin tools. Up until now, WBT has had a monolithic architecture, where all of the tools live within a single binary. This architecture has provided a number of benefits up until now. However, as the number of tools in WBT grows, it becomes increasingly difficult to maintain this program structure - in particular, compile times have grown significantly since the projects start. A plugin architecture provides much greater flexibility in this regard. Single tool plugins can be created, placed within the new 'plugins' folder within the WBT directory, and the whitebox_tools.exe binary will treat these plugins like any other tool within the monolith. This also means that WBT users can develop their own custom tools, without the required know-how of figuring out how to integrate their tool into the large WBT code-base. The user manual will be updated shortly to describe how this process works. For now, there is only one plugin tool example in the open-core (SplitVectorLines) although several other plugins have been developed (more on this below). The one downside of the new plugin architecture is that the size of the WBT download will inevitably grow, as individual tool executables will be larger than the single monolith. We believe that this is an acceptable compromise.
    • In order to accommodate plugin tools, we have significantly changed the codebase. Most significantly We have pulled the code associated with low-level functions, the so-called 'plumbing' code, (e.g. code for reading and writing various data files) into separate sub-repositories. In this way, the tools in the monolith and the plugin tools can both use this code without duplication.
    • WBT now has persistent environment variables contained within a 'settings.json' file within the WBT folder. Currently, these settings including 'verbose_mode', 'working_directory', 'compress_rasters', and 'max_procs'. More environment variables may be added in later releases. The fact that verbose mode the working directory, and the compress_rasters flag are now persistent does have implications for the Python and R front-ends and for the way these settings are used. The user manual will be updated shortly to reflect these changes.
    • We introduced the 'max_procs' setting. Now, all tools that run in parallel, or partially parallelize, can be restricted to a maximum number of processes. Before, WBT would simply use all of the available cores in the machine it was running on. While this is still the default (max_procs: -1), there are certain conditions where this behaviour is undesirable. For example, when WBT is run on large servers or cloud-computing environments where a great many cores are shared among many users, it can be problematic when a single user/program consumes all of the available cores. This setting limits the maximum number of procs.
    • Added the EmbankmentMapping tool for mapping transportation embankments (road, rail) in LiDAR DEMs.
    • Added the SplitVectorLines tool. This tool will parse an input line vector into a series of segments of a specified length. It is also an example of a WBT plugin.
    • The code has been updated to reflect the new zLidar v1.1 specification, which has significantly improved compression rates (testing shows it is between 91% and 109% of LAZ), greater flexibility (users may specify the degree of compression versus speed of reading/writing), and numerous bug fixes. The zLidar specification webpage will soon be updated to reflect the new version. Further news on this front, it has come to our attention recently that there is now a Rust-based LAZ encoder/decoder, which provides an opportunity for us to add LAZ support in a future version of WBT. We are currently evaluating this as an option.
    • We are trying to be more engaging with the WBT user community. In this regard, we have set up a new Google Groups forum for user to ask questions (https://groups.google.com/g/whiteboxtools), and have a new Twitter account (@whiteboxgeo) and newsletter to make announcements. Feel free to sign up for either if you're interested in staying in touch.
    • Lastly, we are very pleased to announce the creation of WhiteboxTools Geospatial Inc., a new company based on providing extension services around the open-source WBT platform. It is our vision that this company will provide a way of making the ongoing development of the WBT open-core more sustainable in the future, by enabling developers to work full-time on the project. Please read my 'open letter to the WBT community' (https://www.whiteboxgeo.com/open-letter-whiteboxtools-community/) for more details about this exciting development. Our plan is to maintain, and continue development of, the open-core of WBT, while providing plugin extensions that enhance the core capabilities. To begin with, we are launching the Whitebox General Toolset Extension, a set of (currently) 19 tools to help GIS professionals with their everyday workflows. Please see the newly redesigned WBT webpage at www.whiteboxgeo.com for more details. If you have been interested in supporting the WBT project in the past and haven't known how, buying a license for the General Toolset Extension is a wonderful way of doing so.
    Source code(tar.gz)
    Source code(zip)
  • 1.4.0(Sep 4, 2020)

    This release add some new tools and several bug fixes. Of the new tools, we are most excited about the addition of the TimeInDaylight tool, which estimates the proportion of daytime that each cell in a digital surface model (DSM) is in an exposed area. This is a very powerful method of performing a basic solar radiation modelling workflow. The new LidarDigitalSurfaceModel tool can be used to create DSMs for input to the TimeInDaylight tool. In addition to these updates, the User Manual has also been updated in numerous places with enhanced documentation. As always, if you wish to compile from source code, be sure to update to the most recent version of Rust beforehand using rustup update stable. Pre-compiled binaries are available for Windows (win), MacOS (Darwin), and Linux on Github and from the WhiteboxTools homepage. Please report any bugs that you encounter by creating an issue on the WhiteboxTools Github site.

    • Added the TimeInDaylight model tool for modelling the proportion of daytime that a location is not in shadow.
    • Added the MapOffTerrainObjects tool.
    • Added the FilterRasterFeaturesByArea tool.
    • Added the LidarDigitalSurfaceModel tool.
    • The D8 and FD8 flow pointer tools now output byte rasters.
    • The Isobasins tool now optionally outputs an upstream/downstream connections table.
    • The HorizonAngle tool has had significant performance improvements.
    • Improvements to the RemoveOffTerrainObjects tool's performance.
    • The Resample tool has been modified so that it does not require a 'destination' raster. Instead, it will create a new output raster either based on a user-specified target cell resolution or an optional base raster, much like the vector-to-raster conversion tools.
    • Tools that input a z_factor conversion no longer override user input with geographic coordinates (see issue #113).
    • The StreamLinkIdentifier tool now outputs a 32-bit integer format, increasing the maximum allowable number of streams (see issue #110).
    • Fixed a bug with cubic-convolution and bilinear resampling in the Mosaic tool (see issue #109).
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(6.06 MB)
    WhiteboxTools_linux_amd64.tar.xz(4.25 MB)
    WhiteboxTools_win_amd64.zip(6.92 MB)
  • v1.3.1(Jul 23, 2020)

    This release adds a few new tools, including two options for creating more advanced hillshade images from DEMs, and better raster file support. This includes critical fixes for the WBT GeoTIFF reader/writer and added support for reading BIL files.

    • Added the HypsometricallyTintedHillshade tool to create hypsometric tinted hillshades.
    • Added the MultidirectionalHillshade tool.
    • Added the ability to read/write in the Esri BIL raster format.
    • Added the LidarRooftopAnalysis tool.
    • The MultiPartToSinglePart tool now handles MultiPoint vectors.
    • Fixed a bug with the VoronoiDiagram to better handle MultiPoint vectors.
    • Fixed an issue with writing compressed RGB GeoTIFFs.
    • Fixed an issue reading LZW compressed GeoTIFFs.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(6.09 MB)
    WhiteboxTools_linux_amd64.tar.xz(4.31 MB)
    Whiteboxtools_win_amd64.zip(6.86 MB)
  • v1.3.0(Jun 8, 2020)

    • Tools will now output DEFLATE compressed GeoTIFFs when the --compress_rasters parameter is used.
    • Added support for a newly developed compressed LiDAR data format, the ZLidar file. All tools that accepted LAS file inputs and produced LAS outputs can now use '*.zlidar' files as well. I have also added the LasToZlidar and ZlidarToLas tools to perform conversions. While the ZLidar format does not yield compression rates quite as good as the popular LAZ file format, you can
      expect ZLidar files to be between 20-30% of the size of the equivalent LAS file. A file
      specification will be published in the near future to describe the open ZLidar data format.
    • Added the AsciiToLas tool.
    • Added the ContoursFromRaster tool for creating a vector contour coverage from a raster surface model (DEM).
    • Added the ContoursFromPoints tool for creating a vector contour coverage from vector points.
    • Added the UpdateNodataCells tool.
    • Modified the Slope tool to optionally output in degrees, radians, or percent gradient.
    • Modified the Mosaic tool, which now runs much faster with large numbers of input tiles.
    • The vector-to-raster conversion tools now preserve input projections.
    • Fixed a bug in the RasterToVectorPolygons tool.
    • Fixed several bugs in the MergeTableWithCsv tool.
    • Modified the FillMissingData tool to allow for the exclusion of edge-connected NoData cells from the operation. This is better for irregular shaped DEMs that have large areas of NoData surrounding the valid data.
    • The LidarConstructVectorTin tool has been depreciated. The tool was not creating the proper output. Furthermore, since the number of points in the average LiDAR tile is usually many million, this tool would usually produce Shapefiles that exceed the maximum allowable number of shape geometries. If a vector TIN is required for a LiDAR point set, users should convert the file to a Shapefile and then use the ConstructVectorTin tool instead. And of course, if you are interested in a raster TIN from a LiDAR file, use the LidarTinGridding tool instead.
    • FlattenLakes now handles multipart lake polygons.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.86 MB)
    WhiteboxTools_linux_amd64.tar.xz(4.20 MB)
    WhiteboxTools_win_amd64.zip(6.65 MB)
  • v1.2.0(Feb 21, 2020)

    • Added the RasterToVectorPolygons tool, which now completes the raster-vector conversion tool set.
    • Added the MultiscaleElevationPercentile tool.
    • Added the AttributeCorrelationNeighbourhoodAnalysis tool.
    • Added the RadialBasisFunctionInterpolation tool, which includes a thin-plate spline mode.
    • Added the RasterPerimeter tool to measure the perimeter of raster polygons.
    • Added the MDInfFlowAccumulation tool to perform the MD-infinity flow accumulation of Seibert and McGlynn (2007).
    • Added the InsertDams tool, which can be used to insert impoundment features at a set of points of interest into a DEM. This tool can be used in combination with the ImpoundmentSizeIndex tool to create artificial reservoirs/depressions.
    • Added the HeightAboveGround tool, to normalize a LiDAR point cloud. Each point's z-value is converted to the height above the nearest ground-classified point.
    • Modified the LidarRbfInterpolation tool to improve efficiency.
    • Fixed an issue with how floating point attributes were written in Shapefile attribute tables.
    • Updated the LidarSegmentation tool, which now used RANSAC to fit planar models to points.
    • Fixed an issue with the Reclass and ReclassFromFile tool that caused striping.
    • The Relcass and ReclassFromFile tools now take 'min' and 'max' in the reclass string.
    • The watershed tool now accepts either a set of vector points or a raster for the pour points file. If a raster is specified, all non-zero, non-NoData valued cells will be considered outlet cells and the watershed labels will be assigned based on these values.
    • The D8 and D-infinity flow accumulation tools now take either an input DEM or a flow pointer raster as inputs.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.80 MB)
    WhiteboxTools_linux_amd64.tar.xz(4.61 MB)
    WhiteboxTools_win_amd64.zip(6.13 MB)
  • v1.1.0(Dec 10, 2019)

    • Added the BreachDepressionsLeastCost tool, which performs a modified form of the Lindsay and Dhun (2015) impact minimizing breaching algorithm. This modified algorithm is very efficient and can provide an excellent method for creating depressionless DEMs from large DEMs, including those derived from LiDAR. It is particularly well suited to breaching through road embankments, approximately the pathway of culverts.
    • The FillDepressions tool algorithm has been completely re-developed. The new algorithm is significantly faster than the previous method, which was based on the Wang and Lui method. For legacy reasons, the previous tool has been retained and renamed FillDepressonsWangAndLui. Notice that this new method also incorporates significantly improved flat area correction that maintains general flowpaths of filled areas.
    • The Sink and DepthInSink tools have been updated to use the new depression filling algorithm.
    • Added the ClassifyBuildingsInLidar tool to reclassify LiDAR points within a LAS file to the building class value (6) that are located within one or more building footprint contained in an input polygon vector file.
    • Added the NaturalNeighbourInterpolation tool for performing Sibson's (1981) interpolation method on input point data.
    • Added the UpslopeDepressionStorage tool to estimate the average upslope depression storage capacity (DSC).
    • Added the LidarRfbInterpolation tool for performing a radial basis function interpolation of LiDAR data sets.
    • The WhiteboxTools Runner user interface has been significantly improved (many thanks to Rachel Broders for these contributions).
    • Fixed a bug in which the photometric interpretation was not being set by certain raster decoders, including the SAGA encoder. This was causing an error when outputting GeoTIFF files.
    • Updated the ConstructVectorTIN and TINGridding tools to include a maximum triangle edge length to help avoid the creation of spurious long and narrow triangles in convex regions along the data boundaries.
    • Added the ImageCorrelationNeighbourhoodAnalysis tool for performing correlation analysis between two input rasters within roving search windows. The tool can be used to perform Pearson's r, Spearman's Rho, or Kendall's Tau-b correlations.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.17 MB)
    WhiteboxTools_linux_amd64.tar.xz(4.47 MB)
    WhiteboxTools_win_amd64.zip(6.03 MB)
  • v1.0.2(Nov 1, 2019)

    • Added the BurnStreamsAtRoads tool.
    • Added a two-sample K-S test (TwoSampleKsTest) for comparing the distributions of two rasters.
    • Added a Wilcoxon Signed-Rank test (WilcoxonSignedRankTest) for comparing two rasters.
    • Added a paired-samples Student's t-test (PairedSampleTTest) for comparing two rasters.
    • Added the inverse hyperbolic trig functions, i.e. the Arcosh, Arsinh, and Artanh tools.
    • Renamed the LeeFilter to the LeeSigmaFilter.
    • Renamed the RelativeStreamPowerIndex tool to StreamPowerIndex, to be more in-line with other software.
    • Fixed another bug related to the handling of Boolean tool parameters.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.01 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.93 MB)
    WhiteboxTools_win_amd64.zip(5.41 MB)
  • v1.0.1(Oct 20, 2019)

    This is a bug-fix release. It includes the following changes:

    • Boolean type tool parameters previously worked simply by their presence in the parameter list. That is, simply have --flag in the list set the value of flag to True while its absence set it to False. This was causing problems with some WBT front-ends, particularly the QGIS front-end, where the parameters were being provided to WBT as --flag=False. In this case, because the flag was present, it was assumed to be True. All tools that have Boolean parameters have been updated to handle the case of --flag=False. This is a widespread modification that should fix the unexpected behaviour of many tools in certain front-ends. Because this represents a significant modification to the behaviour of numerous tools, it was decided that this minor release was warranted.
    • Fixed a minor bug with the VectorPolygonToRaster tool.
    • Fixed a bug in the DownstreamDistanceToStream tool.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.01 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.91 MB)
    WhiteboxTools_win_amd64.zip(5.37 MB)
  • v1.0.0(Sep 29, 2019)

    We are very pleased to announce the release of WhiteboxTools v1.0.0. This milestone release contains numerous feature additions and bug fixes and marks a period of stabilization in the platform. Modifications include the following:

    • Added support for reading and writing the BigTIFF format. This has resulted in numerous changes throughout the codebase as a result of significant modification of ByteOrderReader and addition of ByteOrderWriter. This change has touched almost every one of the raster format encoders/decoders.
    • Performance improvements have been made to the FlattenLakes (hydro-flattening) tool.
    • Fixed a bug preventing the SplitColourComposite tool from reading the '--input' flag correctly.
    • The ClipLidarToPolygon now issues a warning if the output LAS file does not contain any points within the clipped region and does not output a file. Also, the LAS reader no longer panics when it encounters a file with no points. Now it reads the header file, issues a warning, and carries on, allowing the tools to handle the case of no points.
    • ImageRegression can now optionally output a scatterplot. The scatterplot is based on a random sample of a user-defined size.
    • Added the CleanVector tool.
    • ExtractRasterStatistics has been renamed ZonalStatistics to be more inline with other GIS, including ArcGIS and QGIS.
    • Added the median as a statistic that ZonalStatistics provides.
    • Fixed a bug in the VectorPolygonsToRaster tool that sometimes mishandled polygon holes.
    • Added the FilterLidarClasses tool to filter out points of user-specified classes.
    • Added the LidarRansacPlanes tool to identify points belonging to planar surfaces. This tool uses the RANSAC method, which is a robust modelling method that handles the presence of numerous outlier points.
    • The ClipLidarToPolygon tool has been parallelized for improved performance.
    • The LasToAscii and AsciiToLas tools have been updated to handle RGB colour data for points.
    • Added the CsvPointsToVector tool to convert a CSV text table into a shapefile of vector points. The table must contain x and y coordinate fields.
    • The FeaturePreservingDenoise was renamed to FeaturePreservingSmoothing. The DrainagePreservingSmoothing tool was removed. Use FeaturePreservingSmoothing instead.
    • Added the ability to output the average number of point returns per pulse in the LidarPointStats tool.
    • LidarTinGridding, LidarIdwIntarpolation, and LidarNearestNeighbourGridding now can interpolate the return number, number of returns, and RGB colour data associated with points in a LAS file.
    • Added the ModifyNoDataValue tool to change the NoData value in a raster. It updates the value in the raster header and then modifies each grid cell in the raster containing the old NoData value to the new value. This operation overwrites the existing raster.
    • Fixed an issue with GeoTIFF NoData values that impacted many tools. NoData values were not interpreted correctly when they were very large positive or negative values (near the min/max of an f32).
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(4.94 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.88 MB)
    WhiteboxTools_win_amd64.zip(5.29 MB)
  • v0.16.0(May 24, 2019)

    Version 0.16.0 (24-05-2019)

    • Added the MergeLineSegments and SphericalStdDevOfNormals tools.
    • Fixed a bug with reading LAS files with point records with extra bytes. Previously, the LAS decoder assumed the Point Record Length matched that of the LAS specifications (with the variable of the optional intensity and user data). Some LAS files in the wild (particularly those created using LASTools and of LAS version 1.2) have larger Point Record Lengths, which presumably carry extra bytes of information. These extra byes are ignored, but they no longer throw off the decoding.
    • Fixed a bug with writing Big-Ending GeoTIFF files. The 'MM' file header was not correct previously.
    • Significantly reduced the memory requirements of the StochasticDepressionAnalysis tool. The tool may be somewhat slower as a result, but it should be applicable to larger DEMs than was previously possible.
    • Fixed bugs with the Union and SplitWithLines tools.
    • WhiteboxTools can now read and write Shapefiles of MultiPointZ, PolyLineZ, and PolygonZ ShapeTypes missing the optional 'M' values (i.e. measures).
    • SelectTilesByPolygon and LidarTileFootprint are now compatible with LAZ file inputs. Both of these tools only rely on information in the input LiDAR file's header, which is the same for a LAZ file as a LAS file.
    • Fixed a bug with writing Saga GIS files (*.sdat) that inverted rasters.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.13 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.82 MB)
    WhiteboxTools_win_amd64.zip(5.45 MB)
  • v0.15(Mar 10, 2019)

    Version 0.15.0 (03-03-2019)

    • The following tools were added to the project: BoundaryShapeComplexity NarrownessIndex ShapeComplexityIndexRaster

    • Fixed a bug with the PanchromaticSharpening tool.

    • Previously, if a LAS v1.4 file were input to a tool, the output LAS file, which is currently always in LAS v1.3 format, would not correctly translate the 64-bit information (point return, number of returns, classification) into 32-bit format. I have added the get_32bit_from_64bit function to handle this translation more gracefully; albeit it is still a lossy translation where returns greater than 5 are ignored and classification values greater than 31 are lost.

    • Added a maximum triangle edge length parameter to the LidarTinGridding tool to allow for the exclusion of large-area triangles (i.e. low point density) from the gridding.

    • The NormalizedDifferenceVegetationIndex tool has been renamed to NormalizedDifferenceIndex to indicate the more general nature of this tool (i.e. NDVI, NDWI, OSAVI, etc.).

    • Significant changes have been made to the BreachDepressions tool to make it more in-line with the behaviour of the GoSpatial algorithm described in the original Lindsay (2016) paper. These changes include: 1) the inclusion of an optional parameter to fill single-cell pits prior to breaching, 2) the addition of a --flat_increment parameter, which overrides the automatically derived value assigned to flat areas along breach channels (or filled depressions), and 3) the tool now performs a fast post-breach filling operation, when run in constrained-breaching mode (i.e. when the user specifies values for either --max_depth or --max_length, placing constraints on the allowable breach channel size).

    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.07 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.88 MB)
    WhiteboxTools_win_amd64.zip(5.34 MB)
  • v0.14.1(Feb 11, 2019)

  • v0.14(Jan 28, 2019)

    • This release largely focusses on bug-fixes rather than adding new features. However, the following tools for measuring surface roughness in a DEM were added to the project: CircularVarianceOfAspect EdgeDensity SurfaceAreaRatio
    • Fixed a bug that resulted in rasters with projected coordinate systems being interpreted as geographic coordinates, thereby messing up the calculation of inter-cell distances for tools like slope, aspect, curvature, etc.
    • Fixed a bug with several of the math tools; output files took their data type from the input file. In some cases, this does not work well because the input is integer and the output must be floating point data.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(5.01 MB)
    WhiteboxTools_linux_amd64.tar.xz(3.84 MB)
    WhiteboxTools_win_amd64.zip(5.27 MB)
  • v0.13(Jan 14, 2019)

    • The release largely focusses on bug-fixes rather than adding new features. The following tools were added to the project: MosaicWithFeathering
    • Support was added for GeoTIFF MODELTRANSFORMATIONTAG (Tag 33920).
    • Support was added for reading GeoTIFFs that have coordinate transformations defined by multiple tiepoints contained with the ModelTiepointTag (Tag 33922). These rasters have their raster-to-model transform defined by a 2D polynomial regression of the 3rd order.
    • The initialize_using_file function in the abstract Raster model now transfers information contained in an input GeoTIFF's ModelTiePoint, ModelPixelScale, ModelTransform, GeoKeyDirectory, GeoDoubleParms, and GeoAsciiParams tags to the output raster. This means that if a GeoTIFF file is input to a Whitebox tool, and the output raster is specified to be of GeoTIFF format as well, all of the coordinate information contain in the input raster will now be contained in the output raster.
    • The FeaturePreservingDenoise and DrainagePreservingSmoothing tools, both of which are used for DEM generalization, now represent surface normal vectors using 32-bit floats instead of the original double-precision values. This does not alter the results of these tools significantly, but does reduce the memory requirements and run-times of these tools substantially.
    • The LidarKappa tool now outputs a raster displaying the spatial distribution of the overall accuracy per grid cell (i.e. percent agreement).
    • Fixed a bug with the RasterStreamsToVector tool that resulted in overlapping traced streams.
    • The D8FlowAccumulation tool has been modifed to use a fixed flow-width to calculate specific contributing area, equal to the average grid cell resolution. The tool previously used a variable flow-width for SCA calculations, however,
      1. this differs from the constant value used in Whitebox GAT, and 2. a variable flow-width means that flow accumulation values do not increase continuously in a downstream direction. This last issue was causing problems with applications involving stream network extraction. This change does not affect the 'cells' nor 'catchment area' outputs of the tool.
    • Fixed a bug with the GeoTIFF NoData tag.
    • Fixed a bug with the SetNodataValue tool.
    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(9.37 MB)
    WhiteboxTools_linux_amd64.tar.xz(8.42 MB)
    WhiteboxTools_win_amd64.zip(9.57 MB)
  • v0.12.1(Nov 22, 2018)

    Version 0.12.0 (22-11-2018) Tools Added

    • The following tools were added to the project: BlockMaximumGridding BlockMinimumGridding Clip Dissolve Erase JoinTables Intersect LasToShapefile LidarClassifySubset LinearityIndex LineIntersections LongestFlowpath MergeTableWithCsv MergeVectors NearestNeighbourGridding PatchOrientation Polygonize RasterToVectorLines SplitWithLines SymmetricalDifference Union VoronoiDiagram

    Other Changes

    • Modified the algorithm used by the CostDistance tool from an iterative method of finding the minimum cost surface to one that uses a priority-flood approach. This is far more efficient. Also, there was a bug in the original code that was the result of a mis-match between the neighbouring cell distances and the back-link direction. In some cases this resulted in an infinite loop, which is now resolved.
    • Improvements have been made to the WhiteboxTools GeoTIFF reader. A bug has been fixed that prevented tile-oriented (in contrast to the more common strip-oriented) TIFF files from being read properly. Support has been added for reading rasters that have been compressed using the DEFLATE algorithm. Lastly, the WhiteboxTools GeoTIFF reader now supports sparse rasters, as implemented by GDAL's GeoTIFF driver.
    • An issue in the SAGA raster format reader has been fixed.

    Pre-compiled Binaries Pre-compiled executables for Windows, MacOS, and Linux can also be downloaded from the WhiteboxTools homepage.

    Source code(tar.gz)
    Source code(zip)
    WhiteboxTools_darwin_amd64.zip(9.02 MB)
    WhiteboxTools_linux_amd64.tar.xz(8.11 MB)
    WhiteboxTools_win_amd64.zip(9.10 MB)
  • v0.11.0(Oct 1, 2018)

    This release is marked by the addition of several vector data processing capabilities. Most notably, this includes support for TINing and TIN based gridding (vector and LiDAR), as well as several vector patch shape indicies. The following tools were added to the project:

    • AddPointCoordinatesToTable
    • CentroidVector
    • CompactnessRatio
    • ConstructVectorTIN
    • ElongationRatio
    • ExtendVectorLines
    • HoleProportion
    • LayerFootprint
    • LidarConstructVectorTIN
    • LidarTINGridding
    • LinesToPolygons
    • Medoid
    • MinimumBoundingCircle
    • MinimumBoundingEnvelope
    • MultiPartToSinglePart
    • PerimeterAreaRatio
    • PolygonArea
    • PolygonPerimeter
    • RasterStreamsToVector
    • RasterToVectorPoints
    • RelatedCircumscribingCircle
    • RemovePolygonHoles
    • ShapeComplexityIndex
    • SinglePartToMultiPart
    • SmoothVectors
    • SumOverlay
    • TINGridding

    Other Changes

    • Added a minimum number of neighbours criteria in the neighbourhood search of the LidarGroundPointFilter tool. In this way, if the fixed-radius search yields fewer neighbours than this minimum neighbours threshold, a second kNN search is carried out to identify the k nearest neighbours. This can be preferable for cases where the point density varies significantly in the data set, e.g. in the case of terrestrial LiDAR point clouds.
    • The MinimumBoundingBox tool has been modified to take an optional minimization criteria, including minimum box area, length, width, or perimeter.
    • Fixed: Bug that resulted in a 0.5 m offset in the positioning of interpolated grids.
    • Fixed: Viewshed tool now emits an intelligible error when the viewing station does not overlap with the DEM.

    Pre-compiled Binaries Download pre-compiled executables for Windows, MacOS, and Linux from the WhiteboxTools homepage.

    Source code(tar.gz)
    Source code(zip)
  • 0.10.0(Sep 18, 2018)

    Download pre-compiled executables for Windows, MacOS, and Linux at https://www.uoguelph.ca/~hydrogeo/WhiteboxTools/download.html.

    • The following tools were added to the project:
      • CreateHexagonalVectorGrid
      • CreateRectangularVectorGrid
      • DrainagePreservingSmoothing
      • EliminateCoincidentPoints
      • ExtractNodes
      • HighPassMedianFilter
      • LasToMultipointShapefile
      • LidarHexBinning and VectorHexBinning
      • LidarTileFootprint
      • MaxDifferenceFromMean
      • MinimumBoundingBox
      • MinimumConvexHull
      • PolygonLongAxis and PolygonShortAxis
      • PolygonsToLines
      • ReinitializeAttributeTable
    Source code(tar.gz)
    Source code(zip)
Geospatial primitives and algorithms for Rust

geo Geospatial Primitives, Algorithms, and Utilities The geo crate provides geospatial primitive types such as Point, LineString, and Polygon, and pro

GeoRust 989 Dec 29, 2022
Fast Geospatial Feature Storage API

Hecate OpenStreetMap Inspired Data Storage Backend Focused on Performance and GeoJSON Interchange Hecate Feature Comparison Feature Hecate ESRI MapSer

Mapbox 243 Dec 19, 2022
Geospatial primitives and algorithms for Rust

geo Geospatial Primitives, Algorithms, and Utilities The geo crate provides geospatial primitive types such as Point, LineString, and Polygon, and pro

GeoRust 990 Jan 1, 2023
Geo-rasterize - a pure-rust 2D rasterizer for geospatial applications

geo-rasterize: a pure-rust 2D rasterizer for geospatial applications This crate is intended for folks who have some vector data (like a geo::Polygon)

null 23 Dec 26, 2022
Spatial Data Structures for Rust

spade Documentation Using spade Examples Project state Performance License Spade (SPAtial DatastructurEs, obviously!) implements a few nifty data stru

Stefan Altmayer 195 Dec 21, 2022
A performant binary encoding for geographic data based on flatbuffers

FlatGeobuf A performant binary encoding for geographic data based on flatbuffers that can hold a collection of Simple Features including circular inte

FlatGeobuf 477 Jan 5, 2023
Convert perf.data files to the Firefox Profiler format

fxprof-perf-convert A converter from the Linux perf perf.data format into the Firefox Profiler format, specifically into the processed profile format.

Markus Stange 12 Sep 19, 2022
Heimdall is an advanced Ethereum smart contract toolkit for forensic and heuristic analysis.

Heimdall is an advanced EVM toolkit which aims to make dealing with smart contracts on EVM based chains easier. Installation & Usage Heimdall's update

Jonathan Becker 489 Jan 2, 2023
Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis

OnTimeDB Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis OnTimeDB is a time

Stuart 2 Apr 5, 2022
Zero-Copy reading and writing of geospatial data.

GeoZero Zero-Copy reading and writing of geospatial data. GeoZero defines an API for reading geospatial data formats without an intermediate represent

GeoRust 155 Dec 29, 2022
Retina is a network analysis framework that supports 100+ Gbps traffic analysis on a single server with no specialized hardware.

Retina Retina is a network analysis framework that enables operators and researchers to ask complex questions about high-speed (>100gbE) network links

Stanford Security Research 73 Jun 21, 2023
The powerful analysis platform to explore and visualize data from blockchain.

Mars: The powerful analysis platform to explore and visualize data from Web3 Features Blazing Fast Create from scratch with Rust. Pipeline Processor E

DeepETH 66 Dec 17, 2022
Nodium is an easy-to-use data analysis and automation platform built using Rust, designed to be versatile and modular.

Nodium is an easy-to-use data analysis and automation platform built using Rust, designed to be versatile and modular. Nodium aims to provide a user-friendly visual node-based interface for various tasks.

roggen 19 May 2, 2023
K-dimensional tree in Rust for fast geospatial indexing and lookup

kdtree K-dimensional tree in Rust for fast geospatial indexing and nearest neighbors lookup Crate Documentation Usage Benchmark License Usage Add kdtr

Rui Hu 152 Jan 2, 2023
Geospatial primitives and algorithms for Rust

geo Geospatial Primitives, Algorithms, and Utilities The geo crate provides geospatial primitive types such as Point, LineString, and Polygon, and pro

GeoRust 989 Dec 29, 2022
Fast Geospatial Feature Storage API

Hecate OpenStreetMap Inspired Data Storage Backend Focused on Performance and GeoJSON Interchange Hecate Feature Comparison Feature Hecate ESRI MapSer

Mapbox 243 Dec 19, 2022
Geospatial primitives and algorithms for Rust

geo Geospatial Primitives, Algorithms, and Utilities The geo crate provides geospatial primitive types such as Point, LineString, and Polygon, and pro

GeoRust 990 Jan 1, 2023
K-dimensional tree in Rust for fast geospatial indexing and lookup

kdtree K-dimensional tree in Rust for fast geospatial indexing and nearest neighbors lookup Crate Documentation Usage Benchmark License Usage Add kdtr

Rui Hu 154 Jan 4, 2023
Geo-rasterize - a pure-rust 2D rasterizer for geospatial applications

geo-rasterize: a pure-rust 2D rasterizer for geospatial applications This crate is intended for folks who have some vector data (like a geo::Polygon)

null 23 Dec 26, 2022
Rust implementation of the H3 geospatial indexing system.

h3o Rust implementation of the H3 geospatial indexing system. Design This is not a binding of the reference implementation, but a reimplementation fro

Hydronium Labs 196 Jan 31, 2023