FORCE v. 3.0.0

Release: 09.03.2020

• General changes and announcements

  • FORCE v. 3.0 is a major update. A lot of modules have received a major code overhaul. Much of this is not visible, but internally, code was extensively restructured, simplified, modularized, and optimized.

  • The official FORCE paper was published in Remote Sensing. The paper describes FORCE and its underlying principles. Frantz 2019: https://doi.org/10.3390/rs11091124

  • The code has been moved to GitHub. A self-registration is no longer necessary. https://github.com/davidfrantz/force

  • The documentation was transformed to an online documentation: https://force-eo.readthedocs.io/

  • FORCE Tutorials are now available! Make sure to regularly check for new content: https://davidfrantz.github.io/#tutorials

  • An open Google self-help group was set up. FORCE users, please participate, and help others. Together, we can move EO research forward. https://groups.google.com/d/forum/force_eo

  • FORCE has continued to participate in the ACIX II and CMIX intercomparisons (Atmosperic Correction / Cloud Masking Intercomparison eXercises). The preliminary results look very good, FORCE is a very reliable software framework and produces high quality products.

• Deprecated programs

  • Due to restructuring, many FORCE programs were removed, but their functionality was integrated and synergised in fewer programs to unify usage and simplify code maintenance and reduce redundancy.

  • force-level3, force-tsa, force-cso, force-improphe, force-l2imp are now available as submodules in force-higher-level.

  • force-parameter-level2, force-parameter-level3, force-parameter-tsa, force-parameter-cso, force-parameter-improphe, force-parameter-l2imp are now available as submodules in force-parameter

  • force-quicklook-level2, force-quicklook-level3 were removed as support for building quicklooks was directly integrated into the respective processing systems.

  • force-level1-sentinel2-long was deprecated for good. Sentinel-2 images with the outdated, long naming convention are no longer available. As such, this variant of force-level1-sentinel2 is no longer needed.

• New programs

  • Some new programs are introduced with v. 3.0, which either complement new functionality or integrate several deprecated solo programs.

  • force-cube is a tool to convert any image into datacube format. force-cube warps the image to the target projection, and tiles the data according to the grid system in use. Various resampling options can be used. It is key that a nodata value is given for the input images. force-cube can also warp, rasterize, and tile shapefiles. If used with shapefiles, masks (1 = occurence of geometry, 0 = no geometry) are generated, which can be used in force-higher-level to speed up analyses.

  • force-pyramid generates DEFLATE compressed overview images for speedy visualization (levels 2 4 8 16). It works well in combination with force-mosaic to generate pyramids for VRT mosaics.

  • force-parameter generates parameter file skeletons for each FORCE module. The skeletons also contain more in depth descriptions for each parameter, and supported parameter values/ranges. The descriptions can be turned off to generate more compact parameter files. This program fully substitutes the various force-parameter-* programs.

  • force-higher-level fully substitutes the deprecated higher level tools force-level3, force-tsa, force-cso, force-improphe, and force-l2imp. It provides a unified user interface for all higher level functionality, and provides a general framework for processing the Level 2 ARD products, e.g. the looping over the tiles is handled herein. Several new submodules (machine learning, texture, landscape metrics, and sampling) were implemented.

  • force-train allows to train (and validate) machine learning models using tables with features, and response variable, respectively. Features may be extracted from any FORCE-derived or compatible data source using the new sampling module in the new force-higher-level program (or any other program). Support Vector Machine and Random Forest models can be used, both as classification or regression. The samples can be split into training and validation sets. The trained models can be used in force-higher-level to apply the prediction to large datasets.

• New dependencies

  • The OpenCV library is now a mandatory dependency for the higher-level FORCE functionality. OpenCV is used for the newly introduced machine learning and texture functionality.

• CITEME

  • In order to increase fair usage, increase acceptance from external developers to integrate their code in FORCE, and to guide users on what references to cite, each FORCE module now generates a “CITEME” file with suggestions for references to be cited. This list is based on the specific parameterization you are using.

