dataesr/scientific-paragraphs-categorization huggingface dataset:
Thus, SMU components may be derived from the unequal representation of soil samples across SMUs. Harmonising soil data to reduce the number of STU is a great challenge by itself. Grouping some STUs regarding their pedological similarities such as sharing comparable morphological criteria, having similar pedogenic horizons and occurring in analogous environmental conditions is worthwhile to be investigated. More importantly, unifying soil data according to more functional aspects such as soil agricultural potential allows also to generate a relevant regional soil database easily handled by soil users to satisfy their needs. Many countries around the world have already harmonized their soil databases such as Denmark and Australia, where high pedological complexity was captured with a reasonable STU number, with not exceeding 23 soil groups in Denmark  (Møller et al.
4. 3) Taxonomic similarities In the recent DSM literature, DSMART approach is considered as an efficient tool to disaggregate existing coarse soil maps. In this study, we compared variants of the DSMART based approach, which differed by the training dataset used to calibrate the C5. 0 model and the allocation procedure. Modified DSMART algorithms used additional calibration datasets derived from supplement soil observations and expert sampling of polygons. Hence, taxonomic similarities were not taken into account neither in the calibration process nor in the current component assignment scheme. Even if there is a large number of STUs addressing inherent soil landscape heterogeneity, there is most likely a short taxonomic distance between many of them. As a result, these STUs may have similar forming conditions, making it a challenge to suitably constrain the prediction probabilities using DSMART algorithm.
Therefore, frequent STUs are more likely to be predicted rather than rare STUs. Meanwhile, by adding supplement soil profiles, preliminarily assigned to a suitable STU to the training dataset, we constrain STUs with low proportions of occurrence predictions. Major differences between DSMART with expert rules map and DMSART with soil observations were mainly observed in the southern part of the study area and valleys areas. In general, Fluvisol Stagnic soils were overestimated by DSMART with extra soil observations. This was likely due to the purposive sampling design followed to supplement soil observations. The 755 legacy soil profiles were selected to characterize hydromorphic soil conditions and to characterize inherent soil landscape variability supposed to be organized along the hillslope.
4. 5) Improvements and future work Even though this work emphasizes the contribution of pedological knowledge in the disaggregation process, other pathways can also be explored to improve map's accuracy. As recommended by  Mulder et al. (2016) , compensating the temporal changes and differences in laboratory analytics is a good option to improve the quality of legacy soil data. This suggests harmonising local soil database and regrouping some STUs with similar soil forming factors through statistical modelling. Moreover, additional environmental covariates with high spatial resolution should be used to capture micro landscape variability  (Lacoste et al. , 2014; Odgers et al. , 2014; Chaney et al. , 2016; Møller et al. , 2019). For example, adding a more detailed Digital Elevation Model allowed to capture small terrain features, where may be particular, STUs occurs.
Visual inspection of the obtained DSMART with extra soil observations map as well as DSMART with expert rules map showed an increase in soil heterogeneity when compared to Original DSMART map. More importantly, legacy soil profiles made it possible to take into account some rare soil types with low probability to be predicted. Therefore, adding supplement sampling points via the expert calibration dataset and the 755 extra soil profiles allowed to predict STUs characterized in the soil database with a low spatial extent. Nevertheless, the three DSMART based approaches spatially disaggregated the most frequent components disregarding the less frequent ones.
Acknowledgments The authors gratefully acknowledge all farmers at the Ille et Vilaine site involved in our research. We thank the technical staff who actively participated in field sampling and laboratory analysis. This research was performed in the framework of the  INRA "Ecoserv" metaprogram. This work was also supported by  Sols de Bretagne  project  and Soilserv program  funded by  ANR  ( Agence Nationale de la Recherche)  ( ANR-16-CE32-0005-01 ).
Seafloor backscatter mosaics are now routinely produced from multibeam echosounder data and used in a wide range of marine applications. However, large differences (>5 dB) can often be observed between the mosaics produced by different software packages processing the same dataset. Without transparency of the processing pipeline and the lack of consistency between software packages raises concerns about the validity of the final results. To recognize the source(s) of inconsistency between software, it is necessary to understand at which stage(s) of the data processing chain the differences become substantial. To this end, willing commercial and academic software developers were invited to generate intermediate processed backscatter results from a common dataset, for cross-comparison. The first phase of the study requested intermediate processed results consisting of two stages of the processing sequence: the one-value-per-beam level obtained after reading the raw data and the level obtained after radiometric corrections but before compensation of the angular dependence.
Recent comparisons of the backscatter products obtained from processing the same datasets with different software highlighted differences in the results  [8, [12] [13] [14]. The approach adopted during these comparisons included comparing the backscatter end-results in the form of mosaics as obtained from various software packages. Having recognized that different software likely process backscatter differently, the challenge remains for the end-users to assess which, if any, of the processing methodology is most accurate. This challenge is further compounded by the lack of standards for backscatter data acquisition  [10, 15]. The uncertainty in backscatter results due to the hardware and environment have only recently begun to be recognized  [15, 16] , and uncertainty standards still need to be developed in the manner that they were developed for multibeam bathymetry data over a decade ago  [17].
With the goal of improving consistency among backscatter data acquisition and processing methodologies, the Backscatter Working Group (BSWG) was established in 2013 under the auspices of the GeoHab (Marine Geological and Biological Habitat Mapping) association. The BSWG compiled its guidelines in a report published in 2015  [11]. Among other recommendations, the BSWG encouraged comparative tests of processing software packages using common data sets  [10]. As an outcome of this recommendation, the Backscatter Software Inter-Comparison Project (BSIP) was launched during the GeoHab 2019 conference. The long-term objective of the Backscatter Inter-comparison Project is to understand the reasons for the differences between the end-results obtained from a common dataset by various backscatter processing tools.
The results in this paper represent the first phase of this project. Since comparing the end-results of the processing solutions does not allow for understanding the root causes of the discrepancies, the developers of commonly-used software were invited to provide a set of intermediate stages from the processing of a common dataset. This approach allows a comparison of intermediate corrections without requiring software developers to disclose the details of their proprietary algorithms. A recent survey of backscatter end-users  [8]  identified the most-commonly used backscatter data processing software packages to date: Hydrographic Information Processing System and Sonar Information Processing System (HIPS and SIPS) by Teledyne CARIS, the Fledermaus Geocoder Toolbox (FMGT) by QPS, Geocoder by the University of New Hampshire (UNH), Hypack by the Xylem, MB-System by the Monterey Bay Aquarium Research Institute, and Sonarscope by IFREMER.
Selection of Test Backscatter Data Five datasets were selected for this study (Table  1 ), representing a range of shallow-and deep-water MBES: Kongsberg EM 2040, EM 3002, EM 710, EM 302, and Teledyne Reson SeaBat 7125. These datasets do not represent an exhaustive list of commercially available MBES but were opportunistically chosen because data from these surveys were publicly available. The test datasets were collected by different agencies (Table  1 ). The list of individual data files used during this study is provided as Appendix A (Table  A1 ). The common datasets used in this project are publicly available at https://bswg. github. io/bsip/.
BL0: The Backscatter Level as Read in The Raw Files The first stage of backscatter processing consists of reading the raw backscatter data recorded in the MBES raw data files. For both Kongsberg and Teledyne Reson systems, the raw data format organizes the collected information into several types of data units, known as datagrams, and the structure of each datagram type is described in format specifications made publicly available by the manufacturers  [21, 22]. Not only are backscatter data typically available in different datagrams, but the formats, the intermediate calculations applied, and the output resolution may have changed over the years. For example, in Kongsberg systems, the backscatter data are available in both the "onevalue-per-beam" and "several-samples-per-beam" formats in two different datagrams ("Depth" datagram for the former and "Seabed Image" datagram for the later).
In November 2005, the "Depth" datagram was superseded by the "XYZ 88" datagram, and the "Seabed Image" datagram was superseded by the "Seabed Image 89" datagram, with both newer datagrams upgrading the data resolution from 0. 5 dB to 0. 1 dB  [21]. Although Kongsberg released KMALL format in 2017  [23] , this format has not been adopted widely by the processing software packages and was not considered during this study. For the Reson system, datagrams with multiple samples per beam data are referred to as "snippets". With the aim of using the same raw data, software developers were requested to start the processing with the Seabed Image / Snippets data as the basis to calculate BL0.
BL 0 : The Backscatter Level as Read in The Raw Files The first stage of backscatter processing consists of reading the raw backscatter data recorded in the MBES raw data files. For both Kongsberg and Teledyne Reson systems, the raw data format organizes the collected information into several types of data units, known as datagrams, and the structure of each datagram type is described in format specifications made publicly available by the manufacturers  [21, 22]. Not only are backscatter data typically available in different datagrams, but the formats, the intermediate calculations applied, and the output resolution may have changed over the years. For example, in Kongsberg systems, the backscatter data are available in both the "one-value-per-beam" and "several-samples-per-beam" formats in two different datagrams ("Depth" datagram for the former and "Seabed Image" datagram for the later).
In November 2005, the "Depth" datagram was superseded by the "XYZ 88" datagram, and the "Seabed Image" datagram was superseded by the "Seabed Image 89" datagram, with both newer datagrams upgrading the data resolution from 0. 5 dB to 0. 1 dB  [21]. Although Kongsberg released KMALL format in 2017  [23] , this format has not been adopted widely by the processing software packages and was not considered during this study. For the Reson system, datagrams with multiple samples per beam data are referred to as "snippets". With the aim of using the same raw data, software developers were requested to start the processing with the Seabed Image / Snippets data as the basis to calculate BL 0.
CARIS SIPS Backscatter Processing Workflow The backscatter processing implementation in CARIS SIPS is a continuation of its bathymetric processing workflow and is aimed towards creating a backscatter mosaic. SIPS supports data sources from Reson and Kongsberg systems in their three record modes: Side scan (only applicable to Reson systems), beam average intensities, and snippets. Two separate backscatter processing engines are available within SIPS: Geocoder and SIPS backscatter processing engine. As the existing SIPS workflow did not allow end-users to extract BL 0 and BL 3 , these data were extracted by the SIPS software developers themselves. The following corrections and settings were selected: Processing Engine: SIPS; Source Data Type: Time series; Slant Range Correction, Beam Pattern Correction; Angular Variation Gains, Adaptive; AVG size filter, 200 samples.
CARIS SIPS Backscatter Processing Workflow The backscatter processing implementation in CARIS SIPS is a continuation of its bathymetric processing workflow and is aimed towards creating a backscatter mosaic. SIPS supports data sources from Reson and Kongsberg systems in their three record modes: Side scan (only applicable to Reson systems), beam average intensities, and snippets. Two separate backscatter processing engines are available within SIPS: Geocoder and SIPS backscatter processing engine. As the existing SIPS workflow did not allow end-users to extract BL0 and BL3, these data were extracted by the SIPS software developers themselves. The following corrections and settings were selected: Processing.
FMGT Backscatter Processing Workflow The backscatter data processing in the QPS software suite is implemented in a separate toolbox: Fledermaus Geocoder Toolbox (FMGT). A notable factor in this implementation is that all the survey parameters are read directly from the survey line files. The processing parameters used included "Tx/Rx Power Gain Correction", "Apply Beam Pattern Correction", and "Keep data for ARA (Angle Range analysis)". Backscatter Range was selected based on the minimum and maximum value of backscatter from "calibrated" backscatter with beam angle cut off between 0 • and 90 •. Export of BL 0 and BL 3 data are available through export 'ASCII ARA beam detail' (Figure  3 ). Geosciences 2019, 9, x FOR PEER REVIEW 6 of 24.
FMGT Backscatter Processing Workflow The backscatter data processing in the QPS software suite is implemented in a separate toolbox: Fledermaus Geocoder Toolbox (FMGT). A notable factor in this implementation is that all the survey parameters are read directly from the survey line files. The processing parameters used included "Tx/Rx Power Gain Correction", "Apply Beam Pattern Correction", and "Keep data for ARA (Angle Range analysis)". Backscatter Range was selected based on the minimum and maximum value of backscatter from "calibrated" backscatter with beam angle cut off between 0° and 90°. Export of BL0 and BL3 data are available through export 'ASCII ARA beam detail' (Figure  3 ).
SonarScope Data Processing Workflow SonarScope is a research tool developed by the department of Underwater Acoustics at IFREMER. SonarScope is available for free under an academic non-commercial use license. This tool is developed in Matlab as a laboratory tool aimed at research and development, rather than production. SonarScope can handle a variety of MBES formats. SonarScope implemented a new backscatter data processing methodology concurrently with this study. A detailed analysis of various processing stages based on the sonar equation  [7]  is provided in this updated workflow and exported as an HTML summary file with graphical displays of the various corrections. An ASCII output file is also produced that contains several fields describing the corrections (Figure  4 ).
SonarScope Data Processing Workflow SonarScope is a research tool developed by the department of Underwater Acoustics at IFREMER. SonarScope is available for free under an academic non-commercial use license. This tool is developed in Matlab as a laboratory tool aimed at research and development, rather than production. SonarScope can handle a variety of MBES formats. SonarScope implemented a new backscatter data processing methodology concurrently with this study. A detailed analysis of various processing stages based on the sonar equation  [7]  is provided in this updated workflow and exported as an HTML summary file with graphical displays of the various corrections. An ASCII output file is also produced that contains several fields describing the corrections (Figure  4 ). Geosciences 2019, 9, x FOR PEER REVIEW 6 of 24.
MB Process Data Processing and SONAR2MAT Data Conversion MB Process is a proprietary backscatter data processing tool coded in Matlab and developed and used by Curtin University Centre for Marine Science and Technology (CMST) and Geoscience Australia (GA) researchers to process Kongsberg (. all) files and Reson MBES (files saved as XTF)  [24]. CMST-GA MB Process is available to download for free from https://cmst. curtin. edu. au/products/ multibeam-software/ (last accessed September 2019). As this study used Reson (. s7k) files, the converter SONAR2MAT  [25]  was used to convert the (. s7k) data first to MATLAB (. mat) data files. SONAR2MAT converter supports a variety of MBES data formats and is available to download for free from https://cmst. curtin. edu. au/products/sonar2mat-software/ (last accessed Sept 2019).
MB Process Data Processing and SONAR2MAT Data Conversion MB Process is a proprietary backscatter data processing tool coded in Matlab and developed and used by Curtin University Centre for Marine Science and Technology (CMST) and Geoscience Australia (GA) researchers to process Kongsberg (. all) files and Reson MBES (files saved as XTF)  [24]. CMST-GA MB Process is available to download for free from https://cmst. curtin. edu. au/products/multibeam-software/ (last accessed September 2019). As this study used Reson (. s7k) files, the converter SONAR2MAT  [25]  was used to convert the (. s7k) data first to MATLAB (. mat) data files. SONAR2MAT converter supports a variety of MBES data formats and is available to download for free from https://cmst. curtin. edu. au/products/sonar2mat-software/ (last accessed Sept 2019).
Summary of Differences Between Software for Different Sonar Types In the previous sections, the differences between SIPS, FMGT, and SonarScope processing an EM302 data file were explored. In this section, the results of BL 0 , BL 3 , and incidence angle for other sonar types are summarized. The results show that EM 710 (Figures  14  and 15 ), EM 3002 (Figures  16  and 17 ), EM 2040 (Figures  18  and 19 ), and SeaBat 7125 (Figures  20  and 21 ) also present large differences. The pairwise differences for both BL0 and BL3 results differ considerably among processing solutions for the example files from all sonar models. The mean differences (except for the SeaBat 7125 data file) ranged from ~2 dB to ~10 dB with standard deviations of up to 8 dB. For the Seabat 7125 data file, the mean of the difference between FMGT and MB Process results was < 1 dB, but the difference was ~100 dB for comparisons involving SIPS.
The large discrepancy observed in SIPS results for the SeaBat 7125 data file indicates the application of large offset while reading the snippets. The pairwise differences for both BL0 and BL3 results differ considerably among processing solutions for the example files from all sonar models. The mean differences (except for the SeaBat 7125 data file) ranged from ~2 dB to ~10 dB with standard deviations of up to 8 dB. For the Seabat 7125 data file, the mean of the difference between FMGT and MB Process results was < 1 dB, but the difference was ~100 dB for comparisons involving SIPS. The large discrepancy observed in SIPS results for the SeaBat 7125 data file indicates the application of large offset while reading the snippets. The pairwise differences for both BL 0 and BL 3 results differ considerably among processing solutions for the example files from all sonar models.
The mean differences (except for the SeaBat 7125 data file) ranged from ~2 dB to ~10 dB with standard deviations of up to 8 dB. For the Seabat 7125 data file, the mean of the difference between FMGT and MB Process results was <1 dB, but the difference was ~100 dB for comparisons involving SIPS. The large discrepancy observed in SIPS results for the SeaBat 7125 data file indicates the application of large offset while reading the snippets. The results presented above showed that software solutions provided levels that differ both at the initial raw data reading stage (BL 0 ) and after the radiometric correction have been applied (BL 3 ). A few possible reasons for differences in BL 0 will be discussed in Section 4. 2.
A γ value of 1 indicates that both sources of difference contribute equally to the difference in end results. In Table  3 , we report for each dataset and each pair of software that could be, thus, compared, the median γ value and its interquartile range. In the case of Kongsberg systems, the median γ value is almost always less than 1, indicating that for most datasets and most software comparisons, the difference in data reading has more influence on the difference in the end results than radiometric corrections. Only the SIPS/FMGT comparison on the EM710 dataset shows a median γ larger than 1, indicating, in this case, that difference in radiometric corrections have a (slightly) larger influence. The same analysis applied to the SeaBat 7125 data produced many different results. MB Process and FMGT read the SeaBat 7125 raw data very similarly, leading to a very large median γ value that confirms that the difference in end results is almost entirely due to the difference in radiometric corrections.
However, SIPS reads the data differently than the two other software, and the difference in end result seems to be mostly due to this difference in data reading when compared with FMGT (median γ of 0. 71), but mostly due to difference in radiometric processing when compared with MB Process (median γ of 2. 27). Note that the interquartile ranges are often quite large, indicating that to obtain the future goal of consistent end results both of the two sources of difference will need to be addressed but the most important source of the differences in the end-results (except for MB Process and FMGT's approach to processing SeaBat 7125 data), currently is simply due to the original choice of the starting value (BL 0 ).
Discussion MBES backscatter data are increasingly used to provide information about the nature of the seabed, in resource management projects, to assess the potential environmental impacts of human activities on the seabed, and for monitoring and managing marine habitats  [8, 10]. In many of such projects, it is often required to merge backscatter data from several sources, which often use different data processing and analysis software packages (e. g. , EU national monitoring programs in relation with the EU Marine Strategic Framework Directive [27], Seamap Australia-a national seafloor habitat classification scheme  [28]  and Marine AREA database for Norwegian waters: MAREANO  [29] ). In this context, the quality control of the data and final products have important regulatory and legal implications.