The approach used in i.cutlines is inspired by Soares et al (2016). The module first uses an edge detection algorithm (which the user can chose with the edge_detection parameter) to identify edges in the image. It then uses r.cost and r.drain to draw lines through the image, following edges when possible and going straight when there are none.
The user can determine the number of lines desired (number_lines) in each direction and the friction associated with pixels which are not on an edge detected in the image (no_edge_friction). The higher this value, the more the module will follow the detected edges.
In order to avoid that all lines gather into one single lowest cost path, the module defines a lane for each desired line. The parameter lane_border_multiplier defines the a multiplier of the no_edge_friction value, in order to define the cost to cross that line, i.e. the lower the value, the more likely cutlines will join each other across lanes. Output is in the form of vector polygon tiles. The user can decide a minimum size defined in map units (min_tile_size). Tiles smaller than that size will be merged with the neighboring tile they share the longest border with.
The user can provide a series of auxiliary vector maps which contain existing cutlines (roads, boundaries, etc) that the module should take into account (existing_cutlines). These can be either lines or polygons. The module will transform all to potential cutlines.
For edge detection the user can chose between the i.zc module or the i.edge addon. For the former, the user can determine the zc_threshold and the zc_width parameters. For the latter, the canny_low_threshold, canny_high_threshold and canny_sigma parameters. See the manual page of the respective modules for details about these parameters which might need tuning to fit to the specific image. As these modules read the entire image into RAM, i.cutlines allows the user to run split the image into rectangular tiles and to process each tile separately. Tiles can be defined with the tile_width, tile_height and overlap parameters. If processes is higher than one, these tiles will be processed in parallel as will the r.cost calls for the two directions.
The memory parameter determines the memory used both for the r.cost runs.
g.region rast=ortho_2001_t792_1m -p i.cutlines ortho_2001_t792_1m number_lines=10 output=ortho_tiles
Last changed: $Date$