• FORCE L1AS

  • A ‘dry-run’ option was added to force-level1-sentinel2, which only checks how much data (number and volume) would be downloaded with the parameters you provided. No image will be downloaded.

  • In September 2018, ESA has activated the Long Term Archive (LTA) to roll out old (and potentially infrequently used) data products from the online storage system to offline storage. LTA-support was added to force-level1-sentinel2 (previous versions crash when encountering LTA images). However, please note that the data retrieval happens at any time within 24h, and the products stay online for 3 days. If a pull request was issued by force-level1-sentinel2, the program will go on to the next image. The program needs to be started again after a while to retrieve the potentially restored image. Also note, a user quota is implemented to prevent users from pulling the entire archive unfortunately this quota is ridicously low, 1 request per hour and user… Hopefully, this will change in the future.

  • force-level1-sentinel2-long was deprecated; see section ‘deprecated programs’

• FORCE AUX

  • force-tabulate-grid can now generate the grid as ESRI shapefile or in KML format. This is controlled by an additional parameter, which is either set to shp or kml.

• FORCE L2PS

  • force-parameter-level2 was deprecated, and substituted with the new force-parameter (see new programs section).

  • Performance and portability to different infrastructures was impoved. The RAM requirements were lowered substantially from about 13GB for a full Sentinel-2 image to about 8GB while approximately staying at the same runtime. Partial images now only use partial RAM, e.g. a Sentinel image with half nodata only uses half the RAM. It is now possible to use hybrid parallelization. The main parallelization strategy is still multiprocessing, i.e. single images are preprocessed simultaneously. New is: each process can additionally use multithreading. As multiprocessing is more efficient than multithreading (due to the sequential nature of the Level 2 workflow with different parts being more suitable for multithreading), we recommend to use as many processes, and as few threads as possible. However, a mild mix may be beneficial, e.g. 2 threads / process. If processing only a few (or one) image, or if RAM is too small, increase the multithreading ratio accordingly. This can speed up the work significantly.

  • Parallelization parameters are now specified in the parameter file, even those only used by the batch processor force-level2.

    • NPROC for the number of parallel processes. As before, NPROC can be adjusted during runtime.

    • NTHREAD for the number of threads each process may use. Overall, you are using NPROC*NTHREAD cores.

    • Before starting a new process, DELAY seconds are waited (use this if I/O jams occur).

    • PARALLEL_READS controls whether the individual bands of the Level 1 input images are read sequentially or in parallel. Note that we have observed two kinds of GDAL installation:

      1. The JPEG driver reads each band sequentially, but each image with as many threads as there are available. If this is the case, it is strongly recommended to disable PARALLEL_READS (for Sentinel-2).

      2. The GDAL JPEG drived does not do anything in parallel. In this case, use PARALLEL_READ to speed up the work (also use it for Landsat).

    • TIMEOUT_ZIP sets a timeout for unpacking zip/tar.gz input images (if they are still zipped).

      This parameter was implemented as on some platforms the Level 1 data are sitting on tape, and retrieving from tape occasionally take longer than the system can tolerate. As a result, the unzip/tar commands might hang. Timeout kills the job if it didn’t finish in the given time.

    • Following table indicates whether this option is used:

      +==============–+==============+————+ + Parameter + force-level2 + force-l2ps + +================+==============+============+ + NPROC + X + - + +==============–+==============+————+ + NTHREAD + X + X + +==============–+==============+————+ + DELAY + X + - + +==============–+==============+————+ + PARALLEL_READS + X + X + +==============–+==============+————+ + TIMEOUT_ZIP + X + - + +==============–+==============+————+

  • Sentinel-2 data with the old, long naming convention are completely gone from ESA archives. For the file queue, and for force-l2ps, it was necessary to give the file path to the granule within the Sentinel-2 product (because there were several granules). For the sake of usability, it is now possible to only give the filepath of the top directory, i.e. the *.SAFE directory. For force-level2, it is also possible to give the zipfile; force-l2ps needs the extracted file however. Note: if you give the top directory, but the image follows the outdated file structure, only the first granule will be processed. For the sake of backward compatibility, it is still possible to give the filepath of the granule.

  • We encountered an issue with the JP2ECW driver when reading Sentinel-2 images. The driver performed some kind of high-pass filtering and thus sharpened the image (while reading). However, this destroyed radiometry to a degree that the resulting surface reflectance was very unreliable (often negative reflectance). FORCE v. 3.0 removes JP2ECW from the list of potential drivers to open Sentinel-2 images.

  • To clarify that the coud masks are included in the QAI quality bit product, the cloud distance product CLD was renamed to DST. The cloud distance is not the cloud mask.

  • Cloud masking was improved. For cirrus masking, the elevation-dependent equation from Baetens et al.: https://doi.org/10.3390/rs11040433 was implemented.

  • Cloud shadow matching was accelerated by improving on the FIFO queue for the flood-fill algorithm (circular buffer instead of step-wise allocations). Cloud shadow matching was accelerated by (1) only using pixels in 30m steps (was 2 pixels for Sentinel-2), and (2) by increasing the step size for the base height iteration to a height that coincides with a horizontal shift of 50m (was 2 pixels).

  • Cloud masking-related QAI flags are not mutually exclusive anymore. E.g. it is now possible to have both the cloud and snow flags on.

  • The SUN_VIEW_GRID parameter that specifies how large the coarse resolution grid cells for atmospheric modeling are, was removed from the parameter file. It was fixed to 5km, which already was the default value, and which already was the constant used for Sentinel-2.

  • The AOD estimation in mountains was improved. Before, AOD was often too high, and thus negative reflectance was pretty common. This was due to a fixed parameter in equations that scale the AOD with altitude. Now, the scaling parameter is estimated from the image, and AOD overestimations are reduced.

  • The AOD averaging for the 5km coarse grid cells was changed. Before, the AOD-from-vegetation map, and the AOD-from-water map were averaged. Now, the map is generated by averaging each AOD estimate from each target.

  • The logfile logs cloud cover, snow cover, data cover (new), and water cover (new) for each image.

  • A coregistration module was implemented in FORCE L2PS. It was implemented to improve the georegistration of Sentinel-2 images, see Rufin et al.: DOI-TO-COME. For this purpose, the LSReg algorithm developed by Yan et al.: https://doi.org/10.3390/rs8060520 was integrated into FORCE (thanks Lin for the support). When using this option, FORCE expects a NIR master image that covers the complete image(s) to be processed. The image can be a mosaic in vrt format or any other format that is readable by GDAL. The projection of the master mosaic can be freely chosen, it does not need to be in the same projection as the processed images. FORCE expects that the master image has 12 bands, one for each month of the year. We have found, that using multi-annual monthly average amages are suitable images for a succesful coregistration. FORCE expects that the first five digits of the master image are ‘YYYY-‘. Multiple master images can be generated for different years. If there are master images ‘2015-’ and ‘2020-’, the first image is chosen when processing a 2017 image; the 2nd one is chosen when processing a 2020 image. For details about this strategy, see Rufin et al.: DOI-TO-COME. If the coregistration was unsuccesful, processing of the image is aborted. Information about the coregistration (# of tie points, corrected shift etc.) and its success are written to the logfile. DIR_MASTER specifies the directory that contain the master mosaics. If DIR_MASTER = NULL, no coregistration is performed. MASTER_NODATA gives the nodata value of the master image.

  • The primary processing unit of the higher level processing system has changed from tiles to blocks. Accordingly, ARD output is structured in blocks. The blocks are horizontal strips, i.e. they are tile-wide, and as high as specified with BLOCK_SIZE. The data cube definition file (output of L2PS) has a new line, which holds the BLOCK_SIZE.

  • RGB quicklooks can be generated as regular output (OUTPUT_OVV parameter). The quicklook is a jpeg overview with RGB image, and highlighted quality information.

    +==============——-+———-+ + cirrus + red + +=====================+==========+ + cirrus + red + +==============——-+———-+ + opaque cloud + pink + +==============——-+———-+ + cloud shadow + cyan + +==============——-+———-+ + snow + yellow + +==============——-+———-+ + saturated pixels + orange + +==============——-+———-+ + subzero reflectance + greenish + +==============——-+———-+

  • The PROJECTION tag and the WKT string should be given in one line now! In previous version, they needed to be given in two lines due to the parsing code employed.

  • There are two pre-defined projection/grid systems available. The EQUI7 grid is a set of 7 continental equi-distant projections and 100km tiles. The GLANCE7 grid is a set of 7 continental equal-area projections and 150km tiles. If one of these options is used in PROJECTION, the values given in ORIGIN_LAT/ORIGIN_LON/TILE_SIZE/BLOCK_SIZE are ignored and internally overwritten with the respective definition.

  • EQUI7 or GLANCE7 may also be used for a single continent. The default behaviour is: if the image intersects with one of the continental grids, it is processed and output into the continental datacube; this is repeated for each of the 7 continents. If you only want to have data for one continent, you can use one of the following subprojections: EQUI7-AF, EQUI7-AN, EQUI7-AS, EQUI7-EU, EQUI7-NA, EQUI7-OC, EQUI7-SA. For GLANCE7, it works analogously.

  • Instead of RESOLUTION, the parameters RESOLUTION_LANDSAT and RESOLUTION_SENTINEL2 are now available. With this change, it is now possible to use one and the same parameter file for both sensors.

  • In Sentinel-2 images, the metadata with the solar and viewing angle do not exactly align with the image data at the Eastern edge of the swath. In former FORCE versions, this resulted in a coarse stair-effect (5km) at the left side of the image, i.e. a few pixels at the edge of the swath were missing. With the help of some extrapolation, this issue is resolved with FORCE v. 3.0

  • The nodata value for the DEM can now be specified (DEM_NODATA). If you are using 0, a warning will be displayed as this is a bad choice for DEM nodata.

  • The new parameter DIR_LOG defines where to store the logfiles; before it was in DIR_LEVEL2 next to the image output.

  • IMPULSE_NOISE detection for the older 8-bit input data (L5/L7) can be switched off.

  • In previous Landsat products, the pixels next to nodata pixels were somehow contaminated, probably due to not considering nodata values during resampling. BUFFER_NODATA controls whether nodata pixels should be buffered by 1 pixel or not.

