Documentation update

README.md

@@ -18,10 +18,12 @@ This plugin proposes an automatic method to segment both polygon layers of valle
 
 This plugin can segment valley bottom layers or active channels layers. The geometry of these layers has to be of type *polygons*. The coordinate reference system of these layers have to use the *meters* as units. Both the valley bottom layer and the active channel layers have to be associated to only one river without any tributaries (figure 2).
 
+<div align="center">
 <figure>
 <img src="./figures/layers.svg" alt="Layers" width="50%">
 <figcaption><b>Figure 2: Geometry of the input layers.</b></figcaption>
 </figure>
+</div>
 
 As shown on figure 2, if there are a main river and a tributary, the user has to create a valley bottom layer, or active channels layers, specifically for each river. The valley bottom layer could be manually digitized based on geological maps. The active channels layers could be manually digitized based on aerial photographs. It is better to start the digitizing by the upstream part of the valley bottom or of the active channel in order to follow the natural way of the river.
 
@@ -43,10 +45,12 @@ The *Diachronix* plugin requires at least QGIS 3.14. The plugin was successfully
 
 The plugin could be run either through the *Extensions* menu or by clicking on the corresponding icon. The main window of the plugin could be divided in three parts (figure 3).
 
+<div align="center">
 <figure>
 <img src="./figures/window_parts.svg" alt="Window" width="70%">
 <figcaption><b>Figure 3: The main window of the plugin.</b></figcaption>
 </figure>
+</div>
 
 In the part 1, the user may choose :
 - to calculate the blocks of the bottom valley layer (*i.e.* the reference layer) only, by checking the *Valley bottom blocks* box
@@ -62,10 +66,12 @@ Then the user may choose a length for the blocks to be calculated at the line *D
 
 At the line *Valley bottom blocks (output)* the user sets a path and a name for the layer containing the resulting blocks which will be created. The format of this layer may be *shapefile* or *GeoPackage*. At the line *Table of valley bottom blocks (output)* the user sets a path and a name for the table which will contain the data relative to the resulting blocks. This table can be stored in *csv*, in Excel format (*.xlsx*) or in OpenDocument format (*.ods*). This table is exactly the same as the attribute table of the produced layer. The user may choose *To reverse the starting point* in order to start the blocks from the upstream part of the valley or from the downstream part of the valley. In order to check the intermediate layers, the user may load the temporary layers by clicking on *To load the temporary layers*. By clicking on *OK*, the blocks of the bottom valley layer will be produced. The process may take from some seconds to a few minutes according to the size of the layer to be segmented. The attribute table of the bottom valley blocks layer is shown on the figure 4.
 
+<div align="center">
 <figure>
 <img src="./figures/attribute_table.png" alt="Attribute table" width="60%">
 <figcaption><b>Figure 4: The attribute table of the bottom valley blocks layer.</b></figcaption>
 </figure>
+</div>
 
 In this attribute table, the *fid* and *ID* fields are just two ID fields. Each block has a unique ID. The other fields are:
 - *distance*: the distance in meters between the centroid of the block and the upstream part (or the downstream part) of the valley (figure 5).
@@ -73,17 +79,21 @@ In this attribute table, the *fid* and *ID* fields are just two ID fields. Each
 - *length_m*: the length in meter of each block along its centerline. These lengths are always very close to the length set by the user for the *Distance between two cross-sections*.
 - *mean_width_m*: the mean width of each block in meter. This mean width is simply the ratio of the area of each block by the length of each block.
 
+<div align="center">
 <figure>
 <img src="./figures/distance_blocks.svg" alt="Distance between blocks" width="50%">
 <figcaption><b>Figure 5: The distance of each block.</b></figcaption>
 </figure>
+</div>
 
 The plugin also exports the result in a simple table format (*.csv*, *.xlsx* or *.ods*). This table is exactly the same as the attribute table of the exported layer but allows the user to directly work on it outside from QGIS (figure 6).
 
+<div align="center">
 <figure>
 <img src="./figures/table_ods.png" alt="Simple table" width="60%">
 <figcaption><b>Figure 6: The exported table opened in LibreOffice Calc.</b></figcaption>
 </figure>
+</div>
 
 
 ### Segmentation of the active channel layer
@@ -107,10 +117,12 @@ The plugin suffers from some limitations listed below.
 
 As said previously, the distance between two cross-sections is freely set by the user. However, this distance should not be too small in order to avoid some issues in the building of the blocks. The figure 7 shows the issues when this distance is too short.
 
+<div align="center">
 <figure>
 <img src="./figures/distance_too_short.png" alt="Distance too short" width="50%">
 <figcaption><b>Figure 7: Effect of a distance too short (5 m in this example) on the resulting blocks.</b></figcaption>
 </figure>
+</div>
 
 To avoid this issue, we have to set a larger distance between two cross-sections.
 
@@ -119,10 +131,12 @@ To avoid this issue, we have to set a larger distance between two cross-sections
 
 The width of the cross-sections is freely set by the user. However, this width should be larger than the maximum width of the layer to be segmented. Otherwise, some blocks will be missing, resulting in blocks of non equal lengths (figure 8).
 
+<div align="center">
 <figure>
 <img src="./figures/cross-sections_too_small.svg" alt="Cross-sections too short" width="65%">
 <figcaption><b>Figure 8: Effects of the cross-sections widths on the resulting blocks.</b></figcaption>
 </figure>
+</div>
 
 As shown on the figure 8, the blocks 1 and 2 are not well segmented. They are two times longer than the normal blocks. This is explained by the cross-sections 1 and 2 used for the segmentation. These two cross-sections are too short compared to the maximum width of the layer to be segmented. To avoid this issue, we have to set a larger value for the width of the cross-section.
 
@@ -131,10 +145,12 @@ As shown on the figure 8, the blocks 1 and 2 are not well segmented. They are tw
 
 In the initial method, the cross-sections should be perpendicular to the centerlines of the layers to be segmented. However, this notion of *perpendicular* is not so obvious to implement in an automatic method. Thus, in this plugin the cross-sections are not always perpendicular to the cross-sections as shown on the figure 9.
 
+<div align="center">
 <figure>
 <img src="./figures/perpendicular.svg" alt="Cross-sections not perpendicular" width="40%">
 <figcaption><b>Figure 9: The cross-section 1 is not perpendicular to the centerline.</b></figcaption>
 </figure>
+</div>
 
 As shown on the figure 9, the cross-section 1 is not perpendicular to the centerline. Because of this, the area of the block 1 is slightly underestimated compared to the block 2 which is slightly overestimated. However, this limitation has relatively few impacts on the calculation of the mean widths of the blocks.
 
@@ -143,10 +159,12 @@ As shown on the figure 9, the cross-section 1 is not perpendicular to the center
 
 In the case of rivers with high sinuosity, some issues may appear in the meanders. In the meanders, one cross-section may cut two times the layer to be segmented. When this case happens, some blocks are missing (figure 10).
 
+<div align="center">
 <figure>
 <img src="./figures/sinuosity.svg" alt="Sinuosity" width="50%">
 <figcaption><b>Figure 10: The cross-section 1 cuts two times the layer to be segmented, therefore the block *a* is missing.</b></figcaption>
 </figure>
+</div>
 
 To avoid this issue, the user may shorten the width of the cross-sections or make the distance between the cross-sections larger.