• FORCE WVDB

  • The LAADS HTTP has introduced to request an authentification. Thus, you need to obtain an App Key, see here: https://ladsweb.modaps.eosdis.nasa.gov/tools-and-services/data-download-scripts/#requesting This key needs to be stored in a file .laads in your home directoy.

• FORCE HIGHER LEVEL

  • force-parameter-level3, force-parameter-tsa, force-parameter-cso, force-parameter-improphe, force-parameter-l2imp were deprecated, and substituted with the new force-parameter (see new programs section).

  • force-level3, force-tsa, force-cso, force-improphe, force-l2imp are now available as submodules in force-higher-level. force-higher-level integrates all the higher level functionality in one program, and provides a general framework for processing the Level 2 ARD products, e.g. the looping over the tiles is handled herein. The different submodules do still exist, and the parameter files specify which submodule will be executed by force-higher-level.

  • There is now more flexibility with different hardware, especially the amount of RAM necessary. Before, the processing was tile-based, which means that the tiles were processed sequentially. The primary processing unit has changed from tiles to blocks. Accordingly, ARD output is structured in blocks. The blocks are horizontal strips, i.e. they are tile-wide, and as high as specified with BLOCK_SIZE. The data cube definition files have a new line, which holds the BLOCK_SIZE. Tiles are still processed sequentially, but within each tile, the blocks are now processed sequentially. A block needs far less RAM than a complete tile, especially with long time series and/or high spatial resolution. If the default block size is still too large for your system, you can override BLOCK_SIZE with a smaller value.

  • A considerable performance boost has been gained by preloading data (as e.g. Youtube does). Due to the sequential processing of tiles or blocks and the parallelization on the pixel level, the general data access pattern was

    (1) read all necessary data for the tile/block,

    (2) process the data,

    (3) output the results.

    repeat 1)-3) for each processing unit (tile/block).

    This resulted in ressource underutilisation as especially 1) and 3) are I/O bound with very little CPU usage, whereas 2) is CPU-heavy with no I/O load.

    Since v. 3.0, three teams of threads are used to break these read/process/write cycles, i.e.

    (Team 1) reads data for the next processing unit (PU+1)

    (Team 2) processes the data from the current processing unit (PU)

    (Team 3) output the results from the last processing unit (PU-1)

    (Teams 1-3) do this simultaneously.

    Thus, if processing time is larger than reading and writing time, there is no CPU underutilisation.

    Each team can have multiple subthreads. NTHREAD_READ controls how many images are read parallely, NTHREAD_COMPUTE controls how many threads are used to do the per-pixel parallelisation of processing, NTHREAD_WRITE controls how many products are written parallely. force-higher-level tracks how much time is spent for reading, computing and writing (I/C/O). During runtime, this indicates whether your task is Read-, CPU-, or Write-bound. A summary of the time saved by streaming is displayed upon completion of the task.

  • There are two kinds of higher level submodules, which mainly differ in the type of data that is used

    1. Level 2/3 ARD products, i.e. time and sensor-stamped inputs

    2. features, i.e. virtually any image data without timeor sensor context (e.g. data used for machine learning predictions; often output from other higher-level modules, or external data like climate variables see also force-cube)

  • For the ARD input, the filenames of the output products are inferred from the parameterization for the ARD input. For feature input, a basename needs to be defined in the parameterfile.

  • Input data must have one of these file extensions: Unexpected files, e.g. *.ovr etc do not cause errors anymore.

    +———–+============================+ + extension + format + +===========+============================+ + dat + uncompressed binary (ENVI) + +———–+============================+ + bsq + uncompressed binary (ENVI) + +———–+============================+ + bil + uncompressed binary (ENVI) + +———–+============================+ + tif + GeoTiff + +———–+============================+ + vrt + GDAL Virtual Format + +———–+============================+

  • Analysis masks are now specified using their directory (DIR_MASK, should contain masks, and their basename (BASE_MASK).

  • The Higher Level Processing System is able to process Best Available Pixel composites as input images (instead or in addition to Level 2). To make this work, both the BAP and INF products need to be present (both are output products of the Level 3 submodule), and you need to use the SENSOR as it appears in the filename of these products.

  • The Higher Level Processing System is able to process Sentinel-1 SAR data! You can perform all available time series analyses, Spectral Temporal Metrics, compositing etc. as if it would be a spectral index from optical data. Please note however that there is no FORCE module implemented to preprocess the SAR data (any volunteers to integrate this?). The S1 data need to be prepared in a FORCE-compatible format: they need to be in the correct tiling scheme (see e.g. force-cube). The images need to be signed 16bit integers with scaled backscatter in the order of -1000s, nodata value needs to be -9999. The data need to have two bands:

    +——+==============+ + Band + Polarization + +======+==============+ # 1 + VV + +——+==============+ # 2 + VH + +——+==============+

    Four new “sensors” (like LND08 or SEN2A) have been introduced, i.e.

    +——–+==============————-+ + SENSOR + Description + +========+===========================+ + S1AIA + Sentinel-1A IW Ascending + +——–+==============————-+ + S1AID + Sentinel-1A IW Descending + +——–+==============————-+ + S1BIA + Sentinel-1B IW Ascending + +——–+==============————-+ + S1BID + Sentinel-1B IW Descending + +——–+==============————-+

    This allows to merge (or keep them separated) data from ascending and descending orbits, and from S1A and S1B. Data needs to be named like this: 20180108_LEVEL2_S1AIA_SIG.tif

  • Parameters that indicate ranges were changed. E.g. X_TILE_MIN, and X_TILE_MAX were consolidated in X_TILE_RANGE.

  • For the ARD input type, the time range is now specified in a consolidated way across submodules. The DATE_RANGE parameter (YYYY-MM-DD) specifies the general slice of the time series used for the analysis. The DOY_RANGE parameter acts as filter on DATE_RANGE to limit processing to a seasonal rangem e.g. to only use summer images. DOY_RANGE can extend over the years for winter seasons/Southern hemisphere.

  • For the Time Series Analysis module, multiple indices can be selected at once, and the processing will generate all available output data for each index. While this is very handy, please keep in mind that depending on parameterization you can potentially generate an absurd amount of results and quickly fill up disc space. Fully parameterized, FORCE TSA can output 5100 products! Each of these products are multi-band images. Some of these products, e.g. interpolated time series, can have 1000s of bands. Use with care!

  • Additional indices were implemented:

    • NDBI (normalized difference building index),

    • NDWI (normalized difference water index),

    • mNDWI (modified normalized difference water index),

    • NDSI (normalized difference snow index)

  • A time series noise filtering was implemted, which can remove outliers on a per-pixel basis. Noise is estimated using the method described in Vermote et al.: https://doi.org/10.1109/TGRS.2008.2005977. Outliers are iteratively eliminated until the largest residual is smaller than ABOVE_NOISE. To further reduce commission errors of the cloud/cloud shadow masks, masked pixels that have a residual smaller than BELOW_NOISE are restored.

  • The DOYs and corresponding scoring function values in the Level 3 module are now given wih two parameters only, i.e.

    +==============——-+============================-+ + Old + New + +=====================+=============================+ + DOY_SCORE_0 = 120 + + +==============——-+ + + DOY_SCORE_1 = 180 + DOY_SCORE = 120 180 240 + +==============——-+ + + DOY_SCORE_2 = 240 + + +==============——-+============================-+ + DOY_STATIC_0 = 0.01 + + +==============——-+ + + DOY_STATIC_1 = 0.99 + DOY_STATIC = 0.01 0.99 0.01 + +==============——-+ + + DOY_STATIC_2 = 0.01 + + +==============——-+============================-+

  • The LSP files for the phenology-adaptive compositing (PAC) in the Level 3 module are now given as basenames (instead of patterns), and are given with one parameter only:

    +==============———–+==========================================——+ + Old + New + +=========================+================================================+ + LSP_PATTERN_PAR_0 = POS + + +==============———–+ + + LSP_PATTERN_PAR_1 = EOS + LSP_FILE = LSP-POS.tif LSP-EOS.tif LSP-MOS.tif + +==============———–+ + + LSP_PATTERN_PAR_2 = MOS + + +==============———–+==========================================——+

  • In version 2, there was an overlap between Spectral Temporal Metrics (a by-product of the compositing process) in the Level 3 module and basic statistics in the Time Series Analysis module. Those two concepts were merged, and are now available in the Time Series Analysis module as “Spectral Temporal Metrics” (STMs). Thus, the STMs are no longer sitting behind the compositing-specific quality filtering (which had both pros and cons). STMs can now be computed for any index requested, i.e. for any spectral band, and for each available index. STMs can be computed based on the regular time series, or based on the interpolated time series. The user can request a custom set of STMs, e.g. only average and standard deviation. Quantiles can be freely requested, e.g. the 37% quantile. In total, 107 STMs can be generated.

  • Several time series folds can now be computed within the same run. For each fold, trends or change+trends can be computed. A quarterly folding option was introduced. The available statistics to perform the folding have substantially increased: 107 statistics can now be used (101 quantiles, range, IQR, mean, std, skewness, kurtosis).

  • Land Surface Phenology metrics can now be freely selected. Before, all 26 available metrics were output. The user can define an amplitude threshold (LSP_MIN_AMPLITUDE), which suppresses the computation of phenometrics for non-seasonal land covers. An index value threshold (LSP_MIN_VALUE) can be defined to suppresses the computation of phenometrics for unvegetated pixels. The user can set the amplitude threshold (LSP_AMP_THRESHOLD), which is used to determine Start and End of Season, defaults to 0.2. The spline fit can be output, too. For each requested metric, trends or change+trends can be computed.

  • In the Clear-Sky Observations (CSO) module, the statistics can now be freely chosen. Besides the number of observations, 107 statistics on the temporal distance between obaservations can be computed (101 quantiles, range, IQR, mean, std, skewness, kurtosis).

  • To reduce confusion, the ImproPhe module was renamed to “Continuous Field ImproPhe”. The parameter file should now be enclosed by the tags “++PARAM_CFIMP_START++” and “++PARAM_CFIMP_END++” (instead of “++PARAM_IMP_START++” and “++PARAM_IMP_END++”). The coarse resolution continuous fields (input), are now expected to be in datacube format. Before, the images were warped to the extent of the tiles. This was done to increase consistency within the higher level program, and to only need to rely on a single data input mechanism. For cubing the continuous fields, see the new program force-cube

  • In the Level 2 ImproPhe and Continuous Field ImproPhe modules, the prediction and texture kernel are now given as radius, before it was in diameter.

  • To reduce confusion, the parameter USE_IMPROPHE in the ARD-specific higher level modules was renamed to USE_L2_IMPROPHE to clarify that this relates to the output of the Level 2 ImproPhe module, i.e. spatially improved ARD datasets and not to the spatially improved continous field outputs as generated with the Continuous Field ImproPhe module.

  • A new module was added: the Machine Learning module. This module allows the application of machine learning models (e.g. trained with force-train, see new programs above) to predict a variable, e.g. classification or quantitative variable (fraction, biomass etc). Implemented are regression and classification flavors of Random Forest and Support Vector Machines (ML_METHOD). The features need to be given with the INPUT_FEATURE parameters, which can be given multiple times. The given features must correspond to the features that were used to train the model (e.g. force-train). The model(s) must be in OpenCV xml format, and must be stored in DIR_MODEL. Multiple models can be given, in which case the average (mode) of the predictions will be used for regression (classification). A convergence factor (ML_CONVERGENCE) can be specified for the regression. If the models converge, i.e. the average of the ensemble does not change when adding predictions from more models, no more predictions are added (saves time). This is done on the pixel-level, i.e. different pixels may be averaged using a different amount of predictions. The OUTPUT_MLI product provides the number of models used for each pixel. The OUTPUT_MLU model provides the standard deviation of the predictions used for each pixel. Multiple modelsets can be given, in which case multiple predictions are performed, e.g. a crop classification, land cover classification and tree species classififcation can be computed in the same run. The different predictions are stored as separate bands in the output file. A scaling factor (ML_SCALE) can be specified to scale to prediction to 16bit integers.

  • A new module was added: the Texture module. This module allows the computation of texture metrics. Currently implemented are morphological operators, i.e. open, close, erode, dilate, gradient, tophat and blackhat. The metrics can be computed on any feature provided with the INPUT_FEATURE parameters, which can be given multiple times. TXT_RADIUS defines the radius in projection units, and TXT_ITERATION defines the number of iterations the morphological opearionts are performed.

  • A new module was added: the Sampling module. This module takes a table with geographic coordinates and a response variable. Each feature provided with the INPUT_FEATURE parameters will be sampled, which can be given multiple times. The module outputs a file with the sampled features (FILE_SAMPLE), the corresponding response variable (FILE_RESPONSE), and the corresponding coordinates (FILE_COORDINATES). Note that the derived samples are not in the same order as the input table, as force-higher-level follows a tile/blockbased processing order. Points that are outside of the provided spatial extent are not sampled, too. The parameter FEATURE_EXCLUDE controls wheter a sample is taken if one of the features has a nodata value. The output of this file can serve as input for force-train to train machine learning modules.

  • A new module was added: the landscape metrics module (C) Franz Schug, fschug@wisc.edu. This module allows for the computation of landscape metrics with a moving window strategy, as well as some focal statistics. The metrics can be computed on any feature provided with the INPUT_FEATURE parameters, which can be given multiple times.