diff --git a/PROJ-DTRK/image/separator.gif b/PROJ-DTRK/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-DTRK/image/separator.gif and /dev/null differ
diff --git a/PROJ-DTRK/index.html b/PROJ-DTRK/index.html
index c69935a..03f7ed8 100644
--- a/PROJ-DTRK/index.html
+++ b/PROJ-DTRK/index.html
@@ -355,10 +355,6 @@ <h2 id="introduction">Introduction<a class="headerlink" href="#introduction" tit
 <p>The applied corrections are always the result of a complex process, involving different territory actors, until the decision is made to integrate them into the land register. In addition, land register models comes with an additional constraint linked to political decisions. Indeed, the land register models are the result of a <em>political mission</em> conducted under <em>federal laws</em> making these models of high importance and requiring constant care. We show in this research project how differences detection tool [1] of the <em>STDL 4D framework</em> can be used to emphasize and analyze these corrections along the time dimension.</p>
 <p>In addition to the constant updates of the models, changes in the reference frame can also lead to large-scale corrections of the land register models. These <em>global</em> corrections are then made even more complex by the <em>federal laws</em> that impose a high degree of correctness and accuracy.</p>
 <p>In the context of the introduction of the new reference frame <em>DM.flex</em> [2] for the Swiss land register, being able to assess the applied changes on the geographical model appear as an important aspect. Indeed, changing the reference frame for the land register models is a long and complex technical process that can be error prompt. We also show in this research project how the difference detection algorithm can be helpful to assess and verify the performed corrections.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-project-specifications">Research Project Specifications<a class="headerlink" href="#research-project-specifications" title="Permanent link">&para;</a></h2>
 <p>In this research project, the difference detection algorithm implemented in the <em>STDL 4D framework</em> is applied on <em>INTERLIS</em> data containing the official land register models of different Swiss <em>Canton</em>. As introduced, two main directions are considered for the difference detection algorithm :</p>
 <ul>
@@ -371,10 +367,6 @@ <h2 id="research-project-specifications">Research Project Specifications<a class
 </ul>
 <p>Through the first direction, the difference detection algorithm is presented. Considering the <em>difference models</em> it allows computing, it is shown how such model are able to extract information in between the models in order to emphasize the ability to represent, and then, to verify the evolution of the land register models.</p>
 <p>The second direction focuses on demonstrating that <em>difference models</em> are a helpful representation of the large-scale corrections that can be applied to land register during reference frame modification and how they can be used as a tool to assess the modifications and to help to fulfil the complex task of the verification of the corrected models.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-project-data">Research Project Data<a class="headerlink" href="#research-project-data" title="Permanent link">&para;</a></h2>
 <p>For the first research direction, the land register models of the <em>Thurgau Kanton</em> are considered. They are selected in order to have a small temporal distance allowing to focus on a small amount of well-defined differences :</p>
 <ul>
@@ -400,10 +392,6 @@ <h2 id="research-project-data">Research Project Data<a class="headerlink" href="
 <p><em>Canton of Geneva</em>, <strong>2019-04</strong>, <em>INTERLIS</em></p>
 </li>
 </ul>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="difference-models-a-temporal-derivative">Difference Models : A Temporal Derivative<a class="headerlink" href="#difference-models-a-temporal-derivative" title="Permanent link">&para;</a></h2>
 <p>This first section focuses on short-term differences to show how difference models work and how they are able to represent the modifications extracted out of the two compared models. The following images give an illustration of the considered dataset, which are the land register models of <em>Thurgau Kanton</em> :</p>
 <div align="center" style="font-style: italic">
@@ -454,10 +442,6 @@ <h2 id="difference-models-a-temporal-derivative">Difference Models : A Temporal
 </div>
 
 <p>One can see how <em>difference models</em> can be used to track down modifications brought to the land register in a simple manner, while keeping the information of the unchanged elements between the two compared models. This demonstrates that information that exists between models can be extracted and represented for further users or automated processes. In addition, such <em>difference models</em> can be computed at any scale, considering small area up to the whole countries.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="difference-models-an-assessment-tool">Difference Models : An Assessment Tool<a class="headerlink" href="#difference-models-an-assessment-tool" title="Permanent link">&para;</a></h2>
 <p>On the previous section, the <em>difference models</em> are computed using two models only separated of a few days, containing only a small amount of clear and simple modifications. This section focuses on detecting differences on larger models, separated by several years. In this case, the land register of the <em>Canton of Geneva</em> is considered :</p>
 <div align="center" style="font-style: italic">
diff --git a/PROJ-GEPOOL/image/separator.gif b/PROJ-GEPOOL/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-GEPOOL/image/separator.gif and /dev/null differ
diff --git a/PROJ-GEPOOL/index.html b/PROJ-GEPOOL/index.html
index 6d9c042..91cb4ce 100644
--- a/PROJ-GEPOOL/index.html
+++ b/PROJ-GEPOOL/index.html
@@ -340,10 +340,6 @@ <h2 id="introduction">Introduction<a class="headerlink" href="#introduction" tit
 <p>The Canton of Geneva manages a register of swimming pools, counting - in principle - all and only those swimming pools that are in-ground or, at least, permanently fixed to the ground. The swimming pool register is part of a far more general cadastre, including several other classes of objects (cf. <a href="https://ge.ch/sitg/fiche/3205">this page</a>). </p>
 <p>Typically the swimming pool register is updated either by taking building/demolition permits into account, or by manually checking its multiple records (4000+ to date) against aerial images, which is quite a long and tedious task. Exploring the opportunity of leveraging Machine Learning to help domain experts in such an otherwise tedious tasks was one of the main motivations behind this study. As such, no prior requirements/expectations were set by the recipients. </p>
 <p>The study was autonomously conducted by the STDL team, using Open Source software and Open Data published by the Canton of Geneva. Domain experts were asked for feedback only at a later stage. In the following, details are provided regarding the various steps we followed. We refer the reader to <a href="../TASK-IDET/">this page</a> for a thorough description of the generic STDL Object Detection Framework.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="method">Method<a class="headerlink" href="#method" title="Permanent link">&para;</a></h2>
 <p>Several steps are required to set the stage for object detection and eventually reach the goal of obtaining - ideally - even more than decent results. Despite the linear presentation that the reader will find here-below, multiple back-and-forths are actually required, especially through steps 2-4.</p>
 <h3 id="1-data-preparation">1. Data preparation<a class="headerlink" href="#1-data-preparation" title="Permanent link">&para;</a></h3>
@@ -442,10 +438,6 @@ <h3 id="4-prediction-assessment">4. Prediction assessment<a class="headerlink" h
 
 <p>The latter figure was obtained by evaluating the predictions of our best model over the test dataset. Inferior models exhibited a similar behavior, with a downward offset in terms of <span class="arithmatex">\(F_1\)</span> score. In practice, upon <strong>iterating over multiple realizations</strong> (with different hyper-parameters, training data and so on) we aimed at maximizing the value of the <span class="arithmatex">\(F_1\)</span> score on the validation dataset, and stopped when the <span class="arithmatex">\(F_1\)</span> score went over the value of 90%.</p>
 <p>As the ground-truth data we used turned out not to be 100% accurate, the responsibility for mismatching predictions has to be shared between ground-truth data and the predictive model, at least in some cases. In a more ideal setting, ground-truth data would be 100% accurate and differences between a given metric (precision, recall, <span class="arithmatex">\(F_1\)</span> score) and 100% should be imputed to the model.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="domain-experts-feedback">Domain experts feedback<a class="headerlink" href="#domain-experts-feedback" title="Permanent link">&para;</a></h2>
 <p>All the predictions having a score <span class="arithmatex">\(\geq\)</span> 5% obtained by our best model were exported to Shapefile and shared with the experts in charge of the cadastre of the Canton of Geneva, who carried out a thorough evaluation. By checking predictions against the swimming pool register as well as aerial images, it was empirically found that the threshold on the minimum score (= <code>thr</code>) should be set as high as 97%, in order not to have too many false positives to deal with. In spite of such a high threshold, 562 potentially new objects were detected (over 4652 objects which were known when this study started), of which:</p>
 <ul>
@@ -472,10 +464,6 @@ <h2 id="domain-experts-feedback">Domain experts feedback<a class="headerlink" hr
 <i>Examples of detected swimming pools which are not subject to registration: placed on top of a building (left), inflatable hence temporary (right).</i>
 </p>
 
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">&para;</a></h2>
 <p>The analysis reported in this document confirms the opportunity of using state-of-the-art Deep Learning approaches to assist experts in some of their tasks, in this case that of keeping the cadastre up to date. Not only the opportunity was explored and actually confirmed, but valuable results were also produced, leading to the detection of previously unknown objects. At the same time, our study also shows how essential domain expertise still remains, despite the usage of such advanced methods.</p>
 <p>As a concluding remark, let us note that our predictive model may be further improved. In particular, it may be rendered less prone to false positives, for instance by:</p>
diff --git a/PROJ-HETRES/images/F17A_all_VarImp.tif b/PROJ-HETRES/images/F17A_all_VarImp.tif
new file mode 100644
index 0000000..3e1988e
Binary files /dev/null and b/PROJ-HETRES/images/F17A_all_VarImp.tif differ
diff --git a/PROJ-HETRES/images/F17B_all_VarImp.tif b/PROJ-HETRES/images/F17B_all_VarImp.tif
new file mode 100644
index 0000000..ac12dd1
Binary files /dev/null and b/PROJ-HETRES/images/F17B_all_VarImp.tif differ
diff --git a/PROJ-HETRES/images/F18_sample_removal.png b/PROJ-HETRES/images/F18_sample_removal.png
new file mode 100644
index 0000000..16e6992
Binary files /dev/null and b/PROJ-HETRES/images/F18_sample_removal.png differ
diff --git a/PROJ-HETRES/images/F5_profiles.pdf b/PROJ-HETRES/images/F5_profiles.pdf
new file mode 100644
index 0000000..e21a52e
Binary files /dev/null and b/PROJ-HETRES/images/F5_profiles.pdf differ
diff --git a/PROJ-HETRES/index.html b/PROJ-HETRES/index.html
index 05f7667..307c1fa 100644
--- a/PROJ-HETRES/index.html
+++ b/PROJ-HETRES/index.html
@@ -607,9 +607,11 @@ <h3 id="42-image-processing">4.2 Image processing<a class="headerlink" href="#42
 
 <h4 id="421-statistical-tests-on-the-original-and-filtered-pixels">4.2.1 Statistical tests on the original and filtered pixels<a class="headerlink" href="#421-statistical-tests-on-the-original-and-filtered-pixels" title="Permanent link">&para;</a></h4>
 <p>The statistical tests were performed on the original and filtered pixels.</p>
-<p>Two low pass filters were tested:
-- Gaussian with a sigma of 5;
-- Bilinear downsampling with scale factors of 1/3, 1/5 and 1/17, corresponding to resolutions of 9, 15 and 50 cm.</p>
+<p>Two low pass filters were tested:</p>
+<ul>
+<li>Gaussian with a sigma of 5;</li>
+<li>Bilinear downsampling with scale factors of 1/3, 1/5 and 1/17, corresponding to resolutions of 9, 15 and 50 cm.</li>
+</ul>
 <p>In the original and the filtered cases, the pixels for each GT tree were extracted from the images and sorted by class. Then, the corresponding NDVI is computed. Each pixel has 5 attributes corresponding to its value on the four bands (R, G, B, NIR) and its NDVI.<br />
 First, the per-class boxplots of the attributes were executed to see if the distinction between classes was possible on one or several bands or on the NDVI.<br />
 Then, the principal component analysis (PCA) was computed on the same values to see if their linear combination allowed the distinction of the classes.</p>
@@ -840,7 +842,7 @@ <h4 id="532-vegetation-healthy-index">5.3.2 Vegetation Healthy Index<a class="he
 <li>unhealthy and other trees in 2021</li>
 <li>dead and unhealthy trees in 2020 and 2022</li>
 </ul>
-<p>Explanations similar to those for NDVI may partly explain the significance obtained. In any case,it is encouraging that the VHI helps to differentiate health classes thanks to different evolution through the years. </p>
+<p>Explanations similar to those for NDVI may partly explain the significance obtained. In any case,it is encouraging that the VHI helps to differentiate health classes thanks to different evolution through the years.</p>
 <h3 id="54-random-forest">5.4 Random Forest<a class="headerlink" href="#54-random-forest" title="Permanent link">&para;</a></h3>
 <p>The results of the RF that are presented and discussed are: (1) the optimization and ablation study, (2) the ground truth analysis, (3) the predictions for the AOI and (4) the performance with downgraded data. </p>
 <h4 id="541-optimization-and-ablation-study">5.4.1 Optimization and ablation study<a class="headerlink" href="#541-optimization-and-ablation-study" title="Permanent link">&para;</a></h4>
diff --git a/PROJ-LANDSTATS/image/separator.gif b/PROJ-LANDSTATS/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-LANDSTATS/image/separator.gif and /dev/null differ
diff --git a/PROJ-LANDSTATS/index.html b/PROJ-LANDSTATS/index.html
index 1ebd773..fd1fb4a 100644
--- a/PROJ-LANDSTATS/index.html
+++ b/PROJ-LANDSTATS/index.html
@@ -456,10 +456,6 @@ <h1 id="using-spatio-temporal-neighbor-data-information-to-detect-changes-in-lan
 Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249.</em> </p>
 <p><em>Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used.</em> </p>
 <p><em>It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation.</em>  </p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="1-introduction">1. Introduction<a class="headerlink" href="#1-introduction" title="Permanent link">&para;</a></h2>
 <p>The introduction presents the background and the objectives of the projects, but also introduces the input data and its specific features.</p>
 <h3 id="11-background">1.1 Background<a class="headerlink" href="#11-background" title="Permanent link">&para;</a></h3>
@@ -568,10 +564,6 @@ <h3 id="13-input-data">1.3 Input data<a class="headerlink" href="#13-input-data"
 *<em>The shortened LC1/LU1 to LC4/LU4 will be used to simplify the notation of Land Cover/Use of survey 1 to survey 4 in the following documentation.</em>
 </small> </p>
 <p>For machine learning, training data quality has strong influence on model performance. With the <em>training</em> label, domain experts from FSO selected data points that are more reliable and representative. These 348'474 tiles and their neighbors composed the training and testing dataset for machine learning methodology.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="2-exploratory-data-analysis">2. Exploratory data analysis<a class="headerlink" href="#2-exploratory-data-analysis" title="Permanent link">&para;</a></h2>
 <p>As suggested by domain experts, exploratory data analysis (EDA) is of significance to understand the data statistics and find the potential internal patterns of class transformation. The EDA is implemented from three different perspectives: distribution, quantity and probability. With the combination of the three, we can find that there do exist certain trends in the transformation of both land cover and land use classes. </p>
 <p>For the land cover, main findings are: </p>
@@ -707,10 +699,6 @@ <h4 id="232-land-use-analysis">2.3.2 Land use analysis<a class="headerlink" href
 
 <p>Figure 11 tells the difference in the diversity of transformation destination. The construction and unexploited areas would turn into all kinds of urban areas, with more than 95% changed and the maximum probability to a fixed class is less than 35%. While the <em>Afforestation</em>, <em>Lumbering areas</em> and <em>Damaged Forest</em> returned to <em>Forest</em> with a probability of more than 90%, the transformation pattern within these four classes is fairly fixed.</p>
 <p>The distribution statistics, the quantity statistics and the probability matrices have shown to validate and complement each other during the exploratory analysis of the data.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="3-methods">3. Methods<a class="headerlink" href="#3-methods" title="Permanent link">&para;</a></h2>
 <p>The developed method should be integrated in the OFS framework for change detection and classification of land use and land cover illustrated in Figure 12. The interesting parts for this project are highlighted in orange and will be presented in the following. </p>
 <p align="center">
@@ -862,10 +850,6 @@ <h3 id="34-training-and-testing-plan">3.4 Training and testing plan<a class="hea
 <li>outputs of the best performing temporal-spatial module, followed by FCN training for the integration module. </li>
 </ul>
 <p>The extra information gain from the temporal-spatial module will be studied by comparison with image-level performance only. The image-level data contain multi-class classification prediction and its confidence. We can calculate the change probability according to the probability of each class. Therefore, the weighted metric can also be applied at the image-level only. Then, the RF and FCN are tested for the integration module which combines various types of information sources. </p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="4-experiments">4. Experiments<a class="headerlink" href="#4-experiments" title="Permanent link">&para;</a></h2>
 <p>The Experiments section covers the results obtained when performing the <a href="#34-training-and-testing-plan">planned simulations</a> for the temporal-spatial module and the integration module. </p>
 <h3 id="41-temporal-spatial-module">4.1 Temporal-spatial module<a class="headerlink" href="#41-temporal-spatial-module" title="Permanent link">&para;</a></h3>
@@ -1214,25 +1198,13 @@ <h3 id="42-integration-module">4.2 Integration module<a class="headerlink" href=
 </table>
 <p>The study demonstrates that the image-level contains more information related to change detection compared with temporal-spatial neighbors (<em>FCN</em> row in the Table 5). However, performance improvement from the temporal-spatial module when combined with image-level data, achieving 0.438 in weighted metric in the end (<em>FCN+RF</em> and <em>FCN+FCN</em>).</p>
 <p>Regarding the composition of different models for the two modules, FCN is proved to be the best one for the temporal-spatial module, while RF and FCN have similar performance in the integration module. The choice of integration module could be influenced by the data format of other potential modules. This will be further studied by the FSO team.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="5-conclusion-and-outlook">5. Conclusion and outlook<a class="headerlink" href="#5-conclusion-and-outlook" title="Permanent link">&para;</a></h2>
 <p>This project studied the potential of historical and spatial neighbor data in change detection task for the fifth interpretation process of the areal statistic of FSO. For the evaluation of this specific project, a weighted metric was defined by the FSO team. The temporal-spatial information was proved not to be as powerful as image-level information which directly detects change within visual data. However, an efficient prototype was built with 6% performance improvement in weighted metric combining the temporal-spatial module and the image-level module. It is validated that integration of modules with different source information can help to enhance the final capacity of the entire workflow.</p>
 <p>The next research step of the project would be to modify the current implementation of ConvRNN. If the numerical relationship is removed from the synthetic image data, ConvRNN should have similar performance as FCN theoretically. Also, CNN is worth trying to validate whether the temporal pattern matters in this dataset. Besides, by changing the size of the synthetic images, we can figure out how does the number of neighbour tiles impact the model performance.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <!--## 6. Acknowledgements
 
 We are very grateful to everyone who participated in this project and helped us achieve our goals. We thank the Swiss Federal Statistical Office for submitting this project to the STDL and for providing us with the necessary domain expertise to complete it. Special attention is given to the beneficiaries for their regular assistance and supervision. We congratulate Shanci Li (Uzufly for STDL) for his innovative ideas and technical realization of the project, and Clotilde Marmy (Exolabs for STDL) for her suggestions during the research process and for her review of the code and documentation. We also thank Alessandro Cerioni (State of Geneva for the STDL) for his wise technical advice and his thoroughness. Finally, we thank Roxane Pott (swisstopo for the STDL) for her leadership and project management, and Raphael Rollier (swisstopo for the STDL) for his coordination and general project communication.
 
-
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
 -->
 
 <h2 id="appendix">Appendix<a class="headerlink" href="#appendix" title="Permanent link">&para;</a></h2>
diff --git a/PROJ-REGBL/image/separator.gif b/PROJ-REGBL/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-REGBL/image/separator.gif and /dev/null differ
diff --git a/PROJ-REGBL/index.html b/PROJ-REGBL/index.html
index 9f5ed63..56ead94 100644
--- a/PROJ-REGBL/index.html
+++ b/PROJ-REGBL/index.html
@@ -431,10 +431,6 @@ <h2 id="introduction">Introduction<a class="headerlink" href="#introduction" tit
 <p>The construction year of buildings turns out to be complicated to gather, as adding new buildings to the register already impose an important workload even for the simple information. In addition, in many cases, the construction year of the building is missing or can not be easily collected to update the register.</p>
 <p>The <em>Statistical Office</em> mandated the <em>STDL</em> to perform researches on the possibility to automatically gather the construction year by analysing the <em>swisstopo</em> [3] <em>National Maps</em> [4]. Indeed, the Swiss national maps are known for their excellency, their availability on any geographical area, and for their temporal cover. The national maps are made with a rigorous and well controlled methodology from the <em>1950s</em> and therefore they can be used as a reliable source of information to determine the buildings' construction year.</p>
 <p>The <em>STDL</em> was then responsible for performing the researches and developing a proof-of-concept to provide all the information needed to the <em>Statistical Office</em> for them to take the right decision on considering national maps as a reliable way of assigning a construction year for the buildings lacking information.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-project-specifications">Research Project Specifications<a class="headerlink" href="#research-project-specifications" title="Permanent link">&para;</a></h2>
 <p>Extracting the construction date out of the national maps is a real challenge, as the national maps are a heavy dataset, they are not easy to be considered as a whole. In addition, the <em>Statistical Office</em> needs the demonstration that it can be done in a reliable way and within a reasonable amount of time to limit the cost of such process. They are also subjected to strict tolerances on the efficiency of the construction years extraction through an automated process. The goal of at least <em>80</em>% of overall success was then provided as a constraint to the <em>STDL</em>.</p>
 <p>As a result, the research specifications for the <em>STDL</em> were:</p>
@@ -449,10 +445,6 @@ <h2 id="research-project-specifications">Research Project Specifications<a class
 <p>Assessing the results with a reliable metric to allow demonstrating the quality and reliability of the obtained construction years</p>
 </li>
 </ul>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-data-selected-areas">Research Data &amp; Selected Areas<a class="headerlink" href="#research-data-selected-areas" title="Permanent link">&para;</a></h2>
 <p>In this research project, two datasets were considered: the building register itself and the national maps. As both datasets are heavy and complex, considering them entirely for such a research project would have been too complicated and unnecessary. It was then decided to focus on four areas selected for their representativeness of Swiss landscape:</p>
 <ul>
@@ -585,10 +577,6 @@ <h3 id="national-maps">National Maps<a class="headerlink" href="#national-maps"
 </div>
 
 <p>One can see that a large portion of the <em>20th</em> century can be covered using the maps with a very good resolution of around five to six years between the maps.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-approaches">Research Approaches<a class="headerlink" href="#research-approaches" title="Permanent link">&para;</a></h2>
 <p>In this research project, the main focus was put on the national maps to extract the construction year of buildings as the maps are sources on which we can rely and assess the results. The only drawback of the maps is their limited temporal coverage, as they only start to be available in the <em>1950s</em>.</p>
 <p>This is the reason why another experimental approach was also added to address the cases of building being built before the <em>1950s</em>. This secondary approach focused on a statistical methodology to verify to which extent it could be possible to assign a construction date even in the case no maps are available.</p>
@@ -601,10 +589,6 @@ <h2 id="research-approaches">Research Approaches<a class="headerlink" href="#res
 </li>
 </ul>
 <p>The statistical analysis allows then to consider buildings that were detected on all maps, meaning their construction is older than the oldest available map, to assign them an estimation of their construction year, knowing they had to be older than the oldest map.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-approach-national-maps">Research Approach: National Maps<a class="headerlink" href="#research-approach-national-maps" title="Permanent link">&para;</a></h2>
 <p>In order to detect construction year of buildings, we need to be able to track them down on the maps across the temporal coverage. The <em>RBD</em> is providing the reference list of the building, each coming with a federal identifier (<em>EGID</em>) and a position. This position can then be used to track down the building on maps for its appearance or morphological change.</p>
 <p>As the maps are already selected, as the research areas, this research approach can be summarised in the following way:</p>
@@ -888,10 +872,6 @@ <h3 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Pe
 <p>In this approach, it turns out that developing the proof-of-concept was the easy part. Indeed, finding a metric and demonstrating its representativeness and reliability was much more complicated. Indeed, as the two datasets can not be considered as fully reliable in the first place, a strategy had to be defined in order to be able to demonstrate that the chosen metric was able to assess our result in the way expected by the <em>Statistical Office</em>.</p>
 <p>In addition, the metric only required one additional hypothesis on top of the two datasets. This hypothesis, consisting in assuming that the <em>synchronous</em> sub-set was a quasi-sub-set of the <em>absolutely correct construction years</em>, can be assumed to be reasonable. Nevertheless it is important to emphasise that it was necessary to make it, leading us to remains critic and careful whilst reading the results given by our metric.</p>
 <p>The developed proof-of-concept was developed in <em>C++</em>, leading to an efficient code able to be used for the whole processing of Switzerland without the necessity to deeply modify it.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="research-approach-statistical">Research Approach: Statistical<a class="headerlink" href="#research-approach-statistical" title="Permanent link">&para;</a></h2>
 <p>As the availability of the topographic/national maps does not reach the integrity of all building's year of construction in the registry, an add-on was developed to infer this information, whenever there was this need for extrapolation. Usually, the maps availability reaches the 1950s, whilst in some cities the minimum year of construction can be in the order of the 12th century, e.g. The core of this statistical model is based on the Concentric Zones Model (Park and Burgess, 1925)[6] extended to the idea of the growth of the city from the a centre (Central Business District - CBD) to all inner areas. The concept behind this statistical approach can be seen below using the example of a crop of Basel city:</p>
 <div align="center" style="font-style: italic">
@@ -978,10 +958,6 @@ <h3 id="results_1">Results<a class="headerlink" href="#results_1" title="Permane
 <h3 id="conclusion_1">Conclusion<a class="headerlink" href="#conclusion_1" title="Permanent link">&para;</a></h3>
 <p>This add-on allows extrapolating the predictions to beyond the range of the topographical maps. Its predictions are limited, but the accuracy reached can be considered reasonable, once there is a considerable lack of information in this prediction range. Nor the dates in the <em>RBD</em>, nor the topographic maps can be fully trusted, ergo <em>15.6</em> years of error for the older buildings is acceptable, especially by considering the relative lack of spread in errors distribution. If a suggestion for improvement were to be given, a method for smoothing the intYEARpolator predictions could be interesting. This would possibly shift the distribution of the error into closer to a gaussian with mean zero. The dangerous found when searching for such an approach is that the year of construction of buildings does not seem to present a smooth surface, despite the spatial dependence. Hence, if this were to be considered, a balance between smoothing and variability would need to found.</p>
 <p>We also demonstrated a completely different perspective on how the spatial and temporal dimensions can be joined as the random variable predicted through spatial methodology was actually time. Therefore a strong demonstration of the importance of time in spatially related models and approaches was also given. The code for the intYEARpolator was developed in Python and it runs smoothly even with this quite big proportion of data. The singular case it can be quite time-demanding is in the case of high proportion of prediction points (missing values). It should also be reproducible to the whole Switzerland with no need for modification. A conditional argument is the use of concentric zones, that can be excluded in case of a total different pattern of processing time.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="reproduction-resources">Reproduction Resources<a class="headerlink" href="#reproduction-resources" title="Permanent link">&para;</a></h2>
 <p>The source code of the <em>proof-of-concept</em> for national maps can be found here :</p>
 <ul>
diff --git a/PROJ-TGLN/image/separator.gif b/PROJ-TGLN/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-TGLN/image/separator.gif and /dev/null differ
diff --git a/PROJ-TGLN/index.html b/PROJ-TGLN/index.html
index 33a7ebf..cb024c9 100644
--- a/PROJ-TGLN/index.html
+++ b/PROJ-TGLN/index.html
@@ -425,10 +425,6 @@ <h1 id="updating-the-cultivable-area-layer-of-the-agricultural-office-canton-of-
 March 2021 to June 2021 - Published on July 7, 2021</p>
 <p><br /></p>
 <p><em><strong>Abstract</strong>: The Cultivable agricultural area layer ("LN, Landwirtschaftliche Nutzfläche") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions.</em></p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="1-introduction">1    Introduction<a class="headerlink" href="#1-introduction" title="Permanent link">&para;</a></h2>
 <h3 id="11-background">1.1 Background<a class="headerlink" href="#11-background" title="Permanent link">&para;</a></h3>
 <p>Switzerland's direct payment system is the basis for sustainable, market-oriented agriculture. The federal government supports local farms in the form of various types of contributions and enables farming families to claim an adequate income. (cf. Art. 104 BV)</p>
@@ -456,10 +452,6 @@ <h3 id="12-silage-bales">1.2 Silage Bales<a class="headerlink" href="#12-silage-
 <p>One of several features of interest specifically excluded from the subsidized cultivable LN area are silage hay bales. These bales are processed and compacted fermenting grass cuttings wrapped in plastic foil. They often roughly measure 1 - 2 cubic meters in volume and are weighed in at around 900kg. They are mainly used as animal food during winter when no fresh hay is available. Farmers are encouraged to compactly («discretely») stack them in regular piles at few locations rather than keeping them in scattered collections consuming large areas. </p>
 <p>The agricultural office can assess the silage bale stack locations and sizes in order to approve the application for subsidies, since areas where silage bales are stored do not count into the cultivable LN area. Farmers can specify those areas where they must not receive contributions for in a specialized webGIS system by digitizing them manually with the attribute «code 898». For validation purposes specialists are manually evaluating aerial imagery and conduct field visits. The process of aerial imagery evaluation is arduous and monotonous and could therefore greatly profit from automatization. </p>
 <p>The agricultural office of the Canton of Thurgau (LWA) requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area. The delivered dataset should be compatible with their webGIS workflow and should be made available with new aquisitions of aerial imaging campaigns. Having such detections readily available would reduce the workload of the responsible official by directing the monitoring to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. This project therefore aims at the development of an efficient silage bale detection algorithm which offers a highly accurate performance and can be quickly deployed over imaged areas as large as the complete canton of Thurgau (approx. 992 km²). </p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="2-method">2    Method<a class="headerlink" href="#2-method" title="Permanent link">&para;</a></h2>
 <h3 id="21-overview">2.1 Overview<a class="headerlink" href="#21-overview" title="Permanent link">&para;</a></h3>
 <p>Sileage bale stacks are clearly visible on the newest 2019 layer of the 10cm Swissimage orthophoto provided by Swisstopo. A few hundred of these stacks were manually digitized as vector polygons with QGIS in a semi-automatic approach.</p>
@@ -527,10 +519,6 @@ <h3 id="26-post-processing">2.6 Post-Processing<a class="headerlink" href="#26-p
 <p>Curve polygons contain a high number of vertex points, which is why a simplification operation can be performed afterwards. 
 The intersection with the LN layer required a preparation of that dataset. First, the perimeters of all LN polygons in Thurgau, stemming from the cadastre, were intersected with the layer "LN difference". Areas which contained the attribute "No LN" in the difference layer were therefore removed, areas with the attribute "LN" or "To be checked" were kept or if necessary (if not yet available) added to the LN dataset. Areas excluded by farmers from the subsidy themself (so-called "layer code 898") were removed from the LN polygons. The silage bale detections were now intersected (clipped) with all remaining LN areas such that only those portions of the detections remained that were present within the LN perimeter.
 For all these leftover detection polygons, the area is calculated and added as an attribute to the polygon. With a threshold operation all silo bale stacks with an area below 20 m2 are filtered out of the dataset in order to provide only economically relevant detections.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="3-results">3    Results<a class="headerlink" href="#3-results" title="Permanent link">&para;</a></h2>
 <h3 id="31-metrics-and-evaluation">3.1 Metrics and Evaluation<a class="headerlink" href="#31-metrics-and-evaluation" title="Permanent link">&para;</a></h3>
 <p align="center">
@@ -615,10 +603,6 @@ <h3 id="33-relevant-features-for-delivery">3.3 Relevant Features for Delivery<a
 </i>
 </p>
 
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="4-discussion">4    Discussion<a class="headerlink" href="#4-discussion" title="Permanent link">&para;</a></h2>
 <h3 id="41-feedback-by-the-agricultural-office">4.1 Feedback by the Agricultural Office<a class="headerlink" href="#41-feedback-by-the-agricultural-office" title="Permanent link">&para;</a></h3>
 <p>The contact person at the agricultural office, Mr. T. Froehlich describes the detections as very accurate with a very low percentage of wrong detections. As a GIS product the detections layer can be used in the standard workflow in order to cross-check base datasets or to perform updates and corrections.</p>
@@ -626,10 +610,6 @@ <h3 id="41-feedback-by-the-agricultural-office">4.1 Feedback by the Agricultural
 <p>Most farmers adhere to the policies and false declaration of areas followed by sanctions is extremely rare. Silage bales are therefore not the first priority when monitoring the advancements and updates considering the LN layer. Nevertheless these new detections allow the end users at the agricultural office to direct their eyes more quickly at relevant hotspots and spare them some aspects of the long and tidious manual search that was performed in the past.</p>
 <h3 id="42-outlook">4.2 Outlook<a class="headerlink" href="#42-outlook" title="Permanent link">&para;</a></h3>
 <p>Silage bales are by far not the only object limiting the extent of the cultivable subsidized land. A much larger area is consumed by farm yards – heterogenous spaces around the central farm buildings. Monitoring the growth of these spaces into the LN layer would greatly diminuish the manual workload at the agricultural office. As these spaces might also be detectable by a similar approach, this project will continue to investigate the potential of the STDL Object Detection Framework now into this direction.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="references">References<a class="headerlink" href="#references" title="Permanent link">&para;</a></h2>
 <ul>
 <li>
diff --git a/PROJ-TGPOOL/image/separator.gif b/PROJ-TGPOOL/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-TGPOOL/image/separator.gif and /dev/null differ
diff --git a/PROJ-TGPOOL/index.html b/PROJ-TGPOOL/index.html
index b2d2fc3..28849a3 100644
--- a/PROJ-TGPOOL/index.html
+++ b/PROJ-TGPOOL/index.html
@@ -411,18 +411,10 @@ <h1 id="swimming-pool-detection-for-the-canton-of-thurgau">SWIMMING POOL DETECTI
 January 2021 to April 2021 - Published on April 21, 2021</p>
 <p><br /></p>
 <p><em><strong>Abstract</strong>: The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour.</em></p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="introduction">Introduction<a class="headerlink" href="#introduction" title="Permanent link">&para;</a></h2>
 <p>Until February 2021 the Swiss Territorial Data Lab developed an approach based on Mask RCNN Deep Learning algorithms for the detection of objects on aerial images, with swimming pools serving as a demonstration object. The official cadastres of the Canton of Thurgau include – among many other objects – the registration of larger private swimming pools that are permanently anchored in the ground. </p>
 <p>The challenge is to keep the cadastre up to date on a regular basis which is usually done manually by surveying or verification with aerial imagery. Because the Canton of Thurgau (unlike the Canton of Geneva) does not maintain an own specific register of swimming pools, this study primarily serves as a technology demonstration. </p>
 <p>A secondary goal encompasses detailed knowledge transfer from the data scientist team at the STDL to the cantonal authorities such as providing insight and interpretation guidance into the performance metrics and raising awareness for the prerequisites of the detector framework.  </p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="methodology">Methodology<a class="headerlink" href="#methodology" title="Permanent link">&para;</a></h2>
 <h3 id="process-overview">Process Overview<a class="headerlink" href="#process-overview" title="Permanent link">&para;</a></h3>
 <p align="center">
@@ -523,10 +515,6 @@ <h4 id="dataset-split">Dataset Split<a class="headerlink" href="#dataset-split"
 <h3 id="inference-and-assessment">Inference and Assessment<a class="headerlink" href="#inference-and-assessment" title="Permanent link">&para;</a></h3>
 <p>After training, tile by tile the entire “Prediction AoI” as well as the ground truth datasets presented to the final model for prediction generation. From a minimum confidence threshold up to 100% the model produces a segmentation mask for each swimming pool detection delimiting its proposed outer boundary. This boundary can be vectorized and transformed back from image space into map coordinates during post-processing. Through this process we can accumulate a consistent GIS-compatible vector layer for visualization, counting and further analysis. </p>
 <p>In case of the ground truth data the resulting vector layer can be intersected with the original input data (especially the “Test Subset”) to obtain unbiased model performance metrics. In case of a well-performing model the resulting vector layer can then be intersected with the “Prediction AoI”-derived Thurgau dataset to identify missing or surplus swimming pools in the cadastre.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="results">Results<a class="headerlink" href="#results" title="Permanent link">&para;</a></h2>
 <h3 id="metrics-and-model-selection">Metrics and Model Selection<a class="headerlink" href="#metrics-and-model-selection" title="Permanent link">&para;</a></h3>
 <p align="center">
@@ -579,10 +567,6 @@ <h3 id="false-positives">False Positives<a class="headerlink" href="#false-posit
 <i>“False Positive” detections – (Top) Two clear examples of detected swimming pools that are missing in the cadastre. (Bottom Left) More ambiguous examples of detected swimming pools which might be missing in the cadastre. (Bottom Right) A clear error of the detector misclassifying a photovoltaic installation as a swimming pool.  </i>
 </p>
 
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">&para;</a></h2>
 <h3 id="manual-evaluation">Manual Evaluation<a class="headerlink" href="#manual-evaluation" title="Permanent link">&para;</a></h3>
 <p>In the city of Frauenfeld a sample district was chosen for manual evaluation by a STDL data scientist. Even though this task should ideally be performed by a local expert this analysis does provide some insight on the potential errors currently existing within the cadastre as well as the object detection quality. Within the sampled area a total of 99 identifiable swimming pool objects were found to be present.</p>
@@ -596,10 +580,6 @@ <h3 id="manual-evaluation">Manual Evaluation<a class="headerlink" href="#manual-
 <h3 id="interpretation">Interpretation<a class="headerlink" href="#interpretation" title="Permanent link">&para;</a></h3>
 <p>We can conclude that the use of annotation data gathered in another canton of Switzerland allows for highly accurate predictions in Thurgau using the freely and publicly available SWISSIMAGE dataset. We demonstrate that such a transferrable approach can therefore be applied within a relatively short time span to other cantons without the effort of manually digitizing objects in a new area. This is supported by the assumption that SWISSIMAGE is of the same consistent radiometrical and spatial quality we see in Thurgau over the whole country.</p>
 <p>Manual evaluation will stay paramount before authorities take for example legal action or perform updates and changes to the cadastre. Nevertheless a great amount of workload reduction can be achieved by redirecting the eyes of the experts to the detected or undetected areas that are worth looking at.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="references">References<a class="headerlink" href="#references" title="Permanent link">&para;</a></h2>
 <ul>
 <li>
diff --git a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-ComplexCase.svg b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-ComplexCase.svg
index dda1a10..3697f3c 100644
--- a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-ComplexCase.svg
+++ b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-ComplexCase.svg
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Do not edit this file with editors other than diagrams.net -->
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than diagrams.net -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
 <svg xmlns="http://www.w3.org/2000/svg" style="background-color: rgb(255, 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="703px" height="401px" viewBox="-0.5 -0.5 703 401" content="&lt;mxfile host=&quot;app.diagrams.net&quot; modified=&quot;2022-02-15T15:55:22.428Z&quot; agent=&quot;5.0 (Windows)&quot; version=&quot;16.5.3&quot; etag=&quot;4tw-Gp-kSOnj0WY2eZZD&quot; type=&quot;google&quot;&gt;&lt;diagram id=&quot;DYUd112QM_4DImj04pT7&quot;&gt;7ZlNf5sgGMA/TY7NT0CNHpu03Q7bqYedaSSG34w4xCbtpx8oGkXSJIumW1cvxYcX4f+88TQTtNjsvnCcrb+ziCQT6ES7CbqbQIiAG8g/SvJSSSCaaUnMaVTJwF7wSF+JFjpaWtCI5J2BgrFE0KwrXLI0JUvRkWHO2bY7bMWS7lczHJOe4HGJk770B43EupIGnrOXfyU0XtdfBo7u2eB6sBbkaxyxbUuE7idowRkTVWuzW5BE0au5VPMeDvQ2G+MkFadMgNWEZ5wU+mx6X+KlPixnRRoRNd6ZoPl2TQV5zPBS9W6lfqVsLTaJfAOyuaJJsmAJ4/I9ZakcNM8FZz8bTvKEc/1NwgXZHdw3aGhIOyJsQwR/kUO0ydy4ria43StgVmNet+CjeiDWSo+bxfZcZEOjsWNCxzHJCdL8yHFEOM8qm1zRncI6X7FUPOANTdTZvhVLGmG59IKlOVOLl/3aB6BjZ3wJUT2hAdoQhn3C0LUQhkMQdj8+YRBOw87jd4GjMJx6/hWZe8eZy/iUqeaSszx/wvw4/H24AH9AfgjMpiED38oVQBvXAbD6PaxAhf4eW3lEYRhuQuNU0ZZHJYq1AkFl3rnVHRsaRSU3TnL6ip/KpRS3jNFUlHv25hPvTq1VCJZXZIHNxE9RjN6r6RIRWeEiEQOpa+Ya6pp5NnV5ttg+gLZmZzrBKR4gsKBM6evG9QyWwJoRW9oBl2bIekIQTmfI2T/QCO+hM3XaTx+5LfAMEXcCC3K/tKeIPnfQ+78KdRMq+dxU1nwrBwCY7UpKdb9sxeV8ImTkl9FHXgg5IfWyT/yiVetl5LnKDdbSo/5cKdrIJJbkUvt9QlbiLa+3GV73enZGvB3K0CAKz7asUNmmzbimrnu5fYVjurRzdYduuAbWPDaWl9bFVgtjXBpb6VyF/HztZJ9+UDI33cCuLgAP2f4AKgPjJ7O+rWeEU7lVwtUqNI3bN46WkwyAODRv0F3iCFiJBxYHCYagfULxfCbt44FliIB9pA6RlnxVjCcU138jRhD40/r22KCb9Wvm0bj9ByVzA6pxcQvg8Qpk8DErZNcxK2TLP9NGK4/BZ318lrKQWR+71yuOwRWq4/e8UCDf8AQYXjGA2+rgfyDxuT1owRWhjVrcvb9FetDMeJbYPBZc2C/5PkK+80yDBRYvHy3fwX5R9pnv3lBWaOa7cLR8J1/3P7WWfa1frNH9bw==&lt;/diagram&gt;&lt;/mxfile&gt;"><defs/><g><rect x="1" y="59" width="700" height="340" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="561" cy="199" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><ellipse cx="141" cy="219.44" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 141 329.44 L 141 349.44 M 261 329.44 L 261 349.44 M 141 339.44 L 261 339.44" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="175" y="323.44" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 338px; margin-left: 200px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="200" y="344" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 190.73 25 L 206.73 25 L 206.73 9 L 214.73 9 L 214.73 25 L 230.73 25 L 230.73 33 L 214.73 33 L 214.73 49 L 206.73 49 L 206.73 33 L 190.73 33 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,210.73,29)" pointer-events="all"/><rect x="240" y="9" width="99.73" height="40.44" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 98px; height: 1px; padding-top: 29px; margin-left: 242px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><div style="font-size: 12px">detected tree<br style="font-size: 12px" /></div></div></div></div></foreignObject><text x="242" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">detected tree&#xa;</text></switch></g><path d="M 1 25.44 L 17 25.44 L 17 9.44 L 25 9.44 L 25 25.44 L 41 25.44 L 41 33.44 L 25 33.44 L 25 49.44 L 17 49.44 L 17 33.44 L 1 33.44 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><rect x="50" y="9.44" width="129.73" height="40" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 128px; height: 1px; padding-top: 29px; margin-left: 52px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">ground truth tree</div></div></div></foreignObject><text x="52" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">ground truth tree</text></switch></g><path d="M 101 211.44 L 133 211.44 L 133 179.44 L 149 179.44 L 149 211.44 L 181 211.44 L 181 227.44 L 149 227.44 L 149 259.44 L 133 259.44 L 133 227.44 L 101 227.44 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,141,219.44)" pointer-events="all"/><path d="M 31 281.44 L 63 281.44 L 63 249.44 L 79 249.44 L 79 281.44 L 111 281.44 L 111 297.44 L 79 297.44 L 79 329.44 L 63 329.44 L 63 297.44 L 31 297.44 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><path d="M 187.27 261 L 219.27 261 L 219.27 229 L 235.27 229 L 235.27 261 L 267.27 261 L 267.27 277 L 235.27 277 L 235.27 309 L 219.27 309 L 219.27 277 L 187.27 277 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><ellipse cx="401" cy="249" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 401 359 L 401 379 M 521 359 L 521 379 M 401 369 L 521 369" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="435" y="353" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 368px; margin-left: 460px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="460" y="374" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 361 241 L 393 241 L 393 209 L 409 209 L 409 241 L 441 241 L 441 257 L 409 257 L 409 289 L 393 289 L 393 257 L 361 257 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,401,249)" pointer-events="all"/><path d="M 461 251 L 493 251 L 493 219 L 509 219 L 509 251 L 541 251 L 541 267 L 509 267 L 509 299 L 493 299 L 493 267 L 461 267 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><path d="M 521 191 L 553 191 L 553 159 L 569 159 L 569 191 L 601 191 L 601 207 L 569 207 L 569 239 L 553 239 L 553 207 L 521 207 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,561,199)" pointer-events="all"/><path d="M 561 309 L 561 329 M 681 309 L 681 329 M 561 319 L 681 319" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="595" y="303" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 318px; margin-left: 620px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="620" y="324" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
\ No newline at end of file
diff --git a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-GraphComponents.svg b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-GraphComponents.svg
index ab39a42..53581bf 100644
--- a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-GraphComponents.svg
+++ b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-GraphComponents.svg
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Do not edit this file with editors other than diagrams.net -->
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than diagrams.net -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
 <svg xmlns="http://www.w3.org/2000/svg" style="background-color: rgb(255, 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="702px" height="401px" viewBox="-0.5 -0.5 702 401" content="&lt;mxfile host=&quot;app.diagrams.net&quot; modified=&quot;2022-02-15T15:57:01.146Z&quot; agent=&quot;5.0 (Windows)&quot; version=&quot;16.5.3&quot; etag=&quot;3GU5rOr0bb6NVkk9S9pJ&quot; type=&quot;google&quot;&gt;&lt;diagram id=&quot;4A3x5x9yCVlqGh8H7L00&quot;&gt;7VtNc6M4EP01PsaFEGA4TuxJ5rBbNVVJ1e4cCcg2NRh5hZzY8+tXAgnQhxOcgMebtS9BDUjivSd1q6VM4Hyzvyfxdv0nTlE+cZ10P4GLieuCyIfsD7cchGUGvNqyIlkqbK3hIfuFhNER1l2WolJ5kGKc02yrGhNcFCihii0mBL+ojy1xrra6jVfIMDwkcW5a/8pSuq6toe+09m8oW61ly8ARdzaxfFgYynWc4peOCX6dwDnBmNZXm/0c5Rw9iUv93t2Ru03HCCponxfc+oXnON+JbxP9ogf5sQTvihTx550JvH1ZZxQ9bOOE331h/DLbmm5yVgLscpnl+RznmLBygQv20G1JCf7Z4MS+8Fa0iQhF+6P9Bg0aTEcIbxAlB/aIkMyNBPClxX8mUV53sIeeMMaC81VTVwsLuxDI2FGCb6PEXmDqQ28jFJfbWpLLbM9RvV3igt7Fmyznn/bHLsnSmFU9x0WJeeXVfTEEXMcO8UcAFS94ngmo61kAdYcA1Pv8gEqBHmRx6sGo8wvPCLf/NtxsItryy4TgsnyKydu4t/MCeAfoAyAMPA1in2HsGbAC1wbrAKgGBqqAT/EGtOwLqSbZPFsVHGz2pYhDzXHImH/5Im5ssjStYCOozH7FT1VVHLYtzgpa9dm/nfgLXteO4rIGFtjE3YcX0Vd9MKRoGe9yOhBbM09ly/NsbPm2OXwAsmYnDoE++qcxzTCn68bzrY5ui0jGeooIryUrVl2ORLu605y4MPVRmHpNhZ07ofsEg2AYPqJoGik/hR0WsdjYCS3shAOwEw7Ojo6xSc5vQR2qUxaYnRXm6P8CMwiDqRzyEmrfDHDGwlmuUz51fBOqUrbAO15AA8CnjGg8R4toQhPU0cIZYK4Fr/HMK1xBLZ6ZnS+YAT0WpJcSzSyXKEgS24SfzqInZ6CRAwPNscIzzvY9VrNju9XzoOzpKFuSBqOhfOoi9tNr3tdSDBZnMRoZ5tr3M/hfX9O3a5lFxvO/5hL16n9f4SrS/K97Rv/bY72KivQL32pgJcyeO6Z0jhHaZ/Rvfj31RelHVfIiT5QX+86ji0On8F1OUMJW0phQreHKdpflsnXWtU7pWH4epdomSIl3JBGmsDddb9AhbQTlbC5+Vlu0cSRa+M6F28lmqAMXAo3luu/ipZZoox49pwj01QqDcoWoUVGlmOar+4mox2r8BBGNSPzFsNzkXCU70eXTLF1Dh+aFSbQ5p6uhg1i3W5by/ed+m/dVNaRM7t9Q/ox4TaoXAN5AEfvMiNhtqbBgJG/rmhmEBbjSwveqVVrsieDRaDGTEAt4pcX1oR7rn5UVM99w/zgILW1I+F9lxtPmsaaKc/BiZh7uH6+zWJtjfn1neDRazFTF/ePV5/N4zdiWcc/s9nskLgZYucnSxa3bZK7yYkJ6qDk2NnSnTvcH1Rr7Rvj6VgrfaXW8tlpXrXbAeL/HSYNRl3WMV3LoiJIXf6jFVpZV6dAtmcLsKbMaQmHyL0xmvi4HPQvaW1d6fMwiMad7sCsYTVg9kk7Jjjw3CdSOyoTfOK6yn4gm60YGUk4t/50U9nzOx49VGWlcrpvmm6Ot6kQJZ6AzVYKTJ8oek5x7YeJzQzVVCR3/feJztVjzxoW91MZkEB86j4ms7ysdBuqk7CiniNlFXeO7pTz8QRRjL6fHFlonwPnoseTm3Ek0nUHHcDOSr5nm3AIj8LEdmRjkCLPtSEpQrbzS7FmBPvhnx4+fV/jc1FsBX9gDwN3uK5TkfXa1qt5nozOhbNwzH0AQktU+kQ/VKqthH1Z1UFoHD6JztKQDhtCv71QNJTQXRqcqK+LStImrib8/pK9TT+ScNKSdsw9oiWsQTf0zjlIz/bWqtFaNrR1rXo6x6zCoMNdGgZ0t4B6T/smMsWL7zzm152v/xwl+/Rc=&lt;/diagram&gt;&lt;/mxfile&gt;"><defs/><g><rect x="1" y="59" width="700" height="340" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="561" cy="199" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><ellipse cx="141" cy="219.44" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 141 329.44 L 141 349.44 M 261 329.44 L 261 349.44 M 141 339.44 L 261 339.44" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="175" y="323.44" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 338px; margin-left: 200px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="200" y="344" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 101 211.44 L 133 211.44 L 133 179.44 L 149 179.44 L 149 211.44 L 181 211.44 L 181 227.44 L 149 227.44 L 149 259.44 L 133 259.44 L 133 227.44 L 101 227.44 Z" fill="#d5e8d4" stroke="#82b366" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,141,219.44)" pointer-events="all"/><path d="M 31 281.44 L 63 281.44 L 63 249.44 L 79 249.44 L 79 281.44 L 111 281.44 L 111 297.44 L 79 297.44 L 79 329.44 L 63 329.44 L 63 297.44 L 31 297.44 Z" fill="#d5e8d4" stroke="#82b366" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><path d="M 187.27 261 L 219.27 261 L 219.27 229 L 235.27 229 L 235.27 261 L 267.27 261 L 267.27 277 L 235.27 277 L 235.27 309 L 219.27 309 L 219.27 277 L 187.27 277 Z" fill="#d5e8d4" stroke="#82b366" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><ellipse cx="401" cy="249" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 401 359 L 401 379 M 521 359 L 521 379 M 401 369 L 521 369" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="435" y="353" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 368px; margin-left: 460px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="460" y="374" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 361 241 L 393 241 L 393 209 L 409 209 L 409 241 L 441 241 L 441 257 L 409 257 L 409 289 L 393 289 L 393 257 L 361 257 Z" fill="#ffe6cc" stroke="#d79b00" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,401,249)" pointer-events="all"/><path d="M 461 251 L 493 251 L 493 219 L 509 219 L 509 251 L 541 251 L 541 267 L 509 267 L 509 299 L 493 299 L 493 267 L 461 267 Z" fill="#ffe6cc" stroke="#d79b00" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><path d="M 521 191 L 553 191 L 553 159 L 569 159 L 569 191 L 601 191 L 601 207 L 569 207 L 569 239 L 553 239 L 553 207 L 521 207 Z" fill="#ffe6cc" stroke="#d79b00" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,561,199)" pointer-events="all"/><path d="M 561 309 L 561 329 M 681 309 L 681 329 M 561 319 L 681 319" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="595" y="303" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 318px; margin-left: 620px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="620" y="324" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 73.12 286.84 L 138.88 221.12" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="stroke"/><ellipse cx="71" cy="288.96" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="141" cy="219" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><path d="M 224.41 267.49 L 143.59 220.51" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="stroke"/><ellipse cx="227" cy="269" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="141" cy="219" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><rect x="371" y="209.44" width="60" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 219px; margin-left: 372px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">D2</div></div></div></foreignObject><text x="401" y="224" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">D2</text></switch></g><rect x="111" y="179.44" width="60" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 189px; margin-left: 112px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">D1</div></div></div></foreignObject><text x="141" y="194" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">D1</text></switch></g><rect x="531" y="159.44" width="60" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 169px; margin-left: 532px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">D3</div></div></div></foreignObject><text x="561" y="174" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">D3</text></switch></g><rect x="471" y="300" width="60" height="20" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 310px; margin-left: 472px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GT3</div></div></div></foreignObject><text x="501" y="314" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">GT3</text></switch></g><rect x="41" y="329.44" width="60" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 339px; margin-left: 42px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GT1</div></div></div></foreignObject><text x="71" y="344" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">GT1</text></switch></g><rect x="197.27" y="309.44" width="60" height="20" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 319px; margin-left: 198px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GT2</div></div></div></foreignObject><text x="227" y="324" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">GT2</text></switch></g><path d="M 498.01 258.7 L 403.99 249.34" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="stroke"/><ellipse cx="501" cy="259" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="401" cy="249.04" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><path d="M 503.12 256.88 L 558.88 201.12" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="stroke"/><ellipse cx="501" cy="259" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="561" cy="199" rx="3" ry="3" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><path d="M 260.7 399 Q 282 279 271 56" fill="none" stroke="#cc0000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="6 6" pointer-events="stroke"/><path d="M 190.73 25 L 206.73 25 L 206.73 9 L 214.73 9 L 214.73 25 L 230.73 25 L 230.73 33 L 214.73 33 L 214.73 49 L 206.73 49 L 206.73 33 L 190.73 33 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,210.73,29)" pointer-events="all"/><rect x="240" y="9" width="99.73" height="40.44" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 98px; height: 1px; padding-top: 29px; margin-left: 242px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><div style="font-size: 12px">detected tree<br style="font-size: 12px" /></div></div></div></div></foreignObject><text x="242" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">detected tree&#xa;</text></switch></g><path d="M 1 25.44 L 17 25.44 L 17 9.44 L 25 9.44 L 25 25.44 L 41 25.44 L 41 33.44 L 25 33.44 L 25 49.44 L 17 49.44 L 17 33.44 L 1 33.44 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><rect x="50" y="9.44" width="129.73" height="40" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 128px; height: 1px; padding-top: 29px; margin-left: 52px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">ground truth tree</div></div></div></foreignObject><text x="52" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">ground truth tree</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
\ No newline at end of file
diff --git a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-TaggingInTheMostTrivialCase.svg b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-TaggingInTheMostTrivialCase.svg
index 854c4b1..b78c360 100644
--- a/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-TaggingInTheMostTrivialCase.svg
+++ b/PROJ-TREEDET/image/STDL-TreeDet-AssessmentScript-TaggingInTheMostTrivialCase.svg
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Do not edit this file with editors other than diagrams.net -->
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than diagrams.net -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
 <svg xmlns="http://www.w3.org/2000/svg" style="background-color: rgb(255, 255, 255);" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="703px" height="351px" viewBox="-0.5 -0.5 703 351" content="&lt;mxfile host=&quot;app.diagrams.net&quot; modified=&quot;2022-02-15T15:55:56.389Z&quot; agent=&quot;5.0 (Windows)&quot; version=&quot;16.5.3&quot; etag=&quot;1Ymyr_wxfz_mnzJu1-l-&quot; type=&quot;google&quot;&gt;&lt;diagram id=&quot;qLP7pWAbqrdydvM_HPSS&quot;&gt;7ZlLc5swEMc/Dcd4kHgfYyduD22nM+lMzzII0BQjKkTs5NNXgHhZSnBqnOlk6ktg9QD9/rurRTGszf74iaEi/UojnBnQjI6GdWdAaAHbF39qy1NrgZYnLQkjUWsDg+GBPGNpNKW1IhEuJx05pRknxdQY0jzHIZ/YEGP0MO0W02z61AIlWDE8hChTrT9JxNPW6jvmYP+MSZJ2TwambNmjrrM0lCmK6GFksu4Na8Mo5e3V/rjBWU2v49KO277Q2r8Ywzk/ZwBsBzyirJJrk+/Fn7rFMlrlEa77m4a1PqSE44cChXXrQegrbCnfZ+IOiMuYZNmGZpSJ+5zmotO65Iz+6jmJFa7lMzHj+Pjie4OehvAjTPeYsyfRRbrMjd/5wmEQwOswpyP4MJBGJEVP+skGLuJCotFjsuYxiQHC/fA8IlQWrU/G5FhjXcc051u0J1m9ti9VSCIkpt7QvKT15E27jAFo6hlfQlQOsE2wctpBHWMvAApjaAUaxvYCjO2Pzxj4Kw8Go593Clx16p7t4sCdeeAiPRX1ZchoWe4Qmyc/ZAtwIXYDWmbzW4i9JeBbU96Oq/IGUMd7AdyughvUO4LCXCyRn3hzRpK8VkEsFdca1CCI2I5uZcOeRFHDk+GSPKNdM1XNraAk5807O2vDuavnqjgtW+KgT84nnj5WIcIxqjKu0+ocbeWyzCUE9KBGQFcR0NHoZy2gn/fGcDknVjjihNYK3tjOCbJBnfHWORIBXLqVdgMCU3A1hx+cMvY1QaLLSUukJF/D2G28LyKPE9bu74p2XnnTOvSt6ABgcWywdO3iKmnGYy52BJGYRKnIMO6m3bGLZu2mEetqXrCzzob0bNxJUxf6GY75a4Gv87Rp4faGVLyUZ/Uu8ZorAU/rSyvbvtydgmuGrPnuAdtjdIKVoya+awVlV2mPMCaNbzWxVInHdzH13+3HG9CMXMC6ll5A0evH9+X3qmmpFvshDkNFYtGy8x3bMbXBUWBGxPIwq59L8mRUNY6jagFNgtPKeyqRp/ma9DXy+EvIc8Y39wequx1onn5XOq76XXm1shuo3+4fu+5eQjNXo9n7VdpAPQrY/gsJLEJl2ofYX2azBQ5qfHCavNRwulryUg8NLt9b3q7EfN21AGg4c1rj2u+4aainB9tvC3OPEPZjLXc39PEuPov7JEYWEMGCmmPJq3EXt8PZe9M2+heGdf8H&lt;/diagram&gt;&lt;/mxfile&gt;"><defs/><g><rect x="1" y="59" width="700" height="290" fill="none" stroke="rgb(0, 0, 0)" stroke-width="2" pointer-events="all"/><ellipse cx="522" cy="198" rx="119.50000000000001" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><ellipse cx="139.73" cy="199" rx="120" ry="120" fill="transparent" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 139.73 309 L 139.73 329 M 259.73 309 L 259.73 329 M 139.73 319 L 259.73 319" fill="#000000" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="173.73" y="303" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 318px; margin-left: 199px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="199" y="324" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 191.73 25 L 207.73 25 L 207.73 9 L 215.73 9 L 215.73 25 L 231.73 25 L 231.73 33 L 215.73 33 L 215.73 49 L 207.73 49 L 207.73 33 L 191.73 33 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,211.73,29)" pointer-events="all"/><rect x="241" y="9" width="170" height="40.44" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 168px; height: 1px; padding-top: 29px; margin-left: 243px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><div style="font-size: 12px">detected tree<br style="font-size: 12px" /></div></div></div></div></foreignObject><text x="243" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">detected tree&#xa;</text></switch></g><path d="M 1 25.44 L 17 25.44 L 17 9.44 L 25 9.44 L 25 25.44 L 41 25.44 L 41 33.44 L 25 33.44 L 25 49.44 L 17 49.44 L 17 33.44 L 1 33.44 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><rect x="51" y="9.44" width="130" height="40" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe flex-start; width: 128px; height: 1px; padding-top: 29px; margin-left: 53px;"><div style="box-sizing: border-box; font-size: 0px; text-align: left;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">ground truth tree</div></div></div></foreignObject><text x="53" y="33" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="12px">ground truth tree</text></switch></g><path d="M 99.73 191 L 131.73 191 L 131.73 159 L 147.73 159 L 147.73 191 L 179.73 191 L 179.73 207 L 147.73 207 L 147.73 239 L 131.73 239 L 131.73 207 L 99.73 207 Z" fill="#f8cecc" stroke="#b85450" stroke-width="2" stroke-miterlimit="10" transform="rotate(-45,139.73,199)" pointer-events="all"/><g transform="translate(-0.5 -0.5)rotate(-45 139.73000000000002 199)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 199px; margin-left: 101px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;">TP</div></div></div></foreignObject><text x="140" y="203" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle" font-weight="bold">TP</text></switch></g><path d="M 521.5 308 L 521.5 328 M 641.5 308 L 641.5 328 M 521.5 318 L 641.5 318" fill="#000000" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/><rect x="561.5" y="303" width="50" height="30" fill="rgb(255, 255, 255)" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 318px; margin-left: 587px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 20px; font-family: Lucida Console; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;">1 m</div></div></div></foreignObject><text x="587" y="324" fill="rgb(0, 0, 0)" font-family="Lucida Console" font-size="20px" text-anchor="middle">1 m</text></switch></g><path d="M 482 190 L 514 190 L 514 158 L 530 158 L 530 190 L 562 190 L 562 206 L 530 206 L 530 238 L 514 238 L 514 206 L 482 206 Z" fill="#f8cecc" stroke="#b85450" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="6 6" transform="rotate(-45,522,198)" pointer-events="all"/><g transform="translate(-0.5 -0.5)rotate(-45 522.0000000000005 197.99999999999977)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 198px; margin-left: 483px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;">FP</div></div></div></foreignObject><text x="522" y="202" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle" font-weight="bold">FP</text></switch></g><path d="M 29.73 261 L 61.73 261 L 61.73 229 L 77.73 229 L 77.73 261 L 109.73 261 L 109.73 277 L 77.73 277 L 77.73 309 L 61.73 309 L 61.73 277 L 29.73 277 Z" fill="#f8cecc" stroke="#b85450" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 269px; margin-left: 31px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;">TP</div></div></div></foreignObject><text x="70" y="273" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle" font-weight="bold">TP</text></switch></g><path d="M 322.5 111 L 354.5 111 L 354.5 79 L 370.5 79 L 370.5 111 L 402.5 111 L 402.5 127 L 370.5 127 L 370.5 159 L 354.5 159 L 354.5 127 L 322.5 127 Z" fill="#dae8fc" stroke="#6c8ebf" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="6 6" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 119px; margin-left: 324px;"><div style="box-sizing: border-box; font-size: 0px; text-align: center;" data-drawio-colors="color: rgb(0, 0, 0); "><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;">FN</div></div></div></foreignObject><text x="363" y="123" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle" font-weight="bold">FN</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
\ No newline at end of file
diff --git a/PROJ-TREEDET/image/separator.gif b/PROJ-TREEDET/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/PROJ-TREEDET/image/separator.gif and /dev/null differ
diff --git a/PROJ-TREEDET/index.html b/PROJ-TREEDET/index.html
index 119ad5f..a1040cd 100644
--- a/PROJ-TREEDET/index.html
+++ b/PROJ-TREEDET/index.html
@@ -473,10 +473,6 @@ <h1 id="tree-detection-from-point-clouds-over-the-canton-of-geneva"><span style=
 May 2021 to March 2022 - Published on April 22, 2022</p>
 <p><br/></p>
 <p><em><strong>Abstract</strong>: Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or "urban") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement.</em></p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="1-introduction">1. Introduction<a class="headerlink" href="#1-introduction" title="Permanent link">&para;</a></h2>
 <h3 id="11-context">1.1 Context<a class="headerlink" href="#11-context" title="Permanent link">&para;</a></h3>
 <p>Human societies benefits from the presence of trees in cities and their surroundings. More specifically, as far as urban contexts are concerned, trees deliver many ecosystem services such as:</p>
@@ -879,10 +875,6 @@ <h4 id="152-digital-forestry-toolbox-dft">1.5.2 Digital Forestry Toolbox (DFT)<a
 <li>stem detection (cf.&nbsp;<a href="https://mparkan.github.io/Digital-Forestry-Toolbox/tutorial-3.html">this other tutorial</a>).</li>
 </ol>
 <p>We refer the reader to the <a href="http://mparkan.github.io/Digital-Forestry-Toolbox/">official documentation</a> for further information.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="2-method">2. Method<a class="headerlink" href="#2-method" title="Permanent link">&para;</a></h2>
 <p>As already stated, in spite of the thorough and ambitious objectives of this project (cf. <a href="#12-objectives">here</a>), only the</p>
 <ul>
@@ -1407,10 +1399,6 @@ <h4 id="242-from-counts-to-metrics">2.4.2 From counts to metrics<a class="header
 <li>recall is optimal (= 1.0) iff all the ground truth trees are detected (no FNs).</li>
 </ul>
 <p>Typically, one cannot optimize both precision and recall for the same values of a set of parameters. Instead, they can exhibit opposite trends as a function of a given parameter (<i>e.g.</i> precision increases while recall decreases). In such cases, the F1-score would exhibit convexity and could be optimized.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="3-results-and-discussion">3. Results and discussion<a class="headerlink" href="#3-results-and-discussion" title="Permanent link">&para;</a></h2>
 <p>Figure 3.1 shows some of the tree detection trials we performed, using Terrascan and DFT. Each trial corresponds to a different set of parameters and is represented either by gray dots or colored diamonds in a precision-recall plot (see the image caption for further details).</p>
 <p align="center">
@@ -1697,10 +1685,6 @@ <h3 id="35-tree-detection-over-the-full-2021-high-density-lidar-dataset">3.5 Tre
 <i>Figure 3.10: Result of the application of the best performing Terrascan parameters to the full dataset.</i>
 </p>
 
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="4-conclusion-and-outlook">4. Conclusion and outlook<a class="headerlink" href="#4-conclusion-and-outlook" title="Permanent link">&para;</a></h2>
 <p>Despite all the efforts documented here above, the results we obtained are not as satisfactory as expected. Indeed, the metrics we managed to attain all sectors combined indicate that tree detections are neither reliable (low precision) nor exhaustive (low recall). Still, we think that results may be improved by further developing some ideas, which we sketch in the following.</p>
 <h3 id="41-further-the-dft-parameter-space-exploration">4.1 Further the DFT parameter space exploration<a class="headerlink" href="#41-further-the-dft-parameter-space-exploration" title="Permanent link">&para;</a></h3>
@@ -1738,16 +1722,8 @@ <h3 id="45-use-machine-learning">4.5 Use Machine Learning<a class="headerlink" h
 <li>using our best TerraScan/DFT model to segment the 3D point cloud;</li>
 <li>using 2D ground truth data to filter out wrong segmentations.</li>
 </ol>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="5-other-resources">5. Other resources<a class="headerlink" href="#5-other-resources" title="Permanent link">&para;</a></h2>
 <p>The work documented here was the object of a <em>Forum SITG</em> which took place online on March 29, 2022. Videos and presentation materials can be found <a href="https://ge.ch/sitg/calendrier/espace-public/des-solutions-digitales-et-innovantes-pour-mieux-connaitre-les-arbres-1635">here</a>.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="6-acknowledgements">6. Acknowledgements<a class="headerlink" href="#6-acknowledgements" title="Permanent link">&para;</a></h2>
 <p>This project was made possible thanks to a tight collaboration between the STDL team and some experts of the Canton of Neuchâtel (NE), the Canton of Geneva (GE), the <em>Conservatoire et Jardin botaniques de la Ville de Genève</em> (CJBG) and the University of Geneva (UNIGE). The STDL team acknowledges key contributions from Marc Riedo (SITN, NE), Bertrand Favre (OCAN, GE), Nicolas Wyler (CJBG) and Gregory Giuliani (UNIGE). We also wish to warmly thank Matthew Parkan for developing, maintaining and advising us on the <a href="https://mparkan.github.io/Digital-Forestry-Toolbox/">Digital Forestry Toolbox</a>.</p>
 
diff --git a/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning.fmw b/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning.fmw
index fc604df..429187a 100644
--- a/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning.fmw
+++ b/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning.fmw
@@ -1,2479 +1,2479 @@
-#! <?xml version="1.0" encoding="UTF-8" ?>
-#! <WORKSPACE
-#    Command-line to run this workspace:
-#        "C:\Program Files (x86)\FME2020\fme.exe" G:\STDL\LIDAR_2021\Scripts_et_Processus\LAS_Pretraitement_2021_cleaning_MNC_class10.fmw
-#              --SourceDataset_LAS "G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las"
-#              --SourceDataset_GEOTIFF "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
-#              --DestDataset_LAS "G:\STDL\LIDAR_PAST\Comp_pretrait_2021"
-#              --SourceDataset_GEOTIFF_3 "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif"
-#    
-#!   ATTR_TYPE_ENCODING="SDF"
-#!   BEGIN_PYTHON=""
-#!   BEGIN_TCL=""
-#!   CATEGORY=""
-#!   DESCRIPTION=""
-#!   DESTINATION="NONE"
-#!   DESTINATION_ROUTING_FILE=""
-#!   DOC_EXTENTS="7966.8 2320.58"
-#!   DOC_TOP_LEFT="-1168.89 -1826.3"
-#!   END_PYTHON=""
-#!   END_TCL=""
-#!   EXPLICIT_BOOKMARK_ORDER="false"
-#!   FME_BUILD_NUM="20596"
-#!   FME_DOCUMENT_GUID="d05b3aac-af8c-4859-a8d1-19db9ba773fc"
-#!   FME_DOCUMENT_PRIORGUID="e44176b6-c7b1-43ea-b9f4-2c32a085725b,c381042f-601f-4ea6-8815-83d7bd38b88a,f7a0bbd2-1db7-4a74-ae55-a63987eae69b,078fad80-7051-4100-84e6-4696f553bbea,51ed0ff3-37f8-45b3-9ff8-b75998c54609,02adf04c-e29a-4e52-92d5-abeca0924965,5ebbce74-be36-4454-a815-31428db8a416,e5e0372a-302f-4a0a-9427-792bc02785fd,bfca1a2a-75c0-4e6a-89e9-1ea630185fed,82dc1478-a881-4404-85db-ad0da5c5d130,ee5d0c1d-9e12-4458-a89a-2c815a0c0582,0154c093-9f4f-4ea3-a30c-d4bd3c69ca7e,ecba9442-0ed9-411b-b89d-7a7a54adedbf,44ced49f-ea1e-406c-a6d7-02600807ae35,6925ca57-8fec-4a5c-b0fc-0f1035cea0fd,3c3c63d6-737a-423f-85cc-d182978e7f3b,cbbcb408-ad67-4b86-88b7-503650200f32,4dbc4746-c035-40d8-ab8b-2eef885a849a"
-#!   FME_GEOMETRY_HANDLING="Enhanced"
-#!   FME_IMPLICIT_CSMAP_REPROJECTION_MODE="Auto"
-#!   FME_REPROJECTION_ENGINE="FME"
-#!   FME_SERVER_SERVICES=""
-#!   FME_STROKE_MAX_DEVIATION="0"
-#!   HISTORY=""
-#!   IGNORE_READER_FAILURE="No"
-#!   LAST_SAVE_BUILD="FME(R) 2020.1.0.1 (20200710 - Build 20596 - WIN32)"
-#!   LAST_SAVE_DATE="2022-03-01T17:21:47"
-#!   LOG_FILE=""
-#!   LOG_MAX_RECORDED_FEATURES="200"
-#!   MARKDOWN_DESCRIPTION=""
-#!   MARKDOWN_USAGE=""
-#!   MAX_LOG_FEATURES="200"
-#!   MULTI_WRITER_DATASET_ORDER="BY_ID"
-#!   PASSWORD=""
-#!   PYTHON_COMPATIBILITY="37"
-#!   REDIRECT_TERMINATORS="NONE"
-#!   SAVE_ON_PROMPT_AND_RUN="Yes"
-#!   SHOW_ANNOTATIONS="true"
-#!   SHOW_INFO_NODES="true"
-#!   SOURCE="NONE"
-#!   SOURCE_ROUTING_FILE=""
-#!   TERMINATE_REJECTED="YES"
-#!   TITLE=""
-#!   USAGE=""
-#!   USE_MARKDOWN=""
-#!   VIEW_POSITION="-186.74 613.573"
-#!   WARN_INVALID_XFORM_PARAM="Yes"
-#!   WORKSPACE_VERSION="1"
-#!   ZOOM_SCALE="82"
-#! >
-#! <DATASETS>
-#! <DATASET
-#!   IS_SOURCE="true"
-#!   ROLE="READER"
-#!   FORMAT="LAS"
-#!   DATASET="$(SourceDataset_LAS)"
-#!   KEYWORD="LAS_1"
-#!   MULTI_GEOM_ALLOWED="false"
-#!   ATTR_MAX_LENGTH="0"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="false"
-#!   EXPOSABLE_ATTRS="fme_fill_color char(50) fme_basename char(50) fme_secondary_axis number(31,15) las_type char(255) las_synthetic_returns logical multi_reader_full_id number(11,0) las_project_id char(36) fme_dataset char(50) las_version char(3) las_gps_time_type number(1,0) fme_rotation number(31,15) fme_color char(50) fme_start_angle number(31,15) fme_text_size number(31,15) fme_type char(50) fme_feature_type char(50) las_file_source_id number(6,0) las_file_creation_date date las_zlas_rearranged_points logical las_vertical_coordsys_code number(6,0) las_generating_software char(32) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_sweep_angle number(31,15) las_system_identifier char(32) fme_geometry char(50) multi_reader_id number(11,0) las_vertical_units_code number(6,0) multi_reader_keyword char(50) fme_text_string char(50) multi_reader_type char(50)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE="LISTBOX_ENCODED"
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FEATURE_TYPES=""
-#!   MAX_FEATURES=""
-#!   MAX_FEATURES_PER_FEATURE_TYPE=""
-#!   MIN_FEATURES=""
-#!   START_FEATURE=""
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="las file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="File1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="LAS File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the LAS file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the LAS file"
-#! />
-#! </DATASET>
-#! <DATASET
-#!   IS_SOURCE="true"
-#!   ROLE="READER"
-#!   FORMAT="GEOTIFF"
-#!   DATASET="$(SourceDataset_GEOTIFF)"
-#!   KEYWORD="GEOTIFF_1"
-#!   MULTI_GEOM_ALLOWED="false"
-#!   ATTR_MAX_LENGTH="0"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="true"
-#!   EXPOSABLE_ATTRS="geotiff_tifftag_software char(255) geotiff_subdataset_name char(255) geotiff_pyramid_num_levels integer geotiff_subdataset_description char(255) geotiff_type char(255) geotiff_pyramid_level{}.num_columns integer fme_type char(50) multi_reader_type char(50) geotiff_area_or_point char(255) fme_geometry char(50) geotiff_tifftag_xresolution float multi_reader_keyword char(50) geotiff_tifftag_artist char(255) geotiff_tifftag_imagedescription char(255) fme_text_string char(50) fme_text_size float geotiff_number_of_bits_per_cell decimal(1,0) multi_reader_full_id integer geotiff_tifftag_datetime datetime fme_basename char(50) fme_start_angle float fme_secondary_axis float geotiff_tifftag_minsamplevalue integer geotiff_private_keys{}.value char(255) geotiff_tifftag_yresolution float geotiff_photometric_interpretation char(10) fme_color char(50) geotiff_private_keys{}.id integer geotiff_tifftag_hostcomputer char(255) geotiff_compression_method char(9) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_tifftag_documentname char(255) fme_sweep_angle float fme_primary_axis float fme_dataset char(50) multi_reader_id integer geotiff_tifftag_copyright char(255) geotiff_tifftag_maxsamplevalue integer fme_rotation float fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_byte_order char(7) fme_feature_type char(50) geotiff_pyramid_level{}.num_rows integer geotiff_private_keys{}.type char(6)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE="LISTBOX_ENCODED"
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FEATURE_TYPES=""
-#!   MAX_FEATURES=""
-#!   MAX_FEATURES_PER_FEATURE_TYPE=""
-#!   MIN_FEATURES=""
-#!   START_FEATURE=""
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="tif file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="Raster1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="Raster File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="MIME_TYPE"
-#!   VALUE="image/TIFF"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the GeoTIFF file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the GeoTIFF file"
-#! />
-#! </DATASET>
-#! <DATASET
-#!   IS_SOURCE="true"
-#!   ROLE="READER"
-#!   FORMAT="GEOTIFF"
-#!   DATASET="$(SourceDataset_GEOTIFF_3)"
-#!   KEYWORD="GEOTIFF_2"
-#!   MULTI_GEOM_ALLOWED="false"
-#!   ATTR_MAX_LENGTH="0"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="true"
-#!   EXPOSABLE_ATTRS="geotiff_tifftag_software char(255) geotiff_subdataset_name char(255) geotiff_pyramid_num_levels integer geotiff_subdataset_description char(255) geotiff_type char(255) geotiff_pyramid_level{}.num_columns integer fme_type char(50) multi_reader_type char(50) geotiff_area_or_point char(255) fme_geometry char(50) geotiff_tifftag_xresolution float multi_reader_keyword char(50) geotiff_tifftag_artist char(255) geotiff_tifftag_imagedescription char(255) fme_text_string char(50) fme_text_size float geotiff_number_of_bits_per_cell decimal(1,0) multi_reader_full_id integer geotiff_tifftag_datetime datetime fme_basename char(50) fme_start_angle float fme_secondary_axis float geotiff_tifftag_minsamplevalue integer geotiff_private_keys{}.value char(255) geotiff_tifftag_yresolution float geotiff_photometric_interpretation char(10) fme_color char(50) geotiff_private_keys{}.id integer geotiff_tifftag_hostcomputer char(255) geotiff_compression_method char(9) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_tifftag_documentname char(255) fme_sweep_angle float fme_primary_axis float fme_dataset char(50) multi_reader_id integer geotiff_tifftag_copyright char(255) geotiff_tifftag_maxsamplevalue integer fme_rotation float fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_byte_order char(7) fme_feature_type char(50) geotiff_pyramid_level{}.num_rows integer geotiff_private_keys{}.type char(6)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE="LISTBOX_ENCODED"
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FEATURE_TYPES=""
-#!   MAX_FEATURES=""
-#!   MAX_FEATURES_PER_FEATURE_TYPE=""
-#!   MIN_FEATURES=""
-#!   START_FEATURE=""
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="tif file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="Raster1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="Raster File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="MIME_TYPE"
-#!   VALUE="image/TIFF"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the GeoTIFF file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the GeoTIFF file"
-#! />
-#! </DATASET>
-#! <DATASET
-#!   IS_SOURCE="false"
-#!   ROLE="WRITER"
-#!   FORMAT="LAS"
-#!   DATASET="$(DestDataset_LAS)"
-#!   KEYWORD="LAS_2"
-#!   MULTI_GEOM_ALLOWED="true"
-#!   ATTR_MAX_LENGTH="60"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="false"
-#!   EXPOSABLE_ATTRS="fme_fill_color char(50) fme_basename char(50) fme_secondary_axis number(31,15) las_type char(255) las_synthetic_returns logical las_project_id char(36) fme_dataset char(50) las_gps_time_type number(1,0) fme_rotation number(31,15) fme_color char(50) fme_start_angle number(31,15) fme_text_size number(31,15) fme_type char(50) fme_feature_type char(50) las_file_source_id number(6,0) las_file_creation_date date las_zlas_rearranged_points logical las_vertical_coordsys_code number(6,0) fme_primary_axis number(31,15) las_generating_software char(32) las_vertical_datum_code number(6,0) fme_sweep_angle number(31,15) fme_geometry char(50) las_system_identifier char(32) las_vertical_units_code number(6,0) fme_text_string char(50)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE=""
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS="CH1903Plus_1.LV95/01"
-#!   FANOUT_EXPRESSION="&lt;Unused&gt;"
-#!   FANOUT_GROUP="NO"
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="las file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="File1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="LAS File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the LAS file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the LAS file"
-#! />
-#! </DATASET>
-#! </DATASETS>
-#! <DATA_TYPES>
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="datetime"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="time"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="decimal(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="float"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="float"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="integer"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="largeint"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="decimal(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="largeint"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="integer"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(20)"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(12)"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(31,15)"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(15,7)"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(20)"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(12)"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(31,15)"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(15,7)"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="LAS"
-#! />
-#! </DATA_TYPES>
-#! <GEOM_TYPES>
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_raster"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="las_point_cloud"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="las_point_cloud"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="LAS"
-#! />
-#! </GEOM_TYPES>
-#! <FEATURE_TYPES>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="true"
-#!   NODE_NAME="LAS"
-#!   FEATURE_TYPE_NAME=""
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="false"
-#!   IDENTIFIER="2"
-#!   FEAT_GEOMTYPE="las_point_cloud"
-#!   POSITION="-1069.8849601762599 -235.55147610299639"
-#!   BOUNDING_RECT="-1069.8849601762599 -235.55147610299639 454 71"
-#!   ORDER="500000000000000"
-#!   COLLAPSED="true"
-#!   KEYWORD="LAS_1"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   HIDDEN_USER_ATTRS=""
-#!   MERGE_FILTER=""
-#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
-#!   MERGE_FILTER_CASE_SENSITIVE="true"
-#!   DYNAMIC_SCHEMA="false"
-#! >
-#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
-#! </FEATURE_TYPE>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="true"
-#!   NODE_NAME="GEOTIFF"
-#!   FEATURE_TYPE_NAME=""
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="false"
-#!   IDENTIFIER="3"
-#!   FEAT_GEOMTYPE="geotiff_raster"
-#!   POSITION="-1078.5791925327244 154.49930308258965"
-#!   BOUNDING_RECT="-1078.5791925327244 154.49930308258965 454 71"
-#!   ORDER="500000000000000"
-#!   COLLAPSED="true"
-#!   KEYWORD="GEOTIFF_1"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   HIDDEN_USER_ATTRS=""
-#!   MERGE_FILTER=""
-#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
-#!   MERGE_FILTER_CASE_SENSITIVE="false"
-#!   DYNAMIC_SCHEMA="false"
-#! >
-#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
-#! </FEATURE_TYPE>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="false"
-#!   NODE_NAME="LAS01"
-#!   FEATURE_TYPE_NAME="@Value(fme_basename)_CLEAN"
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="true"
-#!   IDENTIFIER="67"
-#!   FEAT_GEOMTYPE="All"
-#!   POSITION="5883.3943172105264 -1701.8038744401044"
-#!   BOUNDING_RECT="5883.3943172105264 -1701.8038744401044 822.51709593866872 71"
-#!   ORDER="500000000000018"
-#!   COLLAPSED="true"
-#!   KEYWORD="LAS_2"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   SCHEMA_ATTRIBUTE_SOURCE="1"
-#! >
-#! </FEATURE_TYPE>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="true"
-#!   NODE_NAME="GEOTIFF"
-#!   FEATURE_TYPE_NAME=""
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="false"
-#!   IDENTIFIER="69"
-#!   FEAT_GEOMTYPE="geotiff_raster"
-#!   POSITION="-1076.8859688596885 -764.40991501184817"
-#!   BOUNDING_RECT="-1076.8859688596885 -764.40991501184817 454 71"
-#!   ORDER="500000000000000"
-#!   COLLAPSED="true"
-#!   KEYWORD="GEOTIFF_2"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   HIDDEN_USER_ATTRS=""
-#!   MERGE_FILTER=""
-#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
-#!   MERGE_FILTER_CASE_SENSITIVE="false"
-#!   DYNAMIC_SCHEMA="false"
-#! >
-#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
-#! </FEATURE_TYPE>
-#! </FEATURE_TYPES>
-#! <FMESERVER>
-#! <READER_DATASETS>
-#! <DATASET
-#!   NAME="LAS_1"
-#!   OVERRIDE="-LAS_1_DATASET"
-#!   DATASET="LAS_1/LAS_2021_norm045_10traj.las"
-#! />
-#! <DATASET
-#!   NAME="GEOTIFF_2"
-#!   OVERRIDE="-GEOTIFF_2_DATASET"
-#!   DATASET="GEOTIFF_2/MNC_GE_Raster_2.tif"
-#! />
-#! <DATASET
-#!   NAME="GEOTIFF_1"
-#!   OVERRIDE="-GEOTIFF_1_DATASET"
-#!   DATASET="GEOTIFF_1/Murs_THOCHB_Buff05_rast.tif"
-#! />
-#! </READER_DATASETS>
-#! <WRITER_DATASETS>
-#! <DATASET
-#!   NAME="LAS_2"
-#!   OVERRIDE="-LAS_2_DATASET"
-#!   DATASET="LAS_2/Comp_pretrait_2021"
-#! />
-#! </WRITER_DATASETS>
-#! </FMESERVER>
-#! <GLOBAL_PARAMETERS>
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las"
-#!   IS_STAND_ALONE="false"
-#! />
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
-#!   IS_STAND_ALONE="false"
-#! />
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_PAST\Comp_pretrait_2021"
-#!   IS_STAND_ALONE="false"
-#! />
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF_3 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif"
-#!   IS_STAND_ALONE="false"
-#! />
-#! </GLOBAL_PARAMETERS>
-#! <COMMENTS>
-#! <COMMENT
-#!   IDENTIFIER="50"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt; with 50cm buffer and rasterized (pixel value = 3)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="-1165.5614675295687 292.97280707294868"
-#!   TOP_LEFT="-1165.5614675295687 292.97280707294868"
-#!   BOTTOM_RIGHT="-202.79458113730072 194.22211956607362"
-#!   BOUNDING_RECT="-1165.5614675295687 292.97280707294868 962.76688639226802 98.750687506875067"
-#!   ORDER="500000000000027"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="0.59607843137254901,0.91764705882352937,0.72549019607843135,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="0"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="51"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;rasterized(pixel value = 1)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="-1139.7498726760314 -616.14091318218152"
-#!   TOP_LEFT="-1139.7498726760314 -616.14091318218152"
-#!   BOTTOM_RIGHT="-578.46323144082498 -714.89160068905653"
-#!   BOUNDING_RECT="-1139.7498726760314 -616.14091318218152 561.28664123520639 98.750687506875067"
-#!   ORDER="500000000000028"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="0.59215686274509804,0.75294117647058822,0.90980392156862744,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="0"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="52"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Extraction of vegetation points (4-5)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="-359.10451665445083 2.1426788735972195"
-#!   TOP_LEFT="-359.10451665445083 2.1426788735972195"
-#!   BOTTOM_RIGHT="192.82107714694172 -96.608008633277848"
-#!   BOUNDING_RECT="-359.10451665445083 2.1426788735972195 551.92559380139255 98.750687506875067"
-#!   ORDER="500000000000029"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="4"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="44"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Addition of new components for wall and canopy informations&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="194.87047996450929 -454.44558381754035"
-#!   TOP_LEFT="194.87047996450929 -454.44558381754035"
-#!   BOTTOM_RIGHT="960.78088440458862 -596.94670882879041"
-#!   BOUNDING_RECT="194.87047996450929 -454.44558381754035 765.91040444007933 142.50112501125011"
-#!   ORDER="500000000000030"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="5"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="53"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;mur&amp;quot; to indicate if the point is situated above a wall (3) or not (0)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="753.10136511177552 494.27736160785571"
-#!   TOP_LEFT="753.10136511177552 494.27736160785571"
-#!   BOTTOM_RIGHT="2064.5153260043239 351.7762365966056"
-#!   BOUNDING_RECT="753.10136511177552 494.27736160785571 1311.4139608925484 142.50112501125011"
-#!   ORDER="500000000000031"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="7"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="54"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;canopy&amp;quot; to indicate if the point is situated under higher canopy (&amp;gt;3m) or not&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="1911.1070036738879 -391.95294768796134"
-#!   TOP_LEFT="1911.1070036738879 -391.95294768796134"
-#!   BOTTOM_RIGHT="2995.375698437836 -534.45407269921145"
-#!   BOUNDING_RECT="1911.1070036738879 -391.95294768796134 1084.2686947639481 142.50112501125011"
-#!   ORDER="500000000000032"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="34"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="55"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out the points of class 4 NOT situated under higher canopy&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="2838.876854100331 -625.39260868799249"
-#!   TOP_LEFT="2838.876854100331 -625.39260868799249"
-#!   BOTTOM_RIGHT="3440.8588766738731 -767.8937336992426"
-#!   BOUNDING_RECT="2838.876854100331 -625.39260868799249 601.98202257354205 142.50112501125011"
-#!   ORDER="500000000000033"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="37"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="56"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out the points of class 4 situated above a wall&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="3098.4352396715458 -1249.2896877730261"
-#!   TOP_LEFT="3098.4352396715458 -1249.2896877730261"
-#!   BOTTOM_RIGHT="3645.3193640978961 -1391.7908127842761"
-#!   BOUNDING_RECT="3098.4352396715458 -1249.2896877730261 546.88412442635035 142.50112501125011"
-#!   ORDER="500000000000034"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="38"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="57"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 3&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="4661.4071588338174 -588.31535203534895"
-#!   TOP_LEFT="4661.4071588338174 -588.31535203534895"
-#!   BOTTOM_RIGHT="5359.0961441529325 -687.06603954222396"
-#!   BOUNDING_RECT="4661.4071588338174 -588.31535203534895 697.68898531911509 98.750687506875067"
-#!   ORDER="500000000000035"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="43"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="59"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Recombination of all points  for writing&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="5258.9106929677328 -1428.3424344986706"
-#!   TOP_LEFT="5258.9106929677328 -1428.3424344986706"
-#!   BOTTOM_RIGHT="6026.8459827455408 -1527.0931220055456"
-#!   BOUNDING_RECT="5258.9106929677328 -1428.3424344986706 767.93528977780807 98.750687506875067"
-#!   ORDER="500000000000037"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="41"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="65"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 4&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="4325.7680028002278 -974.12671167517988"
-#!   TOP_LEFT="4325.7680028002278 -974.12671167517988"
-#!   BOTTOM_RIGHT="5023.4569881193429 -1072.8773991820549"
-#!   BOUNDING_RECT="4325.7680028002278 -974.12671167517988 697.68898531911509 98.750687506875067"
-#!   ORDER="500000000000035"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="64"
-#! />
-#! </COMMENTS>
-#! <CONSTANTS>
-#! </CONSTANTS>
-#! <BOOKMARKS>
-#! <BOOKMARK
-#!   IDENTIFIER="42"
-#!   NAME="Cadastre of walls "
-#!   DESCRIPTION=""
-#!   TOP_LEFT="-1168.8859688596885 382.31765296376369"
-#!   ORDER="500000000000023"
-#!   PALETTE_COLOR="Color5"
-#!   BOTTOM_RIGHT="-126.33105054454791 29.999303082589677"
-#!   BOUNDING_RECT="-1168.8859688596885 382.31765296376369 1042.5549183151406 352.31834988117402"
-#!   STICKY="true"
-#!   COLOUR="0.59607843137254901,0.91764705882352937,0.72549019607843135,1"
-#!   CONTENTS="3 50 "
-#! >
-#! </BOOKMARK>
-#! <BOOKMARK
-#!   IDENTIFIER="48"
-#!   NAME="LAS file"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="-1146.952958891291 -93.086037243351157"
-#!   ORDER="500000000000024"
-#!   PALETTE_COLOR="Color6"
-#!   BOTTOM_RIGHT="-531.56146752956874 -356.37496874968753"
-#!   BOUNDING_RECT="-1146.952958891291 -93.086037243351157 615.39149136172227 263.28893150633638"
-#!   STICKY="true"
-#!   COLOUR="0.59215686274509804,0.8901960784313725,0.90980392156862744,1"
-#!   CONTENTS="2 "
-#! >
-#! </BOOKMARK>
-#! <BOOKMARK
-#!   IDENTIFIER="49"
-#!   NAME="Canopy cover layer"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="-1168.8859688596885 -521.94670882879041"
-#!   ORDER="500000000000025"
-#!   PALETTE_COLOR="Color7"
-#!   BOTTOM_RIGHT="-534.88596885968855 -888.90991501184817"
-#!   BOUNDING_RECT="-1168.8859688596885 -521.94670882879041 634 366.96320618305776"
-#!   STICKY="true"
-#!   COLOUR="0.59215686274509804,0.75294117647058822,0.90980392156862744,1"
-#!   CONTENTS="51 69 "
-#! >
-#! </BOOKMARK>
-#! <BOOKMARK
-#!   IDENTIFIER="58"
-#!   NAME="New LAS file cleaned"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="5795.3943172105264 -1573.3038744401044"
-#!   ORDER="500000000000036"
-#!   PALETTE_COLOR="Color8"
-#!   BOTTOM_RIGHT="6797.9114131491951 -1826.3038744401044"
-#!   BOUNDING_RECT="5795.3943172105264 -1573.3038744401044 1002.5170959386687 253"
-#!   STICKY="true"
-#!   COLOUR="0.62352941176470589,0.5725490196078431,0.8784313725490196,1"
-#!   CONTENTS="67 "
-#! >
-#! </BOOKMARK>
-#! </BOOKMARKS>
-#! <TRANSFORMERS>
-#! <TRANSFORMER
-#!   IDENTIFIER="4"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="-513.92559380139255 -231.87496874968753"
-#!   BOUNDING_RECT="-513.92559380139255 -231.87496874968753 454 71"
-#!   ORDER="500000000000001"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;trunks&lt;space&gt;&lt;openparen&gt;10&lt;closeparen&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==10 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;trunks&lt;space&gt;&lt;openparen&gt;10&lt;closeparen&gt;"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="5"
-#!   TYPE="PointCloudComponentAdder"
-#!   VERSION="1"
-#!   POSITION="139.7844427211582 -178.84192352561826"
-#!   BOUNDING_RECT="139.7844427211582 -178.84192352561826 580.00106825772946 71"
-#!   ORDER="500000000000002"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD" PARM_VALUE="mur,Real64,0,canopy,Real64,0"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudComponentAdder"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="7"
-#!   TYPE="PointCloudOnRasterComponentSetter"
-#!   VERSION="3"
-#!   POSITION="753.10136511177552 292.97280707294868"
-#!   BOUNDING_RECT="753.10136511177552 292.97280707294868 430 71"
-#!   ORDER="500000000000003"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="PointCloud"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|mur|$(SourceDataset_GEOTIFF)"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
-#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="31"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="1279.7025517152713 105.50039237765995"
-#!   BOUNDING_RECT="1279.7025517152713 105.50039237765995 454 71"
-#!   ORDER="500000000000012"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4-10"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="5"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="3"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==10 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10 ; 5"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_4"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="34"
-#!   TYPE="PointCloudOnRasterComponentSetter"
-#!   VERSION="3"
-#!   POSITION="1827.9944704208951 -655.35918706950406"
-#!   BOUNDING_RECT="1827.9944704208951 -655.35918706950406 785.00106825772946 71"
-#!   ORDER="500000000000013"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="PointCloud"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|canopy|0"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
-#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_3"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="37"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="2777.1418141967411 -846.6441712036177"
-#!   BOUNDING_RECT="2777.1418141967411 -846.6441712036177 454 71"
-#!   ORDER="500000000000014"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4-10&lt;space&gt;out"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;canopy&lt;closeparen&gt;&lt;lt&gt;1 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10&lt;space&gt;out"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_5"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="38"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="3403.0386186329533 -974.12671167517988"
-#!   BOUNDING_RECT="3403.0386186329533 -974.12671167517988 454 71"
-#!   ORDER="500000000000014"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4-10&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_6"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="41"
-#!   TYPE="PointCloudCombiner"
-#!   VERSION="6"
-#!   POSITION="5293.5861916376134 -1635.7640714809982"
-#!   BOUNDING_RECT="5293.5861916376134 -1635.7640714809982 454 71"
-#!   ORDER="500000000000015"
-#!   PARMS_EDITED="false"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="71"
-#!   TYPE="PointCloudCombiner"
-#!   VERSION="6"
-#!   POSITION="3937.113505116753 -673.01884029790165"
-#!   BOUNDING_RECT="3937.113505116753 -673.01884029790165 454 71"
-#!   ORDER="500000000000015"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner_2"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="43"
-#!   TYPE="PointCloudExpressionEvaluator"
-#!   VERSION="3"
-#!   POSITION="4523.208588337473 -738.68854619282229"
-#!   BOUNDING_RECT="4523.208588337473 -738.68854619282229 669.00106825772946 71"
-#!   ORDER="500000000000019"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="RESULT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 3"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_2"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="64"
-#!   TYPE="PointCloudExpressionEvaluator"
-#!   VERSION="3"
-#!   POSITION="4187.5694323038824 -1121.728091283936"
-#!   BOUNDING_RECT="4187.5694323038824 -1121.728091283936 669.00106825772946 71"
-#!   ORDER="500000000000019"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="RESULT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 4"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_3"/>
-#! </TRANSFORMER>
-#! </TRANSFORMERS>
-#! <FEAT_LINKS>
-#! <FEAT_LINK
-#!   IDENTIFIER="8"
-#!   SOURCE_NODE="2"
-#!   TARGET_NODE="4"
-#!   SOURCE_PORT_DESC="-1"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="9"
-#!   SOURCE_NODE="3"
-#!   TARGET_NODE="7"
-#!   SOURCE_PORT_DESC="-1"
-#!   TARGET_PORT_DESC="fi 1 Raster"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="70"
-#!   SOURCE_NODE="69"
-#!   TARGET_NODE="34"
-#!   SOURCE_PORT_DESC="-1"
-#!   TARGET_PORT_DESC="fi 1 Raster"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="60"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="5"
-#!   SOURCE_PORT_DESC="fo 0 V&lt;lt&gt;u00e9&lt;gt&gt;g&lt;lt&gt;u00e9&lt;gt&gt;tation&lt;lt&gt;space&lt;gt&gt;moyenne&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;4&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;haute&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;5&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;trunks&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;10&lt;lt&gt;closeparen&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="22"
-#!   SOURCE_NODE="5"
-#!   TARGET_NODE="7"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="fi 0 PointCloud"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="32"
-#!   SOURCE_NODE="7"
-#!   TARGET_NODE="31"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="61"
-#!   SOURCE_NODE="31"
-#!   TARGET_NODE="34"
-#!   SOURCE_PORT_DESC="fo 0 4-10"
-#!   TARGET_PORT_DESC="fi 0 PointCloud"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="39"
-#!   SOURCE_NODE="34"
-#!   TARGET_NODE="37"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="62"
-#!   SOURCE_NODE="37"
-#!   TARGET_NODE="71"
-#!   SOURCE_PORT_DESC="fo 0 4-10&lt;lt&gt;space&lt;gt&gt;out"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="63"
-#!   SOURCE_NODE="38"
-#!   TARGET_NODE="71"
-#!   SOURCE_PORT_DESC="fo 0 4-10&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="68"
-#!   SOURCE_NODE="41"
-#!   TARGET_NODE="67"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="-1"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="47"
-#!   SOURCE_NODE="43"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 0 RESULT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="36"
-#!   SOURCE_NODE="64"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 0 RESULT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="46"
-#!   SOURCE_NODE="71"
-#!   TARGET_NODE="43"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="45"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="33"
-#!   SOURCE_NODE="31"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 1 5"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="40"
-#!   SOURCE_NODE="37"
-#!   TARGET_NODE="38"
-#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="66"
-#!   SOURCE_NODE="38"
-#!   TARGET_NODE="64"
-#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! </FEAT_LINKS>
-#! <BREAKPOINTS>
-#! </BREAKPOINTS>
-#! <ATTR_LINKS>
-#! </ATTR_LINKS>
-#! <SUBDOCUMENTS>
-#! </SUBDOCUMENTS>
-#! <LOOKUP_TABLES>
-#! </LOOKUP_TABLES>
-#! </WORKSPACE>
-
-FME_PYTHON_VERSION 37
-GUI IGNORE SourceDataset_LAS_1,LAS_IN_USE_SEARCH_ENVELOPE_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1,LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1,LAS_IN_CLIP_TO_ENVELOPE_LAS_1,LAS_IN_NETWORK_AUTHENTICATION_LAS_1,SourceDataset_GEOTIFF_1,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1,SourceDataset_GEOTIFF_2,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2,DestDataset_LAS_2,LAS_OUT_FME_GROUP_NAMED1_LAS_2,LAS_OUT_VERSION_LAS_2,LAS_OUT_COMPRESSION_LAS_2,LAS_OUT_USER_GROUP_LAS_2,LAS_OUT_USER_COMPONENTS_LAS_2,LAS_OUT_ADVANCED_PARAMETERS_LAS_2,LAS_OUT_LAS_DATASET_FILE_LAS_2,LAS_OUT_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_ZLAS_PARAMETERS_LAS_2,LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2
-DEFAULT_MACRO SourceDataset_LAS G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las
-GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):
-DEFAULT_MACRO SourceDataset_GEOTIFF G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif
-GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
-DEFAULT_MACRO DestDataset_LAS G:\STDL\LIDAR_PAST\Comp_pretrait_2021
-GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:
-DEFAULT_MACRO SourceDataset_GEOTIFF_3 G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif
-GUI MULTIFILE SourceDataset_GEOTIFF_3 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
-INCLUDE [ if {{$(SourceDataset_LAS)} == {}} { puts_real {Parameter 'SourceDataset_LAS' must be given a value.}; exit 1; }; ]
-INCLUDE [ if {{$(SourceDataset_GEOTIFF)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF' must be given a value.}; exit 1; }; ]
-INCLUDE [ if {{$(DestDataset_LAS)} == {}} { puts_real {Parameter 'DestDataset_LAS' must be given a value.}; exit 1; }; ]
-INCLUDE [ if {{$(SourceDataset_GEOTIFF_3)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF_3' must be given a value.}; exit 1; }; ]
-#! START_HEADER
-#! START_WB_HEADER
-READER_TYPE MULTI_READER
-MULTI_READER_TYPE{0} LAS
-MULTI_READER_KEYWORD{0} LAS_1
-MULTI_READER_GEN_DIRECTIVES{0} USE_SEARCH_ENVELOPE,NO,CLIP_TO_ENVELOPE,NO,READER_META_ATTRIBUTES,fme_dataset,GROUP_BY_DATASET,No,_MERGE_SCHEMAS,YES,SEARCH_ENVELOPE_MAXX,0,SEARCH_ENVELOPE_MAXY,0,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MINY,0,LAS_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0
-MULTI_READER_TYPE{1} GEOTIFF
-MULTI_READER_KEYWORD{1} GEOTIFF_1
-MULTI_READER_GEN_DIRECTIVES{1} APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MAXY,0,USE_SEARCH_ENVELOPE,NO,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXX,0,IGNORE_RASTER_TYPE_KEY,No,FEATURE_TYPE_NAME,FORMAT_NAME,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PYRAMID_LEVEL,,GEOTIFF_RDR_ADV_PARM_GROUP,,PREFER_FILE_CS_UNITS,Yes,READ_OFFSETS_IN_CS_UNITS,No,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,CLIP_TO_ENVELOPE,NO
-MULTI_READER_TYPE{2} GEOTIFF
-MULTI_READER_KEYWORD{2} GEOTIFF_2
-MULTI_READER_GEN_DIRECTIVES{2} IGNORE_RASTER_TYPE_KEY,No,GEOTIFF_EXPOSE_FORMAT_ATTRS,,PYRAMID_LEVEL,,USE_SEARCH_ENVELOPE,NO,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXY,0,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_RDR_ADV_PARM_GROUP,,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MAXX,0,CLIP_TO_ENVELOPE,NO,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PREFER_FILE_CS_UNITS,Yes,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,READ_OFFSETS_IN_CS_UNITS,No,FEATURE_TYPE_NAME,FORMAT_NAME,APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,
-WRITER_TYPE MULTI_WRITER
-MULTI_WRITER_DATASET_ORDER BY_ID
-MULTI_WRITER_FIRST_WRITER_ID 0
-MULTI_WRITER_TYPE{0} LAS
-MULTI_WRITER_KEYWORD{0} LAS_2
-#! END_WB_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "LAS_1"
-#! END_WB_HEADER
-#! START_SOURCE_HEADER LAS LAS_1
-# =======================================================================
-# The following GUI line prompts for a file to be used as the source LAS file.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be read.
-# The dataset this mapping file was generated from was:
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO SourceDataset
-INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
- puts {DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset)}     \
- } ]
-#! END_WB_HEADER
-#! START_SOURCE_HEADER LAS LAS_1
-DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset_LAS)
-GUI MULTIFILE SourceDataset_LAS_1 LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|All_files(*)|* Source ASPRS LAS File(s):
-DEFAULT_MACRO LAS_IN_READER_META_ATTRIBUTES_LAS_1 fme_dataset
-LAS_1_READER_META_ATTRIBUTES "$(LAS_IN_READER_META_ATTRIBUTES_LAS_1)"
-DEFAULT_MACRO LAS_IN_GROUP_BY_DATASET_LAS_1 No
-LAS_1_GROUP_BY_DATASET "$(LAS_IN_GROUP_BY_DATASET_LAS_1)"
-DEFAULT_MACRO LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1 
-LAS_1_EXPOSE_ATTRS_GROUP "$(LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1)"
-# Include this file in source setting section to add external search envelope processing
-# Zero as a default means we don't do any search -- this makes workbench happier
-DEFAULT_MACRO LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 NO
-LAS_1_USE_SEARCH_ENVELOPE "$(LAS_IN_USE_SEARCH_ENVELOPE_LAS_1)"
-GUI ACTIVEDISCLOSUREGROUP LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1%LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1%LAS_IN_CLIP_TO_ENVELOPE_LAS_1%LAS_IN_SEARCH_METHOD%LAS_IN_SEARCH_METHOD_FILTER%LAS_IN_SEARCH_ORDER%LAS_IN_SEARCH_FEATURE%LAS_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 Minimum X:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 Minimum Y:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 Maximum X:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 Maximum Y:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 <Unused>, 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1)"
-GUI OPTIONAL COORDSYS LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 Search Envelope Coordinate System:
-# ===========================================================================
-# BUG18999: We now have a soft clip to fall back on like native spatial index
-# thus we are reintroducing the clip to envelop as an option for users.
-# Defualt to soft clip as per the existing database readers we are emulating
-GUI LOOKUP LAS_IN_CLIP_TO_ENVELOPE_LAS_1 <Unused>,NO 
-DEFAULT_MACRO LAS_IN_CLIP_TO_ENVELOPE_LAS_1 NO
-LAS_1_CLIP_TO_ENVELOPE "$(LAS_IN_CLIP_TO_ENVELOPE_LAS_1)"
-GUI OPTIONAL CHECKBOX LAS_IN_CLIP_TO_ENVELOPE_LAS_1 YES%NO Clip to Search Envelope
-# ===========================================================================
-DEFAULT_MACRO LAS_IN_NETWORK_AUTHENTICATION_LAS_1 
-LAS_1_NETWORK_AUTHENTICATION "$(LAS_IN_NETWORK_AUTHENTICATION_LAS_1)"
-GUI OPTIONAL AUTHENTICATOR LAS_IN_NETWORK_AUTHENTICATION_LAS_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
-# ============================================================================ 
-DEFAULT_MACRO LAS_IN_ATTRIBUTE_READING_LAS_1 ALL
-LAS_1_ATTRIBUTE_READING "$(LAS_IN_ATTRIBUTE_READING_LAS_1)"
-# ============================================================================ 
-LAS_1_GENERATE_FME_BUILD_NUM 20596
-LAS_1_DATASET "$(SourceDataset_LAS_1)"
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "GEOTIFF_1"
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
-# =======================================================================
-# The following GUI line prompts for a file to be used as the source GEOTIFF file.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be read.
-# The dataset this mapping file was generated from was:
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO SourceDataset
-INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
- puts {DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset)}     \
- } ]
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
-DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset_GEOTIFF)
-GUI MULTIFILE SourceDataset_GEOTIFF_1 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
-DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1 fme_dataset fme_basename
-GEOTIFF_1_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1)"
-DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1 FORMAT_NAME
-GEOTIFF_1_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1)"
-DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 NO
-GEOTIFF_1_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Apply GCP's
-DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 NearestNeighbor
-GEOTIFF_1_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1)"
-GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
-GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 <Unused>,NearestNeighbor 
-DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1 
-GEOTIFF_1_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1)"
-# Include this file in source setting section to add external search envelope processing
-# Zero as a default means we don't do any search -- this makes workbench happier
-DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 NO
-GEOTIFF_1_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 Minimum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 Minimum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 Maximum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 Maximum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 <Unused>, 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1)"
-GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 Search Envelope Coordinate System:
-# ===========================================================================
-# BUG18999: We now have a soft clip to fall back on like native spatial index
-# thus we are reintroducing the clip to envelop as an option for users.
-# Defualt to soft clip as per the existing database readers we are emulating
-GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 <Unused>,NO 
-DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 NO
-GEOTIFF_1_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1)"
-GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 YES%NO Clip to Search Envelope
-DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 
-GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Advanced
-DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 
-GEOTIFF_1_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1)"
-GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 Pyramid Level to Read:
-DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes
-GEOTIFF_1_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes%No Prefer File Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 No
-GEOTIFF_1_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 Yes%No Offsets in Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 No
-GEOTIFF_1_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Yes%No Ignore Raster Type Key:
-# ===========================================================================
-DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 
-GEOTIFF_1_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1)"
-GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
-# ============================================================================ 
-DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1 ALL
-GEOTIFF_1_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1)"
-# ============================================================================ 
-GEOTIFF_1_GENERATE_FME_BUILD_NUM 20596
-GEOTIFF_1_DATASET "$(SourceDataset_GEOTIFF_1)"
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "GEOTIFF_2"
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_2
-# =======================================================================
-# The following GUI line prompts for a file to be used as the source GEOTIFF file.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be read.
-# The dataset this mapping file was generated from was:
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO SourceDataset
-INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
- puts {DEFAULT_MACRO SourceDataset_GEOTIFF_2 $(SourceDataset)}     \
- } ]
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_2
-DEFAULT_MACRO SourceDataset_GEOTIFF_2 $(SourceDataset_GEOTIFF_3)
-GUI MULTIFILE SourceDataset_GEOTIFF_2 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
-DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_2 fme_dataset fme_basename
-GEOTIFF_2_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_2)"
-DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_2 FORMAT_NAME
-GEOTIFF_2_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_2)"
-DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2 NO
-GEOTIFF_2_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 Apply GCP's
-DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 NearestNeighbor
-GEOTIFF_2_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2)"
-GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
-GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 <Unused>,NearestNeighbor 
-DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_2 
-GEOTIFF_2_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_2)"
-# Include this file in source setting section to add external search envelope processing
-# Zero as a default means we don't do any search -- this makes workbench happier
-DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2 NO
-GEOTIFF_2_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 0
-GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 Minimum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 0
-GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 Minimum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 0
-GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 Maximum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 0
-GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 Maximum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 <Unused>, 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 
-GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2)"
-GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 Search Envelope Coordinate System:
-# ===========================================================================
-# BUG18999: We now have a soft clip to fall back on like native spatial index
-# thus we are reintroducing the clip to envelop as an option for users.
-# Defualt to soft clip as per the existing database readers we are emulating
-GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 <Unused>,NO 
-DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 NO
-GEOTIFF_2_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2)"
-GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 YES%NO Clip to Search Envelope
-DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2 
-GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 Advanced
-DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2 
-GEOTIFF_2_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2)"
-GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2 Pyramid Level to Read:
-DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2 Yes
-GEOTIFF_2_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2)"
-GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2 Yes%No Prefer File Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2 No
-GEOTIFF_2_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2)"
-GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2 Yes%No Offsets in Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 No
-GEOTIFF_2_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2)"
-GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 Yes%No Ignore Raster Type Key:
-# ===========================================================================
-DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2 
-GEOTIFF_2_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2)"
-GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
-# ============================================================================ 
-DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_2 ALL
-GEOTIFF_2_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_2)"
-# ============================================================================ 
-GEOTIFF_2_GENERATE_FME_BUILD_NUM 20596
-GEOTIFF_2_DATASET "$(SourceDataset_GEOTIFF_2)"
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "LAS_2"
-#! END_WB_HEADER
-#! START_DEST_HEADER LAS LAS_2
-# The following GUI lines prompt for a LAS file to be used as the
-# the destination of the data.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be written.
-#! END_DEST_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO DestDataset
-INCLUDE [ if {"$(DestDataset)" != ""} {                          \
- puts {DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset)}         \
- } ]
-#! END_WB_HEADER
-#! START_DEST_HEADER LAS LAS_2
-DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset_LAS)
-GUI DIRNAME DestDataset_LAS_2 Destination ASPRS LAS Folder:
-DEFAULT_MACRO LAS_OUT_FME_GROUP_NAMED1_LAS_2 FME_DISCLOSURE_OPEN
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_FME_GROUP_NAMED1_LAS_2 LAS_OUT_VERSION_LAS_2%LAS_OUT_COMPRESSION_LAS_2 Parameters
-# ============================================================================
-# Version
-DEFAULT_MACRO LAS_OUT_VERSION_LAS_2 1.4
-LAS_2_VERSION "$(LAS_OUT_VERSION_LAS_2)"
-GUI LOOKUP_CHOICE LAS_OUT_VERSION_LAS_2 1.0,1.0%1.1,1.1%1.2,1.2%1.3,1.3%"\"1.4 (Legacy Compatible)\",1.4-legacy-compatible"%1.4,1.4 ASPRS LAS Version:
-# [PR#30472] Compression
-DEFAULT_MACRO LAS_OUT_COMPRESSION_LAS_2 None
-LAS_2_COMPRESSION "$(LAS_OUT_COMPRESSION_LAS_2)"
-GUI ACTIVECHOICE LAS_OUT_COMPRESSION_LAS_2 None,LAS_OUT_ZLAS_PARAMETERS_LAS_2%LAZ,LAS_OUT_ZLAS_PARAMETERS_LAS_2%zLAS Compression
-# This is a placeholder parameter that will be replaced with a custom table in the controller
-DEFAULT_MACRO LAS_OUT_USER_GROUP_LAS_2 FME_DISCLOSURE_OPEN
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_USER_GROUP_LAS_2 LAS_OUT_USER_COMPONENTS_LAS_2 Additional User Components
-DEFAULT_MACRO LAS_OUT_USER_COMPONENTS_LAS_2 Distance<comma>Normal<comma>Group
-LAS_2_USER_COMPONENTS "$(LAS_OUT_USER_COMPONENTS_LAS_2)"
-GUI OPTIONAL GUI_LINE_TABLE_ENCODED LAS_OUT_USER_COMPONENTS_LAS_2 NO_LABEL%ROW_DELIM:,%COL_DELIM:,%"User Components"%"STRING COMPONENTS" User Components
-# ============================================================================
-# Opt in for destination dataset type vs format type validation
-DEFAULT_MACRO LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2 Yes
-LAS_2_DESTINATION_DATASETTYPE_VALIDATION "$(LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2)"
-DEFAULT_MACRO LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2 FEATURE
-LAS_2_COORDINATE_SYSTEM_GRANULARITY "$(LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2)"
-DEFAULT_MACRO LAS_OUT_ADVANCED_PARAMETERS_LAS_2 FME_DISCLOSURE_CLOSED
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ADVANCED_PARAMETERS_LAS_2 LAS_OUT_LAS_DATASET_FILE_LAS_2%LAS_OUT_ZLAS_PARAMETERS_LAS_2 Advanced
-DEFAULT_MACRO LAS_OUT_LAS_DATASET_FILE_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_LAS_DATASET_FILE_LAS_2 LAS_OUT_ARCGIS_LAS_DATASET_LAS_2%LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 LAS Dataset File
-# The following GUI line provides the ability to create an
-# Esri ArcGIS LAS Dataset encapsulating the LAS files produced
-# by this translation. The LAS Dataset can then be used to view
-# the output using Esri's tools.
-DEFAULT_MACRO LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 
-LAS_2_ARCGIS_LAS_DATASET "$(LAS_OUT_ARCGIS_LAS_DATASET_LAS_2)"
-GUI OPTIONAL TEXT LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 ArcGIS LAS Dataset (.lasd) Filename
-# The following GUI line determines whether statistics should
-# be calculated on the ArcGIS LAS Dataset. This keyword is
-# applicable when FME is creating an ArcGIS LAS Dataset.
-DEFAULT_MACRO LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 No
-LAS_2_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET "$(LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2)"
-GUI CHOICE LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 Yes%No Compute Statistics on ArcGIS LAS Dataset
-DEFAULT_MACRO LAS_OUT_ZLAS_PARAMETERS_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ZLAS_PARAMETERS_LAS_2 LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Parameters
-DEFAULT_MACRO LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 <Unused>
-LAS_2_ZLAS_REARRANGE_POINTS "$(LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2)"
-GUI CHOICE LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 Yes%No Rearrange Points for zLAS Compression
-DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 <Unused>
-LAS_2_ZLAS_POINT_SPACING_SOURCE "$(LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2)"
-GUI LOOKUP_CHOICE LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 "\"Scan Points\",scan"%"\"From Header\",header"%"\"Specify Value\",specify" zLAS Point Spacing Source
-DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 <Unused>
-LAS_2_ZLAS_POINT_SPACING_VALUE "$(LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2)"
-GUI FLOAT LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Point Spacing Value
-# ============================================================================ 
-LAS_2_GENERATE_FME_BUILD_NUM 20596
-LAS_2_DATASET "$(DestDataset_LAS_2)"
-#! END_DEST_HEADER
-#! START_WB_HEADER
-#! END_WB_HEADER
-#! END_HEADER
-
-LOG_FILTER_MASK -1
-LOG_MAX_FEATURES 200
-LOG_MAX_RECORDED_FEATURES 200
-FME_REPROJECTION_ENGINE FME
-FME_IMPLICIT_CSMAP_REPROJECTION_MODE Auto
-FME_GEOMETRY_HANDLING Enhanced
-FME_STROKE_MAX_DEVIATION 0
-DEFAULT_MACRO DATASET_KEYWORD_LAS_1 LAS_1
-DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_1 GEOTIFF_1
-DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_2 GEOTIFF_2
-DEFAULT_MACRO DATASET_KEYWORD_LAS_2 LAS_2
-# -------------------------------------------------------------------------
-
-LAS_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
-
-# -------------------------------------------------------------------------
-
-GEOTIFF_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
-
-# -------------------------------------------------------------------------
-
-GEOTIFF_2_READER_META_ATTRIBUTES fme_feature_type fme_basename
-
-# -------------------------------------------------------------------------
-
-LAS_2_COORDINATE_SYSTEM CH1903Plus_1.LV95/01
-MULTI_READER_CONTINUE_ON_READER_FAILURE No
-
-# -------------------------------------------------------------------------
-
-MACRO WORKSPACE_NAME LAS_Pretraitement_2021_cleaning_MNC_class10
-MACRO FME_VIEWER_APP fmedatainspector
-# -------------------------------------------------------------------------
-LAS_1_DEF LAS
-# -------------------------------------------------------------------------
-GEOTIFF_1_DEF GEOTIFF
-# -------------------------------------------------------------------------
-GEOTIFF_2_DEF GEOTIFF
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * RoutingFactory   FACTORY_NAME "Router and Unexpected Input Remover"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE LAS LAS_1::LAS multi_reader_keyword,$(DATASET_KEYWORD_LAS_1) TO FME_GENERIC ::LAS ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_1::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_1) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_2::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_2) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    MERGE_INPUT Yes   OUTPUT ROUTED FEATURE_TYPE *
-LAS_1_MERGE_DEF LAS_1::LAS EXACT LAS
-GEOTIFF_1_MERGE_DEF GEOTIFF_1::GEOTIFF EXACT GEOTIFF
-GEOTIFF_2_MERGE_DEF GEOTIFF_2::GEOTIFF EXACT GEOTIFF
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory    FACTORY_NAME "LAS_LAS_1 Splitter"    INPUT FEATURE_TYPE LAS    OUTPUT FEATURE_TYPE LAS_LAS_1
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_1 Splitter"    INPUT FEATURE_TYPE GEOTIFF      multi_reader_keyword $(DATASET_KEYWORD_GEOTIFF_1)    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_1
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_2 Splitter"    INPUT FEATURE_TYPE GEOTIFF      multi_reader_keyword $(DATASET_KEYWORD_GEOTIFF_2)    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_2
-DEFAULT_MACRO WB_CURRENT_CONTEXT
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter    INPUT  FEATURE_TYPE LAS_LAS_1    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==5<space>||<space><at>Component<openparen>classification<closeparen>==10 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * TeeFactory    FACTORY_NAME PointCloudComponentAdder    INPUT  FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    OUTPUT FEATURE_TYPE ___TOREJECTOR___       @RenameAttributes(FME_STRICT,___fme_rejection_code___,fme_rejection_code)       @AddPointCloudComponents(REJECTABLE,mur,Real64,0,canopy,Real64,0)
-FACTORY_DEF * TestFactory    FACTORY_NAME PointCloudComponentAdder_Rejector    INPUT FEATURE_TYPE ___TOREJECTOR___    TEST @Value(fme_rejection_code) != ""    OUTPUT PASSED FEATURE_TYPE PointCloudComponentAdder_<REJECTED>       @RemoveAttributes(___fme_rejection_code___)    OUTPUT FAILED FEATURE_TYPE PointCloudComponentAdder_OUTPUT       @RenameAttributes(FME_STRICT,fme_rejection_code,___fme_rejection_code___)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudComponentAdder_<Rejected> INPUT FEATURE_TYPE PointCloudComponentAdder_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudComponentAdder<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|mur|$(SourceDataset_GEOTIFF)} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
-FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter    INPUT  FEATURE_TYPE PointCloudComponentAdder_OUTPUT    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_1    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_4    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==10 ; <at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10 ; 5    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_4_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_4-10    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = 5 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_5    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_4 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_4_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_4<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|canopy|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
-FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_3    INPUT  FEATURE_TYPE PointCloudFilter_4_4-10    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_2    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_3_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_3_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_5    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>canopy<closeparen><lt>1 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10<space>out    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_5_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_5_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10<space>out OUTPUT PASSED FEATURE_TYPE PointCloudFilter_5_4-10<space>out    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_5_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_5<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_6    INPUT  FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_6_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_6_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_6_4-10<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_6_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_6<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-DEFAULT_MACRO PointCloudExpressionEvaluator_3_COMPONENT_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_3_COMPONENT_TYPE_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_3_EXPRESSION_LIST
-INCLUDE [    foreach {component componenttype expression} [split {classification Auto 4}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_3_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_3    INPUT  FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_3_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_3_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_3_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_3_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_3_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_3_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner_2___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_5_4-10<space>out    INPUT  FEATURE_TYPE PointCloudFilter_6_4-10<space>-<space>mur    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner_2)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
-FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner_2___Combiner    INPUT FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_2_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_2_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_EXPRESSION_LIST
-INCLUDE [    foreach {component componenttype expression} [split {classification Auto 3}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_2_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_2    INPUT  FEATURE_TYPE PointCloudCombiner_2_OUTPUT    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_2_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_2_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner___VectorMerger    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_3_RESULT    INPUT  FEATURE_TYPE PointCloudFilter_<UNFILTERED>    INPUT  FEATURE_TYPE PointCloudFilter_4_5    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
-FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner___Combiner    INPUT FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * RoutingFactory FACTORY_NAME "Destination Feature Type Routing Correlator"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE FME_GENERIC PointCloudCombiner_OUTPUT TO LAS __GO_TO_FINAL_OUTPUT_ROUTER__ multi_writer_id,0,<at>SupplyAttributes<openparen>ENCODED<comma>fme_template_feature_type<comma>LAS01<closeparen>,<at>EvaluateExpression<openparen>ATTR_CREATE_EXPR<comma>__wb_out_feat_type__<comma><lt>at<gt>Value<lt>openparen<gt>fme_basename<lt>closeparen<gt>_CLEAN<comma>LAS01<closeparen> COORDINATE_SYSTEM CH1903Plus_1.LV95/01 GEOMETRY   FEATURE_TYPE_ATTRIBUTE __wb_out_feat_type__   OUTPUT ROUTED FEATURE_TYPE *    OUTPUT NOT_ROUTED FEATURE_TYPE __nuke_me__ @Tcl2("FME_StatMessage 818059 [FME_GetAttribute fme_template_feature_type] 818060 818061 fme_warn")
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory   FACTORY_NAME "Final Output Nuker"   INPUT FEATURE_TYPE __nuke_me__
-
-# -------------------------------------------------------------------------
-LAS_2_DEF LAS01
+#! <?xml version="1.0" encoding="UTF-8" ?>
+#! <WORKSPACE
+#    Command-line to run this workspace:
+#        "C:\Program Files (x86)\FME2020\fme.exe" G:\STDL\LIDAR_2021\Scripts_et_Processus\LAS_Pretraitement_2021_cleaning_MNC_class10.fmw
+#              --SourceDataset_LAS "G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las"
+#              --SourceDataset_GEOTIFF "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
+#              --DestDataset_LAS "G:\STDL\LIDAR_PAST\Comp_pretrait_2021"
+#              --SourceDataset_GEOTIFF_3 "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif"
+#    
+#!   ATTR_TYPE_ENCODING="SDF"
+#!   BEGIN_PYTHON=""
+#!   BEGIN_TCL=""
+#!   CATEGORY=""
+#!   DESCRIPTION=""
+#!   DESTINATION="NONE"
+#!   DESTINATION_ROUTING_FILE=""
+#!   DOC_EXTENTS="7966.8 2320.58"
+#!   DOC_TOP_LEFT="-1168.89 -1826.3"
+#!   END_PYTHON=""
+#!   END_TCL=""
+#!   EXPLICIT_BOOKMARK_ORDER="false"
+#!   FME_BUILD_NUM="20596"
+#!   FME_DOCUMENT_GUID="d05b3aac-af8c-4859-a8d1-19db9ba773fc"
+#!   FME_DOCUMENT_PRIORGUID="e44176b6-c7b1-43ea-b9f4-2c32a085725b,c381042f-601f-4ea6-8815-83d7bd38b88a,f7a0bbd2-1db7-4a74-ae55-a63987eae69b,078fad80-7051-4100-84e6-4696f553bbea,51ed0ff3-37f8-45b3-9ff8-b75998c54609,02adf04c-e29a-4e52-92d5-abeca0924965,5ebbce74-be36-4454-a815-31428db8a416,e5e0372a-302f-4a0a-9427-792bc02785fd,bfca1a2a-75c0-4e6a-89e9-1ea630185fed,82dc1478-a881-4404-85db-ad0da5c5d130,ee5d0c1d-9e12-4458-a89a-2c815a0c0582,0154c093-9f4f-4ea3-a30c-d4bd3c69ca7e,ecba9442-0ed9-411b-b89d-7a7a54adedbf,44ced49f-ea1e-406c-a6d7-02600807ae35,6925ca57-8fec-4a5c-b0fc-0f1035cea0fd,3c3c63d6-737a-423f-85cc-d182978e7f3b,cbbcb408-ad67-4b86-88b7-503650200f32,4dbc4746-c035-40d8-ab8b-2eef885a849a"
+#!   FME_GEOMETRY_HANDLING="Enhanced"
+#!   FME_IMPLICIT_CSMAP_REPROJECTION_MODE="Auto"
+#!   FME_REPROJECTION_ENGINE="FME"
+#!   FME_SERVER_SERVICES=""
+#!   FME_STROKE_MAX_DEVIATION="0"
+#!   HISTORY=""
+#!   IGNORE_READER_FAILURE="No"
+#!   LAST_SAVE_BUILD="FME(R) 2020.1.0.1 (20200710 - Build 20596 - WIN32)"
+#!   LAST_SAVE_DATE="2022-03-01T17:21:47"
+#!   LOG_FILE=""
+#!   LOG_MAX_RECORDED_FEATURES="200"
+#!   MARKDOWN_DESCRIPTION=""
+#!   MARKDOWN_USAGE=""
+#!   MAX_LOG_FEATURES="200"
+#!   MULTI_WRITER_DATASET_ORDER="BY_ID"
+#!   PASSWORD=""
+#!   PYTHON_COMPATIBILITY="37"
+#!   REDIRECT_TERMINATORS="NONE"
+#!   SAVE_ON_PROMPT_AND_RUN="Yes"
+#!   SHOW_ANNOTATIONS="true"
+#!   SHOW_INFO_NODES="true"
+#!   SOURCE="NONE"
+#!   SOURCE_ROUTING_FILE=""
+#!   TERMINATE_REJECTED="YES"
+#!   TITLE=""
+#!   USAGE=""
+#!   USE_MARKDOWN=""
+#!   VIEW_POSITION="-186.74 613.573"
+#!   WARN_INVALID_XFORM_PARAM="Yes"
+#!   WORKSPACE_VERSION="1"
+#!   ZOOM_SCALE="82"
+#! >
+#! <DATASETS>
+#! <DATASET
+#!   IS_SOURCE="true"
+#!   ROLE="READER"
+#!   FORMAT="LAS"
+#!   DATASET="$(SourceDataset_LAS)"
+#!   KEYWORD="LAS_1"
+#!   MULTI_GEOM_ALLOWED="false"
+#!   ATTR_MAX_LENGTH="0"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="false"
+#!   EXPOSABLE_ATTRS="fme_fill_color char(50) fme_basename char(50) fme_secondary_axis number(31,15) las_type char(255) las_synthetic_returns logical multi_reader_full_id number(11,0) las_project_id char(36) fme_dataset char(50) las_version char(3) las_gps_time_type number(1,0) fme_rotation number(31,15) fme_color char(50) fme_start_angle number(31,15) fme_text_size number(31,15) fme_type char(50) fme_feature_type char(50) las_file_source_id number(6,0) las_file_creation_date date las_zlas_rearranged_points logical las_vertical_coordsys_code number(6,0) las_generating_software char(32) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_sweep_angle number(31,15) las_system_identifier char(32) fme_geometry char(50) multi_reader_id number(11,0) las_vertical_units_code number(6,0) multi_reader_keyword char(50) fme_text_string char(50) multi_reader_type char(50)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE="LISTBOX_ENCODED"
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FEATURE_TYPES=""
+#!   MAX_FEATURES=""
+#!   MAX_FEATURES_PER_FEATURE_TYPE=""
+#!   MIN_FEATURES=""
+#!   START_FEATURE=""
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="las file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="File1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="LAS File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the LAS file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the LAS file"
+#! />
+#! </DATASET>
+#! <DATASET
+#!   IS_SOURCE="true"
+#!   ROLE="READER"
+#!   FORMAT="GEOTIFF"
+#!   DATASET="$(SourceDataset_GEOTIFF)"
+#!   KEYWORD="GEOTIFF_1"
+#!   MULTI_GEOM_ALLOWED="false"
+#!   ATTR_MAX_LENGTH="0"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="true"
+#!   EXPOSABLE_ATTRS="geotiff_tifftag_software char(255) geotiff_subdataset_name char(255) geotiff_pyramid_num_levels integer geotiff_subdataset_description char(255) geotiff_type char(255) geotiff_pyramid_level{}.num_columns integer fme_type char(50) multi_reader_type char(50) geotiff_area_or_point char(255) fme_geometry char(50) geotiff_tifftag_xresolution float multi_reader_keyword char(50) geotiff_tifftag_artist char(255) geotiff_tifftag_imagedescription char(255) fme_text_string char(50) fme_text_size float geotiff_number_of_bits_per_cell decimal(1,0) multi_reader_full_id integer geotiff_tifftag_datetime datetime fme_basename char(50) fme_start_angle float fme_secondary_axis float geotiff_tifftag_minsamplevalue integer geotiff_private_keys{}.value char(255) geotiff_tifftag_yresolution float geotiff_photometric_interpretation char(10) fme_color char(50) geotiff_private_keys{}.id integer geotiff_tifftag_hostcomputer char(255) geotiff_compression_method char(9) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_tifftag_documentname char(255) fme_sweep_angle float fme_primary_axis float fme_dataset char(50) multi_reader_id integer geotiff_tifftag_copyright char(255) geotiff_tifftag_maxsamplevalue integer fme_rotation float fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_byte_order char(7) fme_feature_type char(50) geotiff_pyramid_level{}.num_rows integer geotiff_private_keys{}.type char(6)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE="LISTBOX_ENCODED"
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FEATURE_TYPES=""
+#!   MAX_FEATURES=""
+#!   MAX_FEATURES_PER_FEATURE_TYPE=""
+#!   MIN_FEATURES=""
+#!   START_FEATURE=""
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="tif file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="Raster1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="Raster File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="MIME_TYPE"
+#!   VALUE="image/TIFF"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the GeoTIFF file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the GeoTIFF file"
+#! />
+#! </DATASET>
+#! <DATASET
+#!   IS_SOURCE="true"
+#!   ROLE="READER"
+#!   FORMAT="GEOTIFF"
+#!   DATASET="$(SourceDataset_GEOTIFF_3)"
+#!   KEYWORD="GEOTIFF_2"
+#!   MULTI_GEOM_ALLOWED="false"
+#!   ATTR_MAX_LENGTH="0"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="true"
+#!   EXPOSABLE_ATTRS="geotiff_tifftag_software char(255) geotiff_subdataset_name char(255) geotiff_pyramid_num_levels integer geotiff_subdataset_description char(255) geotiff_type char(255) geotiff_pyramid_level{}.num_columns integer fme_type char(50) multi_reader_type char(50) geotiff_area_or_point char(255) fme_geometry char(50) geotiff_tifftag_xresolution float multi_reader_keyword char(50) geotiff_tifftag_artist char(255) geotiff_tifftag_imagedescription char(255) fme_text_string char(50) fme_text_size float geotiff_number_of_bits_per_cell decimal(1,0) multi_reader_full_id integer geotiff_tifftag_datetime datetime fme_basename char(50) fme_start_angle float fme_secondary_axis float geotiff_tifftag_minsamplevalue integer geotiff_private_keys{}.value char(255) geotiff_tifftag_yresolution float geotiff_photometric_interpretation char(10) fme_color char(50) geotiff_private_keys{}.id integer geotiff_tifftag_hostcomputer char(255) geotiff_compression_method char(9) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_tifftag_documentname char(255) fme_sweep_angle float fme_primary_axis float fme_dataset char(50) multi_reader_id integer geotiff_tifftag_copyright char(255) geotiff_tifftag_maxsamplevalue integer fme_rotation float fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_byte_order char(7) fme_feature_type char(50) geotiff_pyramid_level{}.num_rows integer geotiff_private_keys{}.type char(6)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE="LISTBOX_ENCODED"
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FEATURE_TYPES=""
+#!   MAX_FEATURES=""
+#!   MAX_FEATURES_PER_FEATURE_TYPE=""
+#!   MIN_FEATURES=""
+#!   START_FEATURE=""
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="tif file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="Raster1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="Raster File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="MIME_TYPE"
+#!   VALUE="image/TIFF"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the GeoTIFF file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the GeoTIFF file"
+#! />
+#! </DATASET>
+#! <DATASET
+#!   IS_SOURCE="false"
+#!   ROLE="WRITER"
+#!   FORMAT="LAS"
+#!   DATASET="$(DestDataset_LAS)"
+#!   KEYWORD="LAS_2"
+#!   MULTI_GEOM_ALLOWED="true"
+#!   ATTR_MAX_LENGTH="60"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="false"
+#!   EXPOSABLE_ATTRS="fme_fill_color char(50) fme_basename char(50) fme_secondary_axis number(31,15) las_type char(255) las_synthetic_returns logical las_project_id char(36) fme_dataset char(50) las_gps_time_type number(1,0) fme_rotation number(31,15) fme_color char(50) fme_start_angle number(31,15) fme_text_size number(31,15) fme_type char(50) fme_feature_type char(50) las_file_source_id number(6,0) las_file_creation_date date las_zlas_rearranged_points logical las_vertical_coordsys_code number(6,0) fme_primary_axis number(31,15) las_generating_software char(32) las_vertical_datum_code number(6,0) fme_sweep_angle number(31,15) fme_geometry char(50) las_system_identifier char(32) las_vertical_units_code number(6,0) fme_text_string char(50)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE=""
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS="CH1903Plus_1.LV95/01"
+#!   FANOUT_EXPRESSION="&lt;Unused&gt;"
+#!   FANOUT_GROUP="NO"
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="las file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="File1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="LAS File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the LAS file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the LAS file"
+#! />
+#! </DATASET>
+#! </DATASETS>
+#! <DATA_TYPES>
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="datetime"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="time"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="decimal(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="float"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="float"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="integer"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="largeint"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="decimal(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="largeint"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="integer"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(20)"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(12)"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(31,15)"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(15,7)"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(20)"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(12)"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(31,15)"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(15,7)"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="LAS"
+#! />
+#! </DATA_TYPES>
+#! <GEOM_TYPES>
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_raster"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="las_point_cloud"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="las_point_cloud"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="LAS"
+#! />
+#! </GEOM_TYPES>
+#! <FEATURE_TYPES>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="true"
+#!   NODE_NAME="LAS"
+#!   FEATURE_TYPE_NAME=""
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="false"
+#!   IDENTIFIER="2"
+#!   FEAT_GEOMTYPE="las_point_cloud"
+#!   POSITION="-1069.8849601762599 -235.55147610299639"
+#!   BOUNDING_RECT="-1069.8849601762599 -235.55147610299639 454 71"
+#!   ORDER="500000000000000"
+#!   COLLAPSED="true"
+#!   KEYWORD="LAS_1"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   HIDDEN_USER_ATTRS=""
+#!   MERGE_FILTER=""
+#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
+#!   MERGE_FILTER_CASE_SENSITIVE="true"
+#!   DYNAMIC_SCHEMA="false"
+#! >
+#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
+#! </FEATURE_TYPE>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="true"
+#!   NODE_NAME="GEOTIFF"
+#!   FEATURE_TYPE_NAME=""
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="false"
+#!   IDENTIFIER="3"
+#!   FEAT_GEOMTYPE="geotiff_raster"
+#!   POSITION="-1078.5791925327244 154.49930308258965"
+#!   BOUNDING_RECT="-1078.5791925327244 154.49930308258965 454 71"
+#!   ORDER="500000000000000"
+#!   COLLAPSED="true"
+#!   KEYWORD="GEOTIFF_1"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   HIDDEN_USER_ATTRS=""
+#!   MERGE_FILTER=""
+#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
+#!   MERGE_FILTER_CASE_SENSITIVE="false"
+#!   DYNAMIC_SCHEMA="false"
+#! >
+#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
+#! </FEATURE_TYPE>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="false"
+#!   NODE_NAME="LAS01"
+#!   FEATURE_TYPE_NAME="@Value(fme_basename)_CLEAN"
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="true"
+#!   IDENTIFIER="67"
+#!   FEAT_GEOMTYPE="All"
+#!   POSITION="5883.3943172105264 -1701.8038744401044"
+#!   BOUNDING_RECT="5883.3943172105264 -1701.8038744401044 822.51709593866872 71"
+#!   ORDER="500000000000018"
+#!   COLLAPSED="true"
+#!   KEYWORD="LAS_2"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   SCHEMA_ATTRIBUTE_SOURCE="1"
+#! >
+#! </FEATURE_TYPE>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="true"
+#!   NODE_NAME="GEOTIFF"
+#!   FEATURE_TYPE_NAME=""
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="false"
+#!   IDENTIFIER="69"
+#!   FEAT_GEOMTYPE="geotiff_raster"
+#!   POSITION="-1076.8859688596885 -764.40991501184817"
+#!   BOUNDING_RECT="-1076.8859688596885 -764.40991501184817 454 71"
+#!   ORDER="500000000000000"
+#!   COLLAPSED="true"
+#!   KEYWORD="GEOTIFF_2"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   HIDDEN_USER_ATTRS=""
+#!   MERGE_FILTER=""
+#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
+#!   MERGE_FILTER_CASE_SENSITIVE="false"
+#!   DYNAMIC_SCHEMA="false"
+#! >
+#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
+#! </FEATURE_TYPE>
+#! </FEATURE_TYPES>
+#! <FMESERVER>
+#! <READER_DATASETS>
+#! <DATASET
+#!   NAME="LAS_1"
+#!   OVERRIDE="-LAS_1_DATASET"
+#!   DATASET="LAS_1/LAS_2021_norm045_10traj.las"
+#! />
+#! <DATASET
+#!   NAME="GEOTIFF_2"
+#!   OVERRIDE="-GEOTIFF_2_DATASET"
+#!   DATASET="GEOTIFF_2/MNC_GE_Raster_2.tif"
+#! />
+#! <DATASET
+#!   NAME="GEOTIFF_1"
+#!   OVERRIDE="-GEOTIFF_1_DATASET"
+#!   DATASET="GEOTIFF_1/Murs_THOCHB_Buff05_rast.tif"
+#! />
+#! </READER_DATASETS>
+#! <WRITER_DATASETS>
+#! <DATASET
+#!   NAME="LAS_2"
+#!   OVERRIDE="-LAS_2_DATASET"
+#!   DATASET="LAS_2/Comp_pretrait_2021"
+#! />
+#! </WRITER_DATASETS>
+#! </FMESERVER>
+#! <GLOBAL_PARAMETERS>
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las"
+#!   IS_STAND_ALONE="false"
+#! />
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
+#!   IS_STAND_ALONE="false"
+#! />
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_PAST\Comp_pretrait_2021"
+#!   IS_STAND_ALONE="false"
+#! />
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF_3 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif"
+#!   IS_STAND_ALONE="false"
+#! />
+#! </GLOBAL_PARAMETERS>
+#! <COMMENTS>
+#! <COMMENT
+#!   IDENTIFIER="50"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt; with 50cm buffer and rasterized (pixel value = 3)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="-1165.5614675295687 292.97280707294868"
+#!   TOP_LEFT="-1165.5614675295687 292.97280707294868"
+#!   BOTTOM_RIGHT="-202.79458113730072 194.22211956607362"
+#!   BOUNDING_RECT="-1165.5614675295687 292.97280707294868 962.76688639226802 98.750687506875067"
+#!   ORDER="500000000000027"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="0.59607843137254901,0.91764705882352937,0.72549019607843135,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="0"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="51"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;rasterized(pixel value = 1)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="-1139.7498726760314 -616.14091318218152"
+#!   TOP_LEFT="-1139.7498726760314 -616.14091318218152"
+#!   BOTTOM_RIGHT="-578.46323144082498 -714.89160068905653"
+#!   BOUNDING_RECT="-1139.7498726760314 -616.14091318218152 561.28664123520639 98.750687506875067"
+#!   ORDER="500000000000028"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="0.59215686274509804,0.75294117647058822,0.90980392156862744,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="0"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="52"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Extraction of vegetation points (4-5)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="-359.10451665445083 2.1426788735972195"
+#!   TOP_LEFT="-359.10451665445083 2.1426788735972195"
+#!   BOTTOM_RIGHT="192.82107714694172 -96.608008633277848"
+#!   BOUNDING_RECT="-359.10451665445083 2.1426788735972195 551.92559380139255 98.750687506875067"
+#!   ORDER="500000000000029"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="4"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="44"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Addition of new components for wall and canopy informations&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="194.87047996450929 -454.44558381754035"
+#!   TOP_LEFT="194.87047996450929 -454.44558381754035"
+#!   BOTTOM_RIGHT="960.78088440458862 -596.94670882879041"
+#!   BOUNDING_RECT="194.87047996450929 -454.44558381754035 765.91040444007933 142.50112501125011"
+#!   ORDER="500000000000030"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="5"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="53"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;mur&amp;quot; to indicate if the point is situated above a wall (3) or not (0)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="753.10136511177552 494.27736160785571"
+#!   TOP_LEFT="753.10136511177552 494.27736160785571"
+#!   BOTTOM_RIGHT="2064.5153260043239 351.7762365966056"
+#!   BOUNDING_RECT="753.10136511177552 494.27736160785571 1311.4139608925484 142.50112501125011"
+#!   ORDER="500000000000031"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="7"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="54"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;canopy&amp;quot; to indicate if the point is situated under higher canopy (&amp;gt;3m) or not&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="1911.1070036738879 -391.95294768796134"
+#!   TOP_LEFT="1911.1070036738879 -391.95294768796134"
+#!   BOTTOM_RIGHT="2995.375698437836 -534.45407269921145"
+#!   BOUNDING_RECT="1911.1070036738879 -391.95294768796134 1084.2686947639481 142.50112501125011"
+#!   ORDER="500000000000032"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="34"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="55"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out the points of class 4 NOT situated under higher canopy&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="2838.876854100331 -625.39260868799249"
+#!   TOP_LEFT="2838.876854100331 -625.39260868799249"
+#!   BOTTOM_RIGHT="3440.8588766738731 -767.8937336992426"
+#!   BOUNDING_RECT="2838.876854100331 -625.39260868799249 601.98202257354205 142.50112501125011"
+#!   ORDER="500000000000033"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="37"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="56"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out the points of class 4 situated above a wall&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="3098.4352396715458 -1249.2896877730261"
+#!   TOP_LEFT="3098.4352396715458 -1249.2896877730261"
+#!   BOTTOM_RIGHT="3645.3193640978961 -1391.7908127842761"
+#!   BOUNDING_RECT="3098.4352396715458 -1249.2896877730261 546.88412442635035 142.50112501125011"
+#!   ORDER="500000000000034"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="38"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="57"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 3&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="4661.4071588338174 -588.31535203534895"
+#!   TOP_LEFT="4661.4071588338174 -588.31535203534895"
+#!   BOTTOM_RIGHT="5359.0961441529325 -687.06603954222396"
+#!   BOUNDING_RECT="4661.4071588338174 -588.31535203534895 697.68898531911509 98.750687506875067"
+#!   ORDER="500000000000035"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="43"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="59"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Recombination of all points  for writing&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="5258.9106929677328 -1428.3424344986706"
+#!   TOP_LEFT="5258.9106929677328 -1428.3424344986706"
+#!   BOTTOM_RIGHT="6026.8459827455408 -1527.0931220055456"
+#!   BOUNDING_RECT="5258.9106929677328 -1428.3424344986706 767.93528977780807 98.750687506875067"
+#!   ORDER="500000000000037"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="41"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="65"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 4&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="4325.7680028002278 -974.12671167517988"
+#!   TOP_LEFT="4325.7680028002278 -974.12671167517988"
+#!   BOTTOM_RIGHT="5023.4569881193429 -1072.8773991820549"
+#!   BOUNDING_RECT="4325.7680028002278 -974.12671167517988 697.68898531911509 98.750687506875067"
+#!   ORDER="500000000000035"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="64"
+#! />
+#! </COMMENTS>
+#! <CONSTANTS>
+#! </CONSTANTS>
+#! <BOOKMARKS>
+#! <BOOKMARK
+#!   IDENTIFIER="42"
+#!   NAME="Cadastre of walls "
+#!   DESCRIPTION=""
+#!   TOP_LEFT="-1168.8859688596885 382.31765296376369"
+#!   ORDER="500000000000023"
+#!   PALETTE_COLOR="Color5"
+#!   BOTTOM_RIGHT="-126.33105054454791 29.999303082589677"
+#!   BOUNDING_RECT="-1168.8859688596885 382.31765296376369 1042.5549183151406 352.31834988117402"
+#!   STICKY="true"
+#!   COLOUR="0.59607843137254901,0.91764705882352937,0.72549019607843135,1"
+#!   CONTENTS="3 50 "
+#! >
+#! </BOOKMARK>
+#! <BOOKMARK
+#!   IDENTIFIER="48"
+#!   NAME="LAS file"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="-1146.952958891291 -93.086037243351157"
+#!   ORDER="500000000000024"
+#!   PALETTE_COLOR="Color6"
+#!   BOTTOM_RIGHT="-531.56146752956874 -356.37496874968753"
+#!   BOUNDING_RECT="-1146.952958891291 -93.086037243351157 615.39149136172227 263.28893150633638"
+#!   STICKY="true"
+#!   COLOUR="0.59215686274509804,0.8901960784313725,0.90980392156862744,1"
+#!   CONTENTS="2 "
+#! >
+#! </BOOKMARK>
+#! <BOOKMARK
+#!   IDENTIFIER="49"
+#!   NAME="Canopy cover layer"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="-1168.8859688596885 -521.94670882879041"
+#!   ORDER="500000000000025"
+#!   PALETTE_COLOR="Color7"
+#!   BOTTOM_RIGHT="-534.88596885968855 -888.90991501184817"
+#!   BOUNDING_RECT="-1168.8859688596885 -521.94670882879041 634 366.96320618305776"
+#!   STICKY="true"
+#!   COLOUR="0.59215686274509804,0.75294117647058822,0.90980392156862744,1"
+#!   CONTENTS="51 69 "
+#! >
+#! </BOOKMARK>
+#! <BOOKMARK
+#!   IDENTIFIER="58"
+#!   NAME="New LAS file cleaned"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="5795.3943172105264 -1573.3038744401044"
+#!   ORDER="500000000000036"
+#!   PALETTE_COLOR="Color8"
+#!   BOTTOM_RIGHT="6797.9114131491951 -1826.3038744401044"
+#!   BOUNDING_RECT="5795.3943172105264 -1573.3038744401044 1002.5170959386687 253"
+#!   STICKY="true"
+#!   COLOUR="0.62352941176470589,0.5725490196078431,0.8784313725490196,1"
+#!   CONTENTS="67 "
+#! >
+#! </BOOKMARK>
+#! </BOOKMARKS>
+#! <TRANSFORMERS>
+#! <TRANSFORMER
+#!   IDENTIFIER="4"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="-513.92559380139255 -231.87496874968753"
+#!   BOUNDING_RECT="-513.92559380139255 -231.87496874968753 454 71"
+#!   ORDER="500000000000001"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;trunks&lt;space&gt;&lt;openparen&gt;10&lt;closeparen&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==10 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;trunks&lt;space&gt;&lt;openparen&gt;10&lt;closeparen&gt;"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="5"
+#!   TYPE="PointCloudComponentAdder"
+#!   VERSION="1"
+#!   POSITION="139.7844427211582 -178.84192352561826"
+#!   BOUNDING_RECT="139.7844427211582 -178.84192352561826 580.00106825772946 71"
+#!   ORDER="500000000000002"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD" PARM_VALUE="mur,Real64,0,canopy,Real64,0"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudComponentAdder"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="7"
+#!   TYPE="PointCloudOnRasterComponentSetter"
+#!   VERSION="3"
+#!   POSITION="753.10136511177552 292.97280707294868"
+#!   BOUNDING_RECT="753.10136511177552 292.97280707294868 430 71"
+#!   ORDER="500000000000003"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="PointCloud"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|mur|$(SourceDataset_GEOTIFF)"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
+#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="31"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="1279.7025517152713 105.50039237765995"
+#!   BOUNDING_RECT="1279.7025517152713 105.50039237765995 454 71"
+#!   ORDER="500000000000012"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4-10"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="5"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="3"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==10 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10 ; 5"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_4"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="34"
+#!   TYPE="PointCloudOnRasterComponentSetter"
+#!   VERSION="3"
+#!   POSITION="1827.9944704208951 -655.35918706950406"
+#!   BOUNDING_RECT="1827.9944704208951 -655.35918706950406 785.00106825772946 71"
+#!   ORDER="500000000000013"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="PointCloud"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|canopy|0"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
+#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_3"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="37"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="2777.1418141967411 -846.6441712036177"
+#!   BOUNDING_RECT="2777.1418141967411 -846.6441712036177 454 71"
+#!   ORDER="500000000000014"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4-10&lt;space&gt;out"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;canopy&lt;closeparen&gt;&lt;lt&gt;1 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10&lt;space&gt;out"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_5"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="38"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="3403.0386186329533 -974.12671167517988"
+#!   BOUNDING_RECT="3403.0386186329533 -974.12671167517988 454 71"
+#!   ORDER="500000000000014"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4-10&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_6"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="41"
+#!   TYPE="PointCloudCombiner"
+#!   VERSION="6"
+#!   POSITION="5293.5861916376134 -1635.7640714809982"
+#!   BOUNDING_RECT="5293.5861916376134 -1635.7640714809982 454 71"
+#!   ORDER="500000000000015"
+#!   PARMS_EDITED="false"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="71"
+#!   TYPE="PointCloudCombiner"
+#!   VERSION="6"
+#!   POSITION="3937.113505116753 -673.01884029790165"
+#!   BOUNDING_RECT="3937.113505116753 -673.01884029790165 454 71"
+#!   ORDER="500000000000015"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner_2"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="43"
+#!   TYPE="PointCloudExpressionEvaluator"
+#!   VERSION="3"
+#!   POSITION="4523.208588337473 -738.68854619282229"
+#!   BOUNDING_RECT="4523.208588337473 -738.68854619282229 669.00106825772946 71"
+#!   ORDER="500000000000019"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="RESULT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 3"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_2"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="64"
+#!   TYPE="PointCloudExpressionEvaluator"
+#!   VERSION="3"
+#!   POSITION="4187.5694323038824 -1121.728091283936"
+#!   BOUNDING_RECT="4187.5694323038824 -1121.728091283936 669.00106825772946 71"
+#!   ORDER="500000000000019"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="RESULT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 4"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_3"/>
+#! </TRANSFORMER>
+#! </TRANSFORMERS>
+#! <FEAT_LINKS>
+#! <FEAT_LINK
+#!   IDENTIFIER="8"
+#!   SOURCE_NODE="2"
+#!   TARGET_NODE="4"
+#!   SOURCE_PORT_DESC="-1"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="9"
+#!   SOURCE_NODE="3"
+#!   TARGET_NODE="7"
+#!   SOURCE_PORT_DESC="-1"
+#!   TARGET_PORT_DESC="fi 1 Raster"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="70"
+#!   SOURCE_NODE="69"
+#!   TARGET_NODE="34"
+#!   SOURCE_PORT_DESC="-1"
+#!   TARGET_PORT_DESC="fi 1 Raster"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="60"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="5"
+#!   SOURCE_PORT_DESC="fo 0 V&lt;lt&gt;u00e9&lt;gt&gt;g&lt;lt&gt;u00e9&lt;gt&gt;tation&lt;lt&gt;space&lt;gt&gt;moyenne&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;4&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;haute&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;5&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;trunks&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;10&lt;lt&gt;closeparen&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="22"
+#!   SOURCE_NODE="5"
+#!   TARGET_NODE="7"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="fi 0 PointCloud"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="32"
+#!   SOURCE_NODE="7"
+#!   TARGET_NODE="31"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="61"
+#!   SOURCE_NODE="31"
+#!   TARGET_NODE="34"
+#!   SOURCE_PORT_DESC="fo 0 4-10"
+#!   TARGET_PORT_DESC="fi 0 PointCloud"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="39"
+#!   SOURCE_NODE="34"
+#!   TARGET_NODE="37"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="62"
+#!   SOURCE_NODE="37"
+#!   TARGET_NODE="71"
+#!   SOURCE_PORT_DESC="fo 0 4-10&lt;lt&gt;space&lt;gt&gt;out"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="63"
+#!   SOURCE_NODE="38"
+#!   TARGET_NODE="71"
+#!   SOURCE_PORT_DESC="fo 0 4-10&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="68"
+#!   SOURCE_NODE="41"
+#!   TARGET_NODE="67"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="-1"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="47"
+#!   SOURCE_NODE="43"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 0 RESULT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="36"
+#!   SOURCE_NODE="64"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 0 RESULT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="46"
+#!   SOURCE_NODE="71"
+#!   TARGET_NODE="43"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="45"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="33"
+#!   SOURCE_NODE="31"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 1 5"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="40"
+#!   SOURCE_NODE="37"
+#!   TARGET_NODE="38"
+#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="66"
+#!   SOURCE_NODE="38"
+#!   TARGET_NODE="64"
+#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! </FEAT_LINKS>
+#! <BREAKPOINTS>
+#! </BREAKPOINTS>
+#! <ATTR_LINKS>
+#! </ATTR_LINKS>
+#! <SUBDOCUMENTS>
+#! </SUBDOCUMENTS>
+#! <LOOKUP_TABLES>
+#! </LOOKUP_TABLES>
+#! </WORKSPACE>
+
+FME_PYTHON_VERSION 37
+GUI IGNORE SourceDataset_LAS_1,LAS_IN_USE_SEARCH_ENVELOPE_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1,LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1,LAS_IN_CLIP_TO_ENVELOPE_LAS_1,LAS_IN_NETWORK_AUTHENTICATION_LAS_1,SourceDataset_GEOTIFF_1,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1,SourceDataset_GEOTIFF_2,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2,DestDataset_LAS_2,LAS_OUT_FME_GROUP_NAMED1_LAS_2,LAS_OUT_VERSION_LAS_2,LAS_OUT_COMPRESSION_LAS_2,LAS_OUT_USER_GROUP_LAS_2,LAS_OUT_USER_COMPONENTS_LAS_2,LAS_OUT_ADVANCED_PARAMETERS_LAS_2,LAS_OUT_LAS_DATASET_FILE_LAS_2,LAS_OUT_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_ZLAS_PARAMETERS_LAS_2,LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2
+DEFAULT_MACRO SourceDataset_LAS G:\STDL\LIDAR_PAST\Comp_pretrait_2021\LAS_2021_norm045_10traj.las
+GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):
+DEFAULT_MACRO SourceDataset_GEOTIFF G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif
+GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
+DEFAULT_MACRO DestDataset_LAS G:\STDL\LIDAR_PAST\Comp_pretrait_2021
+GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:
+DEFAULT_MACRO SourceDataset_GEOTIFF_3 G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\MNC_GE_Raster_2.tif
+GUI MULTIFILE SourceDataset_GEOTIFF_3 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
+INCLUDE [ if {{$(SourceDataset_LAS)} == {}} { puts_real {Parameter 'SourceDataset_LAS' must be given a value.}; exit 1; }; ]
+INCLUDE [ if {{$(SourceDataset_GEOTIFF)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF' must be given a value.}; exit 1; }; ]
+INCLUDE [ if {{$(DestDataset_LAS)} == {}} { puts_real {Parameter 'DestDataset_LAS' must be given a value.}; exit 1; }; ]
+INCLUDE [ if {{$(SourceDataset_GEOTIFF_3)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF_3' must be given a value.}; exit 1; }; ]
+#! START_HEADER
+#! START_WB_HEADER
+READER_TYPE MULTI_READER
+MULTI_READER_TYPE{0} LAS
+MULTI_READER_KEYWORD{0} LAS_1
+MULTI_READER_GEN_DIRECTIVES{0} USE_SEARCH_ENVELOPE,NO,CLIP_TO_ENVELOPE,NO,READER_META_ATTRIBUTES,fme_dataset,GROUP_BY_DATASET,No,_MERGE_SCHEMAS,YES,SEARCH_ENVELOPE_MAXX,0,SEARCH_ENVELOPE_MAXY,0,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MINY,0,LAS_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0
+MULTI_READER_TYPE{1} GEOTIFF
+MULTI_READER_KEYWORD{1} GEOTIFF_1
+MULTI_READER_GEN_DIRECTIVES{1} APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MAXY,0,USE_SEARCH_ENVELOPE,NO,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXX,0,IGNORE_RASTER_TYPE_KEY,No,FEATURE_TYPE_NAME,FORMAT_NAME,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PYRAMID_LEVEL,,GEOTIFF_RDR_ADV_PARM_GROUP,,PREFER_FILE_CS_UNITS,Yes,READ_OFFSETS_IN_CS_UNITS,No,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,CLIP_TO_ENVELOPE,NO
+MULTI_READER_TYPE{2} GEOTIFF
+MULTI_READER_KEYWORD{2} GEOTIFF_2
+MULTI_READER_GEN_DIRECTIVES{2} IGNORE_RASTER_TYPE_KEY,No,GEOTIFF_EXPOSE_FORMAT_ATTRS,,PYRAMID_LEVEL,,USE_SEARCH_ENVELOPE,NO,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXY,0,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_RDR_ADV_PARM_GROUP,,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MAXX,0,CLIP_TO_ENVELOPE,NO,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PREFER_FILE_CS_UNITS,Yes,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,READ_OFFSETS_IN_CS_UNITS,No,FEATURE_TYPE_NAME,FORMAT_NAME,APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,
+WRITER_TYPE MULTI_WRITER
+MULTI_WRITER_DATASET_ORDER BY_ID
+MULTI_WRITER_FIRST_WRITER_ID 0
+MULTI_WRITER_TYPE{0} LAS
+MULTI_WRITER_KEYWORD{0} LAS_2
+#! END_WB_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "LAS_1"
+#! END_WB_HEADER
+#! START_SOURCE_HEADER LAS LAS_1
+# =======================================================================
+# The following GUI line prompts for a file to be used as the source LAS file.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be read.
+# The dataset this mapping file was generated from was:
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO SourceDataset
+INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
+ puts {DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset)}     \
+ } ]
+#! END_WB_HEADER
+#! START_SOURCE_HEADER LAS LAS_1
+DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset_LAS)
+GUI MULTIFILE SourceDataset_LAS_1 LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|All_files(*)|* Source ASPRS LAS File(s):
+DEFAULT_MACRO LAS_IN_READER_META_ATTRIBUTES_LAS_1 fme_dataset
+LAS_1_READER_META_ATTRIBUTES "$(LAS_IN_READER_META_ATTRIBUTES_LAS_1)"
+DEFAULT_MACRO LAS_IN_GROUP_BY_DATASET_LAS_1 No
+LAS_1_GROUP_BY_DATASET "$(LAS_IN_GROUP_BY_DATASET_LAS_1)"
+DEFAULT_MACRO LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1 
+LAS_1_EXPOSE_ATTRS_GROUP "$(LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1)"
+# Include this file in source setting section to add external search envelope processing
+# Zero as a default means we don't do any search -- this makes workbench happier
+DEFAULT_MACRO LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 NO
+LAS_1_USE_SEARCH_ENVELOPE "$(LAS_IN_USE_SEARCH_ENVELOPE_LAS_1)"
+GUI ACTIVEDISCLOSUREGROUP LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1%LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1%LAS_IN_CLIP_TO_ENVELOPE_LAS_1%LAS_IN_SEARCH_METHOD%LAS_IN_SEARCH_METHOD_FILTER%LAS_IN_SEARCH_ORDER%LAS_IN_SEARCH_FEATURE%LAS_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 Minimum X:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 Minimum Y:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 Maximum X:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 Maximum Y:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 <Unused>, 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1)"
+GUI OPTIONAL COORDSYS LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 Search Envelope Coordinate System:
+# ===========================================================================
+# BUG18999: We now have a soft clip to fall back on like native spatial index
+# thus we are reintroducing the clip to envelop as an option for users.
+# Defualt to soft clip as per the existing database readers we are emulating
+GUI LOOKUP LAS_IN_CLIP_TO_ENVELOPE_LAS_1 <Unused>,NO 
+DEFAULT_MACRO LAS_IN_CLIP_TO_ENVELOPE_LAS_1 NO
+LAS_1_CLIP_TO_ENVELOPE "$(LAS_IN_CLIP_TO_ENVELOPE_LAS_1)"
+GUI OPTIONAL CHECKBOX LAS_IN_CLIP_TO_ENVELOPE_LAS_1 YES%NO Clip to Search Envelope
+# ===========================================================================
+DEFAULT_MACRO LAS_IN_NETWORK_AUTHENTICATION_LAS_1 
+LAS_1_NETWORK_AUTHENTICATION "$(LAS_IN_NETWORK_AUTHENTICATION_LAS_1)"
+GUI OPTIONAL AUTHENTICATOR LAS_IN_NETWORK_AUTHENTICATION_LAS_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
+# ============================================================================ 
+DEFAULT_MACRO LAS_IN_ATTRIBUTE_READING_LAS_1 ALL
+LAS_1_ATTRIBUTE_READING "$(LAS_IN_ATTRIBUTE_READING_LAS_1)"
+# ============================================================================ 
+LAS_1_GENERATE_FME_BUILD_NUM 20596
+LAS_1_DATASET "$(SourceDataset_LAS_1)"
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "GEOTIFF_1"
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
+# =======================================================================
+# The following GUI line prompts for a file to be used as the source GEOTIFF file.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be read.
+# The dataset this mapping file was generated from was:
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO SourceDataset
+INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
+ puts {DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset)}     \
+ } ]
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
+DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset_GEOTIFF)
+GUI MULTIFILE SourceDataset_GEOTIFF_1 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
+DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1 fme_dataset fme_basename
+GEOTIFF_1_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1)"
+DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1 FORMAT_NAME
+GEOTIFF_1_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1)"
+DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 NO
+GEOTIFF_1_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Apply GCP's
+DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 NearestNeighbor
+GEOTIFF_1_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1)"
+GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
+GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 <Unused>,NearestNeighbor 
+DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1 
+GEOTIFF_1_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1)"
+# Include this file in source setting section to add external search envelope processing
+# Zero as a default means we don't do any search -- this makes workbench happier
+DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 NO
+GEOTIFF_1_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 Minimum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 Minimum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 Maximum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 Maximum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 <Unused>, 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1)"
+GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 Search Envelope Coordinate System:
+# ===========================================================================
+# BUG18999: We now have a soft clip to fall back on like native spatial index
+# thus we are reintroducing the clip to envelop as an option for users.
+# Defualt to soft clip as per the existing database readers we are emulating
+GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 <Unused>,NO 
+DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 NO
+GEOTIFF_1_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1)"
+GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 YES%NO Clip to Search Envelope
+DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 
+GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Advanced
+DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 
+GEOTIFF_1_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1)"
+GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 Pyramid Level to Read:
+DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes
+GEOTIFF_1_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes%No Prefer File Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 No
+GEOTIFF_1_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 Yes%No Offsets in Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 No
+GEOTIFF_1_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Yes%No Ignore Raster Type Key:
+# ===========================================================================
+DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 
+GEOTIFF_1_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1)"
+GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
+# ============================================================================ 
+DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1 ALL
+GEOTIFF_1_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1)"
+# ============================================================================ 
+GEOTIFF_1_GENERATE_FME_BUILD_NUM 20596
+GEOTIFF_1_DATASET "$(SourceDataset_GEOTIFF_1)"
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "GEOTIFF_2"
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_2
+# =======================================================================
+# The following GUI line prompts for a file to be used as the source GEOTIFF file.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be read.
+# The dataset this mapping file was generated from was:
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO SourceDataset
+INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
+ puts {DEFAULT_MACRO SourceDataset_GEOTIFF_2 $(SourceDataset)}     \
+ } ]
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_2
+DEFAULT_MACRO SourceDataset_GEOTIFF_2 $(SourceDataset_GEOTIFF_3)
+GUI MULTIFILE SourceDataset_GEOTIFF_2 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
+DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_2 fme_dataset fme_basename
+GEOTIFF_2_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_2)"
+DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_2 FORMAT_NAME
+GEOTIFF_2_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_2)"
+DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2 NO
+GEOTIFF_2_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_2 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 Apply GCP's
+DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 NearestNeighbor
+GEOTIFF_2_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2)"
+GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
+GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_2 <Unused>,NearestNeighbor 
+DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_2 
+GEOTIFF_2_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_2)"
+# Include this file in source setting section to add external search envelope processing
+# Zero as a default means we don't do any search -- this makes workbench happier
+DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2 NO
+GEOTIFF_2_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_2 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 0
+GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_2 Minimum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 0
+GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_2 Minimum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 0
+GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_2 Maximum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 0
+GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_2 Maximum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 <Unused>, 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 
+GEOTIFF_2_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2)"
+GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_2 Search Envelope Coordinate System:
+# ===========================================================================
+# BUG18999: We now have a soft clip to fall back on like native spatial index
+# thus we are reintroducing the clip to envelop as an option for users.
+# Defualt to soft clip as per the existing database readers we are emulating
+GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 <Unused>,NO 
+DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 NO
+GEOTIFF_2_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2)"
+GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_2 YES%NO Clip to Search Envelope
+DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2 
+GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_2 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 Advanced
+DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2 
+GEOTIFF_2_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2)"
+GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_2 Pyramid Level to Read:
+DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2 Yes
+GEOTIFF_2_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2)"
+GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_2 Yes%No Prefer File Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2 No
+GEOTIFF_2_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2)"
+GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_2 Yes%No Offsets in Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 No
+GEOTIFF_2_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2)"
+GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_2 Yes%No Ignore Raster Type Key:
+# ===========================================================================
+DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2 
+GEOTIFF_2_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2)"
+GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_2 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
+# ============================================================================ 
+DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_2 ALL
+GEOTIFF_2_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_2)"
+# ============================================================================ 
+GEOTIFF_2_GENERATE_FME_BUILD_NUM 20596
+GEOTIFF_2_DATASET "$(SourceDataset_GEOTIFF_2)"
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "LAS_2"
+#! END_WB_HEADER
+#! START_DEST_HEADER LAS LAS_2
+# The following GUI lines prompt for a LAS file to be used as the
+# the destination of the data.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be written.
+#! END_DEST_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO DestDataset
+INCLUDE [ if {"$(DestDataset)" != ""} {                          \
+ puts {DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset)}         \
+ } ]
+#! END_WB_HEADER
+#! START_DEST_HEADER LAS LAS_2
+DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset_LAS)
+GUI DIRNAME DestDataset_LAS_2 Destination ASPRS LAS Folder:
+DEFAULT_MACRO LAS_OUT_FME_GROUP_NAMED1_LAS_2 FME_DISCLOSURE_OPEN
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_FME_GROUP_NAMED1_LAS_2 LAS_OUT_VERSION_LAS_2%LAS_OUT_COMPRESSION_LAS_2 Parameters
+# ============================================================================
+# Version
+DEFAULT_MACRO LAS_OUT_VERSION_LAS_2 1.4
+LAS_2_VERSION "$(LAS_OUT_VERSION_LAS_2)"
+GUI LOOKUP_CHOICE LAS_OUT_VERSION_LAS_2 1.0,1.0%1.1,1.1%1.2,1.2%1.3,1.3%"\"1.4 (Legacy Compatible)\",1.4-legacy-compatible"%1.4,1.4 ASPRS LAS Version:
+# [PR#30472] Compression
+DEFAULT_MACRO LAS_OUT_COMPRESSION_LAS_2 None
+LAS_2_COMPRESSION "$(LAS_OUT_COMPRESSION_LAS_2)"
+GUI ACTIVECHOICE LAS_OUT_COMPRESSION_LAS_2 None,LAS_OUT_ZLAS_PARAMETERS_LAS_2%LAZ,LAS_OUT_ZLAS_PARAMETERS_LAS_2%zLAS Compression
+# This is a placeholder parameter that will be replaced with a custom table in the controller
+DEFAULT_MACRO LAS_OUT_USER_GROUP_LAS_2 FME_DISCLOSURE_OPEN
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_USER_GROUP_LAS_2 LAS_OUT_USER_COMPONENTS_LAS_2 Additional User Components
+DEFAULT_MACRO LAS_OUT_USER_COMPONENTS_LAS_2 Distance<comma>Normal<comma>Group
+LAS_2_USER_COMPONENTS "$(LAS_OUT_USER_COMPONENTS_LAS_2)"
+GUI OPTIONAL GUI_LINE_TABLE_ENCODED LAS_OUT_USER_COMPONENTS_LAS_2 NO_LABEL%ROW_DELIM:,%COL_DELIM:,%"User Components"%"STRING COMPONENTS" User Components
+# ============================================================================
+# Opt in for destination dataset type vs format type validation
+DEFAULT_MACRO LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2 Yes
+LAS_2_DESTINATION_DATASETTYPE_VALIDATION "$(LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2)"
+DEFAULT_MACRO LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2 FEATURE
+LAS_2_COORDINATE_SYSTEM_GRANULARITY "$(LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2)"
+DEFAULT_MACRO LAS_OUT_ADVANCED_PARAMETERS_LAS_2 FME_DISCLOSURE_CLOSED
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ADVANCED_PARAMETERS_LAS_2 LAS_OUT_LAS_DATASET_FILE_LAS_2%LAS_OUT_ZLAS_PARAMETERS_LAS_2 Advanced
+DEFAULT_MACRO LAS_OUT_LAS_DATASET_FILE_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_LAS_DATASET_FILE_LAS_2 LAS_OUT_ARCGIS_LAS_DATASET_LAS_2%LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 LAS Dataset File
+# The following GUI line provides the ability to create an
+# Esri ArcGIS LAS Dataset encapsulating the LAS files produced
+# by this translation. The LAS Dataset can then be used to view
+# the output using Esri's tools.
+DEFAULT_MACRO LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 
+LAS_2_ARCGIS_LAS_DATASET "$(LAS_OUT_ARCGIS_LAS_DATASET_LAS_2)"
+GUI OPTIONAL TEXT LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 ArcGIS LAS Dataset (.lasd) Filename
+# The following GUI line determines whether statistics should
+# be calculated on the ArcGIS LAS Dataset. This keyword is
+# applicable when FME is creating an ArcGIS LAS Dataset.
+DEFAULT_MACRO LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 No
+LAS_2_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET "$(LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2)"
+GUI CHOICE LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 Yes%No Compute Statistics on ArcGIS LAS Dataset
+DEFAULT_MACRO LAS_OUT_ZLAS_PARAMETERS_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ZLAS_PARAMETERS_LAS_2 LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Parameters
+DEFAULT_MACRO LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 <Unused>
+LAS_2_ZLAS_REARRANGE_POINTS "$(LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2)"
+GUI CHOICE LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 Yes%No Rearrange Points for zLAS Compression
+DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 <Unused>
+LAS_2_ZLAS_POINT_SPACING_SOURCE "$(LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2)"
+GUI LOOKUP_CHOICE LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 "\"Scan Points\",scan"%"\"From Header\",header"%"\"Specify Value\",specify" zLAS Point Spacing Source
+DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 <Unused>
+LAS_2_ZLAS_POINT_SPACING_VALUE "$(LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2)"
+GUI FLOAT LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Point Spacing Value
+# ============================================================================ 
+LAS_2_GENERATE_FME_BUILD_NUM 20596
+LAS_2_DATASET "$(DestDataset_LAS_2)"
+#! END_DEST_HEADER
+#! START_WB_HEADER
+#! END_WB_HEADER
+#! END_HEADER
+
+LOG_FILTER_MASK -1
+LOG_MAX_FEATURES 200
+LOG_MAX_RECORDED_FEATURES 200
+FME_REPROJECTION_ENGINE FME
+FME_IMPLICIT_CSMAP_REPROJECTION_MODE Auto
+FME_GEOMETRY_HANDLING Enhanced
+FME_STROKE_MAX_DEVIATION 0
+DEFAULT_MACRO DATASET_KEYWORD_LAS_1 LAS_1
+DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_1 GEOTIFF_1
+DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_2 GEOTIFF_2
+DEFAULT_MACRO DATASET_KEYWORD_LAS_2 LAS_2
+# -------------------------------------------------------------------------
+
+LAS_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
+
+# -------------------------------------------------------------------------
+
+GEOTIFF_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
+
+# -------------------------------------------------------------------------
+
+GEOTIFF_2_READER_META_ATTRIBUTES fme_feature_type fme_basename
+
+# -------------------------------------------------------------------------
+
+LAS_2_COORDINATE_SYSTEM CH1903Plus_1.LV95/01
+MULTI_READER_CONTINUE_ON_READER_FAILURE No
+
+# -------------------------------------------------------------------------
+
+MACRO WORKSPACE_NAME LAS_Pretraitement_2021_cleaning_MNC_class10
+MACRO FME_VIEWER_APP fmedatainspector
+# -------------------------------------------------------------------------
+LAS_1_DEF LAS
+# -------------------------------------------------------------------------
+GEOTIFF_1_DEF GEOTIFF
+# -------------------------------------------------------------------------
+GEOTIFF_2_DEF GEOTIFF
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * RoutingFactory   FACTORY_NAME "Router and Unexpected Input Remover"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE LAS LAS_1::LAS multi_reader_keyword,$(DATASET_KEYWORD_LAS_1) TO FME_GENERIC ::LAS ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_1::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_1) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_2::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_2) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    MERGE_INPUT Yes   OUTPUT ROUTED FEATURE_TYPE *
+LAS_1_MERGE_DEF LAS_1::LAS EXACT LAS
+GEOTIFF_1_MERGE_DEF GEOTIFF_1::GEOTIFF EXACT GEOTIFF
+GEOTIFF_2_MERGE_DEF GEOTIFF_2::GEOTIFF EXACT GEOTIFF
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory    FACTORY_NAME "LAS_LAS_1 Splitter"    INPUT FEATURE_TYPE LAS    OUTPUT FEATURE_TYPE LAS_LAS_1
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_1 Splitter"    INPUT FEATURE_TYPE GEOTIFF      multi_reader_keyword $(DATASET_KEYWORD_GEOTIFF_1)    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_1
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_2 Splitter"    INPUT FEATURE_TYPE GEOTIFF      multi_reader_keyword $(DATASET_KEYWORD_GEOTIFF_2)    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_2
+DEFAULT_MACRO WB_CURRENT_CONTEXT
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter    INPUT  FEATURE_TYPE LAS_LAS_1    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==5<space>||<space><at>Component<openparen>classification<closeparen>==10 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * TeeFactory    FACTORY_NAME PointCloudComponentAdder    INPUT  FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen><space>+<space>trunks<space><openparen>10<closeparen>    OUTPUT FEATURE_TYPE ___TOREJECTOR___       @RenameAttributes(FME_STRICT,___fme_rejection_code___,fme_rejection_code)       @AddPointCloudComponents(REJECTABLE,mur,Real64,0,canopy,Real64,0)
+FACTORY_DEF * TestFactory    FACTORY_NAME PointCloudComponentAdder_Rejector    INPUT FEATURE_TYPE ___TOREJECTOR___    TEST @Value(fme_rejection_code) != ""    OUTPUT PASSED FEATURE_TYPE PointCloudComponentAdder_<REJECTED>       @RemoveAttributes(___fme_rejection_code___)    OUTPUT FAILED FEATURE_TYPE PointCloudComponentAdder_OUTPUT       @RenameAttributes(FME_STRICT,fme_rejection_code,___fme_rejection_code___)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudComponentAdder_<Rejected> INPUT FEATURE_TYPE PointCloudComponentAdder_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudComponentAdder<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|mur|$(SourceDataset_GEOTIFF)} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
+FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter    INPUT  FEATURE_TYPE PointCloudComponentAdder_OUTPUT    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_1    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_4    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==10 ; <at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10 ; 5    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_4_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_4-10    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = 5 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_5    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_4 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_4_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_4<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|canopy|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
+FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_3    INPUT  FEATURE_TYPE PointCloudFilter_4_4-10    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_2    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_3_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_3_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_5    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>canopy<closeparen><lt>1 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10<space>out    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_5_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_5_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10<space>out OUTPUT PASSED FEATURE_TYPE PointCloudFilter_5_4-10<space>out    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_5_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_5<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_6    INPUT  FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4-10<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_6_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_6_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4-10<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_6_4-10<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_6_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_6<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+DEFAULT_MACRO PointCloudExpressionEvaluator_3_COMPONENT_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_3_COMPONENT_TYPE_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_3_EXPRESSION_LIST
+INCLUDE [    foreach {component componenttype expression} [split {classification Auto 4}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_3_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_3    INPUT  FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_3_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_3_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_3_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_3_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_3_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_3_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner_2___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_5_4-10<space>out    INPUT  FEATURE_TYPE PointCloudFilter_6_4-10<space>-<space>mur    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner_2)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
+FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner_2___Combiner    INPUT FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_2_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_2_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_EXPRESSION_LIST
+INCLUDE [    foreach {component componenttype expression} [split {classification Auto 3}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_2_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_2    INPUT  FEATURE_TYPE PointCloudCombiner_2_OUTPUT    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_2_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_2_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner___VectorMerger    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_3_RESULT    INPUT  FEATURE_TYPE PointCloudFilter_<UNFILTERED>    INPUT  FEATURE_TYPE PointCloudFilter_4_5    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
+FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner___Combiner    INPUT FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * RoutingFactory FACTORY_NAME "Destination Feature Type Routing Correlator"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE FME_GENERIC PointCloudCombiner_OUTPUT TO LAS __GO_TO_FINAL_OUTPUT_ROUTER__ multi_writer_id,0,<at>SupplyAttributes<openparen>ENCODED<comma>fme_template_feature_type<comma>LAS01<closeparen>,<at>EvaluateExpression<openparen>ATTR_CREATE_EXPR<comma>__wb_out_feat_type__<comma><lt>at<gt>Value<lt>openparen<gt>fme_basename<lt>closeparen<gt>_CLEAN<comma>LAS01<closeparen> COORDINATE_SYSTEM CH1903Plus_1.LV95/01 GEOMETRY   FEATURE_TYPE_ATTRIBUTE __wb_out_feat_type__   OUTPUT ROUTED FEATURE_TYPE *    OUTPUT NOT_ROUTED FEATURE_TYPE __nuke_me__ @Tcl2("FME_StatMessage 818059 [FME_GetAttribute fme_template_feature_type] 818060 818061 fme_warn")
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory   FACTORY_NAME "Final Output Nuker"   INPUT FEATURE_TYPE __nuke_me__
+
+# -------------------------------------------------------------------------
+LAS_2_DEF LAS01
diff --git a/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning_alternative.fmw b/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning_alternative.fmw
index 5fd0bf8..f2602f8 100644
--- a/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning_alternative.fmw
+++ b/PROJ-TREEDET/resources/LAS_Preprocess_2021_cleaning_alternative.fmw
@@ -1,2654 +1,2654 @@
-#! <?xml version="1.0" encoding="UTF-8" ?>
-#! <WORKSPACE
-#    Command-line to run this workspace:
-#        "C:\Program Files (x86)\FME2020\fme.exe" G:\STDL\LIDAR_2021\Scripts_et_Processus\LAS_Pretraitement_2021_cleaning_MNHC.fmw
-#              --SourceDataset_LAS "G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las"
-#              --SourceDataset_GEOTIFF "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
-#              --DestDataset_LAS "G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1"
-#    
-#!   ATTR_TYPE_ENCODING="SDF"
-#!   BEGIN_PYTHON=""
-#!   BEGIN_TCL=""
-#!   CATEGORY=""
-#!   DESCRIPTION=""
-#!   DESTINATION="NONE"
-#!   DESTINATION_ROUTING_FILE=""
-#!   DOC_EXTENTS="8882.7 3257.1"
-#!   DOC_TOP_LEFT="-1168.89 -2802.58"
-#!   END_PYTHON=""
-#!   END_TCL=""
-#!   EXPLICIT_BOOKMARK_ORDER="false"
-#!   FME_BUILD_NUM="20596"
-#!   FME_DOCUMENT_GUID="13630376-052c-4951-806c-6d68a363e1db"
-#!   FME_DOCUMENT_PRIORGUID="e44176b6-c7b1-43ea-b9f4-2c32a085725b,c381042f-601f-4ea6-8815-83d7bd38b88a,f7a0bbd2-1db7-4a74-ae55-a63987eae69b,078fad80-7051-4100-84e6-4696f553bbea,51ed0ff3-37f8-45b3-9ff8-b75998c54609,a59d9bc8-853b-4bc5-b623-147dc834d4d4,4f78c6c4-ded3-4776-b8ea-5b68e5da3bbf,3296ce31-5f45-4f4d-9043-d690711b051f,3245acd7-3769-436b-af73-f216ec552967"
-#!   FME_GEOMETRY_HANDLING="Enhanced"
-#!   FME_IMPLICIT_CSMAP_REPROJECTION_MODE="Auto"
-#!   FME_REPROJECTION_ENGINE="FME"
-#!   FME_SERVER_SERVICES=""
-#!   FME_STROKE_MAX_DEVIATION="0"
-#!   HISTORY=""
-#!   IGNORE_READER_FAILURE="No"
-#!   LAST_SAVE_BUILD="FME(R) 2020.1.0.1 (20200710 - Build 20596 - WIN32)"
-#!   LAST_SAVE_DATE="2022-01-12T17:51:04"
-#!   LOG_FILE=""
-#!   LOG_MAX_RECORDED_FEATURES="200"
-#!   MARKDOWN_DESCRIPTION=""
-#!   MARKDOWN_USAGE=""
-#!   MAX_LOG_FEATURES="200"
-#!   MULTI_WRITER_DATASET_ORDER="BY_ID"
-#!   PASSWORD=""
-#!   PYTHON_COMPATIBILITY="37"
-#!   REDIRECT_TERMINATORS="NONE"
-#!   SAVE_ON_PROMPT_AND_RUN="Yes"
-#!   SHOW_ANNOTATIONS="true"
-#!   SHOW_INFO_NODES="true"
-#!   SOURCE="NONE"
-#!   SOURCE_ROUTING_FILE=""
-#!   TERMINATE_REJECTED="YES"
-#!   TITLE=""
-#!   USAGE=""
-#!   USE_MARKDOWN=""
-#!   VIEW_POSITION="2448.6 443.042"
-#!   WARN_INVALID_XFORM_PARAM="Yes"
-#!   WORKSPACE_VERSION="1"
-#!   ZOOM_SCALE="79"
-#! >
-#! <DATASETS>
-#! <DATASET
-#!   IS_SOURCE="true"
-#!   ROLE="READER"
-#!   FORMAT="LAS"
-#!   DATASET="$(SourceDataset_LAS)"
-#!   KEYWORD="LAS_1"
-#!   MULTI_GEOM_ALLOWED="false"
-#!   ATTR_MAX_LENGTH="0"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="false"
-#!   EXPOSABLE_ATTRS="fme_secondary_axis number(31,15) las_file_creation_date date las_project_id char(36) las_synthetic_returns logical las_generating_software char(32) fme_sweep_angle number(31,15) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_basename char(50) fme_feature_type char(50) las_file_source_id number(6,0) fme_color char(50) fme_type char(50) fme_dataset char(50) las_vertical_coordsys_code number(6,0) fme_rotation number(31,15) las_gps_time_type number(1,0) fme_fill_color char(50) multi_reader_type char(50) multi_reader_id number(11,0) las_system_identifier char(32) multi_reader_keyword char(50) fme_geometry char(50) las_version char(3) multi_reader_full_id number(11,0) fme_text_string char(50) las_zlas_rearranged_points logical las_vertical_units_code number(6,0) las_type char(255) fme_text_size number(31,15) fme_start_angle number(31,15)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE="LISTBOX_ENCODED"
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FEATURE_TYPES=""
-#!   MAX_FEATURES=""
-#!   MAX_FEATURES_PER_FEATURE_TYPE=""
-#!   MIN_FEATURES=""
-#!   START_FEATURE=""
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="las file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="File1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="LAS File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the LAS file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the LAS file"
-#! />
-#! </DATASET>
-#! <DATASET
-#!   IS_SOURCE="true"
-#!   ROLE="READER"
-#!   FORMAT="GEOTIFF"
-#!   DATASET="$(SourceDataset_GEOTIFF)"
-#!   KEYWORD="GEOTIFF_1"
-#!   MULTI_GEOM_ALLOWED="false"
-#!   ATTR_MAX_LENGTH="0"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="true"
-#!   EXPOSABLE_ATTRS="geotiff_subdataset_name char(255) geotiff_tifftag_yresolution float fme_color char(50) geotiff_tifftag_imagedescription char(255) fme_sweep_angle float fme_basename char(50) geotiff_area_or_point char(255) multi_reader_keyword char(50) geotiff_photometric_interpretation char(10) geotiff_tifftag_datetime datetime fme_dataset char(50) multi_reader_type char(50) fme_text_string char(50) geotiff_tifftag_xresolution float multi_reader_full_id integer fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_tifftag_documentname char(255) fme_start_angle float geotiff_tifftag_hostcomputer char(255) fme_feature_type char(50) geotiff_type char(255) geotiff_tifftag_software char(255) geotiff_private_keys{}.type char(6) geotiff_tifftag_maxsamplevalue integer geotiff_tifftag_copyright char(255) geotiff_tifftag_minsamplevalue integer fme_geometry char(50) multi_reader_id integer fme_type char(50) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_private_keys{}.id integer geotiff_number_of_bits_per_cell decimal(1,0) geotiff_tifftag_artist char(255) fme_secondary_axis float geotiff_subdataset_description char(255) fme_rotation float geotiff_pyramid_level{}.num_rows integer geotiff_pyramid_num_levels integer fme_text_size float fme_primary_axis float geotiff_compression_method char(9) geotiff_pyramid_level{}.num_columns integer geotiff_private_keys{}.value char(255) geotiff_byte_order char(7)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE="LISTBOX_ENCODED"
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FEATURE_TYPES=""
-#!   MAX_FEATURES=""
-#!   MAX_FEATURES_PER_FEATURE_TYPE=""
-#!   MIN_FEATURES=""
-#!   START_FEATURE=""
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="tif file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="Raster1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="Raster File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="MIME_TYPE"
-#!   VALUE="image/TIFF"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the GeoTIFF file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the GeoTIFF file"
-#! />
-#! </DATASET>
-#! <DATASET
-#!   IS_SOURCE="false"
-#!   ROLE="WRITER"
-#!   FORMAT="LAS"
-#!   DATASET="$(DestDataset_LAS)"
-#!   KEYWORD="LAS_2"
-#!   MULTI_GEOM_ALLOWED="true"
-#!   ATTR_MAX_LENGTH="60"
-#!   ATTR_CASE="ANY"
-#!   ALLOWED_FEAT_TYPES=""
-#!   WRITE_DEFS="true"
-#!   DEFLINE_TEMPLATE=""
-#!   DEFLINE_ATTRS="false"
-#!   EXPOSABLE_ATTRS="fme_secondary_axis number(31,15) las_file_creation_date date las_project_id char(36) las_synthetic_returns logical las_generating_software char(32) fme_sweep_angle number(31,15) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_basename char(50) fme_feature_type char(50) las_file_source_id number(6,0) fme_color char(50) fme_type char(50) las_vertical_coordsys_code number(6,0) fme_dataset char(50) fme_rotation number(31,15) las_gps_time_type number(1,0) fme_fill_color char(50) las_system_identifier char(32) fme_geometry char(50) fme_text_string char(50) las_zlas_rearranged_points logical las_vertical_units_code number(6,0) las_type char(255) fme_text_size number(31,15) fme_start_angle number(31,15)"
-#!   DEFLINE_PARMS=""
-#!   ATTR_INDEX_TYPES=""
-#!   ATTR_NAME_INVALID_CHARS=""
-#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
-#!   ENABLED="true"
-#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
-#!   DATASET_TYPE="FILEDIR"
-#!   FTTR_TYPE=""
-#!   GENERATE_FME_BUILD_NUM="20596"
-#!   COORDSYS=""
-#!   FANOUT_EXPRESSION=""
-#!   FANOUT_GROUP="NO"
-#! >
-#! <METAFILE_PARAMETER
-#!   NAME="ADVANCED_PARMS"
-#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="AUTO_FANOUT_ATTRIBUTE"
-#!   VALUE="fme_basename"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="DATASET_NAME"
-#!   VALUE="las file"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
-#!   VALUE="File1"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="FEATURE_TYPE_NAME"
-#!   VALUE="LAS File"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_AUTO_EXPOSE"
-#!   VALUE="fme_basename char(50)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="READER_DATASET_HINT"
-#!   VALUE="Select the LAS file(s)"
-#! />
-#! <METAFILE_PARAMETER
-#!   NAME="WRITER_DATASET_HINT"
-#!   VALUE="Specify a folder for the LAS file"
-#! />
-#! </DATASET>
-#! </DATASETS>
-#! <DATA_TYPES>
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(20)"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(12)"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(31,15)"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(15,7)"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="number(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="datetime"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="time"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="decimal(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="float"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="float"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="integer"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="largeint"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="decimal(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="largeint"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="integer"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="smallint"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varchar(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_varbinary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_char(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(width)"
-#!   FME_TYPE="fme_binary(width)"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_buffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_binarybuffer"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_xml"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(254)"
-#!   FME_TYPE="fme_json"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(20)"
-#!   FME_TYPE="fme_datetime"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="char(12)"
-#!   FME_TYPE="fme_time"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="date"
-#!   FME_TYPE="fme_date"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(31,15)"
-#!   FME_TYPE="fme_real64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(15,7)"
-#!   FME_TYPE="fme_real32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_int32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(11,0)"
-#!   FME_TYPE="fme_uint32"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_int64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(20,0)"
-#!   FME_TYPE="fme_uint64"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="logical"
-#!   FME_TYPE="fme_boolean"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_int16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(6,0)"
-#!   FME_TYPE="fme_uint16"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_int8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(4,0)"
-#!   FME_TYPE="fme_uint8"
-#!   FORMAT="LAS"
-#! />
-#! <DATA_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="number(width,decimal)"
-#!   FME_TYPE="fme_decimal(width,decimal)"
-#!   FORMAT="LAS"
-#! />
-#! </DATA_TYPES>
-#! <GEOM_TYPES>
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="las_point_cloud"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_raster"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="true"
-#!   FORMAT_TYPE="geotiff_none"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="GEOTIFF"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="las_point_cloud"
-#!   FME_TYPE="fme_point_cloud"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_point"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_text"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_line"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_arc"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_area"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_ellipse"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_rounded_rectangle"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_no_geom"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_raster"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_solid"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_surface"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_feature_table"
-#!   FORMAT="LAS"
-#! />
-#! <GEOM_TYPE
-#!   IS_SOURCE="false"
-#!   FORMAT_TYPE="fme_no_map"
-#!   FME_TYPE="fme_collection"
-#!   FORMAT="LAS"
-#! />
-#! </GEOM_TYPES>
-#! <FEATURE_TYPES>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="true"
-#!   NODE_NAME="LAS"
-#!   FEATURE_TYPE_NAME=""
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="false"
-#!   IDENTIFIER="2"
-#!   FEAT_GEOMTYPE="las_point_cloud"
-#!   POSITION="-1076.8859688596885 -231.8749687496875"
-#!   BOUNDING_RECT="-1076.8859688596885 -231.8749687496875 454 71"
-#!   ORDER="500000000000000"
-#!   COLLAPSED="true"
-#!   KEYWORD="LAS_1"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   HIDDEN_USER_ATTRS=""
-#!   MERGE_FILTER=""
-#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
-#!   MERGE_FILTER_CASE_SENSITIVE="true"
-#!   DYNAMIC_SCHEMA="false"
-#! >
-#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
-#! </FEATURE_TYPE>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="true"
-#!   NODE_NAME="GEOTIFF"
-#!   FEATURE_TYPE_NAME=""
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="false"
-#!   IDENTIFIER="3"
-#!   FEAT_GEOMTYPE="geotiff_raster"
-#!   POSITION="599.57896652137288 -1000.3837188371879"
-#!   BOUNDING_RECT="599.57896652137288 -1000.3837188371879 454 71"
-#!   ORDER="500000000000000"
-#!   COLLAPSED="true"
-#!   KEYWORD="GEOTIFF_1"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   HIDDEN_USER_ATTRS=""
-#!   MERGE_FILTER=""
-#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
-#!   MERGE_FILTER_CASE_SENSITIVE="false"
-#!   DYNAMIC_SCHEMA="false"
-#! >
-#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
-#! </FEATURE_TYPE>
-#! <FEATURE_TYPE
-#!   IS_SOURCE="false"
-#!   NODE_NAME="LAS01"
-#!   FEATURE_TYPE_NAME="@Value(fme_basename)_CLEAN"
-#!   FEATURE_TYPE_NAME_QUALIFIER=""
-#!   IS_EDITABLE="true"
-#!   IDENTIFIER="67"
-#!   FEAT_GEOMTYPE="All"
-#!   POSITION="7167.8157641634389 -2678.0814285993265"
-#!   BOUNDING_RECT="7167.8157641634389 -2678.0814285993265 454 71"
-#!   ORDER="500000000000018"
-#!   COLLAPSED="true"
-#!   KEYWORD="LAS_2"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   SCHEMA_ATTRIBUTE_SOURCE="1"
-#! >
-#! </FEATURE_TYPE>
-#! </FEATURE_TYPES>
-#! <FMESERVER>
-#! <READER_DATASETS>
-#! <DATASET
-#!   NAME="LAS_1"
-#!   OVERRIDE="-LAS_1_DATASET"
-#!   DATASET="LAS_1/GT_Bel_Air_Buf20.las"
-#! />
-#! <DATASET
-#!   NAME="GEOTIFF_1"
-#!   OVERRIDE="-GEOTIFF_1_DATASET"
-#!   DATASET="GEOTIFF_1/Murs_THOCHB_Buff05_rast.tif"
-#! />
-#! </READER_DATASETS>
-#! <WRITER_DATASETS>
-#! <DATASET
-#!   NAME="LAS_2"
-#!   OVERRIDE="-LAS_2_DATASET"
-#!   DATASET="LAS_2/Test_cleaning_1"
-#! />
-#! </WRITER_DATASETS>
-#! </FMESERVER>
-#! <GLOBAL_PARAMETERS>
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las"
-#!   IS_STAND_ALONE="false"
-#! />
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
-#!   IS_STAND_ALONE="false"
-#! />
-#! <GLOBAL_PARAMETER
-#!   GUI_LINE="GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:"
-#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1"
-#!   IS_STAND_ALONE="false"
-#! />
-#! </GLOBAL_PARAMETERS>
-#! <COMMENTS>
-#! <COMMENT
-#!   IDENTIFIER="70"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 3&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="6012.7543942690818 -911.69959378330645"
-#!   TOP_LEFT="6012.7543942690818 -911.69959378330645"
-#!   BOTTOM_RIGHT="6710.4433795881969 -1010.4502812901815"
-#!   BOUNDING_RECT="6012.7543942690818 -911.69959378330645 697.68898531911509 98.750687506875067"
-#!   ORDER="500000000000035"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="69"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="64"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Extraction of vegetation points (4-5) for cleaning and ground + water points (2,9) to produce the Digital Elevation model (DEM) and then the Digital Canopy Height Model (DCHM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="-1036.5957318109765 310.21526678681414"
-#!   TOP_LEFT="-1036.5957318109765 310.21526678681414"
-#!   BOTTOM_RIGHT="19.227255153649139 123.96370427118899"
-#!   BOUNDING_RECT="-1036.5957318109765 310.21526678681414 1055.8229869646257 186.25156251562515"
-#!   ORDER="500000000000037"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="4"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="65"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Production of Digital Elevation Model (DEM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="415.26683382775855 454.51432789690216"
-#!   TOP_LEFT="415.26683382775855 454.51432789690216"
-#!   BOTTOM_RIGHT="1303.3666922035072 355.76364039002709"
-#!   BOUNDING_RECT="415.26683382775855 454.51432789690216 888.09985837574857 98.750687506875067"
-#!   ORDER="500000000000038"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="19"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="72"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt; with 50cm buffer and rasterized (pixel value = 3.5)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="536.1557398713943 -871.88371883718787"
-#!   TOP_LEFT="536.1557398713943 -871.88371883718787"
-#!   BOTTOM_RIGHT="1498.9226262636623 -970.63440634406288"
-#!   BOUNDING_RECT="536.1557398713943 -871.88371883718787 962.76688639226802 98.750687506875067"
-#!   ORDER="500000000000027"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="0.63529411764705879,0.80000000000000004,0.59999999999999998,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="0"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="73"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Addition of new components for wall and height informations&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="86.16072564766057 -592.54385422642099"
-#!   TOP_LEFT="86.16072564766057 -592.54385422642099"
-#!   BOTTOM_RIGHT="978.54513898674338 -735.0449792376711"
-#!   BOUNDING_RECT="86.16072564766057 -592.54385422642099 892.38441333908281 142.50112501125011"
-#!   ORDER="500000000000040"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="5"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="74"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets the the altitude of the ground under the point&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="1246.7063076427874 108.51432789690219"
-#!   TOP_LEFT="1246.7063076427874 108.51432789690219"
-#!   BOTTOM_RIGHT="2018.7063076427874 107.51432789690219"
-#!   BOUNDING_RECT="1246.7063076427874 108.51432789690219 772 1"
-#!   ORDER="500000000000041"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="21"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="75"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Calculation of the height of the point&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="1791.5119433664809 -50.001750017500171"
-#!   TOP_LEFT="1791.5119433664809 -50.001750017500171"
-#!   BOTTOM_RIGHT="2544.2173613655327 -148.75243752437524"
-#!   BOUNDING_RECT="1791.5119433664809 -50.001750017500171 752.70541799905186 98.750687506875067"
-#!   ORDER="500000000000042"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="24"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="59"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out abberrant or negative points&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="2640.1870626176733 -100.02162569693064"
-#!   TOP_LEFT="2640.1870626176733 -100.02162569693064"
-#!   BOTTOM_RIGHT="3447.0394481112248 -198.77231320380571"
-#!   BOUNDING_RECT="2640.1870626176733 -100.02162569693064 806.85238549355154 98.750687506875067"
-#!   ORDER="500000000000043"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="26"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="60"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Production of the Digital Canopy Height Model (DCHM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="3170.9913058726552 -227.50287502875028"
-#!   TOP_LEFT="3170.9913058726552 -227.50287502875028"
-#!   BOTTOM_RIGHT="3980.4690976202687 -370.00400004000039"
-#!   BOUNDING_RECT="3170.9913058726552 -227.50287502875028 809.47779174761354 142.50112501125011"
-#!   ORDER="500000000000045"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="28"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="61"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;mur&amp;quot; to indicate if the point is situated above a wall (3) or not (0)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="1432.8800495879839 -1295.1268698771116"
-#!   TOP_LEFT="1432.8800495879839 -1295.1268698771116"
-#!   BOTTOM_RIGHT="2162.8800495879841 -1296.1268698771116"
-#!   BOUNDING_RECT="1432.8800495879839 -1295.1268698771116 730 1"
-#!   ORDER="500000000000046"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="7"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="62"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;z_max&amp;quot; corresponding to the height of the highest point of vegetaion above a point of class 4. It indicates if the points is situated under higher vegetation or not.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="3502.2194882143003 -719.44352404689062"
-#!   TOP_LEFT="3502.2194882143003 -719.44352404689062"
-#!   BOTTOM_RIGHT="4878.6895635946648 -905.69508656251583"
-#!   BOUNDING_RECT="3502.2194882143003 -719.44352404689062 1376.4700753803645 186.25156251562515"
-#!   ORDER="500000000000047"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="34"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="76"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out all points of class 4 that are NOT under higher vegetation (z-max &amp;lt;=3). &lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="3942.8650513689618 -959.38459384593807"
-#!   TOP_LEFT="3942.8650513689618 -959.38459384593807"
-#!   BOTTOM_RIGHT="4769.465170379859 -1101.8857188571883"
-#!   BOUNDING_RECT="3942.8650513689618 -959.38459384593807 826.60011901089729 142.50112501125011"
-#!   ORDER="500000000000048"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="37"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="78"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out points of class 4 that are situated above a wall&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="4574.0705446717948 -1693.4785721845751"
-#!   TOP_LEFT="4574.0705446717948 -1693.4785721845751"
-#!   BOTTOM_RIGHT="5289.8729070785848 -1835.9796971958253"
-#!   BOUNDING_RECT="4574.0705446717948 -1693.4785721845751 715.80236240679005 142.50112501125011"
-#!   ORDER="500000000000049"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="38"
-#! />
-#! <COMMENT
-#!   IDENTIFIER="80"
-#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Recombination of all points  for writing&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
-#!   POSITION="6395.5222988431415 -2447.3528510634337"
-#!   TOP_LEFT="6395.5222988431415 -2447.3528510634337"
-#!   BOTTOM_RIGHT="7145.095722801887 -2546.103538570309"
-#!   BOUNDING_RECT="6395.5222988431415 -2447.3528510634337 749.57342395874548 98.750687506875067"
-#!   ORDER="500000000000050"
-#!   FOLLOW_ANCHOR="true"
-#!   INFO_NODE="false"
-#!   CUSTOM_USER_COLOR="false"
-#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
-#!   SIZE_POLICY="10"
-#!   ANCHORED_NODE="41"
-#! />
-#! </COMMENTS>
-#! <CONSTANTS>
-#! </CONSTANTS>
-#! <BOOKMARKS>
-#! <BOOKMARK
-#!   IDENTIFIER="63"
-#!   NAME="LAS file"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="-1168.8859688596885 -103.3749687496875"
-#!   ORDER="500000000000036"
-#!   PALETTE_COLOR="Color1"
-#!   BOTTOM_RIGHT="-534.88596885968855 -356.37496874968747"
-#!   BOUNDING_RECT="-1168.8859688596885 -103.3749687496875 634 253"
-#!   STICKY="true"
-#!   COLOUR="0.59999999999999998,0.80000000000000004,0.80000000000000004,1"
-#!   CONTENTS="2 "
-#! >
-#! </BOOKMARK>
-#! <BOOKMARK
-#!   IDENTIFIER="66"
-#!   NAME="Cadastre of walls"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="507.57896652137288 -762.20274397865921"
-#!   ORDER="500000000000039"
-#!   PALETTE_COLOR="Color2"
-#!   BOTTOM_RIGHT="1535.8385291169984 -1124.8837188371879"
-#!   BOUNDING_RECT="507.57896652137288 -762.20274397865921 1028.2595625956255 362.68097485852866"
-#!   STICKY="true"
-#!   COLOUR="0.63529411764705879,0.80000000000000004,0.59999999999999998,1"
-#!   CONTENTS="3 72 "
-#! >
-#! </BOOKMARK>
-#! <BOOKMARK
-#!   IDENTIFIER="81"
-#!   NAME="New LAS file cleaned"
-#!   DESCRIPTION=""
-#!   TOP_LEFT="7079.8157641634389 -2549.5814285993265"
-#!   ORDER="500000000000051"
-#!   PALETTE_COLOR="Color4"
-#!   BOTTOM_RIGHT="7713.8157641634389 -2802.5814285993265"
-#!   BOUNDING_RECT="7079.8157641634389 -2549.5814285993265 634 253"
-#!   STICKY="true"
-#!   COLOUR="0.85098039215686272,0.92941176470588238,0.60392156862745094,1"
-#!   CONTENTS="67 "
-#! >
-#! </BOOKMARK>
-#! </BOOKMARKS>
-#! <TRANSFORMERS>
-#! <TRANSFORMER
-#!   IDENTIFIER="4"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="-434.37934379343807 -227.50287502875031"
-#!   BOUNDING_RECT="-434.37934379343807 -227.50287502875031 454 71"
-#!   ORDER="500000000000001"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="Ground&lt;space&gt;&lt;openparen&gt;2&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;Water&lt;space&gt;&lt;openparen&gt;9&lt;closeparen&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="3"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==2&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==9 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Ground&lt;space&gt;&lt;openparen&gt;2&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;Water&lt;space&gt;&lt;openparen&gt;9&lt;closeparen&gt; ; V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="5"
-#!   TYPE="PointCloudComponentAdder"
-#!   VERSION="1"
-#!   POSITION="345.12253122531229 -347.50287502875028"
-#!   BOUNDING_RECT="345.12253122531229 -347.50287502875028 580.00106825772946 71"
-#!   ORDER="500000000000002"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD" PARM_VALUE="z_ground,Real64,0,z_max,Real64,0,mur,Real64,0"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudComponentAdder"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="7"
-#!   TYPE="PointCloudOnRasterComponentSetter"
-#!   VERSION="3"
-#!   POSITION="1660.2623126231272 -871.88371883718787"
-#!   BOUNDING_RECT="1660.2623126231272 -871.88371883718787 430 71"
-#!   ORDER="500000000000003"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="PointCloud"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|mur|$(SourceDataset_GEOTIFF)"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
-#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="19"
-#!   TYPE="RasterDEMGenerator"
-#!   VERSION="5"
-#!   POSITION="415.26683382775855 277.01320288565205"
-#!   BOUNDING_RECT="415.26683382775855 277.01320288565205 455.00106825772946 71"
-#!   ORDER="500000000000007"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="DEM_RASTER"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION_TYPE" PARM_VALUE="AUTO"/>
-#!     <XFORM_PARM PARM_NAME="NODATA_VALUE" PARM_VALUE="-32767.0"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TOLERANCE" PARM_VALUE="0.1"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="RasterDEMGenerator"/>
-#!     <XFORM_PARM PARM_NAME="X_SPACING" PARM_VALUE="0.4"/>
-#!     <XFORM_PARM PARM_NAME="Y_SPACING" PARM_VALUE="0.4"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="21"
-#!   TYPE="PointCloudOnRasterComponentSetter"
-#!   VERSION="3"
-#!   POSITION="1246.7063076427874 -68.986797114347922"
-#!   BOUNDING_RECT="1246.7063076427874 -68.986797114347922 430 71"
-#!   ORDER="500000000000008"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="PointCloud"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|z_ground|0"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
-#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_2"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="24"
-#!   TYPE="PointCloudExpressionEvaluator"
-#!   VERSION="3"
-#!   POSITION="1829.5119433664809 -227.50287502875028"
-#!   BOUNDING_RECT="1829.5119433664809 -227.50287502875028 430 71"
-#!   ORDER="500000000000009"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="RESULT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="z Real32 &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;-&lt;at&gt;Component&lt;openparen&gt;z_ground&lt;closeparen&gt;"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="26"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="2365.648656486565 -281.25281252812522"
-#!   BOUNDING_RECT="2365.648656486565 -281.25281252812522 454 71"
-#!   ORDER="500000000000010"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="Negative&lt;space&gt;points"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="Aberrant&lt;space&gt;height&lt;space&gt;points&lt;space&gt;&lt;openparen&gt;higher&lt;space&gt;than&lt;space&gt;50m&lt;closeparen&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="3"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;&lt;lt&gt;0 ; &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;&lt;gt&gt;50 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Negative&lt;space&gt;points ; Aberrant&lt;space&gt;height&lt;space&gt;points&lt;space&gt;&lt;openparen&gt;higher&lt;space&gt;than&lt;space&gt;50m&lt;closeparen&gt;"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_3"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="28"
-#!   TYPE="RasterDEMGenerator"
-#!   VERSION="5"
-#!   POSITION="2950.0295002950033 -403.12903129031281"
-#!   BOUNDING_RECT="2950.0295002950033 -403.12903129031281 497.00106825772946 71"
-#!   ORDER="500000000000011"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="DEM_RASTER"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION_TYPE" PARM_VALUE="AUTO"/>
-#!     <XFORM_PARM PARM_NAME="NODATA_VALUE" PARM_VALUE="-32767.0"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TOLERANCE" PARM_VALUE="0.1"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="RasterDEMGenerator_2"/>
-#!     <XFORM_PARM PARM_NAME="X_SPACING" PARM_VALUE="0.4"/>
-#!     <XFORM_PARM PARM_NAME="Y_SPACING" PARM_VALUE="0.4"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="31"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="2212.5221252212523 -1069.3850938509395"
-#!   BOUNDING_RECT="2212.5221252212523 -1069.3850938509395 454 71"
-#!   ORDER="500000000000012"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="5"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="3"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4 ; 5"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_4"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="34"
-#!   TYPE="PointCloudOnRasterComponentSetter"
-#!   VERSION="3"
-#!   POSITION="2950.0295002950033 -959.38459384593807"
-#!   BOUNDING_RECT="2950.0295002950033 -959.38459384593807 785.00106825772946 71"
-#!   ORDER="500000000000013"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="PointCloud"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|z_max|0"/>
-#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
-#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_3"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="37"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="3862.5386253862539 -1129.3850938509395"
-#!   BOUNDING_RECT="3862.5386253862539 -1129.3850938509395 454 71"
-#!   ORDER="500000000000014"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4&lt;space&gt;out"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;z_max&lt;closeparen&gt;&lt;lt&gt;=3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;out"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_5"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="38"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="4574.0705446717948 -1301.8599283282338"
-#!   BOUNDING_RECT="4574.0705446717948 -1301.8599283282338 454 71"
-#!   ORDER="500000000000014"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_6"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="41"
-#!   TYPE="PointCloudCombiner"
-#!   VERSION="6"
-#!   POSITION="6427.4542769978752 -2612.7179323841506"
-#!   BOUNDING_RECT="6427.4542769978752 -2612.7179323841506 454 71"
-#!   ORDER="500000000000015"
-#!   PARMS_EDITED="false"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="52"
-#!   TYPE="PointCloudFilter"
-#!   VERSION="2"
-#!   POSITION="4574.0705446717948 -100.02162569693064"
-#!   BOUNDING_RECT="4574.0705446717948 -100.02162569693064 454 71"
-#!   ORDER="500000000000014"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="4&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="2"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
-#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;-&lt;space&gt;mur"/>
-#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_7"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="53"
-#!   TYPE="Inspector"
-#!   VERSION="5"
-#!   POSITION="5255.1809418109106 -168.75157360247033"
-#!   BOUNDING_RECT="5255.1809418109106 -168.75157360247033 430 71"
-#!   ORDER="500000000000016"
-#!   PARMS_EDITED="false"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <XFORM_PARM PARM_NAME="AREA_COLOR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="PEN_COLOR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="POINTCLOUD_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_NUM_COLS" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="RASTER_NUM_ROWS" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="RASTER_START_COL" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="RASTER_START_ROW" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="RASTER_VISUALIZATION_OPTION" PARM_VALUE="No Reduction"/>
-#!     <XFORM_PARM PARM_NAME="TACKATTRS" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="THINNER_INTERVAL" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="THINNER_MAX_NUM_POINTS" PARM_VALUE="&lt;Unused&gt;"/>
-#!     <XFORM_PARM PARM_NAME="THINNER_TYPE_DISPLAY" PARM_VALUE="No Thinning"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="VECTOR_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="4-mur_2"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="56"
-#!   TYPE="PointCloudCombiner"
-#!   VERSION="6"
-#!   POSITION="5227.186316457115 -1015.776028676891"
-#!   BOUNDING_RECT="5227.186316457115 -1015.776028676891 485.00106825772946 71"
-#!   ORDER="500000000000019"
-#!   PARMS_EDITED="false"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="OUTPUT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
-#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner_2"/>
-#! </TRANSFORMER>
-#! <TRANSFORMER
-#!   IDENTIFIER="69"
-#!   TYPE="PointCloudExpressionEvaluator"
-#!   VERSION="3"
-#!   POSITION="5874.5558237727373 -1062.0727879407798"
-#!   BOUNDING_RECT="5874.5558237727373 -1062.0727879407798 669.00106825772946 71"
-#!   ORDER="500000000000019"
-#!   PARMS_EDITED="true"
-#!   ENABLED="true"
-#!   LAST_PARM_EDIT="20596"
-#! >
-#!     <OUTPUT_FEAT NAME="RESULT"/>
-#!     <FEAT_COLLAPSED COLLAPSED="0"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
-#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
-#!     <FEAT_COLLAPSED COLLAPSED="1"/>
-#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
-#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 3"/>
-#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
-#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_2"/>
-#! </TRANSFORMER>
-#! </TRANSFORMERS>
-#! <FEAT_LINKS>
-#! <FEAT_LINK
-#!   IDENTIFIER="8"
-#!   SOURCE_NODE="2"
-#!   TARGET_NODE="4"
-#!   SOURCE_PORT_DESC="-1"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="9"
-#!   SOURCE_NODE="3"
-#!   TARGET_NODE="7"
-#!   SOURCE_PORT_DESC="-1"
-#!   TARGET_PORT_DESC="fi 1 Raster"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="20"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="19"
-#!   SOURCE_PORT_DESC="fo 0 Ground&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;2&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;Water&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;9&lt;lt&gt;closeparen&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 POINTS&lt;solidus&gt;LINES"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="44"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 0 Ground&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;2&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;Water&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;9&lt;lt&gt;closeparen&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="1"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="22"
-#!   SOURCE_NODE="5"
-#!   TARGET_NODE="21"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="fi 0 PointCloud"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="32"
-#!   SOURCE_NODE="7"
-#!   TARGET_NODE="31"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="23"
-#!   SOURCE_NODE="19"
-#!   TARGET_NODE="21"
-#!   SOURCE_PORT_DESC="fo 0 DEM_RASTER"
-#!   TARGET_PORT_DESC="fi 1 Raster"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="25"
-#!   SOURCE_NODE="21"
-#!   TARGET_NODE="24"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="30"
-#!   SOURCE_NODE="21"
-#!   TARGET_NODE="7"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 PointCloud"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="1"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="27"
-#!   SOURCE_NODE="24"
-#!   TARGET_NODE="26"
-#!   SOURCE_PORT_DESC="fo 0 RESULT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="36"
-#!   SOURCE_NODE="28"
-#!   TARGET_NODE="34"
-#!   SOURCE_PORT_DESC="fo 0 DEM_RASTER"
-#!   TARGET_PORT_DESC="fi 1 Raster"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="35"
-#!   SOURCE_NODE="31"
-#!   TARGET_NODE="34"
-#!   SOURCE_PORT_DESC="fo 0 4"
-#!   TARGET_PORT_DESC="fi 0 PointCloud"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="39"
-#!   SOURCE_NODE="34"
-#!   TARGET_NODE="37"
-#!   SOURCE_PORT_DESC="fo 0 PointCloud"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="54"
-#!   SOURCE_NODE="37"
-#!   TARGET_NODE="52"
-#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;out"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="57"
-#!   SOURCE_NODE="37"
-#!   TARGET_NODE="56"
-#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;out"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="1"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="58"
-#!   SOURCE_NODE="38"
-#!   TARGET_NODE="56"
-#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="68"
-#!   SOURCE_NODE="41"
-#!   TARGET_NODE="67"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="-1"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="55"
-#!   SOURCE_NODE="52"
-#!   TARGET_NODE="53"
-#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="71"
-#!   SOURCE_NODE="56"
-#!   TARGET_NODE="69"
-#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="51"
-#!   SOURCE_NODE="69"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 0 RESULT"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="18"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="5"
-#!   SOURCE_PORT_DESC="fo 1 V&lt;lt&gt;u00e9&lt;gt&gt;g&lt;lt&gt;u00e9&lt;gt&gt;tation&lt;lt&gt;space&lt;gt&gt;moyenne&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;4&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;haute&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;5&lt;lt&gt;closeparen&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="77"
-#!   SOURCE_NODE="31"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 1 5"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="79"
-#!   SOURCE_NODE="37"
-#!   TARGET_NODE="38"
-#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="42"
-#!   SOURCE_NODE="38"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="45"
-#!   SOURCE_NODE="4"
-#!   TARGET_NODE="41"
-#!   SOURCE_PORT_DESC="fo 2 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 "
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! <FEAT_LINK
-#!   IDENTIFIER="29"
-#!   SOURCE_NODE="26"
-#!   TARGET_NODE="28"
-#!   SOURCE_PORT_DESC="fo 2 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
-#!   TARGET_PORT_DESC="fi 0 POINTS&lt;solidus&gt;LINES"
-#!   ENABLED="true"
-#!   EXECUTION_IDX="0"
-#!   HIDDEN="false"
-#!   COLOUR="0,0,0,1"
-#!   PEN_WIDTH="4"
-#!   PEN_STYLE="1"
-#!   LINK_STYLE_NAME="&lt;Default&gt;"
-#!   EXTRA_POINTS=""
-#! />
-#! </FEAT_LINKS>
-#! <BREAKPOINTS>
-#! </BREAKPOINTS>
-#! <ATTR_LINKS>
-#! </ATTR_LINKS>
-#! <SUBDOCUMENTS>
-#! </SUBDOCUMENTS>
-#! <LOOKUP_TABLES>
-#! </LOOKUP_TABLES>
-#! </WORKSPACE>
-
-FME_PYTHON_VERSION 37
-GUI IGNORE SourceDataset_LAS_1,LAS_IN_USE_SEARCH_ENVELOPE_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1,LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1,LAS_IN_CLIP_TO_ENVELOPE_LAS_1,LAS_IN_NETWORK_AUTHENTICATION_LAS_1,SourceDataset_GEOTIFF_1,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1,DestDataset_LAS_2,LAS_OUT_FME_GROUP_NAMED1_LAS_2,LAS_OUT_VERSION_LAS_2,LAS_OUT_COMPRESSION_LAS_2,LAS_OUT_USER_GROUP_LAS_2,LAS_OUT_USER_COMPONENTS_LAS_2,LAS_OUT_ADVANCED_PARAMETERS_LAS_2,LAS_OUT_LAS_DATASET_FILE_LAS_2,LAS_OUT_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_ZLAS_PARAMETERS_LAS_2,LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2
-DEFAULT_MACRO SourceDataset_LAS G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las
-GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):
-DEFAULT_MACRO SourceDataset_GEOTIFF G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif
-GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
-DEFAULT_MACRO DestDataset_LAS G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1
-GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:
-INCLUDE [ if {{$(SourceDataset_LAS)} == {}} { puts_real {Parameter 'SourceDataset_LAS' must be given a value.}; exit 1; }; ]
-INCLUDE [ if {{$(SourceDataset_GEOTIFF)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF' must be given a value.}; exit 1; }; ]
-INCLUDE [ if {{$(DestDataset_LAS)} == {}} { puts_real {Parameter 'DestDataset_LAS' must be given a value.}; exit 1; }; ]
-#! START_HEADER
-#! START_WB_HEADER
-READER_TYPE MULTI_READER
-MULTI_READER_TYPE{0} LAS
-MULTI_READER_KEYWORD{0} LAS_1
-MULTI_READER_GEN_DIRECTIVES{0} USE_SEARCH_ENVELOPE,NO,CLIP_TO_ENVELOPE,NO,READER_META_ATTRIBUTES,fme_dataset,GROUP_BY_DATASET,No,_MERGE_SCHEMAS,YES,SEARCH_ENVELOPE_MAXX,0,SEARCH_ENVELOPE_MAXY,0,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MINY,0,LAS_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0
-MULTI_READER_TYPE{1} GEOTIFF
-MULTI_READER_KEYWORD{1} GEOTIFF_1
-MULTI_READER_GEN_DIRECTIVES{1} APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MAXY,0,USE_SEARCH_ENVELOPE,NO,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXX,0,IGNORE_RASTER_TYPE_KEY,No,FEATURE_TYPE_NAME,FORMAT_NAME,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PYRAMID_LEVEL,,GEOTIFF_RDR_ADV_PARM_GROUP,,PREFER_FILE_CS_UNITS,Yes,READ_OFFSETS_IN_CS_UNITS,No,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,CLIP_TO_ENVELOPE,NO
-WRITER_TYPE MULTI_WRITER
-MULTI_WRITER_DATASET_ORDER BY_ID
-MULTI_WRITER_FIRST_WRITER_ID 0
-MULTI_WRITER_TYPE{0} LAS
-MULTI_WRITER_KEYWORD{0} LAS_2
-#! END_WB_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "LAS_1"
-#! END_WB_HEADER
-#! START_SOURCE_HEADER LAS LAS_1
-# =======================================================================
-# The following GUI line prompts for a file to be used as the source LAS file.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be read.
-# The dataset this mapping file was generated from was:
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO SourceDataset
-INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
- puts {DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset)}     \
- } ]
-#! END_WB_HEADER
-#! START_SOURCE_HEADER LAS LAS_1
-DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset_LAS)
-GUI MULTIFILE SourceDataset_LAS_1 LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|All_files(*)|* Source ASPRS LAS File(s):
-DEFAULT_MACRO LAS_IN_READER_META_ATTRIBUTES_LAS_1 fme_dataset
-LAS_1_READER_META_ATTRIBUTES "$(LAS_IN_READER_META_ATTRIBUTES_LAS_1)"
-DEFAULT_MACRO LAS_IN_GROUP_BY_DATASET_LAS_1 No
-LAS_1_GROUP_BY_DATASET "$(LAS_IN_GROUP_BY_DATASET_LAS_1)"
-DEFAULT_MACRO LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1 
-LAS_1_EXPOSE_ATTRS_GROUP "$(LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1)"
-# Include this file in source setting section to add external search envelope processing
-# Zero as a default means we don't do any search -- this makes workbench happier
-DEFAULT_MACRO LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 NO
-LAS_1_USE_SEARCH_ENVELOPE "$(LAS_IN_USE_SEARCH_ENVELOPE_LAS_1)"
-GUI ACTIVEDISCLOSUREGROUP LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1%LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1%LAS_IN_CLIP_TO_ENVELOPE_LAS_1%LAS_IN_SEARCH_METHOD%LAS_IN_SEARCH_METHOD_FILTER%LAS_IN_SEARCH_ORDER%LAS_IN_SEARCH_FEATURE%LAS_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 Minimum X:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 Minimum Y:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 Maximum X:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 <Unused>,0 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 0
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1)"
-GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 Maximum Y:
-# ===========================================================================
-GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 <Unused>, 
-DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 
-LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1)"
-GUI OPTIONAL COORDSYS LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 Search Envelope Coordinate System:
-# ===========================================================================
-# BUG18999: We now have a soft clip to fall back on like native spatial index
-# thus we are reintroducing the clip to envelop as an option for users.
-# Defualt to soft clip as per the existing database readers we are emulating
-GUI LOOKUP LAS_IN_CLIP_TO_ENVELOPE_LAS_1 <Unused>,NO 
-DEFAULT_MACRO LAS_IN_CLIP_TO_ENVELOPE_LAS_1 NO
-LAS_1_CLIP_TO_ENVELOPE "$(LAS_IN_CLIP_TO_ENVELOPE_LAS_1)"
-GUI OPTIONAL CHECKBOX LAS_IN_CLIP_TO_ENVELOPE_LAS_1 YES%NO Clip to Search Envelope
-# ===========================================================================
-DEFAULT_MACRO LAS_IN_NETWORK_AUTHENTICATION_LAS_1 
-LAS_1_NETWORK_AUTHENTICATION "$(LAS_IN_NETWORK_AUTHENTICATION_LAS_1)"
-GUI OPTIONAL AUTHENTICATOR LAS_IN_NETWORK_AUTHENTICATION_LAS_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
-# ============================================================================ 
-DEFAULT_MACRO LAS_IN_ATTRIBUTE_READING_LAS_1 ALL
-LAS_1_ATTRIBUTE_READING "$(LAS_IN_ATTRIBUTE_READING_LAS_1)"
-# ============================================================================ 
-LAS_1_GENERATE_FME_BUILD_NUM 20596
-LAS_1_DATASET "$(SourceDataset_LAS_1)"
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "GEOTIFF_1"
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
-# =======================================================================
-# The following GUI line prompts for a file to be used as the source GEOTIFF file.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be read.
-# The dataset this mapping file was generated from was:
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO SourceDataset
-INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
- puts {DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset)}     \
- } ]
-#! END_WB_HEADER
-#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
-DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset_GEOTIFF)
-GUI MULTIFILE SourceDataset_GEOTIFF_1 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
-DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1 fme_dataset fme_basename
-GEOTIFF_1_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1)"
-DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1 FORMAT_NAME
-GEOTIFF_1_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1)"
-DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 NO
-GEOTIFF_1_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Apply GCP's
-DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 NearestNeighbor
-GEOTIFF_1_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1)"
-GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
-GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 <Unused>,NearestNeighbor 
-DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1 
-GEOTIFF_1_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1)"
-# Include this file in source setting section to add external search envelope processing
-# Zero as a default means we don't do any search -- this makes workbench happier
-DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 NO
-GEOTIFF_1_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1)"
-GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 Minimum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 Minimum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 Maximum X:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 <Unused>,0 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 0
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1)"
-GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 Maximum Y:
-# ===========================================================================
-GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 <Unused>, 
-DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 
-GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1)"
-GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 Search Envelope Coordinate System:
-# ===========================================================================
-# BUG18999: We now have a soft clip to fall back on like native spatial index
-# thus we are reintroducing the clip to envelop as an option for users.
-# Defualt to soft clip as per the existing database readers we are emulating
-GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 <Unused>,NO 
-DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 NO
-GEOTIFF_1_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1)"
-GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 YES%NO Clip to Search Envelope
-DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 
-GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Advanced
-DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 
-GEOTIFF_1_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1)"
-GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 Pyramid Level to Read:
-DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes
-GEOTIFF_1_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes%No Prefer File Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 No
-GEOTIFF_1_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 Yes%No Offsets in Coordinate System Units:
-DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 No
-GEOTIFF_1_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1)"
-GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Yes%No Ignore Raster Type Key:
-# ===========================================================================
-DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 
-GEOTIFF_1_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1)"
-GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
-# ============================================================================ 
-DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1 ALL
-GEOTIFF_1_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1)"
-# ============================================================================ 
-GEOTIFF_1_GENERATE_FME_BUILD_NUM 20596
-GEOTIFF_1_DATASET "$(SourceDataset_GEOTIFF_1)"
-#! END_SOURCE_HEADER
-#! START_WB_HEADER
-MACRO WB_KEYWORD "LAS_2"
-#! END_WB_HEADER
-#! START_DEST_HEADER LAS LAS_2
-# The following GUI lines prompt for a LAS file to be used as the
-# the destination of the data.
-# The user input is stored in a macro, which is then used to define
-# the dataset to be written.
-#! END_DEST_HEADER
-#! START_WB_HEADER
-DEFAULT_MACRO DestDataset
-INCLUDE [ if {"$(DestDataset)" != ""} {                          \
- puts {DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset)}         \
- } ]
-#! END_WB_HEADER
-#! START_DEST_HEADER LAS LAS_2
-DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset_LAS)
-GUI DIRNAME DestDataset_LAS_2 Destination ASPRS LAS Folder:
-DEFAULT_MACRO LAS_OUT_FME_GROUP_NAMED1_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_FME_GROUP_NAMED1_LAS_2 LAS_OUT_VERSION_LAS_2%LAS_OUT_COMPRESSION_LAS_2 Parameters
-# ============================================================================
-# Version
-DEFAULT_MACRO LAS_OUT_VERSION_LAS_2 1.2
-LAS_2_VERSION "$(LAS_OUT_VERSION_LAS_2)"
-GUI LOOKUP_CHOICE LAS_OUT_VERSION_LAS_2 1.0,1.0%1.1,1.1%1.2,1.2%1.3,1.3%"\"1.4 (Legacy Compatible)\",1.4-legacy-compatible"%1.4,1.4 ASPRS LAS Version:
-# [PR#30472] Compression
-DEFAULT_MACRO LAS_OUT_COMPRESSION_LAS_2 None
-LAS_2_COMPRESSION "$(LAS_OUT_COMPRESSION_LAS_2)"
-GUI ACTIVECHOICE LAS_OUT_COMPRESSION_LAS_2 None,LAS_OUT_ZLAS_PARAMETERS_LAS_2%LAZ,LAS_OUT_ZLAS_PARAMETERS_LAS_2%zLAS Compression
-# This is a placeholder parameter that will be replaced with a custom table in the controller
-DEFAULT_MACRO LAS_OUT_USER_GROUP_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_USER_GROUP_LAS_2 LAS_OUT_USER_COMPONENTS_LAS_2 Additional User Components
-DEFAULT_MACRO LAS_OUT_USER_COMPONENTS_LAS_2 
-LAS_2_USER_COMPONENTS "$(LAS_OUT_USER_COMPONENTS_LAS_2)"
-GUI OPTIONAL GUI_LINE_TABLE_ENCODED LAS_OUT_USER_COMPONENTS_LAS_2 NO_LABEL%ROW_DELIM:,%COL_DELIM:,%"User Components"%"STRING COMPONENTS" User Components
-# ============================================================================
-# Opt in for destination dataset type vs format type validation
-DEFAULT_MACRO LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2 Yes
-LAS_2_DESTINATION_DATASETTYPE_VALIDATION "$(LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2)"
-DEFAULT_MACRO LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2 FEATURE
-LAS_2_COORDINATE_SYSTEM_GRANULARITY "$(LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2)"
-DEFAULT_MACRO LAS_OUT_ADVANCED_PARAMETERS_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ADVANCED_PARAMETERS_LAS_2 LAS_OUT_LAS_DATASET_FILE_LAS_2%LAS_OUT_ZLAS_PARAMETERS_LAS_2 Advanced
-DEFAULT_MACRO LAS_OUT_LAS_DATASET_FILE_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_LAS_DATASET_FILE_LAS_2 LAS_OUT_ARCGIS_LAS_DATASET_LAS_2%LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 LAS Dataset File
-# The following GUI line provides the ability to create an
-# Esri ArcGIS LAS Dataset encapsulating the LAS files produced
-# by this translation. The LAS Dataset can then be used to view
-# the output using Esri's tools.
-DEFAULT_MACRO LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 
-LAS_2_ARCGIS_LAS_DATASET "$(LAS_OUT_ARCGIS_LAS_DATASET_LAS_2)"
-GUI OPTIONAL TEXT LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 ArcGIS LAS Dataset (.lasd) Filename
-# The following GUI line determines whether statistics should
-# be calculated on the ArcGIS LAS Dataset. This keyword is
-# applicable when FME is creating an ArcGIS LAS Dataset.
-DEFAULT_MACRO LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 No
-LAS_2_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET "$(LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2)"
-GUI CHOICE LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 Yes%No Compute Statistics on ArcGIS LAS Dataset
-DEFAULT_MACRO LAS_OUT_ZLAS_PARAMETERS_LAS_2 
-GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ZLAS_PARAMETERS_LAS_2 LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Parameters
-DEFAULT_MACRO LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 <Unused>
-LAS_2_ZLAS_REARRANGE_POINTS "$(LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2)"
-GUI CHOICE LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 Yes%No Rearrange Points for zLAS Compression
-DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 <Unused>
-LAS_2_ZLAS_POINT_SPACING_SOURCE "$(LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2)"
-GUI LOOKUP_CHOICE LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 "\"Scan Points\",scan"%"\"From Header\",header"%"\"Specify Value\",specify" zLAS Point Spacing Source
-DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 <Unused>
-LAS_2_ZLAS_POINT_SPACING_VALUE "$(LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2)"
-GUI FLOAT LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Point Spacing Value
-# ============================================================================ 
-LAS_2_GENERATE_FME_BUILD_NUM 20596
-LAS_2_DATASET "$(DestDataset_LAS_2)"
-#! END_DEST_HEADER
-#! START_WB_HEADER
-#! END_WB_HEADER
-#! END_HEADER
-
-LOG_FILTER_MASK -1
-LOG_MAX_FEATURES 200
-LOG_MAX_RECORDED_FEATURES 200
-FME_REPROJECTION_ENGINE FME
-FME_IMPLICIT_CSMAP_REPROJECTION_MODE Auto
-FME_GEOMETRY_HANDLING Enhanced
-FME_STROKE_MAX_DEVIATION 0
-DEFAULT_MACRO DATASET_KEYWORD_LAS_1 LAS_1
-DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_1 GEOTIFF_1
-DEFAULT_MACRO DATASET_KEYWORD_LAS_2 LAS_2
-# -------------------------------------------------------------------------
-
-LAS_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
-
-# -------------------------------------------------------------------------
-
-GEOTIFF_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
-
-# -------------------------------------------------------------------------
-
-MULTI_READER_CONTINUE_ON_READER_FAILURE No
-
-# -------------------------------------------------------------------------
-
-MACRO WORKSPACE_NAME LAS_Pretraitement_2021_cleaning_MNHC
-MACRO FME_VIEWER_APP fmedatainspector
-# -------------------------------------------------------------------------
-
-INCLUDE [ if {[info exists env(FME_TEMP)] && [file isdirectory $env(FME_TEMP)]} {set gVisualizerTemp $env(FME_TEMP)}  elseif {[info exists env(TEMP)] && [file isdirectory $env(TEMP)]}  {set gVisualizerTemp $env(TEMP)}  elseif { $tcl_platform(platform) == "unix" } {set gVisualizerTemp "/tmp"} else {set gVisualizerTemp c:};  regsub -all {[ ,&]} {$(WORKSPACE_NAME)} {_} wsname; set gVisualizerTemp $gVisualizerTemp/${wsname}_[clock format [clock seconds] -format %H%M%S];  puts "MACRO WORKSPACE_TEMP_DIR $gVisualizerTemp"; 
-MACRO VISUALIZER_FEATURE_FILE $(WORKSPACE_TEMP_DIR)/inspector.ffs
-MACRO VISUALIZER_SCHEMA_FILE $(WORKSPACE_TEMP_DIR)/inspector.fsc
-MACRO VISUALIZER_CREATE_SPATIAL_INDEX YES
-# -------------------------------------------------------------------------
-LAS_1_DEF LAS
-# -------------------------------------------------------------------------
-GEOTIFF_1_DEF GEOTIFF
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * RoutingFactory   FACTORY_NAME "Router and Unexpected Input Remover"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE LAS LAS_1::LAS multi_reader_keyword,$(DATASET_KEYWORD_LAS_1) TO FME_GENERIC ::LAS ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_1::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_1) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    MERGE_INPUT Yes   OUTPUT ROUTED FEATURE_TYPE *
-LAS_1_MERGE_DEF LAS_1::LAS EXACT LAS
-GEOTIFF_1_MERGE_DEF GEOTIFF_1::GEOTIFF EXACT GEOTIFF
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory    FACTORY_NAME "LAS_LAS_1 Splitter"    INPUT FEATURE_TYPE LAS    OUTPUT FEATURE_TYPE LAS_LAS_1
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_1 Splitter"    INPUT FEATURE_TYPE GEOTIFF    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_1
-DEFAULT_MACRO WB_CURRENT_CONTEXT
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter    INPUT  FEATURE_TYPE LAS_LAS_1    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==2<space>||<space><at>Component<openparen>classification<closeparen>==9 ; <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> ; V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_2
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> Splitter"   INPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>   OUTPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_0_iQyPhi3mnFo=   OUTPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_1_WXAwGkpiE4A=
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * TeeFactory    FACTORY_NAME PointCloudComponentAdder    INPUT  FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    OUTPUT FEATURE_TYPE ___TOREJECTOR___       @RenameAttributes(FME_STRICT,___fme_rejection_code___,fme_rejection_code)       @AddPointCloudComponents(REJECTABLE,z_ground,Real64,0,z_max,Real64,0,mur,Real64,0)
-FACTORY_DEF * TestFactory    FACTORY_NAME PointCloudComponentAdder_Rejector    INPUT FEATURE_TYPE ___TOREJECTOR___    TEST @Value(fme_rejection_code) != ""    OUTPUT PASSED FEATURE_TYPE PointCloudComponentAdder_<REJECTED>       @RemoveAttributes(___fme_rejection_code___)    OUTPUT FAILED FEATURE_TYPE PointCloudComponentAdder_OUTPUT       @RenameAttributes(FME_STRICT,fme_rejection_code,___fme_rejection_code___)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudComponentAdder_<Rejected> INPUT FEATURE_TYPE PointCloudComponentAdder_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudComponentAdder<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} SurfaceModelFactory    FACTORY_NAME RasterDEMGenerator    FLUSH_WHEN_GROUPS_CHANGE No    INPUT POINTS FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_0_iQyPhi3mnFo=    TOLERANCE 0.1    SAMPLE_SPACING 0.4 0.4    INTERPOLATION_TYPE AUTO    NODATA_VALUE -32767.0    REJECT_INVALID_GEOM YES    OUTPUT DEM_RASTER FEATURE_TYPE RasterDEMGenerator_DEM_RASTER        @SupplyAttributes(?,fme_basename,RasterDEMGenerator)    OUTPUT REJECTED FEATURE_TYPE RasterDEMGenerator_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME RasterDEMGenerator_<Rejected> INPUT FEATURE_TYPE RasterDEMGenerator_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, RasterDEMGenerator<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_2_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|z_ground|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_2_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
-FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_2    INPUT  FEATURE_TYPE PointCloudComponentAdder_OUTPUT    INPUT  FEATURE_TYPE RasterDEMGenerator_DEM_RASTER    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_2_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_2_<REJECTED>
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudOnRasterComponentSetter_2 PointCloud Splitter"   INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud   OUTPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_0_Cp3PFkJGvQM=   OUTPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_1_pOvQ2H97RY4=
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_2_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|mur|$(SourceDataset_GEOTIFF)} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
-FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_1_pOvQ2H97RY4=    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_1    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_4    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4 ; <at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4 ; 5    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_4_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_4    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = 5 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_5    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_4 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_4_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_4<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-DEFAULT_MACRO PointCloudExpressionEvaluator_COMPONENT_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_COMPONENT_TYPE_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_EXPRESSION_LIST
-INCLUDE [    foreach {component componenttype expression} [split {z Real32 @EvaluateExpression(FDIV,STRING_ENCODED,<at>Component<openparen>z<closeparen>-<at>Component<openparen>z_ground<closeparen>,PointCloudExpressionEvaluator)}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_0_Cp3PFkJGvQM=    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_3    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_RESULT    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>z<closeparen><lt>0 ; <at>Component<openparen>z<closeparen><gt>50 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Negative<space>points ; Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_3_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_3_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = Negative<space>points OUTPUT PASSED FEATURE_TYPE PointCloudFilter_3_Negative<space>points    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_3_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_3_Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_2
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_3_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_3_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_3 Negative<space>points Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_3_Negative<space>points
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_3 Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_3_Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_3_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} SurfaceModelFactory    FACTORY_NAME RasterDEMGenerator_2    FLUSH_WHEN_GROUPS_CHANGE No    INPUT POINTS FEATURE_TYPE PointCloudFilter_3_<UNFILTERED>    TOLERANCE 0.1    SAMPLE_SPACING 0.4 0.4    INTERPOLATION_TYPE AUTO    NODATA_VALUE -32767.0    REJECT_INVALID_GEOM YES    OUTPUT DEM_RASTER FEATURE_TYPE RasterDEMGenerator_2_DEM_RASTER        @SupplyAttributes(?,fme_basename,RasterDEMGenerator_2)    OUTPUT REJECTED FEATURE_TYPE RasterDEMGenerator_2_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME RasterDEMGenerator_2_<Rejected> INPUT FEATURE_TYPE RasterDEMGenerator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, RasterDEMGenerator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|z_max|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
-FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_3    INPUT  FEATURE_TYPE PointCloudFilter_4_4    INPUT  FEATURE_TYPE RasterDEMGenerator_2_DEM_RASTER    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_3_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_3_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_5    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>z_max<closeparen><lt>=3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>out    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_5_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_5_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>out OUTPUT PASSED FEATURE_TYPE PointCloudFilter_5_4<space>out    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_5 4<space>out Splitter"   INPUT FEATURE_TYPE PointCloudFilter_5_4<space>out   OUTPUT FEATURE_TYPE PointCloudFilter_5_4<space>out_0_MZflbMncRTk=   OUTPUT FEATURE_TYPE PointCloudFilter_5_4<space>out_1_8onCNNziEwg=
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_5_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_5<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_6    INPUT  FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_6_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_6_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_6_4<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_6_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_6<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner_2___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_5_4<space>out_1_8onCNNziEwg=    INPUT  FEATURE_TYPE PointCloudFilter_6_4<space>-<space>mur    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner_2)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
-FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner_2___Combiner    INPUT FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_2_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_2_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST
-DEFAULT_MACRO PointCloudExpressionEvaluator_2_EXPRESSION_LIST
-INCLUDE [    foreach {component componenttype expression} [split {classification Auto 3}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_2_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_2    INPUT  FEATURE_TYPE PointCloudCombiner_2_OUTPUT    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_2_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_2_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_1_WXAwGkpiE4A=    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    INPUT  FEATURE_TYPE PointCloudFilter_4_5    INPUT  FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    INPUT  FEATURE_TYPE PointCloudFilter_<UNFILTERED>    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
-FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner___Combiner    INPUT FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_7    INPUT  FEATURE_TYPE PointCloudFilter_5_4<space>out_0_MZflbMncRTk=    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_7_<REJECTED>
-FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_7_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_7_4<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_1
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_7_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_7_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
-FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_7 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_7_<UNFILTERED>
-DEFAULT_MACRO _WB_BYPASS_TERMINATION No
-FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_7_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_7_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_7<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
-# -------------------------------------------------------------------------
-# Assumption is that the workspace temp dir has been already set and created.  See controldefs.cpp - ControlDefs::writeVisualizerTempDir
-DEFAULT_MACRO WORKSPACE_TEMP_DIR
-INCLUDE [    set safeName "[regsub -all {[^a-zA-Z0-9]} {4-mur_2} _]_[expr round(rand() * 1000000)]_[clock clicks  -milliseconds]";    puts "MACRO SAFE_FFS_NAME $safeName"; ]
-FACTORY_DEF {*} InspectorFactory    FACTORY_NAME 4-mur_2_Prepper    COMMAND_PARM_EVALUATION SINGLE_PASS    INPUT  FEATURE_TYPE PointCloudFilter_7_4<space>-<space>mur    GROUP_ATTRIBUTE __inspector_feature_type_attr__    GROUP_BY {  }    GROUP_ATTRIBUTE_PREFIX { 4-mur_2 }    RASTER_REDUCTION NoReduction    POINT_CLOUD_REDUCTION NO_THINNING    OUTPUT RESULT FEATURE_TYPE __viewme__
-# Now route all the features into the recorder, changing their
-# feature type to the transformer name so that they view nicely
-DEFAULT_MACRO VISUALIZER_FEATURE_FILE $(WORKSPACE_TEMP_DIR)/$(SAFE_FFS_NAME).ffs
-DEFAULT_MACRO VISUALIZER_CREATE_SPATIAL_INDEX NO
-# [PR#45549] The Data Inspector will limit the maximum number of features
-# it reads on WIN32, so we will correspondingly limit the number of
-# features we record here using the MAX_FEATURES_TO_RECORD directive.
-FACTORY_DEF * RecorderFactory    FACTORY_NAME 4-mur_2_Recorder    COMMAND_PARM_EVALUATION SINGLE_PASS    INPUT FEATURE_TYPE __viewme__       _wb_termination_feature Yes       @FeatureType(TERMINATOR_@Value(_wb_termination_xformer))    INPUT FEATURE_TYPE __viewme__       @FeatureType(@Value(__inspector_feature_type_attr__))       @RemoveAttributes(__inspector_feature_type_attr__)    FEATURE_FILE "$(VISUALIZER_FEATURE_FILE)"    STORE_SCANNED_SCHEMA YES    NORMALIZE_LIST_ATTRIBUTES_ON_SCHEMA YES    CREATE_SPATIAL_INDEX "$(VISUALIZER_CREATE_SPATIAL_INDEX)"    INSPECTOR "$(VISUALIZER_CREATE_SPATIAL_INDEX)"    FSC_SCHEMA fme_basename,varchar<openparen>50<closeparen>    MODE RECORD    STORE_SCANNED_METADATA    RECORD_DIRECTLY_TO_DISK YES    MAX_FEATURES_TO_RECORD WIN32 2000000
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * RoutingFactory FACTORY_NAME "Destination Feature Type Routing Correlator"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE FME_GENERIC PointCloudCombiner_OUTPUT TO LAS __GO_TO_FINAL_OUTPUT_ROUTER__ multi_writer_id,0,<at>SupplyAttributes<openparen>ENCODED<comma>fme_template_feature_type<comma>LAS01<closeparen>,<at>EvaluateExpression<openparen>ATTR_CREATE_EXPR<comma>__wb_out_feat_type__<comma><lt>at<gt>Value<lt>openparen<gt>fme_basename<lt>closeparen<gt>_CLEAN<comma>LAS01<closeparen> GEOMETRY   FEATURE_TYPE_ATTRIBUTE __wb_out_feat_type__   OUTPUT ROUTED FEATURE_TYPE *    OUTPUT NOT_ROUTED FEATURE_TYPE __nuke_me__ @Tcl2("FME_StatMessage 818059 [FME_GetAttribute fme_template_feature_type] 818060 818061 fme_warn")
-# -------------------------------------------------------------------------
-
-FACTORY_DEF * TeeFactory   FACTORY_NAME "Final Output Nuker"   INPUT FEATURE_TYPE __nuke_me__
-
-# -------------------------------------------------------------------------
-
-DEFAULT_MACRO FME_LAUNCH_VIEWER_APP NO
-FACTORY_DEF * CreationFactory    FACTORY_NAME VisualizerProcessor   CREATE_AT_END   OUTPUT FEATURE_TYPE __NUKEME__   @TCL("if {{$(FME_LAUNCH_VIEWER_APP)} == {YES}} {  if [file exists {$(WORKSPACE_TEMP_DIR)}] {set files [glob -nocomplain -directory  {$(WORKSPACE_TEMP_DIR)} -tails *.ffs];   if {[llength $files] == 1} {    set theFile {$(WORKSPACE_TEMP_DIR)/};   append theFile [lindex $files 0];   eval FME_Execute System \173\042$(FME_HOME_UNIX)/fmedatainspector\042 --visualizer --single-application --delete-on-close --no-source-prompt -f FFS \042$theFile\042 & \175;  } elseif { [llength $files] == 0 } {  catch { file delete -force {$(WORKSPACE_TEMP_DIR)} };  } else {  set filesNoExt {}; set lastfile {}; foreach {fileName} [lsort $files] { set fileNoExt [string trimright $fileName {.ffs}]; if [regexp {(.*)_[0-9]*$} $fileNoExt wholething fileNoExtBase] {  if { $fileNoExtBase == $lastfile } { continue } }; set lastfile $fileNoExt; lappend filesNoExt $fileNoExt };  eval FME_Execute System \173\042$(FME_HOME_UNIX)/fmedatainspector\042 --visualizer --single-application --delete-on-close --no-source-prompt -d {$(WORKSPACE_TEMP_DIR)} -a ffs -f FFS $filesNoExt & \175; }; }; }; ")
-FACTORY_DEF * TeeFactory    FACTORY_NAME VisualizerCleaner   INPUT FEATURE_TYPE __NUKEME__
-# -------------------------------------------------------------------------
-LAS_2_DEF LAS01
+#! <?xml version="1.0" encoding="UTF-8" ?>
+#! <WORKSPACE
+#    Command-line to run this workspace:
+#        "C:\Program Files (x86)\FME2020\fme.exe" G:\STDL\LIDAR_2021\Scripts_et_Processus\LAS_Pretraitement_2021_cleaning_MNHC.fmw
+#              --SourceDataset_LAS "G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las"
+#              --SourceDataset_GEOTIFF "G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
+#              --DestDataset_LAS "G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1"
+#    
+#!   ATTR_TYPE_ENCODING="SDF"
+#!   BEGIN_PYTHON=""
+#!   BEGIN_TCL=""
+#!   CATEGORY=""
+#!   DESCRIPTION=""
+#!   DESTINATION="NONE"
+#!   DESTINATION_ROUTING_FILE=""
+#!   DOC_EXTENTS="8882.7 3257.1"
+#!   DOC_TOP_LEFT="-1168.89 -2802.58"
+#!   END_PYTHON=""
+#!   END_TCL=""
+#!   EXPLICIT_BOOKMARK_ORDER="false"
+#!   FME_BUILD_NUM="20596"
+#!   FME_DOCUMENT_GUID="13630376-052c-4951-806c-6d68a363e1db"
+#!   FME_DOCUMENT_PRIORGUID="e44176b6-c7b1-43ea-b9f4-2c32a085725b,c381042f-601f-4ea6-8815-83d7bd38b88a,f7a0bbd2-1db7-4a74-ae55-a63987eae69b,078fad80-7051-4100-84e6-4696f553bbea,51ed0ff3-37f8-45b3-9ff8-b75998c54609,a59d9bc8-853b-4bc5-b623-147dc834d4d4,4f78c6c4-ded3-4776-b8ea-5b68e5da3bbf,3296ce31-5f45-4f4d-9043-d690711b051f,3245acd7-3769-436b-af73-f216ec552967"
+#!   FME_GEOMETRY_HANDLING="Enhanced"
+#!   FME_IMPLICIT_CSMAP_REPROJECTION_MODE="Auto"
+#!   FME_REPROJECTION_ENGINE="FME"
+#!   FME_SERVER_SERVICES=""
+#!   FME_STROKE_MAX_DEVIATION="0"
+#!   HISTORY=""
+#!   IGNORE_READER_FAILURE="No"
+#!   LAST_SAVE_BUILD="FME(R) 2020.1.0.1 (20200710 - Build 20596 - WIN32)"
+#!   LAST_SAVE_DATE="2022-01-12T17:51:04"
+#!   LOG_FILE=""
+#!   LOG_MAX_RECORDED_FEATURES="200"
+#!   MARKDOWN_DESCRIPTION=""
+#!   MARKDOWN_USAGE=""
+#!   MAX_LOG_FEATURES="200"
+#!   MULTI_WRITER_DATASET_ORDER="BY_ID"
+#!   PASSWORD=""
+#!   PYTHON_COMPATIBILITY="37"
+#!   REDIRECT_TERMINATORS="NONE"
+#!   SAVE_ON_PROMPT_AND_RUN="Yes"
+#!   SHOW_ANNOTATIONS="true"
+#!   SHOW_INFO_NODES="true"
+#!   SOURCE="NONE"
+#!   SOURCE_ROUTING_FILE=""
+#!   TERMINATE_REJECTED="YES"
+#!   TITLE=""
+#!   USAGE=""
+#!   USE_MARKDOWN=""
+#!   VIEW_POSITION="2448.6 443.042"
+#!   WARN_INVALID_XFORM_PARAM="Yes"
+#!   WORKSPACE_VERSION="1"
+#!   ZOOM_SCALE="79"
+#! >
+#! <DATASETS>
+#! <DATASET
+#!   IS_SOURCE="true"
+#!   ROLE="READER"
+#!   FORMAT="LAS"
+#!   DATASET="$(SourceDataset_LAS)"
+#!   KEYWORD="LAS_1"
+#!   MULTI_GEOM_ALLOWED="false"
+#!   ATTR_MAX_LENGTH="0"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="false"
+#!   EXPOSABLE_ATTRS="fme_secondary_axis number(31,15) las_file_creation_date date las_project_id char(36) las_synthetic_returns logical las_generating_software char(32) fme_sweep_angle number(31,15) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_basename char(50) fme_feature_type char(50) las_file_source_id number(6,0) fme_color char(50) fme_type char(50) fme_dataset char(50) las_vertical_coordsys_code number(6,0) fme_rotation number(31,15) las_gps_time_type number(1,0) fme_fill_color char(50) multi_reader_type char(50) multi_reader_id number(11,0) las_system_identifier char(32) multi_reader_keyword char(50) fme_geometry char(50) las_version char(3) multi_reader_full_id number(11,0) fme_text_string char(50) las_zlas_rearranged_points logical las_vertical_units_code number(6,0) las_type char(255) fme_text_size number(31,15) fme_start_angle number(31,15)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE="LISTBOX_ENCODED"
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FEATURE_TYPES=""
+#!   MAX_FEATURES=""
+#!   MAX_FEATURES_PER_FEATURE_TYPE=""
+#!   MIN_FEATURES=""
+#!   START_FEATURE=""
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="las file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="File1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="LAS File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the LAS file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the LAS file"
+#! />
+#! </DATASET>
+#! <DATASET
+#!   IS_SOURCE="true"
+#!   ROLE="READER"
+#!   FORMAT="GEOTIFF"
+#!   DATASET="$(SourceDataset_GEOTIFF)"
+#!   KEYWORD="GEOTIFF_1"
+#!   MULTI_GEOM_ALLOWED="false"
+#!   ATTR_MAX_LENGTH="0"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="true"
+#!   EXPOSABLE_ATTRS="geotiff_subdataset_name char(255) geotiff_tifftag_yresolution float fme_color char(50) geotiff_tifftag_imagedescription char(255) fme_sweep_angle float fme_basename char(50) geotiff_area_or_point char(255) multi_reader_keyword char(50) geotiff_photometric_interpretation char(10) geotiff_tifftag_datetime datetime fme_dataset char(50) multi_reader_type char(50) fme_text_string char(50) geotiff_tifftag_xresolution float multi_reader_full_id integer fme_fill_color char(50) geotiff_interleaving_type char(3) geotiff_tifftag_documentname char(255) fme_start_angle float geotiff_tifftag_hostcomputer char(255) fme_feature_type char(50) geotiff_type char(255) geotiff_tifftag_software char(255) geotiff_private_keys{}.type char(6) geotiff_tifftag_maxsamplevalue integer geotiff_tifftag_copyright char(255) geotiff_tifftag_minsamplevalue integer fme_geometry char(50) multi_reader_id integer fme_type char(50) geotiff_tifftag_resolutionunit decimal(1,0) geotiff_private_keys{}.id integer geotiff_number_of_bits_per_cell decimal(1,0) geotiff_tifftag_artist char(255) fme_secondary_axis float geotiff_subdataset_description char(255) fme_rotation float geotiff_pyramid_level{}.num_rows integer geotiff_pyramid_num_levels integer fme_text_size float fme_primary_axis float geotiff_compression_method char(9) geotiff_pyramid_level{}.num_columns integer geotiff_private_keys{}.value char(255) geotiff_byte_order char(7)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE="LISTBOX_ENCODED"
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FEATURE_TYPES=""
+#!   MAX_FEATURES=""
+#!   MAX_FEATURES_PER_FEATURE_TYPE=""
+#!   MIN_FEATURES=""
+#!   START_FEATURE=""
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY GEOTIFF_IN_PYRAMID_LEVEL GEOTIFF_IN_PREFER_FILE_CS_UNITS GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_IGNORE_RASTER_TYPE_KEY GEOTIFF_OUT_WRITE_OFFSETS_IN_CS_UNITS GEOTIFF_OUT_WRITE_PROJECTED_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_COORDSYS_AS_EPSG_CODE GEOTIFF_OUT_WRITE_GEOGRAPHIC_KEYS_FOR_PROJECTED_COORDSYS GEOTIFF_OUT_WRITE_ESRI_COMPATIBLE_COORDSYS"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="tif file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="Raster1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="Raster File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="MIME_TYPE"
+#!   VALUE="image/TIFF"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the GeoTIFF file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the GeoTIFF file"
+#! />
+#! </DATASET>
+#! <DATASET
+#!   IS_SOURCE="false"
+#!   ROLE="WRITER"
+#!   FORMAT="LAS"
+#!   DATASET="$(DestDataset_LAS)"
+#!   KEYWORD="LAS_2"
+#!   MULTI_GEOM_ALLOWED="true"
+#!   ATTR_MAX_LENGTH="60"
+#!   ATTR_CASE="ANY"
+#!   ALLOWED_FEAT_TYPES=""
+#!   WRITE_DEFS="true"
+#!   DEFLINE_TEMPLATE=""
+#!   DEFLINE_ATTRS="false"
+#!   EXPOSABLE_ATTRS="fme_secondary_axis number(31,15) las_file_creation_date date las_project_id char(36) las_synthetic_returns logical las_generating_software char(32) fme_sweep_angle number(31,15) fme_primary_axis number(31,15) las_vertical_datum_code number(6,0) fme_basename char(50) fme_feature_type char(50) las_file_source_id number(6,0) fme_color char(50) fme_type char(50) las_vertical_coordsys_code number(6,0) fme_dataset char(50) fme_rotation number(31,15) las_gps_time_type number(1,0) fme_fill_color char(50) las_system_identifier char(32) fme_geometry char(50) fme_text_string char(50) las_zlas_rearranged_points logical las_vertical_units_code number(6,0) las_type char(255) fme_text_size number(31,15) fme_start_angle number(31,15)"
+#!   DEFLINE_PARMS=""
+#!   ATTR_INDEX_TYPES=""
+#!   ATTR_NAME_INVALID_CHARS=""
+#!   SUPPORTS_FEATURE_TYPE_FANOUT="true"
+#!   ENABLED="true"
+#!   DYNAMIC_FEATURE_TYPES_LIST_ON_MERGE="true"
+#!   DATASET_TYPE="FILEDIR"
+#!   FTTR_TYPE=""
+#!   GENERATE_FME_BUILD_NUM="20596"
+#!   COORDSYS=""
+#!   FANOUT_EXPRESSION=""
+#!   FANOUT_GROUP="NO"
+#! >
+#! <METAFILE_PARAMETER
+#!   NAME="ADVANCED_PARMS"
+#!   VALUE="LAS_OUT_ARCGIS_LAS_DATASET LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET LAS_OUT_ZLAS_REARRANGE_POINTS LAS_OUT_ZLAS_POINT_SPACING_SOURCE LAS_OUT_ZLAS_POINT_SPACING_VALUE"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="AUTO_FANOUT_ATTRIBUTE"
+#!   VALUE="fme_basename"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="DATASET_NAME"
+#!   VALUE="las file"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_DEFAULT_NAME"
+#!   VALUE="File1"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="FEATURE_TYPE_NAME"
+#!   VALUE="LAS File"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_AUTO_EXPOSE"
+#!   VALUE="fme_basename char(50)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="READER_DATASET_HINT"
+#!   VALUE="Select the LAS file(s)"
+#! />
+#! <METAFILE_PARAMETER
+#!   NAME="WRITER_DATASET_HINT"
+#!   VALUE="Specify a folder for the LAS file"
+#! />
+#! </DATASET>
+#! </DATASETS>
+#! <DATA_TYPES>
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(20)"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(12)"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(31,15)"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(15,7)"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="number(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="datetime"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="time"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="decimal(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="float"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="float"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="integer"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="largeint"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="decimal(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="largeint"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="integer"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="smallint"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varchar(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_varbinary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_char(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(width)"
+#!   FME_TYPE="fme_binary(width)"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_buffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_binarybuffer"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_xml"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(254)"
+#!   FME_TYPE="fme_json"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(20)"
+#!   FME_TYPE="fme_datetime"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="char(12)"
+#!   FME_TYPE="fme_time"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="date"
+#!   FME_TYPE="fme_date"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(31,15)"
+#!   FME_TYPE="fme_real64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(15,7)"
+#!   FME_TYPE="fme_real32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_int32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(11,0)"
+#!   FME_TYPE="fme_uint32"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_int64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(20,0)"
+#!   FME_TYPE="fme_uint64"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="logical"
+#!   FME_TYPE="fme_boolean"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_int16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(6,0)"
+#!   FME_TYPE="fme_uint16"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_int8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(4,0)"
+#!   FME_TYPE="fme_uint8"
+#!   FORMAT="LAS"
+#! />
+#! <DATA_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="number(width,decimal)"
+#!   FME_TYPE="fme_decimal(width,decimal)"
+#!   FORMAT="LAS"
+#! />
+#! </DATA_TYPES>
+#! <GEOM_TYPES>
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="las_point_cloud"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_raster"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="true"
+#!   FORMAT_TYPE="geotiff_none"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="GEOTIFF"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="las_point_cloud"
+#!   FME_TYPE="fme_point_cloud"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_point"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_text"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_line"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_arc"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_area"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_ellipse"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_rounded_rectangle"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_no_geom"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_raster"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_solid"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_surface"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_feature_table"
+#!   FORMAT="LAS"
+#! />
+#! <GEOM_TYPE
+#!   IS_SOURCE="false"
+#!   FORMAT_TYPE="fme_no_map"
+#!   FME_TYPE="fme_collection"
+#!   FORMAT="LAS"
+#! />
+#! </GEOM_TYPES>
+#! <FEATURE_TYPES>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="true"
+#!   NODE_NAME="LAS"
+#!   FEATURE_TYPE_NAME=""
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="false"
+#!   IDENTIFIER="2"
+#!   FEAT_GEOMTYPE="las_point_cloud"
+#!   POSITION="-1076.8859688596885 -231.8749687496875"
+#!   BOUNDING_RECT="-1076.8859688596885 -231.8749687496875 454 71"
+#!   ORDER="500000000000000"
+#!   COLLAPSED="true"
+#!   KEYWORD="LAS_1"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   HIDDEN_USER_ATTRS=""
+#!   MERGE_FILTER=""
+#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
+#!   MERGE_FILTER_CASE_SENSITIVE="true"
+#!   DYNAMIC_SCHEMA="false"
+#! >
+#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
+#! </FEATURE_TYPE>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="true"
+#!   NODE_NAME="GEOTIFF"
+#!   FEATURE_TYPE_NAME=""
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="false"
+#!   IDENTIFIER="3"
+#!   FEAT_GEOMTYPE="geotiff_raster"
+#!   POSITION="599.57896652137288 -1000.3837188371879"
+#!   BOUNDING_RECT="599.57896652137288 -1000.3837188371879 454 71"
+#!   ORDER="500000000000000"
+#!   COLLAPSED="true"
+#!   KEYWORD="GEOTIFF_1"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   HIDDEN_USER_ATTRS=""
+#!   MERGE_FILTER=""
+#!   MERGE_FILTER_TYPE="FILTER_TYPE_GLOB"
+#!   MERGE_FILTER_CASE_SENSITIVE="false"
+#!   DYNAMIC_SCHEMA="false"
+#! >
+#!     <FEAT_ATTRIBUTE ATTR_NAME="fme_basename" ATTR_TYPE="char(50)"  EXPOSABLE_ATTR="true" ATTR_HAS_PORT="true" ATTR_VALUE=""/>
+#! </FEATURE_TYPE>
+#! <FEATURE_TYPE
+#!   IS_SOURCE="false"
+#!   NODE_NAME="LAS01"
+#!   FEATURE_TYPE_NAME="@Value(fme_basename)_CLEAN"
+#!   FEATURE_TYPE_NAME_QUALIFIER=""
+#!   IS_EDITABLE="true"
+#!   IDENTIFIER="67"
+#!   FEAT_GEOMTYPE="All"
+#!   POSITION="7167.8157641634389 -2678.0814285993265"
+#!   BOUNDING_RECT="7167.8157641634389 -2678.0814285993265 454 71"
+#!   ORDER="500000000000018"
+#!   COLLAPSED="true"
+#!   KEYWORD="LAS_2"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   SCHEMA_ATTRIBUTE_SOURCE="1"
+#! >
+#! </FEATURE_TYPE>
+#! </FEATURE_TYPES>
+#! <FMESERVER>
+#! <READER_DATASETS>
+#! <DATASET
+#!   NAME="LAS_1"
+#!   OVERRIDE="-LAS_1_DATASET"
+#!   DATASET="LAS_1/GT_Bel_Air_Buf20.las"
+#! />
+#! <DATASET
+#!   NAME="GEOTIFF_1"
+#!   OVERRIDE="-GEOTIFF_1_DATASET"
+#!   DATASET="GEOTIFF_1/Murs_THOCHB_Buff05_rast.tif"
+#! />
+#! </READER_DATASETS>
+#! <WRITER_DATASETS>
+#! <DATASET
+#!   NAME="LAS_2"
+#!   OVERRIDE="-LAS_2_DATASET"
+#!   DATASET="LAS_2/Test_cleaning_1"
+#! />
+#! </WRITER_DATASETS>
+#! </FMESERVER>
+#! <GLOBAL_PARAMETERS>
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las"
+#!   IS_STAND_ALONE="false"
+#! />
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif"
+#!   IS_STAND_ALONE="false"
+#! />
+#! <GLOBAL_PARAMETER
+#!   GUI_LINE="GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:"
+#!   DEFAULT_VALUE="G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1"
+#!   IS_STAND_ALONE="false"
+#! />
+#! </GLOBAL_PARAMETERS>
+#! <COMMENTS>
+#! <COMMENT
+#!   IDENTIFIER="70"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Move filtered points to the class 3&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="6012.7543942690818 -911.69959378330645"
+#!   TOP_LEFT="6012.7543942690818 -911.69959378330645"
+#!   BOTTOM_RIGHT="6710.4433795881969 -1010.4502812901815"
+#!   BOUNDING_RECT="6012.7543942690818 -911.69959378330645 697.68898531911509 98.750687506875067"
+#!   ORDER="500000000000035"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="69"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="64"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Extraction of vegetation points (4-5) for cleaning and ground + water points (2,9) to produce the Digital Elevation model (DEM) and then the Digital Canopy Height Model (DCHM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="-1036.5957318109765 310.21526678681414"
+#!   TOP_LEFT="-1036.5957318109765 310.21526678681414"
+#!   BOTTOM_RIGHT="19.227255153649139 123.96370427118899"
+#!   BOUNDING_RECT="-1036.5957318109765 310.21526678681414 1055.8229869646257 186.25156251562515"
+#!   ORDER="500000000000037"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="4"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="65"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Production of Digital Elevation Model (DEM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="415.26683382775855 454.51432789690216"
+#!   TOP_LEFT="415.26683382775855 454.51432789690216"
+#!   BOTTOM_RIGHT="1303.3666922035072 355.76364039002709"
+#!   BOUNDING_RECT="415.26683382775855 454.51432789690216 888.09985837574857 98.750687506875067"
+#!   ORDER="500000000000038"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="19"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="72"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt; with 50cm buffer and rasterized (pixel value = 3.5)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="536.1557398713943 -871.88371883718787"
+#!   TOP_LEFT="536.1557398713943 -871.88371883718787"
+#!   BOTTOM_RIGHT="1498.9226262636623 -970.63440634406288"
+#!   BOUNDING_RECT="536.1557398713943 -871.88371883718787 962.76688639226802 98.750687506875067"
+#!   ORDER="500000000000027"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="0.63529411764705879,0.80000000000000004,0.59999999999999998,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="0"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="73"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Addition of new components for wall and height informations&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="86.16072564766057 -592.54385422642099"
+#!   TOP_LEFT="86.16072564766057 -592.54385422642099"
+#!   BOTTOM_RIGHT="978.54513898674338 -735.0449792376711"
+#!   BOUNDING_RECT="86.16072564766057 -592.54385422642099 892.38441333908281 142.50112501125011"
+#!   ORDER="500000000000040"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="5"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="74"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets the the altitude of the ground under the point&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="1246.7063076427874 108.51432789690219"
+#!   TOP_LEFT="1246.7063076427874 108.51432789690219"
+#!   BOTTOM_RIGHT="2018.7063076427874 107.51432789690219"
+#!   BOUNDING_RECT="1246.7063076427874 108.51432789690219 772 1"
+#!   ORDER="500000000000041"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="21"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="75"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Calculation of the height of the point&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="1791.5119433664809 -50.001750017500171"
+#!   TOP_LEFT="1791.5119433664809 -50.001750017500171"
+#!   BOTTOM_RIGHT="2544.2173613655327 -148.75243752437524"
+#!   BOUNDING_RECT="1791.5119433664809 -50.001750017500171 752.70541799905186 98.750687506875067"
+#!   ORDER="500000000000042"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="24"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="59"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out abberrant or negative points&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="2640.1870626176733 -100.02162569693064"
+#!   TOP_LEFT="2640.1870626176733 -100.02162569693064"
+#!   BOTTOM_RIGHT="3447.0394481112248 -198.77231320380571"
+#!   BOUNDING_RECT="2640.1870626176733 -100.02162569693064 806.85238549355154 98.750687506875067"
+#!   ORDER="500000000000043"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="26"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="60"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Production of the Digital Canopy Height Model (DCHM)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="3170.9913058726552 -227.50287502875028"
+#!   TOP_LEFT="3170.9913058726552 -227.50287502875028"
+#!   BOTTOM_RIGHT="3980.4690976202687 -370.00400004000039"
+#!   BOUNDING_RECT="3170.9913058726552 -227.50287502875028 809.47779174761354 142.50112501125011"
+#!   ORDER="500000000000045"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="28"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="61"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;mur&amp;quot; to indicate if the point is situated above a wall (3) or not (0)&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="1432.8800495879839 -1295.1268698771116"
+#!   TOP_LEFT="1432.8800495879839 -1295.1268698771116"
+#!   BOTTOM_RIGHT="2162.8800495879841 -1296.1268698771116"
+#!   BOUNDING_RECT="1432.8800495879839 -1295.1268698771116 730 1"
+#!   ORDER="500000000000046"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="7"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="62"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Sets a value in the new component &amp;quot;z_max&amp;quot; corresponding to the height of the highest point of vegetaion above a point of class 4. It indicates if the points is situated under higher vegetation or not.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="3502.2194882143003 -719.44352404689062"
+#!   TOP_LEFT="3502.2194882143003 -719.44352404689062"
+#!   BOTTOM_RIGHT="4878.6895635946648 -905.69508656251583"
+#!   BOUNDING_RECT="3502.2194882143003 -719.44352404689062 1376.4700753803645 186.25156251562515"
+#!   ORDER="500000000000047"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="34"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="76"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out all points of class 4 that are NOT under higher vegetation (z-max &amp;lt;=3). &lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="3942.8650513689618 -959.38459384593807"
+#!   TOP_LEFT="3942.8650513689618 -959.38459384593807"
+#!   BOTTOM_RIGHT="4769.465170379859 -1101.8857188571883"
+#!   BOUNDING_RECT="3942.8650513689618 -959.38459384593807 826.60011901089729 142.50112501125011"
+#!   ORDER="500000000000048"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="37"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="78"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Filters out points of class 4 that are situated above a wall&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="4574.0705446717948 -1693.4785721845751"
+#!   TOP_LEFT="4574.0705446717948 -1693.4785721845751"
+#!   BOTTOM_RIGHT="5289.8729070785848 -1835.9796971958253"
+#!   BOUNDING_RECT="4574.0705446717948 -1693.4785721845751 715.80236240679005 142.50112501125011"
+#!   ORDER="500000000000049"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="38"
+#! />
+#! <COMMENT
+#!   IDENTIFIER="80"
+#!   COMMENT_VALUE="&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0//EN&quot; &quot;http://www.w3.org/TR/REC-html40/strict.dtd&quot;&gt;&#10;&lt;html&gt;&lt;head&gt;&lt;meta name=&quot;qrichtext&quot; content=&quot;1&quot; /&gt;&lt;style type=&quot;text/css&quot;&gt;&#10;p, li { white-space: pre-wrap; }&#10;&lt;/style&gt;&lt;/head&gt;&lt;body style=&quot; font-family:&apos;MS Shell Dlg 2&apos;; font-size:9pt; font-weight:400; font-style:normal;&quot;&gt;&#10;&lt;p style=&quot; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;&quot;&gt;Recombination of all points  for writing&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;"
+#!   POSITION="6395.5222988431415 -2447.3528510634337"
+#!   TOP_LEFT="6395.5222988431415 -2447.3528510634337"
+#!   BOTTOM_RIGHT="7145.095722801887 -2546.103538570309"
+#!   BOUNDING_RECT="6395.5222988431415 -2447.3528510634337 749.57342395874548 98.750687506875067"
+#!   ORDER="500000000000050"
+#!   FOLLOW_ANCHOR="true"
+#!   INFO_NODE="false"
+#!   CUSTOM_USER_COLOR="false"
+#!   COLOUR="1,1,0.95686274509803926,0.78431372549019607"
+#!   SIZE_POLICY="10"
+#!   ANCHORED_NODE="41"
+#! />
+#! </COMMENTS>
+#! <CONSTANTS>
+#! </CONSTANTS>
+#! <BOOKMARKS>
+#! <BOOKMARK
+#!   IDENTIFIER="63"
+#!   NAME="LAS file"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="-1168.8859688596885 -103.3749687496875"
+#!   ORDER="500000000000036"
+#!   PALETTE_COLOR="Color1"
+#!   BOTTOM_RIGHT="-534.88596885968855 -356.37496874968747"
+#!   BOUNDING_RECT="-1168.8859688596885 -103.3749687496875 634 253"
+#!   STICKY="true"
+#!   COLOUR="0.59999999999999998,0.80000000000000004,0.80000000000000004,1"
+#!   CONTENTS="2 "
+#! >
+#! </BOOKMARK>
+#! <BOOKMARK
+#!   IDENTIFIER="66"
+#!   NAME="Cadastre of walls"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="507.57896652137288 -762.20274397865921"
+#!   ORDER="500000000000039"
+#!   PALETTE_COLOR="Color2"
+#!   BOTTOM_RIGHT="1535.8385291169984 -1124.8837188371879"
+#!   BOUNDING_RECT="507.57896652137288 -762.20274397865921 1028.2595625956255 362.68097485852866"
+#!   STICKY="true"
+#!   COLOUR="0.63529411764705879,0.80000000000000004,0.59999999999999998,1"
+#!   CONTENTS="3 72 "
+#! >
+#! </BOOKMARK>
+#! <BOOKMARK
+#!   IDENTIFIER="81"
+#!   NAME="New LAS file cleaned"
+#!   DESCRIPTION=""
+#!   TOP_LEFT="7079.8157641634389 -2549.5814285993265"
+#!   ORDER="500000000000051"
+#!   PALETTE_COLOR="Color4"
+#!   BOTTOM_RIGHT="7713.8157641634389 -2802.5814285993265"
+#!   BOUNDING_RECT="7079.8157641634389 -2549.5814285993265 634 253"
+#!   STICKY="true"
+#!   COLOUR="0.85098039215686272,0.92941176470588238,0.60392156862745094,1"
+#!   CONTENTS="67 "
+#! >
+#! </BOOKMARK>
+#! </BOOKMARKS>
+#! <TRANSFORMERS>
+#! <TRANSFORMER
+#!   IDENTIFIER="4"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="-434.37934379343807 -227.50287502875031"
+#!   BOUNDING_RECT="-434.37934379343807 -227.50287502875031 454 71"
+#!   ORDER="500000000000001"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="Ground&lt;space&gt;&lt;openparen&gt;2&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;Water&lt;space&gt;&lt;openparen&gt;9&lt;closeparen&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="3"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==2&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==9 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4&lt;space&gt;||&lt;space&gt;&lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Ground&lt;space&gt;&lt;openparen&gt;2&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;Water&lt;space&gt;&lt;openparen&gt;9&lt;closeparen&gt; ; V&lt;u00e9&gt;g&lt;u00e9&gt;tation&lt;space&gt;moyenne&lt;space&gt;&lt;openparen&gt;4&lt;closeparen&gt;&lt;space&gt;+&lt;space&gt;haute&lt;space&gt;&lt;openparen&gt;5&lt;closeparen&gt;"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="5"
+#!   TYPE="PointCloudComponentAdder"
+#!   VERSION="1"
+#!   POSITION="345.12253122531229 -347.50287502875028"
+#!   BOUNDING_RECT="345.12253122531229 -347.50287502875028 580.00106825772946 71"
+#!   ORDER="500000000000002"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD" PARM_VALUE="z_ground,Real64,0,z_max,Real64,0,mur,Real64,0"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENTS_TO_ADD_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudComponentAdder"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="7"
+#!   TYPE="PointCloudOnRasterComponentSetter"
+#!   VERSION="3"
+#!   POSITION="1660.2623126231272 -871.88371883718787"
+#!   BOUNDING_RECT="1660.2623126231272 -871.88371883718787 430 71"
+#!   ORDER="500000000000003"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="PointCloud"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|mur|$(SourceDataset_GEOTIFF)"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
+#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="19"
+#!   TYPE="RasterDEMGenerator"
+#!   VERSION="5"
+#!   POSITION="415.26683382775855 277.01320288565205"
+#!   BOUNDING_RECT="415.26683382775855 277.01320288565205 455.00106825772946 71"
+#!   ORDER="500000000000007"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="DEM_RASTER"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION_TYPE" PARM_VALUE="AUTO"/>
+#!     <XFORM_PARM PARM_NAME="NODATA_VALUE" PARM_VALUE="-32767.0"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TOLERANCE" PARM_VALUE="0.1"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="RasterDEMGenerator"/>
+#!     <XFORM_PARM PARM_NAME="X_SPACING" PARM_VALUE="0.4"/>
+#!     <XFORM_PARM PARM_NAME="Y_SPACING" PARM_VALUE="0.4"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="21"
+#!   TYPE="PointCloudOnRasterComponentSetter"
+#!   VERSION="3"
+#!   POSITION="1246.7063076427874 -68.986797114347922"
+#!   BOUNDING_RECT="1246.7063076427874 -68.986797114347922 430 71"
+#!   ORDER="500000000000008"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="PointCloud"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|z_ground|0"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
+#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_2"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="24"
+#!   TYPE="PointCloudExpressionEvaluator"
+#!   VERSION="3"
+#!   POSITION="1829.5119433664809 -227.50287502875028"
+#!   BOUNDING_RECT="1829.5119433664809 -227.50287502875028 430 71"
+#!   ORDER="500000000000009"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="RESULT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="z Real32 &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;-&lt;at&gt;Component&lt;openparen&gt;z_ground&lt;closeparen&gt;"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="26"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="2365.648656486565 -281.25281252812522"
+#!   BOUNDING_RECT="2365.648656486565 -281.25281252812522 454 71"
+#!   ORDER="500000000000010"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="Negative&lt;space&gt;points"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="Aberrant&lt;space&gt;height&lt;space&gt;points&lt;space&gt;&lt;openparen&gt;higher&lt;space&gt;than&lt;space&gt;50m&lt;closeparen&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="3"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;&lt;lt&gt;0 ; &lt;at&gt;Component&lt;openparen&gt;z&lt;closeparen&gt;&lt;gt&gt;50 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Negative&lt;space&gt;points ; Aberrant&lt;space&gt;height&lt;space&gt;points&lt;space&gt;&lt;openparen&gt;higher&lt;space&gt;than&lt;space&gt;50m&lt;closeparen&gt;"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_3"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="28"
+#!   TYPE="RasterDEMGenerator"
+#!   VERSION="5"
+#!   POSITION="2950.0295002950033 -403.12903129031281"
+#!   BOUNDING_RECT="2950.0295002950033 -403.12903129031281 497.00106825772946 71"
+#!   ORDER="500000000000011"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="DEM_RASTER"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION_TYPE" PARM_VALUE="AUTO"/>
+#!     <XFORM_PARM PARM_NAME="NODATA_VALUE" PARM_VALUE="-32767.0"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TOLERANCE" PARM_VALUE="0.1"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="RasterDEMGenerator_2"/>
+#!     <XFORM_PARM PARM_NAME="X_SPACING" PARM_VALUE="0.4"/>
+#!     <XFORM_PARM PARM_NAME="Y_SPACING" PARM_VALUE="0.4"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="31"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="2212.5221252212523 -1069.3850938509395"
+#!   BOUNDING_RECT="2212.5221252212523 -1069.3850938509395 454 71"
+#!   ORDER="500000000000012"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="5"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="3"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="3" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==4 ; &lt;at&gt;Component&lt;openparen&gt;classification&lt;closeparen&gt;==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4 ; 5"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_4"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="34"
+#!   TYPE="PointCloudOnRasterComponentSetter"
+#!   VERSION="3"
+#!   POSITION="2950.0295002950033 -959.38459384593807"
+#!   BOUNDING_RECT="2950.0295002950033 -959.38459384593807 785.00106825772946 71"
+#!   ORDER="500000000000013"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="PointCloud"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="COMPONENT_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_MAPPING" PARM_VALUE="0|z_max|0"/>
+#!     <XFORM_PARM PARM_NAME="COMPONENT_SPECIFICATION" PARM_VALUE="Custom"/>
+#!     <XFORM_PARM PARM_NAME="DEFAULT_VALUES_OVERWRITE_DATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_NODATA" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="INTERPOLATION" PARM_VALUE="Nearest Neighbor"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudOnRasterComponentSetter_3"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="37"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="3862.5386253862539 -1129.3850938509395"
+#!   BOUNDING_RECT="3862.5386253862539 -1129.3850938509395 454 71"
+#!   ORDER="500000000000014"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4&lt;space&gt;out"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;z_max&lt;closeparen&gt;&lt;lt&gt;=3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;out"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_5"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="38"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="4574.0705446717948 -1301.8599283282338"
+#!   BOUNDING_RECT="4574.0705446717948 -1301.8599283282338 454 71"
+#!   ORDER="500000000000014"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_6"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="41"
+#!   TYPE="PointCloudCombiner"
+#!   VERSION="6"
+#!   POSITION="6427.4542769978752 -2612.7179323841506"
+#!   BOUNDING_RECT="6427.4542769978752 -2612.7179323841506 454 71"
+#!   ORDER="500000000000015"
+#!   PARMS_EDITED="false"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="52"
+#!   TYPE="PointCloudFilter"
+#!   VERSION="2"
+#!   POSITION="4574.0705446717948 -100.02162569693064"
+#!   BOUNDING_RECT="4574.0705446717948 -100.02162569693064 454 71"
+#!   ORDER="500000000000014"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="4&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;UNFILTERED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="2"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="2" />
+#!     <XFORM_PARM PARM_NAME="FILTER_TABLE" PARM_VALUE="EXPRESSION_LIST &lt;at&gt;Component&lt;openparen&gt;mur&lt;closeparen&gt;&lt;gt&gt;3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4&lt;space&gt;-&lt;space&gt;mur"/>
+#!     <XFORM_PARM PARM_NAME="OUTPUT_UNFILTERED_POINTS" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudFilter_7"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="53"
+#!   TYPE="Inspector"
+#!   VERSION="5"
+#!   POSITION="5255.1809418109106 -168.75157360247033"
+#!   BOUNDING_RECT="5255.1809418109106 -168.75157360247033 430 71"
+#!   ORDER="500000000000016"
+#!   PARMS_EDITED="false"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <XFORM_PARM PARM_NAME="AREA_COLOR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="PEN_COLOR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="POINTCLOUD_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_NUM_COLS" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="RASTER_NUM_ROWS" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="RASTER_START_COL" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="RASTER_START_ROW" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="RASTER_VISUALIZATION_OPTION" PARM_VALUE="No Reduction"/>
+#!     <XFORM_PARM PARM_NAME="TACKATTRS" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="THINNER_INTERVAL" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="THINNER_MAX_NUM_POINTS" PARM_VALUE="&lt;Unused&gt;"/>
+#!     <XFORM_PARM PARM_NAME="THINNER_TYPE_DISPLAY" PARM_VALUE="No Thinning"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="VECTOR_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="4-mur_2"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="56"
+#!   TYPE="PointCloudCombiner"
+#!   VERSION="6"
+#!   POSITION="5227.186316457115 -1015.776028676891"
+#!   BOUNDING_RECT="5227.186316457115 -1015.776028676891 485.00106825772946 71"
+#!   ORDER="500000000000019"
+#!   PARMS_EDITED="false"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="OUTPUT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="ACCUM_ATTRS_NAME" PARM_VALUE="Yes"/>
+#!     <XFORM_PARM PARM_NAME="ATTRIBUTES_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="ATTRS_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="COUNT_ATTR" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="EXTRACT_RASTER_NODATA_NAME" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="GROUP_BY_MODE" PARM_VALUE="No"/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="MEASURES_TO_PRESERVE_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="RASTER_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="SPACING" PARM_VALUE="1.0"/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="VECTOR_PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudCombiner_2"/>
+#! </TRANSFORMER>
+#! <TRANSFORMER
+#!   IDENTIFIER="69"
+#!   TYPE="PointCloudExpressionEvaluator"
+#!   VERSION="3"
+#!   POSITION="5874.5558237727373 -1062.0727879407798"
+#!   BOUNDING_RECT="5874.5558237727373 -1062.0727879407798 669.00106825772946 71"
+#!   ORDER="500000000000019"
+#!   PARMS_EDITED="true"
+#!   ENABLED="true"
+#!   LAST_PARM_EDIT="20596"
+#! >
+#!     <OUTPUT_FEAT NAME="RESULT"/>
+#!     <FEAT_COLLAPSED COLLAPSED="0"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="0" />
+#!     <OUTPUT_FEAT NAME="&lt;REJECTED&gt;"/>
+#!     <FEAT_COLLAPSED COLLAPSED="1"/>
+#!     <XFORM_ATTR ATTR_NAME="fme_basename" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_code" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_ATTR ATTR_NAME="fme_rejection_message" IS_USER_CREATED="false" FEAT_INDEX="1" />
+#!     <XFORM_PARM PARM_NAME="EXPRESSION_TABLE" PARM_VALUE="classification Auto 3"/>
+#!     <XFORM_PARM PARM_NAME="PARAMETERS_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="TRANSFORMER_GROUP" PARM_VALUE=""/>
+#!     <XFORM_PARM PARM_NAME="XFORMER_NAME" PARM_VALUE="PointCloudExpressionEvaluator_2"/>
+#! </TRANSFORMER>
+#! </TRANSFORMERS>
+#! <FEAT_LINKS>
+#! <FEAT_LINK
+#!   IDENTIFIER="8"
+#!   SOURCE_NODE="2"
+#!   TARGET_NODE="4"
+#!   SOURCE_PORT_DESC="-1"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="9"
+#!   SOURCE_NODE="3"
+#!   TARGET_NODE="7"
+#!   SOURCE_PORT_DESC="-1"
+#!   TARGET_PORT_DESC="fi 1 Raster"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="20"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="19"
+#!   SOURCE_PORT_DESC="fo 0 Ground&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;2&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;Water&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;9&lt;lt&gt;closeparen&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 POINTS&lt;solidus&gt;LINES"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="44"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 0 Ground&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;2&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;Water&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;9&lt;lt&gt;closeparen&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="1"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="22"
+#!   SOURCE_NODE="5"
+#!   TARGET_NODE="21"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="fi 0 PointCloud"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="32"
+#!   SOURCE_NODE="7"
+#!   TARGET_NODE="31"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="23"
+#!   SOURCE_NODE="19"
+#!   TARGET_NODE="21"
+#!   SOURCE_PORT_DESC="fo 0 DEM_RASTER"
+#!   TARGET_PORT_DESC="fi 1 Raster"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="25"
+#!   SOURCE_NODE="21"
+#!   TARGET_NODE="24"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="30"
+#!   SOURCE_NODE="21"
+#!   TARGET_NODE="7"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 PointCloud"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="1"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="27"
+#!   SOURCE_NODE="24"
+#!   TARGET_NODE="26"
+#!   SOURCE_PORT_DESC="fo 0 RESULT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="36"
+#!   SOURCE_NODE="28"
+#!   TARGET_NODE="34"
+#!   SOURCE_PORT_DESC="fo 0 DEM_RASTER"
+#!   TARGET_PORT_DESC="fi 1 Raster"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="35"
+#!   SOURCE_NODE="31"
+#!   TARGET_NODE="34"
+#!   SOURCE_PORT_DESC="fo 0 4"
+#!   TARGET_PORT_DESC="fi 0 PointCloud"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="39"
+#!   SOURCE_NODE="34"
+#!   TARGET_NODE="37"
+#!   SOURCE_PORT_DESC="fo 0 PointCloud"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="54"
+#!   SOURCE_NODE="37"
+#!   TARGET_NODE="52"
+#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;out"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="57"
+#!   SOURCE_NODE="37"
+#!   TARGET_NODE="56"
+#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;out"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="1"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="58"
+#!   SOURCE_NODE="38"
+#!   TARGET_NODE="56"
+#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="68"
+#!   SOURCE_NODE="41"
+#!   TARGET_NODE="67"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="-1"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="55"
+#!   SOURCE_NODE="52"
+#!   TARGET_NODE="53"
+#!   SOURCE_PORT_DESC="fo 0 4&lt;lt&gt;space&lt;gt&gt;-&lt;lt&gt;space&lt;gt&gt;mur"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="71"
+#!   SOURCE_NODE="56"
+#!   TARGET_NODE="69"
+#!   SOURCE_PORT_DESC="fo 0 OUTPUT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="51"
+#!   SOURCE_NODE="69"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 0 RESULT"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="18"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="5"
+#!   SOURCE_PORT_DESC="fo 1 V&lt;lt&gt;u00e9&lt;gt&gt;g&lt;lt&gt;u00e9&lt;gt&gt;tation&lt;lt&gt;space&lt;gt&gt;moyenne&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;4&lt;lt&gt;closeparen&lt;gt&gt;&lt;lt&gt;space&lt;gt&gt;+&lt;lt&gt;space&lt;gt&gt;haute&lt;lt&gt;space&lt;gt&gt;&lt;lt&gt;openparen&lt;gt&gt;5&lt;lt&gt;closeparen&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="77"
+#!   SOURCE_NODE="31"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 1 5"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="79"
+#!   SOURCE_NODE="37"
+#!   TARGET_NODE="38"
+#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="42"
+#!   SOURCE_NODE="38"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 1 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="45"
+#!   SOURCE_NODE="4"
+#!   TARGET_NODE="41"
+#!   SOURCE_PORT_DESC="fo 2 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 "
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! <FEAT_LINK
+#!   IDENTIFIER="29"
+#!   SOURCE_NODE="26"
+#!   TARGET_NODE="28"
+#!   SOURCE_PORT_DESC="fo 2 &lt;lt&gt;UNFILTERED&lt;gt&gt;"
+#!   TARGET_PORT_DESC="fi 0 POINTS&lt;solidus&gt;LINES"
+#!   ENABLED="true"
+#!   EXECUTION_IDX="0"
+#!   HIDDEN="false"
+#!   COLOUR="0,0,0,1"
+#!   PEN_WIDTH="4"
+#!   PEN_STYLE="1"
+#!   LINK_STYLE_NAME="&lt;Default&gt;"
+#!   EXTRA_POINTS=""
+#! />
+#! </FEAT_LINKS>
+#! <BREAKPOINTS>
+#! </BREAKPOINTS>
+#! <ATTR_LINKS>
+#! </ATTR_LINKS>
+#! <SUBDOCUMENTS>
+#! </SUBDOCUMENTS>
+#! <LOOKUP_TABLES>
+#! </LOOKUP_TABLES>
+#! </WORKSPACE>
+
+FME_PYTHON_VERSION 37
+GUI IGNORE SourceDataset_LAS_1,LAS_IN_USE_SEARCH_ENVELOPE_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1,LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1,LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1,LAS_IN_CLIP_TO_ENVELOPE_LAS_1,LAS_IN_NETWORK_AUTHENTICATION_LAS_1,SourceDataset_GEOTIFF_1,GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1,GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1,GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1,GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1,GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1,GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1,GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1,GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1,GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1,GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1,DestDataset_LAS_2,LAS_OUT_FME_GROUP_NAMED1_LAS_2,LAS_OUT_VERSION_LAS_2,LAS_OUT_COMPRESSION_LAS_2,LAS_OUT_USER_GROUP_LAS_2,LAS_OUT_USER_COMPONENTS_LAS_2,LAS_OUT_ADVANCED_PARAMETERS_LAS_2,LAS_OUT_LAS_DATASET_FILE_LAS_2,LAS_OUT_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2,LAS_OUT_ZLAS_PARAMETERS_LAS_2,LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2,LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2
+DEFAULT_MACRO SourceDataset_LAS G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1\GT_Bel_Air_Buf20.las
+GUI MULTIFILE SourceDataset_LAS LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_files(*)|* Source ASPRS LAS File(s):
+DEFAULT_MACRO SourceDataset_GEOTIFF G:\STDL\LIDAR_2021\LIDAR_new_selection\GT_zones\Murs_THOCHB_Buff05_rast.tif
+GUI MULTIFILE SourceDataset_GEOTIFF GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|Compressed_Files(*.bz2;*.gz)|*.bz2;*.gz|Archive_Files(*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx)|*.7z;*.7zip;*.rar;*.rvz;*.tar;*.tar.bz2;*.tar.gz;*.tgz;*.zip;*.zipx|All_Files(*)|* Source GeoTIFF File(s):
+DEFAULT_MACRO DestDataset_LAS G:\STDL\LIDAR_2021\LIDAR_new_selection\LAS_GT_sectors\LAS_GT_sectors\TEST_cleaning\Test_cleaning_1
+GUI DIRNAME DestDataset_LAS Destination ASPRS LAS Folder:
+INCLUDE [ if {{$(SourceDataset_LAS)} == {}} { puts_real {Parameter 'SourceDataset_LAS' must be given a value.}; exit 1; }; ]
+INCLUDE [ if {{$(SourceDataset_GEOTIFF)} == {}} { puts_real {Parameter 'SourceDataset_GEOTIFF' must be given a value.}; exit 1; }; ]
+INCLUDE [ if {{$(DestDataset_LAS)} == {}} { puts_real {Parameter 'DestDataset_LAS' must be given a value.}; exit 1; }; ]
+#! START_HEADER
+#! START_WB_HEADER
+READER_TYPE MULTI_READER
+MULTI_READER_TYPE{0} LAS
+MULTI_READER_KEYWORD{0} LAS_1
+MULTI_READER_GEN_DIRECTIVES{0} USE_SEARCH_ENVELOPE,NO,CLIP_TO_ENVELOPE,NO,READER_META_ATTRIBUTES,fme_dataset,GROUP_BY_DATASET,No,_MERGE_SCHEMAS,YES,SEARCH_ENVELOPE_MAXX,0,SEARCH_ENVELOPE_MAXY,0,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MINY,0,LAS_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0
+MULTI_READER_TYPE{1} GEOTIFF
+MULTI_READER_KEYWORD{1} GEOTIFF_1
+MULTI_READER_GEN_DIRECTIVES{1} APPLY_GCPS,NO,SEARCH_ENVELOPE_COORDINATE_SYSTEM,,SEARCH_ENVELOPE_MAXY,0,USE_SEARCH_ENVELOPE,NO,GCP_INTERPOLATION_METHOD,NearestNeighbor,GEOTIFF_EXPOSE_FORMAT_ATTRS,,SEARCH_ENVELOPE_MINX,0,SEARCH_ENVELOPE_MAXX,0,IGNORE_RASTER_TYPE_KEY,No,FEATURE_TYPE_NAME,FORMAT_NAME,EXPOSE_ATTRS_GROUP,,SEARCH_ENVELOPE_MINY,0,_MERGE_SCHEMAS,YES,PYRAMID_LEVEL,,GEOTIFF_RDR_ADV_PARM_GROUP,,PREFER_FILE_CS_UNITS,Yes,READ_OFFSETS_IN_CS_UNITS,No,READER_META_ATTRIBUTES,fme_dataset<space>fme_basename,CLIP_TO_ENVELOPE,NO
+WRITER_TYPE MULTI_WRITER
+MULTI_WRITER_DATASET_ORDER BY_ID
+MULTI_WRITER_FIRST_WRITER_ID 0
+MULTI_WRITER_TYPE{0} LAS
+MULTI_WRITER_KEYWORD{0} LAS_2
+#! END_WB_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "LAS_1"
+#! END_WB_HEADER
+#! START_SOURCE_HEADER LAS LAS_1
+# =======================================================================
+# The following GUI line prompts for a file to be used as the source LAS file.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be read.
+# The dataset this mapping file was generated from was:
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO SourceDataset
+INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
+ puts {DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset)}     \
+ } ]
+#! END_WB_HEADER
+#! START_SOURCE_HEADER LAS LAS_1
+DEFAULT_MACRO SourceDataset_LAS_1 $(SourceDataset_LAS)
+GUI MULTIFILE SourceDataset_LAS_1 LAS_Files(*.las;*.laz;*.zlas;*.lasd)|*.las;*.laz;*.zlas;*.lasd|LAS_Files(*.las)|*.las|Compressed_LAS_Files(*.laz)|*.laz|Esri_Optimized_LAS_Files(*.zlas)|*.zlas|Esri_LAS_Dataset_Files(*.lasd)|*.lasd|All_files(*)|* Source ASPRS LAS File(s):
+DEFAULT_MACRO LAS_IN_READER_META_ATTRIBUTES_LAS_1 fme_dataset
+LAS_1_READER_META_ATTRIBUTES "$(LAS_IN_READER_META_ATTRIBUTES_LAS_1)"
+DEFAULT_MACRO LAS_IN_GROUP_BY_DATASET_LAS_1 No
+LAS_1_GROUP_BY_DATASET "$(LAS_IN_GROUP_BY_DATASET_LAS_1)"
+DEFAULT_MACRO LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1 
+LAS_1_EXPOSE_ATTRS_GROUP "$(LAS_IN_EXPOSE_ATTRS_GROUP_LAS_1)"
+# Include this file in source setting section to add external search envelope processing
+# Zero as a default means we don't do any search -- this makes workbench happier
+DEFAULT_MACRO LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 NO
+LAS_1_USE_SEARCH_ENVELOPE "$(LAS_IN_USE_SEARCH_ENVELOPE_LAS_1)"
+GUI ACTIVEDISCLOSUREGROUP LAS_IN_USE_SEARCH_ENVELOPE_LAS_1 LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1%LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1%LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1%LAS_IN_CLIP_TO_ENVELOPE_LAS_1%LAS_IN_SEARCH_METHOD%LAS_IN_SEARCH_METHOD_FILTER%LAS_IN_SEARCH_ORDER%LAS_IN_SEARCH_FEATURE%LAS_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINX_LAS_1 Minimum X:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MINY_LAS_1 Minimum Y:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXX_LAS_1 Maximum X:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 <Unused>,0 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 0
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1)"
+GUI OPTIONAL FLOAT LAS_IN_SEARCH_ENVELOPE_MAXY_LAS_1 Maximum Y:
+# ===========================================================================
+GUI LOOKUP LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 <Unused>, 
+DEFAULT_MACRO LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 
+LAS_1_SEARCH_ENVELOPE "$(LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1)"
+GUI OPTIONAL COORDSYS LAS_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_LAS_1 Search Envelope Coordinate System:
+# ===========================================================================
+# BUG18999: We now have a soft clip to fall back on like native spatial index
+# thus we are reintroducing the clip to envelop as an option for users.
+# Defualt to soft clip as per the existing database readers we are emulating
+GUI LOOKUP LAS_IN_CLIP_TO_ENVELOPE_LAS_1 <Unused>,NO 
+DEFAULT_MACRO LAS_IN_CLIP_TO_ENVELOPE_LAS_1 NO
+LAS_1_CLIP_TO_ENVELOPE "$(LAS_IN_CLIP_TO_ENVELOPE_LAS_1)"
+GUI OPTIONAL CHECKBOX LAS_IN_CLIP_TO_ENVELOPE_LAS_1 YES%NO Clip to Search Envelope
+# ===========================================================================
+DEFAULT_MACRO LAS_IN_NETWORK_AUTHENTICATION_LAS_1 
+LAS_1_NETWORK_AUTHENTICATION "$(LAS_IN_NETWORK_AUTHENTICATION_LAS_1)"
+GUI OPTIONAL AUTHENTICATOR LAS_IN_NETWORK_AUTHENTICATION_LAS_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
+# ============================================================================ 
+DEFAULT_MACRO LAS_IN_ATTRIBUTE_READING_LAS_1 ALL
+LAS_1_ATTRIBUTE_READING "$(LAS_IN_ATTRIBUTE_READING_LAS_1)"
+# ============================================================================ 
+LAS_1_GENERATE_FME_BUILD_NUM 20596
+LAS_1_DATASET "$(SourceDataset_LAS_1)"
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "GEOTIFF_1"
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
+# =======================================================================
+# The following GUI line prompts for a file to be used as the source GEOTIFF file.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be read.
+# The dataset this mapping file was generated from was:
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO SourceDataset
+INCLUDE [ if {{$(SourceDataset)} != ""} {                        \
+ puts {DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset)}     \
+ } ]
+#! END_WB_HEADER
+#! START_SOURCE_HEADER GEOTIFF GEOTIFF_1
+DEFAULT_MACRO SourceDataset_GEOTIFF_1 $(SourceDataset_GEOTIFF)
+GUI MULTIFILE SourceDataset_GEOTIFF_1 GeoTIFF_Files(*.tif;*.tiff;*.itiff;*.ovr)|*.tif;*.tiff;*.itiff;*.ovr|All_Files(*)|* Source GeoTIFF File(s):
+DEFAULT_MACRO GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1 fme_dataset fme_basename
+GEOTIFF_1_READER_META_ATTRIBUTES "$(GEOTIFF_IN_READER_META_ATTRIBUTES_GEOTIFF_1)"
+DEFAULT_MACRO GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1 FORMAT_NAME
+GEOTIFF_1_FEATURE_TYPE_NAME "$(GEOTIFF_IN_FEATURE_TYPE_NAME_GEOTIFF_1)"
+DEFAULT_MACRO GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 NO
+GEOTIFF_1_APPLY_GCPS "$(GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_APPLY_GCPS_GEOTIFF_1 GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Apply GCP's
+DEFAULT_MACRO GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 NearestNeighbor
+GEOTIFF_1_GCP_INTERPOLATION_METHOD "$(GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1)"
+GUI LOOKUP_CHOICE GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 Nearest<space>Neighbor,NearestNeighbor%Bilinear,Bilinear%Bicubic,Bicubic GCP Interpolation Method
+GUI LOOKUP GEOTIFF_IN_GCP_INTERPOLATION_METHOD_GEOTIFF_1 <Unused>,NearestNeighbor 
+DEFAULT_MACRO GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1 
+GEOTIFF_1_EXPOSE_ATTRS_GROUP "$(GEOTIFF_IN_EXPOSE_ATTRS_GROUP_GEOTIFF_1)"
+# Include this file in source setting section to add external search envelope processing
+# Zero as a default means we don't do any search -- this makes workbench happier
+DEFAULT_MACRO GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 NO
+GEOTIFF_1_USE_SEARCH_ENVELOPE "$(GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1)"
+GUI ACTIVEDISCLOSUREGROUP GEOTIFF_IN_USE_SEARCH_ENVELOPE_GEOTIFF_1 GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1%GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1%GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1%GEOTIFF_IN_SEARCH_METHOD%GEOTIFF_IN_SEARCH_METHOD_FILTER%GEOTIFF_IN_SEARCH_ORDER%GEOTIFF_IN_SEARCH_FEATURE%GEOTIFF_IN_DUMMY_SEARCH_ENVELOPE_PARAMETER Use Search Envelope
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINX_GEOTIFF_1 Minimum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MINY_GEOTIFF_1 Minimum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXX_GEOTIFF_1 Maximum X:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 <Unused>,0 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 0
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1)"
+GUI OPTIONAL FLOAT GEOTIFF_IN_SEARCH_ENVELOPE_MAXY_GEOTIFF_1 Maximum Y:
+# ===========================================================================
+GUI LOOKUP GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 <Unused>, 
+DEFAULT_MACRO GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 
+GEOTIFF_1_SEARCH_ENVELOPE "$(GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1)"
+GUI OPTIONAL COORDSYS GEOTIFF_IN_SEARCH_ENVELOPE_COORDINATE_SYSTEM_GEOTIFF_1 Search Envelope Coordinate System:
+# ===========================================================================
+# BUG18999: We now have a soft clip to fall back on like native spatial index
+# thus we are reintroducing the clip to envelop as an option for users.
+# Defualt to soft clip as per the existing database readers we are emulating
+GUI LOOKUP GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 <Unused>,NO 
+DEFAULT_MACRO GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 NO
+GEOTIFF_1_CLIP_TO_ENVELOPE "$(GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1)"
+GUI OPTIONAL CHECKBOX GEOTIFF_IN_CLIP_TO_ENVELOPE_GEOTIFF_1 YES%NO Clip to Search Envelope
+DEFAULT_MACRO GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 
+GUI OPTIONAL DISCLOSUREGROUP GEOTIFF_IN_GEOTIFF_RDR_ADV_PARM_GROUP_GEOTIFF_1 GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1%GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1%GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Advanced
+DEFAULT_MACRO GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 
+GEOTIFF_1_PYRAMID_LEVEL "$(GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1)"
+GUI OPTIONAL INTEGER GEOTIFF_IN_PYRAMID_LEVEL_GEOTIFF_1 Pyramid Level to Read:
+DEFAULT_MACRO GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes
+GEOTIFF_1_PREFER_FILE_CS_UNITS "$(GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_PREFER_FILE_CS_UNITS_GEOTIFF_1 Yes%No Prefer File Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 No
+GEOTIFF_1_READ_OFFSETS_IN_CS_UNITS "$(GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_READ_OFFSETS_IN_CS_UNITS_GEOTIFF_1 Yes%No Offsets in Coordinate System Units:
+DEFAULT_MACRO GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 No
+GEOTIFF_1_IGNORE_RASTER_TYPE_KEY "$(GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1)"
+GUI CHOICE GEOTIFF_IN_IGNORE_RASTER_TYPE_KEY_GEOTIFF_1 Yes%No Ignore Raster Type Key:
+# ===========================================================================
+DEFAULT_MACRO GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 
+GEOTIFF_1_NETWORK_AUTHENTICATION "$(GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1)"
+GUI OPTIONAL AUTHENTICATOR GEOTIFF_IN_NETWORK_AUTHENTICATION_GEOTIFF_1 CONTAINER%GROUP%CONTAINER_TITLE%"Network Authentication"%PROMPT_TYPE%NETWORK Network Authentication
+# ============================================================================ 
+DEFAULT_MACRO GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1 ALL
+GEOTIFF_1_ATTRIBUTE_READING "$(GEOTIFF_IN_ATTRIBUTE_READING_GEOTIFF_1)"
+# ============================================================================ 
+GEOTIFF_1_GENERATE_FME_BUILD_NUM 20596
+GEOTIFF_1_DATASET "$(SourceDataset_GEOTIFF_1)"
+#! END_SOURCE_HEADER
+#! START_WB_HEADER
+MACRO WB_KEYWORD "LAS_2"
+#! END_WB_HEADER
+#! START_DEST_HEADER LAS LAS_2
+# The following GUI lines prompt for a LAS file to be used as the
+# the destination of the data.
+# The user input is stored in a macro, which is then used to define
+# the dataset to be written.
+#! END_DEST_HEADER
+#! START_WB_HEADER
+DEFAULT_MACRO DestDataset
+INCLUDE [ if {"$(DestDataset)" != ""} {                          \
+ puts {DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset)}         \
+ } ]
+#! END_WB_HEADER
+#! START_DEST_HEADER LAS LAS_2
+DEFAULT_MACRO DestDataset_LAS_2 $(DestDataset_LAS)
+GUI DIRNAME DestDataset_LAS_2 Destination ASPRS LAS Folder:
+DEFAULT_MACRO LAS_OUT_FME_GROUP_NAMED1_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_FME_GROUP_NAMED1_LAS_2 LAS_OUT_VERSION_LAS_2%LAS_OUT_COMPRESSION_LAS_2 Parameters
+# ============================================================================
+# Version
+DEFAULT_MACRO LAS_OUT_VERSION_LAS_2 1.2
+LAS_2_VERSION "$(LAS_OUT_VERSION_LAS_2)"
+GUI LOOKUP_CHOICE LAS_OUT_VERSION_LAS_2 1.0,1.0%1.1,1.1%1.2,1.2%1.3,1.3%"\"1.4 (Legacy Compatible)\",1.4-legacy-compatible"%1.4,1.4 ASPRS LAS Version:
+# [PR#30472] Compression
+DEFAULT_MACRO LAS_OUT_COMPRESSION_LAS_2 None
+LAS_2_COMPRESSION "$(LAS_OUT_COMPRESSION_LAS_2)"
+GUI ACTIVECHOICE LAS_OUT_COMPRESSION_LAS_2 None,LAS_OUT_ZLAS_PARAMETERS_LAS_2%LAZ,LAS_OUT_ZLAS_PARAMETERS_LAS_2%zLAS Compression
+# This is a placeholder parameter that will be replaced with a custom table in the controller
+DEFAULT_MACRO LAS_OUT_USER_GROUP_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_USER_GROUP_LAS_2 LAS_OUT_USER_COMPONENTS_LAS_2 Additional User Components
+DEFAULT_MACRO LAS_OUT_USER_COMPONENTS_LAS_2 
+LAS_2_USER_COMPONENTS "$(LAS_OUT_USER_COMPONENTS_LAS_2)"
+GUI OPTIONAL GUI_LINE_TABLE_ENCODED LAS_OUT_USER_COMPONENTS_LAS_2 NO_LABEL%ROW_DELIM:,%COL_DELIM:,%"User Components"%"STRING COMPONENTS" User Components
+# ============================================================================
+# Opt in for destination dataset type vs format type validation
+DEFAULT_MACRO LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2 Yes
+LAS_2_DESTINATION_DATASETTYPE_VALIDATION "$(LAS_OUT_DESTINATION_DATASETTYPE_VALIDATION_LAS_2)"
+DEFAULT_MACRO LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2 FEATURE
+LAS_2_COORDINATE_SYSTEM_GRANULARITY "$(LAS_OUT_COORDINATE_SYSTEM_GRANULARITY_LAS_2)"
+DEFAULT_MACRO LAS_OUT_ADVANCED_PARAMETERS_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ADVANCED_PARAMETERS_LAS_2 LAS_OUT_LAS_DATASET_FILE_LAS_2%LAS_OUT_ZLAS_PARAMETERS_LAS_2 Advanced
+DEFAULT_MACRO LAS_OUT_LAS_DATASET_FILE_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_LAS_DATASET_FILE_LAS_2 LAS_OUT_ARCGIS_LAS_DATASET_LAS_2%LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 LAS Dataset File
+# The following GUI line provides the ability to create an
+# Esri ArcGIS LAS Dataset encapsulating the LAS files produced
+# by this translation. The LAS Dataset can then be used to view
+# the output using Esri's tools.
+DEFAULT_MACRO LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 
+LAS_2_ARCGIS_LAS_DATASET "$(LAS_OUT_ARCGIS_LAS_DATASET_LAS_2)"
+GUI OPTIONAL TEXT LAS_OUT_ARCGIS_LAS_DATASET_LAS_2 ArcGIS LAS Dataset (.lasd) Filename
+# The following GUI line determines whether statistics should
+# be calculated on the ArcGIS LAS Dataset. This keyword is
+# applicable when FME is creating an ArcGIS LAS Dataset.
+DEFAULT_MACRO LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 No
+LAS_2_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET "$(LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2)"
+GUI CHOICE LAS_OUT_COMPUTE_STATISTICS_ON_ARCGIS_LAS_DATASET_LAS_2 Yes%No Compute Statistics on ArcGIS LAS Dataset
+DEFAULT_MACRO LAS_OUT_ZLAS_PARAMETERS_LAS_2 
+GUI OPTIONAL DISCLOSUREGROUP LAS_OUT_ZLAS_PARAMETERS_LAS_2 LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2%LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Parameters
+DEFAULT_MACRO LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 <Unused>
+LAS_2_ZLAS_REARRANGE_POINTS "$(LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2)"
+GUI CHOICE LAS_OUT_ZLAS_REARRANGE_POINTS_LAS_2 Yes%No Rearrange Points for zLAS Compression
+DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 <Unused>
+LAS_2_ZLAS_POINT_SPACING_SOURCE "$(LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2)"
+GUI LOOKUP_CHOICE LAS_OUT_ZLAS_POINT_SPACING_SOURCE_LAS_2 "\"Scan Points\",scan"%"\"From Header\",header"%"\"Specify Value\",specify" zLAS Point Spacing Source
+DEFAULT_MACRO LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 <Unused>
+LAS_2_ZLAS_POINT_SPACING_VALUE "$(LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2)"
+GUI FLOAT LAS_OUT_ZLAS_POINT_SPACING_VALUE_LAS_2 zLAS Point Spacing Value
+# ============================================================================ 
+LAS_2_GENERATE_FME_BUILD_NUM 20596
+LAS_2_DATASET "$(DestDataset_LAS_2)"
+#! END_DEST_HEADER
+#! START_WB_HEADER
+#! END_WB_HEADER
+#! END_HEADER
+
+LOG_FILTER_MASK -1
+LOG_MAX_FEATURES 200
+LOG_MAX_RECORDED_FEATURES 200
+FME_REPROJECTION_ENGINE FME
+FME_IMPLICIT_CSMAP_REPROJECTION_MODE Auto
+FME_GEOMETRY_HANDLING Enhanced
+FME_STROKE_MAX_DEVIATION 0
+DEFAULT_MACRO DATASET_KEYWORD_LAS_1 LAS_1
+DEFAULT_MACRO DATASET_KEYWORD_GEOTIFF_1 GEOTIFF_1
+DEFAULT_MACRO DATASET_KEYWORD_LAS_2 LAS_2
+# -------------------------------------------------------------------------
+
+LAS_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
+
+# -------------------------------------------------------------------------
+
+GEOTIFF_1_READER_META_ATTRIBUTES fme_feature_type fme_basename
+
+# -------------------------------------------------------------------------
+
+MULTI_READER_CONTINUE_ON_READER_FAILURE No
+
+# -------------------------------------------------------------------------
+
+MACRO WORKSPACE_NAME LAS_Pretraitement_2021_cleaning_MNHC
+MACRO FME_VIEWER_APP fmedatainspector
+# -------------------------------------------------------------------------
+
+INCLUDE [ if {[info exists env(FME_TEMP)] && [file isdirectory $env(FME_TEMP)]} {set gVisualizerTemp $env(FME_TEMP)}  elseif {[info exists env(TEMP)] && [file isdirectory $env(TEMP)]}  {set gVisualizerTemp $env(TEMP)}  elseif { $tcl_platform(platform) == "unix" } {set gVisualizerTemp "/tmp"} else {set gVisualizerTemp c:};  regsub -all {[ ,&]} {$(WORKSPACE_NAME)} {_} wsname; set gVisualizerTemp $gVisualizerTemp/${wsname}_[clock format [clock seconds] -format %H%M%S];  puts "MACRO WORKSPACE_TEMP_DIR $gVisualizerTemp"; 
+MACRO VISUALIZER_FEATURE_FILE $(WORKSPACE_TEMP_DIR)/inspector.ffs
+MACRO VISUALIZER_SCHEMA_FILE $(WORKSPACE_TEMP_DIR)/inspector.fsc
+MACRO VISUALIZER_CREATE_SPATIAL_INDEX YES
+# -------------------------------------------------------------------------
+LAS_1_DEF LAS
+# -------------------------------------------------------------------------
+GEOTIFF_1_DEF GEOTIFF
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * RoutingFactory   FACTORY_NAME "Router and Unexpected Input Remover"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE LAS LAS_1::LAS multi_reader_keyword,$(DATASET_KEYWORD_LAS_1) TO FME_GENERIC ::LAS ALIAS_GEOMETRY    ROUTE GEOTIFF GEOTIFF_1::GEOTIFF multi_reader_keyword,$(DATASET_KEYWORD_GEOTIFF_1) TO FME_GENERIC ::GEOTIFF ALIAS_GEOMETRY    MERGE_INPUT Yes   OUTPUT ROUTED FEATURE_TYPE *
+LAS_1_MERGE_DEF LAS_1::LAS EXACT LAS
+GEOTIFF_1_MERGE_DEF GEOTIFF_1::GEOTIFF EXACT GEOTIFF
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory    FACTORY_NAME "LAS_LAS_1 Splitter"    INPUT FEATURE_TYPE LAS    OUTPUT FEATURE_TYPE LAS_LAS_1
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory    FACTORY_NAME "GEOTIFF_GEOTIFF_1 Splitter"    INPUT FEATURE_TYPE GEOTIFF    OUTPUT FEATURE_TYPE GEOTIFF_GEOTIFF_1
+DEFAULT_MACRO WB_CURRENT_CONTEXT
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter    INPUT  FEATURE_TYPE LAS_LAS_1    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==2<space>||<space><at>Component<openparen>classification<closeparen>==9 ; <at>Component<openparen>classification<closeparen>==4<space>||<space><at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> ; V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_2
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen> Splitter"   INPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>   OUTPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_0_iQyPhi3mnFo=   OUTPUT FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_1_WXAwGkpiE4A=
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * TeeFactory    FACTORY_NAME PointCloudComponentAdder    INPUT  FEATURE_TYPE PointCloudFilter_V<u00e9>g<u00e9>tation<space>moyenne<space><openparen>4<closeparen><space>+<space>haute<space><openparen>5<closeparen>    OUTPUT FEATURE_TYPE ___TOREJECTOR___       @RenameAttributes(FME_STRICT,___fme_rejection_code___,fme_rejection_code)       @AddPointCloudComponents(REJECTABLE,z_ground,Real64,0,z_max,Real64,0,mur,Real64,0)
+FACTORY_DEF * TestFactory    FACTORY_NAME PointCloudComponentAdder_Rejector    INPUT FEATURE_TYPE ___TOREJECTOR___    TEST @Value(fme_rejection_code) != ""    OUTPUT PASSED FEATURE_TYPE PointCloudComponentAdder_<REJECTED>       @RemoveAttributes(___fme_rejection_code___)    OUTPUT FAILED FEATURE_TYPE PointCloudComponentAdder_OUTPUT       @RenameAttributes(FME_STRICT,fme_rejection_code,___fme_rejection_code___)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudComponentAdder_<Rejected> INPUT FEATURE_TYPE PointCloudComponentAdder_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudComponentAdder<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} SurfaceModelFactory    FACTORY_NAME RasterDEMGenerator    FLUSH_WHEN_GROUPS_CHANGE No    INPUT POINTS FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_0_iQyPhi3mnFo=    TOLERANCE 0.1    SAMPLE_SPACING 0.4 0.4    INTERPOLATION_TYPE AUTO    NODATA_VALUE -32767.0    REJECT_INVALID_GEOM YES    OUTPUT DEM_RASTER FEATURE_TYPE RasterDEMGenerator_DEM_RASTER        @SupplyAttributes(?,fme_basename,RasterDEMGenerator)    OUTPUT REJECTED FEATURE_TYPE RasterDEMGenerator_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME RasterDEMGenerator_<Rejected> INPUT FEATURE_TYPE RasterDEMGenerator_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, RasterDEMGenerator<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_2_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|z_ground|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_2_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
+FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_2    INPUT  FEATURE_TYPE PointCloudComponentAdder_OUTPUT    INPUT  FEATURE_TYPE RasterDEMGenerator_DEM_RASTER    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_2_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_2_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_2_<REJECTED>
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudOnRasterComponentSetter_2 PointCloud Splitter"   INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud   OUTPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_0_Cp3PFkJGvQM=   OUTPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_1_pOvQ2H97RY4=
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_2_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|mur|$(SourceDataset_GEOTIFF)} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
+FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_1_pOvQ2H97RY4=    INPUT  FEATURE_TYPE GEOTIFF_GEOTIFF_1    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_4    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>classification<closeparen>==4 ; <at>Component<openparen>classification<closeparen>==5 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4 ; 5    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_4_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_4    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_4_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = 5 OUTPUT PASSED FEATURE_TYPE PointCloudFilter_4_5    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_4_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_4 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_4_<UNFILTERED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_4_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_4_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_4<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+DEFAULT_MACRO PointCloudExpressionEvaluator_COMPONENT_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_COMPONENT_TYPE_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_EXPRESSION_LIST
+INCLUDE [    foreach {component componenttype expression} [split {z Real32 @EvaluateExpression(FDIV,STRING_ENCODED,<at>Component<openparen>z<closeparen>-<at>Component<openparen>z_ground<closeparen>,PointCloudExpressionEvaluator)}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_2_PointCloud_0_Cp3PFkJGvQM=    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_3    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_RESULT    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>z<closeparen><lt>0 ; <at>Component<openparen>z<closeparen><gt>50 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST Negative<space>points ; Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_3_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_3_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = Negative<space>points OUTPUT PASSED FEATURE_TYPE PointCloudFilter_3_Negative<space>points    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_3_TestFactory_1 INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_1 STRING_TEST @Value(__pc_internal_filter_attribute__) = Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen> OUTPUT PASSED FEATURE_TYPE PointCloudFilter_3_Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_2
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_3_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_3_POINTCLOUDFILTERINPUTLINE_2 OUTPUT FEATURE_TYPE PointCloudFilter_3_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_3 Negative<space>points Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_3_Negative<space>points
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_3 Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_3_Aberrant<space>height<space>points<space><openparen>higher<space>than<space>50m<closeparen>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_3_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} SurfaceModelFactory    FACTORY_NAME RasterDEMGenerator_2    FLUSH_WHEN_GROUPS_CHANGE No    INPUT POINTS FEATURE_TYPE PointCloudFilter_3_<UNFILTERED>    TOLERANCE 0.1    SAMPLE_SPACING 0.4 0.4    INTERPOLATION_TYPE AUTO    NODATA_VALUE -32767.0    REJECT_INVALID_GEOM YES    OUTPUT DEM_RASTER FEATURE_TYPE RasterDEMGenerator_2_DEM_RASTER        @SupplyAttributes(?,fme_basename,RasterDEMGenerator_2)    OUTPUT REJECTED FEATURE_TYPE RasterDEMGenerator_2_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME RasterDEMGenerator_2_<Rejected> INPUT FEATURE_TYPE RasterDEMGenerator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, RasterDEMGenerator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+INCLUDE [ if {[string equal {CUSTOM} {COLOR}]} {    puts {MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST color_red,color_green,color_blue};    puts {MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST}; } else {    foreach {band component default} [split {0|z_max|0} |] {       lappend componentList "$component";       lappend defaultList "$default";    };    puts "MACRO PointCloudOnRasterComponentSetter_3_COMPONENT_LIST \"[join $componentList ,]\"";    puts "MACRO PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST \"[join $defaultList ,]\""; }; ]
+FACTORY_DEF {*} RasterToPointCloudComponentFactory    FACTORY_NAME PointCloudOnRasterComponentSetter_3    INPUT  FEATURE_TYPE PointCloudFilter_4_4    INPUT  FEATURE_TYPE RasterDEMGenerator_2_DEM_RASTER    FLUSH_WHEN_GROUPS_CHANGE No    COMPONENT_LIST $(PointCloudOnRasterComponentSetter_3_COMPONENT_LIST)    DEFAULT_VALUE $(PointCloudOnRasterComponentSetter_3_DEFAULT_VALUE_LIST)    INTERPOLATION_TYPE_NAME NearestNeighbor    EXTRACT_NODATA No    DEFAULT_VALUES_OVERWRITE_DATA No    REJECT_INVALID_FEATURES YES    OUTPUT POINTCLOUD FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    OUTPUT <REJECTED> FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudOnRasterComponentSetter_3_<Rejected> INPUT FEATURE_TYPE PointCloudOnRasterComponentSetter_3_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudOnRasterComponentSetter_3<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_5    INPUT  FEATURE_TYPE PointCloudOnRasterComponentSetter_3_PointCloud    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>z_max<closeparen><lt>=3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>out    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_5_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_5_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>out OUTPUT PASSED FEATURE_TYPE PointCloudFilter_5_4<space>out    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_5_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_5 4<space>out Splitter"   INPUT FEATURE_TYPE PointCloudFilter_5_4<space>out   OUTPUT FEATURE_TYPE PointCloudFilter_5_4<space>out_0_MZflbMncRTk=   OUTPUT FEATURE_TYPE PointCloudFilter_5_4<space>out_1_8onCNNziEwg=
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_5_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_5_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_5<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_6    INPUT  FEATURE_TYPE PointCloudFilter_5_<UNFILTERED>    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_6_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_6_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_6_4<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_6_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_6_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_6_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_6<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner_2___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_5_4<space>out_1_8onCNNziEwg=    INPUT  FEATURE_TYPE PointCloudFilter_6_4<space>-<space>mur    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner_2)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
+FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner_2___Combiner    INPUT FEATURE_TYPE PointCloudCombiner_2___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_2_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_2_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_2_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST
+DEFAULT_MACRO PointCloudExpressionEvaluator_2_EXPRESSION_LIST
+INCLUDE [    foreach {component componenttype expression} [split {classification Auto 3}] {       lappend lists(COMPONENT) $component;       lappend lists(COMPONENT_TYPE) $componenttype;       if [regexp {@EvaluateExpression\(STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } elseif [regexp {@EvaluateExpression\(FDIV,STRING_ENCODED,(.*),.+\)} $expression -> unwrapped] {          lappend lists(EXPRESSION) $unwrapped;       } else {          lappend lists(EXPRESSION) $expression;       };    };    foreach {listName} [array names lists] {       puts "MACRO PointCloudExpressionEvaluator_2_${listName}_LIST \"[join $lists($listName) {;}]\"";    }; ]
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudExpressionEvaluator_2    INPUT  FEATURE_TYPE PointCloudCombiner_2_OUTPUT    MODE SET_COMPONENT_VALUES    COMPONENT_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_LIST)    COMPONENT_TYPE_LIST $(PointCloudExpressionEvaluator_2_COMPONENT_TYPE_LIST)    EXPRESSION_LIST $(PointCloudExpressionEvaluator_2_EXPRESSION_LIST)    FORCE_FLOAT_DIVISION yes    REJECT_INVALID_FEATURES YES    OUTPUT RESULT FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudExpressionEvaluator_2_<Rejected> INPUT FEATURE_TYPE PointCloudExpressionEvaluator_2_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudExpressionEvaluator_2<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF {*} VectorToPointCloudFactory    FACTORY_NAME PointCloudCombiner___VectorMerger    INPUT  FEATURE_TYPE PointCloudFilter_Ground<space><openparen>2<closeparen><space>+<space>Water<space><openparen>9<closeparen>_1_WXAwGkpiE4A=    INPUT  FEATURE_TYPE PointCloudExpressionEvaluator_2_RESULT    INPUT  FEATURE_TYPE PointCloudFilter_4_5    INPUT  FEATURE_TYPE PointCloudFilter_6_<UNFILTERED>    INPUT  FEATURE_TYPE PointCloudFilter_<UNFILTERED>    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    EXTRACT_RASTER_NODATA no    SPACING "1.0"    MEASURES_TO_PRESERVE    ATTRIBUTES_TO_PRESERVE    REJECT_INVALID_FEATURES yes    OUTPUT COERCED FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__       @SupplyAttributes(?,fme_basename,PointCloudCombiner)    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
+FACTORY_DEF {*} PointCloudCombinerFactory    FACTORY_NAME PointCloudCombiner___Combiner    INPUT FEATURE_TYPE PointCloudCombiner___MergedVectorFeatures__    FLUSH_WHEN_GROUPS_CHANGE No    ACCUMULATE_ATTRIBUTES yes    REJECT_INVALID_FEATURES yes    OUTPUT MERGED FEATURE_TYPE PointCloudCombiner_OUTPUT    OUTPUT <REJECTED> FEATURE_TYPE PointCloudCombiner_<REJECTED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudCombiner_<Rejected> INPUT FEATURE_TYPE PointCloudCombiner_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudCombiner<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+FACTORY_DEF * PointCloudEvaluationFactory    FACTORY_NAME PointCloudFilter_7    INPUT  FEATURE_TYPE PointCloudFilter_5_4<space>out_0_MZflbMncRTk=    MODE FILTER    REJECT_INVALID_FEATURES YES    FORCE_FLOAT_DIVISION yes    EXPRESSION_LIST <at>Component<openparen>mur<closeparen><gt>3 FILTER_ATTRIBUTE __pc_internal_filter_attribute__ FILTER_ATTRIBUTE_VALUES_LIST 4<space>-<space>mur    OUTPUT_UNFILTERED_POINTS "Yes"    OUTPUT RESULT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_0    OUTPUT <REJECTED> FEATURE_TYPE PointCloudFilter_7_<REJECTED>
+FACTORY_DEF * TestFactory FACTORY_NAME PointCloudFilter_7_TestFactory_0 INPUT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_0 STRING_TEST @Value(__pc_internal_filter_attribute__) = 4<space>-<space>mur OUTPUT PASSED FEATURE_TYPE PointCloudFilter_7_4<space>-<space>mur    @RemoveAttributes(__pc_internal_filter_attribute__) OUTPUT FAILED FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_1
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_7_UNFILTERED INPUT FEATURE_TYPE PointCloudFilter_7_POINTCLOUDFILTERINPUTLINE_1 OUTPUT FEATURE_TYPE PointCloudFilter_7_<UNFILTERED>    @RemoveAttributes(__pc_internal_filter_attribute__)
+FACTORY_DEF * TeeFactory   FACTORY_NAME "PointCloudFilter_7 <UNFILTERED> Transformer Output Nuker"   INPUT FEATURE_TYPE PointCloudFilter_7_<UNFILTERED>
+DEFAULT_MACRO _WB_BYPASS_TERMINATION No
+FACTORY_DEF * TeeFactory FACTORY_NAME PointCloudFilter_7_<Rejected> INPUT FEATURE_TYPE PointCloudFilter_7_<REJECTED>  OUTPUT FAILED FEATURE_TYPE * @Abort(ENCODED, PointCloudFilter_7<space>output<space>a<space><lt>Rejected<gt><space>feature.<space><space>To<space>continue<space>translation<space>when<space>features<space>are<space>rejected<comma><space>change<space><apos>Workspace<space>Parameters<apos><space><gt><space>Translation<space><gt><space><apos>Rejected<space>Feature<space>Handling<apos><space>to<space><apos>Continue<space>Translation<apos>)
+# -------------------------------------------------------------------------
+# Assumption is that the workspace temp dir has been already set and created.  See controldefs.cpp - ControlDefs::writeVisualizerTempDir
+DEFAULT_MACRO WORKSPACE_TEMP_DIR
+INCLUDE [    set safeName "[regsub -all {[^a-zA-Z0-9]} {4-mur_2} _]_[expr round(rand() * 1000000)]_[clock clicks  -milliseconds]";    puts "MACRO SAFE_FFS_NAME $safeName"; ]
+FACTORY_DEF {*} InspectorFactory    FACTORY_NAME 4-mur_2_Prepper    COMMAND_PARM_EVALUATION SINGLE_PASS    INPUT  FEATURE_TYPE PointCloudFilter_7_4<space>-<space>mur    GROUP_ATTRIBUTE __inspector_feature_type_attr__    GROUP_BY {  }    GROUP_ATTRIBUTE_PREFIX { 4-mur_2 }    RASTER_REDUCTION NoReduction    POINT_CLOUD_REDUCTION NO_THINNING    OUTPUT RESULT FEATURE_TYPE __viewme__
+# Now route all the features into the recorder, changing their
+# feature type to the transformer name so that they view nicely
+DEFAULT_MACRO VISUALIZER_FEATURE_FILE $(WORKSPACE_TEMP_DIR)/$(SAFE_FFS_NAME).ffs
+DEFAULT_MACRO VISUALIZER_CREATE_SPATIAL_INDEX NO
+# [PR#45549] The Data Inspector will limit the maximum number of features
+# it reads on WIN32, so we will correspondingly limit the number of
+# features we record here using the MAX_FEATURES_TO_RECORD directive.
+FACTORY_DEF * RecorderFactory    FACTORY_NAME 4-mur_2_Recorder    COMMAND_PARM_EVALUATION SINGLE_PASS    INPUT FEATURE_TYPE __viewme__       _wb_termination_feature Yes       @FeatureType(TERMINATOR_@Value(_wb_termination_xformer))    INPUT FEATURE_TYPE __viewme__       @FeatureType(@Value(__inspector_feature_type_attr__))       @RemoveAttributes(__inspector_feature_type_attr__)    FEATURE_FILE "$(VISUALIZER_FEATURE_FILE)"    STORE_SCANNED_SCHEMA YES    NORMALIZE_LIST_ATTRIBUTES_ON_SCHEMA YES    CREATE_SPATIAL_INDEX "$(VISUALIZER_CREATE_SPATIAL_INDEX)"    INSPECTOR "$(VISUALIZER_CREATE_SPATIAL_INDEX)"    FSC_SCHEMA fme_basename,varchar<openparen>50<closeparen>    MODE RECORD    STORE_SCANNED_METADATA    RECORD_DIRECTLY_TO_DISK YES    MAX_FEATURES_TO_RECORD WIN32 2000000
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * RoutingFactory FACTORY_NAME "Destination Feature Type Routing Correlator"   COMMAND_PARM_EVALUATION SINGLE_PASS   INPUT FEATURE_TYPE *    ROUTE FME_GENERIC PointCloudCombiner_OUTPUT TO LAS __GO_TO_FINAL_OUTPUT_ROUTER__ multi_writer_id,0,<at>SupplyAttributes<openparen>ENCODED<comma>fme_template_feature_type<comma>LAS01<closeparen>,<at>EvaluateExpression<openparen>ATTR_CREATE_EXPR<comma>__wb_out_feat_type__<comma><lt>at<gt>Value<lt>openparen<gt>fme_basename<lt>closeparen<gt>_CLEAN<comma>LAS01<closeparen> GEOMETRY   FEATURE_TYPE_ATTRIBUTE __wb_out_feat_type__   OUTPUT ROUTED FEATURE_TYPE *    OUTPUT NOT_ROUTED FEATURE_TYPE __nuke_me__ @Tcl2("FME_StatMessage 818059 [FME_GetAttribute fme_template_feature_type] 818060 818061 fme_warn")
+# -------------------------------------------------------------------------
+
+FACTORY_DEF * TeeFactory   FACTORY_NAME "Final Output Nuker"   INPUT FEATURE_TYPE __nuke_me__
+
+# -------------------------------------------------------------------------
+
+DEFAULT_MACRO FME_LAUNCH_VIEWER_APP NO
+FACTORY_DEF * CreationFactory    FACTORY_NAME VisualizerProcessor   CREATE_AT_END   OUTPUT FEATURE_TYPE __NUKEME__   @TCL("if {{$(FME_LAUNCH_VIEWER_APP)} == {YES}} {  if [file exists {$(WORKSPACE_TEMP_DIR)}] {set files [glob -nocomplain -directory  {$(WORKSPACE_TEMP_DIR)} -tails *.ffs];   if {[llength $files] == 1} {    set theFile {$(WORKSPACE_TEMP_DIR)/};   append theFile [lindex $files 0];   eval FME_Execute System \173\042$(FME_HOME_UNIX)/fmedatainspector\042 --visualizer --single-application --delete-on-close --no-source-prompt -f FFS \042$theFile\042 & \175;  } elseif { [llength $files] == 0 } {  catch { file delete -force {$(WORKSPACE_TEMP_DIR)} };  } else {  set filesNoExt {}; set lastfile {}; foreach {fileName} [lsort $files] { set fileNoExt [string trimright $fileName {.ffs}]; if [regexp {(.*)_[0-9]*$} $fileNoExt wholething fileNoExtBase] {  if { $fileNoExtBase == $lastfile } { continue } }; set lastfile $fileNoExt; lappend filesNoExt $fileNoExt };  eval FME_Execute System \173\042$(FME_HOME_UNIX)/fmedatainspector\042 --visualizer --single-application --delete-on-close --no-source-prompt -d {$(WORKSPACE_TEMP_DIR)} -a ffs -f FFS $filesNoExt & \175; }; }; }; ")
+FACTORY_DEF * TeeFactory    FACTORY_NAME VisualizerCleaner   INPUT FEATURE_TYPE __NUKEME__
+# -------------------------------------------------------------------------
+LAS_2_DEF LAS01
diff --git a/TASK-4RAS/image/description b/TASK-4RAS/image/description
index 2db40a0..9bde5eb 100644
--- a/TASK-4RAS/image/description
+++ b/TASK-4RAS/image/description
@@ -1 +1 @@
-mixed-models.jpg : illustration of mixed models in the 4D plateform (LIADR, INTERLIS, Mesh)
+mixed-models.jpg : illustration of mixed models in the 4D plateform (LIADR, INTERLIS, Mesh)
diff --git a/TASK-DIFF/image/asymetric-illustration.svg b/TASK-DIFF/image/asymetric-illustration.svg
index 41c8a12..c58cac4 100644
--- a/TASK-DIFF/image/asymetric-illustration.svg
+++ b/TASK-DIFF/image/asymetric-illustration.svg
@@ -1,709 +1,709 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
-<svg
-   xmlns:dc="http://purl.org/dc/elements/1.1/"
-   xmlns:cc="http://creativecommons.org/ns#"
-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-   xmlns:svg="http://www.w3.org/2000/svg"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   width="89mm"
-   height="43mm"
-   viewBox="0 0 89 43"
-   version="1.1"
-   id="svg8"
-   inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)"
-   sodipodi:docname="asymetric-illustration.svg"
-   inkscape:export-filename="/media/user/head_loop1/loop_405e-5f-dc22/405e-5f-dc22_hades/hades_kronos/kronos_b57b-23-6c9b/b57b-23-6c9b_stdl-reporting/docs/TASK-DIFF/image/asymetric-illustration.png"
-   inkscape:export-xdpi="211.88"
-   inkscape:export-ydpi="211.88">
-  <defs
-     id="defs2">
-    <marker
-       inkscape:stockid="Arrow1Lstart"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Lstart"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path4522"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.8,0,0,0.8,10,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Lend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker8697"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path8695"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker8264"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Lend"
-       inkscape:collect="always">
-      <path
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         id="path8262"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Lend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker7068"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path7066"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         style="fill:#00ff00;fill-opacity:1;fill-rule:evenodd;stroke:#00ff00;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6900"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Lend"
-       inkscape:collect="always">
-      <path
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         id="path6898"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6702"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6700"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6548"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6546"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6412"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6410"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6282"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6280"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6158"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6156"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6040"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6038"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5928"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5926"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5744"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path5742"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5644"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5642"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5550"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5548"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5462"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5460"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5380"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5378"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5304"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5302"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5234"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5232"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5158"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM"
-       inkscape:collect="always">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5156"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5100"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5098"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5048"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5046"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5002"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5000"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker4962"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path4960"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker4928"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path4926"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker4900"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path4898"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="DotM"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path4586"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Lend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Lend"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path4525"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         style="fill:#828282;fill-opacity:1;fill-rule:evenodd;stroke:#828282;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker8264-7"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Lend">
-      <path
-         inkscape:connector-curvature="0"
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         id="path8262-0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5644-3"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5642-6"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6548-7"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6546-5"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5048-3"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5046-5"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="DotM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker5644-3-2"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5642-6-9"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6548-7-1"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path6546-5-2"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker5048-3-7"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="DotM">
-      <path
-         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
-         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
-         id="path5046-5-0"
-         inkscape:connector-curvature="0" />
-    </marker>
-  </defs>
-  <sodipodi:namedview
-     id="base"
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1.0"
-     inkscape:pageopacity="0.0"
-     inkscape:pageshadow="2"
-     inkscape:zoom="5.6"
-     inkscape:cx="162.65374"
-     inkscape:cy="82.904535"
-     inkscape:document-units="mm"
-     inkscape:current-layer="layer1"
-     showgrid="true"
-     inkscape:window-width="3439"
-     inkscape:window-height="1414"
-     inkscape:window-x="1"
-     inkscape:window-y="0"
-     inkscape:window-maximized="1">
-    <inkscape:grid
-       type="xygrid"
-       id="grid3713" />
-  </sodipodi:namedview>
-  <metadata
-     id="metadata5">
-    <rdf:RDF>
-      <cc:Work
-         rdf:about="">
-        <dc:format>image/svg+xml</dc:format>
-        <dc:type
-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
-        <dc:title />
-      </cc:Work>
-    </rdf:RDF>
-  </metadata>
-  <g
-     inkscape:label="Calque 1"
-     inkscape:groupmode="layer"
-     id="layer1"
-     transform="translate(0,-254)">
-    <path
-       style="fill:none;stroke:#828282;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
-       d="m 3.96875,255.98958 0,38.36459"
-       id="path3715"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#828282;fill-opacity:1;stroke:none;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none"
-       x="-262.77982"
-       y="3.1431084"
-       id="text4806-3"
-       transform="rotate(-90)"><tspan
-         sodipodi:role="line"
-         id="tspan4804-6"
-         x="-262.77982"
-         y="3.1431084"
-         style="font-size:2.82222223px;fill:#828282;fill-opacity:1;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none">Time</tspan></text>
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5744);marker-mid:url(#marker5744);marker-end:url(#marker5100)"
-       d="m 11.90625,255.98958 13.229167,6.61458 -13.229167,7.9375"
-       id="path4826"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5644);marker-mid:url(#marker6548);marker-end:url(#marker5048)"
-       d="M 39.6875,262.60416 H 25.135417"
-       id="path4828"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5550);marker-mid:url(#marker6412);marker-end:url(#marker5002)"
-       d="m 11.90625,279.80208 13.229167,6.61458 -13.229167,7.9375"
-       id="path4826-7"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#marker5462);marker-mid:url(#marker6282);marker-end:url(#marker4962)"
-       d="M 39.6875,286.41666 27.78125,282.44791"
-       id="path4828-5"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5380);marker-mid:url(#marker6158);marker-end:url(#marker4928)"
-       d="M 50.270832,255.98958 63.5,262.60416 l -13.229168,7.9375"
-       id="path4826-3"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5304);marker-mid:url(#marker6040);marker-end:url(#marker4900)"
-       d="M 78.052083,262.60416 H 63.5"
-       id="path4828-56"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5234);marker-mid:url(#marker5928);marker-end:url(#DotM)"
-       d="M 50.270832,279.80208 63.5,286.41666 l -13.229168,7.9375"
-       id="path4826-7-2"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5158);marker-mid:url(#marker6702);marker-end:url(#marker5158)"
-       d="m 78.052083,286.41666 -11.90625,-3.96875"
-       id="path4828-5-9"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#ff0000;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker6900)"
-       d="m 27.781249,281.12499 1e-6,-19.84374"
-       id="path6890"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#00ff00;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker7068)"
-       d="M 63.499999,263.92707 63.5,283.77083"
-       id="path7058"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8264)"
-       d="m 42.333333,286.41666 c 5.77024,-6.49494 4.794155,-14.67646 0,-23.8125"
-       id="path8252"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Lstart)"
-       d="m 80.697917,286.41666 c 5.770243,-6.49494 4.794153,-14.67646 0,-23.8125"
-       id="path8252-9"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#828282;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1"
-       d="M 3.96875,275.83333 H 87.3125"
-       id="path9451"
-       inkscape:connector-curvature="0" />
-    <circle
-       style="fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
-       id="path1649"
-       cx="27.78125"
-       cy="282.44791"
-       r="1.3229166" />
-    <circle
-       style="fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:0.26499999,0.26499999;stroke-dashoffset:0;stroke-opacity:1"
-       id="path1655"
-       cx="27.78125"
-       cy="258.63541"
-       r="1.3229166" />
-    <circle
-       style="fill:none;fill-opacity:1;stroke:#00ff00;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
-       id="path1903"
-       cx="63.5"
-       cy="262.60416"
-       r="1.3229166" />
-    <circle
-       style="fill:none;fill-opacity:1;stroke:#00ff00;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
-       id="path1905"
-       cx="63.5"
-       cy="286.41666"
-       r="1.3229166" />
-  </g>
-</svg>
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="89mm"
+   height="43mm"
+   viewBox="0 0 89 43"
+   version="1.1"
+   id="svg8"
+   inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)"
+   sodipodi:docname="asymetric-illustration.svg"
+   inkscape:export-filename="/media/user/head_loop1/loop_405e-5f-dc22/405e-5f-dc22_hades/hades_kronos/kronos_b57b-23-6c9b/b57b-23-6c9b_stdl-reporting/docs/TASK-DIFF/image/asymetric-illustration.png"
+   inkscape:export-xdpi="211.88"
+   inkscape:export-ydpi="211.88">
+  <defs
+     id="defs2">
+    <marker
+       inkscape:stockid="Arrow1Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lstart"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4522"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.8,0,0,0.8,10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker8697"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path8695"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8264"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path8262"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker7068"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path7066"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#00ff00;fill-opacity:1;fill-rule:evenodd;stroke:#00ff00;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6900"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6898"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6702"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6700"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6548"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6546"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6412"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6410"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6282"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6280"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6158"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6156"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6040"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6038"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5928"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5926"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5744"
+       style="overflow:visible"
+       inkscape:isstock="true"
+       inkscape:collect="always">
+      <path
+         id="path5742"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5644"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5642"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5550"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5548"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5462"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5460"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5380"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5378"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5304"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5302"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5234"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5232"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5158"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM"
+       inkscape:collect="always">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5156"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5100"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5098"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5048"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5046"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5002"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5000"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4962"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path4960"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4928"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path4926"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4900"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path4898"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="DotM"
+       style="overflow:visible"
+       inkscape:isstock="true"
+       inkscape:collect="always">
+      <path
+         id="path4586"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#00468c;fill-opacity:1;fill-rule:evenodd;stroke:#00468c;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible"
+       inkscape:isstock="true"
+       inkscape:collect="always">
+      <path
+         id="path4525"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#828282;fill-opacity:1;fill-rule:evenodd;stroke:#828282;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8264-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         inkscape:connector-curvature="0"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path8262-0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5644-3"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5642-6"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6548-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6546-5"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5048-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5046-5"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="DotM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5644-3-2"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5642-6-9"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6548-7-1"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path6546-5-2"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker5048-3-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="DotM">
+      <path
+         transform="matrix(0.4,0,0,0.4,2.96,0.4)"
+         style="fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#202020;stroke-width:1.00000003pt;stroke-opacity:1"
+         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         id="path5046-5-0"
+         inkscape:connector-curvature="0" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="5.6"
+     inkscape:cx="162.65374"
+     inkscape:cy="82.904535"
+     inkscape:document-units="mm"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     inkscape:window-width="3439"
+     inkscape:window-height="1414"
+     inkscape:window-x="1"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3713" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata5">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Calque 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(0,-254)">
+    <path
+       style="fill:none;stroke:#828282;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
+       d="m 3.96875,255.98958 0,38.36459"
+       id="path3715"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#828282;fill-opacity:1;stroke:none;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none"
+       x="-262.77982"
+       y="3.1431084"
+       id="text4806-3"
+       transform="rotate(-90)"><tspan
+         sodipodi:role="line"
+         id="tspan4804-6"
+         x="-262.77982"
+         y="3.1431084"
+         style="font-size:2.82222223px;fill:#828282;fill-opacity:1;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none">Time</tspan></text>
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5744);marker-mid:url(#marker5744);marker-end:url(#marker5100)"
+       d="m 11.90625,255.98958 13.229167,6.61458 -13.229167,7.9375"
+       id="path4826"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5644);marker-mid:url(#marker6548);marker-end:url(#marker5048)"
+       d="M 39.6875,262.60416 H 25.135417"
+       id="path4828"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5550);marker-mid:url(#marker6412);marker-end:url(#marker5002)"
+       d="m 11.90625,279.80208 13.229167,6.61458 -13.229167,7.9375"
+       id="path4826-7"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#marker5462);marker-mid:url(#marker6282);marker-end:url(#marker4962)"
+       d="M 39.6875,286.41666 27.78125,282.44791"
+       id="path4828-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5380);marker-mid:url(#marker6158);marker-end:url(#marker4928)"
+       d="M 50.270832,255.98958 63.5,262.60416 l -13.229168,7.9375"
+       id="path4826-3"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5304);marker-mid:url(#marker6040);marker-end:url(#marker4900)"
+       d="M 78.052083,262.60416 H 63.5"
+       id="path4828-56"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5234);marker-mid:url(#marker5928);marker-end:url(#DotM)"
+       d="M 50.270832,279.80208 63.5,286.41666 l -13.229168,7.9375"
+       id="path4826-7-2"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;stroke:#00468c;stroke-width:0.265;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5158);marker-mid:url(#marker6702);marker-end:url(#marker5158)"
+       d="m 78.052083,286.41666 -11.90625,-3.96875"
+       id="path4828-5-9"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#ff0000;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker6900)"
+       d="m 27.781249,281.12499 1e-6,-19.84374"
+       id="path6890"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#00ff00;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker7068)"
+       d="M 63.499999,263.92707 63.5,283.77083"
+       id="path7058"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8264)"
+       d="m 42.333333,286.41666 c 5.77024,-6.49494 4.794155,-14.67646 0,-23.8125"
+       id="path8252"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.26499999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Lstart)"
+       d="m 80.697917,286.41666 c 5.770243,-6.49494 4.794153,-14.67646 0,-23.8125"
+       id="path8252-9"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#828282;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916663, 0.26458332;stroke-dashoffset:0;stroke-opacity:1"
+       d="M 3.96875,275.83333 H 87.3125"
+       id="path9451"
+       inkscape:connector-curvature="0" />
+    <circle
+       style="fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="path1649"
+       cx="27.78125"
+       cy="282.44791"
+       r="1.3229166" />
+    <circle
+       style="fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:0.26499999,0.26499999;stroke-dashoffset:0;stroke-opacity:1"
+       id="path1655"
+       cx="27.78125"
+       cy="258.63541"
+       r="1.3229166" />
+    <circle
+       style="fill:none;fill-opacity:1;stroke:#00ff00;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="path1903"
+       cx="63.5"
+       cy="262.60416"
+       r="1.3229166" />
+    <circle
+       style="fill:none;fill-opacity:1;stroke:#00ff00;stroke-width:0.26499999;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="path1905"
+       cx="63.5"
+       cy="286.41666"
+       r="1.3229166" />
+  </g>
+</svg>
diff --git a/TASK-DIFF/image/separator.gif b/TASK-DIFF/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/TASK-DIFF/image/separator.gif and /dev/null differ
diff --git a/TASK-DIFF/index.html b/TASK-DIFF/index.html
index f48bdf9..4680a90 100644
--- a/TASK-DIFF/index.html
+++ b/TASK-DIFF/index.html
@@ -491,10 +491,6 @@ <h2 id="task-context-difference-detection">Task Context : Difference Detection<a
 
 <p>As one can see, <em>AND</em> convolutions allow detecting, through the black spots, large area of structural changes between the two times and also, with more care, allow guessing smaller differences. Nevertheless, reading and interpreting such representation remains complex for users.</p>
 <p>The goal of this task is then to tackle these two drawbacks, allowing the platform to detect changes not only for point-based models but also for vector-based models and to implement a variation of the <em>XOR</em> operator for point-based models allowing to efficiently highlight the structural evolution. The task consists then in the implementation, testing and validation of a difference detection algorithm suitable for any type of model and to conduct a formal analysis on the best rendering techniques.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="methodology">Methodology<a class="headerlink" href="#methodology" title="Permanent link">&para;</a></h2>
 <p>A step by step methodology is defined to address the problem of difference detection in the platform. In a first phase, the algorithm will be developed and validated on vector-based models as follows :</p>
 <ul>
@@ -545,10 +541,6 @@ <h2 id="methodology">Methodology<a class="headerlink" href="#methodology" title=
 </li>
 </ul>
 <p>In addition, the development of difference detection algorithm has to be conducted keeping in mind the possible future evolutions of the platform such as addition of layers (separation of data), implementation of a multi-scale approach of the time dimension and addition of raster data in the platform.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="first-phase-synthetic-variations">First Phase : Synthetic Variations<a class="headerlink" href="#first-phase-synthetic-variations" title="Permanent link">&para;</a></h2>
 <p>In order to implements the vector-based difference detection algorithm, sets of data are considered as base on which synthetic differences are applied to simulate the evolution of the territory. This approach allows focusing on well controlled data to formally benchmark the results of the implemented algorithm. Experiments are conducted using these data to formally evaluate the performance of the developed algorithm.</p>
 <h3 id="selected-resources-and-models">Selected Resources and Models<a class="headerlink" href="#selected-resources-and-models" title="Permanent link">&para;</a></h3>
@@ -782,10 +774,6 @@ <h3 id="conclusion-first-phase">Conclusion : First Phase<a class="headerlink" hr
 <p>The user-based experiments showed that using the platform interface, a human can significantly outperform the result of a <em>naive</em> automated process operating on the models themselves. The experiments showed that the user is able to efficiently search and find through space and time the evolutions of the territory appearing in the data.</p>
 <p>Of course, as the model size and complexity increases, the user-driven interface starts to show its limits. In such a case, the process-based experiments showed that automated processes can take over these more complicated searches through methods allowing performing exhaustive detection over wide models in a matter of several minutes.</p>
 <p>At this point, the developments and validations of the algorithm, and its variations, were conducted on synthetic modifications introduced in models using controlled procedures. The next phase focuses on formal data extracted from land registers.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="second-phase-true-variations">Second Phase : True Variations<a class="headerlink" href="#second-phase-true-variations" title="Permanent link">&para;</a></h2>
 <p>In this second phase, also dedicated to vector-based models, the focus is set on applying the developed difference detection algorithm on <em>true</em> land register models. Two sets of data are considered in order to address short-term and long-term difference detection.</p>
 <h3 id="selected-resources-and-models_1">Selected Resources and Models<a class="headerlink" href="#selected-resources-and-models_1" title="Permanent link">&para;</a></h3>
@@ -1014,10 +1002,6 @@ <h3 id="conclusion-second-phase">Conclusion : Second Phase<a class="headerlink"
 <p>Indeed, on the <em>Geneva</em> models, a large amount of differences is detected even on a relative short period of time (two years). In addition to the regular updates, following the territory evolution, a large amount of corrections is made to keep the model in the correct reference frame. The Swiss federal system can also add complexity, as all Cantons have to align themselves on a common set of expectations.</p>
 <p>In such a case, the difference detection turned out to be an interesting tool to understand and follows the corrections made to the model in addition to the regular updates. On the <em>Geneva</em> case, we illustrated that, by detecting it in the difference model, the correction on the coordinates frame on large pieces of the territory. This shows how the difference detection can be seen as a service that can help to keep track of the life of the model by detecting and checking these type of modifications.</p>
 <p>As a result, difference detection can be a tool for the user of the land register but can also be a tool for the land register authorities themselves. The difference models can be used to check and audit the evolution of the models, helping the required follow-up on the applied correction and updates.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="third-phase-point-based-models">Third Phase : Point-Based Models<a class="headerlink" href="#third-phase-point-based-models" title="Permanent link">&para;</a></h2>
 <p>In this third and last phase, the developed algorithm for difference detection on vector models is tested on point-based ones. As mentioned in the introduction, the platform was already implementing logical operators allowing comparing point-based models across time. As illustrated in the introduction, only the <em>AND</em> operator allowed emphasizing differences, but rendering them as missing part of the composite models. It was then difficult for the user to determine and analyze those differences.</p>
 <p>The goal of this last phase is to determine in which extend the developed algorithm is able to improve the initial results of point-based logical operators and how it can be adapted to provide better detection of differences.</p>
@@ -1269,20 +1253,12 @@ <h3 id="third-phase">Third Phase<a class="headerlink" href="#third-phase" title=
 <h3 id="synthesis">Synthesis<a class="headerlink" href="#synthesis" title="Permanent link">&para;</a></h3>
 <p>As a synthesis, it is clear that models are carrying a large amount of richness themselves, that is already a challenge to exploit, but it is also clear that a large amount of information can be found between the <em>versions</em> of the models. The difference detection algorithm brings a first tool that demonstrate the ability to reach and start to exploit these informations.</p>
 <p>More than the content of the models itself, the understanding of the evolution of this content is a major topic especially in the field of <em>geodata</em> as they represent, transcript, the evolution of the surveyed territory. It then appears clear that being able to reach and exploit the information contained in-between the models is a major advantage as it allows understanding what are these models, that is four dimensional objects.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="perspectives">Perspectives<a class="headerlink" href="#perspectives" title="Permanent link">&para;</a></h2>
 <p>Many perspectives are opened following the implementation and analysis of the difference detection. Several perspectives, mostly technical, are presented here as a final section.</p>
 <p>In the first place, as raster are entering the set of data that can be injected in the platform, evolution of the difference detection could be applied to the platform, taking advantage of the evolution of machine learning. The possibility of detected differences in images could lead to very interesting perspective through the <em>data communication</em> features of the platform.</p>
 <p>Another perspective could be to allow the platform to separate the data into formal layers, the separation being only currently ensure by type and times. Splitting data into layers would allow applying difference detection in a much more controlled manner, leading to difference models focused on very specific elements of the model temporal evolution.</p>
 <p>The addition of layer could also be the starting point to the notion of <em>data convolution micro language</em>. Currently, data communication and difference detection only apply through the specification of two different and parallel navigation time. The users, or processes, have to specify each of the two time position in order to obtain the mixed of differences models they need.</p>
 <p>An interesting evolution would be to replace these two navigation time by a small and simple <em>micro language</em> allowing the user to compare more than two times in a more complex manner. This could also benefit from data separation through layer. Such <em>micro language</em> could allow to compare two, three or more models, or layers, and would also open the access the mixed models of differences models such as comparing the difference detection between point-based and vector-based models, which would then be a comparison of a comparison.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="reproduction-resources">Reproduction Resources<a class="headerlink" href="#reproduction-resources" title="Permanent link">&para;</a></h2>
 <p>To reproduce the presented experiments, the <em>STDL 4D framework</em> has to be used and can be found here :</p>
 <ul>
@@ -1335,10 +1311,6 @@ <h2 id="reproduction-resources">Reproduction Resources<a class="headerlink" href
 </li>
 </ul>
 <p>You can contact <em>STDL</em> for any question regarding the reproduction of the presented results.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="auxiliary-developments-corrections">Auxiliary Developments &amp; Corrections<a class="headerlink" href="#auxiliary-developments-corrections" title="Permanent link">&para;</a></h2>
 <p>In addition to the main developments made, some additional scripts and other corrections have been made to solve auxiliary problems or to improve the code according to the developed features during this task. The auxiliary developments are summarized here :</p>
 <ul>
@@ -1373,10 +1345,6 @@ <h2 id="auxiliary-developments-corrections">Auxiliary Developments &amp; Correct
 <p>Developments of various scripts for plots and figures creations.</p>
 </li>
 </ul>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="references">References<a class="headerlink" href="#references" title="Permanent link">&para;</a></h2>
 <p>[1] REFRAME, SwissTopo, https://www.swisstopo.admin.ch/de/karten-daten-online/calculation-services.html</p>
 
diff --git a/TASK-IDET/image/separator.gif b/TASK-IDET/image/separator.gif
deleted file mode 100644
index 4d41cdc..0000000
Binary files a/TASK-IDET/image/separator.gif and /dev/null differ
diff --git a/TASK-IDET/index.html b/TASK-IDET/index.html
index 2d186eb..cc36724 100644
--- a/TASK-IDET/index.html
+++ b/TASK-IDET/index.html
@@ -360,10 +360,6 @@ <h2 id="introduction">Introduction<a class="headerlink" href="#introduction" tit
 <p>A generic framework was developed within the STDL, allowing the usage of <a href="https://paperswithcode.com/task/object-detection">state-of-the-art machine learning methods</a> to detect objects in aerial images. Such framework allows one to leverage aerial images <em>e.g.</em> to provide valuable hints towards the update of cadastral information. At least as far as Switzerland is concerned, high-resolution (&lt; 30 cm Ground Sample Distance) are acquired at the cantonal and federal scales on a regular basis. An inventory of the STDL's applications will be provided at the end of this article.</p>
 <p>The STDL's object detection framework is powered at its core by <a href="https://github.com/facebookresearch/detectron2">Detectron2</a>, a Python library developed by the Facebook Artificial Intelligence Research group and released under the <a href="https://github.com/facebookresearch/detectron2/blob/master/LICENSE">Apache 2.0 open-source license</a>. Detectron2 includes methods to train models performing various tasks, object detection and instance segmentation to name a few. Specific pieces of code were written by the STDL to pre-process data to be input to Detectron2, as well as to post-process outputs and turn them into meaningful information for the projects being developed. More precisely, our developments enable the usage of Detectron2 with georeferenced images and labels.</p>
 <p>Our workflow goes through the steps described here-below.</p>
-<div align="center">
-<img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="workflow">Workflow<a class="headerlink" href="#workflow" title="Permanent link">&para;</a></h2>
 <h3 id="1-tileset-generation">1. Tileset generation<a class="headerlink" href="#1-tileset-generation" title="Permanent link">&para;</a></h3>
 <p>Typically, aerial coverages are made accessible through Web Services, publicly or privately. While making opaque to the user the server-side tiling and file-based structure, these Web Services can efficiently generate raster images on-demand depending on the parameters sent by the requesting client. These parameters include:</p>
@@ -476,10 +472,6 @@ <h3 id="4-assessment">4. Assessment<a class="headerlink" href="#4-assessment" ti
 <h3 id="5-iterate-until-results-are-satisfactory">5. Iterate until results are satisfactory<a class="headerlink" href="#5-iterate-until-results-are-satisfactory" title="Permanent link">&para;</a></h3>
 <p>Several training sessions can be executed, using different values of the various hyper-parameters involved in the process. As a matter of fact, reviewing and improving ground truth data is also part of the hyper-parameter tuning (cf. "<a href="https://towardsdatascience.com/from-model-centric-to-data-centric-artificial-intelligence-77e423f3f593">From Model-centric to Data-centric Artificial Intelligence</a>''). Keeping track of the above-mentioned metrics across multiple realizations, eventually an optimal model should be found (at least, a local optimum). </p>
 <p>The exploration of the hyper-parameter space is a tedious task, which consumes time as well as human and computing resources. It can be performed in a more or less systematic/heuristic way, depending on the experience of the operator as well as on the features offered by the code. Typically, a partial exploration is enough to obtain acceptable results. Within the STDL team, it is customary to first perform some iterations until "decent scores" are obtained, then to involve beneficiaries and domain experts in the continuous evaluation and improvement of results, until satisfactory results are obtained. These exchanges between data scientists and domain experts are also key to raise both communities' awareness of the virtues and flaws of machine learning approaches.</p>
-<div align="center">
-    <img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="use-cases">Use cases<a class="headerlink" href="#use-cases" title="Permanent link">&para;</a></h2>
 <p>Here is a list of the successful applications of the object detection framework described in this article:</p>
 <ul>
@@ -489,10 +481,6 @@ <h2 id="use-cases">Use cases<a class="headerlink" href="#use-cases" title="Perma
 <li><a href="../PROJ-ROADSURF/">Classification of road surfaces</a></li>
 <li><a href="../PROJ-TGLN/">Updating the «Cultivable Area» Layer of the Agricultural Office, Canton of Thurgau</a></li>
 </ul>
-<div align="center">
-    <img src="image/separator.gif?raw=true" width="5%">
-</div>
-
 <h2 id="concluding-remarks">Concluding remarks<a class="headerlink" href="#concluding-remarks" title="Permanent link">&para;</a></h2>
 <p>The STDL's object detection framework is still under development and receives updates as new use cases are tackled.</p>
 
diff --git a/assets/javascripts/config.js b/assets/javascripts/config.js
index 8cf0d6b..ca24057 100644
--- a/assets/javascripts/config.js
+++ b/assets/javascripts/config.js
@@ -1,12 +1,12 @@
-window.MathJax = {
-    tex: {
-      inlineMath: [["\\(", "\\)"]],
-      displayMath: [["\\[", "\\]"]],
-      processEscapes: true,
-      processEnvironments: true
-    },
-    options: {
-      ignoreHtmlClass: ".*|",
-      processHtmlClass: "arithmatex"
-    }
+window.MathJax = {
+    tex: {
+      inlineMath: [["\\(", "\\)"]],
+      displayMath: [["\\[", "\\]"]],
+      processEscapes: true,
+      processEnvironments: true
+    },
+    options: {
+      ignoreHtmlClass: ".*|",
+      processHtmlClass: "arithmatex"
+    }
   };
\ No newline at end of file
diff --git a/search/search_index.json b/search/search_index.json
index 4e3aecb..d753400 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Swiss Territorial Data Lab - STDL \u00b6 The STDL aims to promote collective innovation around the Swiss territory and its digital copy. It mainly explores the possibilities provided by data science to improve official land registering. A multidisciplinary team composed of cantonal, federal and academic partners is reinforced by engineers specialized in geographical data science to tackle the challenges around the management of territorial data-sets. The developed STDL platform codes and documentation are published under open licenses to allow partners and Swiss territory management actors to leverage the developed technologies. Exploratory Projects \u00b6 Exploratory projects in the field of the Swiss territorial data are conducted at the demand of institutions or actors of the Swiss territory. The exploratory projects are conducted with the supervision of the principal in order to closely analyze the answers to the specifications along the project. The goal of exploratory project aims to provide proof-of-concept and expertise in the application of technologies to Swiss territorial data. Automatic detection and observation of mineral extraction sites in Switzerland January 2024 Cl\u00e9mence Herny (ExoLabs) - Shanci Li (Uzufly) - Alessandro Cerioni (Etat de Gen\u00e8ve) - Roxane Pott (Swisstopo) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY The study of the evolution of mineral extraction sites (MES) is primordial for the management of mineral resources and the assessment of their environmental impact. In this context, swisstopo has solicited the STDL to automate the vectorisation of MES over the years. This tedious task was previously carried out manually and was not regularly updated. Automatic object detection using a deep learning method was applied to SWISSIMAGE RGB orthophotos with a spatial resolution of 1.6 m px -1 . The trained model proved its ability to accurately detect MES, achieving a f1-score of 82%. Detection by inference was performed on images from 1999 to 2021, enabling us to track the evolution of potential MES over several years. Although the results are satisfactory, a careful examination of the detections must be carried out by experts to validate them as true MES. Despite this remaining manual work involved, the process is faster than a full manual vectorisation and can be used in the future to keep MES information up-to-date. Full article Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds August 2023 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Republic and Canton of Jura - PROJ-HETRES Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. Full article Using spatio-temporal neighbor data information to detect changes in land use and land cover April 2023 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used.It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. Full article Classification of road surfaces March 2023 Gwena\u00eblle Salamin (swisstopo) - Cl\u00e9mence Herny (Exolabs) - Roxane Pott (swisstopo) - Alessandro Cerioni (Canton of Geneva) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. Full article Tree Detection from Point Clouds for the Canton of Geneva March 2022 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. Full article Detection of thermal panels on canton territory to follow renewable energy deployment February 2022 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Full article Automatic detection of quarries and the lithology below them in Switzerland January 2022 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been mode manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an f1-score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. Full article Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau June 2021 Adrian Meyer (FHNW) - Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGLN The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. Full article Swimming Pool Detection for the Canton of Thurgau April 2021 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Full article Completion of the federal register of buildings and dwellings February 2021 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL The Swiss Federal Statistical Office is in charge of the national Register of of Buildings and Dwellings (RBD) which keep tracks of every existing building in Switzerland. Currently, the register is being completed with building in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issue dues to missing information and their difficulty to be collected. The construction years of the building is one missing information for large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Full article Swimming Pool Detection from Aerial Images over the Canton of Geneva January 2021 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Full article Difference models applied to the land register November 2020 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - TASK-DTRK Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Full article Research Developments \u00b6 Research developments are conducted aside of the research projects to provide a framework of tools and expertise around the Swiss territorial data and related technologies. The research developments are conducted according to the research plan established by the data scientists and validated by the steering committee. OBJECT DETECTION FRAMEWORK November 2021 Alessandro Cerioni (Canton of Geneva) - Cl\u00e9mence Herny (Exolabs) - Adrian Meyer (FHNW) - Gwena\u00eblle Salamin (Exolabs) Project scheduled in the STDL research roadmap - TASK-IDET This strategic component of the STDL consists of the automated analysis of geospatial images using deep learning while providing practical applications for specific use cases. The overall goal is the extraction of vectorized semantic information from remote sensing data. The involved case studies revolve around concrete object detection use cases deploying modern machine learning methods and utilizing a multitude of available datasets. The goal is to arrive at a prototypical platform for object detection which is highly useful not only for cadastre specialists and authorities but also for stakeholders at various contact points in society. Full article AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT November 2020 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Full article Steering Committee \u00b6 The steering committee of the Swiss Territorial Data Lab is composed of Swiss public administrations bringing their expertise and competences to guide the conducted projects and developments. Members of the STDL steering committee Submitting a project \u00b6 To submit a project to the STDL, simply fill this form . To contact the STDL, please write an email to info@stdl.ch . We will reply as soon as possible!","title":"Homepage"},{"location":"#swiss-territorial-data-lab-stdl","text":"The STDL aims to promote collective innovation around the Swiss territory and its digital copy. It mainly explores the possibilities provided by data science to improve official land registering. A multidisciplinary team composed of cantonal, federal and academic partners is reinforced by engineers specialized in geographical data science to tackle the challenges around the management of territorial data-sets. The developed STDL platform codes and documentation are published under open licenses to allow partners and Swiss territory management actors to leverage the developed technologies.","title":"Swiss Territorial Data Lab - STDL"},{"location":"#exploratory-projects","text":"Exploratory projects in the field of the Swiss territorial data are conducted at the demand of institutions or actors of the Swiss territory. The exploratory projects are conducted with the supervision of the principal in order to closely analyze the answers to the specifications along the project. The goal of exploratory project aims to provide proof-of-concept and expertise in the application of technologies to Swiss territorial data. Automatic detection and observation of mineral extraction sites in Switzerland January 2024 Cl\u00e9mence Herny (ExoLabs) - Shanci Li (Uzufly) - Alessandro Cerioni (Etat de Gen\u00e8ve) - Roxane Pott (Swisstopo) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY The study of the evolution of mineral extraction sites (MES) is primordial for the management of mineral resources and the assessment of their environmental impact. In this context, swisstopo has solicited the STDL to automate the vectorisation of MES over the years. This tedious task was previously carried out manually and was not regularly updated. Automatic object detection using a deep learning method was applied to SWISSIMAGE RGB orthophotos with a spatial resolution of 1.6 m px -1 . The trained model proved its ability to accurately detect MES, achieving a f1-score of 82%. Detection by inference was performed on images from 1999 to 2021, enabling us to track the evolution of potential MES over several years. Although the results are satisfactory, a careful examination of the detections must be carried out by experts to validate them as true MES. Despite this remaining manual work involved, the process is faster than a full manual vectorisation and can be used in the future to keep MES information up-to-date. Full article Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds August 2023 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Republic and Canton of Jura - PROJ-HETRES Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. Full article Using spatio-temporal neighbor data information to detect changes in land use and land cover April 2023 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used.It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. Full article Classification of road surfaces March 2023 Gwena\u00eblle Salamin (swisstopo) - Cl\u00e9mence Herny (Exolabs) - Roxane Pott (swisstopo) - Alessandro Cerioni (Canton of Geneva) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. Full article Tree Detection from Point Clouds for the Canton of Geneva March 2022 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. Full article Detection of thermal panels on canton territory to follow renewable energy deployment February 2022 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Full article Automatic detection of quarries and the lithology below them in Switzerland January 2022 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been mode manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an f1-score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. Full article Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau June 2021 Adrian Meyer (FHNW) - Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGLN The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. Full article Swimming Pool Detection for the Canton of Thurgau April 2021 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Full article Completion of the federal register of buildings and dwellings February 2021 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL The Swiss Federal Statistical Office is in charge of the national Register of of Buildings and Dwellings (RBD) which keep tracks of every existing building in Switzerland. Currently, the register is being completed with building in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issue dues to missing information and their difficulty to be collected. The construction years of the building is one missing information for large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Full article Swimming Pool Detection from Aerial Images over the Canton of Geneva January 2021 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Full article Difference models applied to the land register November 2020 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - TASK-DTRK Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Full article","title":"Exploratory Projects"},{"location":"#research-developments","text":"Research developments are conducted aside of the research projects to provide a framework of tools and expertise around the Swiss territorial data and related technologies. The research developments are conducted according to the research plan established by the data scientists and validated by the steering committee. OBJECT DETECTION FRAMEWORK November 2021 Alessandro Cerioni (Canton of Geneva) - Cl\u00e9mence Herny (Exolabs) - Adrian Meyer (FHNW) - Gwena\u00eblle Salamin (Exolabs) Project scheduled in the STDL research roadmap - TASK-IDET This strategic component of the STDL consists of the automated analysis of geospatial images using deep learning while providing practical applications for specific use cases. The overall goal is the extraction of vectorized semantic information from remote sensing data. The involved case studies revolve around concrete object detection use cases deploying modern machine learning methods and utilizing a multitude of available datasets. The goal is to arrive at a prototypical platform for object detection which is highly useful not only for cadastre specialists and authorities but also for stakeholders at various contact points in society. Full article AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT November 2020 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Full article","title":"Research Developments"},{"location":"#steering-committee","text":"The steering committee of the Swiss Territorial Data Lab is composed of Swiss public administrations bringing their expertise and competences to guide the conducted projects and developments. Members of the STDL steering committee","title":"Steering Committee"},{"location":"#submitting-a-project","text":"To submit a project to the STDL, simply fill this form . To contact the STDL, please write an email to info@stdl.ch . We will reply as soon as possible!","title":"Submitting a project"},{"location":"PROJ-DQRY/","text":"Automatic Detection of Quarries and the Lithology below them in Switzerland \u00b6 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Supervision : Nils Hamel (UNIGE) - Raphael Rollier (swisstopo) Proposed by swisstopo - PROJ-DQRY June 2021 to January 2022 - Published on January 30th, 2022 Abstract : Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been made manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an F1 Score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. 1 - Introduction \u00b6 Mining is an important economic activity worldwide and this is also the case in Switzerland. The Confederation topographic office (swisstopo) is responsible for monitoring the presence of quarries and also the materials being explored. This is extremely relevant for planning the demand and shortage of explored materials and also their transportation through the country. As this of federal importance the mapping of these features is already done. Although this work is very detailed and accurate, quarries have a very characteristical updating pattern. Quarries can appear and disappear in a matter of a few months, in especial when they are relatively small, as in Switzerland. Therefore it is of interest of swisstopo to make an automatic detection of quarries in a way that it is also reproducible in time. A strategy offen offered by the Swiss Territorial Data Lab is the automatic detection of several objects in aerial imagery through deep learning, following our Object Detection Framework . In this case it is fully applicable as quarries in Switzerland are relatively small, so high resolution imagery is required, which is something our Neural Network has proven to tackle with mastery in past projects. This high resolution imagery is also reachable through SWISSIMAGE , aerial images from swisstopo that cover almost the whole country with a 10cm pixel size (GSD). Nevertheless, in order to train our neural network, and as it's usually the case in deep learning, several labelled images are required. These data work as ground truth so that the neural network \"learns\" what's the object to be detected and which should not. For this purpose, the work from the topographic landscape model ( TLM ) team of swisstopo has been of extreme importance. Among different surface features, quarries have been mapped all over Switzerland with a highly detailed scale. Although the high quality and precision of the labels from TLM, quarries are constantly changing, appearing and disappearing, and therefore the labels are not always synchronized with the images from SWISSIMAGE. This lack of of synchronization between these sets of data can be seen in Figure 1, where in the left one has the year of mapping of TLM and on the right the year of the SWISSIMAGE flights. Figure 1 : Comparison of TLM (left) and SWISSIMAGE (right) temporality. For this purpose, a two-times interaction was necessary with the domain expert. In order to have a ground truth that was fully synchronized with SWISSIMAGE we required two stages of training : one making use of the TLM data and a second one with a manual correction of the predicted labels from the first interaction. It is of crucial importance to state that this correction needed to be made by the domain expert so that he could carefully check each detection in pre-defined tiles. With that in hands, we could go further with a more trustworthy training. As stated, it is of interest of swisstopo to also identify the material being explored by every quarry. For that purpose, it was recommended the usage of the GeoCover dataset from swisstopo as well. This dataset a vector layer of the the geological cover of the whole Switzerland, which challenged us to cross the detector predictions with such vector information. In summary, the challenge of the STDL was to investigate to which extent is it possible to automatically detect quarries using Deep Learning considering their high update ratio using aerial imagery. 2 - Methodology \u00b6 First of all the \"area of interest\" must be identified. This is where the detection and training took place. In this case, a polygon of the whole Switzerland was used. After that, the area of interest is divided in several tiles of fixed size. This is then defining the slicing of SWISSIMAGE (given as WMS). For this study, tiles of different sizes were tested, being 500x500m tiles defined for final usage. Following the resolution of the images must be defined, which, again, after several tests, was defined as 512x512 pixels. For validation purposes the data is then split into Training, Validation and Testing. The training data-set is used inside the network for its learning; the validation is completely apart from training and used only to check results and testing is used for cross-validation. 70% of the data was used for training, 15% for validation and 15% for testing. To what concerns the labels, the ones from TLM were manually checked so that a group of approximately 250 labels with full synchronization with the SWISSIMAGE were found and recorded. Following, the first row training passes through the same framework from former STDL projects. We make use of a predictive Recursive-Convolutional Neural Network with ResNet-50 backbone provided by Detectron2 . A deeper explanation of the network functionality can be found here and here . Even with different parameters set, it was observed that predictions were including too much false positives, which were mainly made of snow. Most probably the reflectance of snow is similar to the one of quarries and this needed a special treatment. For this purpose, a filtering of the results was used. First of all the features were filtered based on the score values (0.9) and then by elevation, using the SRTM digital elevation model. As snow usually does not precipitate below around 1155 m, this was used as threshold. Finally an area threshold is also passed (using smallest predictions area) and predictions are merged. A more detailed description of how to operate this first filter can be seen here . Once several tests were performed, the new predictions were sent back to the domain expert for detailed revision with a rigid protocol. This included the removal of false positives and the inclusion of false negatives, mainly. This was performed by 4 different experts from swisstopo in 4 regions with the same amount of tiles to be analyzed. It is important to the state again the importance of domain expertise in this step, as a very careful and manual evaluation of what is and what is not a quarry must be made. Once the predictions were corrected, a new session of training was performed using different parameters. Once again, the same resolution and tile size were used as in the first iteration (512x512m tiles with 512x512 pixels of resolution), although this time a new filtering was developed. Very similar to the first one, but in a different order, allowing more aesthetical predictions in the end, something the domain expert was also carrying about. This procedure is summarized in figure 2. Figure 2 : Methodology applied for the detection of quarries and new training sessions. In the end, in order to also include the geological information of the detected quarries, a third layer resulting of the intersection of both the predictions and the GeoCover labels is created. This was done in a way that the final user can click to obtain both information on the quarry (when not a pure prediction) and the information of the geology/lithology on this part of the quarry. As a result, each resulting intersection poylgon contains both information from quarry and GeoCover. In order to evaluate the obtained results, the F1 Score was computed and also the final predictions were compared to the corrected labels from the domain expert side. This was done visually by acquiring the centroid of each quarry detected and by a heat-map, allowing one to detect the spatial pattern of detections. The heat-map was computed using 10'000 m radius and a 100 m pixel size. 3 - Results & Discussion \u00b6 In the first iteration, when the neural was trained with some labels of the TLM vector data, an optimal F1 score of approximately 0.78 was obtained. The figure 3 shows the behavior of the precision, recall and F1 score for the final model selected. Figure 3 : Precision, Recall and F1 score of the first iteration (using TLM data). Given the predictions resulting from the correction by the domain experts, there was an outstanding improve in the F1 score obtained, which was of approximately 0.85 in its optimal, as seen in figure 4. A total of 1265 were found in Switzerland after filtering. Figure 4 : Precision, Recall and F1 score of the second iteration (using data corrected by the domain expert). Figure 5 demonstrates some examples of detected quarries and this one can have some notion of the quality of the shape of the detections and how they mark the real-world quarries. Examples of false positives and false negatives, unfortunately still present in the detections are also shown. This is also an interesting demonstration of how some objects that are very similar to quarries, in the point of view of non-experts and how they may influence the results. These examples of errors are also an interesting indication of the importance of domain expertise in evaluating machine made results. Figure 5 : Examples of detected quarries, with true positive, false negative and false positive. To check on the validity of the new predictions generated, the centroid of them was plot along the centroid of the corrected labels, so one could check the spatial pattern of them and this way evaluate if they were respecting the same behavior. Figure 6 shows this plot. Figure 6 : Disposition of the centroids of assessed predictions and final predictions. One can see that despite some slight differences, the overall pattern is very similar among the disposition of the predictions. A very similar result can be seen with the computed heat-map of these points, seen in figure 7. Figure 7 : Heatmap of assessed predictions and final predictions. There is a small area to the west of the country where there were less detections than desired and in general there were more predictions than before. The objective of the heat-map is more to give a general view of the results than giving an exact comparison, as a point is created for every feature and the new filter used tended to smooth the results and join many features into a single one too. At the end the results were also intersected with GeoCover, which provide the Swiss soil detailed lithology, and an example of the results can be seen below using the QGIS Software. Figure 8 : Intersection of predictions with GeoCover seen in QGIS. Finally and most important, the domain expert was highly satisfied with this work, due to the support it can give to swisstopo and the TLM team in mapping the future quarries. The domain expert also demonstrated interest in pursuing the work by investigating the temporal pattern of quarries and detecting the volume of material in each quarry. 4 - Conclusion \u00b6 Through this collaboration with swisstopo, we managed to demonstrate that data science is able to provide relevant and efficient tool to ease complex and time-consuming task. With the produced inventory of the quarries on the whole Swiss territory, we were able to provide a quasi-exhaustive view of the situation to the domain expert, leading him to have a better view of the exploitation sites. This is of importance and a major step forward compared to the previous situation. Indeed, before this project, the only solution available to the domain expert was to gather all the federal and cantonal data, through non-standardized and time-consuming process, to hope having a beginning of an inventory, with temporality issues. With the developed prototype, within hours, the entire SWISSIMAGE data-set can be processed and turn into a full scale inventory, guiding the domain expert directly toward its interests. The resulting geographical layer can then be seen as the result of this demonstrator, able to turn the aerial images into a simple polygonal layer representing the quarries, with little false positive and false negative, providing the required view for the domain expert understanding of the Swiss situation. With such a result, it is possible to convolve it with all the other existing data, with the GeoCover in the first place. This lithology model of the Swiss soil can be intersected with the produced quarries layer in order to create a secondary geographical layer merging both quarries location and quarries soil type, leading to a powerful analyzing tool for the domain expert. The produced demonstrator shows that it is possible, in hours, to deduce a simple and reliable geographical layer based on a simple set of orthomosaic. The STDL then was able to prove the possibility to repeat the process along the time dimension, for future and past images, opening the way to build and rebuild the history and evolution of the quarries. With such a process, it will be possible to compute statistical quantities on the long term to catch the evolution and the resources, leading to more reliable strategical understanding of the Swiss resources and sovereignty.","title":"Automatic Detection of Quarries and the Lithology below them in Switzerland"},{"location":"PROJ-DQRY/#automatic-detection-of-quarries-and-the-lithology-below-them-in-switzerland","text":"Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Supervision : Nils Hamel (UNIGE) - Raphael Rollier (swisstopo) Proposed by swisstopo - PROJ-DQRY June 2021 to January 2022 - Published on January 30th, 2022 Abstract : Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been made manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an F1 Score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result.","title":"Automatic Detection of Quarries and the Lithology below them in Switzerland"},{"location":"PROJ-DQRY/#1-introduction","text":"Mining is an important economic activity worldwide and this is also the case in Switzerland. The Confederation topographic office (swisstopo) is responsible for monitoring the presence of quarries and also the materials being explored. This is extremely relevant for planning the demand and shortage of explored materials and also their transportation through the country. As this of federal importance the mapping of these features is already done. Although this work is very detailed and accurate, quarries have a very characteristical updating pattern. Quarries can appear and disappear in a matter of a few months, in especial when they are relatively small, as in Switzerland. Therefore it is of interest of swisstopo to make an automatic detection of quarries in a way that it is also reproducible in time. A strategy offen offered by the Swiss Territorial Data Lab is the automatic detection of several objects in aerial imagery through deep learning, following our Object Detection Framework . In this case it is fully applicable as quarries in Switzerland are relatively small, so high resolution imagery is required, which is something our Neural Network has proven to tackle with mastery in past projects. This high resolution imagery is also reachable through SWISSIMAGE , aerial images from swisstopo that cover almost the whole country with a 10cm pixel size (GSD). Nevertheless, in order to train our neural network, and as it's usually the case in deep learning, several labelled images are required. These data work as ground truth so that the neural network \"learns\" what's the object to be detected and which should not. For this purpose, the work from the topographic landscape model ( TLM ) team of swisstopo has been of extreme importance. Among different surface features, quarries have been mapped all over Switzerland with a highly detailed scale. Although the high quality and precision of the labels from TLM, quarries are constantly changing, appearing and disappearing, and therefore the labels are not always synchronized with the images from SWISSIMAGE. This lack of of synchronization between these sets of data can be seen in Figure 1, where in the left one has the year of mapping of TLM and on the right the year of the SWISSIMAGE flights. Figure 1 : Comparison of TLM (left) and SWISSIMAGE (right) temporality. For this purpose, a two-times interaction was necessary with the domain expert. In order to have a ground truth that was fully synchronized with SWISSIMAGE we required two stages of training : one making use of the TLM data and a second one with a manual correction of the predicted labels from the first interaction. It is of crucial importance to state that this correction needed to be made by the domain expert so that he could carefully check each detection in pre-defined tiles. With that in hands, we could go further with a more trustworthy training. As stated, it is of interest of swisstopo to also identify the material being explored by every quarry. For that purpose, it was recommended the usage of the GeoCover dataset from swisstopo as well. This dataset a vector layer of the the geological cover of the whole Switzerland, which challenged us to cross the detector predictions with such vector information. In summary, the challenge of the STDL was to investigate to which extent is it possible to automatically detect quarries using Deep Learning considering their high update ratio using aerial imagery.","title":"1 - Introduction"},{"location":"PROJ-DQRY/#2-methodology","text":"First of all the \"area of interest\" must be identified. This is where the detection and training took place. In this case, a polygon of the whole Switzerland was used. After that, the area of interest is divided in several tiles of fixed size. This is then defining the slicing of SWISSIMAGE (given as WMS). For this study, tiles of different sizes were tested, being 500x500m tiles defined for final usage. Following the resolution of the images must be defined, which, again, after several tests, was defined as 512x512 pixels. For validation purposes the data is then split into Training, Validation and Testing. The training data-set is used inside the network for its learning; the validation is completely apart from training and used only to check results and testing is used for cross-validation. 70% of the data was used for training, 15% for validation and 15% for testing. To what concerns the labels, the ones from TLM were manually checked so that a group of approximately 250 labels with full synchronization with the SWISSIMAGE were found and recorded. Following, the first row training passes through the same framework from former STDL projects. We make use of a predictive Recursive-Convolutional Neural Network with ResNet-50 backbone provided by Detectron2 . A deeper explanation of the network functionality can be found here and here . Even with different parameters set, it was observed that predictions were including too much false positives, which were mainly made of snow. Most probably the reflectance of snow is similar to the one of quarries and this needed a special treatment. For this purpose, a filtering of the results was used. First of all the features were filtered based on the score values (0.9) and then by elevation, using the SRTM digital elevation model. As snow usually does not precipitate below around 1155 m, this was used as threshold. Finally an area threshold is also passed (using smallest predictions area) and predictions are merged. A more detailed description of how to operate this first filter can be seen here . Once several tests were performed, the new predictions were sent back to the domain expert for detailed revision with a rigid protocol. This included the removal of false positives and the inclusion of false negatives, mainly. This was performed by 4 different experts from swisstopo in 4 regions with the same amount of tiles to be analyzed. It is important to the state again the importance of domain expertise in this step, as a very careful and manual evaluation of what is and what is not a quarry must be made. Once the predictions were corrected, a new session of training was performed using different parameters. Once again, the same resolution and tile size were used as in the first iteration (512x512m tiles with 512x512 pixels of resolution), although this time a new filtering was developed. Very similar to the first one, but in a different order, allowing more aesthetical predictions in the end, something the domain expert was also carrying about. This procedure is summarized in figure 2. Figure 2 : Methodology applied for the detection of quarries and new training sessions. In the end, in order to also include the geological information of the detected quarries, a third layer resulting of the intersection of both the predictions and the GeoCover labels is created. This was done in a way that the final user can click to obtain both information on the quarry (when not a pure prediction) and the information of the geology/lithology on this part of the quarry. As a result, each resulting intersection poylgon contains both information from quarry and GeoCover. In order to evaluate the obtained results, the F1 Score was computed and also the final predictions were compared to the corrected labels from the domain expert side. This was done visually by acquiring the centroid of each quarry detected and by a heat-map, allowing one to detect the spatial pattern of detections. The heat-map was computed using 10'000 m radius and a 100 m pixel size.","title":"2 - Methodology"},{"location":"PROJ-DQRY/#3-results-discussion","text":"In the first iteration, when the neural was trained with some labels of the TLM vector data, an optimal F1 score of approximately 0.78 was obtained. The figure 3 shows the behavior of the precision, recall and F1 score for the final model selected. Figure 3 : Precision, Recall and F1 score of the first iteration (using TLM data). Given the predictions resulting from the correction by the domain experts, there was an outstanding improve in the F1 score obtained, which was of approximately 0.85 in its optimal, as seen in figure 4. A total of 1265 were found in Switzerland after filtering. Figure 4 : Precision, Recall and F1 score of the second iteration (using data corrected by the domain expert). Figure 5 demonstrates some examples of detected quarries and this one can have some notion of the quality of the shape of the detections and how they mark the real-world quarries. Examples of false positives and false negatives, unfortunately still present in the detections are also shown. This is also an interesting demonstration of how some objects that are very similar to quarries, in the point of view of non-experts and how they may influence the results. These examples of errors are also an interesting indication of the importance of domain expertise in evaluating machine made results. Figure 5 : Examples of detected quarries, with true positive, false negative and false positive. To check on the validity of the new predictions generated, the centroid of them was plot along the centroid of the corrected labels, so one could check the spatial pattern of them and this way evaluate if they were respecting the same behavior. Figure 6 shows this plot. Figure 6 : Disposition of the centroids of assessed predictions and final predictions. One can see that despite some slight differences, the overall pattern is very similar among the disposition of the predictions. A very similar result can be seen with the computed heat-map of these points, seen in figure 7. Figure 7 : Heatmap of assessed predictions and final predictions. There is a small area to the west of the country where there were less detections than desired and in general there were more predictions than before. The objective of the heat-map is more to give a general view of the results than giving an exact comparison, as a point is created for every feature and the new filter used tended to smooth the results and join many features into a single one too. At the end the results were also intersected with GeoCover, which provide the Swiss soil detailed lithology, and an example of the results can be seen below using the QGIS Software. Figure 8 : Intersection of predictions with GeoCover seen in QGIS. Finally and most important, the domain expert was highly satisfied with this work, due to the support it can give to swisstopo and the TLM team in mapping the future quarries. The domain expert also demonstrated interest in pursuing the work by investigating the temporal pattern of quarries and detecting the volume of material in each quarry.","title":"3 - Results &amp; Discussion"},{"location":"PROJ-DQRY/#4-conclusion","text":"Through this collaboration with swisstopo, we managed to demonstrate that data science is able to provide relevant and efficient tool to ease complex and time-consuming task. With the produced inventory of the quarries on the whole Swiss territory, we were able to provide a quasi-exhaustive view of the situation to the domain expert, leading him to have a better view of the exploitation sites. This is of importance and a major step forward compared to the previous situation. Indeed, before this project, the only solution available to the domain expert was to gather all the federal and cantonal data, through non-standardized and time-consuming process, to hope having a beginning of an inventory, with temporality issues. With the developed prototype, within hours, the entire SWISSIMAGE data-set can be processed and turn into a full scale inventory, guiding the domain expert directly toward its interests. The resulting geographical layer can then be seen as the result of this demonstrator, able to turn the aerial images into a simple polygonal layer representing the quarries, with little false positive and false negative, providing the required view for the domain expert understanding of the Swiss situation. With such a result, it is possible to convolve it with all the other existing data, with the GeoCover in the first place. This lithology model of the Swiss soil can be intersected with the produced quarries layer in order to create a secondary geographical layer merging both quarries location and quarries soil type, leading to a powerful analyzing tool for the domain expert. The produced demonstrator shows that it is possible, in hours, to deduce a simple and reliable geographical layer based on a simple set of orthomosaic. The STDL then was able to prove the possibility to repeat the process along the time dimension, for future and past images, opening the way to build and rebuild the history and evolution of the quarries. With such a process, it will be possible to compute statistical quantities on the long term to catch the evolution and the resources, leading to more reliable strategical understanding of the Swiss resources and sovereignty.","title":"4 - Conclusion"},{"location":"PROJ-DQRY-TM/","text":"Automatic detection and observation of mineral extraction sites in Switzerland \u00b6 Cl\u00e9mence Herny (Exolabs), Shanci Li (Uzufly), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve), Roxane Pott (swisstopo) Proposed by swisstopo - PROJ-DQRY-TM October 2022 to February 2023 - Published on January 2024 Abstract : Studying the evolution of mineral extraction sites (MES) is of primary importance for assessing the availability of mineral resources, managing MES and evaluating the impact of mining activity on the environment. In Switzerland, MES are inventoried at local level by the cantons and at federal level by swisstopo. The latter performs manual vectorisation of MES boundaries. Unfortunately, although the data is of high quality, it is not regularly updated. To automate this tedious task and to better observe the evolution of MES, swisstopo has solicited the STDL to carry out an automatic detection of MES in Switzerland over the years. We performed instance segmentation using a deep learning method to automatically detect MES in RGB aerial images with a spatial resolution of 1.6 m px -1 . The detection model was trained with 266 labels and orthophotos from the SWISSIMAGE RGB mosaic published in 2020. The selected trained model achieved a f1-score of 82% on the validation dataset. The model was used to do detection by inference of potential MES in SWISSIMAGE RGB orthophotos from 1999 to 2021. The model shows good ability to detect potential MES with about 82% of labels detected for the 2020 SWISSIMAGE mosaic. The detections obtained with SWISSIMAGE orthophotos acquired over different years can be tracked to observe their temporal evolution. The framework developed can perform detection in an area of interest (about a third of Switzerland at the most) in just a few hours, which is a major advantage over manual mapping. We acknowledge that there are some missed and false detections in the final product, and the results need to be reviewed and validated by domain experts before being analysed and interpreted. The results can be used to perform statistics over time and update MES evolution in future image acquisitions. 1. Introduction \u00b6 1.1 Context \u00b6 Mineral extraction constitutes a strategic activity worldwide, including in Switzerland. Demand for mineral resources has been growing significantly in recent decades 1 , mainly due to the rapid increase in the production of batteries and electronic chips, or buildings construction, for example. As a result, the exploitation of some resources, such as rare earth elements, lithium, or sand, is putting pressure on their availability. Being able to observe the development of mineral extraction sites (MES) is of primary importance to adapting mining strategy and anticipating demand and shortage. Mining has also strong environmental and societal impact 2 3 . It implies the extraction of rocks and minerals from water ponds, cliffs, and quarries. The surface affected, initially natural areas, can reach up to thousands of square kilometres 1 . The extraction of some minerals could lead to soil and water pollution and involves polluting truck transport. Economic and political interests of some resources might overwhelm land protection, and conflicts are gradually intensifying 2 . MES are dynamic features that can evolve according to singular patterns, especially if they are small, as is the case in Switzerland. A site can expand horizontally and vertically or be filled to recover the site 4 2 3 5 . Changes can happen quickly, in a couple of months. As a results, updating the MES inventory can be challenging. There is a significant demand for effective MES observation of development worldwide. Majority of MES mapping is performed manually by visual inspection of images 1 . Alternatively, recent improvements in the availability of high spatial and temporal resolution space/airborne imagery and computational methods have encouraged the development of automated image processing. Supervised classification of spectral images is an effective method but requires complex workflow 6 4 2 . More recently, few studies have implemented deep learning algorithms to train models to detect extraction sites in images and have shown high levels of accuracy 3 . In Switzerland, MES management is historically regulated on a canton-based level using GIS data, including information about the MES location, extent, and extracted materials among others. At the federal level, swisstopo and the Federal Office of Statistics (FSO) observe the development of MES. swisstopo has carried out a detailed manual delineation of MES based on SWISSIMAGE dataset over Switzerland. In the scope to fasten and improving the process of MES mapping in Switzerland, we developed a method for automating MES detection over the years. Ultimately, the goal is to keep the database up to date when new images are acquired. The results can be statistically process to better assess the MES evolution over time in Switzerland. 1.2. Approach \u00b6 The STDL has developed a framework named object-detector to automatically detect objects in a georeferenced imagery dataset based on deep learning method. The framework can be adapted to detect MES (also referred as quarry in the project) in Switzerland. A project to automatically detect MES in Switzerland 7 has been carried out by the STDL in 2021 ( detector-interface framework). Detection of potential MES obtained by automatic detection on the 2020 SWISSIMAGE mosaic has already been delivered to swisstopo (layer 2021_10_STDL_QC1 ). The method has proven its efficiency detecting MES. The numerical model trained with the object detector achieved a f1-score of 82% and detected about 1200 potential MES over Switzerland. In this project, we aim to continue this work and extend it to a second objective, that of observing MES evolution over time. The main challenge is to prove the algorithm reliability for detecting objects in a multi-year dataset images acquired with different sensors. The project workflow is synthesised in Figure 1. First, a deep learning algorithm is trained using a manually mapped MES dataset that serves as ground truth (GT). After evaluating the performance of the trained model, the selected one was used to perform inference detection for a given year dataset and area of interest (AoI). The results were filtered to discard irrelevant detection. The operation was repeated over several years. Finally, each potential MES detected was tracked over the years to observe its evolution. Figure 1: Workflow diagram for automatic MES detection. In this report, we first describe the data used, including the image description and the definition of AoI. Then we explain the model training, evaluation and object detection procedure. Next, we present the results of potential MES detection and the MES tracking strategy. Finally, we provide conclusion and perspectives. 2. Data \u00b6 2.1 Images and area of interest \u00b6 Automatic detection of potential MES over the years in Switzerland was performed with aerial orthophotos from the swisstopo product SWISSIMAGE Journey . Images are georeferenced RGB TIF tiles with a size of 256 x 256 pixels (1 km 2 ). Product Year Coordinate system Spatial resolution SWISSIMAGE 10 cm 2017 - current CH1903+/MN95 (EPSG:2056) 0.10 m ( \\(\\sigma\\) \\(\\pm\\) 0.15 m) - 0.25 m SWISSIMAGE 25 cm 2005 - 2016 MN03 (2005 - 2007) and MN95 (since 2008) 0.25 m ( \\(\\sigma\\) \\(\\pm\\) 0.25 m) - 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 3.00 - 5.00 m) SWISSIMAGE 50 cm 1998 - 2004 MN03 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 0.50 m) Table 1: SWISSIMAGE products characteristics. Several SWISSIMAGE products exist, produced from different instrumentation (Table 1). SWISSIMAGE mosaics are built and published yearly. The year of the mosaic corresponds to the last year of the dataset publication, and the most recent orthophotos datasets available are then used to complete the mosaic. For example the 2020 SWISSIMAGE mosaic is a combination of 2020, 2019 and 2018 images acquisition. The 1998 mosaic release corresponds to a year of transition from black and white images ( SWISSIMAGE HIST ) to RGB images. For this study, only RGB data from 1999 to 2021 were considered. Figure 2: Acquisition footprint of SWISSIMAGE aerial orthophotos for the years 2016 to 2021. The SWISSIMAGE Journey mosaic in the background is the 2020 release. Acquisition footprints of yearly acquired orthophotos were used as AoI to perform MES detection through time. Over the years, the footprints may spatially overlap (Fig. 2). Since 2017, the geometry of the acquisition footprints has been quasi-constant, dividing Switzerland into three more or less equal areas, ensuring that the orthophotos are updated every three years. For the years before 2017, the acquisition footprints were not systematic and do not guarantee a periodically update of the orthophotos. The acquisition footprint may also not be spatially contiguous. Figure 3: Illustration of the combination of SWISSIMAGE images and FSO images for the 2007 SWISSIMAGE mosaic. (a) Overview of the 2007 SWISSIMAGE mosaic. The red polygon corresponds to the provided SWISSIMAGE acquisition footprint for 2007. The orange polygon corresponds to the surface covered by the new SWISSIMAGE for 2007. The remaining area of the red polygon corresponds to the FSO image dataset acquired in 2007. The black box indicates the panel (b) location, and the white box indicates the panel (c) location. (b) Side-by-side comparison of image composition in 2006 and 2007 SWISSIMAGE mosaics. (c) Examples of detection polygons (white polygons) obtained by inference on the 2007 SWISSIMAGE dataset (red box) and FSO images 2007 (outlined by black box). SWISSIMAGE Journey mosaics of 2005, 2006, and 2007 present a particularity as it is composed not only of 25 cm resolution SWISSIMAGE but also of orthophotos acquired for the FSO. These are tiff RGB orthophotos with a spatial resolution of 50 cm px -1 (coordinate system: CH1903/LV03 (EPSG:21781)) and have been integrated into the SWISSIMAGE Journey products. However, these images were discarded (modification of the footprint shape) from our dataset because they were causing issues in the MES automatic detection producing odd segmented detection shapes (Fig. 3). This is probably due to the different stretching of pixel colour between datasets. It also has to be noted that there are currently missing images (about 88 tiles at zoom level 16) in the 2020 SWISSIMAGE dataset. 2.2 Image fetching \u00b6 Pre-rendered SWISSIMAGE tiles (256 x 256 px, 1 km 2 ) are downloaded using the Web Map Tile Service (WMTS) wmts.geo.admin.ch via an XYZ connector. Tiles are served on a cartesian coordinates grid using a Web Mercator Quad projection and a coordinate reference system EPGS 3857. Position of a tile on the grid is defined by x and y coordinates and the pixel resolution of the image is defined by z , its zoom level. Changing the zoom level affects the resolution by a factor of 2 (Fig. 4). For instance a zoom level of 17 corresponds to a resolution of 0.8 m px -1 and a zoom level of 16 to a resolution of 1.6 m px -1 . Figure 4: Examples of tiles geometry at zoom level 16 (z16, black polygons) and at zoom level 17 (z17, blue polygons). The number of tiles for each zoom level is indicated in square brackets. The tiles are selected for model training, i.e. only tiles intersecting swissTLM3D labels (tlm-hr-trn-topo, yellow polygons). Note that in the subsequent project carried out by Reichel and Hamel (2021) 7 , the tiling method adopted was slightly different from the one adopted for this project. Custom size and resolution tiles were built. A sensitivity analysis of these two parameters was conducted and led to the choice of tiles with a size of about 500 m and a pixel resolution of about 1 m (above, the performance was not significantly improved). 2.3 Ground truth \u00b6 The MES labels originate from the swiss Topographic Landscape Model 3D ( swissTLM3D ) produced by swisstopo . swissTLM3D is a large-scale topographic landscape model of Switzerland, including manually drawn and georeferenced vectors of objects of interest at a high resolution, including MES features. Domain experts from swisstopo have carried out extensive work to review the labeled MES and to synchronise them with the 2020 SWISSIMAGE mosaic to improve the quality of the labeled dataset. A total of 266 labels are available. The mapped MES reveal the diversity of MES characteristics, such as the presence or absence of buildings/infrastructures, trucks, water pounds, and vegetation (Fig. 5). Figure 5: Examples of MES mapped in swissTLM3D and synchronised to 2020 SWISSIMAGE mosaic. These labels are used as the ground truth (GT) i.e. the reference dataset indicating the presence of a MES in an image. The GT is used both as input to train the model to detect MES and to evaluate the model performance. 3. Automatic detection methodology \u00b6 3.1 Deep learning algorithm for object detection \u00b6 Training and inference detection of potential MES in SWISSIMAGE were performed with the object detector framework. This project is based on the open source detectron2 framework 8 implemented with PyTorch by the Facebook Artificial Intelligence Research group (FAIR). Instance segmentation (delineation of object) was performed with a Mask R-CNN deep learning algorithm 9 . It is based on a Recursive-Convolutional Neural Network (CNN) with a backbone pre-trained model ResNet-50 (50 layers deep residual network). Images were annotated with custom COCO object based on the labels (class 'Quarry'). The model is trained with this dataset to later perform inference detection on images. If the object is detected by the algorithm, a pixel mask is produced with a confidence score (0 to 1) attributed to the detection (Fig. 6). Figure 6: Example of detection mask. The pink rectangle corresponds to the bounding box of the object, the object is segmented by the pink polygons associated with the detection class ('Quarry') and a confidence score. The object detector framework permits to convert detection mask to georeferenced polygon that can be used in GIS softwares. The implementation of the Ramer-Douglas-Peucker ( RDP ) algorithm, allows the simplification of the derived polygons by discarding non-essential points based on a smoothing parameter. This allow to considerably reduces the amount of data to be stored and prevent potential memory saturation while deriving detection polygons on large areas as it is the case for this study. 3.2 Model training \u00b6 Orthophotos from the 2020 SWISSIMAGE mosaic, for which the GT has been defined, were chosen to proceed the model training. Tiles intersecting labels were selected and split randomly into three datasets: the training dataset (70%), the validation dataset (15%), and the test dataset (15%). Addition of empty tiles (no annotation) to confront the model to landscapes not containing the target object has been tested ( Appendix A.1 ) but did not provide significant improvement in the model performance to be adopted. Figure 7: Training curves obtained at zoom level 16 on the 2020 SWISSIMAGE mosaic. The curves were obtained for the trained model 'replicate 3'. (a) Learning rate in function of iteration. The step was defined every 500 iterations. The initial learning rate was 5.0 x 10 -3 with a weight and bias decay of 1.0 x 10 -4 . (b) The total loss is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. (c) The validation loss curve is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. The vertical dashed black lines indicate the iteration minimising the validation loss curve, i.e. 3000. Models were trained with two images per batch ( Appendix A.2 ), a learning rate of 5 x 10 -3 , and a learning rate decay of 1 x 10 -4 every 500 steps (Fig. 7 (a)). For the given model, parameters and a zoom level of 16 ( Section 3.3.3 ), the training is performed over 7000 iterations and lasts about 1 hour on a 16 GiB GPU (NVIDIA Tesla T4) machine compatible with CUDA . The total (train and validation loss) loss curve decreases until reaching a quasi-steady state around 6000 iterations (Fig. 7 (b)). The optimal detection model corresponds to the one minimising the validation loss curve. This minimum is reached between 2000 and 3000 iterations (Fig. 7 (c)). 3.3 Metrics \u00b6 The model performance and detection reliability were assessed by comparing the results to the GT. The detection performed by the model can be either (1) a True Positive (TP), i.e. the detection is real (spatially intersecting the GT) ; (2) a False Positive i.e. the detection is not real (not spatially intersecting the GT) or (3) a False Negative (FN) i.e. the labeled object is not detected by the algorithm (Fig. 8). Tagging the detection (Fig. 9(a)) allows to calculate several metrics (Fig. 9(b)) such as: Figure 8: Examples of different detection cases. Label is represented with a yellow polygon and detection with a red polygon. (a) True Positive (TP) detection intersecting the GT, (b) a potential True Positive (TP?) detection with no GT, (c) False Negative (FN) case with no detection while GT exists, (d) False Positive (FP) detection of object that is not a MES. the recall , translating the amount of TP detections predicted by the model: \\[recall = \\frac{TP}{(TP + FN)}\\] the precision , translating the number of well-predicted TP among all the detections: \\[precision = \\frac{TP}{(TP + FP)}\\] the f1-score , the harmonic average of the precision and the recall: \\[f1 = 2 \\times \\frac{recall \\times precision}{recall + precision}\\] Figure 9: Evaluation of the trained model performance obtained at zoom level 16 for the trained model 'replicate 3' (Table 2). (a) Number of TP (blue), FN (red), and FP (green) as a function of detection score threshold for the validation dataset. (b) Metrics value, precision (blue), recall (red), and f1-score (green) as a function of the detection score threshold for the validation dataset. The maximum f1-score value is 82%. 4. Automatic detection model analysis \u00b6 4.1. Model performance and replicability \u00b6 Trained models reached f1-scores of about 80% with a standard deviation of 2% (Table 2). The performances are similar to the model trained by Reichel and Hamel (2021) 7 . model precision recall f1 replicate 1 0.84 0.79 0.82 replicate 2 0.77 0.76 0.76 replicate 3 0.83 0.81 0.82 replicate 4 0.89 0.77 0.82 replicate 5 0.78 0.82 0.80 Table 2: Metrics value computed for the validation dataset for trained models replicates with the 2020 SWISSIMAGE mosaic at zoom level 16. A variability is expected as the deep learning algorithm displays some random behavior, but it is supposed to be negligible. However, the observed model variability is enough to affect final results that might slightly change by using different trained models with same input parameters (Fig. 10). Figure 10: Detection polygons obtained for the different trained model replicates (Table 2) highlighting results variability. The labels correspond to orange polygons. The number in the square bracket corresponds to the number of polygons. The inference detections have been performed on a subset of 2000 tiles for the 2020 SWISSIMAGE at zoom level 16. Detections have been filtered according to the parameters defined in Section 5.1. To reduce the variability of the trained models, the random seeds of both detectron2 and python have been fixed. Neither of these attempts have been successful, and the variability remains. The nondeterministic behavior of detectron2 has been recognised ( issue 1 , issue 2 ), but no suitable solution has been provided yet. Further investigation on the model performance and consistency should be performed in the future. To mitigate the results variability of model replicates, we could consider in the future to combine the results of several model replicates to remove FP while preserving the TP and potential TP detection. The choice and number of models used should be evaluated. This method is tedious as it requires inference detection from several models, which can be time-consuming and computationally intensive. 4.2 Sensitivity to the zoom level \u00b6 Image resolution is dependent on the zoom level ( Section 2.2 ). To select the most suitable zoom level for MES detection, we performed a sensitivity analysis on trained model performance. Increasing the zoom level increases the value of the metrics following a global linear trend (Fig. 11). Figure 11: Metrics values (precision, recall and f1) as function of zoom level for the validation dataset. The results of the replicates performed at each zoom level are included (Table A1). Models trained at a higher zoom level performed better. However, a higher zoom level implies smaller tile and thus, a larger number of tiles to fill the AoI. For a typical AoI, i.e up to a third of Switzerland, this can lead to a large number of tiles to be stored and processed, leading to potential RAM and/or disk space saturation. For 2019 AoI, 89'290 tiles are required at zoom level 16 while 354'867 tiles are required at zoom level 17, taking respectively 3 hours and 11 hours to process on a 30 GiB RAM machine with a 16 GiB GP. Visual comparison of inference detection reveals that there was no significant improvement in the object detection quality from zoom level 16 to zoom level 17. Both zoom level present a similar proportion of detections intersecting labels (82% and 79% for zoom level 16 and zoom level 17 respectively). On the other hand, the quality of object detection at zoom level 15 was depreciated. Indeed, detection scores were lower, with only tens of detection scores above 0.95 while it was about 400 at zoom level 16 and about 64% of detection intersecting labels. 4.3 Model choice \u00b6 Based on tests performed, we selected the 'replicate 3' model, obtained (Tables 2 and A1) at zoom level 16, to perform inference detection. Models trained at zoom level 16 (1.6 m px -1 pixel resolution) have shown satisfying results in accurately detecting MES contour and limiting the number of FP with high detection score (Fig. 11). It represents a good trade-off between results reliability (f1-score between 76% and 82% on the validation dataset) and computational resources. Then, among all the replicates performed at zoom level 16, we selected the trained model 'replicate 3' (Table 2) because it combines both the highest metrics values (for the validation dataset but also the train and test datasets), close precision and recall values and a rather low amount of low score detections. 5. Automatic detection of MES \u00b6 5.1 Detection post-processing \u00b6 Detection by inference was performed over AoIs with a threshold detection score of 0.3 (Fig. 12). The low score filtering results in a large amount of detections. Several detections may overlap, potentially segmenting a single object. In addition a detection might be split into multiple tiles. To improve the pertinence and the aesthetics of the raw detection polygons, a post-processing procedure was applied. First, a large proportion of FP occurred in mountainous areas (rock outcrops and snow, Fig. 12(a)). We assumed MES are not present (or at least sparse) above a given altitude. An elevation filtering was applied using a Switzerland Digital Elevation Model (about 25 m px -1 ) derived from the SRTM instrument ( USGS - SRTM ). The maximum elevation of the labeled MES is about 1100 m. Second, detection aggregation was applied: - polygons were clustered ( K-means ) according to their centroid position. The method involves setting a predefined number k of clusters. Manual tests performed by Reichel and Hamel (2021) 7 concluded to set k equal to the number of detection divided by three. The highest detection score was assigned to the clustered detection. This method preserves the final integrity of detection polygons by retaining detection that has potentially a low confidence score but belongs to a cluster with a higher confidence score improving the final segmentation of the detected object. The value of the threshold score must be kept relatively low ( i.e. 0.3) when performing the detection to prevent removing too many polygons that could potentially be part of the detected object. We acknowledge that determining the optimal number of clusters by clustering validation indices rather than manual adjustment would be more robust. In addition, exploring other clustering methods, such as DBSCAN , based on local density, can be considered in the future. - score filtering was applied. - spatially close polygons were assumed to belong to the same MES and are merged according to a distance threshold. The averaged score of the merged detection polygons was ultimately computed. Finally, we assumed that a MES covers a minimal area. Detection with an area smaller than a given threshold were filtered out. The minimum MES area in the GT is 2270 m 2 . Figure 12: MES detection filtering. (a) Overview of the automatic detection of MES obtained with 2020 SWISSIMAGE at zoom level 16. Transparent red polygons (with associated confidence score in white) correspond to the raw object detection output and the red line polygons (with associated confidence score in red) correspond to the final filtered detection. The black box outlines the location of the (b) and (c) panel zoom. Note the large number of detection in the mountains (right area of the image). (b) Zoom on several raw detections polygons of a single object with their respective confidence score. (c) Zoom on a filtered detection polygon of a single object with the resulting score. Sensitivity of detections to these filters was investigated (Table 3). The quantitative evaluation of filter combination relevance is tricky as potential MES presence is performed by inference, and the GT provided by swissTLM3D constitutes an incomplete portion of the MES in Switzerland (2020). As indication, we computed the number of spatial intersection between ground truth and detection obtained with the 2020 SWISSIMAGE mosaic. Filter combination number 3 was adopted, allowing to detect about 82% of the GT with a relatively limited amount of FP detection compared to filter combinations 1 and 2 (from visual inspection). filters combination score threshold elevation threshold (m) area threshold (m 2 ) distance threshold (m) number of detection label detection (%) 1 0.95 2000 1100 10 1745 85.1 2 0.95 2000 1200 10 1862 86.6 3 0.95 5000 1200 10 1347 82.1 4 0.96 2000 1100 10 1331 81.3 5 0.96 2000 1200 8 1445 78.7 6 0.96 5000 1200 10 1004 74.3 Table 3: Threshold values of filtering parameters and their respective number of detections and intersection proportion with swissTLM3D labels. The detections have been obtained for the 2020 SWISSIMAGE mosaic. We acknowledged that for the selected filter combination, the area threshold value is higher than the smallest area value of the GT polygons. However, reducing the area value increases significantly the presence of FP. Thirteen labels display an area below 5000 m 2 . 5.2 Inference detections \u00b6 The trained model was used to perform inference detection on SWISSIMAGE orthophotos from 1999 to 2021. The automatic detection model shows good capabilities to detect MES in different years orthophotos (Fig. 13), despite being trained on the 2020 SWISSIMAGE mosaic. The model also demonstrates capabilities to detect potential MES that have not been mapped yet but are strong candidates. However, the model misses some labeled MES or potential MES (FN, Fig. 8). However, when the model process FSO images, with different colour stretching, it failed to correctly detect potential MES (Fig. 3). It reveals that images must have characteristics close to the training dataset for optimal results with a deep learning model. Figure 13: Examples of object detection segmented by polygons in different year orthophotos. The yellow polygon for the year 2020 panel of object ID 3761 corresponds to the label. Other coloured polygons correspond to the algorithm detection. Then, we acknowledge that a significant amount of FP detection can still be observed in our filtered detection dataset (Figs. 8 and 14). The main sources of FP are the presence of large rock outcrops, mountainous areas without vegetation, snow, river sand beds, brownish-coloured fields, or construction areas. MES present a large variety of features (buildings, water pounds, trucks, vegetation) (Fig. 5) which can be a source of confusion for the algorithm but even sometimes for human eye. Therefore, the robustness of the GT is crucial for reliable detection. The algorithm's results should be taken carefully. Figure 14: Examples of FP detection. (a) Snow patches (2019) ; (b) River sand beds and gullies (2019); (c) Brownish field (2020); (d) vineyards (2005); (e) Airport tarmac (2020); (f) Construction site (2008). The detections produced by the algorithm are potential MES, but the final results must be reviewed by experts in the field to discard remaining FP detection and correct FN before any processing or interpretation. 6. Observation of MES evolution \u00b6 6.1 Object tracking strategy \u00b6 Switzerland is covered by RGB SWISSIMAGE product over more than 20 years (1999 to actual), allowing changes to be detected (Fig. 13). Figure 15: Strategy for MES tracking over time. ID assignment to detection. Spatially intersecting polygons share the same ID allowing the MES to be tracked in a multi-year dataset. We assumed that detection polygons that overlap from one year to another describe a single object (Fig. 15). Overlapping detections and unique detections (which do not overlap with polygons from other years) in the multi-year dataset were assigned a unique object identifier (ID). A new object ID in the timeline indicates: - the first occurrence of the object detected in the dataset of the first year available for the area. It does not mean that the object was not present before, - the creation of a potential new MES. The disappearance of an object ID indicates its potential refill. Therefore, the chronology of MES, creation, evolution and filling, can be constrained. 6.2 Evolution of MES over years \u00b6 Figures 13 and 16 illustrate the ability of the trained model to detect and track a single object in a multi-year dataset. The detection over the years appears reliable and consistent, although object detection may be absent from a year dataset ( e.g. due to shadows or colour changes in the surroundings). Remember that the image coverage of a given area is not renewed every year. Characteristics of the potential MES, such as surface evolution (extension or retreat), can be quantified. For example, the surfaces of object IDs 239 and 3861 have more than doubled in about 20 years. Tracking object ID along with image visualisation allows observation of the opening and the closing of potential MES, as object IDs 31, 44, and 229. Figure 16: Detection area (m 2 ) as a function of years for several object ID. Figure 13 provides the visualisation of the object IDs selected. Each point corresponds to an object ID occurrence in the corresponding year dataset. The presence of an object in several years dataset strengthens the likeliness of the detected object to be an actual MES. On the other hand, object detection of only one occurrence is more likely a FP detection. 7. Conclusion and perspectives \u00b6 The project demonstrated the ability to automatically, quickly (a matter of hours for one AoI), and reliably detect potential MES in orthophotos of Switzerland with an automatic detection algorithm (deep learning). The selected trained model achieved a f1-score of 82% on the validation dataset. The final detection polygons accurately delineate the potential MES. We can track single MES through multiple years, emphasising the robustness of the method to detect objects in multi-year datasets despite the detection model being trained on a single dataset (2020 SWISSIMAGE mosaic). However, image colour stretching different from that used to train the model can significantly affect the model's ability to provide reliable detection, as was the case with the FSO images. Although the performance of the trained model is satisfactory, FP and FN are present in the datasets. They are mainly due to confusion of the algorithm between MES and rock outcrops, river sandbeds or construction sites. A manual verification of the relevance of the detection by experts in the field is necessary before processing and interpreting the data. Revision of all the detections from 1999 to 2021 is a time-consuming effort but is necessary to guarantee detection reliability. Despite the required manual checks, the provided framework and detection results constitute a valuable contribution that can greatly assist the inventory and the observation of MES evolution in Switzerland. It provides state-wide detection in a matter of hours, which is a considerable time-saving compared with manual mapping. It also enables MES detection with a standardised method, independent of the information or method adopted by the cantons. Further model improvements could be consider, such as increasing the metrics by improving GT quality, improving model learning strategy, mitigating the model learning variability, or test supervised clustering methods to find relevant detection. This work can be used to compute statistics to study long-term MES in Switzerland and better management of resources and land use in the future. MES detection can be combined with other data, such as the geologic layer, to identify the mineral/rocks exploited and high-resolution DEM ( swissALTI3D ) to infer elevation changes and observe excavation or filling of MES 5 . So far only RGB SWISSIMAGE orthophotos from 1999 to 2021 were processed. Prior to 1999, black and white orthophotos exist but the model trained on RGB images could not be applied trustfully to black and white images. Image colourisation tests (with the help of deep learning algorithm[@farella_colour_2022]) were performed and provided encouraging detection results. This avenue needs to be explored. Finally, automatic detection of MES is rare 1 3 , and most studies perform manual mapping. Therefore, the framework could be the extended to other datasets and/or other countries to provide a valuable asset to the community. A global mapping of MES has been completed with over 21'000 polygons 1 and can be used as a GT database to train an automatic detection model. Code availability \u00b6 The codes are stored and available on the STDL's github repository: proj-dqry : mineral extraction site framework object-detector : object detector framework Acknowledgements \u00b6 This project was made possible thanks to a tight collaboration between the STDL team and swisstopo . In particular, the STDL team acknowledges key contribution from Thomas Galfetti ( swisstopo ). This project has been funded by \"Strategie Suisse pour la G\u00e9oinformation\". Appendix \u00b6 A.1 Influence of empty tiles addition to model performance \u00b6 By selecting tiles intersecting only labels, the detection model is mainly confronted with the presence of the targeted object to be detected. Addition of non-label-intersecting tiles, i.e. empty tiles, provides landscape diversity that might help to improve the object detection performance. In order to evaluate the influence of adding empty tiles to the dataset used for the model performance, empty tiles were chosen randomly (not intersecting labels) within Switzerland boundaries and added to the tile dataset used for the model training (Fig. A1). Empty tiles were added to (1) the whole dataset split as for the initial dataset (training: 70%, test: 15%, and validation: 15%) and (2) only to the training dataset. A visual inspection must be performed to prevent a potential unlabeled MES to be present in the image and disturbing the algorithm learning. Figure A1: View of tiles intersecting (black) labels (yellow) and randomly selected empty tiles (red) in Switzerland. This case correspond to the addition of 35% empty tiles. Figure A1 reveals that adding empty tiles to the dataset does not significantly influence the metrics values. The number of TP, FP, and FN do not show significant variation. However, when performing an inference detection test on a subset of tiles (2000) for an AOI, it appears that the number of raw detections (unfiltered) is reduced as the number of empty tiles increases. However, visual inspection of the final detection after applying filters does not show significant improvement compared to a model trained without adding empty tiles. Figure A1: Influence of the addition of empty tiles (relative to the number of tiles intersecting labels) on trained performance for zoom levels 16 and 17 with (a) the F1-score as a function of the percentage of added empty tiles and (b) the normalised (by the number of tiles sampled = 2000) number of detection as a function of added empty tiles. Empty tiles have been added to only the train dataset for the 5% and 30% cases and to all datasets for 9%, 35%, 70%, and 140% cases. A considered solution to improve the results could be to specifically select tiles for which FP occurred and include them in the training dataset as empty tiles. This way, the model could be trained with relevant confounding features such as snow patches, river sandbeds, or gullies not labeled as GT. A.2 Sensitivity of the model to the number of images per batch \u00b6 During the model learning phase, the trained model is updated after each batch of samples was processed. Adding more samples, i.e. in our case images, to the batch can influence the model learning capacity. We investigated the role of adding more images per batch for a dataset with and without adding a portion of empty tiles to the learning dataset. Adding more images per batch speeds up the model learning (Table A1), and the minimum of the loss curve is reached for a smaller number of iterations. Figure A2: Metrics (precision, recall and f1-score) evolution with the number of images per batch during the model training. Results have been obtained on a dataset without empty tiles addition (red) and with the addition of 23% of empty tiles to the training dataset. Figure A2 reveals that the metrics values remain in a range of constant values while adding extra images to the batch in all cases (with or without empty tiles). A potential effect of adding more images to the batch is the reduction of the metrics variability between replicates of trained models as the range of metrics values is smaller for 8 images per batch than 2 images per batch. However, this observation has to be taken carefully as fewer replicates have been performed with 8 images per batch than for 2 or 4 images per batch. Further investigation would provide stronger insights on this effect. A.3 Evaluation of trained models \u00b6 Table A1 sumup metrics value obtained for all the configuration tested for the project. zoom level model empty tiles (%) image per batch optimum iteration precision recall f1 15 replicate 1 0 2 1000 0.727 0.810 0.766 16 replicate 1 0 2 2000 0.842 0.793 0.817 16 replicate 2 0 2 2000 0.767 0.760 0.763 16 replicate 3 0 2 3000 0.831 0.810 0.820 16 replicate 4 0 2 2000 0.886 0.769 0.826 16 replicate 5 0 2 2000 0.780 0.818 0.798 16 replicate 6 0 2 3000 0.781 0.826 0.803 16 replicate 7 0 4 1000 0.748 0.860 0.800 16 replicate 8 0 4 1000 0.779 0.785 0.782 16 replicate 9 0 8 1500 0.800 0.793 0.797 16 replicate 10 0 4 1000 0.796 0.744 0.769 16 replicate 11 0 8 1000 0.802 0.769 0.785 16 ET-250_allDS_1 34.2 2 2000 0.723 0.770 0.746 16 ET-250_allDS_2 34.2 2 3000 0.748 0.803 0.775 16 ET-1000_allDS_1 73.8 2 6000 0.782 0.815 0.798 16 ET-1000_allDS_2 69.8 2 6000 0.786 0.767 0.776 16 ET-1000_allDS_3 70.9 2 6000 0.777 0.810 0.793 16 ET-1000_allDS_4 73.8 2 6000 0.768 0.807 0.787 16 ET-2000_allDS_1 143.2 2 6000 0.761 0.748 0.754 16 ET-80_trnDS_1 5.4 2 2000 0.814 0.793 0.803 16 ET-80_trnDS_2 5.4 2 2000 0.835 0.752 0.791 16 ET-80_trnDS_3 5.4 2 2000 0.764 0.802 0.782 16 ET-400_trnDS_1 29.5 2 6000 0.817 0.777 0.797 16 ET-400_trnDS_2 29.5 2 5000 0.848 0.785 0.815 16 ET-400_trnDS_3 29.5 2 4000 0.758 0.802 0.779 16 ET-400_trnDS_4 29.5 4 2000 0.798 0.818 0.808 16 ET-400_trnDS_5 29.5 4 1000 0.825 0.777 0.800 16 ET-1000_trnDS_1 0 2 4000 0.758 0.802 0.779 17 replicate 1 0 2 5000 0.819 0.853 0.835 17 replicate 1 0 2 5000 0.803 0.891 0.845 17 replicate 1 0 2 5000 0.872 0.813 0.841 17 ET-250_allDS_1 16.8 2 3000 0.801 0.794 0.797 17 ET-1000_allDS_1 72.2 2 7000 0.743 0.765 0.754 18 replicate 1 0 2 10000 0.864 0.855 0.859 Table A1: Metrics value computed for the validation dataset for all the trained models with the 2020 SWISSIMAGE Journey mosaic at zoom level 16. Victor Maus, Stefan Giljum, Jakob Gutschlhofer, Dieison M. Da Silva, Michael Probst, Sidnei L. B. Gass, Sebastian Luckeneder, Mirko Lieber, and Ian McCallum. A global-scale data set of mining areas. Scientific Data , 7(1):289, September 2020. URL: https://www.nature.com/articles/s41597-020-00624-w , doi:10.1038/s41597-020-00624-w . \u21a9 \u21a9 \u21a9 \u21a9 \u21a9 Vicen\u00e7 Carabassa, Pau Montero, Marc Crespo, Joan-Cristian Padr\u00f3, Xavier Pons, Jaume Balagu\u00e9, Llu\u00eds Brotons, and Josep Maria Alca\u00f1iz. Unmanned aerial system protocol for quarry restoration and mineral extraction monitoring. Journal of Environmental Management , 270:110717, September 2020. URL: https://linkinghub.elsevier.com/retrieve/pii/S0301479720306496 , doi:10.1016/j.jenvman.2020.110717 . \u21a9 \u21a9 \u21a9 \u21a9 Chunsheng Wang, Lili Chang, Lingran Zhao, and Ruiqing Niu. Automatic Identification and Dynamic Monitoring of Open-Pit Mines Based on Improved Mask R-CNN and Transfer Learning. Remote Sensing , 12(21):3474, January 2020. URL: https://www.mdpi.com/2072-4292/12/21/3474 , doi:10.3390/rs12213474 . \u21a9 \u21a9 \u21a9 \u21a9 Haoteng Zhao, Yong Ma, Fu Chen, Jianbo Liu, Liyuan Jiang, Wutao Yao, and Jin Yang. Monitoring Quarry Area with Landsat Long Time-Series for Socioeconomic Study. Remote Sensing , 10(4):517, April 2018. URL: https://www.mdpi.com/2072-4292/10/4/517 , doi:10.3390/rs10040517 . \u21a9 \u21a9 Valentin Tertius Bickel and Andrea Manconi. Decadal Surface Changes and Displacements in Switzerland. Journal of Geovisualization and Spatial Analysis , 6(2):24, December 2022. URL: https://link.springer.com/10.1007/s41651-022-00119-9 , doi:10.1007/s41651-022-00119-9 . \u21a9 \u21a9 George P. Petropoulos, Panagiotis Partsinevelos, and Zinovia Mitraka. Change detection of surface mining activity and reclamation based on a machine learning approach of multi-temporal Landsat TM imagery. Geocarto International , 28(4):323\u2013342, July 2013. URL: http://www.tandfonline.com/doi/abs/10.1080/10106049.2012.706648 , doi:10.1080/10106049.2012.706648 . \u21a9 Huriel Reichel and Nils Hamel. Automatic Detection of Quarries and the Lithology below them in Switzerland. 2022. URL: file:///C:/Users/Clemence/Documents/STDL/Projects/proj-quarries/01_Documentation/Bibliography/Automatic%20Detection%20of%20Quarries%20and%20the%20Lithology%20below%20them%20in%20Switzerland%20-%20Swiss%20Territorial%20Data%20Lab.htm . \u21a9 \u21a9 \u21a9 \u21a9 Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2. 2019. URL: https://github.com/facebookresearch/detectron2 . \u21a9 Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross Girshick. Mask R-CNN. January 2018. arXiv:1703.06870 [cs]. URL: http://arxiv.org/abs/1703.06870 , doi:10.48550/arXiv.1703.06870 . \u21a9","title":"Automatic detection and observation of mineral extraction sites in Switzerland"},{"location":"PROJ-DQRY-TM/#automatic-detection-and-observation-of-mineral-extraction-sites-in-switzerland","text":"Cl\u00e9mence Herny (Exolabs), Shanci Li (Uzufly), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve), Roxane Pott (swisstopo) Proposed by swisstopo - PROJ-DQRY-TM October 2022 to February 2023 - Published on January 2024 Abstract : Studying the evolution of mineral extraction sites (MES) is of primary importance for assessing the availability of mineral resources, managing MES and evaluating the impact of mining activity on the environment. In Switzerland, MES are inventoried at local level by the cantons and at federal level by swisstopo. The latter performs manual vectorisation of MES boundaries. Unfortunately, although the data is of high quality, it is not regularly updated. To automate this tedious task and to better observe the evolution of MES, swisstopo has solicited the STDL to carry out an automatic detection of MES in Switzerland over the years. We performed instance segmentation using a deep learning method to automatically detect MES in RGB aerial images with a spatial resolution of 1.6 m px -1 . The detection model was trained with 266 labels and orthophotos from the SWISSIMAGE RGB mosaic published in 2020. The selected trained model achieved a f1-score of 82% on the validation dataset. The model was used to do detection by inference of potential MES in SWISSIMAGE RGB orthophotos from 1999 to 2021. The model shows good ability to detect potential MES with about 82% of labels detected for the 2020 SWISSIMAGE mosaic. The detections obtained with SWISSIMAGE orthophotos acquired over different years can be tracked to observe their temporal evolution. The framework developed can perform detection in an area of interest (about a third of Switzerland at the most) in just a few hours, which is a major advantage over manual mapping. We acknowledge that there are some missed and false detections in the final product, and the results need to be reviewed and validated by domain experts before being analysed and interpreted. The results can be used to perform statistics over time and update MES evolution in future image acquisitions.","title":"Automatic detection and observation of mineral extraction sites in Switzerland"},{"location":"PROJ-DQRY-TM/#1-introduction","text":"","title":"1. Introduction"},{"location":"PROJ-DQRY-TM/#11-context","text":"Mineral extraction constitutes a strategic activity worldwide, including in Switzerland. Demand for mineral resources has been growing significantly in recent decades 1 , mainly due to the rapid increase in the production of batteries and electronic chips, or buildings construction, for example. As a result, the exploitation of some resources, such as rare earth elements, lithium, or sand, is putting pressure on their availability. Being able to observe the development of mineral extraction sites (MES) is of primary importance to adapting mining strategy and anticipating demand and shortage. Mining has also strong environmental and societal impact 2 3 . It implies the extraction of rocks and minerals from water ponds, cliffs, and quarries. The surface affected, initially natural areas, can reach up to thousands of square kilometres 1 . The extraction of some minerals could lead to soil and water pollution and involves polluting truck transport. Economic and political interests of some resources might overwhelm land protection, and conflicts are gradually intensifying 2 . MES are dynamic features that can evolve according to singular patterns, especially if they are small, as is the case in Switzerland. A site can expand horizontally and vertically or be filled to recover the site 4 2 3 5 . Changes can happen quickly, in a couple of months. As a results, updating the MES inventory can be challenging. There is a significant demand for effective MES observation of development worldwide. Majority of MES mapping is performed manually by visual inspection of images 1 . Alternatively, recent improvements in the availability of high spatial and temporal resolution space/airborne imagery and computational methods have encouraged the development of automated image processing. Supervised classification of spectral images is an effective method but requires complex workflow 6 4 2 . More recently, few studies have implemented deep learning algorithms to train models to detect extraction sites in images and have shown high levels of accuracy 3 . In Switzerland, MES management is historically regulated on a canton-based level using GIS data, including information about the MES location, extent, and extracted materials among others. At the federal level, swisstopo and the Federal Office of Statistics (FSO) observe the development of MES. swisstopo has carried out a detailed manual delineation of MES based on SWISSIMAGE dataset over Switzerland. In the scope to fasten and improving the process of MES mapping in Switzerland, we developed a method for automating MES detection over the years. Ultimately, the goal is to keep the database up to date when new images are acquired. The results can be statistically process to better assess the MES evolution over time in Switzerland.","title":"1.1 Context"},{"location":"PROJ-DQRY-TM/#12-approach","text":"The STDL has developed a framework named object-detector to automatically detect objects in a georeferenced imagery dataset based on deep learning method. The framework can be adapted to detect MES (also referred as quarry in the project) in Switzerland. A project to automatically detect MES in Switzerland 7 has been carried out by the STDL in 2021 ( detector-interface framework). Detection of potential MES obtained by automatic detection on the 2020 SWISSIMAGE mosaic has already been delivered to swisstopo (layer 2021_10_STDL_QC1 ). The method has proven its efficiency detecting MES. The numerical model trained with the object detector achieved a f1-score of 82% and detected about 1200 potential MES over Switzerland. In this project, we aim to continue this work and extend it to a second objective, that of observing MES evolution over time. The main challenge is to prove the algorithm reliability for detecting objects in a multi-year dataset images acquired with different sensors. The project workflow is synthesised in Figure 1. First, a deep learning algorithm is trained using a manually mapped MES dataset that serves as ground truth (GT). After evaluating the performance of the trained model, the selected one was used to perform inference detection for a given year dataset and area of interest (AoI). The results were filtered to discard irrelevant detection. The operation was repeated over several years. Finally, each potential MES detected was tracked over the years to observe its evolution. Figure 1: Workflow diagram for automatic MES detection. In this report, we first describe the data used, including the image description and the definition of AoI. Then we explain the model training, evaluation and object detection procedure. Next, we present the results of potential MES detection and the MES tracking strategy. Finally, we provide conclusion and perspectives.","title":"1.2. Approach"},{"location":"PROJ-DQRY-TM/#2-data","text":"","title":"2. Data"},{"location":"PROJ-DQRY-TM/#21-images-and-area-of-interest","text":"Automatic detection of potential MES over the years in Switzerland was performed with aerial orthophotos from the swisstopo product SWISSIMAGE Journey . Images are georeferenced RGB TIF tiles with a size of 256 x 256 pixels (1 km 2 ). Product Year Coordinate system Spatial resolution SWISSIMAGE 10 cm 2017 - current CH1903+/MN95 (EPSG:2056) 0.10 m ( \\(\\sigma\\) \\(\\pm\\) 0.15 m) - 0.25 m SWISSIMAGE 25 cm 2005 - 2016 MN03 (2005 - 2007) and MN95 (since 2008) 0.25 m ( \\(\\sigma\\) \\(\\pm\\) 0.25 m) - 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 3.00 - 5.00 m) SWISSIMAGE 50 cm 1998 - 2004 MN03 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 0.50 m) Table 1: SWISSIMAGE products characteristics. Several SWISSIMAGE products exist, produced from different instrumentation (Table 1). SWISSIMAGE mosaics are built and published yearly. The year of the mosaic corresponds to the last year of the dataset publication, and the most recent orthophotos datasets available are then used to complete the mosaic. For example the 2020 SWISSIMAGE mosaic is a combination of 2020, 2019 and 2018 images acquisition. The 1998 mosaic release corresponds to a year of transition from black and white images ( SWISSIMAGE HIST ) to RGB images. For this study, only RGB data from 1999 to 2021 were considered. Figure 2: Acquisition footprint of SWISSIMAGE aerial orthophotos for the years 2016 to 2021. The SWISSIMAGE Journey mosaic in the background is the 2020 release. Acquisition footprints of yearly acquired orthophotos were used as AoI to perform MES detection through time. Over the years, the footprints may spatially overlap (Fig. 2). Since 2017, the geometry of the acquisition footprints has been quasi-constant, dividing Switzerland into three more or less equal areas, ensuring that the orthophotos are updated every three years. For the years before 2017, the acquisition footprints were not systematic and do not guarantee a periodically update of the orthophotos. The acquisition footprint may also not be spatially contiguous. Figure 3: Illustration of the combination of SWISSIMAGE images and FSO images for the 2007 SWISSIMAGE mosaic. (a) Overview of the 2007 SWISSIMAGE mosaic. The red polygon corresponds to the provided SWISSIMAGE acquisition footprint for 2007. The orange polygon corresponds to the surface covered by the new SWISSIMAGE for 2007. The remaining area of the red polygon corresponds to the FSO image dataset acquired in 2007. The black box indicates the panel (b) location, and the white box indicates the panel (c) location. (b) Side-by-side comparison of image composition in 2006 and 2007 SWISSIMAGE mosaics. (c) Examples of detection polygons (white polygons) obtained by inference on the 2007 SWISSIMAGE dataset (red box) and FSO images 2007 (outlined by black box). SWISSIMAGE Journey mosaics of 2005, 2006, and 2007 present a particularity as it is composed not only of 25 cm resolution SWISSIMAGE but also of orthophotos acquired for the FSO. These are tiff RGB orthophotos with a spatial resolution of 50 cm px -1 (coordinate system: CH1903/LV03 (EPSG:21781)) and have been integrated into the SWISSIMAGE Journey products. However, these images were discarded (modification of the footprint shape) from our dataset because they were causing issues in the MES automatic detection producing odd segmented detection shapes (Fig. 3). This is probably due to the different stretching of pixel colour between datasets. It also has to be noted that there are currently missing images (about 88 tiles at zoom level 16) in the 2020 SWISSIMAGE dataset.","title":"2.1 Images and area of interest"},{"location":"PROJ-DQRY-TM/#22-image-fetching","text":"Pre-rendered SWISSIMAGE tiles (256 x 256 px, 1 km 2 ) are downloaded using the Web Map Tile Service (WMTS) wmts.geo.admin.ch via an XYZ connector. Tiles are served on a cartesian coordinates grid using a Web Mercator Quad projection and a coordinate reference system EPGS 3857. Position of a tile on the grid is defined by x and y coordinates and the pixel resolution of the image is defined by z , its zoom level. Changing the zoom level affects the resolution by a factor of 2 (Fig. 4). For instance a zoom level of 17 corresponds to a resolution of 0.8 m px -1 and a zoom level of 16 to a resolution of 1.6 m px -1 . Figure 4: Examples of tiles geometry at zoom level 16 (z16, black polygons) and at zoom level 17 (z17, blue polygons). The number of tiles for each zoom level is indicated in square brackets. The tiles are selected for model training, i.e. only tiles intersecting swissTLM3D labels (tlm-hr-trn-topo, yellow polygons). Note that in the subsequent project carried out by Reichel and Hamel (2021) 7 , the tiling method adopted was slightly different from the one adopted for this project. Custom size and resolution tiles were built. A sensitivity analysis of these two parameters was conducted and led to the choice of tiles with a size of about 500 m and a pixel resolution of about 1 m (above, the performance was not significantly improved).","title":"2.2 Image fetching"},{"location":"PROJ-DQRY-TM/#23-ground-truth","text":"The MES labels originate from the swiss Topographic Landscape Model 3D ( swissTLM3D ) produced by swisstopo . swissTLM3D is a large-scale topographic landscape model of Switzerland, including manually drawn and georeferenced vectors of objects of interest at a high resolution, including MES features. Domain experts from swisstopo have carried out extensive work to review the labeled MES and to synchronise them with the 2020 SWISSIMAGE mosaic to improve the quality of the labeled dataset. A total of 266 labels are available. The mapped MES reveal the diversity of MES characteristics, such as the presence or absence of buildings/infrastructures, trucks, water pounds, and vegetation (Fig. 5). Figure 5: Examples of MES mapped in swissTLM3D and synchronised to 2020 SWISSIMAGE mosaic. These labels are used as the ground truth (GT) i.e. the reference dataset indicating the presence of a MES in an image. The GT is used both as input to train the model to detect MES and to evaluate the model performance.","title":"2.3 Ground truth"},{"location":"PROJ-DQRY-TM/#3-automatic-detection-methodology","text":"","title":"3. Automatic detection methodology"},{"location":"PROJ-DQRY-TM/#31-deep-learning-algorithm-for-object-detection","text":"Training and inference detection of potential MES in SWISSIMAGE were performed with the object detector framework. This project is based on the open source detectron2 framework 8 implemented with PyTorch by the Facebook Artificial Intelligence Research group (FAIR). Instance segmentation (delineation of object) was performed with a Mask R-CNN deep learning algorithm 9 . It is based on a Recursive-Convolutional Neural Network (CNN) with a backbone pre-trained model ResNet-50 (50 layers deep residual network). Images were annotated with custom COCO object based on the labels (class 'Quarry'). The model is trained with this dataset to later perform inference detection on images. If the object is detected by the algorithm, a pixel mask is produced with a confidence score (0 to 1) attributed to the detection (Fig. 6). Figure 6: Example of detection mask. The pink rectangle corresponds to the bounding box of the object, the object is segmented by the pink polygons associated with the detection class ('Quarry') and a confidence score. The object detector framework permits to convert detection mask to georeferenced polygon that can be used in GIS softwares. The implementation of the Ramer-Douglas-Peucker ( RDP ) algorithm, allows the simplification of the derived polygons by discarding non-essential points based on a smoothing parameter. This allow to considerably reduces the amount of data to be stored and prevent potential memory saturation while deriving detection polygons on large areas as it is the case for this study.","title":"3.1 Deep learning algorithm for object detection"},{"location":"PROJ-DQRY-TM/#32-model-training","text":"Orthophotos from the 2020 SWISSIMAGE mosaic, for which the GT has been defined, were chosen to proceed the model training. Tiles intersecting labels were selected and split randomly into three datasets: the training dataset (70%), the validation dataset (15%), and the test dataset (15%). Addition of empty tiles (no annotation) to confront the model to landscapes not containing the target object has been tested ( Appendix A.1 ) but did not provide significant improvement in the model performance to be adopted. Figure 7: Training curves obtained at zoom level 16 on the 2020 SWISSIMAGE mosaic. The curves were obtained for the trained model 'replicate 3'. (a) Learning rate in function of iteration. The step was defined every 500 iterations. The initial learning rate was 5.0 x 10 -3 with a weight and bias decay of 1.0 x 10 -4 . (b) The total loss is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. (c) The validation loss curve is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. The vertical dashed black lines indicate the iteration minimising the validation loss curve, i.e. 3000. Models were trained with two images per batch ( Appendix A.2 ), a learning rate of 5 x 10 -3 , and a learning rate decay of 1 x 10 -4 every 500 steps (Fig. 7 (a)). For the given model, parameters and a zoom level of 16 ( Section 3.3.3 ), the training is performed over 7000 iterations and lasts about 1 hour on a 16 GiB GPU (NVIDIA Tesla T4) machine compatible with CUDA . The total (train and validation loss) loss curve decreases until reaching a quasi-steady state around 6000 iterations (Fig. 7 (b)). The optimal detection model corresponds to the one minimising the validation loss curve. This minimum is reached between 2000 and 3000 iterations (Fig. 7 (c)).","title":"3.2 Model training"},{"location":"PROJ-DQRY-TM/#33-metrics","text":"The model performance and detection reliability were assessed by comparing the results to the GT. The detection performed by the model can be either (1) a True Positive (TP), i.e. the detection is real (spatially intersecting the GT) ; (2) a False Positive i.e. the detection is not real (not spatially intersecting the GT) or (3) a False Negative (FN) i.e. the labeled object is not detected by the algorithm (Fig. 8). Tagging the detection (Fig. 9(a)) allows to calculate several metrics (Fig. 9(b)) such as: Figure 8: Examples of different detection cases. Label is represented with a yellow polygon and detection with a red polygon. (a) True Positive (TP) detection intersecting the GT, (b) a potential True Positive (TP?) detection with no GT, (c) False Negative (FN) case with no detection while GT exists, (d) False Positive (FP) detection of object that is not a MES. the recall , translating the amount of TP detections predicted by the model: \\[recall = \\frac{TP}{(TP + FN)}\\] the precision , translating the number of well-predicted TP among all the detections: \\[precision = \\frac{TP}{(TP + FP)}\\] the f1-score , the harmonic average of the precision and the recall: \\[f1 = 2 \\times \\frac{recall \\times precision}{recall + precision}\\] Figure 9: Evaluation of the trained model performance obtained at zoom level 16 for the trained model 'replicate 3' (Table 2). (a) Number of TP (blue), FN (red), and FP (green) as a function of detection score threshold for the validation dataset. (b) Metrics value, precision (blue), recall (red), and f1-score (green) as a function of the detection score threshold for the validation dataset. The maximum f1-score value is 82%.","title":"3.3 Metrics"},{"location":"PROJ-DQRY-TM/#4-automatic-detection-model-analysis","text":"","title":"4. Automatic detection model analysis"},{"location":"PROJ-DQRY-TM/#41-model-performance-and-replicability","text":"Trained models reached f1-scores of about 80% with a standard deviation of 2% (Table 2). The performances are similar to the model trained by Reichel and Hamel (2021) 7 . model precision recall f1 replicate 1 0.84 0.79 0.82 replicate 2 0.77 0.76 0.76 replicate 3 0.83 0.81 0.82 replicate 4 0.89 0.77 0.82 replicate 5 0.78 0.82 0.80 Table 2: Metrics value computed for the validation dataset for trained models replicates with the 2020 SWISSIMAGE mosaic at zoom level 16. A variability is expected as the deep learning algorithm displays some random behavior, but it is supposed to be negligible. However, the observed model variability is enough to affect final results that might slightly change by using different trained models with same input parameters (Fig. 10). Figure 10: Detection polygons obtained for the different trained model replicates (Table 2) highlighting results variability. The labels correspond to orange polygons. The number in the square bracket corresponds to the number of polygons. The inference detections have been performed on a subset of 2000 tiles for the 2020 SWISSIMAGE at zoom level 16. Detections have been filtered according to the parameters defined in Section 5.1. To reduce the variability of the trained models, the random seeds of both detectron2 and python have been fixed. Neither of these attempts have been successful, and the variability remains. The nondeterministic behavior of detectron2 has been recognised ( issue 1 , issue 2 ), but no suitable solution has been provided yet. Further investigation on the model performance and consistency should be performed in the future. To mitigate the results variability of model replicates, we could consider in the future to combine the results of several model replicates to remove FP while preserving the TP and potential TP detection. The choice and number of models used should be evaluated. This method is tedious as it requires inference detection from several models, which can be time-consuming and computationally intensive.","title":"4.1. Model performance and replicability"},{"location":"PROJ-DQRY-TM/#42-sensitivity-to-the-zoom-level","text":"Image resolution is dependent on the zoom level ( Section 2.2 ). To select the most suitable zoom level for MES detection, we performed a sensitivity analysis on trained model performance. Increasing the zoom level increases the value of the metrics following a global linear trend (Fig. 11). Figure 11: Metrics values (precision, recall and f1) as function of zoom level for the validation dataset. The results of the replicates performed at each zoom level are included (Table A1). Models trained at a higher zoom level performed better. However, a higher zoom level implies smaller tile and thus, a larger number of tiles to fill the AoI. For a typical AoI, i.e up to a third of Switzerland, this can lead to a large number of tiles to be stored and processed, leading to potential RAM and/or disk space saturation. For 2019 AoI, 89'290 tiles are required at zoom level 16 while 354'867 tiles are required at zoom level 17, taking respectively 3 hours and 11 hours to process on a 30 GiB RAM machine with a 16 GiB GP. Visual comparison of inference detection reveals that there was no significant improvement in the object detection quality from zoom level 16 to zoom level 17. Both zoom level present a similar proportion of detections intersecting labels (82% and 79% for zoom level 16 and zoom level 17 respectively). On the other hand, the quality of object detection at zoom level 15 was depreciated. Indeed, detection scores were lower, with only tens of detection scores above 0.95 while it was about 400 at zoom level 16 and about 64% of detection intersecting labels.","title":"4.2 Sensitivity to the zoom level"},{"location":"PROJ-DQRY-TM/#43-model-choice","text":"Based on tests performed, we selected the 'replicate 3' model, obtained (Tables 2 and A1) at zoom level 16, to perform inference detection. Models trained at zoom level 16 (1.6 m px -1 pixel resolution) have shown satisfying results in accurately detecting MES contour and limiting the number of FP with high detection score (Fig. 11). It represents a good trade-off between results reliability (f1-score between 76% and 82% on the validation dataset) and computational resources. Then, among all the replicates performed at zoom level 16, we selected the trained model 'replicate 3' (Table 2) because it combines both the highest metrics values (for the validation dataset but also the train and test datasets), close precision and recall values and a rather low amount of low score detections.","title":"4.3 Model choice"},{"location":"PROJ-DQRY-TM/#5-automatic-detection-of-mes","text":"","title":"5. Automatic detection of MES"},{"location":"PROJ-DQRY-TM/#51-detection-post-processing","text":"Detection by inference was performed over AoIs with a threshold detection score of 0.3 (Fig. 12). The low score filtering results in a large amount of detections. Several detections may overlap, potentially segmenting a single object. In addition a detection might be split into multiple tiles. To improve the pertinence and the aesthetics of the raw detection polygons, a post-processing procedure was applied. First, a large proportion of FP occurred in mountainous areas (rock outcrops and snow, Fig. 12(a)). We assumed MES are not present (or at least sparse) above a given altitude. An elevation filtering was applied using a Switzerland Digital Elevation Model (about 25 m px -1 ) derived from the SRTM instrument ( USGS - SRTM ). The maximum elevation of the labeled MES is about 1100 m. Second, detection aggregation was applied: - polygons were clustered ( K-means ) according to their centroid position. The method involves setting a predefined number k of clusters. Manual tests performed by Reichel and Hamel (2021) 7 concluded to set k equal to the number of detection divided by three. The highest detection score was assigned to the clustered detection. This method preserves the final integrity of detection polygons by retaining detection that has potentially a low confidence score but belongs to a cluster with a higher confidence score improving the final segmentation of the detected object. The value of the threshold score must be kept relatively low ( i.e. 0.3) when performing the detection to prevent removing too many polygons that could potentially be part of the detected object. We acknowledge that determining the optimal number of clusters by clustering validation indices rather than manual adjustment would be more robust. In addition, exploring other clustering methods, such as DBSCAN , based on local density, can be considered in the future. - score filtering was applied. - spatially close polygons were assumed to belong to the same MES and are merged according to a distance threshold. The averaged score of the merged detection polygons was ultimately computed. Finally, we assumed that a MES covers a minimal area. Detection with an area smaller than a given threshold were filtered out. The minimum MES area in the GT is 2270 m 2 . Figure 12: MES detection filtering. (a) Overview of the automatic detection of MES obtained with 2020 SWISSIMAGE at zoom level 16. Transparent red polygons (with associated confidence score in white) correspond to the raw object detection output and the red line polygons (with associated confidence score in red) correspond to the final filtered detection. The black box outlines the location of the (b) and (c) panel zoom. Note the large number of detection in the mountains (right area of the image). (b) Zoom on several raw detections polygons of a single object with their respective confidence score. (c) Zoom on a filtered detection polygon of a single object with the resulting score. Sensitivity of detections to these filters was investigated (Table 3). The quantitative evaluation of filter combination relevance is tricky as potential MES presence is performed by inference, and the GT provided by swissTLM3D constitutes an incomplete portion of the MES in Switzerland (2020). As indication, we computed the number of spatial intersection between ground truth and detection obtained with the 2020 SWISSIMAGE mosaic. Filter combination number 3 was adopted, allowing to detect about 82% of the GT with a relatively limited amount of FP detection compared to filter combinations 1 and 2 (from visual inspection). filters combination score threshold elevation threshold (m) area threshold (m 2 ) distance threshold (m) number of detection label detection (%) 1 0.95 2000 1100 10 1745 85.1 2 0.95 2000 1200 10 1862 86.6 3 0.95 5000 1200 10 1347 82.1 4 0.96 2000 1100 10 1331 81.3 5 0.96 2000 1200 8 1445 78.7 6 0.96 5000 1200 10 1004 74.3 Table 3: Threshold values of filtering parameters and their respective number of detections and intersection proportion with swissTLM3D labels. The detections have been obtained for the 2020 SWISSIMAGE mosaic. We acknowledged that for the selected filter combination, the area threshold value is higher than the smallest area value of the GT polygons. However, reducing the area value increases significantly the presence of FP. Thirteen labels display an area below 5000 m 2 .","title":"5.1 Detection post-processing"},{"location":"PROJ-DQRY-TM/#52-inference-detections","text":"The trained model was used to perform inference detection on SWISSIMAGE orthophotos from 1999 to 2021. The automatic detection model shows good capabilities to detect MES in different years orthophotos (Fig. 13), despite being trained on the 2020 SWISSIMAGE mosaic. The model also demonstrates capabilities to detect potential MES that have not been mapped yet but are strong candidates. However, the model misses some labeled MES or potential MES (FN, Fig. 8). However, when the model process FSO images, with different colour stretching, it failed to correctly detect potential MES (Fig. 3). It reveals that images must have characteristics close to the training dataset for optimal results with a deep learning model. Figure 13: Examples of object detection segmented by polygons in different year orthophotos. The yellow polygon for the year 2020 panel of object ID 3761 corresponds to the label. Other coloured polygons correspond to the algorithm detection. Then, we acknowledge that a significant amount of FP detection can still be observed in our filtered detection dataset (Figs. 8 and 14). The main sources of FP are the presence of large rock outcrops, mountainous areas without vegetation, snow, river sand beds, brownish-coloured fields, or construction areas. MES present a large variety of features (buildings, water pounds, trucks, vegetation) (Fig. 5) which can be a source of confusion for the algorithm but even sometimes for human eye. Therefore, the robustness of the GT is crucial for reliable detection. The algorithm's results should be taken carefully. Figure 14: Examples of FP detection. (a) Snow patches (2019) ; (b) River sand beds and gullies (2019); (c) Brownish field (2020); (d) vineyards (2005); (e) Airport tarmac (2020); (f) Construction site (2008). The detections produced by the algorithm are potential MES, but the final results must be reviewed by experts in the field to discard remaining FP detection and correct FN before any processing or interpretation.","title":"5.2 Inference detections"},{"location":"PROJ-DQRY-TM/#6-observation-of-mes-evolution","text":"","title":"6. Observation of MES evolution"},{"location":"PROJ-DQRY-TM/#61-object-tracking-strategy","text":"Switzerland is covered by RGB SWISSIMAGE product over more than 20 years (1999 to actual), allowing changes to be detected (Fig. 13). Figure 15: Strategy for MES tracking over time. ID assignment to detection. Spatially intersecting polygons share the same ID allowing the MES to be tracked in a multi-year dataset. We assumed that detection polygons that overlap from one year to another describe a single object (Fig. 15). Overlapping detections and unique detections (which do not overlap with polygons from other years) in the multi-year dataset were assigned a unique object identifier (ID). A new object ID in the timeline indicates: - the first occurrence of the object detected in the dataset of the first year available for the area. It does not mean that the object was not present before, - the creation of a potential new MES. The disappearance of an object ID indicates its potential refill. Therefore, the chronology of MES, creation, evolution and filling, can be constrained.","title":"6.1 Object tracking strategy"},{"location":"PROJ-DQRY-TM/#62-evolution-of-mes-over-years","text":"Figures 13 and 16 illustrate the ability of the trained model to detect and track a single object in a multi-year dataset. The detection over the years appears reliable and consistent, although object detection may be absent from a year dataset ( e.g. due to shadows or colour changes in the surroundings). Remember that the image coverage of a given area is not renewed every year. Characteristics of the potential MES, such as surface evolution (extension or retreat), can be quantified. For example, the surfaces of object IDs 239 and 3861 have more than doubled in about 20 years. Tracking object ID along with image visualisation allows observation of the opening and the closing of potential MES, as object IDs 31, 44, and 229. Figure 16: Detection area (m 2 ) as a function of years for several object ID. Figure 13 provides the visualisation of the object IDs selected. Each point corresponds to an object ID occurrence in the corresponding year dataset. The presence of an object in several years dataset strengthens the likeliness of the detected object to be an actual MES. On the other hand, object detection of only one occurrence is more likely a FP detection.","title":"6.2 Evolution of MES over years"},{"location":"PROJ-DQRY-TM/#7-conclusion-and-perspectives","text":"The project demonstrated the ability to automatically, quickly (a matter of hours for one AoI), and reliably detect potential MES in orthophotos of Switzerland with an automatic detection algorithm (deep learning). The selected trained model achieved a f1-score of 82% on the validation dataset. The final detection polygons accurately delineate the potential MES. We can track single MES through multiple years, emphasising the robustness of the method to detect objects in multi-year datasets despite the detection model being trained on a single dataset (2020 SWISSIMAGE mosaic). However, image colour stretching different from that used to train the model can significantly affect the model's ability to provide reliable detection, as was the case with the FSO images. Although the performance of the trained model is satisfactory, FP and FN are present in the datasets. They are mainly due to confusion of the algorithm between MES and rock outcrops, river sandbeds or construction sites. A manual verification of the relevance of the detection by experts in the field is necessary before processing and interpreting the data. Revision of all the detections from 1999 to 2021 is a time-consuming effort but is necessary to guarantee detection reliability. Despite the required manual checks, the provided framework and detection results constitute a valuable contribution that can greatly assist the inventory and the observation of MES evolution in Switzerland. It provides state-wide detection in a matter of hours, which is a considerable time-saving compared with manual mapping. It also enables MES detection with a standardised method, independent of the information or method adopted by the cantons. Further model improvements could be consider, such as increasing the metrics by improving GT quality, improving model learning strategy, mitigating the model learning variability, or test supervised clustering methods to find relevant detection. This work can be used to compute statistics to study long-term MES in Switzerland and better management of resources and land use in the future. MES detection can be combined with other data, such as the geologic layer, to identify the mineral/rocks exploited and high-resolution DEM ( swissALTI3D ) to infer elevation changes and observe excavation or filling of MES 5 . So far only RGB SWISSIMAGE orthophotos from 1999 to 2021 were processed. Prior to 1999, black and white orthophotos exist but the model trained on RGB images could not be applied trustfully to black and white images. Image colourisation tests (with the help of deep learning algorithm[@farella_colour_2022]) were performed and provided encouraging detection results. This avenue needs to be explored. Finally, automatic detection of MES is rare 1 3 , and most studies perform manual mapping. Therefore, the framework could be the extended to other datasets and/or other countries to provide a valuable asset to the community. A global mapping of MES has been completed with over 21'000 polygons 1 and can be used as a GT database to train an automatic detection model.","title":"7. Conclusion and perspectives"},{"location":"PROJ-DQRY-TM/#code-availability","text":"The codes are stored and available on the STDL's github repository: proj-dqry : mineral extraction site framework object-detector : object detector framework","title":"Code availability"},{"location":"PROJ-DQRY-TM/#acknowledgements","text":"This project was made possible thanks to a tight collaboration between the STDL team and swisstopo . In particular, the STDL team acknowledges key contribution from Thomas Galfetti ( swisstopo ). This project has been funded by \"Strategie Suisse pour la G\u00e9oinformation\".","title":"Acknowledgements"},{"location":"PROJ-DQRY-TM/#appendix","text":"","title":"Appendix"},{"location":"PROJ-DQRY-TM/#a1-influence-of-empty-tiles-addition-to-model-performance","text":"By selecting tiles intersecting only labels, the detection model is mainly confronted with the presence of the targeted object to be detected. Addition of non-label-intersecting tiles, i.e. empty tiles, provides landscape diversity that might help to improve the object detection performance. In order to evaluate the influence of adding empty tiles to the dataset used for the model performance, empty tiles were chosen randomly (not intersecting labels) within Switzerland boundaries and added to the tile dataset used for the model training (Fig. A1). Empty tiles were added to (1) the whole dataset split as for the initial dataset (training: 70%, test: 15%, and validation: 15%) and (2) only to the training dataset. A visual inspection must be performed to prevent a potential unlabeled MES to be present in the image and disturbing the algorithm learning. Figure A1: View of tiles intersecting (black) labels (yellow) and randomly selected empty tiles (red) in Switzerland. This case correspond to the addition of 35% empty tiles. Figure A1 reveals that adding empty tiles to the dataset does not significantly influence the metrics values. The number of TP, FP, and FN do not show significant variation. However, when performing an inference detection test on a subset of tiles (2000) for an AOI, it appears that the number of raw detections (unfiltered) is reduced as the number of empty tiles increases. However, visual inspection of the final detection after applying filters does not show significant improvement compared to a model trained without adding empty tiles. Figure A1: Influence of the addition of empty tiles (relative to the number of tiles intersecting labels) on trained performance for zoom levels 16 and 17 with (a) the F1-score as a function of the percentage of added empty tiles and (b) the normalised (by the number of tiles sampled = 2000) number of detection as a function of added empty tiles. Empty tiles have been added to only the train dataset for the 5% and 30% cases and to all datasets for 9%, 35%, 70%, and 140% cases. A considered solution to improve the results could be to specifically select tiles for which FP occurred and include them in the training dataset as empty tiles. This way, the model could be trained with relevant confounding features such as snow patches, river sandbeds, or gullies not labeled as GT.","title":"A.1 Influence of empty tiles addition to model performance"},{"location":"PROJ-DQRY-TM/#a2-sensitivity-of-the-model-to-the-number-of-images-per-batch","text":"During the model learning phase, the trained model is updated after each batch of samples was processed. Adding more samples, i.e. in our case images, to the batch can influence the model learning capacity. We investigated the role of adding more images per batch for a dataset with and without adding a portion of empty tiles to the learning dataset. Adding more images per batch speeds up the model learning (Table A1), and the minimum of the loss curve is reached for a smaller number of iterations. Figure A2: Metrics (precision, recall and f1-score) evolution with the number of images per batch during the model training. Results have been obtained on a dataset without empty tiles addition (red) and with the addition of 23% of empty tiles to the training dataset. Figure A2 reveals that the metrics values remain in a range of constant values while adding extra images to the batch in all cases (with or without empty tiles). A potential effect of adding more images to the batch is the reduction of the metrics variability between replicates of trained models as the range of metrics values is smaller for 8 images per batch than 2 images per batch. However, this observation has to be taken carefully as fewer replicates have been performed with 8 images per batch than for 2 or 4 images per batch. Further investigation would provide stronger insights on this effect.","title":"A.2 Sensitivity of the model to the number of images per batch"},{"location":"PROJ-DQRY-TM/#a3-evaluation-of-trained-models","text":"Table A1 sumup metrics value obtained for all the configuration tested for the project. zoom level model empty tiles (%) image per batch optimum iteration precision recall f1 15 replicate 1 0 2 1000 0.727 0.810 0.766 16 replicate 1 0 2 2000 0.842 0.793 0.817 16 replicate 2 0 2 2000 0.767 0.760 0.763 16 replicate 3 0 2 3000 0.831 0.810 0.820 16 replicate 4 0 2 2000 0.886 0.769 0.826 16 replicate 5 0 2 2000 0.780 0.818 0.798 16 replicate 6 0 2 3000 0.781 0.826 0.803 16 replicate 7 0 4 1000 0.748 0.860 0.800 16 replicate 8 0 4 1000 0.779 0.785 0.782 16 replicate 9 0 8 1500 0.800 0.793 0.797 16 replicate 10 0 4 1000 0.796 0.744 0.769 16 replicate 11 0 8 1000 0.802 0.769 0.785 16 ET-250_allDS_1 34.2 2 2000 0.723 0.770 0.746 16 ET-250_allDS_2 34.2 2 3000 0.748 0.803 0.775 16 ET-1000_allDS_1 73.8 2 6000 0.782 0.815 0.798 16 ET-1000_allDS_2 69.8 2 6000 0.786 0.767 0.776 16 ET-1000_allDS_3 70.9 2 6000 0.777 0.810 0.793 16 ET-1000_allDS_4 73.8 2 6000 0.768 0.807 0.787 16 ET-2000_allDS_1 143.2 2 6000 0.761 0.748 0.754 16 ET-80_trnDS_1 5.4 2 2000 0.814 0.793 0.803 16 ET-80_trnDS_2 5.4 2 2000 0.835 0.752 0.791 16 ET-80_trnDS_3 5.4 2 2000 0.764 0.802 0.782 16 ET-400_trnDS_1 29.5 2 6000 0.817 0.777 0.797 16 ET-400_trnDS_2 29.5 2 5000 0.848 0.785 0.815 16 ET-400_trnDS_3 29.5 2 4000 0.758 0.802 0.779 16 ET-400_trnDS_4 29.5 4 2000 0.798 0.818 0.808 16 ET-400_trnDS_5 29.5 4 1000 0.825 0.777 0.800 16 ET-1000_trnDS_1 0 2 4000 0.758 0.802 0.779 17 replicate 1 0 2 5000 0.819 0.853 0.835 17 replicate 1 0 2 5000 0.803 0.891 0.845 17 replicate 1 0 2 5000 0.872 0.813 0.841 17 ET-250_allDS_1 16.8 2 3000 0.801 0.794 0.797 17 ET-1000_allDS_1 72.2 2 7000 0.743 0.765 0.754 18 replicate 1 0 2 10000 0.864 0.855 0.859 Table A1: Metrics value computed for the validation dataset for all the trained models with the 2020 SWISSIMAGE Journey mosaic at zoom level 16. Victor Maus, Stefan Giljum, Jakob Gutschlhofer, Dieison M. Da Silva, Michael Probst, Sidnei L. B. Gass, Sebastian Luckeneder, Mirko Lieber, and Ian McCallum. A global-scale data set of mining areas. Scientific Data , 7(1):289, September 2020. URL: https://www.nature.com/articles/s41597-020-00624-w , doi:10.1038/s41597-020-00624-w . \u21a9 \u21a9 \u21a9 \u21a9 \u21a9 Vicen\u00e7 Carabassa, Pau Montero, Marc Crespo, Joan-Cristian Padr\u00f3, Xavier Pons, Jaume Balagu\u00e9, Llu\u00eds Brotons, and Josep Maria Alca\u00f1iz. Unmanned aerial system protocol for quarry restoration and mineral extraction monitoring. Journal of Environmental Management , 270:110717, September 2020. URL: https://linkinghub.elsevier.com/retrieve/pii/S0301479720306496 , doi:10.1016/j.jenvman.2020.110717 . \u21a9 \u21a9 \u21a9 \u21a9 Chunsheng Wang, Lili Chang, Lingran Zhao, and Ruiqing Niu. Automatic Identification and Dynamic Monitoring of Open-Pit Mines Based on Improved Mask R-CNN and Transfer Learning. Remote Sensing , 12(21):3474, January 2020. URL: https://www.mdpi.com/2072-4292/12/21/3474 , doi:10.3390/rs12213474 . \u21a9 \u21a9 \u21a9 \u21a9 Haoteng Zhao, Yong Ma, Fu Chen, Jianbo Liu, Liyuan Jiang, Wutao Yao, and Jin Yang. Monitoring Quarry Area with Landsat Long Time-Series for Socioeconomic Study. Remote Sensing , 10(4):517, April 2018. URL: https://www.mdpi.com/2072-4292/10/4/517 , doi:10.3390/rs10040517 . \u21a9 \u21a9 Valentin Tertius Bickel and Andrea Manconi. Decadal Surface Changes and Displacements in Switzerland. Journal of Geovisualization and Spatial Analysis , 6(2):24, December 2022. URL: https://link.springer.com/10.1007/s41651-022-00119-9 , doi:10.1007/s41651-022-00119-9 . \u21a9 \u21a9 George P. Petropoulos, Panagiotis Partsinevelos, and Zinovia Mitraka. Change detection of surface mining activity and reclamation based on a machine learning approach of multi-temporal Landsat TM imagery. Geocarto International , 28(4):323\u2013342, July 2013. URL: http://www.tandfonline.com/doi/abs/10.1080/10106049.2012.706648 , doi:10.1080/10106049.2012.706648 . \u21a9 Huriel Reichel and Nils Hamel. Automatic Detection of Quarries and the Lithology below them in Switzerland. 2022. URL: file:///C:/Users/Clemence/Documents/STDL/Projects/proj-quarries/01_Documentation/Bibliography/Automatic%20Detection%20of%20Quarries%20and%20the%20Lithology%20below%20them%20in%20Switzerland%20-%20Swiss%20Territorial%20Data%20Lab.htm . \u21a9 \u21a9 \u21a9 \u21a9 Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2. 2019. URL: https://github.com/facebookresearch/detectron2 . \u21a9 Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross Girshick. Mask R-CNN. January 2018. arXiv:1703.06870 [cs]. URL: http://arxiv.org/abs/1703.06870 , doi:10.48550/arXiv.1703.06870 . \u21a9","title":"A.3 Evaluation of trained models"},{"location":"PROJ-DTRK/","text":"DIFFERENCE MODELS APPLIED ON LAND REGISTER \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - PROJ-DTRK September 2020 to November 2020 - Published on April 23, 2021 Abstract : Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Introduction \u00b6 Land register models are probably to most living of the geographical models as they are constantly updated to offer a rigorous and up-to-date view of the territory. The applied corrections are always the result of a complex process, involving different territory actors, until the decision is made to integrate them into the land register. In addition, land register models comes with an additional constraint linked to political decisions. Indeed, the land register models are the result of a political mission conducted under federal laws making these models of high importance and requiring constant care. We show in this research project how differences detection tool [1] of the STDL 4D framework can be used to emphasize and analyze these corrections along the time dimension. In addition to the constant updates of the models, changes in the reference frame can also lead to large-scale corrections of the land register models. These global corrections are then made even more complex by the federal laws that impose a high degree of correctness and accuracy. In the context of the introduction of the new reference frame DM.flex [2] for the Swiss land register, being able to assess the applied changes on the geographical model appear as an important aspect. Indeed, changing the reference frame for the land register models is a long and complex technical process that can be error prompt. We also show in this research project how the difference detection algorithm can be helpful to assess and verify the performed corrections. Research Project Specifications \u00b6 In this research project, the difference detection algorithm implemented in the STDL 4D framework is applied on INTERLIS data containing the official land register models of different Swiss Canton . As introduced, two main directions are considered for the difference detection algorithm : Demonstrating the ability to extract information in between land register models Demonstrating the ability of difference models to be used as an assessment tool Through the first direction, the difference detection algorithm is presented. Considering the difference models it allows computing, it is shown how such model are able to extract information in between the models in order to emphasize the ability to represent, and then, to verify the evolution of the land register models. The second direction focuses on demonstrating that difference models are a helpful representation of the large-scale corrections that can be applied to land register during reference frame modification and how they can be used as a tool to assess the modifications and to help to fulfil the complex task of the verification of the corrected models. Research Project Data \u00b6 For the first research direction, the land register models of the Thurgau Kanton are considered. They are selected in order to have a small temporal distance allowing to focus on a small amount of well-defined differences : Thurgau Kanton , 2020-10-13 , INTERLIS Thurgau Kanton , 2020-10-17 , INTERLIS For the second direction, which focus on more complex differences, the models of the Canton of Geneva land register are considered with a much larger temporal gap between them : Canton of Geneva , 2009-10 , INTERLIS Canton of Geneva , 2013-04 , INTERLIS Canton of Geneva , 2017-04 , INTERLIS Canton of Geneva , 2019-04 , INTERLIS Difference Models : A Temporal Derivative \u00b6 This first section focuses on short-term differences to show how difference models work and how they are able to represent the modifications extracted out of the two compared models. The following images give an illustration of the considered dataset, which are the land register models of Thurgau Kanton : Illustration of Thurgau Kanton INTERLIS models - Data : Kanton Thurgau The models are made of vector lines, well geo-referenced in the Swiss coordinates frame EPSG:2056 . The models are also made of different layers that are colored differently with the following correspondences : INTERLIS selected topics and tables colors - Official French and German designations These legends are used all along this research project. Considering two temporal versions of this geographical model, separated of a few days, one is able to extract difference models using the 4D framework algorithm. As an example, one can consider this very specific view of the land register, focusing on a few houses : Close view of the Thurgau INTERLIS model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It is clear that most of the close view is identical for the two models, except for a couple of houses that were added to the land register model between these two temporal versions. By applying the difference detection algorithm, one is able to obtain a difference model comparing the two previous models. The following image gives an illustration of the obtained difference models considering the most recent temporal version as reference : Difference model obtained comparing the two temporal versions - Data : Kanton Thrugau One can see how the difference algorithm is able to emphasize the differences and to represent them in a human-readable third model. The algorithm also displays the identical parts in dark gray to offer the context of the differences to the operator. Of course, in such close view, differences detection can appear as irrelevant, as one is clearly able to see that something changed on the selected example without any help. But difference models can be computed at any scale. For example, taking the example of the Amriswil city : View of Amriswil model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It becomes more complicated to track down the differences that can appear between the two temporal versions. By computing their difference model , one is able to access a third model that ease the analysis of the evolution at the scale of the city itself as illustrated on the following image : Difference model computed for the city of Amriswil - Data : Kanton Thrugau One can see how difference models can be used to track down modifications brought to the land register in a simple manner, while keeping the information of the unchanged elements between the two compared models. This demonstrates that information that exists between models can be extracted and represented for further users or automated processes. In addition, such difference models can be computed at any scale, considering small area up to the whole countries. Difference Models : An Assessment Tool \u00b6 On the previous section, the difference models are computed using two models only separated of a few days, containing only a small amount of clear and simple modifications. This section focuses on detecting differences on larger models, separated by several years. In this case, the land register of the Canton of Geneva is considered : Illustration of the Geneva land register in 2017-04 (left) and 2019-04 (right) - Data : Canton of Geneva One can see that at such a scale, taking into account that the Canton of Geneva is one of the smallest in Switzerland, having a vision and a clear understanding of the modifications made between these two models is difficult by considering the two models separately. It's precisely where differences models can be useful to understand and analyze the evolution of the land register, along both the space and time dimensions. Large-Scale Analysis \u00b6 A first large-scale evaluation can be made on the overall models. A difference model can be computed considering the land register of Geneva in 2019 and 2017 as illustrated on the following image : Difference model on Geneva land register between 2019-04 and 2017-04 - Data : Canton of Geneva Two observations can be already made by looking at the difference model . In the first place, one can see that the amount of modifications brought to the land register is large in only two years. A large portion of the land register were subject to modifications or corrections, the unchanged parts being mostly limited outside the populated area. In the second place, one can observe large portions where differences seem to be accumulating over this period of time. Looking at them more closely leads to the conclusion that these zones were actually completely modified, as all elements are highlighted by the difference detection algorithm. The following image gives a closer view of such an area of differences accumulation : Focus on Carouge area of the 2019-04 and 2017-04 difference model - Data : Canton of Geneva Despite the amount of modifications outside this specific zone is also high, it is clear that the pointed zone contains more of them. Looking at it more closely leads to the conclusion that everything changed. In order to understand these areas of differences accumulation, the the land register experts of the Canton of Geneva ( SITG ) were questioned. They provided an explanation for these specific areas. Between 2017 and 2019 , these areas were subjected to a global correction in order to release the tension between the old reference frame LV03 [3] and the current one LV95 [4]. These corrections were made using the FINELTRA algorithm to modify the elements of the land register of the order of a few centimeters. The land register of Geneva provided the following illustration summarizing these reference frame corrections made between 2017 and 2019 on the Geneva territory : Reference frame corrections performed between 2017 and 2019 - Data : SITG Comparing this map from the land register with the computed model allows seeing how differences detection can emphasize this type of corrections efficiently, as the corrected zones on this previous image corresponds to the difference accumulation areas on the computed difference model . Small-Scale Analysis \u00b6 One can also dive deep into the details of the difference models . As we saw on the large scale analysis, two types of areas can be seen on the 2019-04-2017-04 difference model of Geneva : regular evolution with an accumulation of corrections and areas on which global corrections were applied. The following images propose a close view of these two types of situation : Illustration of the two observed type of evolutions of the land register - Data : Canton of Geneva On the left image above, one can observe the regular evolution of the land register where modifications are brought to the model in order to follow the evolution of the territory. On the right image above, one can see a close view of an area subjected to a global correction (reference frame), leading to a difference model highlighting all the elements. Analyzing more closely the right image above lead the observer to conclude that not all the elements are actually highlighted by the difference detection algorithm. Indeed, some elements are rendered in gray on the difference model , indicating their lack of modification between the two compared times. The following image emphasizes the unchanged elements that can be observed : Unchanged elements in the land register after reference frame correction - Data : SITG These unchanged elements can be surprising as they're found in an area that was subject to a global reference frame correction. This shows how difference models can be helpful to track down these type of events in order to check whether these unchanged elements are expected or are the results of a discrepancy in the land register evolution. Other example can be found in this very same area of the Geneva city. The following images give an illustration of two other close view where the unchanged element can be seen despite the reference frame correction : Unchanged elements in the land register after reference frame correction - Data : SITG On the left image above, one can observe that the unchanged elements are the railway tracks within the commune of Carouge . This is an interesting observation, as railway tracks can be considered as specific elements that can be subjected to different legislations regarding the land register. But it is clear that railway tracks were not considered in the reference frame correction. On the right image above, one can see another example of unchanged elements that are more complicated to explain, as they're in the middle of modified other elements. This clearly demonstrate how difference models can be helpful for analyzing and assessing the evolution of the land register models. Such models are able to drive users or automated processes and lead them to focus on relevant aspects and to define the good question in the context of analyzing the evolution of the land register. Conclusion \u00b6 The presented difference models computed based on two temporal versions of the land register and using the 4D framework algorithm showed how differences can be emphasized for users and automated processes [1]. Difference models can be helpful to determine the amount and nature of changes that appear in the land register. Applying such an algorithm on land register is especially relevant as it is a highly living model, that evolves jointly with the territory it describes. Two main applications can be considered using difference models applied on the land register. In the first place, the difference models can be used to assess and analyze the regular evolution of the territory. Indeed, updating the land register is not a simple task. Such modifications involve a whole chain of decisions and verifications, from surveyors to the highest land register authority before to be integrated in the model. Being able to assess and analyze the modifications in the land register through difference models could be one interesting strengthening of the overall process. The second application of difference models could be as an assessment tool of global corrections applied to the land register or parts of it. These modifications are often linked to the reference frame and its evolution. Being able to assess the corrections through the difference models could add a helpful tool in order to verify that the elements of the land register where correctly processed. In this direction, difference models could be used during the introduction of the DM.flex reference frame for both analyzing its introduction and demonstrating that difference models can be an interesting point of view. Reproduction Resources \u00b6 To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Unfortunately, the used data are not currently public. In both cases, the land register INTERLIS datasets were provided to the STDL directly. You can contact both Thurgau Kanton and SITG : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) to query the data. In order to extract and convert the data from the INTERLIS models, the following code is used : INTERLIS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results. References \u00b6 [1] Automatic Detection of Changes in the Environment, N. Hamel, STDL 2020 [2] DM.flex reference frame [3] LV03 Reference frame [4] LV95 Reference frame","title":"DIFFERENCE MODELS APPLIED ON LAND REGISTER"},{"location":"PROJ-DTRK/#difference-models-applied-on-land-register","text":"Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - PROJ-DTRK September 2020 to November 2020 - Published on April 23, 2021 Abstract : Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed.","title":"DIFFERENCE MODELS APPLIED ON LAND REGISTER"},{"location":"PROJ-DTRK/#introduction","text":"Land register models are probably to most living of the geographical models as they are constantly updated to offer a rigorous and up-to-date view of the territory. The applied corrections are always the result of a complex process, involving different territory actors, until the decision is made to integrate them into the land register. In addition, land register models comes with an additional constraint linked to political decisions. Indeed, the land register models are the result of a political mission conducted under federal laws making these models of high importance and requiring constant care. We show in this research project how differences detection tool [1] of the STDL 4D framework can be used to emphasize and analyze these corrections along the time dimension. In addition to the constant updates of the models, changes in the reference frame can also lead to large-scale corrections of the land register models. These global corrections are then made even more complex by the federal laws that impose a high degree of correctness and accuracy. In the context of the introduction of the new reference frame DM.flex [2] for the Swiss land register, being able to assess the applied changes on the geographical model appear as an important aspect. Indeed, changing the reference frame for the land register models is a long and complex technical process that can be error prompt. We also show in this research project how the difference detection algorithm can be helpful to assess and verify the performed corrections.","title":"Introduction"},{"location":"PROJ-DTRK/#research-project-specifications","text":"In this research project, the difference detection algorithm implemented in the STDL 4D framework is applied on INTERLIS data containing the official land register models of different Swiss Canton . As introduced, two main directions are considered for the difference detection algorithm : Demonstrating the ability to extract information in between land register models Demonstrating the ability of difference models to be used as an assessment tool Through the first direction, the difference detection algorithm is presented. Considering the difference models it allows computing, it is shown how such model are able to extract information in between the models in order to emphasize the ability to represent, and then, to verify the evolution of the land register models. The second direction focuses on demonstrating that difference models are a helpful representation of the large-scale corrections that can be applied to land register during reference frame modification and how they can be used as a tool to assess the modifications and to help to fulfil the complex task of the verification of the corrected models.","title":"Research Project Specifications"},{"location":"PROJ-DTRK/#research-project-data","text":"For the first research direction, the land register models of the Thurgau Kanton are considered. They are selected in order to have a small temporal distance allowing to focus on a small amount of well-defined differences : Thurgau Kanton , 2020-10-13 , INTERLIS Thurgau Kanton , 2020-10-17 , INTERLIS For the second direction, which focus on more complex differences, the models of the Canton of Geneva land register are considered with a much larger temporal gap between them : Canton of Geneva , 2009-10 , INTERLIS Canton of Geneva , 2013-04 , INTERLIS Canton of Geneva , 2017-04 , INTERLIS Canton of Geneva , 2019-04 , INTERLIS","title":"Research Project Data"},{"location":"PROJ-DTRK/#difference-models-a-temporal-derivative","text":"This first section focuses on short-term differences to show how difference models work and how they are able to represent the modifications extracted out of the two compared models. The following images give an illustration of the considered dataset, which are the land register models of Thurgau Kanton : Illustration of Thurgau Kanton INTERLIS models - Data : Kanton Thurgau The models are made of vector lines, well geo-referenced in the Swiss coordinates frame EPSG:2056 . The models are also made of different layers that are colored differently with the following correspondences : INTERLIS selected topics and tables colors - Official French and German designations These legends are used all along this research project. Considering two temporal versions of this geographical model, separated of a few days, one is able to extract difference models using the 4D framework algorithm. As an example, one can consider this very specific view of the land register, focusing on a few houses : Close view of the Thurgau INTERLIS model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It is clear that most of the close view is identical for the two models, except for a couple of houses that were added to the land register model between these two temporal versions. By applying the difference detection algorithm, one is able to obtain a difference model comparing the two previous models. The following image gives an illustration of the obtained difference models considering the most recent temporal version as reference : Difference model obtained comparing the two temporal versions - Data : Kanton Thrugau One can see how the difference algorithm is able to emphasize the differences and to represent them in a human-readable third model. The algorithm also displays the identical parts in dark gray to offer the context of the differences to the operator. Of course, in such close view, differences detection can appear as irrelevant, as one is clearly able to see that something changed on the selected example without any help. But difference models can be computed at any scale. For example, taking the example of the Amriswil city : View of Amriswil model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It becomes more complicated to track down the differences that can appear between the two temporal versions. By computing their difference model , one is able to access a third model that ease the analysis of the evolution at the scale of the city itself as illustrated on the following image : Difference model computed for the city of Amriswil - Data : Kanton Thrugau One can see how difference models can be used to track down modifications brought to the land register in a simple manner, while keeping the information of the unchanged elements between the two compared models. This demonstrates that information that exists between models can be extracted and represented for further users or automated processes. In addition, such difference models can be computed at any scale, considering small area up to the whole countries.","title":"Difference Models : A Temporal Derivative"},{"location":"PROJ-DTRK/#difference-models-an-assessment-tool","text":"On the previous section, the difference models are computed using two models only separated of a few days, containing only a small amount of clear and simple modifications. This section focuses on detecting differences on larger models, separated by several years. In this case, the land register of the Canton of Geneva is considered : Illustration of the Geneva land register in 2017-04 (left) and 2019-04 (right) - Data : Canton of Geneva One can see that at such a scale, taking into account that the Canton of Geneva is one of the smallest in Switzerland, having a vision and a clear understanding of the modifications made between these two models is difficult by considering the two models separately. It's precisely where differences models can be useful to understand and analyze the evolution of the land register, along both the space and time dimensions.","title":"Difference Models : An Assessment Tool"},{"location":"PROJ-DTRK/#large-scale-analysis","text":"A first large-scale evaluation can be made on the overall models. A difference model can be computed considering the land register of Geneva in 2019 and 2017 as illustrated on the following image : Difference model on Geneva land register between 2019-04 and 2017-04 - Data : Canton of Geneva Two observations can be already made by looking at the difference model . In the first place, one can see that the amount of modifications brought to the land register is large in only two years. A large portion of the land register were subject to modifications or corrections, the unchanged parts being mostly limited outside the populated area. In the second place, one can observe large portions where differences seem to be accumulating over this period of time. Looking at them more closely leads to the conclusion that these zones were actually completely modified, as all elements are highlighted by the difference detection algorithm. The following image gives a closer view of such an area of differences accumulation : Focus on Carouge area of the 2019-04 and 2017-04 difference model - Data : Canton of Geneva Despite the amount of modifications outside this specific zone is also high, it is clear that the pointed zone contains more of them. Looking at it more closely leads to the conclusion that everything changed. In order to understand these areas of differences accumulation, the the land register experts of the Canton of Geneva ( SITG ) were questioned. They provided an explanation for these specific areas. Between 2017 and 2019 , these areas were subjected to a global correction in order to release the tension between the old reference frame LV03 [3] and the current one LV95 [4]. These corrections were made using the FINELTRA algorithm to modify the elements of the land register of the order of a few centimeters. The land register of Geneva provided the following illustration summarizing these reference frame corrections made between 2017 and 2019 on the Geneva territory : Reference frame corrections performed between 2017 and 2019 - Data : SITG Comparing this map from the land register with the computed model allows seeing how differences detection can emphasize this type of corrections efficiently, as the corrected zones on this previous image corresponds to the difference accumulation areas on the computed difference model .","title":"Large-Scale Analysis"},{"location":"PROJ-DTRK/#small-scale-analysis","text":"One can also dive deep into the details of the difference models . As we saw on the large scale analysis, two types of areas can be seen on the 2019-04-2017-04 difference model of Geneva : regular evolution with an accumulation of corrections and areas on which global corrections were applied. The following images propose a close view of these two types of situation : Illustration of the two observed type of evolutions of the land register - Data : Canton of Geneva On the left image above, one can observe the regular evolution of the land register where modifications are brought to the model in order to follow the evolution of the territory. On the right image above, one can see a close view of an area subjected to a global correction (reference frame), leading to a difference model highlighting all the elements. Analyzing more closely the right image above lead the observer to conclude that not all the elements are actually highlighted by the difference detection algorithm. Indeed, some elements are rendered in gray on the difference model , indicating their lack of modification between the two compared times. The following image emphasizes the unchanged elements that can be observed : Unchanged elements in the land register after reference frame correction - Data : SITG These unchanged elements can be surprising as they're found in an area that was subject to a global reference frame correction. This shows how difference models can be helpful to track down these type of events in order to check whether these unchanged elements are expected or are the results of a discrepancy in the land register evolution. Other example can be found in this very same area of the Geneva city. The following images give an illustration of two other close view where the unchanged element can be seen despite the reference frame correction : Unchanged elements in the land register after reference frame correction - Data : SITG On the left image above, one can observe that the unchanged elements are the railway tracks within the commune of Carouge . This is an interesting observation, as railway tracks can be considered as specific elements that can be subjected to different legislations regarding the land register. But it is clear that railway tracks were not considered in the reference frame correction. On the right image above, one can see another example of unchanged elements that are more complicated to explain, as they're in the middle of modified other elements. This clearly demonstrate how difference models can be helpful for analyzing and assessing the evolution of the land register models. Such models are able to drive users or automated processes and lead them to focus on relevant aspects and to define the good question in the context of analyzing the evolution of the land register.","title":"Small-Scale Analysis"},{"location":"PROJ-DTRK/#conclusion","text":"The presented difference models computed based on two temporal versions of the land register and using the 4D framework algorithm showed how differences can be emphasized for users and automated processes [1]. Difference models can be helpful to determine the amount and nature of changes that appear in the land register. Applying such an algorithm on land register is especially relevant as it is a highly living model, that evolves jointly with the territory it describes. Two main applications can be considered using difference models applied on the land register. In the first place, the difference models can be used to assess and analyze the regular evolution of the territory. Indeed, updating the land register is not a simple task. Such modifications involve a whole chain of decisions and verifications, from surveyors to the highest land register authority before to be integrated in the model. Being able to assess and analyze the modifications in the land register through difference models could be one interesting strengthening of the overall process. The second application of difference models could be as an assessment tool of global corrections applied to the land register or parts of it. These modifications are often linked to the reference frame and its evolution. Being able to assess the corrections through the difference models could add a helpful tool in order to verify that the elements of the land register where correctly processed. In this direction, difference models could be used during the introduction of the DM.flex reference frame for both analyzing its introduction and demonstrating that difference models can be an interesting point of view.","title":"Conclusion"},{"location":"PROJ-DTRK/#reproduction-resources","text":"To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Unfortunately, the used data are not currently public. In both cases, the land register INTERLIS datasets were provided to the STDL directly. You can contact both Thurgau Kanton and SITG : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) to query the data. In order to extract and convert the data from the INTERLIS models, the following code is used : INTERLIS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results.","title":"Reproduction Resources"},{"location":"PROJ-DTRK/#references","text":"[1] Automatic Detection of Changes in the Environment, N. Hamel, STDL 2020 [2] DM.flex reference frame [3] LV03 Reference frame [4] LV95 Reference frame","title":"References"},{"location":"PROJ-GEPOOL/","text":"Swimming Pool Detection from Aerial Images over the Canton of Geneva \u00b6 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL September 2020 to January 2021 - Published on May 18, 2021 Abstract : Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Introduction \u00b6 The Canton of Geneva manages a register of swimming pools, counting - in principle - all and only those swimming pools that are in-ground or, at least, permanently fixed to the ground. The swimming pool register is part of a far more general cadastre, including several other classes of objects (cf. this page ). Typically the swimming pool register is updated either by taking building/demolition permits into account, or by manually checking its multiple records (4000+ to date) against aerial images, which is quite a long and tedious task. Exploring the opportunity of leveraging Machine Learning to help domain experts in such an otherwise tedious tasks was one of the main motivations behind this study. As such, no prior requirements/expectations were set by the recipients. The study was autonomously conducted by the STDL team, using Open Source software and Open Data published by the Canton of Geneva. Domain experts were asked for feedback only at a later stage. In the following, details are provided regarding the various steps we followed. We refer the reader to this page for a thorough description of the generic STDL Object Detection Framework. Method \u00b6 Several steps are required to set the stage for object detection and eventually reach the goal of obtaining - ideally - even more than decent results. Despite the linear presentation that the reader will find here-below, multiple back-and-forths are actually required, especially through steps 2-4. 1. Data preparation \u00b6 As a very first step , one has to define the geographical region over which the study has to be conducted, the so-called \" Area of Interest \" (AoI). In the case of this specific application, the AoI was chosen and obtained as the geometric subtraction between the following two polygons: the unary union of all the polygons of the Canton of Geneva's cadastral parcels dataset, published as Open Data by the SITG , cf. PARCELLES DE LA MENSURATION ; the polygon corresponding to the Lake Geneva (\" lac L\u00e9man \" in French), included in the EMPRISE DU LAC LEMAN (Complet) open dataset, published by the SITG as well. The so-defined AoI covers both the known \"ground-truth\" labels and regions over which hypothetical unknown objects are expected to be detected. The second step consists in downloading aerial images from a remote server, following an established tiling strategy. We adopted the so-called \" Slippy Map \" tiling scheme. Aerial images were fetched from a raster web service hosted by the SITG and powered by ESRI ArcGIS Server. More precisely, the following dataset was used: ORTHOPHOTOS AGGLO 2018 . According to our configuration, this second step produces a folder including one GeoTIFF image per tile, each image having a size of 256x256 pixels. In terms of resolution - or better, in terms of \" Ground Sampling Distance \" (GSD) - the combination of 256x256 pixels images and zoom level 18 Slippy Map Tiles yields approximately a GSD of ~ 60 cm/pixel. The tests we performed at twice the resolution showed little gain in terms of predictive power, surely not enough to support the interest in engaging 4x more resources (storage, CPU/GPU, ...). The third step amounts to splitting the tiles covering the AoI (let's label them \"AoI tiles\") twice: first, tiles are partitioned into two subsets, according to whether they include ( GT tiles) or not ( oth tiles) ground-truth labels: \\(\\mbox{AoI tiles} = (\\mbox{GT tiles}) \\cup (\\mbox{oth tiles}),\\; \\mbox{with}\\; (\\mbox{GT tiles}) \\cap (\\mbox{oth tiles}) = \\emptyset\\) Then, ground-truth tiles are partitioned into three other subsets, namely the training ( trn ), validation ( val ) and test ( tst ) datasets: \\(\\mbox{GT tiles} = (\\mbox{trn tiles}) \\cup (\\mbox{val tiles}) \\cup (\\mbox{tst tiles})\\) with \\(A \\neq B \\Rightarrow A \\cap B = \\emptyset, \\quad \\forall A, B \\in \\{\\mbox{trn tiles}, \\mbox{val tiles}, \\mbox{tst tiles}, \\mbox{oth tiles}\\}\\) We opted for the 70%-15%-15% dataset splitting strategy. Slippy Map Tiles at zoom level 18 covering the Area of Interest, partitioned into several subsets: ground-truth (GT = trn + val + tst), other (oth). Zoom over a portion of the previous image. Concerning ground-truth labels, the final results of this study rely on a curated subset of the public dataset including polygons corresponding to the Canton of Geneva's registered swimming pools, cf. PISCINES . Indeed, some \"warming-up\" iterations of this whole process allowed us to semi-automatically identify tiles where the swimming pool register was inconsistent with aerial images, and viceversa. By manually inspecting the tiles displaying inconsistency, we discarded those tiles for which the swimming pool register seemed to be wrong (at least through the eyes of a Data Scientist; in a further iteration, this data curation step should be performed together with domain experts). While not having the ambition to return a \"100% ground-truth\" training dataset, this data curation step yielded a substantial gain in terms of \\(F_1\\) score (from ~82% to ~90%, to be more precise). 2. Model training \u00b6 A predictive model was trained, stemming from one of the pre-trained models provided by Detectron2 . In particular, the \"R50-FPN\" baseline was used (cf. this page ), which implements a Mask R-CNN architecture leveraging a ResNet-50 backbone along with a Feature Pyramid Network (FPN). We refer the reader e.g. to this blog article for further information about this kind of Deep Learning methods. Training a (Deep) Neural Network model means running an algorithm which iteratively adjusts the various parameters of a Neural Network (40+ million parameters in our case), in order to minimize the value of some \"loss function\". In addition to the model parameters (otherwise called \"weights\", too), multiple \"hyper-parameters\" exist, affecting the model and the way how the optimization is performed. In theory, one should automatize the hyper-parameters tuning , in order to eventually single out the best setting among all the possible ones. In practice, the hyper-parameters space is never fully explored; a minima , a systematic search should be performed, in order to find a \"sweet spot\" among a finite, discrete collection of settings. In our case, no systematic hyper-parameters tuning was actually performed. Instead, a few man hours were spent in order to manually tune the hyper-parameters, until a setting was found which the STDL team judged to be reasonably good (~90% \\(F_1\\) score on the test dataset, see details here-below). The optimal number of iterations was chosen so as to approximately minimize the loss on the validation dataset. 3. Prediction \u00b6 Each image resulting from the tiling of the AoI constitutes - let's say - the \"basic unit of computation\" of this analysis. Thus, the model optimized at the previous step was used to make predictions over: the oth images, meaning images covering no already known swimming pools; the trn , val and tst images, meaning images covering already known swimming pools. The combination of predictions 1 and 2 covers the entire AoI and allows us to discover potential new objects as well as to check whether some of the known objects are outdated, respectively. Image by image, the model produces one segmentation mask per detected object, accompanied by a score ranging from a custom minimum value (5% in our setting) to 100%. The higher the score, the most the model is confident about a given prediction. Sample detections of swimming pools, accompanied by scores. Note that multiple detections can concern the same object, if the latter extends over multiple tiles. Let us note that not only swimming pools exhibiting only \"obvious\" features (bluish color, rectangular shape, ...) were detected, but also: swimming pools covered by some tarp; empty swimming pools; etc. As a matter of fact, the training dataset was rich enough to also include samples of such somewhat tricky cases. 4. Prediction assessment \u00b6 As described here in more detail, in order to assess the reliability of the predictive model predictions have to be post-processed so as to switch from the image coordinates - ranging from (0, 0) to (255, 255) in our case, where 256x256 pixel images were used - to geographical coordinates. This amounts to applying an affine transformation to the various predictions, yielding a vector layer which we can compare with ground-truth ( GT ) data by means of spatial joins: objects which are detected and can also be found in GT data are referred to as \"true positives\" (TPs); objects which are detected but cannot be found in GT data are referred to as \"false positives\" (FPs); GT objects which are not detected are referred to as \"false negatives\" (FNs). Example of a true positive (TP), a false positive (FP) and a false negative (FN). Note that both the TP and the FP object are detected twice, as they extend over multiple tiles. The counting of TPs, FPs, FNs allow us to compute some standard metrics such as precision, recall and \\(F_1\\) score (cf. this Wikipedia page for further information). Actually, one count (hence one set of metrics) can be produced per choice of the minimum score that one is willing to accept. Choosing a threshold value (= thr ) means keeping all the predictions having a score >= thr and discarding the rest. Intuitively, a low threshold should yield a few false negatives; a high threshold should yield a few false positives. Such intuitions can be confirmed by the following diagram, which we obtained by sampling the values of thr by steps of 0.05 (= 5%), from 0.05 to 0.95. True positives (TPs), false negatives (FNs), and false positives (FPs) counted over the test dataset, as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. Performance metrics computed over the test dataset as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. The latter figure was obtained by evaluating the predictions of our best model over the test dataset. Inferior models exhibited a similar behavior, with a downward offset in terms of \\(F_1\\) score. In practice, upon iterating over multiple realizations (with different hyper-parameters, training data and so on) we aimed at maximizing the value of the \\(F_1\\) score on the validation dataset, and stopped when the \\(F_1\\) score went over the value of 90%. As the ground-truth data we used turned out not to be 100% accurate, the responsibility for mismatching predictions has to be shared between ground-truth data and the predictive model, at least in some cases. In a more ideal setting, ground-truth data would be 100% accurate and differences between a given metric (precision, recall, \\(F_1\\) score) and 100% should be imputed to the model. Domain experts feedback \u00b6 All the predictions having a score \\(\\geq\\) 5% obtained by our best model were exported to Shapefile and shared with the experts in charge of the cadastre of the Canton of Geneva, who carried out a thorough evaluation. By checking predictions against the swimming pool register as well as aerial images, it was empirically found that the threshold on the minimum score (= thr ) should be set as high as 97%, in order not to have too many false positives to deal with. In spite of such a high threshold, 562 potentially new objects were detected (over 4652 objects which were known when this study started), of which: 128 items are objects other than swimming pools (let's say an \"actual false positives\"); 211 items are swimming pools that are NOT subject to registration (temporary, above-ground, on top of a building, ...); 223 items are swimming pools that are subject to registration. This figures show that: on the one hand, the model performs quite well on the task it was trained for, in particular when an appropriate threshold is used; on the other hand, the meticulous review of results by domain experts remain essential. This said, automatic detections can surely be used to drive the domain experts' attention towards the areas which might require some. Examples of \"actual false positives\": a fountain (left) and a tunnel (right). Examples of detected swimming pools which are not subject to registration: placed on top of a building (left), inflatable hence temporary (right). Conclusion \u00b6 The analysis reported in this document confirms the opportunity of using state-of-the-art Deep Learning approaches to assist experts in some of their tasks, in this case that of keeping the cadastre up to date. Not only the opportunity was explored and actually confirmed, but valuable results were also produced, leading to the detection of previously unknown objects. At the same time, our study also shows how essential domain expertise still remains, despite the usage of such advanced methods. As a concluding remark, let us note that our predictive model may be further improved. In particular, it may be rendered less prone to false positives, for instance by: leveraging 3D data ( e.g. point clouds), in order to potentially remove temporary, above-ground swimming pools from the set of detected objects; injecting into the training dataset those predictions which were classified by domain experts as other objects or temporary swimming pools; leveraging some other datasets, already available through the SITG portal : buildings , miscellaneous objects , etc.","title":"<span style=\"text-transform:uppercase;\"> Swimming Pool Detection from Aerial Images over the Canton of Geneva </span>"},{"location":"PROJ-GEPOOL/#swimming-pool-detection-from-aerial-images-over-the-canton-of-geneva","text":"Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL September 2020 to January 2021 - Published on May 18, 2021 Abstract : Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date.","title":" Swimming Pool Detection from Aerial Images over the Canton of Geneva "},{"location":"PROJ-GEPOOL/#introduction","text":"The Canton of Geneva manages a register of swimming pools, counting - in principle - all and only those swimming pools that are in-ground or, at least, permanently fixed to the ground. The swimming pool register is part of a far more general cadastre, including several other classes of objects (cf. this page ). Typically the swimming pool register is updated either by taking building/demolition permits into account, or by manually checking its multiple records (4000+ to date) against aerial images, which is quite a long and tedious task. Exploring the opportunity of leveraging Machine Learning to help domain experts in such an otherwise tedious tasks was one of the main motivations behind this study. As such, no prior requirements/expectations were set by the recipients. The study was autonomously conducted by the STDL team, using Open Source software and Open Data published by the Canton of Geneva. Domain experts were asked for feedback only at a later stage. In the following, details are provided regarding the various steps we followed. We refer the reader to this page for a thorough description of the generic STDL Object Detection Framework.","title":"Introduction"},{"location":"PROJ-GEPOOL/#method","text":"Several steps are required to set the stage for object detection and eventually reach the goal of obtaining - ideally - even more than decent results. Despite the linear presentation that the reader will find here-below, multiple back-and-forths are actually required, especially through steps 2-4.","title":"Method"},{"location":"PROJ-GEPOOL/#1-data-preparation","text":"As a very first step , one has to define the geographical region over which the study has to be conducted, the so-called \" Area of Interest \" (AoI). In the case of this specific application, the AoI was chosen and obtained as the geometric subtraction between the following two polygons: the unary union of all the polygons of the Canton of Geneva's cadastral parcels dataset, published as Open Data by the SITG , cf. PARCELLES DE LA MENSURATION ; the polygon corresponding to the Lake Geneva (\" lac L\u00e9man \" in French), included in the EMPRISE DU LAC LEMAN (Complet) open dataset, published by the SITG as well. The so-defined AoI covers both the known \"ground-truth\" labels and regions over which hypothetical unknown objects are expected to be detected. The second step consists in downloading aerial images from a remote server, following an established tiling strategy. We adopted the so-called \" Slippy Map \" tiling scheme. Aerial images were fetched from a raster web service hosted by the SITG and powered by ESRI ArcGIS Server. More precisely, the following dataset was used: ORTHOPHOTOS AGGLO 2018 . According to our configuration, this second step produces a folder including one GeoTIFF image per tile, each image having a size of 256x256 pixels. In terms of resolution - or better, in terms of \" Ground Sampling Distance \" (GSD) - the combination of 256x256 pixels images and zoom level 18 Slippy Map Tiles yields approximately a GSD of ~ 60 cm/pixel. The tests we performed at twice the resolution showed little gain in terms of predictive power, surely not enough to support the interest in engaging 4x more resources (storage, CPU/GPU, ...). The third step amounts to splitting the tiles covering the AoI (let's label them \"AoI tiles\") twice: first, tiles are partitioned into two subsets, according to whether they include ( GT tiles) or not ( oth tiles) ground-truth labels: \\(\\mbox{AoI tiles} = (\\mbox{GT tiles}) \\cup (\\mbox{oth tiles}),\\; \\mbox{with}\\; (\\mbox{GT tiles}) \\cap (\\mbox{oth tiles}) = \\emptyset\\) Then, ground-truth tiles are partitioned into three other subsets, namely the training ( trn ), validation ( val ) and test ( tst ) datasets: \\(\\mbox{GT tiles} = (\\mbox{trn tiles}) \\cup (\\mbox{val tiles}) \\cup (\\mbox{tst tiles})\\) with \\(A \\neq B \\Rightarrow A \\cap B = \\emptyset, \\quad \\forall A, B \\in \\{\\mbox{trn tiles}, \\mbox{val tiles}, \\mbox{tst tiles}, \\mbox{oth tiles}\\}\\) We opted for the 70%-15%-15% dataset splitting strategy. Slippy Map Tiles at zoom level 18 covering the Area of Interest, partitioned into several subsets: ground-truth (GT = trn + val + tst), other (oth). Zoom over a portion of the previous image. Concerning ground-truth labels, the final results of this study rely on a curated subset of the public dataset including polygons corresponding to the Canton of Geneva's registered swimming pools, cf. PISCINES . Indeed, some \"warming-up\" iterations of this whole process allowed us to semi-automatically identify tiles where the swimming pool register was inconsistent with aerial images, and viceversa. By manually inspecting the tiles displaying inconsistency, we discarded those tiles for which the swimming pool register seemed to be wrong (at least through the eyes of a Data Scientist; in a further iteration, this data curation step should be performed together with domain experts). While not having the ambition to return a \"100% ground-truth\" training dataset, this data curation step yielded a substantial gain in terms of \\(F_1\\) score (from ~82% to ~90%, to be more precise).","title":"1. Data preparation"},{"location":"PROJ-GEPOOL/#2-model-training","text":"A predictive model was trained, stemming from one of the pre-trained models provided by Detectron2 . In particular, the \"R50-FPN\" baseline was used (cf. this page ), which implements a Mask R-CNN architecture leveraging a ResNet-50 backbone along with a Feature Pyramid Network (FPN). We refer the reader e.g. to this blog article for further information about this kind of Deep Learning methods. Training a (Deep) Neural Network model means running an algorithm which iteratively adjusts the various parameters of a Neural Network (40+ million parameters in our case), in order to minimize the value of some \"loss function\". In addition to the model parameters (otherwise called \"weights\", too), multiple \"hyper-parameters\" exist, affecting the model and the way how the optimization is performed. In theory, one should automatize the hyper-parameters tuning , in order to eventually single out the best setting among all the possible ones. In practice, the hyper-parameters space is never fully explored; a minima , a systematic search should be performed, in order to find a \"sweet spot\" among a finite, discrete collection of settings. In our case, no systematic hyper-parameters tuning was actually performed. Instead, a few man hours were spent in order to manually tune the hyper-parameters, until a setting was found which the STDL team judged to be reasonably good (~90% \\(F_1\\) score on the test dataset, see details here-below). The optimal number of iterations was chosen so as to approximately minimize the loss on the validation dataset.","title":"2. Model training"},{"location":"PROJ-GEPOOL/#3-prediction","text":"Each image resulting from the tiling of the AoI constitutes - let's say - the \"basic unit of computation\" of this analysis. Thus, the model optimized at the previous step was used to make predictions over: the oth images, meaning images covering no already known swimming pools; the trn , val and tst images, meaning images covering already known swimming pools. The combination of predictions 1 and 2 covers the entire AoI and allows us to discover potential new objects as well as to check whether some of the known objects are outdated, respectively. Image by image, the model produces one segmentation mask per detected object, accompanied by a score ranging from a custom minimum value (5% in our setting) to 100%. The higher the score, the most the model is confident about a given prediction. Sample detections of swimming pools, accompanied by scores. Note that multiple detections can concern the same object, if the latter extends over multiple tiles. Let us note that not only swimming pools exhibiting only \"obvious\" features (bluish color, rectangular shape, ...) were detected, but also: swimming pools covered by some tarp; empty swimming pools; etc. As a matter of fact, the training dataset was rich enough to also include samples of such somewhat tricky cases.","title":"3. Prediction"},{"location":"PROJ-GEPOOL/#4-prediction-assessment","text":"As described here in more detail, in order to assess the reliability of the predictive model predictions have to be post-processed so as to switch from the image coordinates - ranging from (0, 0) to (255, 255) in our case, where 256x256 pixel images were used - to geographical coordinates. This amounts to applying an affine transformation to the various predictions, yielding a vector layer which we can compare with ground-truth ( GT ) data by means of spatial joins: objects which are detected and can also be found in GT data are referred to as \"true positives\" (TPs); objects which are detected but cannot be found in GT data are referred to as \"false positives\" (FPs); GT objects which are not detected are referred to as \"false negatives\" (FNs). Example of a true positive (TP), a false positive (FP) and a false negative (FN). Note that both the TP and the FP object are detected twice, as they extend over multiple tiles. The counting of TPs, FPs, FNs allow us to compute some standard metrics such as precision, recall and \\(F_1\\) score (cf. this Wikipedia page for further information). Actually, one count (hence one set of metrics) can be produced per choice of the minimum score that one is willing to accept. Choosing a threshold value (= thr ) means keeping all the predictions having a score >= thr and discarding the rest. Intuitively, a low threshold should yield a few false negatives; a high threshold should yield a few false positives. Such intuitions can be confirmed by the following diagram, which we obtained by sampling the values of thr by steps of 0.05 (= 5%), from 0.05 to 0.95. True positives (TPs), false negatives (FNs), and false positives (FPs) counted over the test dataset, as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. Performance metrics computed over the test dataset as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. The latter figure was obtained by evaluating the predictions of our best model over the test dataset. Inferior models exhibited a similar behavior, with a downward offset in terms of \\(F_1\\) score. In practice, upon iterating over multiple realizations (with different hyper-parameters, training data and so on) we aimed at maximizing the value of the \\(F_1\\) score on the validation dataset, and stopped when the \\(F_1\\) score went over the value of 90%. As the ground-truth data we used turned out not to be 100% accurate, the responsibility for mismatching predictions has to be shared between ground-truth data and the predictive model, at least in some cases. In a more ideal setting, ground-truth data would be 100% accurate and differences between a given metric (precision, recall, \\(F_1\\) score) and 100% should be imputed to the model.","title":"4. Prediction assessment"},{"location":"PROJ-GEPOOL/#domain-experts-feedback","text":"All the predictions having a score \\(\\geq\\) 5% obtained by our best model were exported to Shapefile and shared with the experts in charge of the cadastre of the Canton of Geneva, who carried out a thorough evaluation. By checking predictions against the swimming pool register as well as aerial images, it was empirically found that the threshold on the minimum score (= thr ) should be set as high as 97%, in order not to have too many false positives to deal with. In spite of such a high threshold, 562 potentially new objects were detected (over 4652 objects which were known when this study started), of which: 128 items are objects other than swimming pools (let's say an \"actual false positives\"); 211 items are swimming pools that are NOT subject to registration (temporary, above-ground, on top of a building, ...); 223 items are swimming pools that are subject to registration. This figures show that: on the one hand, the model performs quite well on the task it was trained for, in particular when an appropriate threshold is used; on the other hand, the meticulous review of results by domain experts remain essential. This said, automatic detections can surely be used to drive the domain experts' attention towards the areas which might require some. Examples of \"actual false positives\": a fountain (left) and a tunnel (right). Examples of detected swimming pools which are not subject to registration: placed on top of a building (left), inflatable hence temporary (right).","title":"Domain experts feedback"},{"location":"PROJ-GEPOOL/#conclusion","text":"The analysis reported in this document confirms the opportunity of using state-of-the-art Deep Learning approaches to assist experts in some of their tasks, in this case that of keeping the cadastre up to date. Not only the opportunity was explored and actually confirmed, but valuable results were also produced, leading to the detection of previously unknown objects. At the same time, our study also shows how essential domain expertise still remains, despite the usage of such advanced methods. As a concluding remark, let us note that our predictive model may be further improved. In particular, it may be rendered less prone to false positives, for instance by: leveraging 3D data ( e.g. point clouds), in order to potentially remove temporary, above-ground swimming pools from the set of detected objects; injecting into the training dataset those predictions which were classified by domain experts as other objects or temporary swimming pools; leveraging some other datasets, already available through the SITG portal : buildings , miscellaneous objects , etc.","title":"Conclusion"},{"location":"PROJ-HETRES/","text":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds \u00b6 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Canton of Jura - PROJ-HETRES October 2022 to August 2023 - Published on November 13, 2023 All scripts are available on GitHub . Abstract : Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. 1. Introduction \u00b6 Since the drought episode of 2018, the canton of Jura and other cantons have noticed dieback of the beech trees in their forests 1 . In the canton of Jura, this problem mainly concerns the Ajoie region, where 1000 hectares of deciduous trees are affected 2 . This is of concern for the productivity and management of the forest, as well as for the security of walkers. In this context, the R\u00e9publique et Canton du Jura has contacted the Swiss Territorial Data Lab to develop a new monitoring solution based on data science, airborne images and LiDAR point clouds. The dieback symptoms are observable in the mortality of branches, the transparency of the tree crown and the leaf mass partition 3 . The vegetation health state influences the reflectance in images (airborne and satellite), which is often used as a monitoring tool, in particular under the form of vegetation indices: Normalized Difference Vegetation Index (NDVI), a combination of the near-infrared and red bands quantifying vegetation health; Vegetation Health Index (VHI), an index quantifying the decrease or increase of vegetation in comparison to a reference state. For instance, Brun et al. studied early-wilting in Central European forests with time series of the Normalized Difference Vegetation Index (NDVI) and estimate the surface concerned by early leaf-shedding 4 . Another technology used to monitor forests is light detection and ranging (LiDAR) as it penetrates the canopy and gives 3D information on trees and forest structures. Several forest and tree descriptors such as the canopy cover 5 or the standard deviation of crown return intensity 6 can be derived from the LiDAR point cloud to monitor vegetation health state. In 5 , the study was conducted at tree level, whereas in 6 stand level was studied. To work at tree level, it is necessary to segment individual trees in the LiDAR point cloud. On complex forests, like with a dense understory near tree stems, it is challenging to get correct segments without manual corrections. The aim of this project is to provide foresters with a map to help plan the felling of beech trees in the Ajoie's forests. To do so, we developed a combined method using LiDAR point clouds and airborne and satellite multispectral images to determine the health state of beech trees. 2. Study area \u00b6 The study was conducted in two areas of interest in the Ajoie region (Fig. 1.A); one near Mi\u00e9court (Fig. 1.B), the other one near Beurnev\u00e9sin (Fig. 1.C). Altogether they cover 5 km 2 , 1.4 % of the Canton of Jura's forests 7 . Mi\u00e9court sub-area is west-south and south oriented, whereas Beurnev\u00e9sin sub-area is rather east-south and south oriented. They are in the same altitude range (600-700 m) and are 2 km away from each other, thus near the same weather station. Figure 1: The study area is composed of two areas of interest. 3. Data \u00b6 The project makes use of different data types: LiDAR point cloud, airborne and satellite imagery, and ground truth data. Table 1 gives an overview of the data and their characteristics. Data have been acquired in late summer 2022 to have an actual and temporally correlated information on the health state of beech trees. Table 1: Overview of the data used in the project. Resolution Acquisition time Proprietary LiDAR 50-100 pts/m 2 08.2022 R\u00e9publique et Canton du Jura Airborne images 0.03 m 08.2022 R\u00e9publique et Canton du Jura Yearly variation of NDVI 10 m 06.2015-08.2022 Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) Weekly vegetation health index 10 m 06.2015-08.2022 ExoLabs Ground truth - (point data) 08.-10.2022 R\u00e9publique et Canton du Jura 3.1 LiDAR point cloud \u00b6 The LiDAR dataset was acquired on the 16th of August 2023 and its point density is 50-100 pts/m\u00b2. It is classified in the following classes: ground, low vegetation (2-10m), middle vegetation (10-20m) and high vegetation (20 m and above). It was delivered in the LAS format and had reflectance values 8 in the intensity storage field. 3.2 Airborne images \u00b6 The airborne images have a ground resolution of 3 cm and were acquired simultaneously to the LiDAR dataset. The camera captured the RGB bands, as well as the near infrared (NIR) one. The acquisition of images with a lot of overlap and oblique views allowed the production of a true orthoimage for a perfect match with the LiDAR point cloud and the data of the ground truth. 3.3 Satellite images \u00b6 The Sentinel-2 mission from the European Space Agency is passing every 6 days over Switzerland and allows free temporal monitoring at a 10 m resolution. The archives are available back to the beginning of beech tree dieback in 2018. 3.3.1 Yearly variation of NDVI \u00b6 The Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) have developed Web Services for vegetation monitoring derived from Sentinel-2 images. For this project, the yearly variation of NDVI 9 between two successive years is used. It measures the decrease in vegetation activity between August of one year (e.g. 2018) and June of the following year (e.g. 2019). The decrease is derived from rasters made of maximum values of the NDVI in June, July or August. The data are downloaded from the WCS service which delivers \"row\" indices: the NDVI values are not cut for a minimal threshold. 3.3.2 VHI \u00b6 The Vegetation Health Index (VHI) was generated by ETHZ, WSL and ExoLab within the SILVA project 10 which proposes several indices for forest monitoring. VHI from 2016 to 2022 is used. It is computed mainly out of Sentinel-2 images, but also out of images from other satellite missions, in order to have data to obtain a weekly index with no time gap. 3.4 Ground truth \u00b6 The ground truth was collected between August and October 2022 by foresters. They assessed the health of the beech trees based on four criteria 3 : mortality of branches; transparency of the tree crown; leaf mass partition; trunk condition and other health aspects. In addition, each tree was associated with its coordinates and pictures as illustrated in Figure 1 and Figure 2 respectively. The forester surveyed: 75 healthy, 77 unhealthy and 56 dead trees. Tree locations were first identified in the field with a GPS-enabled tablet on which the 2022 SWISSIMAGE mosaic was displayed. Afterwards, the tree locations were precisely adjusted on the trunk locations by visually locating the corresponding stems in the LiDAR point cloud with the help of the pictures taken in the field. The location and health status of a further 18 beech trees were added in July 2023. These 226 beeches - under which are 76 healthy, 77 affected and 73 dead trees - surveyed at the two dates are defined as the ground truth for this project. Figure 2: Examples of the three health states: left, a healthy tree with a dense green tree crown; center, an unhealthy tree with dead twigs and a scarce foliage; right, a dead tree completely dry. 4. Method \u00b6 The method developed is based on the processing of LiDAR point clouds and of airborne images . Ready-made vegetation indices derived from satellite imagery were also used. First, a segmentation of the trees in the LiDAR point cloud was carried out using the Digital-Forestry-Toolbox (DFT) 11 . Then, descriptors for the health state of the beech trees were derived from each dataset. Boxplots and corresponding t-test are computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. Finally, the descriptors were used jointly with the ground truth to train a random forest (RF) algorithm, before inferring for the study area. Figure 3: Overview of the methodology, which processes the data into health descriptors for beech trees, before training and evaluating a random forest. 4.1 LiDAR processing \u00b6 At the beginning of LiDAR processing, exploration of the data motivated the segmentation and descriptors computation. 4.1.2 Data exploration \u00b6 In order to get an understanding of the available information at the tree level, we manually segmented three healthy, five unhealthy and three dead trees. More unhealthy trees have been segmented to better represent dieback symptoms. Vertical slices of each tree were rotary extracted, providing visual information on the health state. 4.1.3 Segmentation \u00b6 To be able to describe the health state of each tree, segmentation of the forest was performed using the DFT. Parameters have been tuned to find an appropriate segmentation. Two strategies for peak isolation were tested on the canopy height model (CHM): Maxima smoothing: a height difference is set below which all local maxima are suppressed. Local maxima within search radius: the size of the dilation window for identification of maxima is dependent on the height. Each peak isolation method was tested on a range of parameters and on different cell resolutions for the CHM computation. The detailed plan of the simulation is given in Appendix 1 . The minimum tree height was set to 10 m. For computation time reasons, only 3 LiDAR tiles with 55 ground truth (GT) trees located on them were processed. To find the best segmentation, the locations of the GT trees were compared to the location of the segment peaks. GT trees with a segmented peak less than 4 m away were considered as True Positive (TP). The best segmentation was the one with the most TP. 4.1.4 Structural descriptors \u00b6 An alternative to the segmentation is to change of paradigm and perform the analyses at the stand level. Meng et al. 6 derived structural descriptors for acacia dieback at the stand level based on LiDAR point cloud. By adapting their method to the present case, the following descriptors were derived from the LiDAR point cloud using the LidR library from R 12 : Canopy maximal height. Scale and shape parameters of the Weibull density function fitted for the point distribution along the height. Coefficient of variation of leaf area density (cvLAD) describing the distribution of the vertical structure of photosynthetic tissue along the height. Vertical Complexity Index (VCI): Entropy measure of the vertical distribution of vegetation. Standard deviation of the canopy height model (sdCHM), reflects canopy height variations. Canopy cover (CC) and standard deviation (sdCC), reflects foliage density and coverage. Above ground biomass height (AGH), reflects the understory height until 10 m. Descriptors 1 to 6 are directly overtaken from Meng et al. All the descriptors were first computed for three grid resolutions: 10 m, 5 m and 2.5 m. In a second time, the DFT segments were considered as an adaptive grid around the trees, with the assumption that it is still more natural than a regular grid. Then, structural descriptors for vertical points distribution (descriptors 1 to 4) were computed on each segment, whereas descriptors for horizontal points distribution (descriptors 5 to 7) have been processed for 2.5 m grid. A weight was applied to the value of the latter descriptors according to the area of grid cells included in the footprint of the segments. Furthermore, LiDAR reflectance mean and standard deviation (sd) were computed for the segment crowns to differentiate them by their reflectance. 4.2 Image processing \u00b6 For the image processing, an initial step was to compute the normalized difference vegetation index (NDVI) for each raster image. The normalized difference vegetation index (NDVI) is an index commonly used for the estimation of the health state of vegetation 5 13 14 . \\[\\begin{align} \\ NDVI = {NIR-R \\over NIR+R} \\ \\end{align}\\] where NIR and R are the value of the pixel in the near-infrared and red band respectively. To uncover potential distinctive features between the classes, boxplots and principal component analysis were used on the images four bands (RGB-NIR) and the NDVI. Firstly, we tested if the brute pixel values allowed the distinction between classes at a pixel level. This method avoids the pit of the forest segmentation into trees. Secondly, we tested the same method, but with some low-pass filter to reduce the noise in the data. Thirdly, we tried to find distinct statistical features at the tree level. This approach allows decreasing the noise that can be present in high-resolution information. However, it necessitates having a reasonably good segmentation of the trees. Finally, color filtering and edge detection were tested in order to highlight and extract the linear structure of the branches. For each treatment, it is possible to do it with or without a mask on the tree height. As only trees between 20 m and 40 m tall are affected by dieback, a mask based on the Canopy Height Model (CHM) raster derived from the LiDAR point cloud was tested. Figure 4: Overview of different possible data treatments for the the statistical analysis. 4.2.1 Statistical tests on the original and filtered pixels \u00b6 The statistical tests were performed on the original and filtered pixels. Two low pass filters were tested: - Gaussian with a sigma of 5; - Bilinear downsampling with scale factors of 1/3, 1/5 and 1/17, corresponding to resolutions of 9, 15 and 50 cm. In the original and the filtered cases, the pixels for each GT tree were extracted from the images and sorted by class. Then, the corresponding NDVI is computed. Each pixel has 5 attributes corresponding to its value on the four bands (R, G, B, NIR) and its NDVI. First, the per-class boxplots of the attributes were executed to see if the distinction between classes was possible on one or several bands or on the NDVI. Then, the principal component analysis (PCA) was computed on the same values to see if their linear combination allowed the distinction of the classes. 4.2.2. Statistical tests at the tree level \u00b6 For the tests at the tree level, the GT trees were segmented by hand. For each tree, the statistics of the pixels were calculated over its polygon, on each band and for the NDVI. Then, the results were sorted by class. Each tree has five attributes per band or index corresponding to the statistics of its pixels: minimum (min), maximum (max), mean, median and standard deviation (std). Like with the pixels, the per-class boxplots of the attributes were executed to see if the distinction between classes was possible. Then, the PCA was computed. 4.2.3 Extraction of branches \u00b6 One of the beneficiaries noted that the branches are clearly visible on the RGB images. Therefore, it may be possible to isolate them with color filtering based on the RGB bands. We calibrated an RGB filter through trial and error to produce a binary mask indicating the location of the branches. A sieve filter was used to reduce the noise due to the lighter parts of the foliage. Then, a binary dilation was performed on the mask to highlight the results. Otherwise, they would be too thin to be visible at a 1:5'000 scale. A mask based on the CHM is integrated to the results to limit the influence of the ground. The branches have a characteristic linear structure. In addition, the branches of dead trees tend to be very light line on the dark forest ground and understory. Therefore, we thought that we may detect the dead branches thanks to edge detection. We used the canny edge detector and tested the python functions of the libraries openCV and skimage . 4.3 Satellite-based indices \u00b6 The yearly variation of NDVI and the VHI were used to take account of historical variations of NDVI from 2015 to 2022. For the VHI, the mean for each year is computed over the months considered for the yearly variation of NDVI. The pertinence of using these indices was explored: the values for each tree in the ground truth were extracted and observed in boxplots per health class in 2022 per year pair over the time span from 2015 to 2022. 4.4 Random Forest \u00b6 In R 12 , the caret and randomForest packages were used to train the random forest and make predictions. First, the ground truth was split into the training and the test datasets, with each class being split 70 % into the training set and 30 % into the test set. Health classes with not enough samples were completed with copies. Optimization of the RF was performed on the number of trees to develop and on the number of randomly sampled descriptors to test at each split. In addition, 5-fold cross-validation was used to ensure the use of different parts of the dataset. The search parameter space was from 100 to 1000 decision trees and from 4 to 10 descriptors as the default value is the square root of all descriptors, i.e. 7. RF was assessed using a custom metric, which is an adaptation of the false positive rate for the healthy class. It minimizes the amount of false healthy detections and of dead trees predicted as unhealthy (false unhealthy). It is called custom false positive rate (cFPR) in the text. It was preferred to have a model with more unhealthy predictions to control on the field, than missing unhealthy or dead trees. The cFPR goes from 0 (best) to 1 (worse). Table 2: Confusion matrix for the three health classes. Ground truth Healthy Unhealthy Dead Prediction Healthy A B C Unhealthy D E F Dead G H I According to the confusion matrix in Table 2, the cFPR is computed as follows: \\[\\begin{align} \\ cFPR = {(\ud835\udc35+\ud835\udc36+\ud835\udc39)\\over(\ud835\udc35+\ud835\udc36+\ud835\udc38+\ud835\udc39+\ud835\udc3b+\ud835\udc3c)}. \\ \\end{align}\\] In addition, the overall accuracy (OA), i.e. the ratio of correct predictions over all the predictions, and the sensitivity, which is, per class, the number of correct predictions divided by the number of samples from that class, are used. An ablation study was performed on descriptors to assess the contribution of the different data sources to the final performance. An \u201cimportant\u201d descriptor is having a strong influence on the increase in prediction errors in the case of random reallocation of the descriptor values in the training set. After the optimization, predictions for each DFT segments were computed using the best model according to the cFPR. The inferences were delivered as a thematic map with colors indicating the health state and hue indicating the fraction of decision trees in the RF having voted for the class (vote fraction). The purpose is to give a confidence information, with high vote fraction indicating robust predictions. Furthermore, the ground truth was evaluated for quantity and quality by two means: Removal of samples and its impact on the metric evaluation Splitting the training set into training subsets to evaluate on the original test set. Finally, after having developed the descriptors and the routine on high-quality data, we downgraded them to have resolutions similar to the ones of the swisstopo products (LiDAR: 20 pt/m 2 , orthoimage: 10 cm) and performed again the optimization and prediction steps. Indeed, the data acquisition was especially commissioned for this project and only covers the study area. If in the future the method should be extended, one would like to test if a lower resolution as the one of the standard national-wide product SWISSIMAGE could be sufficient. 5 Results and discussion \u00b6 In this section, the results obtained during the processing of each data source into descriptors are presented and discussed, followed by a section on the random forest results. 5.1 LiDAR processing \u00b6 For the LiDAR data, the reader will first discover the aspect of beech trees in the LiDAR point cloud according to their health state as studied in the data exploration. Then, the segmentation results and the obtained LiDAR-based descriptors will be presented. 5.1.2 Data exploration for 11 beech trees \u00b6 The vertical slices of 11 beech trees provided visual information on health state: branch shape, clearer horizontal and vertical point distribution. In Figure 5, one can appreciate the information shown by these vertical slices. The linear structure of the dead branches, the denser foliage of the healthy tree and the already smaller tree crown of the dead tree are well recognizable. Figure 5: Slices for three trees with different health state. Vertical slices of each tree were rotary extracted, providing visual information on the health state. Dead twigs and density of foliage are particularly distinctive. Some deep learning image classifier could treat LiDAR point cloud slices as artificial images and learn from them before classifying any arbitrary slice from the LiDAR point cloud. However, the subject is not adapted to transfer learning because 200 samples are not enough to train a model to classify three new classes, especially via images without resemblance to datasets used to pre-train deep learning models. 5.1.3 Segmentation \u00b6 Since the tree health classes were visually recognizable for the 11 trees, it was very interesting to individuate each tree in the LiDAR point cloud. After having searched for optimal parameters in the DFT, the best realization of each peak isolation method either slightly oversegmented or slightly undersegmented the forest. The forest has a complex structure with dominant and co-dominant trees, and with understory. A simple yet frequent example is the situation of a small pine growing in the shadow of a beech tree. It is difficult for an algorithm to differentiate between the points belonging to the pine and those belonging to the beech. Complex tree crowns (not spheric, with two maxima) especially lead to oversegmentation. As best segmentation, the smoothing of maxima on a 0.5 m resolution CHM was identified. Out of 55 GT trees, 52 were within a 4 m distance from the centroid of a segment. The total number of segments is 7347. This corresponds to 272 trees/ha. Report of a forest inventory in the Jura forest between 2003 and 2005 indicated a density of 286 trees/ha in high forest 7 . Since the ground truth is only made of point coordinates, it is difficult to assess quantitatively the correctness of the segments, i.e. the attribution of each point to the right segment. Therefore, the work at the tree level is only approximate. 5.1.4 Structural descriptors \u00b6 Nevertheless, the structural descriptors for each tree were computed from the segmented LiDAR point cloud. The t-test between health classes for each descriptor at each resolution (10 m, 5 m, 2.5 m and per-tree grid) are given in Appendices 2 , 3 , 4 and 5 . The number of significant descriptors per resolution is indicated to understand better the effect on the RF: at 10 m: 13 at 5 m: 17 at 2.5 m: 18 per tree: 15 The simulations at 5 m and at 2.5 m seemed a priori the most promising. In both constellations, t-tests indicated a significant different distribution for: maximal height, between the three health states, sdCHM, between the three health states, cvLAD, healthy trees against the others, mean reflectance, healthy trees against the others, VCI, healthy trees against unhealthy trees, canopy cover, healthy trees against dead trees, standard deviation of the reflectance, dead trees against the others, sdCC, dead trees against the others. The maximal height and the sdCHM appear to be the most suited descriptors to separate the three health states. The other descriptors are differentiating healthy trees from the others or dead trees from the others. From the 11 LiDAR-based descriptors, 8 are at least significant for the comparison between two classes. 5.2 Image processing \u00b6 Boxplots and PCA are given to illustrate the results of the image processing exploration. As the masking of pixels below and above the affected height made no difference in the interpretation of the results, they are presented here with the height mask. 5.2.1 Boxplots and PCA over the pixel values of the original images \u00b6 When the pixel values of the original images per health class are compared in boxplots (ex. Fig. 6), the sole brute value of the pixel is not enough to clearly distinguish between classes. Figure 6: Boxplots of the unfiltered pixel values on the different bands and the NDVI index by health class. The PCA in Figure 7 shows that it is not possible to distinguish the groups based on a linear combination of the brute pixel values of the band and NDVI. Figure 7: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI. 5.2.2 Boxplots and PCA over the pixel values of the filtered images \u00b6 A better separation of the different classes is noticeable after the application of a Gaussian filter. The most promising band is the NIR one for a separation of the healthy and dead classes. On the NDVI, the distinction between those two classes should also be possible as illustrated in Figure 8. In all cases, there is no possible distinction between the healthy and unhealthy classes. The separation between the healthy and dead trees on the NIR band would be around 130 and the slight overlap on the NDVI band is between approx. 0.04 and approx. 0.07. Figure 8: Boxplots of the pixel values on the different bands and the NDVI by health class after a Gaussian filter with sigma=5. As for the brute pixels, the overlap between the different classes is still very present in the PCA (Fig. 9). Figure 9: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI after a Gaussian filter with sigma=5. The boxplots produced on the resampled images (Figure 10) give similar results to the ones with the Gaussian filter. The healthy and dead classes are separated on the NIR band around 130. The unhealthy class stays similar to the healthy one. Figure 10: Boxplots of the pixel values on the different bands and the NDVI by health class after a downsampling filter with a factor 1/3. According to the PCA in Figure 11, it seems indeed not possible to distinguish between the classes only with the information presented in this section. Figure 11: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI after a downsampling filter with a factor 1/3. When the factor for the resampling is decreased, i.e. when the resulting resolution increases, the separation on the NIR band becomes stronger. With a factor of 1/17, the healthy and dead classes on the NDVI are almost entirely separated around the value of 0.04. 5.2.3 Boxplots and PCA over the tree statistics \u00b6 As an example for the per-tree statistics, the boxplots and PCA for the blue band are presented in Figures 12 to 14. On the mean and on the standard deviation, healthy and dead classes are well differentiated on the blue band as visible on Figure 12. The same is observed on the mean, median, and minimum of the NDVI, as well as on the maximum, mean, and median of the NIR band. However, there is no possible differentiation on the red and green bands. Figure 12: Boxplots of the statistics values for each tree on the blue band by health class. In the PCA in Figure 13, the groups of the healthy and dead trees are quite well separated, mostly along the first component. Figure 13: Distribution of the trees in the space of the principal components based on their statistical values on the blue band. On Figure 14, the first principal component is influenced principally by the standard deviation of the blue band. The mean, the median and the max have an influence too. This is in accordance with the boxplots where the standard deviation values presented the largest gap between classes. Figure 14: Influence of the statistics for the blue band on the first and second principal components. The point clouds of the dead and healthy classes are also well separated on the PCA of the NIR band and of the NDVI. No separation is visible on the PCA of the green and red bands. 5.2.4 Extraction of branches \u00b6 Finally, the extraction of dead branches was performed. Use of an RGB filter \u00b6 The result of the RGB filter is displayed in Figure 15. It is important to include the binary CHM in the visualization. Otherwise, the ground can have a significant influence on certain zones and distract from the dead trees. Some interferences can still be seen among the coniferous trees that have a similar light color as dead trees. Figure 15: Results produced by the RGB filter for the detection and highlight of dead branches over a zone with coniferous, healthy deciduous and dead deciduous trees. The parts in grey are the zones masked by the filter on the height. Use of the canny edge detector \u00b6 Figure 16 presents the result for the blue band which was the most promising one. The dead branches are well captured. However, there is a lot of noise around them due to the high contrasts in some parts of the foliage. The result is not usable as is. Using a stricter filter decreased the noise, but it also decreased the captured pixels of the branches. In addition, using a sieve filter or trying to combine the results with the ones of the RGB filter did not improve the situation. Figure 16: Test of the canny edge detector from sklearn over a dead tree by using only the blue band. The parts in grey are the zones masked by the CHM filter on the height. The results for the other bands, RGB images or the NDVI were not usable either. 5.2.5 Discussion \u00b6 The results at the tree level are the most promising ones. They are integrated into the random forest. Choosing to work at the tree-level means that all the trees must be segmented with the DFT. This adds uncertainties to the results. As explained in the dedicated section , the DFT has a tendency of over/under-segmenting the results. The procedures at the pixel level, whether on filtered or unfiltered images, are abandoned. For the branch detection, the results were compared with some observations on the terrain by a forest expert. He assessed the result as incorrect in several parts of the forest. Therefore, the use of dead branch detection was not integrated in the random forest. In addition, the edge detection was maybe not the right choice for dead branches and maybe we should have taken an approach more focused on detection of straight lines or graphs. The chance of success of such methods are difficult to predict as there can be a lot of variations in the form of the dead branches. 5.3 Vegetation indices from satellite imagery \u00b6 The t-test used to evaluate the ability of satellite indices to differentiate between health states are given in Appendices 6 and 7 . In the following two subsections, solely the significant tested groups are mentioned for understanding the RF performance. 5.3.1 Yearly variation of NDVI \u00b6 t-test on the yearly variation of NDVI indicated significance between: all health states in 2018-2019: 2018 was an especially dry and hot year, whereas 2019 was in the seasonal normals. The recovery in 2019 may have differed according to the health classes. healthy and other trees in 2016-2017 and 2019-2020: maybe healthy trees are responding diversely to environmental factors than affected trees. healthy and dead trees in 2021-2022: this reflects a higher increase of NDVI for the dead trees. Is the understory benefitting from clearer forest structure? 5.3.2 Vegetation Healthy Index \u00b6 t-test on the VHI indicated significance between: dead and other trees in 2017 healthy and dead trees in 2018 healthy and other trees in 2019 unhealthy and other trees in 2021 dead and unhealthy trees in 2020 and 2022 Explanations similar to those for NDVI may partly explain the significance obtained. In any case,it is encouraging that the VHI helps to differentiate health classes thanks to different evolution through the years. 5.4 Random Forest \u00b6 The results of the RF that are presented and discussed are: (1) the optimization and ablation study, (2) the ground truth analysis, (3) the predictions for the AOI and (4) the performance with downgraded data. 5.4.1 Optimization and ablation study \u00b6 In Table 3, performance for VHI and yearly variation of NDVI (yvNDVI) descriptors using their value at the location of the GT trees are compared. VHI (cFPR = 0.24, OA = 0.63) performed better than the yearly variation of NDVI (cFPR = 0.39, OA = 0.5). Both groups of descriptors are mostly derived from satellite data with the same resolution (10 m). A conceptual difference is that the VHI is a deviation to a long-term reference value; whereas the yearly variation of NDVI reflects the change between two years. For the latter, values can be high or low independently of the actual health state. Example, a succession of two bad years will indicate few to no differences in NDVI. Table 3: RF performance with satellite-based descriptors. Descriptors cFPR OA VHI 0.24 0.63 yvNDVI 0.39 0.5 Nonetheless, only the yearly variation of NDVI is used hereafter as it is available free of charge. Regarding the LiDAR descriptors, the tested resolutions indicated that the 5 m resolution (cFPR = 0.2 and OA = 0.65) was performing the best for the cFPR, but that the per-tree descriptors had the higher OA (cFPR = 0.33, OA = 0.67). At 5 m resolution, fewer affected trees are missed, but there are more errors in the classification, so more control on the field would have to be done. The question of which grid resolution to use on the forest is a complex one, as the forest consists of trees of different sizes. Further, even if dieback affects some areas more severely than others, it's not a continuous phenomenon, and it is important to be able to clearly delimit each tree. However, a grid, as the 2.5 m one, can also hinder to capture the entirety of some trees and the performance may decrease (LiDAR, 2.5 m, OA=0.63). Table 4: RF performance with LiDAR-based descriptors at different resolutions. Descriptors cFPR OA LiDAR, 10 m 0.3 0.6 LiDAR, 5 m 0.2 0.65 LiDAR, 2.5 m 0.28 0.63 LiDAR, per tree 0.33 0.67 Then, the 5 m resolution descriptors are kept for the rest of the analysis according to the decision of reducing missed dying trees. The ablation study performed on the descriptor sources is summarized in Table 5.A and Table 5.B. The two tables reflect performance for two different partitions of the samples in training and test sets. Since the performance is varying form several percents, the performance is impacted by the repartition of the samples. Following those values, the best setups for each partition respectively are the full model (cFPR = 0.13, OA = 0.76) and the airborne-based model (cFPR = 0.11, OA = 0.79). One notices that all the health classes are not predicted with the same accuracy. The airborne-based model, as described in Section 5.2.3 , is less sensitive to the healthy class; whereas the satellite-based model and the LiDAR-based model is more polarized to healthy and dead classes, with low sensitivity performance in the unhealthy class. Table 5.A: Ablation study results, partition A of the dataset. Descriptor sources cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead LiDAR 0.2 0.65 0.65 0.61 0.71 Airborne images 0.18 0.63 0.43 0.61 0.94 yvNDVI 0.4 0.49 0.78 0.26 0.41 LiDAR and yvNDVI 0.23 0.7 0.74 0.61 0.76 Airborne images and yvNDVI 0.15 0.73 0.65 0.7 0.88 LiDAR, airborne images and yvNDVI 0.13 0.76 0.65 0.74 0.94 Table 5.B: Ablation study results, partition B of the dataset. Descriptor sources cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead LiDAR 0.19 0.71 0.76 0.5 0.88 Airborne images 0.11 0.79 0.62 0.8 1 yvdNDVI 0.38 0.62 0.81 0.4 0.65 LiDAR and yvNDVI 0.27 0.74 0.86 0.5 0.88 Airborne images and yvNDVI 0.14 0.78 0.62 0.8 0.94 LiDAR, airborne images and yvNDVI 0.14 0.79 0.71 0.7 1 Even if the performance varies according to the dataset partition, the important descriptors remain quite similar between the two partitions as displayed in Figure 17.A and Figure 17.B. The yearly difference of NDVI between 2018 and 2019 ( NDVI_diff_1918 ) is the most important descriptor; standard deviation on the blue band ( b_std ) and the mean on the NIR band and NDVI ( nir_mean and ndvi_mean ) are standing out in both cases; from the LiDAR, the standard deviation of canopy cover ( sdcc ) and of the LiDAR reflectance ( i_sd_seg ) are the most important descriptors. The order of magnitude explains the better performance on partition B with the airborne-based model: for instance, the b_std has the magnitude of 7.6 instead of 4.6 with Partition B. Figure 17.A: Important descriptors for the full model, dataset partition A. Figure 17.B: Important descriptors for the full model, dataset partition B. The most important descriptor of the full model resulted to be the yearly variation of NDVI between 2018 and 2019. The former was a year with a dry and hot summer which has stressed beech trees and probably participated to cause forest damages 1 . This corroborates the ability of our RF method to monitor the response of trees to extreme drought events. However, the 10 m resolution of the index and the different adaptability of individual beech trees to drought may make the relationship between current health status and the index weak. This can explain that the presence of this descriptor in the full model doesn't offer better performance than the airborne-based model to predict the health state. Both the mean on the NIR band and the standard deviation on the blue band play an important role. Statistical study in Section 5.2.3 indicated that the models might confuse healthy and unhealthy classes. On one hand, airborne imagery only sees the top of the crown and may miss useful information on hidden part. On the other hand, airborne imagery has a good ability to detect dead trees thanks to different reflectance values in NIR and blue bands. One argument that could explain the lower performance of the model based on LiDAR-based descriptors is the difficulty to find the right scale to perform the analysis as beech trees can show a wide range of crown diameters. 5.4.2 Ground truth analysis \u00b6 With progressive removal of sample individuals from the training set, impact of individual beech trees on the performance is further analyzed. The performance variation is shown in Figure 18. The performance is rather stable in the sense that the sensitivities stay in a range of values similar to the initial one up to 40 samples removed, but with each removal, a slight instability in the metrics is visible. The size of the peaks indicates variations of 1 prediction for the dead class, but up to 6 predictions for the unhealthy class and up to 7 for the healthy class. During the sample removal, some samples were always predicted correctly, whereas others were often misclassified leading to the peaks in Figure 18. With the large number of descriptors in the full model, there is no straightforward profile of outliers to identify. Figure 18: Evolution of the per-class sensitivity with removal of samples. In addition, the subsampling of the training set in Table 6 shows that the OA varies only by max. 3% according to the subset used. It indicated again that the amount of ground truth allows to reach a stable OA range, but the characteristics of the samples does not allow a stable OA value. The sensitivity for the dead classes is stable, whereas sensitivity for healthy and unhealthy class are varying. Table 6: Performance according to different random seed for the creation of the training subset. Training set subpartition cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead Random seed = 2 0.13 0.76 0.61 0.83 0.88 Random seed = 22 0.15 0.78 0.70 0.78 0.88 Random seed = 222 0.18 0.75 0.65 0.74 0.88 Random seed = 2222 0.13 0.76 0.65 0.78 0.88 Random seed = 22222 0.10 0.78 0.65 0.83 0.88 5.4.3 Predictions \u00b6 The full model and the airborne-based-model were used to infer the health state of trees in the study area (Fig. 19). As indicated in Table 7, with the full model, 35.1 % of the segments were predicted as healthy, 53 % as unhealthy and 11.9 % as dead. With the airborne-based model, 42.6 % of the segments were predicted as healthy, 46.2 % as unhealthy and 11.2 % as dead. The two models agree on 74.3 % of the predictions. In the 25.6 % of disagreement, it is about 77.1% of disagreement between healthy and unhealthy predictions. Finally, 1.5% are critical disagreement (between healthy and dead classes). Table 7: Percentage of health in the AOI. Model Healthy [%] Unhealth [%] Dead [%] Full 35.1 53 11.9 Airborne-based 42.6 46.2 11.2 Control by forestry experts reported that the predictions mostly correspond to the field situation and that a weak vote fraction often corresponds to false predictions. They confirmed that the map is delivering useful information to help plan beech tree felling. The final model retained after excursion on the field is the full model. Figure 19: Extract of the predicted thematic health map. Green is for healthy, yellow for unhealthy, and red for dead trees. Hues indicate the RF fraction of votes. The predictions can be compared with the true orthophoto in the background. The polygons approximating the tree crowns correspond to the delimitation of segmented trees. 5.4.4 Downgraded data \u00b6 Finally, random forest models are trained and tested on downgraded data with the partition A of the ground truth for all descriptors and by descriptor sources. With this partition, RF have a better cFPR for the full model (0.08 instead of 0.13), the airborne-based model (0.08 instead of 0.21) and the LiDAR-based model (0.28 instead of 0.31). The OA is also better (full model: 0.84 instead of 0.76, airborne-based model: 0.77 instead of 0.63), except in the case of the LiDAR-based model (0.63 instead of 0.66). It indicated that the resolution of 10 cm in the aerial imagery does not weaken the model and can even improve it. For the LiDAR point cloud, a reduction by a factor 5 of the density has not changed much the performance. Table 7.A: Performance for RF trained and tested with the partition A of the dataset of downgraded data. Simulation cFPR OA Full 0.08 0.84 Airborne-based 0.08 0.77 LiDAR-based 0.28 0.63 Table 7.A: Performance for RF trained and tested with the partition A of the dataset for original data. Simulation cFPR OA Full 0.13 0.76 Airborne-based 0.21 0.63 LiDAR-based 0.31 0.66 When the important descriptors are compared between the original and downgraded model, one notices that the airborne descriptors gained in importance in the full model when data are downgraded. The downgraded model showed sufficient accuracy for the objective of the project. 6 Conclusion and outlook \u00b6 The study has demonstrated the ability of a random forest algorithm to learn from structural descriptors derived from LiDAR point clouds and from vegetation reflectance in airborne and satellite images to predict the health state of beech trees. Depending on the used datasets for training and test, the optimized full model including all descriptors reached an OA of 0.76 or of 0.79, with corresponding cFPR values of 0.13 and 0.14 respectively. These metrics are sufficient for the purpose of prioritizing beech tree felling. The produced map, with the predicted health state and the corresponding votes for the segments, delivers useful information for forest management. The cantonal foresters validated the outcomes of this proof-of-concept and explained how the location of affected beech trees as individuals or as groups are used to target high-priority areas. The full model highlighted the importance of the yearly variation of NDVI between a drought year (2018) and a normal year (2019). The airborne imagery showed good ability to predict dead trees, whereas confusion remained between healthy and unhealthy trees. The quality of the LiDAR point cloud segmentation may explain the limited performance of the LiDAR-based model. Finally, the model trained and tested on downgraded data gave an OA of 0.84 and a cFPR of 0.08. In this model, the airborne-based descriptors gained in importance. It was concluded that a 10 cm resolution may help the model by reducing the noise in the image. Outlooks for improving results include improving the ground truth representativeness of symptoms in the field and continuing research into descriptors for differentiating between healthy and unhealthy trees: For the image processing, suggestions are the integration of more statistics like the skewness and kurtosis of the reflectance as in Junttila et al. (2022) 15 . LiDAR-based descriptors had limited impact on the final results. To better valorize them for an application on beech trees, further research would be needed. Beside producing a cleaner segmentation and finding additional descriptors, it could consist in mixing the descriptors at the different resolutions and, with the help of the importance analysis, estimate at which resolution each descriptor brings the most information to the classification. The results showed the important contribution of vegetation indices derived from satellite imagery reflecting the drought year of 2018. If available, using historical image data of higher resolution to derive more descriptors could help improve individual tree health assessment. The possibility of further developments put aside, the challenge is now the extension of the methodology to a larger area. The simultaneity of the data is necessary to an accurate analysis. It has been shown that the representativeness of the ground truth has to be improved to obtain better and more stable results. Thus, for an extension to further areas, we recommend collecting additional ground truth measurements. The health state of the trees showed some autocorrelation that could have boosted our results and make them less representative of the whole forest. They should be more scattered in the forest. Furthermore, required data are a true orthophoto and a LiDAR point cloud for per-tree analysis. It should be possible to use an old LiDAR acquisition to produce a CHM and renounce to use LiDAR-based descriptors without degrading the performance of the model too much. 7 Appendixes \u00b6 7.1 Simulation plan for DFT parameter tuning \u00b6 Table 8: parameter tuning for DFT. CHM cell size [m] Maxima smoothing Local maxima within search radius 0.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 2.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 7.2 t-tests \u00b6 t-test were computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. 7.2.1 t-tests on LiDAR-based descriptors at 10 m \u00b6 Table 9: t-test on LiDAR-based descriptors at 10 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.002 1.12E-11 3.23E-04 scale parameter 0.005 0.014 0.964 shape parameter 0.037 0.002 0.269 cvLAD 0.001 2.22E-04 0.353 VCI 0.426 0.094 0.358 mean reflectance 4.13E-05 0.002 0.164 sd of reflectance 0.612 3.33E-06 9.21E-05 canopy cover 0.009 0.069 0.340 sdCC 0.002 0.056 0.324 sdCHM 0.316 0.262 0.892 AGH 0.569 0.055 0.120 7.2.2 t-test on LiDAR-based descriptors at 5 m \u00b6 Table 10: t-test on LiDAR-based descriptors at 5 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.001 4.67E-12 1.73E-04 scale parameter 0.072 0.831 0.204 shape parameter 0.142 0.654 0.361 cvLAD 9.14E-06 3.22E-05 0.667 VCI 0.006 0.104 0.485 mean reflectance 6.60E-05 2.10E-06 0.249 sd of reflectance 0.862 2.26E-08 9.24E-08 canopy cover 0.288 0.001 0.003 sdCC 1.42E-05 1.94E-11 0.001 sdCHM 0.004 1.94E-08 0.002 AGH 0.783 0.071 0.095 7.2.3 t-test on LiDAR-based descriptors at 2.5 m \u00b6 Table 11: t-test on LiDAR-based descriptors at 2.5 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 3.76E-04 7.28E-11 4.80E-04 scale parameter 0.449 0.283 5.60E-01 shape parameter 0.229 0.087 0.462 cvLAD 3.59E-04 1.06E-07 0.012 VCI 0.004 1.99E-05 0.072 mean reflectance 3.15E-04 5.27E-07 0.068 sd of reflectance 0.498 1.10E-10 4.66E-11 canopy cover 0.431 0.004 0.019 sdCC 0.014 1.94E-13 6.94E-09 sdCHM 0.003 5.56E-07 0.006 AGH 0.910 0.132 0.132 7.2.4 t-test on LiDAR-based descriptors per tree \u00b6 Table 12: t-test on LiDAR-based descriptors per tree. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.001 1.98E-11 2.61E-04 scale parameter 0.726 0.618 0.413 shape parameter 0.739 0.795 0.564 cvLAD 0.001 4.23E-04 0.526 VCI 0.145 0.312 0.763 mean reflectance 1.19E-04 0.001 0.949 sd of reflectance 0.674 3.70E-07 4.79E-07 canopy cover 0.431 0.005 0.023 sdCC 0.014 4.43E-13 1.10E-08 sdCHM 0.003 2.71E-07 0.004 AGH 0.910 0.090 0.087 7.2.5 t-tests on yearly variation of NDVI \u00b6 Table 13: t-test on yearly variation of NDVI. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead 2016 0.177 0.441 0.037 2017 0.079 2.20E-06 0.004 2018 0.093 1.57E-04 0.132 2019 0.003 0.001 0.816 2020 0.536 0.041 0.005 2021 0.002 0.894 0.003 2022 0.131 0.103 0.002 7.2.6 t-test on VHI \u00b6 Table 14: t-test on VHI. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead 2015-2016 0.402 0.572 0.767 2016-2017 0.005 0.002 0.885 2017-2018 0.769 0.329 0.505 2018-2019 2.64E-05 3.98E-14 0.001 2019-2020 7.86E-06 9.55E-05 0.427 2020-2021 0.028 0.790 0.018 2021-2022 0.218 0.001 0.080 8 Sources and references \u00b6 Indications on software and hardware requirements, as well as the code used to perform the project, are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-hetres/tree/main. Other sources of information mentioned in this documentation are listed here: OFEV et al. (\u00e9d.). La canicule et la s\u00e9cheresse de l\u2019\u00e9t\u00e9 2018. Impacts sur l\u2019homme et l\u2019environnement. Technical Report 1909, Office f\u00e9d\u00e9ral de l\u2019environnement, Berne, 2019. \u21a9 \u21a9 Beno\u00eet Grandclement and Daniel Bachmann. 19h30 - En Suisse, la s\u00e9cheresse qui s\u00e9vit depuis plusieurs semaines frappe durement les arbres - Play RTS. February 2023. URL: https://www.rts.ch/play/tv/19h30/video/en-suisse-la-secheresse-qui-sevit-depuis-plusieurs-semaines-frappe-durement-les-arbres?urn=urn:rts:video:13829524 (visited on 2023-03-28). \u21a9 Xavier Gauquelin, editor. Guide de gestion des for\u00eats en crise sanitaire . Office National des For\u00eats, Institut pour le D\u00e9veloppement Forestier, Paris, 2010. ISBN 978-2-84207-344-2. \u21a9 \u21a9 Philipp Brun, Achilleas Psomas, Christian Ginzler, Wilfried Thuiller, Massimiliano Zappa, and Niklaus E. Zimmermann. Large-scale early-wilting response of Central European forests to the 2018 extreme drought. Global Change Biology , 26(12):7021\u20137035, 2020. _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/gcb.15360. URL: https://onlinelibrary.wiley.com/doi/abs/10.1111/gcb.15360 (visited on 2022-10-13), doi:10.1111/gcb.15360 . \u21a9 Run Yu, Youqing Luo, Quan Zhou, Xudong Zhang, Dewei Wu, and Lili Ren. A machine learning algorithm to detect pine wilt disease using UAV-based hyperspectral imagery and LiDAR data at the tree level. International Journal of Applied Earth Observation and Geoinformation , 101:102363, September 2021. URL: https://www.sciencedirect.com/science/article/pii/S0303243421000702 (visited on 2022-10-13), doi:10.1016/j.jag.2021.102363 . \u21a9 \u21a9 \u21a9 Pengyu Meng, Hong Wang, Shuhong Qin, Xiuneng Li, Zhenglin Song, Yicong Wang, Yi Yang, and Jay Gao. Health assessment of plantations based on LiDAR canopy spatial structure parameters. International Journal of Digital Earth , 15(1):712\u2013729, December 2022. URL: https://www.tandfonline.com/doi/full/10.1080/17538947.2022.2059114 (visited on 2022-12-07), doi:10.1080/17538947.2022.2059114 . \u21a9 \u21a9 \u21a9 Patrice Eschmann, Pascal Kohler, Vincent Brahier, and Jo\u00ebl Theubet. La for\u00eat jurassienne en chiffres, R\u00e9sultats et interpr\u00e9tation de l'inventaire forestier cantonal 2003 - 2005. Technical Report, R\u00e9publique et Canton du Jura, St-Ursanne, 2006. URL: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjHuZyfhoSBAxU3hP0HHeBtC4sQFnoECDcQAQ&url=https%3A%2F%2Fwww.jura.ch%2FHtdocs%2FFiles%2FDepartements%2FDEE%2FENV%2FFOR%2FDocuments%2Fpdf%2Frapportinventfor0305.pdf%3Fdownload%3D1&usg=AOvVaw0yr9WOtxMyY-87avVMS9YM&opi=89978449However . \u21a9 \u21a9 Agnieska Ptak. (5) Amplitude vs Reflectance \\textbar LinkedIn. June 2020. URL: https://www.linkedin.com/pulse/amplitude-vs-reflectance-agnieszka-ptak/ (visited on 2023-08-11). \u21a9 BFH-HAFL and BAFU. Waldmonitoring.ch : wcs_ndvi_diff_2016_2015, wcs_ndvi_diff_2017_2016, wcs_ndvi_diff_2018_2017, wcs_ndvi_diff_2019_2018, wcs_ndvi_diff_2020_2019, wcs_ndvi_diff_2021_2020, wcs_ndvi_diff_2022_2021. URL: https://geoserver.karten-werk.ch/wfs?request=GetCapabilities . \u21a9 Reik Leiterer, Gillian Milani, Jan Dirk Wegner, and Christian Ginzler. ExoSilva - ein Multi\u00ad-Sensor\u00ad-Ansatz f\u00fcr ein r\u00e4umlich und zeitlich hochaufgel\u00f6stes Monitoring des Waldzustandes. In Neue Fernerkundungs\u00adtechnologien f\u00fcr die Umweltforschung und Praxis , 17\u201322. Swiss Federal Institute for Forest, Snow and Landscape Research, WSL, April 2023. URL: https://www.dora.lib4ri.ch/wsl/islandora/object/wsl%3A33057 (visited on 2023-11-13), doi:10.55419/wsl:33057 . \u21a9 Matthew Parkan. Mparkan/Digital-Forestry-Toolbox: Initial release. April 2018. URL: https://zenodo.org/record/1213013 (visited on 2023-08-11), doi:10.5281/ZENODO.1213013 . \u21a9 R Core Team. R: A Language and Environment for Statistical Computing. 2023. URL: https://www.R-project.org/ . \u21a9 \u21a9 Olga Brovkina, Emil Cienciala, Peter Surov\u00fd, and P\u0159emysl Janata. Unmanned aerial vehicles (UAV) for assessment of qualitative classification of Norway spruce in temperate forest stands. Geo-spatial Information Science , 21(1):12\u201320, January 2018. URL: https://www.tandfonline.com/doi/full/10.1080/10095020.2017.1416994 (visited on 2022-07-15), doi:10.1080/10095020.2017.1416994 . \u21a9 N.K. Gogoi, Bipul Deka, and L.C. Bora. Remote sensing and its use in detection and monitoring plant diseases: A review. Agricultural Reviews , December 2018. doi:10.18805/ag.R-1835 . \u21a9 Samuli Junttila, Roope N\u00e4si, Niko Koivum\u00e4ki, Mohammad Imangholiloo, Ninni Saarinen, Juha Raisio, Markus Holopainen, Hannu Hyypp\u00e4, Juha Hyypp\u00e4, P\u00e4ivi Lyytik\u00e4inen-Saarenmaa, Mikko Vastaranta, and Eija Honkavaara. Multispectral Imagery Provides Benefits for Mapping Spruce Tree Decline Due to Bark Beetle Infestation When Acquired Late in the Season. Remote Sensing , 14(4):909, February 2022. URL: https://www.mdpi.com/2072-4292/14/4/909 (visited on 2023-10-27), doi:10.3390/rs14040909 . \u21a9","title":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds"},{"location":"PROJ-HETRES/#dieback-of-beech-trees-methodology-for-determining-the-health-state-of-beech-trees-from-airborne-images-and-lidar-point-clouds","text":"Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Canton of Jura - PROJ-HETRES October 2022 to August 2023 - Published on November 13, 2023 All scripts are available on GitHub . Abstract : Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors.","title":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds"},{"location":"PROJ-HETRES/#1-introduction","text":"Since the drought episode of 2018, the canton of Jura and other cantons have noticed dieback of the beech trees in their forests 1 . In the canton of Jura, this problem mainly concerns the Ajoie region, where 1000 hectares of deciduous trees are affected 2 . This is of concern for the productivity and management of the forest, as well as for the security of walkers. In this context, the R\u00e9publique et Canton du Jura has contacted the Swiss Territorial Data Lab to develop a new monitoring solution based on data science, airborne images and LiDAR point clouds. The dieback symptoms are observable in the mortality of branches, the transparency of the tree crown and the leaf mass partition 3 . The vegetation health state influences the reflectance in images (airborne and satellite), which is often used as a monitoring tool, in particular under the form of vegetation indices: Normalized Difference Vegetation Index (NDVI), a combination of the near-infrared and red bands quantifying vegetation health; Vegetation Health Index (VHI), an index quantifying the decrease or increase of vegetation in comparison to a reference state. For instance, Brun et al. studied early-wilting in Central European forests with time series of the Normalized Difference Vegetation Index (NDVI) and estimate the surface concerned by early leaf-shedding 4 . Another technology used to monitor forests is light detection and ranging (LiDAR) as it penetrates the canopy and gives 3D information on trees and forest structures. Several forest and tree descriptors such as the canopy cover 5 or the standard deviation of crown return intensity 6 can be derived from the LiDAR point cloud to monitor vegetation health state. In 5 , the study was conducted at tree level, whereas in 6 stand level was studied. To work at tree level, it is necessary to segment individual trees in the LiDAR point cloud. On complex forests, like with a dense understory near tree stems, it is challenging to get correct segments without manual corrections. The aim of this project is to provide foresters with a map to help plan the felling of beech trees in the Ajoie's forests. To do so, we developed a combined method using LiDAR point clouds and airborne and satellite multispectral images to determine the health state of beech trees.","title":"1. Introduction"},{"location":"PROJ-HETRES/#2-study-area","text":"The study was conducted in two areas of interest in the Ajoie region (Fig. 1.A); one near Mi\u00e9court (Fig. 1.B), the other one near Beurnev\u00e9sin (Fig. 1.C). Altogether they cover 5 km 2 , 1.4 % of the Canton of Jura's forests 7 . Mi\u00e9court sub-area is west-south and south oriented, whereas Beurnev\u00e9sin sub-area is rather east-south and south oriented. They are in the same altitude range (600-700 m) and are 2 km away from each other, thus near the same weather station. Figure 1: The study area is composed of two areas of interest.","title":"2. Study area"},{"location":"PROJ-HETRES/#3-data","text":"The project makes use of different data types: LiDAR point cloud, airborne and satellite imagery, and ground truth data. Table 1 gives an overview of the data and their characteristics. Data have been acquired in late summer 2022 to have an actual and temporally correlated information on the health state of beech trees. Table 1: Overview of the data used in the project. Resolution Acquisition time Proprietary LiDAR 50-100 pts/m 2 08.2022 R\u00e9publique et Canton du Jura Airborne images 0.03 m 08.2022 R\u00e9publique et Canton du Jura Yearly variation of NDVI 10 m 06.2015-08.2022 Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) Weekly vegetation health index 10 m 06.2015-08.2022 ExoLabs Ground truth - (point data) 08.-10.2022 R\u00e9publique et Canton du Jura","title":"3. Data"},{"location":"PROJ-HETRES/#31-lidar-point-cloud","text":"The LiDAR dataset was acquired on the 16th of August 2023 and its point density is 50-100 pts/m\u00b2. It is classified in the following classes: ground, low vegetation (2-10m), middle vegetation (10-20m) and high vegetation (20 m and above). It was delivered in the LAS format and had reflectance values 8 in the intensity storage field.","title":"3.1 LiDAR point cloud"},{"location":"PROJ-HETRES/#32-airborne-images","text":"The airborne images have a ground resolution of 3 cm and were acquired simultaneously to the LiDAR dataset. The camera captured the RGB bands, as well as the near infrared (NIR) one. The acquisition of images with a lot of overlap and oblique views allowed the production of a true orthoimage for a perfect match with the LiDAR point cloud and the data of the ground truth.","title":"3.2 Airborne images"},{"location":"PROJ-HETRES/#33-satellite-images","text":"The Sentinel-2 mission from the European Space Agency is passing every 6 days over Switzerland and allows free temporal monitoring at a 10 m resolution. The archives are available back to the beginning of beech tree dieback in 2018.","title":"3.3 Satellite images"},{"location":"PROJ-HETRES/#34-ground-truth","text":"The ground truth was collected between August and October 2022 by foresters. They assessed the health of the beech trees based on four criteria 3 : mortality of branches; transparency of the tree crown; leaf mass partition; trunk condition and other health aspects. In addition, each tree was associated with its coordinates and pictures as illustrated in Figure 1 and Figure 2 respectively. The forester surveyed: 75 healthy, 77 unhealthy and 56 dead trees. Tree locations were first identified in the field with a GPS-enabled tablet on which the 2022 SWISSIMAGE mosaic was displayed. Afterwards, the tree locations were precisely adjusted on the trunk locations by visually locating the corresponding stems in the LiDAR point cloud with the help of the pictures taken in the field. The location and health status of a further 18 beech trees were added in July 2023. These 226 beeches - under which are 76 healthy, 77 affected and 73 dead trees - surveyed at the two dates are defined as the ground truth for this project. Figure 2: Examples of the three health states: left, a healthy tree with a dense green tree crown; center, an unhealthy tree with dead twigs and a scarce foliage; right, a dead tree completely dry.","title":"3.4 Ground truth"},{"location":"PROJ-HETRES/#4-method","text":"The method developed is based on the processing of LiDAR point clouds and of airborne images . Ready-made vegetation indices derived from satellite imagery were also used. First, a segmentation of the trees in the LiDAR point cloud was carried out using the Digital-Forestry-Toolbox (DFT) 11 . Then, descriptors for the health state of the beech trees were derived from each dataset. Boxplots and corresponding t-test are computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. Finally, the descriptors were used jointly with the ground truth to train a random forest (RF) algorithm, before inferring for the study area. Figure 3: Overview of the methodology, which processes the data into health descriptors for beech trees, before training and evaluating a random forest.","title":"4. Method"},{"location":"PROJ-HETRES/#41-lidar-processing","text":"At the beginning of LiDAR processing, exploration of the data motivated the segmentation and descriptors computation.","title":"4.1 LiDAR processing"},{"location":"PROJ-HETRES/#42-image-processing","text":"For the image processing, an initial step was to compute the normalized difference vegetation index (NDVI) for each raster image. The normalized difference vegetation index (NDVI) is an index commonly used for the estimation of the health state of vegetation 5 13 14 . \\[\\begin{align} \\ NDVI = {NIR-R \\over NIR+R} \\ \\end{align}\\] where NIR and R are the value of the pixel in the near-infrared and red band respectively. To uncover potential distinctive features between the classes, boxplots and principal component analysis were used on the images four bands (RGB-NIR) and the NDVI. Firstly, we tested if the brute pixel values allowed the distinction between classes at a pixel level. This method avoids the pit of the forest segmentation into trees. Secondly, we tested the same method, but with some low-pass filter to reduce the noise in the data. Thirdly, we tried to find distinct statistical features at the tree level. This approach allows decreasing the noise that can be present in high-resolution information. However, it necessitates having a reasonably good segmentation of the trees. Finally, color filtering and edge detection were tested in order to highlight and extract the linear structure of the branches. For each treatment, it is possible to do it with or without a mask on the tree height. As only trees between 20 m and 40 m tall are affected by dieback, a mask based on the Canopy Height Model (CHM) raster derived from the LiDAR point cloud was tested. Figure 4: Overview of different possible data treatments for the the statistical analysis.","title":"4.2 Image processing"},{"location":"PROJ-HETRES/#43-satellite-based-indices","text":"The yearly variation of NDVI and the VHI were used to take account of historical variations of NDVI from 2015 to 2022. For the VHI, the mean for each year is computed over the months considered for the yearly variation of NDVI. The pertinence of using these indices was explored: the values for each tree in the ground truth were extracted and observed in boxplots per health class in 2022 per year pair over the time span from 2015 to 2022.","title":"4.3 Satellite-based indices"},{"location":"PROJ-HETRES/#44-random-forest","text":"In R 12 , the caret and randomForest packages were used to train the random forest and make predictions. First, the ground truth was split into the training and the test datasets, with each class being split 70 % into the training set and 30 % into the test set. Health classes with not enough samples were completed with copies. Optimization of the RF was performed on the number of trees to develop and on the number of randomly sampled descriptors to test at each split. In addition, 5-fold cross-validation was used to ensure the use of different parts of the dataset. The search parameter space was from 100 to 1000 decision trees and from 4 to 10 descriptors as the default value is the square root of all descriptors, i.e. 7. RF was assessed using a custom metric, which is an adaptation of the false positive rate for the healthy class. It minimizes the amount of false healthy detections and of dead trees predicted as unhealthy (false unhealthy). It is called custom false positive rate (cFPR) in the text. It was preferred to have a model with more unhealthy predictions to control on the field, than missing unhealthy or dead trees. The cFPR goes from 0 (best) to 1 (worse). Table 2: Confusion matrix for the three health classes. Ground truth Healthy Unhealthy Dead Prediction Healthy A B C Unhealthy D E F Dead G H I According to the confusion matrix in Table 2, the cFPR is computed as follows: \\[\\begin{align} \\ cFPR = {(\ud835\udc35+\ud835\udc36+\ud835\udc39)\\over(\ud835\udc35+\ud835\udc36+\ud835\udc38+\ud835\udc39+\ud835\udc3b+\ud835\udc3c)}. \\ \\end{align}\\] In addition, the overall accuracy (OA), i.e. the ratio of correct predictions over all the predictions, and the sensitivity, which is, per class, the number of correct predictions divided by the number of samples from that class, are used. An ablation study was performed on descriptors to assess the contribution of the different data sources to the final performance. An \u201cimportant\u201d descriptor is having a strong influence on the increase in prediction errors in the case of random reallocation of the descriptor values in the training set. After the optimization, predictions for each DFT segments were computed using the best model according to the cFPR. The inferences were delivered as a thematic map with colors indicating the health state and hue indicating the fraction of decision trees in the RF having voted for the class (vote fraction). The purpose is to give a confidence information, with high vote fraction indicating robust predictions. Furthermore, the ground truth was evaluated for quantity and quality by two means: Removal of samples and its impact on the metric evaluation Splitting the training set into training subsets to evaluate on the original test set. Finally, after having developed the descriptors and the routine on high-quality data, we downgraded them to have resolutions similar to the ones of the swisstopo products (LiDAR: 20 pt/m 2 , orthoimage: 10 cm) and performed again the optimization and prediction steps. Indeed, the data acquisition was especially commissioned for this project and only covers the study area. If in the future the method should be extended, one would like to test if a lower resolution as the one of the standard national-wide product SWISSIMAGE could be sufficient.","title":"4.4 Random Forest"},{"location":"PROJ-HETRES/#5-results-and-discussion","text":"In this section, the results obtained during the processing of each data source into descriptors are presented and discussed, followed by a section on the random forest results.","title":"5 Results and discussion"},{"location":"PROJ-HETRES/#51-lidar-processing","text":"For the LiDAR data, the reader will first discover the aspect of beech trees in the LiDAR point cloud according to their health state as studied in the data exploration. Then, the segmentation results and the obtained LiDAR-based descriptors will be presented.","title":"5.1 LiDAR processing"},{"location":"PROJ-HETRES/#52-image-processing","text":"Boxplots and PCA are given to illustrate the results of the image processing exploration. As the masking of pixels below and above the affected height made no difference in the interpretation of the results, they are presented here with the height mask.","title":"5.2 Image processing"},{"location":"PROJ-HETRES/#53-vegetation-indices-from-satellite-imagery","text":"The t-test used to evaluate the ability of satellite indices to differentiate between health states are given in Appendices 6 and 7 . In the following two subsections, solely the significant tested groups are mentioned for understanding the RF performance.","title":"5.3 Vegetation indices from satellite imagery"},{"location":"PROJ-HETRES/#54-random-forest","text":"The results of the RF that are presented and discussed are: (1) the optimization and ablation study, (2) the ground truth analysis, (3) the predictions for the AOI and (4) the performance with downgraded data.","title":"5.4 Random Forest"},{"location":"PROJ-HETRES/#6-conclusion-and-outlook","text":"The study has demonstrated the ability of a random forest algorithm to learn from structural descriptors derived from LiDAR point clouds and from vegetation reflectance in airborne and satellite images to predict the health state of beech trees. Depending on the used datasets for training and test, the optimized full model including all descriptors reached an OA of 0.76 or of 0.79, with corresponding cFPR values of 0.13 and 0.14 respectively. These metrics are sufficient for the purpose of prioritizing beech tree felling. The produced map, with the predicted health state and the corresponding votes for the segments, delivers useful information for forest management. The cantonal foresters validated the outcomes of this proof-of-concept and explained how the location of affected beech trees as individuals or as groups are used to target high-priority areas. The full model highlighted the importance of the yearly variation of NDVI between a drought year (2018) and a normal year (2019). The airborne imagery showed good ability to predict dead trees, whereas confusion remained between healthy and unhealthy trees. The quality of the LiDAR point cloud segmentation may explain the limited performance of the LiDAR-based model. Finally, the model trained and tested on downgraded data gave an OA of 0.84 and a cFPR of 0.08. In this model, the airborne-based descriptors gained in importance. It was concluded that a 10 cm resolution may help the model by reducing the noise in the image. Outlooks for improving results include improving the ground truth representativeness of symptoms in the field and continuing research into descriptors for differentiating between healthy and unhealthy trees: For the image processing, suggestions are the integration of more statistics like the skewness and kurtosis of the reflectance as in Junttila et al. (2022) 15 . LiDAR-based descriptors had limited impact on the final results. To better valorize them for an application on beech trees, further research would be needed. Beside producing a cleaner segmentation and finding additional descriptors, it could consist in mixing the descriptors at the different resolutions and, with the help of the importance analysis, estimate at which resolution each descriptor brings the most information to the classification. The results showed the important contribution of vegetation indices derived from satellite imagery reflecting the drought year of 2018. If available, using historical image data of higher resolution to derive more descriptors could help improve individual tree health assessment. The possibility of further developments put aside, the challenge is now the extension of the methodology to a larger area. The simultaneity of the data is necessary to an accurate analysis. It has been shown that the representativeness of the ground truth has to be improved to obtain better and more stable results. Thus, for an extension to further areas, we recommend collecting additional ground truth measurements. The health state of the trees showed some autocorrelation that could have boosted our results and make them less representative of the whole forest. They should be more scattered in the forest. Furthermore, required data are a true orthophoto and a LiDAR point cloud for per-tree analysis. It should be possible to use an old LiDAR acquisition to produce a CHM and renounce to use LiDAR-based descriptors without degrading the performance of the model too much.","title":"6 Conclusion and outlook"},{"location":"PROJ-HETRES/#7-appendixes","text":"","title":"7 Appendixes"},{"location":"PROJ-HETRES/#71-simulation-plan-for-dft-parameter-tuning","text":"Table 8: parameter tuning for DFT. CHM cell size [m] Maxima smoothing Local maxima within search radius 0.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 2.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2","title":"7.1 Simulation plan for DFT parameter tuning"},{"location":"PROJ-HETRES/#72-t-tests","text":"t-test were computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes.","title":"7.2 t-tests"},{"location":"PROJ-HETRES/#8-sources-and-references","text":"Indications on software and hardware requirements, as well as the code used to perform the project, are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-hetres/tree/main. Other sources of information mentioned in this documentation are listed here: OFEV et al. (\u00e9d.). La canicule et la s\u00e9cheresse de l\u2019\u00e9t\u00e9 2018. Impacts sur l\u2019homme et l\u2019environnement. Technical Report 1909, Office f\u00e9d\u00e9ral de l\u2019environnement, Berne, 2019. \u21a9 \u21a9 Beno\u00eet Grandclement and Daniel Bachmann. 19h30 - En Suisse, la s\u00e9cheresse qui s\u00e9vit depuis plusieurs semaines frappe durement les arbres - Play RTS. February 2023. URL: https://www.rts.ch/play/tv/19h30/video/en-suisse-la-secheresse-qui-sevit-depuis-plusieurs-semaines-frappe-durement-les-arbres?urn=urn:rts:video:13829524 (visited on 2023-03-28). \u21a9 Xavier Gauquelin, editor. Guide de gestion des for\u00eats en crise sanitaire . Office National des For\u00eats, Institut pour le D\u00e9veloppement Forestier, Paris, 2010. ISBN 978-2-84207-344-2. \u21a9 \u21a9 Philipp Brun, Achilleas Psomas, Christian Ginzler, Wilfried Thuiller, Massimiliano Zappa, and Niklaus E. Zimmermann. Large-scale early-wilting response of Central European forests to the 2018 extreme drought. Global Change Biology , 26(12):7021\u20137035, 2020. _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/gcb.15360. URL: https://onlinelibrary.wiley.com/doi/abs/10.1111/gcb.15360 (visited on 2022-10-13), doi:10.1111/gcb.15360 . \u21a9 Run Yu, Youqing Luo, Quan Zhou, Xudong Zhang, Dewei Wu, and Lili Ren. A machine learning algorithm to detect pine wilt disease using UAV-based hyperspectral imagery and LiDAR data at the tree level. International Journal of Applied Earth Observation and Geoinformation , 101:102363, September 2021. URL: https://www.sciencedirect.com/science/article/pii/S0303243421000702 (visited on 2022-10-13), doi:10.1016/j.jag.2021.102363 . \u21a9 \u21a9 \u21a9 Pengyu Meng, Hong Wang, Shuhong Qin, Xiuneng Li, Zhenglin Song, Yicong Wang, Yi Yang, and Jay Gao. Health assessment of plantations based on LiDAR canopy spatial structure parameters. International Journal of Digital Earth , 15(1):712\u2013729, December 2022. URL: https://www.tandfonline.com/doi/full/10.1080/17538947.2022.2059114 (visited on 2022-12-07), doi:10.1080/17538947.2022.2059114 . \u21a9 \u21a9 \u21a9 Patrice Eschmann, Pascal Kohler, Vincent Brahier, and Jo\u00ebl Theubet. La for\u00eat jurassienne en chiffres, R\u00e9sultats et interpr\u00e9tation de l'inventaire forestier cantonal 2003 - 2005. Technical Report, R\u00e9publique et Canton du Jura, St-Ursanne, 2006. URL: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjHuZyfhoSBAxU3hP0HHeBtC4sQFnoECDcQAQ&url=https%3A%2F%2Fwww.jura.ch%2FHtdocs%2FFiles%2FDepartements%2FDEE%2FENV%2FFOR%2FDocuments%2Fpdf%2Frapportinventfor0305.pdf%3Fdownload%3D1&usg=AOvVaw0yr9WOtxMyY-87avVMS9YM&opi=89978449However . \u21a9 \u21a9 Agnieska Ptak. (5) Amplitude vs Reflectance \\textbar LinkedIn. June 2020. URL: https://www.linkedin.com/pulse/amplitude-vs-reflectance-agnieszka-ptak/ (visited on 2023-08-11). \u21a9 BFH-HAFL and BAFU. Waldmonitoring.ch : wcs_ndvi_diff_2016_2015, wcs_ndvi_diff_2017_2016, wcs_ndvi_diff_2018_2017, wcs_ndvi_diff_2019_2018, wcs_ndvi_diff_2020_2019, wcs_ndvi_diff_2021_2020, wcs_ndvi_diff_2022_2021. URL: https://geoserver.karten-werk.ch/wfs?request=GetCapabilities . \u21a9 Reik Leiterer, Gillian Milani, Jan Dirk Wegner, and Christian Ginzler. ExoSilva - ein Multi\u00ad-Sensor\u00ad-Ansatz f\u00fcr ein r\u00e4umlich und zeitlich hochaufgel\u00f6stes Monitoring des Waldzustandes. In Neue Fernerkundungs\u00adtechnologien f\u00fcr die Umweltforschung und Praxis , 17\u201322. Swiss Federal Institute for Forest, Snow and Landscape Research, WSL, April 2023. URL: https://www.dora.lib4ri.ch/wsl/islandora/object/wsl%3A33057 (visited on 2023-11-13), doi:10.55419/wsl:33057 . \u21a9 Matthew Parkan. Mparkan/Digital-Forestry-Toolbox: Initial release. April 2018. URL: https://zenodo.org/record/1213013 (visited on 2023-08-11), doi:10.5281/ZENODO.1213013 . \u21a9 R Core Team. R: A Language and Environment for Statistical Computing. 2023. URL: https://www.R-project.org/ . \u21a9 \u21a9 Olga Brovkina, Emil Cienciala, Peter Surov\u00fd, and P\u0159emysl Janata. Unmanned aerial vehicles (UAV) for assessment of qualitative classification of Norway spruce in temperate forest stands. Geo-spatial Information Science , 21(1):12\u201320, January 2018. URL: https://www.tandfonline.com/doi/full/10.1080/10095020.2017.1416994 (visited on 2022-07-15), doi:10.1080/10095020.2017.1416994 . \u21a9 N.K. Gogoi, Bipul Deka, and L.C. Bora. Remote sensing and its use in detection and monitoring plant diseases: A review. Agricultural Reviews , December 2018. doi:10.18805/ag.R-1835 . \u21a9 Samuli Junttila, Roope N\u00e4si, Niko Koivum\u00e4ki, Mohammad Imangholiloo, Ninni Saarinen, Juha Raisio, Markus Holopainen, Hannu Hyypp\u00e4, Juha Hyypp\u00e4, P\u00e4ivi Lyytik\u00e4inen-Saarenmaa, Mikko Vastaranta, and Eija Honkavaara. Multispectral Imagery Provides Benefits for Mapping Spruce Tree Decline Due to Bark Beetle Infestation When Acquired Late in the Season. Remote Sensing , 14(4):909, February 2022. URL: https://www.mdpi.com/2072-4292/14/4/909 (visited on 2023-10-27), doi:10.3390/rs14040909 . \u21a9","title":"8 Sources and references"},{"location":"PROJ-LANDSTATS/","text":"Using spatio-temporal neighbor data information to detect changes in land use and land cover \u00b6 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS September 2022 to March 2023 - Published on April 2023 All scripts are available on GitHub . Abstract : From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used. It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. 1. Introduction \u00b6 The introduction presents the background and the objectives of the projects, but also introduces the input data and its specific features. 1.1 Background \u00b6 Since 1979, the Swiss Federal Statistical Office (FSO) provides detailed and accurate information on the state and evolution of the land use and the land cover in Switzerland. It is a crucial tool for long-term spatial observation. With these statistics, it is possible to determine whether and to what extent changes in land cover and land use are consistent with the goals of Swiss spatial development policies ( FSO ). Figure 1: Visualization of the land cover and land use classification. Every few years, the FSO carries out a survey on aerial or satellite images all over Switzerland. A grid with sample points spaced 100 meters apart overlays the images, providing 4.1 million sample points on which the statistics are based. The classification of the hectare tile is assigned on the center dot, as shown in Figure 1. Currently, a time series of four surveys is accessible, based on aerial images captured in the following years: 1979\u20131985 (1st survey, 1985) 1992\u20131997 (2nd survey, 1997) 2004\u20132009 (3rd survey, 2009) 2013\u20132018 (4th survey, 2018) The first two surveys of the land statistics in 1979 and 1992 were made by visual interpretation of aerial analogue photos using stereoscopes. Since the 2004 survey, the methodology was deeply renewed, in particular through the use of digital aerial photographs, which are observed stereoscopically on workstations using specific photogrammetry software . A new nomenclature (2004 NOAS04) has also been introduced in 2004 which systematically distinguishes 46 land use categories and 27 land cover categories. A numerical label from this catalogue is assigned to each point by a team of trained interpreters. The 1979 and 1992 surveys have been revised according to the nomenclature NOAS04, so that all readings (1979, 1992, 2004, 2013) are comparable. On this page you will find the geodata of the Land Use Statistics at the hectare level since 1979, as well as documentation on the data and the methodology used to produce these data. Detailed information on basic categories and principal domains can be found in Appendix 1 . 1.2 Objectives \u00b6 It is known that manual interpretation work is time-consuming and expensive. However, in a feasibility study , the machine learning technique showed great potential capacity to help speed up the interpretation, especially with deep learning algorithms. According to the study, 50% of the estimated interpretation workload could be saved. Therefore, FSO is currently carrying out a project to assess the relevance of learning and mastering the use of artificial intelligence (AI) technologies to automate (even partially) the interpretation of aerial images for change detection and classification. The project is called Area Statistics Deep Learning (ADELE). FSO had already developed tools for change detection and multi-class classification using the image data. However, the current workflow does not exploit the spatial and temporal dependencies between different points in the surveys. The aim of this project is therefore to evaluate the potential of spatial-temporal neighbors in predicting whether or not points in the land statistics will change class. The methodolgy will be focused on change detection, by finding as many unchanged tiles as possible (automatized capacity) and miss as few changed tiles as possible. The detailed objectives of this project are to: explore the internal transformation patterns of tile classification from a data analytics perspective build a prototype that performs change detection for tiles in the next survey help the domain experts to integrate the prototype within the OFS workflow 1.3 Input data \u00b6 The raw data delivered by the domain experts is a table with 4'163'496 records containing the interpretation results of both land cover and land use from survey 1 to survey 4. An example record is shown in Table 1 and gives following information: RELI: 8-digit number composed by the EAST hectare number concatenated with the NORTH hectare number EAST: EAST coordinates (EPSG:2056) NORTH: NORTH coordinates (EPSG:2056) LUJ: Land Use label for survey J LCJ: Land Cover label for survey J training: value 0 or 1. A value of 1 means that the point can be included in the training or validation set Table 1: Example record of raw data delivered by the domain experts. RELI EAST NORTH LU4* LC4 LU3 LC3 LU2 LC2 LU1 LC1 training 74222228 2742200 1222800 242 21 242 21 242 21 242 21 0 75392541 2753900 1254100 301 41 301 41 301 41 301 41 0 73712628 2737100 1262800 223 46 223 46 223 46 223 46 0 * The shortened LC1/LU1 to LC4/LU4 will be used to simplify the notation of Land Cover/Use of survey 1 to survey 4 in the following documentation. For machine learning, training data quality has strong influence on model performance. With the training label, domain experts from FSO selected data points that are more reliable and representative. These 348'474 tiles and their neighbors composed the training and testing dataset for machine learning methodology. 2. Exploratory data analysis \u00b6 As suggested by domain experts, exploratory data analysis (EDA) is of significance to understand the data statistics and find the potential internal patterns of class transformation. The EDA is implemented from three different perspectives: distribution, quantity and probability. With the combination of the three, we can find that there do exist certain trends in the transformation of both land cover and land use classes. For the land cover, main findings are: distribution: most surface of Switzerland is covered by vegetation or forest, bare land and water areas take up a considerable portion as well, artificial areas take up a small portion of the land cover probability: transformation between some classes had never happened during the past four decades, all classes of land cover are most likely to keep their status rather than to change quantity: there are some clear patterns in quantitative changes Open Forest goes to Closed Forest Brush Meadows go to Shrubs Garden Plants go to Grass and Herb Vegetation Shrubs go to Closed Forest Cluster of Tree goes to Grass and Herb Vegetation For the land use, main findings are: distribution: agricultural and forest areas are the main land uses, unused area also stands out from others classes. probability: transformation between some classes had never happened during the past four decades; on the contrary, construction site, non-exploited urban areas and forest areas tend to change to other classes rather than keep unchanged quantity: the most transformations happened inside the superclasses of Arable and Grassland and of Forest not Agricultural . Readers particularly interested by the change detection methods can directly go to Section 3 ; otherwise, readers are welcomed to read the illustrated and detailed EDA given hereafter. 2.1 Distribution statistics \u00b6 Figure 2: Land cover distribution plot. Figure 3: Land use distribution plot. First, a glance at the overall distribution of land cover and land use is shown in Figure 2 and 3. The X-axis is the label of each class while the Y-axis is the number of tiles in the Log scale. The records of the four surveys are plotted in different colors chronologically. By observation, some trends can be found across the four surveys. Artificial areas only take up a small portion of the land cover (labels between 10 to 20), while most surface of Switzerland is covered by vegetation or forest (20 - 50). Bare land (50 - 60) and water areas (60 - 70) take up a considerable portion as well. For land use, it is obvious that the agricultural (200 - 250) and forest (300 - 310) areas are the main components while the unused area (421) also stands out from others. Most classes kept the same tendency during the past 40 years. There are 11 out of 27 land cover classes and 32 out of 46 land use classes which are continuously increasing or decreasing all the time. Especially for land use, compared with 10 classes rising with time, 22 classes dropping, which indicates that there is some transformation patterns that caused the leakage from some classes to those 10 classes. We will dive into these patterns in the following sections. 2.2 Quantity statistics \u00b6 The data are explored in a quantitative way by three means: visualization of transformations between 2 surveys visualization of sequential transformation over time identifying patterns and most occured transformations in different periods. 2.2.1 Transformation visualization \u00b6 Figure 4: Land cover transformation from 1985 to 2018. The analysis of the transformation patterns in quantitative perspective has been implemented in the interactive visualization in Figure 4. The nodes of the same color belong to a common superclass (principle domain). The size of the node represents the number of tiles for the class and the width of the link reflects the number of transformations in log scale. When hanging over your mouse on these elements, detailed information such as the class label code and the number of transformations will be shown. Clicking the legend will enable you to select the superclasses in which the transformation should be analyzed. Pre-processing had been done for the transformation data. To simplify the graph and stand out the major transformations, links with the number of transformations less than 0.1% of the total were removed from the graph. The filter avoids too many trivial links (580) connecting nearly all the nodes, leaving significant links (112) only. The process filtered 6.5% of the transformations in land cover and 11.5% in land use, which is acceptable considering it is a quantitative analysis focusing on the major transformation. 2.2.2 Sequential transformation visualization \u00b6 Figure 5: Land cover sequential transformation. In addition to the transformation between the 2 surveys, the sequential transformation over time had also been visualized. Here, a similar filter is implemented as well to simplify the result and only tiles that had changed during the 4 surveys are visualized. In Figure 5, the box of a class in column 1985 (survey 1) is composed of different colors while the box of a class in column 2018 (survey 4) only has one color. This is caused by the color of the link showing a kind of sequential transformation. The different colors of a class in the first column show the end status (classification) of the tiles in survey 4. There are some clear patterns we can find in the graph. For example, the red lines point out four diamond patterns in the graph. The diamond pattern with the edges in the same color illustrates the continuous trend that one class of tiles is transferred to the other class. In this figure, it is obvious that the Tree Clusters are degraded to the Grass and Herb , while Grass and Herb are transferred to the Consolidated Surfaces , showing the expansion of urban areas and the destruction to the natural environment. 2.2.3 Quantity statistics analysis \u00b6 Comparing the visualization of different periods, a constant pattern has been spotted in both land cover and land use. For example in land cover, the most transformation happened between the superclass of Tree Vegetation and Brush Vegetation . Also, a visible bi-direction transformation between Grass and Herb Vegetation and Clusters of Trees is witnessed. Greenhouses, wetlands and reedy marshes hardly have edges linked to them all over time, which illustrates that either they have a limited area or they hardly change. A similar property can also be captured in land use classes. The most transformation happened inside the superclass of Arable and Grassland and Forest not Agricultural . Also, a visible transformation from Unused to Forest is highlighted by others. Combining the findings above, it is clear that the transformation related to the Forest and Vegetation is the main part of the story. The forest shrinks or expands over time, changing to shrubs and getting back later. The Arable and Grassland keeps changing based on the need for agriculture or animal husbandry during the survey year. Different kinds of forests interconvert with each other which is a rational natural phenomenon. 2.3 Probability matrix \u00b6 The above analysis demonstrates the occurrence of transformation with quantitative statistics. However, the number of tiles for different classes is not a uniform distribution as shown in the distribution analysis. The largest class is thousands of times more than the smallest one. Sometimes, the quantity of a transformation is trivial compared with the majority, but it is caused by the small amount of tiles for the class. Even if the negligible class would not have a significant impact on the performance of change detection, it is of great importance to reveal the internal transformation pattern of the land statistics and support the multi-class classification task. Therefore, the probability analysis is designed as below: The probability analysis for land cover/use contains 3 parts: The probability matrix presents the probability of transformation from the source class (Y-axis) to the destination class (X-axis). The value of the probability is illustrated by the depth of the color in the log scale. The distribution of the probability that a class does not change, which is a more detailed visualization of the diagonal value of the probability matrix. The distribution of the maximum probability that a class changes to another certain class. This is a deeper inspection to look for a fixed transformation pattern that exists between two classes. The probability is calculated by the status change between the beginning survey and the end survey stated in the figure title. For example Figure 6 is calculated by the transformation between survey 1 and survey 4, without taking into account possible intermediate changes in survey 2 and 3. 2.3.1 Land cover analysis \u00b6 Figure 6: Land cover probability matrix from LC1 to LC4. The first information that the matrix provides is the blank blocks with zero probability of conversion. This discloses that transformation between some classes had never happened during the past four decades. Besides, all the diagonal blocks are with distinct color depth, illustrating that all classes of land cover are most likely to keep their status rather than to change. Another evident features of this matrix are the columns with destination classes Grass and Herb Vegetation (21) and Closed Forest (41) . There are a few classes such as Shrubs (31) , Fruit Tree (33) , Garden Plants (35) and Open Forest (44) which have a noticeable trend to convert to these two classes, which is partially consistent with the quantity analysis while revealing some new findings. Figure 7: Land cover transformation probability without change. When it comes to the refined visualization of the diagonal blocks, it is clear that half of the classes have more than an 80% probability of not transforming, while the minimum one only has about 35%. This is caused by the accumulation of the 4 surveys together which lasts 40 years. For a single decade, as the first 3 sub-graphs of Figure 23 in the Appendix A2.1 , the majority are over 90% probability and the minimum rises to 55%. Figure 8: Maximum transformation probability to a certain class when land cover changes. For those transformed tiles, the maximum probability of converting into another class is shown in Figure 8. This graph together with the matrix in Figure 6 can point out the internal transformation pattern. The top 5 possible transformations between the first survey and the forth survey are: 1. 38% Open Forest (44) --> Closed Forest (41) 2. 36% Brush Meadows (32) --> Shrubs (31) 3. 34% Garden Plants (35) --> Grass and Herb Vegetation (21) 4. 29% Shrubs (31) --> Closed Forest (41) 5. 26% Cluster of Tree (47) --> Grass and Herb Vegetation (21) In this case, the accumulation takes effect as well. For a single decade, the maximum probability decreases to 25%, but the general distribution of the probability is consistent between the four surveys according to Figure 24 in the Appendix A2.1 . 2.3.2 Land use analysis \u00b6 Figure 9: Land use probability matrix from LU1 to LU4. The land use probability matrix has different features compared with the land cover probability matrix. Although most diagonal blocks are with the deepest color depth, there are two areas highlighted by the red line presenting different statistics. The upper area is related to Construction sites (146) and Unexploited Urban areas (147) . These two classes tend to change to other classes rather than keep unchanged, which is reasonable since the construction time of buildings or infrastructures hardly exceeds 10 years. This is confirmed by the left side of the red-edged rectangular block, which has a deeper color depth. This illustrates that construction and unexploited areas ended in the Settlement and Urban Areas (superclass of 100 - 170). The lower red area account for the pattern concerning the Forest Areas (301 -304) . The Afforestation (302) , Lumbering areas (303) and Damaged Forest (304) would thrive and recover between the surveys, and finally become Forest (301) again. Figure 10: Land use transformation probability without change. Figure 10 further validates the assumptions. With most classes with a high probability of not changing, there are two deep valleys for classes 144 to 147 and 302 to 304, which are exactly the results of the stories mentioned above. Figure 11: Maximum transformation probability to a certain class when land use changes. Figure 11 tells the difference in the diversity of transformation destination. The construction and unexploited areas would turn into all kinds of urban areas, with more than 95% changed and the maximum probability to a fixed class is less than 35%. While the Afforestation , Lumbering areas and Damaged Forest returned to Forest with a probability of more than 90%, the transformation pattern within these four classes is fairly fixed. The distribution statistics, the quantity statistics and the probability matrices have shown to validate and complement each other during the exploratory analysis of the data. 3. Methods \u00b6 The developed method should be integrated in the OFS framework for change detection and classification of land use and land cover illustrated in Figure 12. The interesting parts for this project are highlighted in orange and will be presented in the following. Figure 12: Planned structure in FSO framework for final prediction. Figure 12 shows on the left the input data type in the OFS framework. The current project work on the LC/LU neighbors introduced in Section 1.3 . The main objective of the project - to detect change by means of these neighbors - is the temporal-spatial module in Figure 12. As proposed by the feasibility study, FSO had implement studies on change detection and multi-class classification on swisstopo aerial images time series to accelerate the efficiency of the interpretation work. The predicted LC and LU probabilities and information obtained by deep learning are defined as the image-level module. In a second stage of the project, the best model for combining the temporal-spatial and the image-level module outputs is explored to evaluate the gain in performance after integration of the spatial-temporal module in the OFS framework. This is the so-called integration module. The rest of the input data will not be part of the performance evaluation. 3.1 Temporal-spatial module \u00b6 Figure 13: Time and space structure of a tile and its neighbors. The input data to the temporal-spatial module will be the historical interpretation results of the tile to predict and its 8 neighbors. The first three surveys are used as inputs to train the models while the forth survey serves as the ground truth of the prediction. This utilizes both the time and space information in the dataset like depicted in Figure 13. During the preprocessing, the tiles with missing neighbors were discarded from the dataset to keep the data format consistent, which is insignificant (about 400 out of 348'868). The determination of change is influenced by both land cover and land use. When there is a disparity between the classifications in the fourth survey and the third one for a specific tile, it is identified as altered (positive) in change detection. The joint prediction of land cover and land use is based on the assumption that a correlation may exist between them. If the land cover of a tile undergoes a change, it is probable that its land use will also change. Moreover, the tile is assigned numerical labels. Nevertheless, the model does not desire a numerical association between classes, even when they belong to the same superclass and are closely related. To address this, we employ one-hot encoding, which transforms a single land cover column into 26 columns, with all values set to '0' except for one column marked as '1' to indicate the class. Despite increasing the model's complexity with almost two thousand input columns, this is a necessary trade-off to eliminate the risk of numerical misinterpretation. 3.2 Change detection \u00b6 Usually, spatial change detection is a remote sensing application performed on aerial or satellite images for multiclass change detection. However, in this project, a table of point records is used for binary classification into changed and not changed classes. Different traditional and new deep learning approach have been explored to perform this task. The motivations to use them are given hereinafter. An extended version of this section with detailed introduction to the machine learning models is available in Appendix A3 . Three traditional classification models, logistic regression (LR) , XGBoost and random forest (RF) , are tested. The three models represent the most popular approaches in the field - the linear, boosting, and bagging models. In this project, logistic regression is well adapted because it can explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. Concerning XGBoost, it has the advantage that weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling, while misclassified observations would receive extra weight during training. Finally, in random forest, higher accuracy may be obtained and overfitting still avoided through the larger number of trees and the sampling process. Beyond these traditional popular approaches, another two deep learning algorithms are explored as well: fully connected network and convolutional recurrent neural network . Different from the traditional machine learning algorithms, deep learning does not require manual feature extraction or engineering. Deep neural networks capture the desired feature with back-propagation optimization process. Besides, these deep neural networks have some special design for temporal or spatial inputs, because it is assumed that the internal pattern of the dataset would match with the network structure and the model will have better performance. 3.2.1 Focal loss \u00b6 Deep neural networks need differentiable loss function for optimization training. For this project with imbalanced classification task, the local loss was chosen rather than the traditional (binary) cross entropy loss . \\[\\begin{align} \\\\ FL(p_t) = -{\\alpha}(1-p_t)^{\\gamma} \\ log(p_t) \\\\ \\end{align}\\] where \\(p_t\\) is the probability of predicting the correct class, \\(\\alpha\\) is a balance factor between positive and negative classes, and \\(\\gamma\\) is a modulation factor that controls how much weight is given to examples hard to classify. Focal loss is a type of loss function that aims to solve the problem of class imbalance in tasks like classification. Focal loss modifies the cross entropy loss by adding a factor that reduces the loss for easy examples and increases the loss for examples hard to classify. This way, focal loss focuses more on learning from misclassified examples. Compared with other loss functions such as cross entropy, binary cross entropy and dice loss, some advantages of focal loss are: it can reduce the dominance of well-classified examples and prevent them from overwhelming the gradient it can adaptively adjust the weight of each example based on its difficulty level it can improve the accuracy and recall of rare classes by adjusting \\(\\alpha\\) to give more weight to them \\(\\alpha\\) should be chosen based on the class frequency. A common choice is to set \\(\\alpha_t\\) is 1 minus the frequency of class t. This way, rare classes get more weight than frequent classes. \\(\\gamma\\) should be chosen based on how much you want to focus on hard samples. A larger gamma means more focus on hard samples, while a smaller gamma means less focus. The original paper suggested that a gamma equal to 2 is an effective value for most cases. 3.2.2 Fully connected network (FCN) \u00b6 Fully connected network (FCN) in deep learning is a type of neural network that consists of a series of fully connected layers. The major advantage of fully connected networks for this project is that they are structure agnostic. That is, no special assumptions need to be made about the input (for example, that the input consists of images or videos). A disadvantage of FCN is that it can be very computationally expensive and prone to overfitting due to the large number of parameters involved. Another disadvantage is that it does not exploit any spatial or temporal structure in the input data, which can lead to poor performance for some tasks. For implementation, the FCN employ 4 hidden layers (2048, 2048, 1024, 512 neurons respectively) besides the input and output layer. Relu activation function are chosen before the output layer while sigmoid function is applied at the end to scale the result to probability representation. 3.2.3 Convolutional recurrent neural network (ConvRNN) \u00b6 Convolutional recurrent neural network (ConvRNN) is a type of neural network that combines convolutional neural networks (CNNs) and recurrent neural networks (RNNs). CNNs are good at extracting spatial features from images, while RNNs are good at capturing temporal features from sequences. ConvRNNs can be used for tasks that require both spatial and temporal features as it is meant to be achieved in this project. Furthermore, the historical data of the land cover and land use can be translated to some synthetic images. The synthetic images use channels to represent sequence of surveys and the pixel value represents ground truth label. Thus, the spatial relationship of the neighbour tiles could be extracted from the data structure with the CNN. Figure 14: Convolutional Recurrent Neural Network Pipeline. In this project, we explored ConvRNN with structure shown in Figure 14. The sequence of surveys are treated as sequence of input \\(x^t\\) . With the recurrent structure and hidden states \\(h^t\\) to transmit information, the temporal information could be extracted. Different from the traditional RNN, the function \\(f\\) in hidden layers of the recurrent structure use convolutional operation instead of matrix computation and an additional CNN module is applied to the sequence output to detect the spatial information. 3.3 Performance metric \u00b6 Once the different machine learning models are trained for the respective module, comparison has to be made on the test set to evaluate their performance. This will be performed with the help of metrics. 3.3.1 Traditional metrics \u00b6 As discovered in the distribution analysis , the dataset is strongly unbalanced. Some class is thousands of others. This is of importance to change detection. Moreover, among 348'474 tiles in the dataset, only 58'737 (16.86%) tiles have changed. If the overall accuracy is chosen as the performance metric, the biased distribution would make the model tend to predict everything unchanged. In that case, the accuracy of the model can achieve 83.1%, which is a quite high value achieved without any effort. Therefore, avoiding the problem during the model training and selecting the suitable metric that can represent the desired performance are the initial steps. The constant model is defined as a model which predicts the third survey interpretation values as the prediction of the forth survey. In simple words, the constant model predicts that everything does not change. By this definition, we can calculate all kinds of metrics for other change detection models and compare them to the constant model metrics to indentify models with better performance. For change detection with the constant model, the performance is as below: Figure 15: Confusion matrix of constant distribution as prediction: TP=True Positive, TN=True Negative, FP=False Positive, FN=False Negative. Table 2: Metrics evaluation for constant model. Models Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Constant 0.831 0.500 Positive Negative 0.000 0.831 0.000 1.000 0.000 0.907 Definition of abbreviations: For positive case: Precision = TP / (TP + FP) Recall = TP / (TP + FN) (Positive predictive value, PPV) (True positive rate, TPR) For negative case: Precision = TN / (TN + FN) Recall = TN / (TN + FP) (Negative predictive value, NPV) (True negative rate, TNR) Detailed metrics definition can be found here The aim of the change detection is to predict the tiles of high confidence that do not change, so that the interpretation from the last survey can be used directly. However, the negative-case-related metrics above and the accuracy are not suitable for the present task because of the imbalance nature of the problem. Indeed, they indicate a high performance for the constant model, which we know is not depicting the reality, because of the large amount of unchanged tiles. After the test, the balanced accuracy which is the mean of the true positive rate and the true negative rate is considered a suitable metric for change detection. 3.3.2 Specific weighted metric for change detection \u00b6 In theory, true negative rate is equivalent to 1 minus false positive rate. Optimizing balanced accuracy typically results in minimizing the false positive rate. However, our primary objective is to reduce false negative instances (i.e., changed cases labeled as unchanged), while maximizing the true positive rate and true negative rate. False positives are of lesser concern, as they will be manually identified in subsequent steps. Consequently, balanced accuracy does not adequately reflect the project's primary objective. With the help of FSO interpretation team, an additionnal, specific metric targeting on the objective has been designed to measure the model performance. Reminding the Exploratory Data Analysis , some transformation patterns have been found and applied in this metric as well. Figure 16: Workflow with multiple input to define a weighted metric. As depicted in Figure 16, the FSO interpretation team designed two filters to derive a custom metric. The first filter combines inputs from all the possible modules (in this case, the image-level and temporal-spatial modules). The input modules give the probability of change detection or multi-class classification prediction with confidence. As prediction from modules might be different, the first filter will set the final prediction of a tile as positive if any input module gives a positive prediction. Here the threshold to define positive is a significant hyperparameter to finetune. The Weights Matrix defined by the human experts is the core of the entire metric. Based on professional experience and observation of EDA, the experts assigned different weights to all possible transformations. These weights demonstrate the importance of the transformation to the overall statistics. Besides, part of the labels is defined as Small Classes , which means that these classes are negligible or we do not consider them in this study. The second filter removes all the transformations related to the small classes and apply the weights matrix to all the remained tiles. Finally, the weighted metric is calculated as below: \\[\\begin{align} Automatized \\ Tiles &= {\\#Predicted \\ Negatives} \\\\ \\\\ Automatized \\ Capacity &= {{\\#Automatized \\ Tiles} \\over {\\#Negatives \\ (ground \\ truth)}} \\\\ \\\\ Missed \\ Weighted \\ Changed \\ Ratio &= {{\\sum \\{Missed \\ Change \\times Weight\\}} \\over {\\sum \\{All \\ Change \\times Weight\\}}} \\\\ \\\\ Weighted \\ Metric &= Automatized \\ Capacity \\times (0.1 - Missed \\ Weighted \\ Changed \\ Ratio) \\ / \\ 0.1 \\end{align}\\] From now on, we will still calculate metrics like balanced accuracy and recall for reference and analysis; however, the Weighted Metric is the decisive metric for model selection. 3.4 Training and testing plan \u00b6 Introduced in Section 1.3 , the 348'474 tiles with temporal-spatial information are selected for training. The 80%-20% split is applied to the selected tiles to create the train set and the test set respectively. Adam optimizer and multi-step learning rate scheduler are deployed for better convergence. For the temporal-spatial module, metrics for ablation study on the descriptors and descriptor importance are first computed. The descriptor importance is taken from XGBoost simulations. The ablation study is performed with the logistic regression and consists of training the model with: 8 neighbors and time activated, \"baseline\" 4 neighbors (northern, western, southern, eastern neighbors) no spatial-neighbors, \"space deactivate\" no temporal-neighbors, \"time deactivate\" Then, the baseline configuration is used to trained the traditional algorithms and the deep learning ones. Metrics are compared and the best performing models are kept for the integration module. Finally, the performance of several configurations are compared for the integration module. direct outputs of the image-level module direct outputs of the best performing temporal-spatial module outputs of the best performing temporal-spatial module, followed by RF training for the integration module. outputs of the best performing temporal-spatial module, followed by FCN training for the integration module. The extra information gain from the temporal-spatial module will be studied by comparison with image-level performance only. The image-level data contain multi-class classification prediction and its confidence. We can calculate the change probability according to the probability of each class. Therefore, the weighted metric can also be applied at the image-level only. Then, the RF and FCN are tested for the integration module which combines various types of information sources. 4. Experiments \u00b6 The Experiments section covers the results obtained when performing the planned simulations for the temporal-spatial module and the integration module. 4.1 Temporal-spatial module \u00b6 4.1.1 Feature engineering (time and space deactivation) \u00b6 In the temporal-spatial module, the studied models take advantages of both the space (the neighbors) and the time (different surveys) information as introduced in Section 3.1 . Ablation study is performed here to acknowledge the feature importance and which information really matters in the model. Table 3: Model metrics for ablation plan. Logistic Regression Best threshold Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Time deactivate 0.515 0.704 0.718 Positive Negative 0.330 0.930 0.740 0.696 0.457 0.796 Space deactivate 0.505 0.684 0.711 Positive Negative 0.316 0.930 0.752 0.670 0.445 0.779 4 neighbors 0.525 0.707 0.718 Positive Negative 0.332 0.929 0.734 0.701 0.458 0.799 Baseline* 0.525 0.711 0.720 Positive Negative 0.337 0.928 0.734 0.706 0.462 0.802 *Baseline: 8 neighbors with time and space activated Table 3 reveals the performance change when time or space information is totally or partially (4-neighbors instead of 8-neighbors) deactivated. While time deactivation and less-neighbors hardly have an influence on the balanced accuracy (only 0.2% decrease), the one for space deactivation decreased by about 1%. The result demonstrates that space information is more vital to the algorithm than time information, even though both have a minor impact. Figure 17: Feature importance analysis comparasion of 4 (left) and 8 (right) neighbors. Figure 18: Feature importance analysis comparasion of time (left) and space (right) deactivation. Figure 17 and 18 give the feature importance analysis from the XGBoost model. The sum of feature importance from variables all related to the tile itself and its neighbors are plotted in the charts. The 4-neighbor and 8-neighbor have similar capacities but the importance of neighbors for the latter is much more than for the former. This is caused by the number of variables. With more neighbors, the number of variables related to the neighbor increases and the sum of the feature importance grows as well. The feature importance illustrates the weight assigned to the input variables. From Figure 17, it is obvious that the variable related to the tile itself from past surveys is the most critical. Furthermore, the more recent, the more important. The neighbor on the east and west (neighbors 3 and 4) are more significant than others and even more than the land use of the tile in the first survey. In conclusion, the feature importance is not evenly distributed. However, the ablation study shows that the model with all the features as input achieved the best performance. 4.1.2 Baseline models with probability or tree models \u00b6 Utilizing the time and space information from the neighbors, three baseline methods with probability or tree model are fine-tuned. The logistic regression outperforms the other two, achieving 72.0% balanced accuracy. As result, more than 41'000 tiles are correctly predicted as unchanged while only about 3'000 changed tiles are missed as they are the false negatives. Detailed metrics of each method are listed in Table 4. Table 4: Performance metrics for traditional machine learning simulation of spatial-temporal model. Models Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Logistic Regression 0.711 0.720 Positive Negative 0.337 0.928 0.734 0.706 0.462 0.802 Random Forest 0.847 0.715 Positive Negative 0.775 0.849 0.134 0.992 0.229 0.915 XGBoost 0.837 0.715 Positive Negative 0.533 0.869 0.297 0.947 0.381 0.906 Constant 0.830 0.500 Positive Negative 0.000 0.830 0.000 1.000 0.000 0.907 21: Metric changes with different threshold for logistic regression. Besides the optimal performance with balanced accuracy, logistic regression can manually adjust its ability by changing the decision threshold as its output is the probability to change instead of prediction only. For example, we can trade off between the true positive rate and the negative predictive value. As shown in Figure 19, if we decrease the threshold probability, the precision of the negative case (NPV) will increase while the true negative rate goes down. This means more tiles need manual checks; however, fewer changed tiles are missed. Considering both the performance and the characteristics, Logistic Regression is selected as the baseline model. 4.1.3 Neural networks: FCN and ConvRNN \u00b6 FCN and ConvRNN work differently: FCN does not have special structure designed for temporal-spatial data while ConvRNN has specific designation for time and space information respectively. To study these two extreme situations, we explored their performance and compared with the logistic regression which is the best of the baseline models. Table 5: Performance metrics for deep machine learning simulation of spatial-temporal model Models Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity LR (Macro)* 0.237 0.197 0.655 0.954 349 0.046 18995 0.035 14516 0.364 LR (BA)* 0.249 0.207 0.656 0.957 326 0.043 17028 0.031 14478 0.363 FCN 0.259 0.21 0.656 0.958 322 0.042 15563 0.029 14490 0.363 ConvRNN 0.176 0.133 0.606 0.949 388 0.051 19026 0.035 10838 0.272 Constant -10.717 -10.72 0.500 0.000 7607 1.000 542455 1.00 47491 1.191 *Macro: the model is trained with Macro F1-score ; BA: the model is trained with Balanced Accuracy. As a result of its implementation (see Section 3.2.2 ), FCN outperforms all the models with a value of 0.259 for the weighted metric, slightly above the logistic regression with 0.249. ConvRNN does not perform well even if we have increased the size of hidden states to 1024. Following deliberation, we posit that the absence of one-hot encoding during the generation of synthetic images may be the cause, given that an increased number of channels could substantially explodes computational expenses. Since the ground truth label is directly applied to pixel values, the model may attempt to discern numerical relationships among distinct pixel values that, in reality, do not exist. This warrants further investigation in subsequent phases of our research. 4.2 Integration module \u00b6 Table 5 compares the performance of FCN or image-level only to several configurations for the integration module. Table 5: Performance metrics for the integration model in combination with a spatial-temporal model. Model Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity FCN 0.259 0.210 0.656 0.958 322 0.042 15563 0.029 14490 0.363 image-level 0.374 0.305 0.737 0.958 323 0.042 15735 0.029 20895 0.524 LR + RF 0.434 0.372 0.752 0.969 241 0.031 10810 0.020 21567 0.541 FCN + RF 0.438 0.373 0.757 0.968 250 0.032 11277 0.021 22010 0.552 FCN + FCN 0.438 0.376 0.750 0.970 229 0.030 9902 0.018 21312 0.534 LR + FCN 0.423 0.354 0.745 0.967 255 0.033 10993 0.020 21074 0.528 The study demonstrates that the image-level contains more information related to change detection compared with temporal-spatial neighbors ( FCN row in the Table 5). However, performance improvement from the temporal-spatial module when combined with image-level data, achieving 0.438 in weighted metric in the end ( FCN+RF and FCN+FCN ). Regarding the composition of different models for the two modules, FCN is proved to be the best one for the temporal-spatial module, while RF and FCN have similar performance in the integration module. The choice of integration module could be influenced by the data format of other potential modules. This will be further studied by the FSO team. 5. Conclusion and outlook \u00b6 This project studied the potential of historical and spatial neighbor data in change detection task for the fifth interpretation process of the areal statistic of FSO. For the evaluation of this specific project, a weighted metric was defined by the FSO team. The temporal-spatial information was proved not to be as powerful as image-level information which directly detects change within visual data. However, an efficient prototype was built with 6% performance improvement in weighted metric combining the temporal-spatial module and the image-level module. It is validated that integration of modules with different source information can help to enhance the final capacity of the entire workflow. The next research step of the project would be to modify the current implementation of ConvRNN. If the numerical relationship is removed from the synthetic image data, ConvRNN should have similar performance as FCN theoretically. Also, CNN is worth trying to validate whether the temporal pattern matters in this dataset. Besides, by changing the size of the synthetic images, we can figure out how does the number of neighbour tiles impact the model performance. Appendix \u00b6 A1. Classes of land cover and land use \u00b6 Figure 20: Land Cover classification labels. Figure 21: Land Use classification labels. A2. Probability analysis of different periods \u00b6 A2.1 Land cover \u00b6 Figure 22: Land cover probability matrix. Figure 23: Land cover transformation probability without change. Figure 24: Maximum transformation probability to a certain class when land cover changes. A2.2 Land use \u00b6 Figure 25: Land use probability matrix. Figure 26: Land use transformation probability without change. Figure 27: Maximum transformation probability to a certain class when land use changes. A3 Alternative version of Section 3.2 \u00b6 A3.1 Logistic regression \u00b6 Logistic regression is a kind of Generalized Linear Model . It is the appropriate regression analysis to conduct when the dependent variable is dichotomous (binary). Like all regression analyses, logistic regression is a predictive analysis in this project. Logistic regression is used to describe data and to explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. A3.2 XGBoost & random forest \u00b6 Figure 28: Comparison of boosting and bagging models. XGBoost and Random Forest both originate from the tree model, while one is the sequential variant and the other is the parallel variant. Extreme Gradient Boosting (XGBoost) is a distributed, scalable gradient-boosted decision tree (GBDT) machine learning algorithm. Gradient boosting is a flexible method used for regression, multi-class classification, and other tasks since it is compatible with all kinds of loss functions. It recasts boosting as a numerical optimization problem with the goal of reducing the loss function of the model by adding weak classifiers while employing gradient descent. Later, a first-order iterative approach, gradient descent, is used to find the local optimal of its differentiable function. Weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling while misclassified observations would receive extra weight during training. Random Forest is a bagging technique that contains a number of decision trees generated from the dataset. Instead of relying solely on one decision tree, it takes the average of a number of trees to improve the predictive accuracy. For each tree, the input feature is a different sampled subset from all the features, making the model more robust and avoiding overfitting. Then, these trees are trained with a bootstrapping-sampled subset of the dataset respectively. Finally, the random forest takes the prediction from each tree and based on the majority votes makes the final decision. Higher accuracy is obtained and overfitting is avoided through the larger number of trees and the sampling process. A3.3 Focal loss \u00b6 The next two methods are Deep Neural Networks which need differentiable loss function for optimization training. Here we first tell the difference between the loss function and evaluation metric. The choice of loss function and evaluation metric depends on the task and data. The loss function should be chosen based on whether it is suitable for the model architecture and output type, while the evaluation metric should be relevant for the problem domain and application objectives. The loss function and the evaluation metric are two different concepts in deep learning. The loss function is used to optimize the model parameters during training, while the evaluation metric is used to measure the performance of the model on a test set. The loss function and the evaluation metric may not be the same. For example, Here we use focal loss to train a classification model, but use balanced accuracy or specific defined metric to evaluate its performance. The reason for this is that some evaluation metrics may not be differentiable or easy to optimize, or they may not match with the objective of the model. For this project with imbalanced classification task, we think the Focal Loss is a better choice than the traditional (binary) Cross Entropy Loss. \\[\\begin{align} \\\\ FL(p_t) = -{\\alpha}(1-p_t)^{\\gamma} \\ log(p_t) \\\\ \\end{align}\\] where p_t is the probability of predicting the correct class, \\(\\alpha\\) is a balance factor between positive and negative classes, and \\(\\gamma\\) is a modulation factor that controls how much weight is given to examples hard to classify. Focal loss is a type of loss function that aims to solve the problem of class imbalance in tasks like classification. Focal loss modifies the cross entropy loss by adding a factor that reduces the loss for easy examples and increases the loss for examples hard to classify. This way, focal loss focuses more on learning from misclassified examples. Compared with other loss functions such as cross entropy, binary cross entropy and dice loss, some advantages of focal loss are: It can reduce the dominance of well-classified examples and prevent them from overwhelming the gradient. It can adaptively adjust the weight of each example based on its difficulty level. It can improve the accuracy and recall of rare classes by adjusting \\(\\alpha\\) to give more weight to them. \\(\\alpha\\) should be chosen based on the class frequency. A common choice is to set \\(\\alpha_t\\) = 1 - frequency of class t. This way, rare classes get more weight than frequent classes. \\(\\gamma\\) should be chosen based on how much you want to focus on hard samples. A larger gamma means more focus on hard samples, while a smaller gamma means less focus. The original paper suggested gamma = 2 as an effective value for most cases. A3.4 Fully connected network (FCN) \u00b6 Figure 29: Network structure of FCN. The fully connected network (FCN) in deep learning is a type of neural network that consists of a series of fully connected layers. A fully connected layer is a function from \\(\\mathbb{R}_m\\) to \\(\\mathbb{R}_n\\) that maps each input dimension to each output dimension. The FCN can learn complex patterns and features from data using backpropagation algorithm. The major advantage of fully connected networks is that they are \u201cstructure agnostic.\u201d That is, no special assumptions need to be made about the input (for example, that the input consists of images or videos). Fully connected networks are used for thousands of applications, such as image recognition, natural language processing, and recommender systems. A disadvantage of FCN is that it can be very computationally expensive and prone to overfitting due to the large number of parameters involved. Another disadvantage is that it does not exploit any spatial or temporal structure in the input data, which can lead to poor performance for some tasks. A possible alternative to fully connected network is convolutional neural network (CNN), which uses convolutional layers that apply filters to local regions of the input data, reducing the number of parameters and capturing spatial features. A3.5 Convolutional neural network (CNN) \u00b6 CNN stands for convolutional neural network, which is a type of deep learning neural network designed for processing structured arrays of data such as images. CNNs are very good at detecting patterns in the input data, such as lines, shapes, colors, or even faces and objects. CNNs use a special technique called convolution, which is a mathematical operation that applies a filter (also called a kernel) to each part of the input data and produces an output called a feature map. Convolution helps to extract features from the input data and reduce its dimensionality. CNNs usually have multiple layers of convolution, followed by other types of layers such as pooling (which reduces the size of the feature maps), activation (which adds non-linearity to the network), dropout (which prevents overfitting), and fully connected (which performs classification or regression tasks). CNNs can be trained using backpropagation and gradient descent algorithms. CNNs are widely used in computer vision and have become the state of the art for many visual applications such as image classification, object detection, face recognition, semantic segmentation, etc. They have also been applied to other domains such as natural language processing for text analysis. Figure 30: Workflow of Convolutional Neural Network. In this project, the historical data of the land cover and land use can be translated to some synthetic images. The synthetic images use channels to represent sequence of surveys and the pixel value represents ground truth label. Thus, the spatial relationship of the neighbour tiles could be extracted from the data structure with the CNN. A3.6 Convolutional recurrent neural network (ConvRNN) \u00b6 A convolutional recurrent neural network (ConvRNN) is a type of neural network that combines convolutional neural networks (CNNs) and recurrent neural networks (RNNs). CNNs are good at extracting spatial features from images, while RNNs are good at capturing temporal features from sequences. ConvRNNs can be used for tasks that require both spatial and temporal features, such as image captioning and speech recognition. A ConvRNN consists of two main parts: a CNN part and an RNN part. The CNN part takes an input image or signal and applies convolutional filters to extract features. The RNN part takes these features as a sequence and processes them with recurrent units that have memory. The output of the RNN part can be a single vector or a sequence of vectors, depending on the task. A ConvRNN can learn both spatial and temporal patterns from data that have both dimensions, such as audio signals or video frames. For example, a ConvRNN can detect multiple sound events from an audio signal by extracting frequency features with CNNs and capturing temporal dependencies with RNNs. Figure 31: Convolutional Recurrent Neural Network Pipeline. In this project, we explored ConvRNN with structure shown in Figure 31. The sequence of surveys are treated as sequence of input \\(x^t\\) . With the recurrent structure and hidden states \\(h^t\\) to transmit information, the temporal information could be extracted. Different from the traditional Recurrent Neural Network, the function \\(f\\) in hidden layers of the recurrent structure use Convolutional operation instead of matrix computation and an additional CNN module is applied to the sequence output to detect the spatial information.","title":"Using spatio-temporal neighbor data information to detect changes in land use and land cover"},{"location":"PROJ-LANDSTATS/#using-spatio-temporal-neighbor-data-information-to-detect-changes-in-land-use-and-land-cover","text":"Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS September 2022 to March 2023 - Published on April 2023 All scripts are available on GitHub . Abstract : From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used. It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation.","title":"Using spatio-temporal neighbor data information to detect changes in land use and land cover"},{"location":"PROJ-LANDSTATS/#1-introduction","text":"The introduction presents the background and the objectives of the projects, but also introduces the input data and its specific features.","title":"1. Introduction"},{"location":"PROJ-LANDSTATS/#11-background","text":"Since 1979, the Swiss Federal Statistical Office (FSO) provides detailed and accurate information on the state and evolution of the land use and the land cover in Switzerland. It is a crucial tool for long-term spatial observation. With these statistics, it is possible to determine whether and to what extent changes in land cover and land use are consistent with the goals of Swiss spatial development policies ( FSO ). Figure 1: Visualization of the land cover and land use classification. Every few years, the FSO carries out a survey on aerial or satellite images all over Switzerland. A grid with sample points spaced 100 meters apart overlays the images, providing 4.1 million sample points on which the statistics are based. The classification of the hectare tile is assigned on the center dot, as shown in Figure 1. Currently, a time series of four surveys is accessible, based on aerial images captured in the following years: 1979\u20131985 (1st survey, 1985) 1992\u20131997 (2nd survey, 1997) 2004\u20132009 (3rd survey, 2009) 2013\u20132018 (4th survey, 2018) The first two surveys of the land statistics in 1979 and 1992 were made by visual interpretation of aerial analogue photos using stereoscopes. Since the 2004 survey, the methodology was deeply renewed, in particular through the use of digital aerial photographs, which are observed stereoscopically on workstations using specific photogrammetry software . A new nomenclature (2004 NOAS04) has also been introduced in 2004 which systematically distinguishes 46 land use categories and 27 land cover categories. A numerical label from this catalogue is assigned to each point by a team of trained interpreters. The 1979 and 1992 surveys have been revised according to the nomenclature NOAS04, so that all readings (1979, 1992, 2004, 2013) are comparable. On this page you will find the geodata of the Land Use Statistics at the hectare level since 1979, as well as documentation on the data and the methodology used to produce these data. Detailed information on basic categories and principal domains can be found in Appendix 1 .","title":"1.1 Background"},{"location":"PROJ-LANDSTATS/#12-objectives","text":"It is known that manual interpretation work is time-consuming and expensive. However, in a feasibility study , the machine learning technique showed great potential capacity to help speed up the interpretation, especially with deep learning algorithms. According to the study, 50% of the estimated interpretation workload could be saved. Therefore, FSO is currently carrying out a project to assess the relevance of learning and mastering the use of artificial intelligence (AI) technologies to automate (even partially) the interpretation of aerial images for change detection and classification. The project is called Area Statistics Deep Learning (ADELE). FSO had already developed tools for change detection and multi-class classification using the image data. However, the current workflow does not exploit the spatial and temporal dependencies between different points in the surveys. The aim of this project is therefore to evaluate the potential of spatial-temporal neighbors in predicting whether or not points in the land statistics will change class. The methodolgy will be focused on change detection, by finding as many unchanged tiles as possible (automatized capacity) and miss as few changed tiles as possible. The detailed objectives of this project are to: explore the internal transformation patterns of tile classification from a data analytics perspective build a prototype that performs change detection for tiles in the next survey help the domain experts to integrate the prototype within the OFS workflow","title":"1.2 Objectives"},{"location":"PROJ-LANDSTATS/#13-input-data","text":"The raw data delivered by the domain experts is a table with 4'163'496 records containing the interpretation results of both land cover and land use from survey 1 to survey 4. An example record is shown in Table 1 and gives following information: RELI: 8-digit number composed by the EAST hectare number concatenated with the NORTH hectare number EAST: EAST coordinates (EPSG:2056) NORTH: NORTH coordinates (EPSG:2056) LUJ: Land Use label for survey J LCJ: Land Cover label for survey J training: value 0 or 1. A value of 1 means that the point can be included in the training or validation set Table 1: Example record of raw data delivered by the domain experts. RELI EAST NORTH LU4* LC4 LU3 LC3 LU2 LC2 LU1 LC1 training 74222228 2742200 1222800 242 21 242 21 242 21 242 21 0 75392541 2753900 1254100 301 41 301 41 301 41 301 41 0 73712628 2737100 1262800 223 46 223 46 223 46 223 46 0 * The shortened LC1/LU1 to LC4/LU4 will be used to simplify the notation of Land Cover/Use of survey 1 to survey 4 in the following documentation. For machine learning, training data quality has strong influence on model performance. With the training label, domain experts from FSO selected data points that are more reliable and representative. These 348'474 tiles and their neighbors composed the training and testing dataset for machine learning methodology.","title":"1.3 Input data"},{"location":"PROJ-LANDSTATS/#2-exploratory-data-analysis","text":"As suggested by domain experts, exploratory data analysis (EDA) is of significance to understand the data statistics and find the potential internal patterns of class transformation. The EDA is implemented from three different perspectives: distribution, quantity and probability. With the combination of the three, we can find that there do exist certain trends in the transformation of both land cover and land use classes. For the land cover, main findings are: distribution: most surface of Switzerland is covered by vegetation or forest, bare land and water areas take up a considerable portion as well, artificial areas take up a small portion of the land cover probability: transformation between some classes had never happened during the past four decades, all classes of land cover are most likely to keep their status rather than to change quantity: there are some clear patterns in quantitative changes Open Forest goes to Closed Forest Brush Meadows go to Shrubs Garden Plants go to Grass and Herb Vegetation Shrubs go to Closed Forest Cluster of Tree goes to Grass and Herb Vegetation For the land use, main findings are: distribution: agricultural and forest areas are the main land uses, unused area also stands out from others classes. probability: transformation between some classes had never happened during the past four decades; on the contrary, construction site, non-exploited urban areas and forest areas tend to change to other classes rather than keep unchanged quantity: the most transformations happened inside the superclasses of Arable and Grassland and of Forest not Agricultural . Readers particularly interested by the change detection methods can directly go to Section 3 ; otherwise, readers are welcomed to read the illustrated and detailed EDA given hereafter.","title":"2. Exploratory data analysis"},{"location":"PROJ-LANDSTATS/#21-distribution-statistics","text":"Figure 2: Land cover distribution plot. Figure 3: Land use distribution plot. First, a glance at the overall distribution of land cover and land use is shown in Figure 2 and 3. The X-axis is the label of each class while the Y-axis is the number of tiles in the Log scale. The records of the four surveys are plotted in different colors chronologically. By observation, some trends can be found across the four surveys. Artificial areas only take up a small portion of the land cover (labels between 10 to 20), while most surface of Switzerland is covered by vegetation or forest (20 - 50). Bare land (50 - 60) and water areas (60 - 70) take up a considerable portion as well. For land use, it is obvious that the agricultural (200 - 250) and forest (300 - 310) areas are the main components while the unused area (421) also stands out from others. Most classes kept the same tendency during the past 40 years. There are 11 out of 27 land cover classes and 32 out of 46 land use classes which are continuously increasing or decreasing all the time. Especially for land use, compared with 10 classes rising with time, 22 classes dropping, which indicates that there is some transformation patterns that caused the leakage from some classes to those 10 classes. We will dive into these patterns in the following sections.","title":"2.1 Distribution statistics"},{"location":"PROJ-LANDSTATS/#22-quantity-statistics","text":"The data are explored in a quantitative way by three means: visualization of transformations between 2 surveys visualization of sequential transformation over time identifying patterns and most occured transformations in different periods.","title":"2.2 Quantity statistics"},{"location":"PROJ-LANDSTATS/#23-probability-matrix","text":"The above analysis demonstrates the occurrence of transformation with quantitative statistics. However, the number of tiles for different classes is not a uniform distribution as shown in the distribution analysis. The largest class is thousands of times more than the smallest one. Sometimes, the quantity of a transformation is trivial compared with the majority, but it is caused by the small amount of tiles for the class. Even if the negligible class would not have a significant impact on the performance of change detection, it is of great importance to reveal the internal transformation pattern of the land statistics and support the multi-class classification task. Therefore, the probability analysis is designed as below: The probability analysis for land cover/use contains 3 parts: The probability matrix presents the probability of transformation from the source class (Y-axis) to the destination class (X-axis). The value of the probability is illustrated by the depth of the color in the log scale. The distribution of the probability that a class does not change, which is a more detailed visualization of the diagonal value of the probability matrix. The distribution of the maximum probability that a class changes to another certain class. This is a deeper inspection to look for a fixed transformation pattern that exists between two classes. The probability is calculated by the status change between the beginning survey and the end survey stated in the figure title. For example Figure 6 is calculated by the transformation between survey 1 and survey 4, without taking into account possible intermediate changes in survey 2 and 3.","title":"2.3 Probability matrix"},{"location":"PROJ-LANDSTATS/#3-methods","text":"The developed method should be integrated in the OFS framework for change detection and classification of land use and land cover illustrated in Figure 12. The interesting parts for this project are highlighted in orange and will be presented in the following. Figure 12: Planned structure in FSO framework for final prediction. Figure 12 shows on the left the input data type in the OFS framework. The current project work on the LC/LU neighbors introduced in Section 1.3 . The main objective of the project - to detect change by means of these neighbors - is the temporal-spatial module in Figure 12. As proposed by the feasibility study, FSO had implement studies on change detection and multi-class classification on swisstopo aerial images time series to accelerate the efficiency of the interpretation work. The predicted LC and LU probabilities and information obtained by deep learning are defined as the image-level module. In a second stage of the project, the best model for combining the temporal-spatial and the image-level module outputs is explored to evaluate the gain in performance after integration of the spatial-temporal module in the OFS framework. This is the so-called integration module. The rest of the input data will not be part of the performance evaluation.","title":"3. Methods"},{"location":"PROJ-LANDSTATS/#31-temporal-spatial-module","text":"Figure 13: Time and space structure of a tile and its neighbors. The input data to the temporal-spatial module will be the historical interpretation results of the tile to predict and its 8 neighbors. The first three surveys are used as inputs to train the models while the forth survey serves as the ground truth of the prediction. This utilizes both the time and space information in the dataset like depicted in Figure 13. During the preprocessing, the tiles with missing neighbors were discarded from the dataset to keep the data format consistent, which is insignificant (about 400 out of 348'868). The determination of change is influenced by both land cover and land use. When there is a disparity between the classifications in the fourth survey and the third one for a specific tile, it is identified as altered (positive) in change detection. The joint prediction of land cover and land use is based on the assumption that a correlation may exist between them. If the land cover of a tile undergoes a change, it is probable that its land use will also change. Moreover, the tile is assigned numerical labels. Nevertheless, the model does not desire a numerical association between classes, even when they belong to the same superclass and are closely related. To address this, we employ one-hot encoding, which transforms a single land cover column into 26 columns, with all values set to '0' except for one column marked as '1' to indicate the class. Despite increasing the model's complexity with almost two thousand input columns, this is a necessary trade-off to eliminate the risk of numerical misinterpretation.","title":"3.1 Temporal-spatial module"},{"location":"PROJ-LANDSTATS/#32-change-detection","text":"Usually, spatial change detection is a remote sensing application performed on aerial or satellite images for multiclass change detection. However, in this project, a table of point records is used for binary classification into changed and not changed classes. Different traditional and new deep learning approach have been explored to perform this task. The motivations to use them are given hereinafter. An extended version of this section with detailed introduction to the machine learning models is available in Appendix A3 . Three traditional classification models, logistic regression (LR) , XGBoost and random forest (RF) , are tested. The three models represent the most popular approaches in the field - the linear, boosting, and bagging models. In this project, logistic regression is well adapted because it can explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. Concerning XGBoost, it has the advantage that weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling, while misclassified observations would receive extra weight during training. Finally, in random forest, higher accuracy may be obtained and overfitting still avoided through the larger number of trees and the sampling process. Beyond these traditional popular approaches, another two deep learning algorithms are explored as well: fully connected network and convolutional recurrent neural network . Different from the traditional machine learning algorithms, deep learning does not require manual feature extraction or engineering. Deep neural networks capture the desired feature with back-propagation optimization process. Besides, these deep neural networks have some special design for temporal or spatial inputs, because it is assumed that the internal pattern of the dataset would match with the network structure and the model will have better performance.","title":"3.2 Change detection"},{"location":"PROJ-LANDSTATS/#33-performance-metric","text":"Once the different machine learning models are trained for the respective module, comparison has to be made on the test set to evaluate their performance. This will be performed with the help of metrics.","title":"3.3 Performance metric"},{"location":"PROJ-LANDSTATS/#34-training-and-testing-plan","text":"Introduced in Section 1.3 , the 348'474 tiles with temporal-spatial information are selected for training. The 80%-20% split is applied to the selected tiles to create the train set and the test set respectively. Adam optimizer and multi-step learning rate scheduler are deployed for better convergence. For the temporal-spatial module, metrics for ablation study on the descriptors and descriptor importance are first computed. The descriptor importance is taken from XGBoost simulations. The ablation study is performed with the logistic regression and consists of training the model with: 8 neighbors and time activated, \"baseline\" 4 neighbors (northern, western, southern, eastern neighbors) no spatial-neighbors, \"space deactivate\" no temporal-neighbors, \"time deactivate\" Then, the baseline configuration is used to trained the traditional algorithms and the deep learning ones. Metrics are compared and the best performing models are kept for the integration module. Finally, the performance of several configurations are compared for the integration module. direct outputs of the image-level module direct outputs of the best performing temporal-spatial module outputs of the best performing temporal-spatial module, followed by RF training for the integration module. outputs of the best performing temporal-spatial module, followed by FCN training for the integration module. The extra information gain from the temporal-spatial module will be studied by comparison with image-level performance only. The image-level data contain multi-class classification prediction and its confidence. We can calculate the change probability according to the probability of each class. Therefore, the weighted metric can also be applied at the image-level only. Then, the RF and FCN are tested for the integration module which combines various types of information sources.","title":"3.4 Training and testing plan"},{"location":"PROJ-LANDSTATS/#4-experiments","text":"The Experiments section covers the results obtained when performing the planned simulations for the temporal-spatial module and the integration module.","title":"4. Experiments"},{"location":"PROJ-LANDSTATS/#41-temporal-spatial-module","text":"","title":"4.1 Temporal-spatial module"},{"location":"PROJ-LANDSTATS/#42-integration-module","text":"Table 5 compares the performance of FCN or image-level only to several configurations for the integration module. Table 5: Performance metrics for the integration model in combination with a spatial-temporal model. Model Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity FCN 0.259 0.210 0.656 0.958 322 0.042 15563 0.029 14490 0.363 image-level 0.374 0.305 0.737 0.958 323 0.042 15735 0.029 20895 0.524 LR + RF 0.434 0.372 0.752 0.969 241 0.031 10810 0.020 21567 0.541 FCN + RF 0.438 0.373 0.757 0.968 250 0.032 11277 0.021 22010 0.552 FCN + FCN 0.438 0.376 0.750 0.970 229 0.030 9902 0.018 21312 0.534 LR + FCN 0.423 0.354 0.745 0.967 255 0.033 10993 0.020 21074 0.528 The study demonstrates that the image-level contains more information related to change detection compared with temporal-spatial neighbors ( FCN row in the Table 5). However, performance improvement from the temporal-spatial module when combined with image-level data, achieving 0.438 in weighted metric in the end ( FCN+RF and FCN+FCN ). Regarding the composition of different models for the two modules, FCN is proved to be the best one for the temporal-spatial module, while RF and FCN have similar performance in the integration module. The choice of integration module could be influenced by the data format of other potential modules. This will be further studied by the FSO team.","title":"4.2 Integration module"},{"location":"PROJ-LANDSTATS/#5-conclusion-and-outlook","text":"This project studied the potential of historical and spatial neighbor data in change detection task for the fifth interpretation process of the areal statistic of FSO. For the evaluation of this specific project, a weighted metric was defined by the FSO team. The temporal-spatial information was proved not to be as powerful as image-level information which directly detects change within visual data. However, an efficient prototype was built with 6% performance improvement in weighted metric combining the temporal-spatial module and the image-level module. It is validated that integration of modules with different source information can help to enhance the final capacity of the entire workflow. The next research step of the project would be to modify the current implementation of ConvRNN. If the numerical relationship is removed from the synthetic image data, ConvRNN should have similar performance as FCN theoretically. Also, CNN is worth trying to validate whether the temporal pattern matters in this dataset. Besides, by changing the size of the synthetic images, we can figure out how does the number of neighbour tiles impact the model performance.","title":"5. Conclusion and outlook"},{"location":"PROJ-LANDSTATS/#appendix","text":"","title":"Appendix"},{"location":"PROJ-LANDSTATS/#a1-classes-of-land-cover-and-land-use","text":"Figure 20: Land Cover classification labels. Figure 21: Land Use classification labels.","title":"A1. Classes of land cover and land use"},{"location":"PROJ-LANDSTATS/#a2-probability-analysis-of-different-periods","text":"","title":"A2. Probability analysis of different periods"},{"location":"PROJ-LANDSTATS/#a3-alternative-version-of-section-32","text":"","title":"A3 Alternative version of Section 3.2"},{"location":"PROJ-REGBL/","text":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL December 2020 to February 2021 - Published on March 2, 2021 Abstract : The Swiss Federal Statistical Office is in charge of the national Register of Buildings and Dwellings (RBD) which keeps track of every existing building in Switzerland. Currently, the register is being completed with buildings in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issues due to missing information and their difficulty to be collected. The construction year of the buildings is one missing information for a large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Introduction \u00b6 The Swiss Federal Statistical Office [1] is responsible of maintaining the Federal Register of Buildings and Dwellings ( RBD ) in which a collection of information about buildings and homes are stored. Currently, a completion operation of the register is being conducted to include to it any type of construction on the Swiss territory. Such completion operation comes with many challenges including the gathering of the information related to the construction being currently integrated to the register. In this set of information are the construction years of the buildings. Such information is important to efficiently characterise each Swiss building and to allow the Statistical Office to provide a reliable register to all actors relying on it. The construction year of buildings turns out to be complicated to gather, as adding new buildings to the register already impose an important workload even for the simple information. In addition, in many cases, the construction year of the building is missing or can not be easily collected to update the register. The Statistical Office mandated the STDL to perform researches on the possibility to automatically gather the construction year by analysing the swisstopo [3] National Maps [4]. Indeed, the Swiss national maps are known for their excellency, their availability on any geographical area, and for their temporal cover. The national maps are made with a rigorous and well controlled methodology from the 1950s and therefore they can be used as a reliable source of information to determine the buildings' construction year. The STDL was then responsible for performing the researches and developing a proof-of-concept to provide all the information needed to the Statistical Office for them to take the right decision on considering national maps as a reliable way of assigning a construction year for the buildings lacking information. Research Project Specifications \u00b6 Extracting the construction date out of the national maps is a real challenge, as the national maps are a heavy dataset, they are not easy to be considered as a whole. In addition, the Statistical Office needs the demonstration that it can be done in a reliable way and within a reasonable amount of time to limit the cost of such process. They are also subjected to strict tolerances on the efficiency of the construction years extraction through an automated process. The goal of at least 80 % of overall success was then provided as a constraint to the STDL . As a result, the research specifications for the STDL were: Gathering and understanding the data related to the problem Developing a proof-of-concept demonstrating the possibility to extract the construction years from the national maps Assessing the results with a reliable metric to allow demonstrating the quality and reliability of the obtained construction years Research Data & Selected Areas \u00b6 In this research project, two datasets were considered: the building register itself and the national maps. As both datasets are heavy and complex, considering them entirely for such a research project would have been too complicated and unnecessary. It was then decided to focus on four areas selected for their representativeness of Swiss landscape: Basel (BS): Urban area Bern (BE): Urban and peri-urban area Biasca (TI): Rural and mountainous Caslano (TI): Peri-urban and rural The following images give a geographical illustration of the selected areas through their most recent map: Illustration of the selected areas: Basel (2015), Bern (2010), Biasca (2012) and Caslano (2009) Data: swisstopo Basel was selected as it was one example of an area on which the building register was already well filled in terms of construction years. The four regions are 6km by 6km squared areas which allows up to twenty thousand buildings to be considered on a single one. Federal Register of Buildings and Dwellings \u00b6 The register of buildings is a formal database composed with entries, each of them representing a specific building. Each entry comes with a set of information related to the building they describe. In this project, a sub-set of these informations was considered: Federal identifier of the building (EGID) The position of the building, expressed in the EPGS:2056 (GKODE, GKODN) The building construction year, when available (GBAUJ) The surface of the building, when available, expressed in square metres (GAREA) In addition, tests were conducted by considering the position of the entries of each building. In turned out rapidly that they were not useful in this research project as they were missing on a large fraction on the register and only providing a redundant information according to the position of the buildings. The following table gives a summary of the availability of the construction year in the register according to the selected areas: Area Buildings Available years Missing fraction Basel 17\u2019088 16\u2019584 3% Bern 21\u2019251 4\u2019499 79% Biasca 3\u2019774 1\u2019346 64% Caslano 5\u2019252 2\u2019452 53% One can see that the amount of missing construction year can be large depending on the considered area. National Maps \u00b6 On the side of the national maps, the dataset is more complex. In addition to the large number of available maps, variations of them can also be considered. Indeed, maps are made for different purposes and come with variations in their symbology to emphasise elements on which they focus. Moreover, for modern years, sets of vector data can also be considered in parallel to maps. Vector data are interesting as they allow to directly access the desired information, that is the footprint of the building without any processing required. The drawback of the vector data is their temporal coverage which is limited to the last ten to twenty years. The following images give an illustration of the aspect of the available maps and vector datasets considering the example of the Bern area. Starting with the traditional maps : Available map variations: KOMB, KGRS and KREL - Data: swisstopo and the more specific and vector ones: Available map variations: SITU, GEB and DKM25-GEB (vector) - Data: swisstopo In addition to the number of available variations and data types, they all come with their specific temporal coverage. In the case of this research project, we tried to go back in time as much as possible, simplifying the choice for the older maps. The question still remains for more modern times. As we are mostly interesting in buildings, the availability of already extracted building layers, that can be either raster or vector data, is highly interesting. But the problem of data selection is complex in our case. Indeed, no matter the choice, on the older times, the only available maps have to be considered. In addition to building footprint access, the question of the continuity of the data as to be considered with care. More than building footprints, we are interested in the continuity of these footprints, in order to be able to safely assume the cycle of life of the tracker buildings. This consideration led us to discover variation in methodologies depending on the considered set of data. Indeed, buildings are not shaped in the same way on traditional maps than they are in layer focusing on them. It follows that variation of the symbology, so do the shape of the building, appears between traditional maps and building layers (raster and vector). These variations can lead to shocks going from a map to the one preceding it in time. This can break the continuity of the building footprints along time, making them much more difficult to track safely. This is the reason we choose to focus on the KOMB variation of the maps. These maps are very stable and covers the largest temporal ranges. The methodology was kept very similar along the years, making this dataset much more reliable to work with when the time dimension is considered. Only considering the KOMB variation of the maps also allows to ensure that all source data is treated the same in the processing pipeline, easing the assessment of the results. In addition, the KOMB maps are dense in information and come with colorimetry of their symbology. This opens the possibility to more easily extract the information we need in this project, that are the building footprints. One exception was made concerning the KOMB maps: in their very latest version, the methodology changed, causing the symbology to be different with the older KOMB maps. In their latest version, texts are much more numerous and tend to cover a large amount of the buildings, making them invisible . For this reason, their latest version was dropped, slightly reducing the temporal coverage on the 2015-2020 period. Selecting the KOMB variation allowed us to obtain the following temporal coverage for the four selected areas: Area Oldest map Latest map Mean separation Basel 1955 2015 5.5 Years Bern 1954 2010 5.6 Years Biasca 1970 2012 6.0 Years Caslano 1953 2009 6.2 Years One can see that a large portion of the 20th century can be covered using the maps with a very good resolution of around five to six years between the maps. Research Approaches \u00b6 In this research project, the main focus was put on the national maps to extract the construction year of buildings as the maps are sources on which we can rely and assess the results. The only drawback of the maps is their limited temporal coverage, as they only start to be available in the 1950s . This is the reason why another experimental approach was also added to address the cases of building being built before the 1950s . This secondary approach focused on a statistical methodology to verify to which extent it could be possible to assign a construction date even in the case no maps are available. National Maps : This main approach focuses on the national maps from which the construction year of a building is deduced from a temporal analysis of the maps. Each building is tracked until it disappears or change its shape on a given map allowing to deduce that the construction of the building was made in the gap separating the map and its successor one. Statistical Analysis : This method is based on the principle of spatial dependence and furthermore on concentric zones of urban development. This is technically an interpolator which deduces construction years based first on different searching radii for difference variances, second by splitting the data in quantiles and, finally, by a gaussian mixture model unsupervised learning technique to gather the final predictions. The statistical analysis allows then to consider buildings that were detected on all maps, meaning their construction is older than the oldest available map, to assign them an estimation of their construction year, knowing they had to be older than the oldest map. Research Approach: National Maps \u00b6 In order to detect construction year of buildings, we need to be able to track them down on the maps across the temporal coverage. The RBD is providing the reference list of the building, each coming with a federal identifier ( EGID ) and a position. This position can then be used to track down the building on maps for its appearance or morphological change. As the maps are already selected, as the research areas, this research approach can be summarised in the following way: Translating maps into binary images containing only building Extracting the RBD buildings related to the analysed area Detection procedure of the buildings on the maps Detection of the morphological variation of the buildings Assessment of the obtained results The four first points are related to the development of the proof-of-concept. The last one concern a very sensitive and complicated question relative to the considered problem: how to analyse and assess the obtained results. This question was to most difficult question in this research, and finding a clear and reliable answer is mandatory before to develop anything. For this reason, it is considered in the first place. Reliability of the Data \u00b6 Assessing the results is essentially having a strong reference allowing to compare both in order to obtain a reliable characterisation of the success rate in the deduction of the construction years. This question leads to the discovery that this problem is much more complex that and can appear in the first place. Indeed, we were warned by the Statistical Office that the RBD , considering the construction years it already gives, can be unreliable on some of its portions. This can be explained by the fact that collecting such information is a long and complicated administrative process. As an example, the following image gives an illustration of a building tracked on each of the available selected maps: Temporal track of a selected building On this illustration, one can see two things: the RBD announce a construction year in 1985 ; the maps are clearly indicating something different, locating its construction year between 1963 and 1969 . So both datasets are contradicting each other. In order to solve the contradiction, we manually searched for historical aerial images. The following images illustrate what was found: Aerial view of the building situation: 1963, 1967 and 1987 - Data: swisstopo One can clearly see that the maps seem to give the correct answer concerning the construction date of this specific building, the RBD being contradicted by two other sources. This illustrates the fact that the RBD can not be directly considered as a reliable reference to assess the results. The same question applies for the maps. Even if it is believed that they are highly reliable, one has to be careful with such consideration. Indeed, looking at the following example: Temporal track of a selected building In this case, the RBD gives 1986 as the construction date of the pointed building. The maps are giving a construction year between 1994 and 2000 . Again, the two datasets are contradicting each other. The same procedure was conducted to solve the contradiction: Aerial view of the building situation: 1970, 1986 and 1988 - Data: swisstopo Looking at the aerial images, it seems that the tracked building was there in 1988 . One can see that the map in 1994 continue to represent the four old buildings instead on the new one. It's only in 2000 that the maps are correctly representing the new building. This shows that despite maps are a reliable source of geo-information, they can also be subjected to delay in their symbology. The maps also come with the problem of the consistency of the building footprint symbology. Looking at the following example: Temporal track of a selected building one can see that the maps seem to indicate a strange evolution of the situation: a first building appears in 1987 and it is destroyed and replaced by a larger one in 1993 . Then, this new large building seems to have been destroyed right after its construction to be replaced by a new one in 1998 . Considering aerial images of the building situation: Aerial image view of the building situation: 1981, 1987 and 1993 - Data: swisstopo one can clearly see that a first building was constructed and completed by an extension between 1987 and 1993 . This shows an illustration where the symbology of the building footprints can be subjected to variation than can be de-synchronised regarding the true situation. Metric \u00b6 In such context, neither the RBD or the national maps can be formally considered as a reference. It follows that we are left without a solution to assess our results, and more problematically, without any metric able to guide the developments of the proof-of-concept in the right direction. To solve the situation, one hypothesis is made in this research project. Taking into account both the RBD and the national maps, one can observe that both are built using methodologies that are very different. On one hand, the RBD is built out of a complex administrative process, gathering the required information in a step by step process, going from communes to cantons , and finally to the Statistical Office . On the other hand, the national maps are built using regular aerial image campaigns conducted over the whole Switzerland. The process of establishing maps is quite old and can then be considered as well controlled and stable. Both datasets are then made with methodologies that can be considered as fully independent from each other. This led us to the formulation of our hypothesis: Hypothesis : As the RBD and national maps are the results of independent methodologies, an error in one dataset is very unlikely to compensate an error in the other. In other words, if the RBD and the national maps agree on the construction year of a building, this information can be considered as a reliable reference, as it would be very unlikely to have two errors leading to such agreement. One should remain careful with this hypothesis, despite it sounds reasonable. It would be very difficult to assess it as requiring to gather complex confirmation data that would have to be independent of the RBD , the national maps and the aerial images (as maps are based on them). This assumption is the only one made in this research project. Accepting this assumption leads us to the possibility to establish a formal reference that can be used as a metric to assess the results and to guide the development of the proof-of-concept. But such reference has to be made with care, as the problem remains complex. To illustrate this complexity, the following figure gives a set representation of our problem: Set representation of the RBD completion problem The two rectangles represent the set of buildings for a considered area. On the left, one can see the building set from the RBD point of view. The grey area shows the building without the information of their construction year. Its complementary set is split in two sub-sets that are the buildings having a construction year that is absolutely correct and absolutely incorrect (the limit between both is subject to a bit of interpretation, as the construction year is not a strong concept). If a reference can be extracted, it should be in the green sub-set. The problem is that we have no way of knowing which building are in which sub-set. So the national maps were considered to define another sub-set: the synchronous sub-set where both RBD and national maps agree. To build the metric, the RBD sub-set of buildings coming with the information of the construction year is randomly sub-sampled to extract a representative sub-set: the potentials . This sub-set of potentials is then manually analysed to separate the building on which both datasets agree and to reject the other. At the end of the process, the metric sub-set is obtained and should remain representative. On the right of the set representation is the view of the buildings set through the national maps. One can see that the same sub-set appears but it replaces the construction years by the representation of the building on the maps. The grey part is then representing the building that are not represented on the maps because of their size or because they can be hidden by the symbology for example. The difference is that the maps do not give access to the construction years directly, but they are read from the maps through our developed detector. The detector having a success rate, it cuts the whole set of sub-sets in half, which is exactly what we need for out metric. If the metric sub-set remains representative, the success rate of the detector evaluated on it should generalise to the whole represented buildings. This set representation demonstrates that the problem is very complex and has to be handled with care. Considering only the six most important sub-set and considering construction year are extracted by the detector from the maps, it means that up to 72 specific case can apply on each building randomly selected. To perform the manual selection, a random selection of potential buildings was made on the RBD set of buildings coming with a construction year. The following table summarises the selection and manual validation: Area Potentials Metric Basel 450 EGIDs 209 EGIDs Bern 450 EGIDs 180 EGIDs Biasca 336 EGIDs 209 EGIDs Caslano 450 EGIDs 272 EGIDs The previous table gives the result of the second manual validation. Indeed, two manual validation sessions were made, with several weeks in-between, to check the validation process and how it evolved with the increase of the view of the problem. Three main critics can then be addressed to the metric: the first one is that establishing validation criterion is not simple as the number of cases in which buildings can fall is very high. Understanding the problem takes time and requires to see a lot of these cases. It then follows that the second validation session was more stable and rigorous than the first one. The second critic that can be made on our metric is the selection bias. As the process is made by a human, it is affected by its way of applying the criterion and more specifically on by its severity on their application. Considering the whole potentials sub-set, one can conclude that a few buildings could be rejected and validated depending on the person doing the selection. The last critic concerns specific cases for which the asynchronous criterion to reject them is weak. Indeed, for some buildings, the situation is very unclear in the way the RBD and the maps give information that can not be understood. This is the case for example when the building is not represented on the map. This can be the position in the RBD or the lack of information on the maps that lead to such an unclear situation. These cases are then rejected, but without being fully sure of the asynchronous aspect regarding the maps and the RBD . Methodology \u00b6 With a reliable metric, results can be assessed and the development of the proof-of-concept can be properly guided. As mentioned above, the proof-of-concept can be split in four major steps that are the processing of the maps, the extraction of the RBD buildings, detection of the building on the maps and detection in morphological changes. National Maps Processing \u00b6 In order to perform the detection of building on the maps, a reliable methodology is required. Indeed, one could perform the detection directly on the source maps but this would lead to a complicated process. Indeed, maps are mostly the result of the digitisation of paper maps creating a large number of artefacts on the digital images. This would lead to an unreliable way of detecting building as a complicated decision process would have to be implemented each time a RBD position is checked on each map. A map processing step was then introduced in the first place allowing to translate the color digitised images into reliable binary images on which building detection can be made safely and easily. The goal of this process is then to create a binary version of each map with black pixels indicating the building presence. A method of extracting buildings on maps was then designed. Considering the following example of a map cropped according to a defined geographical area ( Basel ): Example of a considered map: Basel in 2005 and closer view - Data: swisstopo The first step of the map processing methodology is to correct and standardise the exposure of the digitised maps. Indeed, as maps mostly result of a digitisation process, they are subjected to exposure variation due to the digitisation process. A simple standardisation is then applied. The next step consists in black pixel extraction. Each pixel of the input map is tested to determine whether or not it can be considered as black using specific thresholds. As the building are drawn in black, extracting black pixels is a first way of separating the buildings from the rest of the symbology. The following result is obtained: Result of the black extraction process As one can see on the result of the black extraction process, the buildings are still highly connected to other symbological elements and to each others in some cases. Having the building footprints well separated and well defined is an important point for subsequent processes responsible of construction years deduction. To achieve it, two steps are added. The first one uses a variation of the Conway game of life [5] to implement a morphological operator able to disconnect pixel groups. The following image gives the results of this separation process along with the previous black extraction result on which it is based: Result of the morphological operator (right) compare to the previous black extraction (left) As the morphological operator provides the desired result, it also shrinks the footprint of the elements. It allows to eliminate a lot of structures that are not buildings, but it also reduces the footprint of the buildings themselves, which can increase the amount of work to perform by the subsequent processes to properly detect a building. To solve this issue and to obtain building footprints that are as close as possible to the original map, a controlled re-growing step is added. It uses a region threshold and the black extraction result to re-grow the buildings without going any further of their original definition. The following images give a view of the final result along with the original map: Final result of the building footprints extraction (right) compared to the original map As the Conway morphological operator is not able to get rid of all the non-building elements, such as large and bold texts, the re-growing final step also thickening them along with the building footprints. Nevertheless, the obtained binary image is able to keep most of the building footprint intact while eliminating most of the other element of the map as illustrated on the following image: Extracted building footprints, in pink, superimposed on the Bern map The obtained binary images are then used for both detection of building and detection of morphological changes as the building are easy to access and to analyse on such representation. Building Extraction from RBD \u00b6 In the case of limited geographical areas as in this research project, extracting the relevant buildings from the RBD was straightforward. Indeed, the RBD is a simple DSV database that is very easy to understand and to process. The four areas were packed into a single DSV file and the relevant building were selected through a very simple geographical filtering. Each area being defined by a simple geographical square, selecting the buildings was only a question of checking if their position was in the square or not. Building Detection Process \u00b6 Based on the computed binary images, each area can be temporally covered with maps on which building can be detected. Thanks to the processed maps, this detection is made easily, as it was reduced to detect black pixels in a small area around the position of the building provided in the RBD . For each building in the RBD , its detection on each temporal version of the map is made to create a presence table of the building. Such table is simply a Boolean value indicating whether a building was there or not according to the position provided in the RBD . The following images give an illustration of the building detection process on a given temporal version of a selected map: Detection overlay superimposed on its original map (left) and on its binary counterpart (right) One can see that for each building and for each temporal version of the map, the decision of a building presence can be made. At the end of this process, each building is associated to a list of presence at each year corresponding to an available map. Morphological Change Detection \u00b6 Detecting the presence of a building on each temporal version of the map is a first step but is not enough to determine whether or not it is the desired building. Indeed, a building can be replaced by another along the time dimension without creating a discontinuity in the presence timeline. This would lead to misinterpret the presence of building with another one, leading the construction year to be deduced too far in time. This can be illustrated by the following example: Example of building being replaced by another one without introducing a gap in the presence table In case the detection of the presence of the building is not enough to correctly deduce a construction year, a morphological criterion is added. Many different methodologies have been tried in this project, going from signature to various quantities deduce out of the footprint of the building. The most simple and most reliable way was to focus on the pixel count of the building footprint, which corresponds to its surface in geographical terms. A morphological change is considered as the surface of the building footprint changes up to a given threshold along the building presence timeline. In such a case, the presence timeline is broken at the position of the morphological change, interpreting it in the same way as a formal appearance of a building. Introducing such criteria allowed to significantly improve our results, especially in the case of urban centers. Indeed, in modern cities, large number of new buildings were built just after a previous building was being destroyed due to the lack of spaces left for new constructions. Results \u00b6 The developed proof-of-concept is applied on the four selected areas to deduce construction year for each building appearing in the RBD . With the defined metric, it is possible to assess the result in a reliable manner. Nevertheless, assessing the results with clear representations is not straightforward. In this research project, two representations were chosen: Histogram of the success rate : For this representation, the building of the metric are assigned to temporal bins of ten years in size and the success rate of the construction year is computed for each bins. Distance and pseudo-distance distribution : As the previous representation only gives access to a binary view of the results, a distance representation is added to understand to which extent mistakes are made on the deduction of a construction year. For buildings detected between two maps, the temporal middle is assumed as the guessed construction year, allowing to compute a formal distance with its reference. In case a building is detected before or beyond the map range, a pseudo-distance of zero is assigned in case the result is correct according to the reference. Otherwise, the deduced year (that is necessarily between two maps) is compared to its reference extremal map date to obtain an error pseudo-distance. In addition to the manually defined metric, the full RBD metric is also considered. As the construction years provided in the RBD have to be considered with care, as part of them are incorrect, comparing the results obtained the full RBD metric and the metric we manually defined opens the important question of the synchronisation between the maps and the RBD , viewed from the construction perspective. Results: Basel Area \u00b6 The following figures give the Basel area result using the histogram representation. The left plot uses the full RBD metric while the right one uses the manually validated one: Histogram of the success rate - Ten years bins One can see one obvious element that is the result provided by the full RBD metric (left) and the manually validated metric (right) are different. This is a clear sign that the RBD and the maps are de-synchronised on a large fraction of the building set of Basel . The other element that can be seen on the right plot is that the deduction of the construction year are more challenging where maps are available. Indeed on the temporal range covered by the maps (vertical white lines), the results drops from the overall results to 50-60 % on some of the histogram bins. The following figures show the distance and pseudo-distance distribution of the error made on the deduced construction year according to the chosen metric: Distance (red and blue) and pseudo-distance (red) of the error on the construction years The same differences as previously observed between the two metrics can also be seen here. Another important observation is that the distribution seems mostly symmetrical. This indicates that no clear deduction bias can be observed in the results provided by the proof-of-concept. Results: Bern Area \u00b6 The following figures give the histogram view of the results obtained on the Bern area: Histogram of the success rate - Ten years bins One can observe that the results are similar to the result of Basel whilst being a bit better. In addition, one can clearly see that the difference between the full RBD metric and the manually validated metric huge here. This is probably the sign that the RBD is mostly incorrect in the case of Bern . The following figures show the distance distributions for the case of Bern : Distance (red and blue) and pseudo-distance (red) of the error on the construction years Again, the distribution of the error on the deduced construction year is symmetrical in the case of Bern . Results: Biasca Area \u00b6 The following figures give the histogram view of the success rate for the case of Biasca : Histogram of the success rate - Ten years bins In this case, the results are much better according to the manually validated metric. This can be explained by the fact that Biasca is a rural/mountainous area in which growing of the urban areas are much simpler as buildings once built tend to remain unchanged, limiting the difficulty to deduce a reliable construction year. The following figures show the distance distribution for Biasca : Distance (red and blue) and pseudo-distance (red) of the error on the construction years This confirms the results seen on the histogram figure and shows that the results are very good on such areas. Results: Caslano Area \u00b6 Finally, the following figures show the histogram view of the success rate of the proof-of-concept on the case of Caslano : Histogram of the success rate - Ten years bins The same consideration applies as for the Biasca case. The results are very good as part of the Caslano area can be considered as rural or at least peri-urban. The results are a bit less good than in the Biasca case, drawing the picture that urban centres are more difficult to infer than rural areas. The following figures show the error distribution for Caslano : Distance (red and blue) and pseudo-distance (red) of the error on the construction years Results: Synthesis \u00b6 In order to synthesise the previous results, that were a bit dense due to the consideration of two representations and two metrics, the following summary is given: Basel : 78.0% of sucess rate and 80.4% of building correctly placed within \u00b15.5 years Bern : 84.4% of sucess rate and 85.0% of building correctly placed within \u00b15.6 years Biasca : 93.5% of sucess rate and 93.9% of building correctly placed within \u00b16.0 years Caslano : 90.8% of sucess rate and 91.2% of building correctly placed within \u00b16.2 years These results only consider the manually validated metric for all of the four areas. By weighting each area with their amount of buildings, one can deduce the following numbers: Switzerland : 83.9% of success rate and 84.7% of building correctly place within \u00b15.8 years These last numbers can be considered as a reasonable extrapolation of the proof-of-concept performance on the overall Switzerland. Conclusion \u00b6 As a main conclusion to the national maps approach, one can consider the results as good. It was possible to develop a proof-of-concept and to apply it on selected and representative areas of Switzerland. In this approach, it turns out that developing the proof-of-concept was the easy part. Indeed, finding a metric and demonstrating its representativeness and reliability was much more complicated. Indeed, as the two datasets can not be considered as fully reliable in the first place, a strategy had to be defined in order to be able to demonstrate that the chosen metric was able to assess our result in the way expected by the Statistical Office . In addition, the metric only required one additional hypothesis on top of the two datasets. This hypothesis, consisting in assuming that the synchronous sub-set was a quasi-sub-set of the absolutely correct construction years , can be assumed to be reasonable. Nevertheless it is important to emphasise that it was necessary to make it, leading us to remains critic and careful whilst reading the results given by our metric. The developed proof-of-concept was developed in C++ , leading to an efficient code able to be used for the whole processing of Switzerland without the necessity to deeply modify it. Research Approach: Statistical \u00b6 As the availability of the topographic/national maps does not reach the integrity of all building's year of construction in the registry, an add-on was developed to infer this information, whenever there was this need for extrapolation. Usually, the maps availability reaches the 1950s, whilst in some cities the minimum year of construction can be in the order of the 12th century, e.g. The core of this statistical model is based on the Concentric Zones Model (Park and Burgess, 1925)[6] extended to the idea of the growth of the city from the a centre (Central Business District - CBD) to all inner areas. The concept behind this statistical approach can be seen below using the example of a crop of Basel city: Illustration of the Burgess concentric zone model Although it is well known the limits of this model, which are strongly described in other famous urban models such as from Hoyt (1939)[7] and Harris and Ullman (1945)[8]. In general those critics refer to the simplicity of the model, which is considered and compensated for this application, especially by the fact that the main prediction target are older buildings that are assumed to follow the concentric zones pattern, differently than newer ones (Duncan et al., 1962)[9]. Commonly this is the pattern seen in many cities, hence older buildings were built in these circular patterns to some point in time when reconstructions and reforms are almost randomly placed in spatial and temporal terms. Moreover processes like gentrification are shown to be dispersed and quite recent (R\u00e9rat et al, 2010)[10]. In summary, a first predictor is built on the basis that data present a spatial dependence, as in many geostatistical models (Kanevski and Maignan, 2004[11]; Diggle and Ribeiro, 2007[12]; Montero and Mateu, 2015[13]). This way we are assuming that closer buildings are more related to distant buildings (Tobler, 1970[14]) in terms of year of construction and ergo the time dimension is being interpolated based on the principles of spatial models. We are here also demonstrating how those two dimensions interact. After that concentric zones are embedded through the use of quantiles, which values will be using in a probabilistic unsupervised learning technique. Finally, the predicted years are computed from the clusters generated. Metric \u00b6 Similar to the detection situation, generating a validation dataset was an especially challenging task. First of all, the dates in the RBD database could not be trusted in their integrity and the topographic maps used did not reach this time frame. In order to ascertain the construction year in the database, aerial images from swisstopo (Swiss Federal Office of Topography) were consulted and this way buildings were manually selected to compound a validation dataset. References extraction from aerial images manual analysis One of the problems related to this approach was the fact that a gap between the surveys necessary for the images exists. This way it is not able to state with precision the construction date. These gaps between surveys were approximately in the range of 5 years, although in Basel , for some areas, it reached 20 years. An example of this methodology to create a trustworthy validation set can be seen below. In the left-hand side one can see the year of the first image survey (up) and the year registered in the RBD (down) and in the right-hand side, one can see the year of the next image survey in the same temporal resolution. Methodology \u00b6 First of all, a prior searching radius is defined as half of the largest distance (between random variables). For every prediction location, the variance between all points in the prior searching radius will be used to create a posterior searching radius. This way, the higher the variance, the smaller the searching radius, as we tend to trust data less. This is mainly based on the principle of spatial dependence used in many geostatistical interpolators. The exception to this rule is for variances that are higher than 2 x the mean distance between points. In this case, the searching radius increases again in order to avoid clusters of very old houses that during tests caused underestimation. The figure below demonstrates the logic being the creation of searching radii. Searching radii computation process being d the distance between points, \u03bc the mean and s\u00b2 the variance of random variable values within the prior searching radius. It is important to mention that in case of very large number of missing data, if the searching radius does not find enough information, the posterior mean will be the same as the prior mean, possibly causing over/underestimation in those areas. This first procedure is used to fill the gaps in the entry database so clustering can be computed. The next step is then splitting the data in 10 quantiles, what could give the idea of concentric growth zones, inspired, in Burgess Model (1925)[7]. Every point in the database will then assume the value of its quantile. It is also possible to ignore this step and pass to clustering directly, what can be useful in two situations, if a more general purpose is intended or if the concentric zones pattern is not observed in the study area. As default, this step is used, which will be followed by an unsupervised learning technique. A gaussian mixture model, which does not only segments data into clusters, but indicates the probability of each point belonging to every cluster is then performed. The number of components computed is a linear function to the total number of points being used, including the ones that previously had gaps. The function to find the number of components is the following: being np the number of components/clusters, and nc the total number of points used. The number of clusters shall usually be very large compared to a standard clustering exercise. To avoid this, this value is being divided by ten, but the number of clusters will never be smaller than five. An example of clustering performed by the embedded gaussian mixture model can be seen below: Example of clustering process on the Basel area Hence the matrix of probabilities of every point belonging to each cluster (\u03bb - what can be considered a matrix of weights) is multiplied by the mean of each cluster ( 1 x nc matrix mc ), forming the A matrix: or in matrices: Finally, the predictions can then be made using the sum of each row in the A matrix. It is important to state that the same crops (study areas) were used for this test. Although Caslano was not used in this case, as it possesses too few houses with a construction date below the oldest map available. Using the metric above explained a hold out cross-validation was performed, this way a group of points was only used for validation and not for training. After that, the RMSE (Root Mean Squared Error) was calculated using the difference between the date in the RBD database and the predicted one. This RMSE was also extrapolated to the whole Switzerland, so one could have a notion of what the overall error could be, using the following equation (for the expected error): where E is the error and n the number of buildings in each region. In addition to the RMSE , the 95th percentile was computed for every study area and using all combined as well. Hence, one could discuss the spread and predictability of errors. Results \u00b6 The first case analysed was Basel , where the final RMSE was 9.78 years. The density plot below demonstrates the distribution of errors in Basel , considering the difference between the year of construction in the RBD database and the predicted one. Distribution of error on construction year extrapolation Among the evaluated cases, Basel presented a strong visible spatial dependence, and it was also the case which the largest estimated proportion of houses with construction years older than (1955) the oldest map ( 11336 or approximately 66 % of buildings). Based on the validation dataset only, there was an overall trend of underestimation and the 95th percentile reached was 20 years, showing a not so spread and flat distribution of errors. Bern was the second case evaluated, and it demonstrated to be an atypical case. This starts from the fact that a big portion of the dates seemed incongruent with reality, based on the aerial images observed and as seen in the previous detection approach. Not only that, but almost 80 % of the buildings in Bern had missing data to what refers to the year of construction. This is especially complicated as the statistical method here presented is in essence an interpolator (intYEARpolator). Basically, as in any inference problem, data that is known is used to fill unknown data, therefore a reasonable split among known and unknown inputs is expected, as well as a considerable confidence on data. In the other hand, an estimated number of 1079 (approximately 27 % of the buildings) buildings was probably older than the oldest map available (1954) in Bern crop. Therefore, in one way liability was lower in this case, but the number of prediction points was smaller too. The following figure displays the density of errors in Bern, where an RMSE of 20.64 years was computed. Distribution of error on construction year extrapolation There was an overall trend for overestimation, though there was still enough lack of spread in errors, especially if one considers the 95th percentile of 42 . Finally, the crop on Biasca was evaluated. The computed RMSE was of 13.13 years, which is closer to the Basel case and the 95th percentile was 17 years, this way presenting the least spread error distribution. In Biasca an estimated 1007 ( 32 %) buildings were found, which is not much more than the proportion in Bern, but Biasca older topographic map used was from 1970, making of it an especially interesting case. The density plot below demonstrates the concentrated error case of Biasca : Distribution of error on construction year extrapolation Once the RMSE was computed for the three regions, it was extrapolated to the whole Switzerland by making consideration the size of each dataset: Extrapolation of the error distribution on the whole Switzerland The expected extrapolated error calculated was 15.6 years and the 95th percentile was then 31 years. Conclusion \u00b6 This add-on allows extrapolating the predictions to beyond the range of the topographical maps. Its predictions are limited, but the accuracy reached can be considered reasonable, once there is a considerable lack of information in this prediction range. Nor the dates in the RBD , nor the topographic maps can be fully trusted, ergo 15.6 years of error for the older buildings is acceptable, especially by considering the relative lack of spread in errors distribution. If a suggestion for improvement were to be given, a method for smoothing the intYEARpolator predictions could be interesting. This would possibly shift the distribution of the error into closer to a gaussian with mean zero. The dangerous found when searching for such an approach is that the year of construction of buildings does not seem to present a smooth surface, despite the spatial dependence. Hence, if this were to be considered, a balance between smoothing and variability would need to found. We also demonstrated a completely different perspective on how the spatial and temporal dimensions can be joined as the random variable predicted through spatial methodology was actually time. Therefore a strong demonstration of the importance of time in spatially related models and approaches was also given. The code for the intYEARpolator was developed in Python and it runs smoothly even with this quite big proportion of data. The singular case it can be quite time-demanding is in the case of high proportion of prediction points (missing values). It should also be reproducible to the whole Switzerland with no need for modification. A conditional argument is the use of concentric zones, that can be excluded in case of a total different pattern of processing time. Reproduction Resources \u00b6 The source code of the proof-of-concept for national maps can be found here : National maps approach proof-of-concept (regbl-poc), STDL The README provides all the information needed to compile and use the proof-of-concept. The presented results and plots can be computed using the following tools suite : National maps approach results and plots (regbl-poc-analysis), STDL with again the README giving the instructions. The proof-of-concept source code for the statistical approach can be found here : Statistical approach proof-of-concept (regbl-poc-intyearpolator), STDL with its README giving the procedure to follow. The data needed to reproduce the national maps approach are not publicly available. For the national maps, a temporal series of the 1:25'000 maps of the same location are needed. They can be asked to swisstopp : GeoTIFF National Maps 1:25'000 rasters temporal sequence, swisstopo With the maps, you can follow the instruction for cutting and preparing them on the proof-of-concept README . The RBD data, used for both approaches, are not publicly available either. You can query them using the request form on the website of the Federal Statistical Office : DSV RBD data request form , Federal Statistical Office Both proof-of-concepts READMEs provide the required information to use these data. References \u00b6 [1] Federal Statistical Office [2] Federal Register of Buildings and Dwellings [3] Federal Office of Topography [4] National Maps (1:25'000) [5] Conway, J. (1970), The game of life. Scientific American, vol. 223, no 4, p. 4. [6] Park, R. E.; Burgess, E. W. (1925). \"The Growth of the City: An Introduction to a Research Project\". The City (PDF). University of Chicago Press. pp. 47\u201362. ISBN 9780226148199. [7] Hoyt, H. (1939), The structure and growth of residential neighborhoods in American cities (Washington, DC). [8] Harris, C. D., and Ullman, E. L. (1945), \u2018The Nature of Cities\u2019, Annals of the American Academy of Political and Social Science, 242/Nov.: 7\u201317. [9] Duncan, B., Sabagh, G., & Van Arsdol,, M. D. (1962). Patterns of City Growth. American Journal of Sociology, 67(4), 418\u2013429. doi:10.1086/223165 [10] R\u00e9rat, P., S\u00f6derstr\u00f6m, O., Piguet, E., & Besson, R. (2010). From urban wastelands to new\u2010build gentrification: The case of Swiss cities. Population, Space and Place, 16(5), 429-442. [11] Kanevski, M., & Maignan, M. (2004). Analysis and modelling of spatial environmental data (Vol. 6501). EPFL press. [12] Diggle, P. J. Ribeiro Jr., P. J. (2007). Model-based Geostatistics. Springer Series in Statistics. [13] Montero, J. M., & Mateu, J. (2015). Spatial and spatio-temporal geostatistical modeling and kriging (Vol. 998). John Wiley & Sons. [14] Tobler, W. R. (1970). A computer movie simulating urban growth in the Detroit region. Economic geography, 46(sup1), 234-240.","title":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS"},{"location":"PROJ-REGBL/#completion-of-the-federal-register-of-buildings-and-dwellings","text":"Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL December 2020 to February 2021 - Published on March 2, 2021 Abstract : The Swiss Federal Statistical Office is in charge of the national Register of Buildings and Dwellings (RBD) which keeps track of every existing building in Switzerland. Currently, the register is being completed with buildings in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issues due to missing information and their difficulty to be collected. The construction year of the buildings is one missing information for a large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results.","title":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS"},{"location":"PROJ-REGBL/#introduction","text":"The Swiss Federal Statistical Office [1] is responsible of maintaining the Federal Register of Buildings and Dwellings ( RBD ) in which a collection of information about buildings and homes are stored. Currently, a completion operation of the register is being conducted to include to it any type of construction on the Swiss territory. Such completion operation comes with many challenges including the gathering of the information related to the construction being currently integrated to the register. In this set of information are the construction years of the buildings. Such information is important to efficiently characterise each Swiss building and to allow the Statistical Office to provide a reliable register to all actors relying on it. The construction year of buildings turns out to be complicated to gather, as adding new buildings to the register already impose an important workload even for the simple information. In addition, in many cases, the construction year of the building is missing or can not be easily collected to update the register. The Statistical Office mandated the STDL to perform researches on the possibility to automatically gather the construction year by analysing the swisstopo [3] National Maps [4]. Indeed, the Swiss national maps are known for their excellency, their availability on any geographical area, and for their temporal cover. The national maps are made with a rigorous and well controlled methodology from the 1950s and therefore they can be used as a reliable source of information to determine the buildings' construction year. The STDL was then responsible for performing the researches and developing a proof-of-concept to provide all the information needed to the Statistical Office for them to take the right decision on considering national maps as a reliable way of assigning a construction year for the buildings lacking information.","title":"Introduction"},{"location":"PROJ-REGBL/#research-project-specifications","text":"Extracting the construction date out of the national maps is a real challenge, as the national maps are a heavy dataset, they are not easy to be considered as a whole. In addition, the Statistical Office needs the demonstration that it can be done in a reliable way and within a reasonable amount of time to limit the cost of such process. They are also subjected to strict tolerances on the efficiency of the construction years extraction through an automated process. The goal of at least 80 % of overall success was then provided as a constraint to the STDL . As a result, the research specifications for the STDL were: Gathering and understanding the data related to the problem Developing a proof-of-concept demonstrating the possibility to extract the construction years from the national maps Assessing the results with a reliable metric to allow demonstrating the quality and reliability of the obtained construction years","title":"Research Project Specifications"},{"location":"PROJ-REGBL/#research-data-selected-areas","text":"In this research project, two datasets were considered: the building register itself and the national maps. As both datasets are heavy and complex, considering them entirely for such a research project would have been too complicated and unnecessary. It was then decided to focus on four areas selected for their representativeness of Swiss landscape: Basel (BS): Urban area Bern (BE): Urban and peri-urban area Biasca (TI): Rural and mountainous Caslano (TI): Peri-urban and rural The following images give a geographical illustration of the selected areas through their most recent map: Illustration of the selected areas: Basel (2015), Bern (2010), Biasca (2012) and Caslano (2009) Data: swisstopo Basel was selected as it was one example of an area on which the building register was already well filled in terms of construction years. The four regions are 6km by 6km squared areas which allows up to twenty thousand buildings to be considered on a single one.","title":"Research Data &amp; Selected Areas"},{"location":"PROJ-REGBL/#federal-register-of-buildings-and-dwellings","text":"The register of buildings is a formal database composed with entries, each of them representing a specific building. Each entry comes with a set of information related to the building they describe. In this project, a sub-set of these informations was considered: Federal identifier of the building (EGID) The position of the building, expressed in the EPGS:2056 (GKODE, GKODN) The building construction year, when available (GBAUJ) The surface of the building, when available, expressed in square metres (GAREA) In addition, tests were conducted by considering the position of the entries of each building. In turned out rapidly that they were not useful in this research project as they were missing on a large fraction on the register and only providing a redundant information according to the position of the buildings. The following table gives a summary of the availability of the construction year in the register according to the selected areas: Area Buildings Available years Missing fraction Basel 17\u2019088 16\u2019584 3% Bern 21\u2019251 4\u2019499 79% Biasca 3\u2019774 1\u2019346 64% Caslano 5\u2019252 2\u2019452 53% One can see that the amount of missing construction year can be large depending on the considered area.","title":"Federal Register of Buildings and Dwellings"},{"location":"PROJ-REGBL/#national-maps","text":"On the side of the national maps, the dataset is more complex. In addition to the large number of available maps, variations of them can also be considered. Indeed, maps are made for different purposes and come with variations in their symbology to emphasise elements on which they focus. Moreover, for modern years, sets of vector data can also be considered in parallel to maps. Vector data are interesting as they allow to directly access the desired information, that is the footprint of the building without any processing required. The drawback of the vector data is their temporal coverage which is limited to the last ten to twenty years. The following images give an illustration of the aspect of the available maps and vector datasets considering the example of the Bern area. Starting with the traditional maps : Available map variations: KOMB, KGRS and KREL - Data: swisstopo and the more specific and vector ones: Available map variations: SITU, GEB and DKM25-GEB (vector) - Data: swisstopo In addition to the number of available variations and data types, they all come with their specific temporal coverage. In the case of this research project, we tried to go back in time as much as possible, simplifying the choice for the older maps. The question still remains for more modern times. As we are mostly interesting in buildings, the availability of already extracted building layers, that can be either raster or vector data, is highly interesting. But the problem of data selection is complex in our case. Indeed, no matter the choice, on the older times, the only available maps have to be considered. In addition to building footprint access, the question of the continuity of the data as to be considered with care. More than building footprints, we are interested in the continuity of these footprints, in order to be able to safely assume the cycle of life of the tracker buildings. This consideration led us to discover variation in methodologies depending on the considered set of data. Indeed, buildings are not shaped in the same way on traditional maps than they are in layer focusing on them. It follows that variation of the symbology, so do the shape of the building, appears between traditional maps and building layers (raster and vector). These variations can lead to shocks going from a map to the one preceding it in time. This can break the continuity of the building footprints along time, making them much more difficult to track safely. This is the reason we choose to focus on the KOMB variation of the maps. These maps are very stable and covers the largest temporal ranges. The methodology was kept very similar along the years, making this dataset much more reliable to work with when the time dimension is considered. Only considering the KOMB variation of the maps also allows to ensure that all source data is treated the same in the processing pipeline, easing the assessment of the results. In addition, the KOMB maps are dense in information and come with colorimetry of their symbology. This opens the possibility to more easily extract the information we need in this project, that are the building footprints. One exception was made concerning the KOMB maps: in their very latest version, the methodology changed, causing the symbology to be different with the older KOMB maps. In their latest version, texts are much more numerous and tend to cover a large amount of the buildings, making them invisible . For this reason, their latest version was dropped, slightly reducing the temporal coverage on the 2015-2020 period. Selecting the KOMB variation allowed us to obtain the following temporal coverage for the four selected areas: Area Oldest map Latest map Mean separation Basel 1955 2015 5.5 Years Bern 1954 2010 5.6 Years Biasca 1970 2012 6.0 Years Caslano 1953 2009 6.2 Years One can see that a large portion of the 20th century can be covered using the maps with a very good resolution of around five to six years between the maps.","title":"National Maps"},{"location":"PROJ-REGBL/#research-approaches","text":"In this research project, the main focus was put on the national maps to extract the construction year of buildings as the maps are sources on which we can rely and assess the results. The only drawback of the maps is their limited temporal coverage, as they only start to be available in the 1950s . This is the reason why another experimental approach was also added to address the cases of building being built before the 1950s . This secondary approach focused on a statistical methodology to verify to which extent it could be possible to assign a construction date even in the case no maps are available. National Maps : This main approach focuses on the national maps from which the construction year of a building is deduced from a temporal analysis of the maps. Each building is tracked until it disappears or change its shape on a given map allowing to deduce that the construction of the building was made in the gap separating the map and its successor one. Statistical Analysis : This method is based on the principle of spatial dependence and furthermore on concentric zones of urban development. This is technically an interpolator which deduces construction years based first on different searching radii for difference variances, second by splitting the data in quantiles and, finally, by a gaussian mixture model unsupervised learning technique to gather the final predictions. The statistical analysis allows then to consider buildings that were detected on all maps, meaning their construction is older than the oldest available map, to assign them an estimation of their construction year, knowing they had to be older than the oldest map.","title":"Research Approaches"},{"location":"PROJ-REGBL/#research-approach-national-maps","text":"In order to detect construction year of buildings, we need to be able to track them down on the maps across the temporal coverage. The RBD is providing the reference list of the building, each coming with a federal identifier ( EGID ) and a position. This position can then be used to track down the building on maps for its appearance or morphological change. As the maps are already selected, as the research areas, this research approach can be summarised in the following way: Translating maps into binary images containing only building Extracting the RBD buildings related to the analysed area Detection procedure of the buildings on the maps Detection of the morphological variation of the buildings Assessment of the obtained results The four first points are related to the development of the proof-of-concept. The last one concern a very sensitive and complicated question relative to the considered problem: how to analyse and assess the obtained results. This question was to most difficult question in this research, and finding a clear and reliable answer is mandatory before to develop anything. For this reason, it is considered in the first place.","title":"Research Approach: National Maps"},{"location":"PROJ-REGBL/#reliability-of-the-data","text":"Assessing the results is essentially having a strong reference allowing to compare both in order to obtain a reliable characterisation of the success rate in the deduction of the construction years. This question leads to the discovery that this problem is much more complex that and can appear in the first place. Indeed, we were warned by the Statistical Office that the RBD , considering the construction years it already gives, can be unreliable on some of its portions. This can be explained by the fact that collecting such information is a long and complicated administrative process. As an example, the following image gives an illustration of a building tracked on each of the available selected maps: Temporal track of a selected building On this illustration, one can see two things: the RBD announce a construction year in 1985 ; the maps are clearly indicating something different, locating its construction year between 1963 and 1969 . So both datasets are contradicting each other. In order to solve the contradiction, we manually searched for historical aerial images. The following images illustrate what was found: Aerial view of the building situation: 1963, 1967 and 1987 - Data: swisstopo One can clearly see that the maps seem to give the correct answer concerning the construction date of this specific building, the RBD being contradicted by two other sources. This illustrates the fact that the RBD can not be directly considered as a reliable reference to assess the results. The same question applies for the maps. Even if it is believed that they are highly reliable, one has to be careful with such consideration. Indeed, looking at the following example: Temporal track of a selected building In this case, the RBD gives 1986 as the construction date of the pointed building. The maps are giving a construction year between 1994 and 2000 . Again, the two datasets are contradicting each other. The same procedure was conducted to solve the contradiction: Aerial view of the building situation: 1970, 1986 and 1988 - Data: swisstopo Looking at the aerial images, it seems that the tracked building was there in 1988 . One can see that the map in 1994 continue to represent the four old buildings instead on the new one. It's only in 2000 that the maps are correctly representing the new building. This shows that despite maps are a reliable source of geo-information, they can also be subjected to delay in their symbology. The maps also come with the problem of the consistency of the building footprint symbology. Looking at the following example: Temporal track of a selected building one can see that the maps seem to indicate a strange evolution of the situation: a first building appears in 1987 and it is destroyed and replaced by a larger one in 1993 . Then, this new large building seems to have been destroyed right after its construction to be replaced by a new one in 1998 . Considering aerial images of the building situation: Aerial image view of the building situation: 1981, 1987 and 1993 - Data: swisstopo one can clearly see that a first building was constructed and completed by an extension between 1987 and 1993 . This shows an illustration where the symbology of the building footprints can be subjected to variation than can be de-synchronised regarding the true situation.","title":"Reliability of the Data"},{"location":"PROJ-REGBL/#metric","text":"In such context, neither the RBD or the national maps can be formally considered as a reference. It follows that we are left without a solution to assess our results, and more problematically, without any metric able to guide the developments of the proof-of-concept in the right direction. To solve the situation, one hypothesis is made in this research project. Taking into account both the RBD and the national maps, one can observe that both are built using methodologies that are very different. On one hand, the RBD is built out of a complex administrative process, gathering the required information in a step by step process, going from communes to cantons , and finally to the Statistical Office . On the other hand, the national maps are built using regular aerial image campaigns conducted over the whole Switzerland. The process of establishing maps is quite old and can then be considered as well controlled and stable. Both datasets are then made with methodologies that can be considered as fully independent from each other. This led us to the formulation of our hypothesis: Hypothesis : As the RBD and national maps are the results of independent methodologies, an error in one dataset is very unlikely to compensate an error in the other. In other words, if the RBD and the national maps agree on the construction year of a building, this information can be considered as a reliable reference, as it would be very unlikely to have two errors leading to such agreement. One should remain careful with this hypothesis, despite it sounds reasonable. It would be very difficult to assess it as requiring to gather complex confirmation data that would have to be independent of the RBD , the national maps and the aerial images (as maps are based on them). This assumption is the only one made in this research project. Accepting this assumption leads us to the possibility to establish a formal reference that can be used as a metric to assess the results and to guide the development of the proof-of-concept. But such reference has to be made with care, as the problem remains complex. To illustrate this complexity, the following figure gives a set representation of our problem: Set representation of the RBD completion problem The two rectangles represent the set of buildings for a considered area. On the left, one can see the building set from the RBD point of view. The grey area shows the building without the information of their construction year. Its complementary set is split in two sub-sets that are the buildings having a construction year that is absolutely correct and absolutely incorrect (the limit between both is subject to a bit of interpretation, as the construction year is not a strong concept). If a reference can be extracted, it should be in the green sub-set. The problem is that we have no way of knowing which building are in which sub-set. So the national maps were considered to define another sub-set: the synchronous sub-set where both RBD and national maps agree. To build the metric, the RBD sub-set of buildings coming with the information of the construction year is randomly sub-sampled to extract a representative sub-set: the potentials . This sub-set of potentials is then manually analysed to separate the building on which both datasets agree and to reject the other. At the end of the process, the metric sub-set is obtained and should remain representative. On the right of the set representation is the view of the buildings set through the national maps. One can see that the same sub-set appears but it replaces the construction years by the representation of the building on the maps. The grey part is then representing the building that are not represented on the maps because of their size or because they can be hidden by the symbology for example. The difference is that the maps do not give access to the construction years directly, but they are read from the maps through our developed detector. The detector having a success rate, it cuts the whole set of sub-sets in half, which is exactly what we need for out metric. If the metric sub-set remains representative, the success rate of the detector evaluated on it should generalise to the whole represented buildings. This set representation demonstrates that the problem is very complex and has to be handled with care. Considering only the six most important sub-set and considering construction year are extracted by the detector from the maps, it means that up to 72 specific case can apply on each building randomly selected. To perform the manual selection, a random selection of potential buildings was made on the RBD set of buildings coming with a construction year. The following table summarises the selection and manual validation: Area Potentials Metric Basel 450 EGIDs 209 EGIDs Bern 450 EGIDs 180 EGIDs Biasca 336 EGIDs 209 EGIDs Caslano 450 EGIDs 272 EGIDs The previous table gives the result of the second manual validation. Indeed, two manual validation sessions were made, with several weeks in-between, to check the validation process and how it evolved with the increase of the view of the problem. Three main critics can then be addressed to the metric: the first one is that establishing validation criterion is not simple as the number of cases in which buildings can fall is very high. Understanding the problem takes time and requires to see a lot of these cases. It then follows that the second validation session was more stable and rigorous than the first one. The second critic that can be made on our metric is the selection bias. As the process is made by a human, it is affected by its way of applying the criterion and more specifically on by its severity on their application. Considering the whole potentials sub-set, one can conclude that a few buildings could be rejected and validated depending on the person doing the selection. The last critic concerns specific cases for which the asynchronous criterion to reject them is weak. Indeed, for some buildings, the situation is very unclear in the way the RBD and the maps give information that can not be understood. This is the case for example when the building is not represented on the map. This can be the position in the RBD or the lack of information on the maps that lead to such an unclear situation. These cases are then rejected, but without being fully sure of the asynchronous aspect regarding the maps and the RBD .","title":"Metric"},{"location":"PROJ-REGBL/#methodology","text":"With a reliable metric, results can be assessed and the development of the proof-of-concept can be properly guided. As mentioned above, the proof-of-concept can be split in four major steps that are the processing of the maps, the extraction of the RBD buildings, detection of the building on the maps and detection in morphological changes.","title":"Methodology"},{"location":"PROJ-REGBL/#results","text":"The developed proof-of-concept is applied on the four selected areas to deduce construction year for each building appearing in the RBD . With the defined metric, it is possible to assess the result in a reliable manner. Nevertheless, assessing the results with clear representations is not straightforward. In this research project, two representations were chosen: Histogram of the success rate : For this representation, the building of the metric are assigned to temporal bins of ten years in size and the success rate of the construction year is computed for each bins. Distance and pseudo-distance distribution : As the previous representation only gives access to a binary view of the results, a distance representation is added to understand to which extent mistakes are made on the deduction of a construction year. For buildings detected between two maps, the temporal middle is assumed as the guessed construction year, allowing to compute a formal distance with its reference. In case a building is detected before or beyond the map range, a pseudo-distance of zero is assigned in case the result is correct according to the reference. Otherwise, the deduced year (that is necessarily between two maps) is compared to its reference extremal map date to obtain an error pseudo-distance. In addition to the manually defined metric, the full RBD metric is also considered. As the construction years provided in the RBD have to be considered with care, as part of them are incorrect, comparing the results obtained the full RBD metric and the metric we manually defined opens the important question of the synchronisation between the maps and the RBD , viewed from the construction perspective.","title":"Results"},{"location":"PROJ-REGBL/#conclusion","text":"As a main conclusion to the national maps approach, one can consider the results as good. It was possible to develop a proof-of-concept and to apply it on selected and representative areas of Switzerland. In this approach, it turns out that developing the proof-of-concept was the easy part. Indeed, finding a metric and demonstrating its representativeness and reliability was much more complicated. Indeed, as the two datasets can not be considered as fully reliable in the first place, a strategy had to be defined in order to be able to demonstrate that the chosen metric was able to assess our result in the way expected by the Statistical Office . In addition, the metric only required one additional hypothesis on top of the two datasets. This hypothesis, consisting in assuming that the synchronous sub-set was a quasi-sub-set of the absolutely correct construction years , can be assumed to be reasonable. Nevertheless it is important to emphasise that it was necessary to make it, leading us to remains critic and careful whilst reading the results given by our metric. The developed proof-of-concept was developed in C++ , leading to an efficient code able to be used for the whole processing of Switzerland without the necessity to deeply modify it.","title":"Conclusion"},{"location":"PROJ-REGBL/#research-approach-statistical","text":"As the availability of the topographic/national maps does not reach the integrity of all building's year of construction in the registry, an add-on was developed to infer this information, whenever there was this need for extrapolation. Usually, the maps availability reaches the 1950s, whilst in some cities the minimum year of construction can be in the order of the 12th century, e.g. The core of this statistical model is based on the Concentric Zones Model (Park and Burgess, 1925)[6] extended to the idea of the growth of the city from the a centre (Central Business District - CBD) to all inner areas. The concept behind this statistical approach can be seen below using the example of a crop of Basel city: Illustration of the Burgess concentric zone model Although it is well known the limits of this model, which are strongly described in other famous urban models such as from Hoyt (1939)[7] and Harris and Ullman (1945)[8]. In general those critics refer to the simplicity of the model, which is considered and compensated for this application, especially by the fact that the main prediction target are older buildings that are assumed to follow the concentric zones pattern, differently than newer ones (Duncan et al., 1962)[9]. Commonly this is the pattern seen in many cities, hence older buildings were built in these circular patterns to some point in time when reconstructions and reforms are almost randomly placed in spatial and temporal terms. Moreover processes like gentrification are shown to be dispersed and quite recent (R\u00e9rat et al, 2010)[10]. In summary, a first predictor is built on the basis that data present a spatial dependence, as in many geostatistical models (Kanevski and Maignan, 2004[11]; Diggle and Ribeiro, 2007[12]; Montero and Mateu, 2015[13]). This way we are assuming that closer buildings are more related to distant buildings (Tobler, 1970[14]) in terms of year of construction and ergo the time dimension is being interpolated based on the principles of spatial models. We are here also demonstrating how those two dimensions interact. After that concentric zones are embedded through the use of quantiles, which values will be using in a probabilistic unsupervised learning technique. Finally, the predicted years are computed from the clusters generated.","title":"Research Approach: Statistical"},{"location":"PROJ-REGBL/#metric_1","text":"Similar to the detection situation, generating a validation dataset was an especially challenging task. First of all, the dates in the RBD database could not be trusted in their integrity and the topographic maps used did not reach this time frame. In order to ascertain the construction year in the database, aerial images from swisstopo (Swiss Federal Office of Topography) were consulted and this way buildings were manually selected to compound a validation dataset. References extraction from aerial images manual analysis One of the problems related to this approach was the fact that a gap between the surveys necessary for the images exists. This way it is not able to state with precision the construction date. These gaps between surveys were approximately in the range of 5 years, although in Basel , for some areas, it reached 20 years. An example of this methodology to create a trustworthy validation set can be seen below. In the left-hand side one can see the year of the first image survey (up) and the year registered in the RBD (down) and in the right-hand side, one can see the year of the next image survey in the same temporal resolution.","title":"Metric"},{"location":"PROJ-REGBL/#methodology_1","text":"First of all, a prior searching radius is defined as half of the largest distance (between random variables). For every prediction location, the variance between all points in the prior searching radius will be used to create a posterior searching radius. This way, the higher the variance, the smaller the searching radius, as we tend to trust data less. This is mainly based on the principle of spatial dependence used in many geostatistical interpolators. The exception to this rule is for variances that are higher than 2 x the mean distance between points. In this case, the searching radius increases again in order to avoid clusters of very old houses that during tests caused underestimation. The figure below demonstrates the logic being the creation of searching radii. Searching radii computation process being d the distance between points, \u03bc the mean and s\u00b2 the variance of random variable values within the prior searching radius. It is important to mention that in case of very large number of missing data, if the searching radius does not find enough information, the posterior mean will be the same as the prior mean, possibly causing over/underestimation in those areas. This first procedure is used to fill the gaps in the entry database so clustering can be computed. The next step is then splitting the data in 10 quantiles, what could give the idea of concentric growth zones, inspired, in Burgess Model (1925)[7]. Every point in the database will then assume the value of its quantile. It is also possible to ignore this step and pass to clustering directly, what can be useful in two situations, if a more general purpose is intended or if the concentric zones pattern is not observed in the study area. As default, this step is used, which will be followed by an unsupervised learning technique. A gaussian mixture model, which does not only segments data into clusters, but indicates the probability of each point belonging to every cluster is then performed. The number of components computed is a linear function to the total number of points being used, including the ones that previously had gaps. The function to find the number of components is the following: being np the number of components/clusters, and nc the total number of points used. The number of clusters shall usually be very large compared to a standard clustering exercise. To avoid this, this value is being divided by ten, but the number of clusters will never be smaller than five. An example of clustering performed by the embedded gaussian mixture model can be seen below: Example of clustering process on the Basel area Hence the matrix of probabilities of every point belonging to each cluster (\u03bb - what can be considered a matrix of weights) is multiplied by the mean of each cluster ( 1 x nc matrix mc ), forming the A matrix: or in matrices: Finally, the predictions can then be made using the sum of each row in the A matrix. It is important to state that the same crops (study areas) were used for this test. Although Caslano was not used in this case, as it possesses too few houses with a construction date below the oldest map available. Using the metric above explained a hold out cross-validation was performed, this way a group of points was only used for validation and not for training. After that, the RMSE (Root Mean Squared Error) was calculated using the difference between the date in the RBD database and the predicted one. This RMSE was also extrapolated to the whole Switzerland, so one could have a notion of what the overall error could be, using the following equation (for the expected error): where E is the error and n the number of buildings in each region. In addition to the RMSE , the 95th percentile was computed for every study area and using all combined as well. Hence, one could discuss the spread and predictability of errors.","title":"Methodology"},{"location":"PROJ-REGBL/#results_1","text":"The first case analysed was Basel , where the final RMSE was 9.78 years. The density plot below demonstrates the distribution of errors in Basel , considering the difference between the year of construction in the RBD database and the predicted one. Distribution of error on construction year extrapolation Among the evaluated cases, Basel presented a strong visible spatial dependence, and it was also the case which the largest estimated proportion of houses with construction years older than (1955) the oldest map ( 11336 or approximately 66 % of buildings). Based on the validation dataset only, there was an overall trend of underestimation and the 95th percentile reached was 20 years, showing a not so spread and flat distribution of errors. Bern was the second case evaluated, and it demonstrated to be an atypical case. This starts from the fact that a big portion of the dates seemed incongruent with reality, based on the aerial images observed and as seen in the previous detection approach. Not only that, but almost 80 % of the buildings in Bern had missing data to what refers to the year of construction. This is especially complicated as the statistical method here presented is in essence an interpolator (intYEARpolator). Basically, as in any inference problem, data that is known is used to fill unknown data, therefore a reasonable split among known and unknown inputs is expected, as well as a considerable confidence on data. In the other hand, an estimated number of 1079 (approximately 27 % of the buildings) buildings was probably older than the oldest map available (1954) in Bern crop. Therefore, in one way liability was lower in this case, but the number of prediction points was smaller too. The following figure displays the density of errors in Bern, where an RMSE of 20.64 years was computed. Distribution of error on construction year extrapolation There was an overall trend for overestimation, though there was still enough lack of spread in errors, especially if one considers the 95th percentile of 42 . Finally, the crop on Biasca was evaluated. The computed RMSE was of 13.13 years, which is closer to the Basel case and the 95th percentile was 17 years, this way presenting the least spread error distribution. In Biasca an estimated 1007 ( 32 %) buildings were found, which is not much more than the proportion in Bern, but Biasca older topographic map used was from 1970, making of it an especially interesting case. The density plot below demonstrates the concentrated error case of Biasca : Distribution of error on construction year extrapolation Once the RMSE was computed for the three regions, it was extrapolated to the whole Switzerland by making consideration the size of each dataset: Extrapolation of the error distribution on the whole Switzerland The expected extrapolated error calculated was 15.6 years and the 95th percentile was then 31 years.","title":"Results"},{"location":"PROJ-REGBL/#conclusion_1","text":"This add-on allows extrapolating the predictions to beyond the range of the topographical maps. Its predictions are limited, but the accuracy reached can be considered reasonable, once there is a considerable lack of information in this prediction range. Nor the dates in the RBD , nor the topographic maps can be fully trusted, ergo 15.6 years of error for the older buildings is acceptable, especially by considering the relative lack of spread in errors distribution. If a suggestion for improvement were to be given, a method for smoothing the intYEARpolator predictions could be interesting. This would possibly shift the distribution of the error into closer to a gaussian with mean zero. The dangerous found when searching for such an approach is that the year of construction of buildings does not seem to present a smooth surface, despite the spatial dependence. Hence, if this were to be considered, a balance between smoothing and variability would need to found. We also demonstrated a completely different perspective on how the spatial and temporal dimensions can be joined as the random variable predicted through spatial methodology was actually time. Therefore a strong demonstration of the importance of time in spatially related models and approaches was also given. The code for the intYEARpolator was developed in Python and it runs smoothly even with this quite big proportion of data. The singular case it can be quite time-demanding is in the case of high proportion of prediction points (missing values). It should also be reproducible to the whole Switzerland with no need for modification. A conditional argument is the use of concentric zones, that can be excluded in case of a total different pattern of processing time.","title":"Conclusion"},{"location":"PROJ-REGBL/#reproduction-resources","text":"The source code of the proof-of-concept for national maps can be found here : National maps approach proof-of-concept (regbl-poc), STDL The README provides all the information needed to compile and use the proof-of-concept. The presented results and plots can be computed using the following tools suite : National maps approach results and plots (regbl-poc-analysis), STDL with again the README giving the instructions. The proof-of-concept source code for the statistical approach can be found here : Statistical approach proof-of-concept (regbl-poc-intyearpolator), STDL with its README giving the procedure to follow. The data needed to reproduce the national maps approach are not publicly available. For the national maps, a temporal series of the 1:25'000 maps of the same location are needed. They can be asked to swisstopp : GeoTIFF National Maps 1:25'000 rasters temporal sequence, swisstopo With the maps, you can follow the instruction for cutting and preparing them on the proof-of-concept README . The RBD data, used for both approaches, are not publicly available either. You can query them using the request form on the website of the Federal Statistical Office : DSV RBD data request form , Federal Statistical Office Both proof-of-concepts READMEs provide the required information to use these data.","title":"Reproduction Resources"},{"location":"PROJ-REGBL/#references","text":"[1] Federal Statistical Office [2] Federal Register of Buildings and Dwellings [3] Federal Office of Topography [4] National Maps (1:25'000) [5] Conway, J. (1970), The game of life. Scientific American, vol. 223, no 4, p. 4. [6] Park, R. E.; Burgess, E. W. (1925). \"The Growth of the City: An Introduction to a Research Project\". The City (PDF). University of Chicago Press. pp. 47\u201362. ISBN 9780226148199. [7] Hoyt, H. (1939), The structure and growth of residential neighborhoods in American cities (Washington, DC). [8] Harris, C. D., and Ullman, E. L. (1945), \u2018The Nature of Cities\u2019, Annals of the American Academy of Political and Social Science, 242/Nov.: 7\u201317. [9] Duncan, B., Sabagh, G., & Van Arsdol,, M. D. (1962). Patterns of City Growth. American Journal of Sociology, 67(4), 418\u2013429. doi:10.1086/223165 [10] R\u00e9rat, P., S\u00f6derstr\u00f6m, O., Piguet, E., & Besson, R. (2010). From urban wastelands to new\u2010build gentrification: The case of Swiss cities. Population, Space and Place, 16(5), 429-442. [11] Kanevski, M., & Maignan, M. (2004). Analysis and modelling of spatial environmental data (Vol. 6501). EPFL press. [12] Diggle, P. J. Ribeiro Jr., P. J. (2007). Model-based Geostatistics. Springer Series in Statistics. [13] Montero, J. M., & Mateu, J. (2015). Spatial and spatio-temporal geostatistical modeling and kriging (Vol. 998). John Wiley & Sons. [14] Tobler, W. R. (1970). A computer movie simulating urban growth in the Detroit region. Economic geography, 46(sup1), 234-240.","title":"References"},{"location":"PROJ-ROADSURF/","text":"Classification of road surfaces \u00b6 Gwena\u00eblle Salamin (swisstopo), Cl\u00e9mence Herny (Exolabs), Roxane Pott (swisstopo), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF August 2022 to March 2023 - Published on August 28, 2023 All scripts are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-roadsurf Abstract : The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. In terms of balanced F1 score, we obtained a global score of 0.74 over the training, validation and test area, 0.56 over the inference-only area. 1. Introduction \u00b6 The Swiss road network extends over 83'274 km 1 . Not only cyclists and hikers can be interested in knowing whether a given road section is covered by a natural or an artificial surface, but also the Swiss Federal Roads Office, which is in charge of road maintenance, and engineering companies. This information is found within the swissTLM3D 2 dataset, the large-scale topographic model of Switzerland produced by the Federal Office of Topography (swisstopo). Keeping the swissTLM3D dataset up to date is a time-consuming work that has to be done methodically. Operators draw and georeference new elements and fill in their attributes based on the visual interpretation of stereoscopic aerial images. The update of existing elements also follows this manual approach. Data science can help by autmatizing this time-consuming and systematic tasks. So far, the majority of data science studies on the identification of the road surface type, in particular those based on artificial intelligence, have been conducted in the context of improving the driving and security of autonomous vehicles 3 4 5 6 . These works rely on images shot by cameras mounted at the front of the moving vehicle itself. To our knowledge, only one study, carried out by Mansourmoghaddam et al. (2022) 7 , proposed a method based on object-based classification from aerial imagery, which could successfully tell artificial roads from natural ones. Another possible approach is to use spectral indices, as done by Zhao & Zhu (2022) 8 working on the distinction between artificial surfaces and bare land. However, their method is not specifically designed for road surfaces. The goal of this project was to determine whether the road cover is artificial or natural with the development of data science tools. For this first test, only the roads of the class \"3m Strasse\" are considered. Figure 1: Overview of the workflow for this project. As the location of roads was known, we faced a problem of supervised classification. Two approaches were tested to address it: machine learning (ML) and deep learning (DL). Both approaches used the same input data, aerial images and vector road location. 2. Data \u00b6 As input data, this project used two datasets produced by the Federal Office of Topography: swissTLM3D and SWISSIMAGE RS. We worked with data for the year 2018, for which the images and ground truth, i.e. the manually vectorized and classified roads, are available for the area of interest (AOI). Coordinates are expressed in the EPSG:2056 reference system. 2.1. Area of interest \u00b6 Figure 2: Delimitation of the area of interest with the tile numbers of the 1:25'000 Swiss national map. The area of interest (AOI) defined for this study was represented by the tiles 1168, 1188, 1208 and 1228 of the Swiss national map at a scale of 1:25'000. This zone covers an area of 840 km 2 and was chosen because of its representativeness of the Swiss territory. 2.2. swissTLM3D \u00b6 The swissTLM3D 2 dataset is a large-scale topographic model of Switzerland. It contains geospatial data necessary o the national map, such as roads, buildings and land cover. Periodical updates rely on the manual work of specialized operators. They interpret stereoscopic images and fill in attributes with the help of some additional information, like cadastral surveys and terrestrial images. The specification of aerial imagery is similar to the SWISSIMAGE RS product. The road layer contains lines with the identifier, the structure (none, bridge, tunnel, etc.), the object type (highways, 8m roads, 1 m paths, etc.) and the surface type as attributes. The two possible classes of the surface type are defined in the metadata: artificial (German: Hart) and natural (Natur). The artificial class contains surfaces of hard artificial materials like asphalt, concrete or slabs. The natural class contains roads with a surface of natural materials like gravel or dirt, and untreated surfaces. In this project, it was decided to test the classification for the type \"3m Strasse\" (3 m roads). This class encompasses roads that are between 2.81 m and 4.20 m wide. Within this subset, 6486 roads have an artificial surface and 289 a natural one. The dataset is heavily unbalanced toward the artificial roads. In addition, the swissTLM3D dataset was used to identify the forests. Indeed, they prevent us from observing roads from aerial images; hence those roads cannot be used in our study. As no layer in the swissTLM3D is specifically devoted to forested areas, they were deduced from the land cover classes. A filter was applied to only keep forests (\"Wald\") and open forests (\"Wald offen\"). Over the AOI, all the roads in quarries have a natural surface. We used our own layer from the project on the detection of mineral extraction sites to know their location. However, it is possible to use the information on the area of use from the swissTLM3D dataset which has a class on gravel quarries and one on stone quarries. 2.3. SWISSIMAGE RS \u00b6 The product SWISSIMAGE RS 9 contains aerial images of Switzerland composed by four bands: near-infrared (NIR), red (R), green (G) and blue (B). The ground resolution equals 0.10 m over the area of interest, except in some high altitude regions or regions with complex topography, where a resolution of 0.25 m is deemed sufficient. The standard deviation is +/- 0.15 m (1 sigma) for a ground resolution of 0.10 m and +/- 0.25 m (1 sigma) for a ground resolution of 0.25 m, +/- 3-5 m (1 sigma). The dataset is composed of a collection of 16-bit encoded GeoTIFF orthorectified images. The overlap between images varies, but stays always present. 3. Preprocessing \u00b6 Both the swissTLM3D and SWISSIMAGE RS dataset were processed to be suitable for the algorithms we wanted to develop. This was achieved with two procedures: the generation of the road domain and the creation of a raster mosaic. 3.1. Generation of the Road Domain \u00b6 The swissTLM3D contains a vector layer representing every road section as a 3D line with some attached attributes. As a first test, the beneficiaries requested us to perform the analysis only on roads of the type \"3m Strasse\", i.e the roads wider than 2.81 m and thinner than 4.20 m. The engineered structures were excluded based on the attribute \"KUNSTBAUTE\". Only bridges and road sections without structures were kept. Data preparation differs slightly between the two performed analyses, machine and deep learning. Results for both approaches are shown here below. Figure 3: Resulting labels (left) from the initial TLM lines (right) in the case of the machine learning. Figure 4: Resulting labels (left) from the initial TLM lines (right) in the case of deep learning. For the machine learning analysis, only the 3m roads were kept (figure 3). For the deep learning analysis, we judged safer to keep all the visible roads (figure 4). Therefore, the neighboring roads were also considered. We made the hypothesis that we would obtain better results by training the model on all the visible roads, rather than on the 3m ones only. Still, the focus on \"3m Strasse\" class was enforced through the selection of raster tiles: only those tiles containing the specific class were used as input data. Road geometries, originally linear, were transformed into polygons by adding a buffer with a flat cap style. This procedure generated unwanted overlapping areas in the neighborhood of the intersection points between contiguous road sections. Such artifacts were handled differently depending on the road types: in the case of roads with different widths, the zone of the overlap inherited the class of the widest road section among the intersecting ones. in the case of roads with the same width, in the case of the machine learning analysis, overlapping parts were discarded; in the case of the deep learning analysis, it was supposed that leaving the overlapping parts would produce more understandable labels for the algorithm than suppressing the overlap. Once that the polygons were generated, sections hidden by a forest canopy were excluded. A buffer of 2 m was also added around forests as the canopy was often seen to be extending beyond the forest delimitation as recorded in the swissTLM3D dataset. We considered adding some information about the altitude of the length of the roads to the labels. Natural and artificial roads share pretty much the same distribution in terms of altitude. For the length, the longest roads all had an artificial surface. However, the experts could not tell us if it was the case for all Switzerland or a coincidence on our AOI. For the deep learning analysis, we tried to improve the overlap between labels and images by taking cadastral data into account. A larger buffer was used on the lines for the TLM. Then, only the parts of the buffer intersecting the road surfaces from cadastral surveying were kept. As described in the deep learning analysis section , we tested the labels straight out of the TLM and the ones augmented by the cadastral surveying. We also tried to merge the labels by width type or by surface type. After the pre-processing step described here above, for the machine learning analysis, 2'781 road sections were obtained, including 110 natural ones; for the deep learning analysis, 12'208 road sections were obtained, including 3078 natural ones. Let us remind that there were many more roads labeled in the second case as we considered all the visible roads. Especially for natural roads, the vast majority did not belong to the class of interest, but rather to the \"1m Weg\" and \"2m Weg\" classes. 3.2. Raster Mosaic Generation \u00b6 As said in the description of SWISSIMAGE RS , a large overlap between images is present in the dataset. To remove this overlap, a mosaic was created. Instead of merging all the images into one, we decided to set up a XYZ raster tile service, allowing us to work at different resolutions. The first step consists in reprojecting images in the EPSG:3857 projection, compliant with standard tile map services . Then, to save memory and disk space, images were converted from 16 to 8 bits. Besides, normalization was performed to optimize the usage of the available dynamic range. Finally, images were exported to the Cloud-Optimized GeoTIFF (COG) format. COG files can then be loaded by the TiTiler application, an Open Source dynamic tile server application 10 . The MosaicJSON specification was used to store image metadata 11 . Zoom levels were bound between 17 and 20, corresponding to resolutions between 1.20 m and 0.15 m. 4. Machine Learning Analysis \u00b6 4.1. Methodology \u00b6 Before delving into machine learning, we performed some exploratory data analysis, aiming at checking whether already existing features were discriminant enough to tell natural roads from artificial ones. Additional predictive features were also generated, based on ratios between pixel values in different bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR); one spectral index; per-band statistics (mean, median, minimum, maximum, standard deviation). The machine learning analysis was performed only on the two middle tiles of the AOI. The most promising spectral index we found in the literature is the Artificial Surface Index (ASI) defined by Zhao & Zhu (2022) 12 . Unfortunately, the computation of the ASI requires the shortwave infrared (SWIR) band which is not available in the SWISSIMAGE RS data. The SWIR band can be available in satellite imagery (e.g.: Landsat 8, Sentinel 2), yet spatial resolution (20-30 m/px) is not enough for the problem at hand. Instead, the VgNIR-BI index 13 could be computed in our case, since it combines the green and NIR bands: \\[\\begin{align} \\ \\mbox{VgNIR-BI} = {\\rho_{green} - \\rho_{NIR} \\over \\rho_{green} + \\rho_{NIR}} \\ \\end{align}\\] where \u03c1 stands for the atmospherically corrected surface reflectance values of the band. In our case, no atmospheric correction was applied, because we dealt with aerial imagery instead of satellite imagery. Boxplots were generated to visualize the distribution of the aforementioned predictive features. Principal component analysis (PCA) were performed, too. The group of values passed to the PCA were the following: - pixel values: Each pixel displays 11 attributes corresponding to (1) its values on the different bands (R, G, B, NIR), (2) the ratio between bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR), and (3) the VgNIR-BI spectral index 13 . - summary statistics: Each road has 5 attributes for each band: the mean, the median, the minimum (min), the maximum (max), and the standard deviation (std). Let us note that: these two analyses were carried out on a curated selection of input data, which was ought to maximize the separation between natural and artificial roads. The road sections were filtered by pixel number and margin of error on their mean to avoid small or crowded road sections. Were the results promising, the analysis would have been carried out on the entire dataset. We confirmed that results were not biased by performing each analysis on the entire dataset and a balanced subset. We also confirmed that results were stable with respect to the chosen zoom level. 4.2. Results \u00b6 In order not to make the presentation too cumbersome, here we only show results produced at zoom level 18, on the entire dataset, and considering road sections corresponding to the following criteria: covering at least 10 pixels; enjoying a margin of error (MOE) on the mean below 12.5, computed with a coefficient level of 0.95. Figure 5: Boxplots of the statistical distribution of pixel values on each band for each surface type. Each graph represents a band and each boxplot a surface type. We can see on the figure 5 that both the median and the upper quartile are systematically higher for natural than for artificial roads across all the bands, meaning the natural roads have brighter parts. Unfortunately, we have that pixel value statistics do not allow a sharp distinction between the two classes, as the lower quartile are very close. Figure 6: Boxplots of the pixel distribution on the VgNIR-BI index and the ratios between bands. Each graph represents a ratio or the index and each boxplot a surface type. Figure 6bis: Boxplots of the pixel distribution on the ratios between bands. Each graph represents a ratio and each boxplot a surface type. The ratios between bands and the VgNIR-BI present similar values for the artificial and natural roads, allowing no distinction between the classes. Figure 7: Boxplots of the distribution for the road summary statistics on the blue band. Each graph represents a statistic and each boxplot a type of road surface. Boxplots produced with the summary statistics computed per band and per road section lead to similar conclusions. Natural roads tend to be lighter than artificial ones. However, the difference is not strong enough to affect the lower quartiles and allow a sharp distinction between classes. Figure 8: PCA of the pixels based on their value on each band. Figure 9: PCA of the roads based on their statistics on the blue band. The figures 8 and 9 present respectively the results of the PCA on the pixel values and on the statistics over road sections. Once more, we have to acknowledge that, unfortunately, artificial and natural roads cannot be separated. 4.3. Discussion \u00b6 Although boxplots reveal that some natural roads can be brighter than artificial roads, statistical indicators overlap in such a way that no sharp distinction between the two classes can be drawn. The PCA confirms such an unfortunate finding. Those results are not surprising. As a matter of fact, natural roads which are found in the \"3m Strasse\" type are mainly made by gravel or similar materials which, color-wise, make them very similar to artificial roads. 5. Deep Learning Analysis \u00b6 5.1. Methodology \u00b6 To perform the detection and classification of roads, the object detector (OD) framework developed by the STDL 14 was used. It is described in details in the dedicated page . The two central parts of the AOI constitute the training zone, i.e. the zone for the training, validation and test datasets. The two exterior parts constitute the inference-only zone, i.e. for the \"other\" dataset, to test the trained model on an entirely new zone. To assess the predictions, a script was written, final_metrics.py instead of using the one directly from the STDL's OD. We decided to take advantage that: 1. Predictions are not exclusive between classes. Every road section was detected several times with predictions of different class overlapping. 2. The delimitation of the roads are already known. Therefore, rather than choosing one correct prediction, we aggregated the predictions in a natural and an artificial index over each label. Those indices were defined as follows: \\[\\begin{align} \\ \\mbox{index}_{class} = \\frac{\\sum_{i=1}^{n} (A_{\\%,i} \\cdot \\mbox{score}_{class,i})}{\\sum_{i=1}^{n} A_{\\%,i}} \\ \\end{align}\\] where n is the number of predictions belonging to the class, \\(A_{\\%, i}\\) is the percentage of overlapping area between the label and the prediction, \\(\\mbox{score}_{class,i}\\) is its confidence score. \\[\\begin{align} \\ \\text{final class} = \\begin{cases} \\mbox{artificial} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\gt \\mbox{index}_{natural}\\\\ \\mbox{natural} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\lt \\mbox{index}_{natural} \\\\ \\mbox{undetected} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = 0 \\; \\text{ and } \\; \\mbox{index}_{natural} = 0 \\\\ \\mbox{undetermined} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = \\mbox{index}_{natural} \\; \\text{ and }\\; \\mbox{index}_{artificial} \\neq 0\\\\ \\end{cases} \\ \\end{align}\\] The largest index indicates the right class as better predictions are supporting it. Once every road has an attributed class, the result was evaluated in terms of recall, precision and balanced F1 score. \\[\\begin{align} \\ P_{class} = \\frac{TP_{class}}{TP_{class}+FP_{class}} \\text{ and } P = \\frac{P_{natural} + P_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ R_{class} = \\frac{TP_{class}}{TP_{class}+FN_{class}} \\text{ and } R = \\frac{R_{natural} + R_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ F1\\text{ }score = \\frac{2PR}{P + R} \\ \\end{align}\\] where \\(FN_{class}\\) is the number of roads that are not detected or wrongly assigned to the other class, \\(FP_{class}\\) is the number of roads from the other class wrongly attributed to the considered class, \\(P_{class}\\) is the precision, i.e. the percentage of correct roads in the detected class, \\(R_{class}\\) is the recall, i.e. the percentage of correctly found and classified roads from a class, \\(TP_{class}\\) is the number of roads correctly found in the class. The predictions are not necessarily all taken into account. They are filtered based on their confidence score. Thresholds were tested over the balanced F1 score of the validation dataset. The current dataset exhibits a very strong class imbalance. Therefore, we decided to use balanced metrics, giving the same weight to both classes. The balanced F1 score was chosen as the determining criterion between the different tested models. As it gives equal weight to both classes, the quality of the classification for the natural road was well taken into consideration. However, we have to keep in mind that we gave great importance to this class compared to its number of individuals. A great risk exists that the model would be biased toward artificial roads, because of the imbalance between classes. Therefore, we decided on a baseline model (BLM) where all the roads in the training zone are classified as artificial. Its metrics are the following: Artificial Natural Global Precision 0.97 0 0.49 Recall 1 0 0.5 F1 score 0.98 0 0.49 Table 1: Metrics for the BLM with all the roads classified as artificial The trained models should improve the global F1 score of 0.49 to be considered as an improvement. Finally, we wanted to know if the artificial and natural index could constitute a confidence score for their respective classes. The reliability diagram has been plotted to visualize the accuracy of the classification at different levels of those indices. Figure 10: Listing of the various tests carried out. To achieve the best possible results, several input parameters and files for the model training were tested. 1. We tried to improve the quality of the labels by integrating data from cadastral surveying and by merging the roads based on their cover, on their type, or not at all. 2. We trained the model with different zoom level images, from 17 to 20. 3. The influence of different band combinations on the model performance was investigated: true colors (RGB) and false colors (NirRG). For each test, the best configuration was chosen based on the global balanced F1 score. This method supposes that the best choice for one parameter did not depend on the others. 5.2. Results \u00b6 When testing different procedures to create the labels, using only the TLM and excluding the data from the cadastral survey gave the best metrics. Besides, cutting the label corresponding to the road sections and not merging them by road type or surface gave better metrics. Increasing the zoom level improved the balanced F1 score. Using the bands RGB and RG with NIR gave very similar results and an equal F1 score. Therefore, the best model is based on labels deduced from the TLM and using the RGB bands at a zoom level 20. Artificial Natural Global Precision 0.99 0.74 0.87 Recall 0.97 0.74 0.86 F1 score (1) 0.98 0.74 0.86 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) 0 0.74 0.32 Table 2: metrics for the best model over the training, test and validation area. The F1 score for the natural roads and the global one outperformed the BLM. The per-class F1 scores has been judged as satisfying by the beneficiaries. Artificial Natural Global Precision 0.98 0.22 0.60 Recall 0.95 0.26 0.61 F1 score (1) 0.96 0.24 0.60 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) -0.02 0.24 0.11 Table 3: metrics for the best model over the inference-only area. Those metrics are worse than the ones obtained over the training area. The global F1 score is still higher than for the BLM. However, the natural F1 score is not high enough. Figure 11: Absolute and relative repartition of the roads in the inference-only zone. 93.2% of the roads are correctly classified, 4.2% are in the wrong class and 2.6% are undetected or undetermined. Nearly half of the natural roads are either undetected or in the wrong class, but as they represent a tiny proportion of the dataset, they impact little the accuracy. In the training zone, only 2% of the roads are in the wrong class and 1.7% are undetected or undetermined. Figure 12: Reliability curves for the training and the inference-only zone. The artificial index can be used as confidence score for the artificial roads. The natural index can be used as confidence score for the natural ones. Indeed, the accuracy of the results for each class increases with their value. 5.3. Discussion \u00b6 The F1 score obtained is 0.86 over the area to train and validate the model and 0.60 over the rest of the AOI. The difference is essentially due to the decrease in the F1 score of the natural roads, passing from 0.74 to 0.24. The first intuition is that we were facing a case of overfitting. However, the validation loss was controlled in order to stop the training on time and avoid this problem. Another possibility would be that the two zones differ significantly and that a model trained on one cannot apply on the other. Hence, we also split the tiles randomly between the training and the inference-only zone. The gap between the balanced F1 score of the training and inference-only zone passed from 0.25 to 0.19 with the same hyper-parameters. The high recall for artificial roads indicates that the model properly detects them. However, once the artificial recall is high, the high artificial precision is in this case necessarily due. As the roads have a known location, the false positives not due to a class confusion are eliminated from our assessment. Then, only the roads classified in the wrong class can affect precision. As there are not a lot of natural roads, even if they were all wrongly classified as artificial like in the BLM, the precision would still remain well at 0.97. In the current case, the precision of the trained model is 0.01 higher than the one of the BLM. The drop in the natural F1 score is due to all the roads predicted in the wrong class. As they are only a few natural roads, errors of the model affect them more heavily. The part of the misclassified road increased by 44% between the training and the inference-only zone. Meanwhile, the part of undetermined roads only increased by 1% The F1 score could maybe be further improved by focusing more strictly on the 3m roads. Indeed, we considered it would be safer to teach the algorithm to differentiate only between surfaces and not between road types, which are defined by width. Therefore, the tiles were selected because they intersected 3m roads, but then all the roads on the tiles were transformed into labels. Because of the rarity of 3m natural roads, most of the natural roads seen by the algorithm are 2m roads and those often have a surface with grass, where the 3m natural roads have a surface made only of gravel or dirt. Over the training zone, 110 natural roads are 3m ones and 1183 ones are 2 m and 1 m paths. Maybe, labelling only the 3m roads would give better results than labelling all the visible roads. We did not tune the hyperparameter used by the deep learning model once we found a satisfying enough combination. In addition, as the algorithm is based on detectron2, not everything can easily be tuned. Using an entirely new framework and tuning the loss weights would allow better handling the class imbalance. A new framework could also allow integrating an attention mask and take advantage of the known road location like recommended by Epel (2018) 15 . Using a new framework could also allow to use images with 4 bands and integrating the NIR. However, we decided here to first try the tools we already had in our team. We can say that there is a bias in the model encouraging it to predict artificial roads. However, it is still better than the BLM. Therefore, this model is adapted for its purpose. 5.3.1. Elements specific to the application on the SwissTLM3D product \u00b6 All these findings seem negative, which is why it is appropriate to recall the significant imbalance between the classes. If we look at the percentages, 93.2% of the dataset is correctly classified over the inference-only zone. This could represent a significant gain of time compared to an operator who would do the classification manually. Indeed, once the model trained, the procedure documented here only needs 20 minutes to classify the roads of the AOI. Besides, the artificial and natural indices allow us to find most of the misclassified roads and limit the time needed for a visual verification. In addition, the information of the road surface type is already available for the whole Switzerland. When using the algorithm to update the swissTLM3D dataset, it would be possible to perform change detection between the previous and new surface type. Then, those changes could be visually verified. 6. Conclusion \u00b6 Keeping the swissTLM3D dataset up to date is a time consuming and methodical task. This project aimed at finding a method to automatize the determination of the road surface type (artificial vs. natural). We focused on roads belonging to the \"3m Strasse\" class and discovered that statistics stemming from pixel values are not enough discriminating to tell artificial roads from natural ones. Therefore, we decided not to attempt any supervised classification based on machine learning. Instead, deep learning methods are performed. With 93% of the roads classified correctly, this method gave better results in regard to the global F1 score than a baseline model classifying all the roads as artificial. However, the model classifies 4.2% of the roads in the wrong class and has difficulties performing new zones. To ensure the quality of the swissTLM3D product, we advise to first perform a classification with the algorithm, then to check roads with a low class index or a change in surface type compared to the previous version years. It could represent a huge time saver for the operators who currently classify and check a second time all the roads. Despite our investigations, we could not find the cause of the gap between the metrics for the training and the inference-only zone. Further investigation is needed. The next step for this project would be to extend the algorithm to paths of 1 to 2 m wide. The natural roads of 3 m are mostly made of gravel, which strongly resembles asphalt, while natural paths are mostly made of dirt and can grow grass. Therefore, when mixing the two road width classes in one model, the natural roads of 3 m could be too difficult to distinguish from artificial roads and end up neglected. 7. References \u00b6 Office f\u00e9d\u00e9ral de la statistique. Longueur des routes en 2020 | Office f\u00e9d\u00e9ral de la statistique. https://www.bfs.admin.ch/news/fr/2020-0273, November 2020. \u21a9 swisstopo. swissTLM3D. https://www.swisstopo.admin.ch/de/geodata/landscape/tlm3d.html. \u21a9 \u21a9 Lushan Cheng, Xu Zhang, and Jie Shen. Road surface condition classification using deep learning. Journal of Visual Communication and Image Representation , 64:102638, October 2019. doi:10.1016/j.jvcir.2019.102638 . \u21a9 Susi Marianingsih, Fitri Utaminingrum, and Fitra Abdurrachman Bachtiar. Road Surface Types Classification Using Combination of K-Nearest Neighbor and Na\u00efve Bayes Based on GLCM. International Journal of Advanced Software Computer Application , 11(2):15\u201327, 2019. \u21a9 Marcus Nolte, Nikita Kister, and Markus Maurer. Assessment of Deep Convolutional Neural Networks for Road Surface Classification. In 2018 21st International Conference on Intelligent Transportation Systems (ITSC) , 381\u2013386. Maui, HI, November 2018. IEEE. doi:10.1109/ITSC.2018.8569396 . \u21a9 Viktor Slavkovikj, Steven Verstockt, Wesley De Neve, Sofie Van Hoecke, and Rik Van De Walle. Image-Based Road Type Classification. In 2014 22nd International Conference on Pattern Recognition , 2359\u20132364. Stockholm, August 2014. IEEE. doi:10.1109/ICPR.2014.409 . \u21a9 Mohammad Mansourmoghaddam, Hamid Reza Ghafarian Malamiri, Fahime Arabi Aliabad, Mehdi Fallah Tafti, Mohamadreza Haghani, and Saeed Shojaei. The Separation of the Unpaved Roads and Prioritization of Paving These Roads Using UAV Images. Air, Soil and Water Research , 15:117862212210862, January 2022. doi:10.1177/11786221221086285 . \u21a9 Hailing Zhou, Hui Kong, Lei Wei, Douglas Creighton, and Saeid Nahavandi. On Detecting Road Regions in a Single UAV Image. IEEE Transactions on Intelligent Transportation Systems , 18(7):1713\u20131722, July 2017. doi:10.1109/TITS.2016.2622280 . \u21a9 swisstopo. SWISSIMAGE RS. https://www.swisstopo.admin.ch/fr/geodata/images/ortho/swissimage-rs.html. \u21a9 TiTiler. https://developmentseed.org/titiler/. \u21a9 Vincent Sarago, Sean Harkins, and Drew Bollinger. Developmentseed / mosaicjson-spec. https://github.com/developmentseed/mosaicjson-spec, 2021. \u21a9 Yongquan Zhao and Zhe Zhu. ASI: An artificial surface Index for Landsat 8 imagery. International Journal of Applied Earth Observation and Geoinformation , 107:102703, March 2022. doi:10.1016/j.jag.2022.102703 . \u21a9 Ronald C. Estoque and Yuji Murayama. Classification and change detection of built-up lands from Landsat-7 ETM+ and Landsat-8 OLI/TIRS imageries: A comparative assessment of various spectral indices. Ecological Indicators , 56:205\u2013217, September 2015. doi:10.1016/j.ecolind.2015.03.037 . \u21a9 \u21a9 Swiss Territorial Data Lab. Object detector. February 2023. URL: https://github.com/swiss-territorial-data-lab/object-detector . \u21a9 Sagi Eppel. Classifying a specific image region using convolutional nets with an ROI mask as input. December 2018. arXiv:1812.00291 . \u21a9","title":"Classification of road surfaces"},{"location":"PROJ-ROADSURF/#classification-of-road-surfaces","text":"Gwena\u00eblle Salamin (swisstopo), Cl\u00e9mence Herny (Exolabs), Roxane Pott (swisstopo), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF August 2022 to March 2023 - Published on August 28, 2023 All scripts are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-roadsurf Abstract : The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. In terms of balanced F1 score, we obtained a global score of 0.74 over the training, validation and test area, 0.56 over the inference-only area.","title":"Classification of road surfaces"},{"location":"PROJ-ROADSURF/#1-introduction","text":"The Swiss road network extends over 83'274 km 1 . Not only cyclists and hikers can be interested in knowing whether a given road section is covered by a natural or an artificial surface, but also the Swiss Federal Roads Office, which is in charge of road maintenance, and engineering companies. This information is found within the swissTLM3D 2 dataset, the large-scale topographic model of Switzerland produced by the Federal Office of Topography (swisstopo). Keeping the swissTLM3D dataset up to date is a time-consuming work that has to be done methodically. Operators draw and georeference new elements and fill in their attributes based on the visual interpretation of stereoscopic aerial images. The update of existing elements also follows this manual approach. Data science can help by autmatizing this time-consuming and systematic tasks. So far, the majority of data science studies on the identification of the road surface type, in particular those based on artificial intelligence, have been conducted in the context of improving the driving and security of autonomous vehicles 3 4 5 6 . These works rely on images shot by cameras mounted at the front of the moving vehicle itself. To our knowledge, only one study, carried out by Mansourmoghaddam et al. (2022) 7 , proposed a method based on object-based classification from aerial imagery, which could successfully tell artificial roads from natural ones. Another possible approach is to use spectral indices, as done by Zhao & Zhu (2022) 8 working on the distinction between artificial surfaces and bare land. However, their method is not specifically designed for road surfaces. The goal of this project was to determine whether the road cover is artificial or natural with the development of data science tools. For this first test, only the roads of the class \"3m Strasse\" are considered. Figure 1: Overview of the workflow for this project. As the location of roads was known, we faced a problem of supervised classification. Two approaches were tested to address it: machine learning (ML) and deep learning (DL). Both approaches used the same input data, aerial images and vector road location.","title":"1. Introduction"},{"location":"PROJ-ROADSURF/#2-data","text":"As input data, this project used two datasets produced by the Federal Office of Topography: swissTLM3D and SWISSIMAGE RS. We worked with data for the year 2018, for which the images and ground truth, i.e. the manually vectorized and classified roads, are available for the area of interest (AOI). Coordinates are expressed in the EPSG:2056 reference system.","title":"2. Data"},{"location":"PROJ-ROADSURF/#21-area-of-interest","text":"Figure 2: Delimitation of the area of interest with the tile numbers of the 1:25'000 Swiss national map. The area of interest (AOI) defined for this study was represented by the tiles 1168, 1188, 1208 and 1228 of the Swiss national map at a scale of 1:25'000. This zone covers an area of 840 km 2 and was chosen because of its representativeness of the Swiss territory.","title":"2.1. Area of interest"},{"location":"PROJ-ROADSURF/#22-swisstlm3d","text":"The swissTLM3D 2 dataset is a large-scale topographic model of Switzerland. It contains geospatial data necessary o the national map, such as roads, buildings and land cover. Periodical updates rely on the manual work of specialized operators. They interpret stereoscopic images and fill in attributes with the help of some additional information, like cadastral surveys and terrestrial images. The specification of aerial imagery is similar to the SWISSIMAGE RS product. The road layer contains lines with the identifier, the structure (none, bridge, tunnel, etc.), the object type (highways, 8m roads, 1 m paths, etc.) and the surface type as attributes. The two possible classes of the surface type are defined in the metadata: artificial (German: Hart) and natural (Natur). The artificial class contains surfaces of hard artificial materials like asphalt, concrete or slabs. The natural class contains roads with a surface of natural materials like gravel or dirt, and untreated surfaces. In this project, it was decided to test the classification for the type \"3m Strasse\" (3 m roads). This class encompasses roads that are between 2.81 m and 4.20 m wide. Within this subset, 6486 roads have an artificial surface and 289 a natural one. The dataset is heavily unbalanced toward the artificial roads. In addition, the swissTLM3D dataset was used to identify the forests. Indeed, they prevent us from observing roads from aerial images; hence those roads cannot be used in our study. As no layer in the swissTLM3D is specifically devoted to forested areas, they were deduced from the land cover classes. A filter was applied to only keep forests (\"Wald\") and open forests (\"Wald offen\"). Over the AOI, all the roads in quarries have a natural surface. We used our own layer from the project on the detection of mineral extraction sites to know their location. However, it is possible to use the information on the area of use from the swissTLM3D dataset which has a class on gravel quarries and one on stone quarries.","title":"2.2. swissTLM3D"},{"location":"PROJ-ROADSURF/#23-swissimage-rs","text":"The product SWISSIMAGE RS 9 contains aerial images of Switzerland composed by four bands: near-infrared (NIR), red (R), green (G) and blue (B). The ground resolution equals 0.10 m over the area of interest, except in some high altitude regions or regions with complex topography, where a resolution of 0.25 m is deemed sufficient. The standard deviation is +/- 0.15 m (1 sigma) for a ground resolution of 0.10 m and +/- 0.25 m (1 sigma) for a ground resolution of 0.25 m, +/- 3-5 m (1 sigma). The dataset is composed of a collection of 16-bit encoded GeoTIFF orthorectified images. The overlap between images varies, but stays always present.","title":"2.3. SWISSIMAGE RS"},{"location":"PROJ-ROADSURF/#3-preprocessing","text":"Both the swissTLM3D and SWISSIMAGE RS dataset were processed to be suitable for the algorithms we wanted to develop. This was achieved with two procedures: the generation of the road domain and the creation of a raster mosaic.","title":"3. Preprocessing"},{"location":"PROJ-ROADSURF/#31-generation-of-the-road-domain","text":"The swissTLM3D contains a vector layer representing every road section as a 3D line with some attached attributes. As a first test, the beneficiaries requested us to perform the analysis only on roads of the type \"3m Strasse\", i.e the roads wider than 2.81 m and thinner than 4.20 m. The engineered structures were excluded based on the attribute \"KUNSTBAUTE\". Only bridges and road sections without structures were kept. Data preparation differs slightly between the two performed analyses, machine and deep learning. Results for both approaches are shown here below. Figure 3: Resulting labels (left) from the initial TLM lines (right) in the case of the machine learning. Figure 4: Resulting labels (left) from the initial TLM lines (right) in the case of deep learning. For the machine learning analysis, only the 3m roads were kept (figure 3). For the deep learning analysis, we judged safer to keep all the visible roads (figure 4). Therefore, the neighboring roads were also considered. We made the hypothesis that we would obtain better results by training the model on all the visible roads, rather than on the 3m ones only. Still, the focus on \"3m Strasse\" class was enforced through the selection of raster tiles: only those tiles containing the specific class were used as input data. Road geometries, originally linear, were transformed into polygons by adding a buffer with a flat cap style. This procedure generated unwanted overlapping areas in the neighborhood of the intersection points between contiguous road sections. Such artifacts were handled differently depending on the road types: in the case of roads with different widths, the zone of the overlap inherited the class of the widest road section among the intersecting ones. in the case of roads with the same width, in the case of the machine learning analysis, overlapping parts were discarded; in the case of the deep learning analysis, it was supposed that leaving the overlapping parts would produce more understandable labels for the algorithm than suppressing the overlap. Once that the polygons were generated, sections hidden by a forest canopy were excluded. A buffer of 2 m was also added around forests as the canopy was often seen to be extending beyond the forest delimitation as recorded in the swissTLM3D dataset. We considered adding some information about the altitude of the length of the roads to the labels. Natural and artificial roads share pretty much the same distribution in terms of altitude. For the length, the longest roads all had an artificial surface. However, the experts could not tell us if it was the case for all Switzerland or a coincidence on our AOI. For the deep learning analysis, we tried to improve the overlap between labels and images by taking cadastral data into account. A larger buffer was used on the lines for the TLM. Then, only the parts of the buffer intersecting the road surfaces from cadastral surveying were kept. As described in the deep learning analysis section , we tested the labels straight out of the TLM and the ones augmented by the cadastral surveying. We also tried to merge the labels by width type or by surface type. After the pre-processing step described here above, for the machine learning analysis, 2'781 road sections were obtained, including 110 natural ones; for the deep learning analysis, 12'208 road sections were obtained, including 3078 natural ones. Let us remind that there were many more roads labeled in the second case as we considered all the visible roads. Especially for natural roads, the vast majority did not belong to the class of interest, but rather to the \"1m Weg\" and \"2m Weg\" classes.","title":"3.1. Generation of the Road Domain"},{"location":"PROJ-ROADSURF/#32-raster-mosaic-generation","text":"As said in the description of SWISSIMAGE RS , a large overlap between images is present in the dataset. To remove this overlap, a mosaic was created. Instead of merging all the images into one, we decided to set up a XYZ raster tile service, allowing us to work at different resolutions. The first step consists in reprojecting images in the EPSG:3857 projection, compliant with standard tile map services . Then, to save memory and disk space, images were converted from 16 to 8 bits. Besides, normalization was performed to optimize the usage of the available dynamic range. Finally, images were exported to the Cloud-Optimized GeoTIFF (COG) format. COG files can then be loaded by the TiTiler application, an Open Source dynamic tile server application 10 . The MosaicJSON specification was used to store image metadata 11 . Zoom levels were bound between 17 and 20, corresponding to resolutions between 1.20 m and 0.15 m.","title":"3.2. Raster Mosaic Generation"},{"location":"PROJ-ROADSURF/#4-machine-learning-analysis","text":"","title":"4. Machine Learning Analysis"},{"location":"PROJ-ROADSURF/#41-methodology","text":"Before delving into machine learning, we performed some exploratory data analysis, aiming at checking whether already existing features were discriminant enough to tell natural roads from artificial ones. Additional predictive features were also generated, based on ratios between pixel values in different bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR); one spectral index; per-band statistics (mean, median, minimum, maximum, standard deviation). The machine learning analysis was performed only on the two middle tiles of the AOI. The most promising spectral index we found in the literature is the Artificial Surface Index (ASI) defined by Zhao & Zhu (2022) 12 . Unfortunately, the computation of the ASI requires the shortwave infrared (SWIR) band which is not available in the SWISSIMAGE RS data. The SWIR band can be available in satellite imagery (e.g.: Landsat 8, Sentinel 2), yet spatial resolution (20-30 m/px) is not enough for the problem at hand. Instead, the VgNIR-BI index 13 could be computed in our case, since it combines the green and NIR bands: \\[\\begin{align} \\ \\mbox{VgNIR-BI} = {\\rho_{green} - \\rho_{NIR} \\over \\rho_{green} + \\rho_{NIR}} \\ \\end{align}\\] where \u03c1 stands for the atmospherically corrected surface reflectance values of the band. In our case, no atmospheric correction was applied, because we dealt with aerial imagery instead of satellite imagery. Boxplots were generated to visualize the distribution of the aforementioned predictive features. Principal component analysis (PCA) were performed, too. The group of values passed to the PCA were the following: - pixel values: Each pixel displays 11 attributes corresponding to (1) its values on the different bands (R, G, B, NIR), (2) the ratio between bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR), and (3) the VgNIR-BI spectral index 13 . - summary statistics: Each road has 5 attributes for each band: the mean, the median, the minimum (min), the maximum (max), and the standard deviation (std). Let us note that: these two analyses were carried out on a curated selection of input data, which was ought to maximize the separation between natural and artificial roads. The road sections were filtered by pixel number and margin of error on their mean to avoid small or crowded road sections. Were the results promising, the analysis would have been carried out on the entire dataset. We confirmed that results were not biased by performing each analysis on the entire dataset and a balanced subset. We also confirmed that results were stable with respect to the chosen zoom level.","title":"4.1. Methodology"},{"location":"PROJ-ROADSURF/#42-results","text":"In order not to make the presentation too cumbersome, here we only show results produced at zoom level 18, on the entire dataset, and considering road sections corresponding to the following criteria: covering at least 10 pixels; enjoying a margin of error (MOE) on the mean below 12.5, computed with a coefficient level of 0.95. Figure 5: Boxplots of the statistical distribution of pixel values on each band for each surface type. Each graph represents a band and each boxplot a surface type. We can see on the figure 5 that both the median and the upper quartile are systematically higher for natural than for artificial roads across all the bands, meaning the natural roads have brighter parts. Unfortunately, we have that pixel value statistics do not allow a sharp distinction between the two classes, as the lower quartile are very close. Figure 6: Boxplots of the pixel distribution on the VgNIR-BI index and the ratios between bands. Each graph represents a ratio or the index and each boxplot a surface type. Figure 6bis: Boxplots of the pixel distribution on the ratios between bands. Each graph represents a ratio and each boxplot a surface type. The ratios between bands and the VgNIR-BI present similar values for the artificial and natural roads, allowing no distinction between the classes. Figure 7: Boxplots of the distribution for the road summary statistics on the blue band. Each graph represents a statistic and each boxplot a type of road surface. Boxplots produced with the summary statistics computed per band and per road section lead to similar conclusions. Natural roads tend to be lighter than artificial ones. However, the difference is not strong enough to affect the lower quartiles and allow a sharp distinction between classes. Figure 8: PCA of the pixels based on their value on each band. Figure 9: PCA of the roads based on their statistics on the blue band. The figures 8 and 9 present respectively the results of the PCA on the pixel values and on the statistics over road sections. Once more, we have to acknowledge that, unfortunately, artificial and natural roads cannot be separated.","title":"4.2. Results"},{"location":"PROJ-ROADSURF/#43-discussion","text":"Although boxplots reveal that some natural roads can be brighter than artificial roads, statistical indicators overlap in such a way that no sharp distinction between the two classes can be drawn. The PCA confirms such an unfortunate finding. Those results are not surprising. As a matter of fact, natural roads which are found in the \"3m Strasse\" type are mainly made by gravel or similar materials which, color-wise, make them very similar to artificial roads.","title":"4.3. Discussion"},{"location":"PROJ-ROADSURF/#5-deep-learning-analysis","text":"","title":"5. Deep Learning Analysis"},{"location":"PROJ-ROADSURF/#51-methodology","text":"To perform the detection and classification of roads, the object detector (OD) framework developed by the STDL 14 was used. It is described in details in the dedicated page . The two central parts of the AOI constitute the training zone, i.e. the zone for the training, validation and test datasets. The two exterior parts constitute the inference-only zone, i.e. for the \"other\" dataset, to test the trained model on an entirely new zone. To assess the predictions, a script was written, final_metrics.py instead of using the one directly from the STDL's OD. We decided to take advantage that: 1. Predictions are not exclusive between classes. Every road section was detected several times with predictions of different class overlapping. 2. The delimitation of the roads are already known. Therefore, rather than choosing one correct prediction, we aggregated the predictions in a natural and an artificial index over each label. Those indices were defined as follows: \\[\\begin{align} \\ \\mbox{index}_{class} = \\frac{\\sum_{i=1}^{n} (A_{\\%,i} \\cdot \\mbox{score}_{class,i})}{\\sum_{i=1}^{n} A_{\\%,i}} \\ \\end{align}\\] where n is the number of predictions belonging to the class, \\(A_{\\%, i}\\) is the percentage of overlapping area between the label and the prediction, \\(\\mbox{score}_{class,i}\\) is its confidence score. \\[\\begin{align} \\ \\text{final class} = \\begin{cases} \\mbox{artificial} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\gt \\mbox{index}_{natural}\\\\ \\mbox{natural} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\lt \\mbox{index}_{natural} \\\\ \\mbox{undetected} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = 0 \\; \\text{ and } \\; \\mbox{index}_{natural} = 0 \\\\ \\mbox{undetermined} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = \\mbox{index}_{natural} \\; \\text{ and }\\; \\mbox{index}_{artificial} \\neq 0\\\\ \\end{cases} \\ \\end{align}\\] The largest index indicates the right class as better predictions are supporting it. Once every road has an attributed class, the result was evaluated in terms of recall, precision and balanced F1 score. \\[\\begin{align} \\ P_{class} = \\frac{TP_{class}}{TP_{class}+FP_{class}} \\text{ and } P = \\frac{P_{natural} + P_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ R_{class} = \\frac{TP_{class}}{TP_{class}+FN_{class}} \\text{ and } R = \\frac{R_{natural} + R_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ F1\\text{ }score = \\frac{2PR}{P + R} \\ \\end{align}\\] where \\(FN_{class}\\) is the number of roads that are not detected or wrongly assigned to the other class, \\(FP_{class}\\) is the number of roads from the other class wrongly attributed to the considered class, \\(P_{class}\\) is the precision, i.e. the percentage of correct roads in the detected class, \\(R_{class}\\) is the recall, i.e. the percentage of correctly found and classified roads from a class, \\(TP_{class}\\) is the number of roads correctly found in the class. The predictions are not necessarily all taken into account. They are filtered based on their confidence score. Thresholds were tested over the balanced F1 score of the validation dataset. The current dataset exhibits a very strong class imbalance. Therefore, we decided to use balanced metrics, giving the same weight to both classes. The balanced F1 score was chosen as the determining criterion between the different tested models. As it gives equal weight to both classes, the quality of the classification for the natural road was well taken into consideration. However, we have to keep in mind that we gave great importance to this class compared to its number of individuals. A great risk exists that the model would be biased toward artificial roads, because of the imbalance between classes. Therefore, we decided on a baseline model (BLM) where all the roads in the training zone are classified as artificial. Its metrics are the following: Artificial Natural Global Precision 0.97 0 0.49 Recall 1 0 0.5 F1 score 0.98 0 0.49 Table 1: Metrics for the BLM with all the roads classified as artificial The trained models should improve the global F1 score of 0.49 to be considered as an improvement. Finally, we wanted to know if the artificial and natural index could constitute a confidence score for their respective classes. The reliability diagram has been plotted to visualize the accuracy of the classification at different levels of those indices. Figure 10: Listing of the various tests carried out. To achieve the best possible results, several input parameters and files for the model training were tested. 1. We tried to improve the quality of the labels by integrating data from cadastral surveying and by merging the roads based on their cover, on their type, or not at all. 2. We trained the model with different zoom level images, from 17 to 20. 3. The influence of different band combinations on the model performance was investigated: true colors (RGB) and false colors (NirRG). For each test, the best configuration was chosen based on the global balanced F1 score. This method supposes that the best choice for one parameter did not depend on the others.","title":"5.1. Methodology"},{"location":"PROJ-ROADSURF/#52-results","text":"When testing different procedures to create the labels, using only the TLM and excluding the data from the cadastral survey gave the best metrics. Besides, cutting the label corresponding to the road sections and not merging them by road type or surface gave better metrics. Increasing the zoom level improved the balanced F1 score. Using the bands RGB and RG with NIR gave very similar results and an equal F1 score. Therefore, the best model is based on labels deduced from the TLM and using the RGB bands at a zoom level 20. Artificial Natural Global Precision 0.99 0.74 0.87 Recall 0.97 0.74 0.86 F1 score (1) 0.98 0.74 0.86 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) 0 0.74 0.32 Table 2: metrics for the best model over the training, test and validation area. The F1 score for the natural roads and the global one outperformed the BLM. The per-class F1 scores has been judged as satisfying by the beneficiaries. Artificial Natural Global Precision 0.98 0.22 0.60 Recall 0.95 0.26 0.61 F1 score (1) 0.96 0.24 0.60 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) -0.02 0.24 0.11 Table 3: metrics for the best model over the inference-only area. Those metrics are worse than the ones obtained over the training area. The global F1 score is still higher than for the BLM. However, the natural F1 score is not high enough. Figure 11: Absolute and relative repartition of the roads in the inference-only zone. 93.2% of the roads are correctly classified, 4.2% are in the wrong class and 2.6% are undetected or undetermined. Nearly half of the natural roads are either undetected or in the wrong class, but as they represent a tiny proportion of the dataset, they impact little the accuracy. In the training zone, only 2% of the roads are in the wrong class and 1.7% are undetected or undetermined. Figure 12: Reliability curves for the training and the inference-only zone. The artificial index can be used as confidence score for the artificial roads. The natural index can be used as confidence score for the natural ones. Indeed, the accuracy of the results for each class increases with their value.","title":"5.2. Results"},{"location":"PROJ-ROADSURF/#53-discussion","text":"The F1 score obtained is 0.86 over the area to train and validate the model and 0.60 over the rest of the AOI. The difference is essentially due to the decrease in the F1 score of the natural roads, passing from 0.74 to 0.24. The first intuition is that we were facing a case of overfitting. However, the validation loss was controlled in order to stop the training on time and avoid this problem. Another possibility would be that the two zones differ significantly and that a model trained on one cannot apply on the other. Hence, we also split the tiles randomly between the training and the inference-only zone. The gap between the balanced F1 score of the training and inference-only zone passed from 0.25 to 0.19 with the same hyper-parameters. The high recall for artificial roads indicates that the model properly detects them. However, once the artificial recall is high, the high artificial precision is in this case necessarily due. As the roads have a known location, the false positives not due to a class confusion are eliminated from our assessment. Then, only the roads classified in the wrong class can affect precision. As there are not a lot of natural roads, even if they were all wrongly classified as artificial like in the BLM, the precision would still remain well at 0.97. In the current case, the precision of the trained model is 0.01 higher than the one of the BLM. The drop in the natural F1 score is due to all the roads predicted in the wrong class. As they are only a few natural roads, errors of the model affect them more heavily. The part of the misclassified road increased by 44% between the training and the inference-only zone. Meanwhile, the part of undetermined roads only increased by 1% The F1 score could maybe be further improved by focusing more strictly on the 3m roads. Indeed, we considered it would be safer to teach the algorithm to differentiate only between surfaces and not between road types, which are defined by width. Therefore, the tiles were selected because they intersected 3m roads, but then all the roads on the tiles were transformed into labels. Because of the rarity of 3m natural roads, most of the natural roads seen by the algorithm are 2m roads and those often have a surface with grass, where the 3m natural roads have a surface made only of gravel or dirt. Over the training zone, 110 natural roads are 3m ones and 1183 ones are 2 m and 1 m paths. Maybe, labelling only the 3m roads would give better results than labelling all the visible roads. We did not tune the hyperparameter used by the deep learning model once we found a satisfying enough combination. In addition, as the algorithm is based on detectron2, not everything can easily be tuned. Using an entirely new framework and tuning the loss weights would allow better handling the class imbalance. A new framework could also allow integrating an attention mask and take advantage of the known road location like recommended by Epel (2018) 15 . Using a new framework could also allow to use images with 4 bands and integrating the NIR. However, we decided here to first try the tools we already had in our team. We can say that there is a bias in the model encouraging it to predict artificial roads. However, it is still better than the BLM. Therefore, this model is adapted for its purpose.","title":"5.3. Discussion"},{"location":"PROJ-ROADSURF/#6-conclusion","text":"Keeping the swissTLM3D dataset up to date is a time consuming and methodical task. This project aimed at finding a method to automatize the determination of the road surface type (artificial vs. natural). We focused on roads belonging to the \"3m Strasse\" class and discovered that statistics stemming from pixel values are not enough discriminating to tell artificial roads from natural ones. Therefore, we decided not to attempt any supervised classification based on machine learning. Instead, deep learning methods are performed. With 93% of the roads classified correctly, this method gave better results in regard to the global F1 score than a baseline model classifying all the roads as artificial. However, the model classifies 4.2% of the roads in the wrong class and has difficulties performing new zones. To ensure the quality of the swissTLM3D product, we advise to first perform a classification with the algorithm, then to check roads with a low class index or a change in surface type compared to the previous version years. It could represent a huge time saver for the operators who currently classify and check a second time all the roads. Despite our investigations, we could not find the cause of the gap between the metrics for the training and the inference-only zone. Further investigation is needed. The next step for this project would be to extend the algorithm to paths of 1 to 2 m wide. The natural roads of 3 m are mostly made of gravel, which strongly resembles asphalt, while natural paths are mostly made of dirt and can grow grass. Therefore, when mixing the two road width classes in one model, the natural roads of 3 m could be too difficult to distinguish from artificial roads and end up neglected.","title":"6. Conclusion"},{"location":"PROJ-ROADSURF/#7-references","text":"Office f\u00e9d\u00e9ral de la statistique. Longueur des routes en 2020 | Office f\u00e9d\u00e9ral de la statistique. https://www.bfs.admin.ch/news/fr/2020-0273, November 2020. \u21a9 swisstopo. swissTLM3D. https://www.swisstopo.admin.ch/de/geodata/landscape/tlm3d.html. \u21a9 \u21a9 Lushan Cheng, Xu Zhang, and Jie Shen. Road surface condition classification using deep learning. Journal of Visual Communication and Image Representation , 64:102638, October 2019. doi:10.1016/j.jvcir.2019.102638 . \u21a9 Susi Marianingsih, Fitri Utaminingrum, and Fitra Abdurrachman Bachtiar. Road Surface Types Classification Using Combination of K-Nearest Neighbor and Na\u00efve Bayes Based on GLCM. International Journal of Advanced Software Computer Application , 11(2):15\u201327, 2019. \u21a9 Marcus Nolte, Nikita Kister, and Markus Maurer. Assessment of Deep Convolutional Neural Networks for Road Surface Classification. In 2018 21st International Conference on Intelligent Transportation Systems (ITSC) , 381\u2013386. Maui, HI, November 2018. IEEE. doi:10.1109/ITSC.2018.8569396 . \u21a9 Viktor Slavkovikj, Steven Verstockt, Wesley De Neve, Sofie Van Hoecke, and Rik Van De Walle. Image-Based Road Type Classification. In 2014 22nd International Conference on Pattern Recognition , 2359\u20132364. Stockholm, August 2014. IEEE. doi:10.1109/ICPR.2014.409 . \u21a9 Mohammad Mansourmoghaddam, Hamid Reza Ghafarian Malamiri, Fahime Arabi Aliabad, Mehdi Fallah Tafti, Mohamadreza Haghani, and Saeed Shojaei. The Separation of the Unpaved Roads and Prioritization of Paving These Roads Using UAV Images. Air, Soil and Water Research , 15:117862212210862, January 2022. doi:10.1177/11786221221086285 . \u21a9 Hailing Zhou, Hui Kong, Lei Wei, Douglas Creighton, and Saeid Nahavandi. On Detecting Road Regions in a Single UAV Image. IEEE Transactions on Intelligent Transportation Systems , 18(7):1713\u20131722, July 2017. doi:10.1109/TITS.2016.2622280 . \u21a9 swisstopo. SWISSIMAGE RS. https://www.swisstopo.admin.ch/fr/geodata/images/ortho/swissimage-rs.html. \u21a9 TiTiler. https://developmentseed.org/titiler/. \u21a9 Vincent Sarago, Sean Harkins, and Drew Bollinger. Developmentseed / mosaicjson-spec. https://github.com/developmentseed/mosaicjson-spec, 2021. \u21a9 Yongquan Zhao and Zhe Zhu. ASI: An artificial surface Index for Landsat 8 imagery. International Journal of Applied Earth Observation and Geoinformation , 107:102703, March 2022. doi:10.1016/j.jag.2022.102703 . \u21a9 Ronald C. Estoque and Yuji Murayama. Classification and change detection of built-up lands from Landsat-7 ETM+ and Landsat-8 OLI/TIRS imageries: A comparative assessment of various spectral indices. Ecological Indicators , 56:205\u2013217, September 2015. doi:10.1016/j.ecolind.2015.03.037 . \u21a9 \u21a9 Swiss Territorial Data Lab. Object detector. February 2023. URL: https://github.com/swiss-territorial-data-lab/object-detector . \u21a9 Sagi Eppel. Classifying a specific image region using convolutional nets with an ROI mask as input. December 2018. arXiv:1812.00291 . \u21a9","title":"7. References"},{"location":"PROJ-TGLN/","text":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau \u00b6 Adrian Meyer (FHNW) Contributions to Background & Agricultural Law: Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGOBJ March 2021 to June 2021 - Published on July 7, 2021 Abstract : The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. 1 Introduction \u00b6 1.1 Background \u00b6 Switzerland's direct payment system is the basis for sustainable, market-oriented agriculture. The federal government supports local farms in the form of various types of contributions and enables farming families to claim an adequate income. (cf. Art. 104 BV) In the years 2014-2017 a new agricultural policy system was introduced in Switzerland. With specialized direct payment subsidies named \u00abLandscape Quality Contributions\u00bb (\u00abLQ\u00bb, Landschaftsqualit\u00e4tsbeitr\u00e4ge in German, Contributions \u00e0 la qualit\u00e9 du paysage in French) farms and agricultural businesses can be awarded for complying with measures that aim at increasing biodiversity and maintaining extensively cultivated open grasslands. Subsidies are calculated by area and the agricultural offices of the respective cantonal administration have to constantly monitor the landscape status as well as the compliance of the business operations in order to approve the requested amounts. Only certain land usage profiles are eligible for subsidies payment. According to Art. 104 \u00a71 BV, the agricultural sector, for its part, has to make a substantial decisive contribution to: Secure the supply of the population with goods and aliments. Preserve of the natural foundations of life and maintain the cultural landscape. Allow decentralized settlement throughout the territorial area. In order to be able to claim direct payments, farms are subject to various conditions. The Cultivable agricultural area layer (\u00abLN\u00bb, from German Landwirtschaftliche Nutzfl\u00e4che) is a GIS product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of contributions. (cf. Art. 35 DZV). The registration and adjustment of the LN is part of the periodic update (\u00abPNF\u00bb, Periodische Nachf\u00fchrung) within the framework of the official cadastral survey (\u00abAV\u00bb, Amtliche Vermessung) and is usually carried out every 6 years (Gamma 2021). Its correct determination is of immense importance, because if the LN area derived from the cadastral survey data deviates from the actual conditions on site, incorrect contribution amounts may be paid out (swisstopo/BLW/BUWAL 2000). Farm areas that are not eligible for contributions, in particular areas that are not usable for effective agriculture such as farmyards or storage areas (e.g. for silage hay bales), are constantly changing due to the high degree of mechanization in agriculture and often fall within the perimeter of the LN. The tracking of these areas with conventional surveying such as repeated field visits or the visual interpretation of current aerial imagery proves to be very time-consuming and costly. Possible alternative approaches are searched for in the context of this use case project. Artificial neural networks based on Deep Learning (DL) have been used for automated detection and classification of image features for quite some time. Reliable detection from aerial imagery using applications of DL would enable cost-effective detection of uneligible areas and provide added value to agricultural offices in all cantons. The Swiss Territorial Data Lab (STDL) is a project of co-creation and a space of experimentation which aims to solve concrete problems of public administrations by using data science applied to geodata. These characteristics make it the perfect environment to conduct this project. Research in the agricultural domain was already lead by project's partners at Fachhochschule Nordwestschweiz (FHNW) using machine learning. Furthermore, students are regularly involved in these projects, for example to automatically define the agricultural cultivation boundaries in collaboration with the Canton of Thurgau. 1.2 Silage Bales \u00b6 Photo of wrapped and stacked silage hay bales (Source Wikimedia). One of several features of interest specifically excluded from the subsidized cultivable LN area are silage hay bales. These bales are processed and compacted fermenting grass cuttings wrapped in plastic foil. They often roughly measure 1 - 2 cubic meters in volume and are weighed in at around 900kg. They are mainly used as animal food during winter when no fresh hay is available. Farmers are encouraged to compactly (\u00abdiscretely\u00bb) stack them in regular piles at few locations rather than keeping them in scattered collections consuming large areas. The agricultural office can assess the silage bale stack locations and sizes in order to approve the application for subsidies, since areas where silage bales are stored do not count into the cultivable LN area. Farmers can specify those areas where they must not receive contributions for in a specialized webGIS system by digitizing them manually with the attribute \u00abcode 898\u00bb. For validation purposes specialists are manually evaluating aerial imagery and conduct field visits. The process of aerial imagery evaluation is arduous and monotonous and could therefore greatly profit from automatization. The agricultural office of the Canton of Thurgau (LWA) requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area. The delivered dataset should be compatible with their webGIS workflow and should be made available with new aquisitions of aerial imaging campaigns. Having such detections readily available would reduce the workload of the responsible official by directing the monitoring to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. This project therefore aims at the development of an efficient silage bale detection algorithm which offers a highly accurate performance and can be quickly deployed over imaged areas as large as the complete canton of Thurgau (approx. 992 km\u00b2). 2 Method \u00b6 2.1 Overview \u00b6 Sileage bale stacks are clearly visible on the newest 2019 layer of the 10cm Swissimage orthophoto provided by Swisstopo. A few hundred of these stacks were manually digitized as vector polygons with QGIS in a semi-automatic approach. Following the structure of the STDL Object Detection Framework, an Area of Interest (AoI) was defined (most of the cantonal area of Thurgau) and tiled into smaller quadratic images (tiles). Those tiles containing an intersecting overlap with an annotation were subsequently fed to a neural object detection network for training in a process known as Transfer Learning. A random portion of the dataset was kept aside from the training process in order to allow an unbiased evaluation of the detector performance. Multiple iterations were performed in order to find out near-optimal input parameters such as tile size, zoom level, or network- and training-specific variables termed \u00abhyperparameters\u00bb. All detector models were evaluated for their prediction perforwmance on the reserved test dataset. The best model was chosen by means of its optimal overall performance. This model was used in turn to perform a prediction operation (\u00abInference\u00bb) on all tiles comprising the AoI \u2013 thereby detecting silage hay bale stacks over the whole canton of Thurgau. Postprocessing included filtering the resulting polygons by a high confidence score threshold provided by the detector for each detection in order to reduce the risk of false positive results (misidentification of an object as a silage bale stack). Subsequently adjacent polygons on seperate tiles were merged by standard vector operations. A spatial intersection with the known LN layer was performed to identify the specific areas occupied by silage stacks which should not receive contributions but potentially did in last years rolling payout. Only stacks covering more than 50m2 of LN area are considered \u00abrelevant\u00bb for the final delivery which translates to the equivalent of max. 10 CHF subsidy payment difference. For completeness, all LN-intersecting polygons of detections covering at least 20m2 are included in the finaly delivery. Filtering can be undertaken easily on the end user side by sorting the features with along a precalculated area column. 2.2 Aerial Imagery \u00b6 The prototypical implementation uses the publically available Swissimage dataset. It was last flown for Thurgau in spring 2019 and offers a maximum spatial resolution of 10cm GSD (Ground Sampling Distance) at 3 year intervals. As the direct subsidies are paid out yearly the periodicity of Swissimage in theory is insufficient for annual use. In this case the high quality imagery on the one hand can serve as a proof of concept though. On the other hand the cantons have the option to order own flight campaigns to increase the periodicity of available aerial imagery if sufficient need can shown from several relevant administrative stakeholders. For our approach aerial images need to be downloaded as small quadratic subsamples of the orthomosaic called \u00abtiles\u00bb to be used in the Deep Learning process. The used tiling grid system follows the slippy map standard with an edge length of 256 pixels and a zoom level system which is derived from a quadaratic division on a mercator-projected world map (whole world equals zoom level = 0). A zoom level = 18 in this system would roughly equal to a ground sampling distance (GSD) of 60 cm. 2.3 Labels / Annotations \u00b6 As no conducive vector dataset for silage bale locations exists in Thurgau or other sources known at this point, the annotations for this use case had to be created manually by the data scientists at STDL. A specific labeling strategy to obtain such a dataset was therefore implemented. Using Swissimage 10cm as a WMS bound basemap in QGIS, a few rural areas throughout the canton of Thurgau were selected and initially approximately 200 stacks of silage bales were manually digitized as polygons. Clearly disjunct stacks were digitized as two separate polygons. For partially visible stacks only visible parts were included. Loose collection of bales were connected into one common polygon if the distances between the single bales were not exceeding the diameter of a single bale. Ground imprints where silage bales were previously stored were not included. Also shadows on the ground were not part of the polygon. Plastic membrane rests were not included unless they seemed to cover additional bales. Most bales were of circular shape with an approximate diameter of 1.2 \u2013 1.5 m, but also smaller rectangular ones were common. Colours ranged from mostly white or green tinted over still common dark green or grey to also more exotic variants such as pink, light blue and yellow (the latter three are related to a specific cancer awareness program). Image: Example of the annotation rules. With these initial 200 annotations a preliminary detector was trained on a relatively high zoom level (18, 60cm GSD, tiling grid at about 150m) and predictions were generated over the whole cantonal area (See section \u00abTraining\u00bb for details). Subsequently, the 300 highest scoring new predictions (all above 99.5%) were checked visually in QGIS, precisely corrected and then transferred into the training dataset. Image: Example of label annotations manually drawn (left and top), as well as semiautomatically generated (right) \u2013 the pixel structure of the detector is visible in the label. All tiles containing labels were checked visually again at full zoom and missing labels were created manually. The resulting annotation dataset consists of approximately 700 silage bale stacks. Image: Positions of the Silage Bale Labels (red) within the borders of Thurgau. 2.4 Training \u00b6 Training of the model was performed with the STDL Object Detection Framework. The technology is based on a Mask RCNN architecture implemented with the High-Level API Detectron2 and the Deep Learning framework Pytorch. Parallelisation is achieved with CUDA-enabled GPUs on the High-Performance Computing cluster at the FHNW server facility in Muttenz. The Mask RCNN Backbone is formed by a ResNet-50 implementation and is accompanied by a Feature Pyramid Network (FPN). This combination of code elements results in a neural network leveraging more than 40 Mio. parameters. The dataset consists of RGB images and feature regions represented by pixel masks superimposing the imagery in the shape of the silage bale stack vectors. Training is performed iteratively by presenting subsets of the tiled dataset to modify \u00abedge weights\u00bb in the network graph. Progress is measured step by step by statistically minimizing the loss functions. Only tiles containing masks (labels) can be trained. Two smaller subsets of all label containing tiles are reserved from the training set (TRN), so a total of 70% of the trainable tiles are presented to the network for loss minimization. The validation set (VAL, 15%) and the test set (TST, 15%) also contain labels but are statistically independent from the TRN set. The VAL set is used to perform recurrent evaluation during training. Training can be stopped if the loss function on the validation set has reached a minimum since after that point further training would push the model into an overfitting scenario. The TST set serves as an unbiased reserve to evaluate the detector performance on previously \u00abunseen\u00bb, but labelled data. Tiles not containing a label yet were classified into a separate class called \u00abother\u00bb (OTH). This dataset was only used for generating predictions. Image: Dataset Split \u2013 Grey tiles are only used in prediction (OTH); they do not contain any labels during training. The colourful tiles contain labels, but are scattered relatively sparsely. Green tiles are used for training the model weights (TRN); orange tiles validate the learning progress during training to avoid overfitting (VAL) and blue tiles are reserved for unbiased post-training evaluation (TST). Multiple training runs were performed not only to optimize the network-specific variables called \u00abhyper-parameters\u00bb (such as batch size, learning rate or momentum), but also to test which zoom level (spatial resolution) would yield the best results. 2.5 Prediction and Assessment \u00b6 For the TRN, VAL and TST subset, confusion matrix counts and classification metrics calculations can be performed since they offer a comparison with the digitized \u00abground truth\u00bb. For all subsets (including the rest of the canton as OTH), predictions are generated as vectors covering those areas of a tile that the detector algorithm identifies as target objects and therefore attributes a confidence score. In case of the label containing tiles, the overlap between the predictions and the labels can be checked. Is an overlap found between a label and a prediction this detection is considered a \u00abTrue Positive\u00bb (TP). If the detector missed a label entirely this label can be considered as \u00abFalse Negative\u00bb (FN). Did the detector predict a silage bale stack that was not present in the labelled data it is considered \u00abFalse Positive\u00bb (FP). On the unlabelled OTH tiles, all detections are by definition therefore considered FP. The counting of TPs, FPs and FNs on the TST subset allows the calculation of standard metrics such as precision (user accuracy), recall (producer accuracy) and F1 score (a common overall performance metric calculated as the harmonic mean of precision and recall). The counts, as well as the metrics can be plotted as function of the minimum confidence score threshold (THR) which can be set to an acceptable percentage for a certain detection task. A low threshold should generally yield fewer FN errors, while a high threshold should yield fewer FP detections. The best performing model by means of maximum F1 score was used to perform a prediction run over the entire cantonal surface area. 2.6 Post-Processing \u00b6 In order to obtain a consistent result dataset, detections need to be postprocessed. Firstly, the confidence score threshold operation is applied. Here, a comparatively high threshold can be used for this operation. \u00abMissing\u00bb the detection of a silage bale stack (FN) is not as costly for the analysis of the resulting dataset at the agricultural office as analyzing large numbers of FP detections would be. Also missing single individual silage bales is much less problematic than missing whole large stacks. These larger stacks are typically attributed with high confidence scores though and are therefore less likely to be missed. In some cases, silage bale stacks cross the tiling grid and are therefore detected on multiple images. This results in edge artifacts along the tile boundaries intersecting detections that should be unified. For this resaon adjacent detection polygons need to merged into a single polygon. This is achieved by first buffering all detections with a 1.5m radius (about the diameter of a single bale). Then all touching polygons are dissolved into a single feature. Afterwards, negative buffering with -1.5m radius is applied to restore the original boundary. This process also leads to an edge smoothing by planing the pixel step derived vector boundary into curves. Image: Example of adjacent detection polygons that need to be unified (buffer dissolved). Curve polygons contain a high number of vertex points, which is why a simplification operation can be performed afterwards. The intersection with the LN layer required a preparation of that dataset. First, the perimeters of all LN polygons in Thurgau, stemming from the cadastre, were intersected with the layer \"LN difference\". Areas which contained the attribute \"No LN\" in the difference layer were therefore removed, areas with the attribute \"LN\" or \"To be checked\" were kept or if necessary (if not yet available) added to the LN dataset. Areas excluded by farmers from the subsidy themself (so-called \"layer code 898\") were removed from the LN polygons. The silage bale detections were now intersected (clipped) with all remaining LN areas such that only those portions of the detections remained that were present within the LN perimeter. For all these leftover detection polygons, the area is calculated and added as an attribute to the polygon. With a threshold operation all silo bale stacks with an area below 20 m2 are filtered out of the dataset in order to provide only economically relevant detections. 3 Results \u00b6 3.1 Metrics and Evaluation \u00b6 Figure: Performance of serveral detectors depending on zoom level (ground sampling distance) as measured by their maximum F1-Score. The model trained with tiles at zoom level = 19 (every pixel approx. 30cm GSD) showed the highest performance with a maximum F1 Score of 92.3%. Increasing the resolution even further by using 15 cm/px GSD did not result in a gain in overall detection performance while drastically increasing storage needs and computational load. Figure: Confusion matrix counts on the TST dataset in dependency of the minimum confidence score threshold. The detector model is performing very well on the independent TST dataset detecting the largest portion of silage bale stacks at any given confidence threshold. The number of FP reaches very low counts towards the higher end of the threshold percentage. Figure: Performance metrics on the TST dataset as a function of the minimum confidence score threshold. Precision, Recall and F1 Score all remain on very performant values throughout the threshold range. The F1 Score plateaus above 90% performance between 5% and 93% essentially allowing to choose any given threshold value to adapt the model performance to the end user needs. For delivery of the dataset a detector was subsequently used at a threshold of 96%. At this value 809 silage bale stacks were rediscovered in the TRN, TST and VAL subset. Just 10 FP detections were found in these subsets. 97 silage bale stacks were not rediscovered (FN). Hence, the model precision (user accuracy) was set at approx. 99% and the recall (hit rate, producer accuracy) was set at approx. 89%. The applied model detected a total of 2\u2019473 additional silage bale stacks over the rest of the canton of Thurgau (FP on OTH). 3.2 Examples \u00b6 Image: Raw detections (yellow) of silage bale stacks displaying very high confidence scores. Image: Raw detections (yellow) and postprocessed detections (red) \u2013 the area occupied by these silage bale stacks does not interesect with the Cultivable land (LN, green hatched). Direct subsidies are correctly paid out in this case. 3.3 Relevant Features for Delivery \u00b6 In total, 288 silage bale stack sections are placed within the subsidized LN area and exhibit an area consumption larger than 20m\u00b2. 87 silage bale stacks consume more than 50m\u00b2, 24 stacks consume more than 100m\u00b2. One has to keep in mind that many stacks only partially intersect with the LN layer. The overlap between all detected silage bale stacks over 20m\u00b2 and the LN layer amounts to 14\u2019200m\u00b2 or an estimated damage between CHF 1'420.- and CHF 2'840.- (assuming the subsidy payout ranges between CHF 10.- and CHF 20.- per 100m\u00b2). Considering only the overlap of the 87 largest stacks with the LN layer the area consumption amounts to 7\u2019900m\u00b2 or a damage between CHF 790.- and CHF 1'580.-. Image: Undeclared silage bale stack (red and yellow) that intersects with the cultivable land layer \u00abLN\u00bb (green). Image: The left side silage bale stack (red) is only touching the LN area (green). The center bottom silage bale stack is completely undeclared within the LN area. Image: Approximately half of the center silage bale stack (red) is undeclared and situated within the LN area. Image: This farm selfdeclared almost all areas needed (blue) for silage bales (red) to be excluded from direct subsidies areas (green). Pink areas are already pre-excluded by the agricultural office. Image: The intersection between the silage bale stack (red) and the LN area (green) is so minute, that it should not be found within the delivery dataset to the agricultural office. Image: Small silage bale stacks in the very left and very right of the image (yellow) are undeclared but each detection falls below the relevance threshold. 4 Discussion \u00b6 4.1 Feedback by the Agricultural Office \u00b6 The contact person at the agricultural office, Mr. T. Froehlich describes the detections as very accurate with a very low percentage of wrong detections. As a GIS product the detections layer can be used in the standard workflow in order to cross-check base datasets or to perform updates and corrections. On an economical scale the damage from misplaced sileage bale stacks in the LN areas is not negligible but also not extremely relevant. Federal annual direct agricultural subsidies of approx. 110 Mio. CHF stand in stark contrast to the estimated economical damage of maybe approx. CHF 2'000.- that misplaced silage bales might have caused for the Canton of Thurgau in 2019. Most farmers adhere to the policies and false declaration of areas followed by sanctions is extremely rare. Silage bales are therefore not the first priority when monitoring the advancements and updates considering the LN layer. Nevertheless these new detections allow the end users at the agricultural office to direct their eyes more quickly at relevant hotspots and spare them some aspects of the long and tidious manual search that was performed in the past. 4.2 Outlook \u00b6 Silage bales are by far not the only object limiting the extent of the cultivable subsidized land. A much larger area is consumed by farm yards \u2013 heterogenous spaces around the central farm buildings. Monitoring the growth of these spaces into the LN layer would greatly diminuish the manual workload at the agricultural office. As these spaces might also be detectable by a similar approach, this project will continue to investigate the potential of the STDL Object Detection Framework now into this direction. References \u00b6 Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau"},{"location":"PROJ-TGLN/#updating-the-cultivable-area-layer-of-the-agricultural-office-canton-of-thurgau","text":"Adrian Meyer (FHNW) Contributions to Background & Agricultural Law: Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGOBJ March 2021 to June 2021 - Published on July 7, 2021 Abstract : The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions.","title":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau"},{"location":"PROJ-TGLN/#1-introduction","text":"","title":"1    Introduction"},{"location":"PROJ-TGLN/#11-background","text":"Switzerland's direct payment system is the basis for sustainable, market-oriented agriculture. The federal government supports local farms in the form of various types of contributions and enables farming families to claim an adequate income. (cf. Art. 104 BV) In the years 2014-2017 a new agricultural policy system was introduced in Switzerland. With specialized direct payment subsidies named \u00abLandscape Quality Contributions\u00bb (\u00abLQ\u00bb, Landschaftsqualit\u00e4tsbeitr\u00e4ge in German, Contributions \u00e0 la qualit\u00e9 du paysage in French) farms and agricultural businesses can be awarded for complying with measures that aim at increasing biodiversity and maintaining extensively cultivated open grasslands. Subsidies are calculated by area and the agricultural offices of the respective cantonal administration have to constantly monitor the landscape status as well as the compliance of the business operations in order to approve the requested amounts. Only certain land usage profiles are eligible for subsidies payment. According to Art. 104 \u00a71 BV, the agricultural sector, for its part, has to make a substantial decisive contribution to: Secure the supply of the population with goods and aliments. Preserve of the natural foundations of life and maintain the cultural landscape. Allow decentralized settlement throughout the territorial area. In order to be able to claim direct payments, farms are subject to various conditions. The Cultivable agricultural area layer (\u00abLN\u00bb, from German Landwirtschaftliche Nutzfl\u00e4che) is a GIS product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of contributions. (cf. Art. 35 DZV). The registration and adjustment of the LN is part of the periodic update (\u00abPNF\u00bb, Periodische Nachf\u00fchrung) within the framework of the official cadastral survey (\u00abAV\u00bb, Amtliche Vermessung) and is usually carried out every 6 years (Gamma 2021). Its correct determination is of immense importance, because if the LN area derived from the cadastral survey data deviates from the actual conditions on site, incorrect contribution amounts may be paid out (swisstopo/BLW/BUWAL 2000). Farm areas that are not eligible for contributions, in particular areas that are not usable for effective agriculture such as farmyards or storage areas (e.g. for silage hay bales), are constantly changing due to the high degree of mechanization in agriculture and often fall within the perimeter of the LN. The tracking of these areas with conventional surveying such as repeated field visits or the visual interpretation of current aerial imagery proves to be very time-consuming and costly. Possible alternative approaches are searched for in the context of this use case project. Artificial neural networks based on Deep Learning (DL) have been used for automated detection and classification of image features for quite some time. Reliable detection from aerial imagery using applications of DL would enable cost-effective detection of uneligible areas and provide added value to agricultural offices in all cantons. The Swiss Territorial Data Lab (STDL) is a project of co-creation and a space of experimentation which aims to solve concrete problems of public administrations by using data science applied to geodata. These characteristics make it the perfect environment to conduct this project. Research in the agricultural domain was already lead by project's partners at Fachhochschule Nordwestschweiz (FHNW) using machine learning. Furthermore, students are regularly involved in these projects, for example to automatically define the agricultural cultivation boundaries in collaboration with the Canton of Thurgau.","title":"1.1 Background"},{"location":"PROJ-TGLN/#12-silage-bales","text":"Photo of wrapped and stacked silage hay bales (Source Wikimedia). One of several features of interest specifically excluded from the subsidized cultivable LN area are silage hay bales. These bales are processed and compacted fermenting grass cuttings wrapped in plastic foil. They often roughly measure 1 - 2 cubic meters in volume and are weighed in at around 900kg. They are mainly used as animal food during winter when no fresh hay is available. Farmers are encouraged to compactly (\u00abdiscretely\u00bb) stack them in regular piles at few locations rather than keeping them in scattered collections consuming large areas. The agricultural office can assess the silage bale stack locations and sizes in order to approve the application for subsidies, since areas where silage bales are stored do not count into the cultivable LN area. Farmers can specify those areas where they must not receive contributions for in a specialized webGIS system by digitizing them manually with the attribute \u00abcode 898\u00bb. For validation purposes specialists are manually evaluating aerial imagery and conduct field visits. The process of aerial imagery evaluation is arduous and monotonous and could therefore greatly profit from automatization. The agricultural office of the Canton of Thurgau (LWA) requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area. The delivered dataset should be compatible with their webGIS workflow and should be made available with new aquisitions of aerial imaging campaigns. Having such detections readily available would reduce the workload of the responsible official by directing the monitoring to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. This project therefore aims at the development of an efficient silage bale detection algorithm which offers a highly accurate performance and can be quickly deployed over imaged areas as large as the complete canton of Thurgau (approx. 992 km\u00b2).","title":"1.2 Silage Bales"},{"location":"PROJ-TGLN/#2-method","text":"","title":"2    Method"},{"location":"PROJ-TGLN/#21-overview","text":"Sileage bale stacks are clearly visible on the newest 2019 layer of the 10cm Swissimage orthophoto provided by Swisstopo. A few hundred of these stacks were manually digitized as vector polygons with QGIS in a semi-automatic approach. Following the structure of the STDL Object Detection Framework, an Area of Interest (AoI) was defined (most of the cantonal area of Thurgau) and tiled into smaller quadratic images (tiles). Those tiles containing an intersecting overlap with an annotation were subsequently fed to a neural object detection network for training in a process known as Transfer Learning. A random portion of the dataset was kept aside from the training process in order to allow an unbiased evaluation of the detector performance. Multiple iterations were performed in order to find out near-optimal input parameters such as tile size, zoom level, or network- and training-specific variables termed \u00abhyperparameters\u00bb. All detector models were evaluated for their prediction perforwmance on the reserved test dataset. The best model was chosen by means of its optimal overall performance. This model was used in turn to perform a prediction operation (\u00abInference\u00bb) on all tiles comprising the AoI \u2013 thereby detecting silage hay bale stacks over the whole canton of Thurgau. Postprocessing included filtering the resulting polygons by a high confidence score threshold provided by the detector for each detection in order to reduce the risk of false positive results (misidentification of an object as a silage bale stack). Subsequently adjacent polygons on seperate tiles were merged by standard vector operations. A spatial intersection with the known LN layer was performed to identify the specific areas occupied by silage stacks which should not receive contributions but potentially did in last years rolling payout. Only stacks covering more than 50m2 of LN area are considered \u00abrelevant\u00bb for the final delivery which translates to the equivalent of max. 10 CHF subsidy payment difference. For completeness, all LN-intersecting polygons of detections covering at least 20m2 are included in the finaly delivery. Filtering can be undertaken easily on the end user side by sorting the features with along a precalculated area column.","title":"2.1 Overview"},{"location":"PROJ-TGLN/#22-aerial-imagery","text":"The prototypical implementation uses the publically available Swissimage dataset. It was last flown for Thurgau in spring 2019 and offers a maximum spatial resolution of 10cm GSD (Ground Sampling Distance) at 3 year intervals. As the direct subsidies are paid out yearly the periodicity of Swissimage in theory is insufficient for annual use. In this case the high quality imagery on the one hand can serve as a proof of concept though. On the other hand the cantons have the option to order own flight campaigns to increase the periodicity of available aerial imagery if sufficient need can shown from several relevant administrative stakeholders. For our approach aerial images need to be downloaded as small quadratic subsamples of the orthomosaic called \u00abtiles\u00bb to be used in the Deep Learning process. The used tiling grid system follows the slippy map standard with an edge length of 256 pixels and a zoom level system which is derived from a quadaratic division on a mercator-projected world map (whole world equals zoom level = 0). A zoom level = 18 in this system would roughly equal to a ground sampling distance (GSD) of 60 cm.","title":"2.2 Aerial Imagery"},{"location":"PROJ-TGLN/#23-labels-annotations","text":"As no conducive vector dataset for silage bale locations exists in Thurgau or other sources known at this point, the annotations for this use case had to be created manually by the data scientists at STDL. A specific labeling strategy to obtain such a dataset was therefore implemented. Using Swissimage 10cm as a WMS bound basemap in QGIS, a few rural areas throughout the canton of Thurgau were selected and initially approximately 200 stacks of silage bales were manually digitized as polygons. Clearly disjunct stacks were digitized as two separate polygons. For partially visible stacks only visible parts were included. Loose collection of bales were connected into one common polygon if the distances between the single bales were not exceeding the diameter of a single bale. Ground imprints where silage bales were previously stored were not included. Also shadows on the ground were not part of the polygon. Plastic membrane rests were not included unless they seemed to cover additional bales. Most bales were of circular shape with an approximate diameter of 1.2 \u2013 1.5 m, but also smaller rectangular ones were common. Colours ranged from mostly white or green tinted over still common dark green or grey to also more exotic variants such as pink, light blue and yellow (the latter three are related to a specific cancer awareness program). Image: Example of the annotation rules. With these initial 200 annotations a preliminary detector was trained on a relatively high zoom level (18, 60cm GSD, tiling grid at about 150m) and predictions were generated over the whole cantonal area (See section \u00abTraining\u00bb for details). Subsequently, the 300 highest scoring new predictions (all above 99.5%) were checked visually in QGIS, precisely corrected and then transferred into the training dataset. Image: Example of label annotations manually drawn (left and top), as well as semiautomatically generated (right) \u2013 the pixel structure of the detector is visible in the label. All tiles containing labels were checked visually again at full zoom and missing labels were created manually. The resulting annotation dataset consists of approximately 700 silage bale stacks. Image: Positions of the Silage Bale Labels (red) within the borders of Thurgau.","title":"2.3 Labels / Annotations"},{"location":"PROJ-TGLN/#24-training","text":"Training of the model was performed with the STDL Object Detection Framework. The technology is based on a Mask RCNN architecture implemented with the High-Level API Detectron2 and the Deep Learning framework Pytorch. Parallelisation is achieved with CUDA-enabled GPUs on the High-Performance Computing cluster at the FHNW server facility in Muttenz. The Mask RCNN Backbone is formed by a ResNet-50 implementation and is accompanied by a Feature Pyramid Network (FPN). This combination of code elements results in a neural network leveraging more than 40 Mio. parameters. The dataset consists of RGB images and feature regions represented by pixel masks superimposing the imagery in the shape of the silage bale stack vectors. Training is performed iteratively by presenting subsets of the tiled dataset to modify \u00abedge weights\u00bb in the network graph. Progress is measured step by step by statistically minimizing the loss functions. Only tiles containing masks (labels) can be trained. Two smaller subsets of all label containing tiles are reserved from the training set (TRN), so a total of 70% of the trainable tiles are presented to the network for loss minimization. The validation set (VAL, 15%) and the test set (TST, 15%) also contain labels but are statistically independent from the TRN set. The VAL set is used to perform recurrent evaluation during training. Training can be stopped if the loss function on the validation set has reached a minimum since after that point further training would push the model into an overfitting scenario. The TST set serves as an unbiased reserve to evaluate the detector performance on previously \u00abunseen\u00bb, but labelled data. Tiles not containing a label yet were classified into a separate class called \u00abother\u00bb (OTH). This dataset was only used for generating predictions. Image: Dataset Split \u2013 Grey tiles are only used in prediction (OTH); they do not contain any labels during training. The colourful tiles contain labels, but are scattered relatively sparsely. Green tiles are used for training the model weights (TRN); orange tiles validate the learning progress during training to avoid overfitting (VAL) and blue tiles are reserved for unbiased post-training evaluation (TST). Multiple training runs were performed not only to optimize the network-specific variables called \u00abhyper-parameters\u00bb (such as batch size, learning rate or momentum), but also to test which zoom level (spatial resolution) would yield the best results.","title":"2.4 Training"},{"location":"PROJ-TGLN/#25-prediction-and-assessment","text":"For the TRN, VAL and TST subset, confusion matrix counts and classification metrics calculations can be performed since they offer a comparison with the digitized \u00abground truth\u00bb. For all subsets (including the rest of the canton as OTH), predictions are generated as vectors covering those areas of a tile that the detector algorithm identifies as target objects and therefore attributes a confidence score. In case of the label containing tiles, the overlap between the predictions and the labels can be checked. Is an overlap found between a label and a prediction this detection is considered a \u00abTrue Positive\u00bb (TP). If the detector missed a label entirely this label can be considered as \u00abFalse Negative\u00bb (FN). Did the detector predict a silage bale stack that was not present in the labelled data it is considered \u00abFalse Positive\u00bb (FP). On the unlabelled OTH tiles, all detections are by definition therefore considered FP. The counting of TPs, FPs and FNs on the TST subset allows the calculation of standard metrics such as precision (user accuracy), recall (producer accuracy) and F1 score (a common overall performance metric calculated as the harmonic mean of precision and recall). The counts, as well as the metrics can be plotted as function of the minimum confidence score threshold (THR) which can be set to an acceptable percentage for a certain detection task. A low threshold should generally yield fewer FN errors, while a high threshold should yield fewer FP detections. The best performing model by means of maximum F1 score was used to perform a prediction run over the entire cantonal surface area.","title":"2.5 Prediction and Assessment"},{"location":"PROJ-TGLN/#26-post-processing","text":"In order to obtain a consistent result dataset, detections need to be postprocessed. Firstly, the confidence score threshold operation is applied. Here, a comparatively high threshold can be used for this operation. \u00abMissing\u00bb the detection of a silage bale stack (FN) is not as costly for the analysis of the resulting dataset at the agricultural office as analyzing large numbers of FP detections would be. Also missing single individual silage bales is much less problematic than missing whole large stacks. These larger stacks are typically attributed with high confidence scores though and are therefore less likely to be missed. In some cases, silage bale stacks cross the tiling grid and are therefore detected on multiple images. This results in edge artifacts along the tile boundaries intersecting detections that should be unified. For this resaon adjacent detection polygons need to merged into a single polygon. This is achieved by first buffering all detections with a 1.5m radius (about the diameter of a single bale). Then all touching polygons are dissolved into a single feature. Afterwards, negative buffering with -1.5m radius is applied to restore the original boundary. This process also leads to an edge smoothing by planing the pixel step derived vector boundary into curves. Image: Example of adjacent detection polygons that need to be unified (buffer dissolved). Curve polygons contain a high number of vertex points, which is why a simplification operation can be performed afterwards. The intersection with the LN layer required a preparation of that dataset. First, the perimeters of all LN polygons in Thurgau, stemming from the cadastre, were intersected with the layer \"LN difference\". Areas which contained the attribute \"No LN\" in the difference layer were therefore removed, areas with the attribute \"LN\" or \"To be checked\" were kept or if necessary (if not yet available) added to the LN dataset. Areas excluded by farmers from the subsidy themself (so-called \"layer code 898\") were removed from the LN polygons. The silage bale detections were now intersected (clipped) with all remaining LN areas such that only those portions of the detections remained that were present within the LN perimeter. For all these leftover detection polygons, the area is calculated and added as an attribute to the polygon. With a threshold operation all silo bale stacks with an area below 20 m2 are filtered out of the dataset in order to provide only economically relevant detections.","title":"2.6 Post-Processing"},{"location":"PROJ-TGLN/#3-results","text":"","title":"3    Results"},{"location":"PROJ-TGLN/#31-metrics-and-evaluation","text":"Figure: Performance of serveral detectors depending on zoom level (ground sampling distance) as measured by their maximum F1-Score. The model trained with tiles at zoom level = 19 (every pixel approx. 30cm GSD) showed the highest performance with a maximum F1 Score of 92.3%. Increasing the resolution even further by using 15 cm/px GSD did not result in a gain in overall detection performance while drastically increasing storage needs and computational load. Figure: Confusion matrix counts on the TST dataset in dependency of the minimum confidence score threshold. The detector model is performing very well on the independent TST dataset detecting the largest portion of silage bale stacks at any given confidence threshold. The number of FP reaches very low counts towards the higher end of the threshold percentage. Figure: Performance metrics on the TST dataset as a function of the minimum confidence score threshold. Precision, Recall and F1 Score all remain on very performant values throughout the threshold range. The F1 Score plateaus above 90% performance between 5% and 93% essentially allowing to choose any given threshold value to adapt the model performance to the end user needs. For delivery of the dataset a detector was subsequently used at a threshold of 96%. At this value 809 silage bale stacks were rediscovered in the TRN, TST and VAL subset. Just 10 FP detections were found in these subsets. 97 silage bale stacks were not rediscovered (FN). Hence, the model precision (user accuracy) was set at approx. 99% and the recall (hit rate, producer accuracy) was set at approx. 89%. The applied model detected a total of 2\u2019473 additional silage bale stacks over the rest of the canton of Thurgau (FP on OTH).","title":"3.1 Metrics and Evaluation"},{"location":"PROJ-TGLN/#32-examples","text":"Image: Raw detections (yellow) of silage bale stacks displaying very high confidence scores. Image: Raw detections (yellow) and postprocessed detections (red) \u2013 the area occupied by these silage bale stacks does not interesect with the Cultivable land (LN, green hatched). Direct subsidies are correctly paid out in this case.","title":"3.2 Examples"},{"location":"PROJ-TGLN/#33-relevant-features-for-delivery","text":"In total, 288 silage bale stack sections are placed within the subsidized LN area and exhibit an area consumption larger than 20m\u00b2. 87 silage bale stacks consume more than 50m\u00b2, 24 stacks consume more than 100m\u00b2. One has to keep in mind that many stacks only partially intersect with the LN layer. The overlap between all detected silage bale stacks over 20m\u00b2 and the LN layer amounts to 14\u2019200m\u00b2 or an estimated damage between CHF 1'420.- and CHF 2'840.- (assuming the subsidy payout ranges between CHF 10.- and CHF 20.- per 100m\u00b2). Considering only the overlap of the 87 largest stacks with the LN layer the area consumption amounts to 7\u2019900m\u00b2 or a damage between CHF 790.- and CHF 1'580.-. Image: Undeclared silage bale stack (red and yellow) that intersects with the cultivable land layer \u00abLN\u00bb (green). Image: The left side silage bale stack (red) is only touching the LN area (green). The center bottom silage bale stack is completely undeclared within the LN area. Image: Approximately half of the center silage bale stack (red) is undeclared and situated within the LN area. Image: This farm selfdeclared almost all areas needed (blue) for silage bales (red) to be excluded from direct subsidies areas (green). Pink areas are already pre-excluded by the agricultural office. Image: The intersection between the silage bale stack (red) and the LN area (green) is so minute, that it should not be found within the delivery dataset to the agricultural office. Image: Small silage bale stacks in the very left and very right of the image (yellow) are undeclared but each detection falls below the relevance threshold.","title":"3.3 Relevant Features for Delivery"},{"location":"PROJ-TGLN/#4-discussion","text":"","title":"4    Discussion"},{"location":"PROJ-TGLN/#41-feedback-by-the-agricultural-office","text":"The contact person at the agricultural office, Mr. T. Froehlich describes the detections as very accurate with a very low percentage of wrong detections. As a GIS product the detections layer can be used in the standard workflow in order to cross-check base datasets or to perform updates and corrections. On an economical scale the damage from misplaced sileage bale stacks in the LN areas is not negligible but also not extremely relevant. Federal annual direct agricultural subsidies of approx. 110 Mio. CHF stand in stark contrast to the estimated economical damage of maybe approx. CHF 2'000.- that misplaced silage bales might have caused for the Canton of Thurgau in 2019. Most farmers adhere to the policies and false declaration of areas followed by sanctions is extremely rare. Silage bales are therefore not the first priority when monitoring the advancements and updates considering the LN layer. Nevertheless these new detections allow the end users at the agricultural office to direct their eyes more quickly at relevant hotspots and spare them some aspects of the long and tidious manual search that was performed in the past.","title":"4.1 Feedback by the Agricultural Office"},{"location":"PROJ-TGLN/#42-outlook","text":"Silage bales are by far not the only object limiting the extent of the cultivable subsidized land. A much larger area is consumed by farm yards \u2013 heterogenous spaces around the central farm buildings. Monitoring the growth of these spaces into the LN layer would greatly diminuish the manual workload at the agricultural office. As these spaces might also be detectable by a similar approach, this project will continue to investigate the potential of the STDL Object Detection Framework now into this direction.","title":"4.2 Outlook"},{"location":"PROJ-TGLN/#references","text":"Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"References"},{"location":"PROJ-TGPOOL/","text":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU \u00b6 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL January 2021 to April 2021 - Published on April 21, 2021 Abstract : The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Introduction \u00b6 Until February 2021 the Swiss Territorial Data Lab developed an approach based on Mask RCNN Deep Learning algorithms for the detection of objects on aerial images, with swimming pools serving as a demonstration object. The official cadastres of the Canton of Thurgau include \u2013 among many other objects \u2013 the registration of larger private swimming pools that are permanently anchored in the ground. The challenge is to keep the cadastre up to date on a regular basis which is usually done manually by surveying or verification with aerial imagery. Because the Canton of Thurgau (unlike the Canton of Geneva) does not maintain an own specific register of swimming pools, this study primarily serves as a technology demonstration. A secondary goal encompasses detailed knowledge transfer from the data scientist team at the STDL to the cantonal authorities such as providing insight and interpretation guidance into the performance metrics and raising awareness for the prerequisites of the detector framework. Methodology \u00b6 Process Overview \u00b6 Generating a Model from Cadastral Vectors and Aerial Images to Predict Objects in the Same or a New Area of Interest (AoI). The STDL object detection framework is based on a bipartite approach of training and inference. This means that a predictive model is statistically adapted to known and verified data (\"training\") in order to then generate classification predictions on new, unknown data (\"inference\"). To achieve this we resample large high-resolution orthophoto mosaics by decomposing them into small square image tiles on which vectorized annotations of swimming pools are drawn. Verified vector annotation data (\"ground truth\") for the training process was available for the cantonal area of Geneva, as well as for a smaller part of the cantonal area of Neuch\u00e2tel covering a total of almost 5'000 swimming pools present in 2019. The predictive model used is a convolutional neural network developed for computer vision (Mask RCNN). It was trained on a high performance computing cluster at the University of Applied Sciences Northwestern Switzerland FHNW using the open source Detectron2 object detection library. During inference, pixel-precise vector contours (\u201csegments\u201d) are produced over the tiled imagery of the canton of Thurgau. Each segment is attributed a confidence score which indicates the certainty of the detections when applied to new data. Using this score as a threshold level, performance metrics are computed in post-classification assessment. Ground Truth Dataset \u00b6 Label annotations are derived from cadastral data and manually curated Vector ground truth annotations demarcating private swimming pools were available at two locations: A near-complete coverage of the cantonal area of Geneva which contains 4\u2019652 known objects, as well as a smaller subsection of the cantonal area of Neuchatel which contains 227 known objects. Label annotations in both cases are derived from cadastral surface vector datasets and then manually curated/verified. In case of the Geneva dataset the manual verification was performed by STDL data scientists in a previous study; in case of the Neuchatel dataset the manual verification was performed by the local cadastre experts. Reference Data and Area of Interest \u00b6 Approximately 5000 cross checked swimming pool annotations are available as vectorized shapes in the Cantons of Geneva and partially in Neuch\u00e2tel. They are compatible with orthophotos from 2018/19 such as the latest SWISSIMAGE 10cm layer. The Area of Interest (AoI) for all tests conducted in this study are divided into two main sections: Those areas in Geneva and Neuchatel containing vectorized ground truth labels are used as \u201cTraining AoI\u201d. The cantonal area of Thurgau is used as \u201cPrediction AoI\u201d. Only those parts of the cantonal surface of Thurgau are used as Prediction AoI which are designated as relevant settlement areas. For this purpose the STDL has received two additional reference datasets from the canton of Thurgau: Vector layer: List of all water basins from the official survey; 3'131 objects. Vector layer: Settlement areas / construction zones to delimit the study area. 2,895 objects from the water basin layer are located wholly or partially within the \u201cPrediction AoI\u201d. Only these objects were used for analysis (see Figure 4, light green objects). For each grid square, an image file with 256x256 pixels edge length and 60cm GSD was generated by WMS. Metadata and georeferencing were stored in an associated JSON. A quick qualitative review of the Thurgau datasets in QGIS revealed two limitations of the datasets. About 7,5% of the water basins are not located in the selected settlement area (e.g., on remote farmsteads or mixed industrial / commercial zones), so no detection attempt was initially undertaken for areas encompassing these objects. It is important to note that there are some objects in the water basin layer that are not comparable to private swimming pools in shape or size, such as public large scale swimming pools, but also sewage treatment plants, silos, tanks, reservoirs, or retention dams. By limiting the Prediction AoI to residential areas and adjacent land, the largest portion of these objects could be excluded. Example of a water treatment plant that appears in the \u201cwater basin layer\u201d and had to be excluded by limiting the \u201cPrediction AoI\u201d to residential and adjacent areas. To additionally calculate metrics on the quality of this reference dataset vs. the quality of the detections a small area over the city of Frauenfeld (Thurgau) containing approximately 100 swimming pools was manually curated and verified by the STDL data scientists. Orthocorrected Imagery \u00b6 Orthoimagery tiles of 150m/256px edge length containing labelled annotations Both AoIs are split by a regular checkerboard segmentation grid into squares (\u201ctiles\u201d), making use of the \u201cSlippy Map Tiles\u201d quadtree-style system. The image data used here was tested with different zoom level resampling resolutions (Ground Sampling Distance, GSD) between 30 cm and 480 cm edge length per pixel while maintaining a consistent extent of 256x256 pixels. Query of the imagery was undertaken using public web map services such using common protocols such as WMS or the MIL standard. Three separate imagery sources were used over the course of the study. The 10cm GSD RGB orthophotomosaic layer SWISSIMAGE of Swisstopo was the primary target of investigation as it was used as the basis of prediction generation over the cantonal area of Thurgau. SWISSIMAGE was also used as the imagery basis for most of the training test runs over the ground truth areas of Geneva and Neuchatel. Additionally, a model was trained leveraging combined cantonal orthophoto imagery from Geneva (SITG) and Neuchatel (SITN) to comparatively test the prediction performance of such a model on the unrelated SWISSIMAGE inference dataset in Thurgau. As it was known from the STDL\u2019s previous work, that the usage of tiles exhibiting a GSD of ~60cm/Px (tile zoom level 18) offered a decent tradeoff between reaching high accuracies during training while keeping computational effort manageable this approach was used for the test using the own cantonal imagery of Geneva and Neuchatel. Using SWISSIMAGE for training, zoom levels in a range between 15 (~480 cm/Px) and 19 (~30 cm/Px) were tested. Training \u00b6 Transfer Learning \u00b6 The choice of a relevant predictive approach fell on a \u201cCOCO-pretrained\u201d deep learning model of the type \"ResNet 50 FPN\" structured in a \u201cMask-RCNN\u201d architecture and implemented with Python and the Detectron2 API. In a transfer learning process about 44 million trainable statistical parameters are adapted (\u201cfinetuned\u201d) as edge weights in a pretrained neural network graph through a number of iterations trying to minimize the value of the so-called \u201closs function\u201d (which is a primary measure for inaccuracy in classification). Transfer Learning is common practice with Deep Learning models. The acquired knowledge gained from massive datasets allows an adaptation of the model to smaller new datasets. Training is performed through highly multithreaded GPU parallelisation of the necessary tensor / matrix operations to speed up training duration. For this purpose the vector annotations are converted into pixel-per-pixel binary masks which are aligned with the respective input image. Network- or Training-specific pre-set variables (\u201chyperparameters\u201d) such as learning rate, learning rate decay, optimizer momentum, batch size or weight decay were either used in their standard configuration or iteratively manually tuned until comparatively high accuracies (e.g. by means of the F1-Score) could be reached. More systematic approaches such as hyperparameter grid search or advanced (e.g. Bayesian) optimization strategies could be implemented in follow-up studies. Dataset Split \u00b6 Tiles falling into the \u201cTraining AoI\u201d but not exhibiting any intersecting area with the Ground Truth Labels are discarded. The remaining ground truth tile datasets are randomly sampled into three disjunct subsets: The \u201cTraining Subset\u201d consists of 70% of the ground truth tiles and is used to change the network graph edge weights. The \u201cValidation Subset\u201d consists of another 15% of the ground truth tiles and is used to validate the generalization performance of the network during training. The iteration cycling is stopped when the loss on the validation dataset is minimized. The \u201cTest Subset\u201d consists of the last 15% of the ground truth tiles and is entirely reserved from the training process to allow for independent and unbiased assessment in the post processing. Subdivision of Ground Truth Datasets Inference and Assessment \u00b6 After training, tile by tile the entire \u201cPrediction AoI\u201d as well as the ground truth datasets presented to the final model for prediction generation. From a minimum confidence threshold up to 100% the model produces a segmentation mask for each swimming pool detection delimiting its proposed outer boundary. This boundary can be vectorized and transformed back from image space into map coordinates during post-processing. Through this process we can accumulate a consistent GIS-compatible vector layer for visualization, counting and further analysis. In case of the ground truth data the resulting vector layer can be intersected with the original input data (especially the \u201cTest Subset\u201d) to obtain unbiased model performance metrics. In case of a well-performing model the resulting vector layer can then be intersected with the \u201cPrediction AoI\u201d-derived Thurgau dataset to identify missing or surplus swimming pools in the cadastre. Results \u00b6 Metrics and Model Selection \u00b6 Results of different training runs using SWISSIMAGE depending on the chosen zoom level The choice of a correct confidence threshold (\"THR\") is of central importance for the interpretation of the results. The division of a data set into true/false positives/negatives is a function of the confidence threshold. A high threshold means that the model is very confident of a detection; a low threshold means that as few detections as possible should be missed, but at the same time more false positive (\"FP\") detections should be triggered. Results of different training runs using SWISSIMAGE depending on the chosen zoom level There are several standardized metrics to evaluate model performance on unknown data. The most important are \"Precision\" (user accuracy), \"Recall\" (hit rate or producer accuracy) and \"F1 Score\" (the mathematical harmonic mean of the other two). \"Precision\" should increase with higher THR, \"Recall\" should decrease. The maximum F1 Score can be used as a measure of how well the model performs regardless of the viewing direction. Results of different training runs using SWISSIMAGE depending on the chosen zoom level Using the cantonal orthomosaics as training input with zoom level 18 the F1 Score reached a maximum of 81,0%. Using SWISSIMAGE as training input with zoom level 18 a slightly higher maximum F1 Score of 83,4% was achieved resulting in the choice of a \u201conly SWISSIMAGE\u201d approach for both, training and inference. The best detection by means of maximum F1 Score was reached using tiles with zoom level 19 displaying a GSD of approx. 30 cm/Px. Since the Slippy Map tile system is based on equal division of squares increasing the zoom level by one step results roughly in quadrupling the number of tiles presented for analysis. Hence also computational demand increases with an exponential factor in particular for file system read/write and sequential processing operations if the zoom level is increased. On the other hand increasing the zoom level (and therefor the GSD) also boosts visibility and size of the target objects which in turn increases detection accuracy. Comparatively slight increases in F1 Score between zoom levels 17, 18 and 19 suggest an asymptotic behaviour where the usage of massively higher amounts computing resources will not result in a much higher detection accuracy any longer. Zoom level 20 (GSD~15cm/Px) was not computed for this reason. True Positives \u00b6 A detection is considered \"True Positive\" (TP) if the algorithm detected a pool that was listed at the same position in the cadastral layer. Setting the threshold very low (THR \u2265 5%), 2'227 of 2\u2019959 swimming pools were detected. This corresponds to a detection proportion of 75% of the recorded water pools. Conversely, this could mean that 25% or 732 objects are False Negatives and therefore \"erroneously\" recorded in the cadastre as swimming pools or missed by the algorithm. \u201cTrue Positive\u201d detections \u2013 note that cases of empty and covered swimming pools are detected with a very high confidence threshold in this example. False Negatives \u00b6 FN describe those objects that the algorithm completely failed to detect, no matter what threshold is set. A total of 732 objects were not detected. FN easily occur when there are obvious discrepancies between orthophoto and cadastre - for example, a pool may have been constructed after the time of flight. The combined number from FN and TP corresponds to the number of analyzed labels from the water pool layer (2\u2019959 objects). Due to the splitting of pools at the segmentation grid boundaries, this value is slightly higher than the 2\u2019895 objects that were in the \u201cPrediction AoI\u201d. Here, only objects larger than 5m\u00b2 in area were counted, since the segmentation grid cuts some pools into several parts and tiny residual of only a few pixels in total area polygons might otherwise be counted as FN even though the largest part of a swimming pool was detected (and therefore counted as TP). \u201cFalse Negatives\u201d \u2013 (Left) An obvious mismatch between the cadastre and the orthophoto, an update should be considered. (Right) An ambiguous swimming pool which might be covered by a white canvas and was therefore missed by the detector. False Positives \u00b6 Swimming pools that were recognized as such in the orthophoto but are not found in the cadastre represent the FP group. If the threshold is set very low (e.g. THR \u2265 5%), a total of 9'427 additional pools would be found in the settlement area. However, this number is not realistic, since most of the detections at such a low threshold do not correspond to pools, but only mark image areas that are related to a pool in a very distant way. Therefore, to get a better estimation of objects that really represent private pools but are still missing in the cadastre, the choice of a very high threshold is recommended. For example, the geoinformation services of the Canton of Geneva work with a threshold of THR \u2265 97%. Applying this threshold, 271 unrecorded swimming pools remain in the dataset with an extremely high probability of correct redetection (9% of the cadastre). However, it is still worth looking at slightly less likely FP detections with a threshold of THR \u2265 90% here. Filtering with this value, a total of 672 unregistered swimming pools were found, which would correspond to 23% of the cadastre layer. At the same time the risk for clear errors by the object detector also increases at lower thresholds, leading to some misclassifications. \u201cFalse Positive\u201d detections \u2013 (Top) Two clear examples of detected swimming pools that are missing in the cadastre. (Bottom Left) More ambiguous examples of detected swimming pools which might be missing in the cadastre. (Bottom Right) A clear error of the detector misclassifying a photovoltaic installation as a swimming pool. Conclusion \u00b6 Manual Evaluation \u00b6 In the city of Frauenfeld a sample district was chosen for manual evaluation by a STDL data scientist. Even though this task should ideally be performed by a local expert this analysis does provide some insight on the potential errors currently existing within the cadastre as well as the object detection quality. Within the sampled area a total of 99 identifiable swimming pool objects were found to be present. Table: Manually evaluated dataset accuracy vs. detector performance comparison. Green indicates the preferred value. Overall, the STDL Detector was more accurate than the provided dataset with a F1 Score of ~90% vs. ~87%. Especially a lot fewer swimming pools (5 FN) were missing in the detections than in the cadastre (18 FN). Room for improvement exists with the False Positives, where our detector identified 16 surplus objects as potential swimming pools which could be falsified manually. At the same time only 9 surplus objects were found in the cadastre. Interpretation \u00b6 We can conclude that the use of annotation data gathered in another canton of Switzerland allows for highly accurate predictions in Thurgau using the freely and publicly available SWISSIMAGE dataset. We demonstrate that such a transferrable approach can therefore be applied within a relatively short time span to other cantons without the effort of manually digitizing objects in a new area. This is supported by the assumption that SWISSIMAGE is of the same consistent radiometrical and spatial quality we see in Thurgau over the whole country. Manual evaluation will stay paramount before authorities take for example legal action or perform updates and changes to the cadastre. Nevertheless a great amount of workload reduction can be achieved by redirecting the eyes of the experts to the detected or undetected areas that are worth looking at. References \u00b6 Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU"},{"location":"PROJ-TGPOOL/#swimming-pool-detection-for-the-canton-of-thurgau","text":"Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL January 2021 to April 2021 - Published on April 21, 2021 Abstract : The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour.","title":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU"},{"location":"PROJ-TGPOOL/#introduction","text":"Until February 2021 the Swiss Territorial Data Lab developed an approach based on Mask RCNN Deep Learning algorithms for the detection of objects on aerial images, with swimming pools serving as a demonstration object. The official cadastres of the Canton of Thurgau include \u2013 among many other objects \u2013 the registration of larger private swimming pools that are permanently anchored in the ground. The challenge is to keep the cadastre up to date on a regular basis which is usually done manually by surveying or verification with aerial imagery. Because the Canton of Thurgau (unlike the Canton of Geneva) does not maintain an own specific register of swimming pools, this study primarily serves as a technology demonstration. A secondary goal encompasses detailed knowledge transfer from the data scientist team at the STDL to the cantonal authorities such as providing insight and interpretation guidance into the performance metrics and raising awareness for the prerequisites of the detector framework.","title":"Introduction"},{"location":"PROJ-TGPOOL/#methodology","text":"","title":"Methodology"},{"location":"PROJ-TGPOOL/#process-overview","text":"Generating a Model from Cadastral Vectors and Aerial Images to Predict Objects in the Same or a New Area of Interest (AoI). The STDL object detection framework is based on a bipartite approach of training and inference. This means that a predictive model is statistically adapted to known and verified data (\"training\") in order to then generate classification predictions on new, unknown data (\"inference\"). To achieve this we resample large high-resolution orthophoto mosaics by decomposing them into small square image tiles on which vectorized annotations of swimming pools are drawn. Verified vector annotation data (\"ground truth\") for the training process was available for the cantonal area of Geneva, as well as for a smaller part of the cantonal area of Neuch\u00e2tel covering a total of almost 5'000 swimming pools present in 2019. The predictive model used is a convolutional neural network developed for computer vision (Mask RCNN). It was trained on a high performance computing cluster at the University of Applied Sciences Northwestern Switzerland FHNW using the open source Detectron2 object detection library. During inference, pixel-precise vector contours (\u201csegments\u201d) are produced over the tiled imagery of the canton of Thurgau. Each segment is attributed a confidence score which indicates the certainty of the detections when applied to new data. Using this score as a threshold level, performance metrics are computed in post-classification assessment.","title":"Process Overview"},{"location":"PROJ-TGPOOL/#ground-truth-dataset","text":"Label annotations are derived from cadastral data and manually curated Vector ground truth annotations demarcating private swimming pools were available at two locations: A near-complete coverage of the cantonal area of Geneva which contains 4\u2019652 known objects, as well as a smaller subsection of the cantonal area of Neuchatel which contains 227 known objects. Label annotations in both cases are derived from cadastral surface vector datasets and then manually curated/verified. In case of the Geneva dataset the manual verification was performed by STDL data scientists in a previous study; in case of the Neuchatel dataset the manual verification was performed by the local cadastre experts.","title":"Ground Truth Dataset"},{"location":"PROJ-TGPOOL/#reference-data-and-area-of-interest","text":"Approximately 5000 cross checked swimming pool annotations are available as vectorized shapes in the Cantons of Geneva and partially in Neuch\u00e2tel. They are compatible with orthophotos from 2018/19 such as the latest SWISSIMAGE 10cm layer. The Area of Interest (AoI) for all tests conducted in this study are divided into two main sections: Those areas in Geneva and Neuchatel containing vectorized ground truth labels are used as \u201cTraining AoI\u201d. The cantonal area of Thurgau is used as \u201cPrediction AoI\u201d. Only those parts of the cantonal surface of Thurgau are used as Prediction AoI which are designated as relevant settlement areas. For this purpose the STDL has received two additional reference datasets from the canton of Thurgau: Vector layer: List of all water basins from the official survey; 3'131 objects. Vector layer: Settlement areas / construction zones to delimit the study area. 2,895 objects from the water basin layer are located wholly or partially within the \u201cPrediction AoI\u201d. Only these objects were used for analysis (see Figure 4, light green objects). For each grid square, an image file with 256x256 pixels edge length and 60cm GSD was generated by WMS. Metadata and georeferencing were stored in an associated JSON. A quick qualitative review of the Thurgau datasets in QGIS revealed two limitations of the datasets. About 7,5% of the water basins are not located in the selected settlement area (e.g., on remote farmsteads or mixed industrial / commercial zones), so no detection attempt was initially undertaken for areas encompassing these objects. It is important to note that there are some objects in the water basin layer that are not comparable to private swimming pools in shape or size, such as public large scale swimming pools, but also sewage treatment plants, silos, tanks, reservoirs, or retention dams. By limiting the Prediction AoI to residential areas and adjacent land, the largest portion of these objects could be excluded. Example of a water treatment plant that appears in the \u201cwater basin layer\u201d and had to be excluded by limiting the \u201cPrediction AoI\u201d to residential and adjacent areas. To additionally calculate metrics on the quality of this reference dataset vs. the quality of the detections a small area over the city of Frauenfeld (Thurgau) containing approximately 100 swimming pools was manually curated and verified by the STDL data scientists.","title":"Reference Data and Area of Interest"},{"location":"PROJ-TGPOOL/#orthocorrected-imagery","text":"Orthoimagery tiles of 150m/256px edge length containing labelled annotations Both AoIs are split by a regular checkerboard segmentation grid into squares (\u201ctiles\u201d), making use of the \u201cSlippy Map Tiles\u201d quadtree-style system. The image data used here was tested with different zoom level resampling resolutions (Ground Sampling Distance, GSD) between 30 cm and 480 cm edge length per pixel while maintaining a consistent extent of 256x256 pixels. Query of the imagery was undertaken using public web map services such using common protocols such as WMS or the MIL standard. Three separate imagery sources were used over the course of the study. The 10cm GSD RGB orthophotomosaic layer SWISSIMAGE of Swisstopo was the primary target of investigation as it was used as the basis of prediction generation over the cantonal area of Thurgau. SWISSIMAGE was also used as the imagery basis for most of the training test runs over the ground truth areas of Geneva and Neuchatel. Additionally, a model was trained leveraging combined cantonal orthophoto imagery from Geneva (SITG) and Neuchatel (SITN) to comparatively test the prediction performance of such a model on the unrelated SWISSIMAGE inference dataset in Thurgau. As it was known from the STDL\u2019s previous work, that the usage of tiles exhibiting a GSD of ~60cm/Px (tile zoom level 18) offered a decent tradeoff between reaching high accuracies during training while keeping computational effort manageable this approach was used for the test using the own cantonal imagery of Geneva and Neuchatel. Using SWISSIMAGE for training, zoom levels in a range between 15 (~480 cm/Px) and 19 (~30 cm/Px) were tested.","title":"Orthocorrected Imagery"},{"location":"PROJ-TGPOOL/#training","text":"","title":"Training"},{"location":"PROJ-TGPOOL/#inference-and-assessment","text":"After training, tile by tile the entire \u201cPrediction AoI\u201d as well as the ground truth datasets presented to the final model for prediction generation. From a minimum confidence threshold up to 100% the model produces a segmentation mask for each swimming pool detection delimiting its proposed outer boundary. This boundary can be vectorized and transformed back from image space into map coordinates during post-processing. Through this process we can accumulate a consistent GIS-compatible vector layer for visualization, counting and further analysis. In case of the ground truth data the resulting vector layer can be intersected with the original input data (especially the \u201cTest Subset\u201d) to obtain unbiased model performance metrics. In case of a well-performing model the resulting vector layer can then be intersected with the \u201cPrediction AoI\u201d-derived Thurgau dataset to identify missing or surplus swimming pools in the cadastre.","title":"Inference and Assessment"},{"location":"PROJ-TGPOOL/#results","text":"","title":"Results"},{"location":"PROJ-TGPOOL/#metrics-and-model-selection","text":"Results of different training runs using SWISSIMAGE depending on the chosen zoom level The choice of a correct confidence threshold (\"THR\") is of central importance for the interpretation of the results. The division of a data set into true/false positives/negatives is a function of the confidence threshold. A high threshold means that the model is very confident of a detection; a low threshold means that as few detections as possible should be missed, but at the same time more false positive (\"FP\") detections should be triggered. Results of different training runs using SWISSIMAGE depending on the chosen zoom level There are several standardized metrics to evaluate model performance on unknown data. The most important are \"Precision\" (user accuracy), \"Recall\" (hit rate or producer accuracy) and \"F1 Score\" (the mathematical harmonic mean of the other two). \"Precision\" should increase with higher THR, \"Recall\" should decrease. The maximum F1 Score can be used as a measure of how well the model performs regardless of the viewing direction. Results of different training runs using SWISSIMAGE depending on the chosen zoom level Using the cantonal orthomosaics as training input with zoom level 18 the F1 Score reached a maximum of 81,0%. Using SWISSIMAGE as training input with zoom level 18 a slightly higher maximum F1 Score of 83,4% was achieved resulting in the choice of a \u201conly SWISSIMAGE\u201d approach for both, training and inference. The best detection by means of maximum F1 Score was reached using tiles with zoom level 19 displaying a GSD of approx. 30 cm/Px. Since the Slippy Map tile system is based on equal division of squares increasing the zoom level by one step results roughly in quadrupling the number of tiles presented for analysis. Hence also computational demand increases with an exponential factor in particular for file system read/write and sequential processing operations if the zoom level is increased. On the other hand increasing the zoom level (and therefor the GSD) also boosts visibility and size of the target objects which in turn increases detection accuracy. Comparatively slight increases in F1 Score between zoom levels 17, 18 and 19 suggest an asymptotic behaviour where the usage of massively higher amounts computing resources will not result in a much higher detection accuracy any longer. Zoom level 20 (GSD~15cm/Px) was not computed for this reason.","title":"Metrics and Model Selection"},{"location":"PROJ-TGPOOL/#true-positives","text":"A detection is considered \"True Positive\" (TP) if the algorithm detected a pool that was listed at the same position in the cadastral layer. Setting the threshold very low (THR \u2265 5%), 2'227 of 2\u2019959 swimming pools were detected. This corresponds to a detection proportion of 75% of the recorded water pools. Conversely, this could mean that 25% or 732 objects are False Negatives and therefore \"erroneously\" recorded in the cadastre as swimming pools or missed by the algorithm. \u201cTrue Positive\u201d detections \u2013 note that cases of empty and covered swimming pools are detected with a very high confidence threshold in this example.","title":"True Positives"},{"location":"PROJ-TGPOOL/#false-negatives","text":"FN describe those objects that the algorithm completely failed to detect, no matter what threshold is set. A total of 732 objects were not detected. FN easily occur when there are obvious discrepancies between orthophoto and cadastre - for example, a pool may have been constructed after the time of flight. The combined number from FN and TP corresponds to the number of analyzed labels from the water pool layer (2\u2019959 objects). Due to the splitting of pools at the segmentation grid boundaries, this value is slightly higher than the 2\u2019895 objects that were in the \u201cPrediction AoI\u201d. Here, only objects larger than 5m\u00b2 in area were counted, since the segmentation grid cuts some pools into several parts and tiny residual of only a few pixels in total area polygons might otherwise be counted as FN even though the largest part of a swimming pool was detected (and therefore counted as TP). \u201cFalse Negatives\u201d \u2013 (Left) An obvious mismatch between the cadastre and the orthophoto, an update should be considered. (Right) An ambiguous swimming pool which might be covered by a white canvas and was therefore missed by the detector.","title":"False Negatives"},{"location":"PROJ-TGPOOL/#false-positives","text":"Swimming pools that were recognized as such in the orthophoto but are not found in the cadastre represent the FP group. If the threshold is set very low (e.g. THR \u2265 5%), a total of 9'427 additional pools would be found in the settlement area. However, this number is not realistic, since most of the detections at such a low threshold do not correspond to pools, but only mark image areas that are related to a pool in a very distant way. Therefore, to get a better estimation of objects that really represent private pools but are still missing in the cadastre, the choice of a very high threshold is recommended. For example, the geoinformation services of the Canton of Geneva work with a threshold of THR \u2265 97%. Applying this threshold, 271 unrecorded swimming pools remain in the dataset with an extremely high probability of correct redetection (9% of the cadastre). However, it is still worth looking at slightly less likely FP detections with a threshold of THR \u2265 90% here. Filtering with this value, a total of 672 unregistered swimming pools were found, which would correspond to 23% of the cadastre layer. At the same time the risk for clear errors by the object detector also increases at lower thresholds, leading to some misclassifications. \u201cFalse Positive\u201d detections \u2013 (Top) Two clear examples of detected swimming pools that are missing in the cadastre. (Bottom Left) More ambiguous examples of detected swimming pools which might be missing in the cadastre. (Bottom Right) A clear error of the detector misclassifying a photovoltaic installation as a swimming pool.","title":"False Positives"},{"location":"PROJ-TGPOOL/#conclusion","text":"","title":"Conclusion"},{"location":"PROJ-TGPOOL/#manual-evaluation","text":"In the city of Frauenfeld a sample district was chosen for manual evaluation by a STDL data scientist. Even though this task should ideally be performed by a local expert this analysis does provide some insight on the potential errors currently existing within the cadastre as well as the object detection quality. Within the sampled area a total of 99 identifiable swimming pool objects were found to be present. Table: Manually evaluated dataset accuracy vs. detector performance comparison. Green indicates the preferred value. Overall, the STDL Detector was more accurate than the provided dataset with a F1 Score of ~90% vs. ~87%. Especially a lot fewer swimming pools (5 FN) were missing in the detections than in the cadastre (18 FN). Room for improvement exists with the False Positives, where our detector identified 16 surplus objects as potential swimming pools which could be falsified manually. At the same time only 9 surplus objects were found in the cadastre.","title":"Manual Evaluation"},{"location":"PROJ-TGPOOL/#interpretation","text":"We can conclude that the use of annotation data gathered in another canton of Switzerland allows for highly accurate predictions in Thurgau using the freely and publicly available SWISSIMAGE dataset. We demonstrate that such a transferrable approach can therefore be applied within a relatively short time span to other cantons without the effort of manually digitizing objects in a new area. This is supported by the assumption that SWISSIMAGE is of the same consistent radiometrical and spatial quality we see in Thurgau over the whole country. Manual evaluation will stay paramount before authorities take for example legal action or perform updates and changes to the cadastre. Nevertheless a great amount of workload reduction can be achieved by redirecting the eyes of the experts to the detected or undetected areas that are worth looking at.","title":"Interpretation"},{"location":"PROJ-TGPOOL/#references","text":"Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"References"},{"location":"PROJ-TPNL/","text":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Supervision : Roxane Pott (swisstopo) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL July 2021 to February 2022 - Published on February 22, 2022 Abstract : Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Introduction \u00b6 For authorities, being able to track the deployment of renewable energy is becoming a major challenge in front of stakes of our societies. In addition, following the deployment of installations on territory is difficult, as construction permits are not sufficient evidences. Indeed, the construction permits materialize a will, but the actual deployment and its specifications can differ from paperwork to reality. In case of thermal panels, domain experts are then put in front of a major challenge, as they have to certify of the surface of solar thermal energy that is deployed and active on their territory on a regular basis. This reporting is made for politics that aim to deploy a certain amount of renewable energy, part of territories energetic politic. Mainly based on paperwork, the current survey of thermal panels deployment are affected by drawbacks. Indeed, it is currently complicated to determine whether a construction permit lead to the deployment of a thermal panel installation and if this installation is still in activity. The goal of this project is to determine if data science is able to provide new solutions for the survey of thermal energy production in order to report more accurate surface values to the politics. Research Project Specification \u00b6 In this project, the goal is to determine whether it is possible to track down thermal panels installation on territory by using aerial images and deep learning methods. The main axis are : Train a deep learning model on aerial images to detect thermal panels Assess the performances of the deep learning model Determine to which extent it is possible to link the predictions to existing domain expert database Research Project Strategy and Collaboration \u00b6 This research project was made in collaboration with the States of Neuch\u00e2tel and Geneva . Both domain experts are facing similar challenges and their needs are nearly identical, despite their current processes differs. For each collaboration, the goals are similar, but the methodology is different. With Neuch\u00e2tel , the domain expert database is considered while with Geneva , the database is not considered. Considering the database in the collaboration with Neuch\u00e2tel lead to a much larger amount of work, as the database need to be pre-processed before to put it into perspective of the deep learning network results. It is nevertheless important to be able to assess the possibility to insert our demonstrator in the existing procedures, that are used by domain expert to track thermal panels installations. Research Data & Selected Areas \u00b6 As mentioned, the best (and probably the only) solution to track down thermal panels is to use aerial images. Indeed, due to their nature, thermal panels are always visible on aerial images. Exceptions to this rule are unusual. In addition, aerial images are acquired regularly and a full set of orthomosaic can be easily obtained each five years (at least in Switzerland). For Geneva and Neuch\u00e2tel , it is not impossible to obtain a set of images each two years. Nevertheless, using aerial images come with drawbacks. The main one is of course resolution ( GSD ). Aerial image sets used to compose orthomosaics are acquired to cover the whole territory. It follows that the resolution is limited. For a large amount of applications, the available resolution is sufficient. But for thermal panels, the resolution starts to become challenging. Illustration of the resolution at which thermal panels can be viewed on aerial images - Data : swisstopo, SITG (GSD ~ 10 cm/pixel) Despite the resolution, aerial images are selected to train a deep learning network. Mainly SWISSIMAGE from swisstopo are considered for this research project. At the time, the 2020 version of the orthomosaic is considered for both Neuch\u00e2tel and Geneva . For both cases, a test area is defined. On the side of Neuch\u00e2tel , a large test area is chosen in order to cover a large portion of the territory that mixes constructed zones and more rural ones. On the side of Geneva , the test area is defined by the domain expert and consists of a rectangular zone. Illustration of the test areas defined on Neuch\u00e2tel (left) and Geneva (right) - Data : swisstopo The research project is then only focusing on portion of territory to keep the scale realistic for such demonstrator according to the available time. Deep Learning Model Initial Training \u00b6 In this project, it is not possible to extract a ground truth, that is annotations on aerial images, from the domain expert databases. Thankfully, the FHNW , partner of the STDL , conducted some year ago annotations for thermal panels on the States of Aargau . The set consists of thousands of annotated tiles of 80x80m in size made on the SWISSIMAGE images set ( 2020 ). The annotation work was made by students of the FHNW and supervised by the D. Jordan scientists team. Such data-set is exactly the required bootstrap data to train an initial deep learning model. The only constraint is coming from the fact that the ground truth is defined by the 80x80m wide tiles on which annotations are made. Illustration of the FHNW ground truth - Labels in white, tiles in red - Data : swisstopo, FHNW Several training sessions are conducted in order to determine which sub-tiling system lead to the best performances scores. Due to the predefined ground truth, only sub-tiles of the 80x80m original tiles are possible. As a result, 80x80m , 40x40m and 26x26m tiles are considered for the network training. In all training sessions, the results are quite stable around a F1-score of 0.8-0.85 , with always a non-negligible proportion of false positives. The best results are obtained for the smaller tiles : 26x26m . It is unfortunate as small tiles comes with drawbacks. Indeed, using small tiles impose important tiling strategy to cover a large area. In addition, using small tiles also induce larger amount of cuts that have to be merged afterwards to create a usable geographical layer. Despite these drawbacks, as a demonstrator is desired, the performances are favored. The following plot shows the precision, recall and F1-score obtained for the initial training using the data of the FHNW . These values are computed over the test set, that consists of 15% of the total data-set. Scores obtained with the FHNW ground truth - Precision, Recall and F1-score On the previous plot, the scores are all computed entity-wise and not pixel-wised. This choice is made to fit the main necessity of domain experts, which is to inventory thermal panel installations more than estimating their surfaces, which is a secondary goal. One can see that encouraging results are obtained, but one can also see that the F1-score plateau is not significantly marked, a sign that the model is not yet optimal, despite the large amount of data. As we are working with domain experts, presenting F1-score according to threshold can be challenging and difficult to understand. During other research projects, it has been clear that efforts have to be put on our side to present the performances of our tools in a way that is informative and understandable by the domain exerts, in order to ensure a working collaboration and dialog, without which, such research projects can be difficult to conduct. It is the reason why an alternate representation of the performances are introduced. It shows the performances of the neural network in a more compact and readable way, focusing on elements that are interesting for the domain experts and their real-world necessities. The proposed plot is as follows : Simplified representation used with domain experts of the obtained scores - The green area is the true positives, the yellow one is false negatives and the red on is the false positive. The upper percentage give the inventory capacity, the lower one adding the false positive to the percentage. The bar is containing three proportions : the true positives, the false negatives and the false positives. The two first proportions are grouped into one in order to represent the capacity of the network to create a reliable inventory. It shows the amount of thermal panels detected over their total amount (recall). The overall bar adds the proportion of false positive, that are seen by domain experts as pollution of the obtained inventory. Showing this proportions indicates to the domain experts, in a simple way, how usable the inventory is. Assessment and Improvement of the Model \u00b6 This section is split into two separated parts, one for the Geneva case and the other for the Neuch\u00e2tel one, as the chosen strategy is different. The case of Geneva , with a more direct approach (not considering the domain expert pre-existing database), is presented first. Case of Geneva \u00b6 In the case of Geneva , the choice is made to not consider existing databases and to proceed on detecting thermal panel installations directly on images to create an inventory that can then be assessed by the domain expert to extract reliable performance scores. Assessment by the Domain Expert \u00b6 In order to produce the predictions over the test area, in this case defined by the domain expert, the area is split into tiles with the chosen size. The tiles are then sent to the deep learning network in order to produce the predictions of thermal panel installations. The following image shows the tiling system over the test area : Illustration of the tiling system applied on the Geneva test area (26x26m tiles) A set of tiles is obtained with predictions on them. The optimal threshold, deduced from the initial training on the FHNW data-set, is used to filter the predictions over the test area of Geneva . The tiles containing no prediction are removed by an automated process. The other tiles are associated with the predictions geographical footprints that and stored in a shapefile to keep the format simple and easy to exchange with the domain expert. By defining a common language with the domain expert on how to validate the predictions, the shapefile containing the predictions are sent to the domain expert along with the aerial images on which predictions are made. The role of the domain expert is to assess the predictions to indicate, on the tiles containing at least a prediction, the true positives, the false positives and the false negatives. Illustration of the common language defined to assess the predictions - The domain expert simply puts a mark in the determined false positive and at the location of the false negative. The true positives are left untouched By assessing the prediction with a domain expert, ensure that the obtained scores are reliable, as thermal panels are difficult to identify on the aerial image for a non expert. Without assessing the predictions through a domain expert would lead to unreliable scores. Results \u00b6 The assessment of the predictions made by the domain expert lead to the following results on the test area. A total of 89 tiles are formally certified by the domain expert with the following counts : Category Count TP 47 FP 63 FN 35 On a total of 110 predictions on the certified tiles, 47 are true positives, 63 being false positives. A total of 35 missing predictions are pointed by the domain expert. It follows that 47 thermal panel installations are found over 47+35=82 . This leads to the performances score for the initial deep learning over the Geneva test area model of : Score Value Precision 0.43 Recall 0.57 F1 0.49 From the inventory point of view, nearly 60% of the thermal panel installations are found by the initial deep learning model on the test area. This is clearly below the initial model, showing that the data-set are not sufficient to obtain stable results at this stage. The following plot shows the results presented in the simplified form : Score obtained on Geneva with the initial deep learning model - Simple representation Taking into account the large amount of false positives, the initial training is clearly not at the desired level to be usable by the domain expert to produce a reliable geographical layer of thermal panel installations. But these number are important, as they are certified by a domain expert, ensuring the ground truth used to assess the prediction is reliable. Improvement of the Deep Learning Network \u00b6 With the assessment made by the domain expert, reliable scores are obtained. In addition, as predictions are marked as correct or incorrect, with addition of missing thermal panel installations on the certified tiles, it was possible to create an extension to the ground truth. Indeed, driven by the corrections of the domain expert, new annotations are made on the certified tiles, including true positives and false negatives. These annotations are made by STDL on the images used to produce the predictions. The predictions in themselves are not sufficiently reliable to be directly translated into labels, and the false negative have to be added anyway. Annotations created on the Geneva area driven by the assessment of the domain expert - The labels are in white and the certified tiles in red In the case of Geneva , the ground truth extension is made on the same images used to produce the prediction. As the number of certified tiles is low, a strategy is tested in order to improve the ground truth extension. The idea consist in looking along the time dimension. Indeed, in Switzerland , aerial images are acquired in a regular basis. It follows that a history of aerial images is available. The time range from 2000 to 2020 is then considered in terms of the available images. For each set of images, the annotation created on the 2020 image set are transferred to the older images. This process is not straightforward, as each prediction have to be checked to certify that the thermal panel installation is there on older images. In addition, each tile has to be checked individually in order to check that no older thermal panel installation was there and destroyed before 2020 . Illustration of the propagation of the ground truth along the time dimension - The image on the right illustrates the limit of the process By doing this exploration along the time dimension, it was possible to increase the ground truth extracted from the assessment procedure made by the domain expert. From only 41 tiles and 64 annotations extracted using the initial test zone on the year 2020 , 394 tiles and 623 annotations are obtained by considering the 2000 to 2020 time range for aerial images. Considering the time dimension allows to better leverage the assessment made by the domain expert, despite the procedure is time-consuming. One has to keep in mind that such process is not ideal, as the same examples are simply repeated. It has some interest as it allows showing the same examples under different condition of luminosity and orientation, which can improve the deep learning model detection ability. With this new ground truth, it was possible to re-train the initial network. This was done using both the FHNW initial ground truth and the annotations made on Geneva . The following results are obtained, shown using the simple representation : Scores obtained on Geneva with consideration of the new annotations certified by the domain expert - Simple representation This plot shows the results on the test set limited to the Geneva test area. Again, the test set contains 15% of the ground truth, and limiting it to the area of Geneva leads to only several tens of tiles. This amount of tiles is quite low to conclude on the encouraging results obtained with the extended ground truth. This is reinforced by the lack of stability already observed in the previous results. Conclusion \u00b6 It is clear that the initial deep learning model, trained with the FHNW ground truth is not satisfying for a real-world usage by domain experts. Its ability to produce an inventory is not optimal, and the amount of false positives make the produced geographical layer difficult to use. Nevertheless, reliable score are obtained and can be trusted on the Geneva area thanks to the domain expert assessment. In addition, the assessment made by the domain expert, as it also included the false negatives (at least on the considered tiles), allowed to extend the ground truth. The extension of the ground truth along the time dimension allows taking advantage of the work of the domain expert as much as possible, leading to more certified tiles. The new training allowed to improve the situation on the Geneva area quite clearly. The inventory capacity of the deep learning model went from around 60% to around 80% . The amount of false positives is also drastically reduced. These are encouraging results, but the small amount of new tiles and the multiplication of the same examples along the time dimension has to lead us to a certain care, especially due to the instabilities of the results. Case of Neuch\u00e2tel \u00b6 The case of Neuch\u00e2tel is clearly more complex than the case of Geneva . In this case, the database of the domain expert is considered in order to try to link the predictions with the entries of the existing database. This choice is made to demonstrate the ability to integrate data science technology in existing pipeline, in order to avoid creating disruptive effect. Processing and Linkage with the Domain Expert Database \u00b6 In the first stage, the domain expert database is analyzed in order to determine the best solution to link the prediction made by the deep learning model and the entries of the database. The database in itself is a simple Excel sheet, with each line corresponding to a subsidy query that goes along the construction permit. Subsidies are provided by the authorities to promote deployment of the renewable energy. This is also a reason explaining the necessity for authorities to track down the construction of thermal panel installations. The major issue with the database is the localization of the thermal panels installation. Along the years, the database being quite old, different ways of localizing the installation were used. Three different localization systems are then available : the postal addresses, the geographical coordinate and the EGID (federal building identifier). Unfortunately, these standards are mixed, and all entries are localized differently. Sometimes only one localization is available, sometimes two or three. In some cases, the different localization information are not consistent, which lead to contradictions in the installation position. For some entries, the localization information is also incorrect or only approximate, which can lead to difficulties to associate a geo-referenced prediction to an entry of the database. For these reason, lots of efforts are put on the pre-processing of the database to make the link between prediction and entries as reliable as possible. The RegBL (federal register of buildings and dwellings) is used to assess the EGID and the postal addresses and to track down contradiction. In addition, the post addresses of the State of Neuch\u00e2tel is also considered to match addresses with geographical positions for the same reason. By doing this, many potential positions are extracted for each entry of the database. This allows to assess the contradiction in order to retain the most probable and reliable localization for each entry of the database. Of course, in many cases, the assessment is quite weak as the amount of information on localization is low (this is especially the case for older installation, the new one being localized in a much more reliable manner using the EGID ). At the end of this complex and time-consuming task, almost all entries of the database are associated with a geographical position. This allows to match predictions, that are geographically localized, to the most probable entry of the database. This process is important as it allows the domain expert to not only have a geographical layer of the thermal panel installation but to have also the link with its pre-existing database. This allows to put into perspective prediction and database to track down construction and destruction of installations along the time dimension. Assessment by the Domain Expert \u00b6 After pre-processing of the domain expert database, a region of Neuch\u00e2tel state is defined. A tiling strategy is made to translate the defined area in tiles of the appropriated size according to the initial training of the deep learning model. Predictions are then made on each of the tiles. Again, the optimal threshold is selected according to the initial training to filter the predictions made on the test area. At this stage, the procedure differ from the case of Geneva . Here, tiles are not filtered based on their content of prediction or not. The database is considered, after its pre-processing, and the predictions are linked to the optimal entry according to its best localization. As a result, a set of predictions linked to a specific entry of the database is obtained. The other predictions are simply discarded for this specific assessment procedure. In order to serve as much as possible the interests of the domain expert, a specific assessment procedure is set. This is set to allow to assess the prediction on one side and to help the domain expert to correct the bad localization of the thermal panel installation in his database on the other side. The chosen approach is based on a dictionary of GeoTIFF images on which the prediction are shown and on which additional information are specified to help the domain expert to assess the localization provided by the database. Illustration of one page of the dictionary corresponding to one database entry - For each entry, such image is provided, showing information on the entry, its localization consistency and the prediction made by the model - Each image is a geo-referenced TIFF The dictionary is made of a GeoTIFF per prediction that is linked with a unique entry of the database. In addition to the prediction geometry drawn on the image, basic information on the linked database entry is provided. The optimal localization (between post addresses, coordinates or EGID) used to link the prediction and the entry of the database is also indicated to help the domain expert to understand the link. Information about the estimated quality of the localization of the thermal panel installation is also provided. This quality indicator is based on the consistency of the multiple location information (post address, coordinates and EGID). The more consistent they are, the better the localization is considered. In case of a potential bad localization, the domain expert is invited to check the entry of the database to correct the position. In parallel, a simple Excel file is set and filled by the domain expert along the procedure. It allows setting the corrected positions, when required, and to indicate if the prediction is correct and correctly linked to the database entry. This process allows setting a win-win strategy where incorrectly located installation are treated on the side of the database and the prediction is assessed for the correct localization. The procedure for the domain expert consists then only to parse a sequence of images on which all the information are shown and to fill columns in the assessment Excel sheet. This allows to assess quickly and efficiently the prediction while correcting the inconsistency in the database. Results \u00b6 Thanks to the assessment procedure, part of the predictions are certified by the domain expert. This allows to compute scores on the capacity of the initial deep learning model to compute inventory of thermal panel installations. Unfortunately, this assessment procedure does not allow the computation of the formal scores, as the false negative are not considered. This is the main drawback coming from the fact that we work in parallel with the domain expert database. On the 354 predictions linked to the database, 316 corresponds to correctly localized entries of the database. On the 316 correct entries of the database, the domain expert reported 255 visible installation. This shows that many installations, present in the database through an entry, are not visible in the reality. With these numbers, one can deduce that 61 installations are reported in the database through paper work but cannot be found in the real world. The explanation is probably complex, but this shows how difficult it is to keep a database of installation up to date with the reality. Without a formal historical analysis, it is not possible to determine what happened to these missing installation. For some of them, one needs to consider the natural cycle of life of such installations. Indeed, thermal panel have a determined lifetime and need to be replaced or decommissioned. It is also possible that for some of them, the construction permit was asked but without leading to the actual construction of a thermal panel installation. This case is expected to be less usual. Back to the score of the initial deep learning model, on the 255 visible installation, the domain expert determined that 204 are correctly detected by the model. This lead to an inventory capacity of 0.8 which remains in the initial model scores. It is interesting to observe that the initial model scores seem to hold in the case of Neuch\u00e2tel but not in the previous case of Geneva . Indeed, on Geneva , the inventory capacity drop to 0.6 . Improvement of the Deep Learning Network \u00b6 With the assessment made by the domain expert, despite false negatives are not considered, it was possible to increase the ground truth with new annotation on the test area of Neuch\u00e2tel . The procedure starts by isolating all prediction that are marked as correct (true positive) by the domain expert. A tiling system is then set to cover the entire test area with size fitting the initial choices. The certified true positive are then manually processed to create a proper annotation, as the prediction are not reliable enough. The certifications made by the domain expert are sufficiently clear for a data scientist to do this task autonomously. The last stage consist in validating the tiles containing a new annotation. This part is the most complex one, as the data scientist has to work autonomously. The tiles containing a new annotation can only be validated, and enter the ground-truth, if and only if no other ambiguous element appear in the validated tiles. If any ambiguities arise for a tile, it needs to be dropped and not considered for the ground truth. In the case of Neuch\u00e2tel a few tiles are then removed for this reason. With this procedure, 272 new annotation are added to the ground truth on 254 tiles. These annotations, as for Geneva , are certified by a domain expert, providing a reliable ground truth. With this new set of annotation, and considering the new annotation made in the case of Geneva , it is possible to conduct a new training of the deep learning model. For this last training, the full ground truth is considered, with the FHNW annotations and those coming from the domain experts of Geneva and Neuch\u00e2tel . The following plot gives an overall simple representation of the obtained results : Score obtained using all the available ground truth, including FHNW, Geneva and Neuch\u00e2tel - Simple representation On the test set, an F1-score of 0.82 is obtained, which is slightly worse that for the initial training ( 0.85 ). On the overall, one can also sees that the inventory capacity is decreased while the amount of false positive is reduced. Again, one can here sees the instabilities of the results, showing that the used data is not sufficient or not enough well suited for such task. One can see on this following plots, the simple representation of the score reduced only the Geneva and Neuch\u00e2tel areas : Score obtained restricted to the Geneva (test set) - Simple representation Score obtained restricted to the Neuch\u00e2tel (test set) - Simple representation One has to take into account that restricting the score to such area leads to very few prediction, leading to poor statistics. It is nevertheless clear that the results on the Neuch\u00e2tel restriction demonstrate the instabilities observed all along the project. On Neuch\u00e2tel , choosing a different threshold could lead to a better inventory capacity, but the fact that the threshold needs to be adapted according to the situation shows that the model was not able to generalise. It is most likely that the nature of the objects, its similarity with other objects and the resolution of the images play a central role in the lack of generalisation. As a conclusion, detecting thermal panels needs higher resolution in order for the model to be able to extract more reliable features from the object instead of relying only on the situation of the object. Conclusion \u00b6 In the case of Neuch\u00e2tel , the procedure is more complex, as the database is considered. The work on the database is time-consuming and the linkage of the predictions with the entries of the database is not straightforward, mainly due to the inconsistencies on thermal panel installation localization. In addition, considering the database lead it to be the main point of view from which the prediction are analyzed, assessed and understood. It offers a very interesting point of view as it allows assessing the synchronization between the database and the current state of the thermal panel installations deployment. Nevertheless, such point of view also introduce drawback, as it does not allow to directly assess the false negative and only part of the false positive. This lead to intermediate scores, that are more focused on the database-reality synchronization than the performances of the deep learning model. It is then clearly demonstrated that a deep learning model can be interfaced with an existing database to ensure processes continuity with the introduction of new technologies in the territory management. It shows that new methods can be introduced without requiring to abandon the previous processes, which is always complicated and undesired. On the initial deep learning model assessment, with an inventory capacity of around 0.85 (recall), one can observe a difference between Neuch\u00e2tel and Geneva . Indeed, in Geneva , the recall dropped to around 0.6 while it was more around 0.8 in the Neuch\u00e2tel case. A possible explanation is the similarity between the Aargau (used as to train the initial deep learning model) and Neuch\u00e2tel in terms of geography. The case of Geneva is more urban than these two others. This confirms the instabilities already observed and seems to indicate that thermal panels remains a complex object to detect at this stage considering the available data. Conclusion and Perspectives \u00b6 As a main conclusion, this project, performed in two stage with Geneva and Neuch\u00e2tel states, is a complex task. The nature of the object of interest is the main source of difficulty. The current available aerial images made the detection of such object possible, but the resolution of the images (GSD) makes the task very difficult. Indeed, as mentioned, the thermal panel installations visible on the image are at the limit of resolution. This forces the deep learning model to learn more with the context than with the object features themselves. To add complexity, thermal panels appear very alike electrical panels on images, leading to a major source of confusion. The fact that the deep learning model is relying more on context than on object features lead the electrical panel to be reported as a thermal one, reducing the efficiency of inventory, leading to large amount of false positive. Despite that, interesting results are obtained and cannot lead to the conclusion that inventory such object is currently impossible. It remains very challenging, but data science can already bring help in the tracking and surveillance of the thermal panel installations. The collaboration with the domain experts is here a necessity. Indeed, such installations, especially with the image resolution, are extremely complex to confirm as such (mainly due to the confusion with electrical panels and other roof elements ). Even for the domain expert, determining if a prediction is a true positive or not is challenging and time-consuming. Without the help of domain experts, data scientists are not able to tackle such problem. Another positive outcome is the demonstration that data science can be interfaced smoothly with existing processes. This is shown with the Neuch\u00e2tel case, where the predictions can instantly be linked to the entries of the pre-existing domain expert database. This eases the domain expert assessment procedure and can also participate to assess the synchronization between the database and the reality. As a final word, the obtained deep learning model is not formally able to enter the management of the territory. It is demonstrated that the nature of the object and the available data makes the model unstable from a situation to another. This shows that the current data available is not formally enough to lead to the production of a fully working prototype able to satisfy the specifications of the domain experts. Nevertheless, such model can already perform pre-processes to ease the work of domain expert in the complex task of tracking the deployment of thermal energy generators on the Swiss territory.","title":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT"},{"location":"PROJ-TPNL/#detection-of-thermal-panels-on-canton-territory-to-follow-renewable-energy-deployment","text":"Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Supervision : Roxane Pott (swisstopo) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL July 2021 to February 2022 - Published on February 22, 2022 Abstract : Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased.","title":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT"},{"location":"PROJ-TPNL/#introduction","text":"For authorities, being able to track the deployment of renewable energy is becoming a major challenge in front of stakes of our societies. In addition, following the deployment of installations on territory is difficult, as construction permits are not sufficient evidences. Indeed, the construction permits materialize a will, but the actual deployment and its specifications can differ from paperwork to reality. In case of thermal panels, domain experts are then put in front of a major challenge, as they have to certify of the surface of solar thermal energy that is deployed and active on their territory on a regular basis. This reporting is made for politics that aim to deploy a certain amount of renewable energy, part of territories energetic politic. Mainly based on paperwork, the current survey of thermal panels deployment are affected by drawbacks. Indeed, it is currently complicated to determine whether a construction permit lead to the deployment of a thermal panel installation and if this installation is still in activity. The goal of this project is to determine if data science is able to provide new solutions for the survey of thermal energy production in order to report more accurate surface values to the politics.","title":"Introduction"},{"location":"PROJ-TPNL/#research-project-specification","text":"In this project, the goal is to determine whether it is possible to track down thermal panels installation on territory by using aerial images and deep learning methods. The main axis are : Train a deep learning model on aerial images to detect thermal panels Assess the performances of the deep learning model Determine to which extent it is possible to link the predictions to existing domain expert database","title":"Research Project Specification"},{"location":"PROJ-TPNL/#research-project-strategy-and-collaboration","text":"This research project was made in collaboration with the States of Neuch\u00e2tel and Geneva . Both domain experts are facing similar challenges and their needs are nearly identical, despite their current processes differs. For each collaboration, the goals are similar, but the methodology is different. With Neuch\u00e2tel , the domain expert database is considered while with Geneva , the database is not considered. Considering the database in the collaboration with Neuch\u00e2tel lead to a much larger amount of work, as the database need to be pre-processed before to put it into perspective of the deep learning network results. It is nevertheless important to be able to assess the possibility to insert our demonstrator in the existing procedures, that are used by domain expert to track thermal panels installations.","title":"Research Project Strategy and Collaboration"},{"location":"PROJ-TPNL/#research-data-selected-areas","text":"As mentioned, the best (and probably the only) solution to track down thermal panels is to use aerial images. Indeed, due to their nature, thermal panels are always visible on aerial images. Exceptions to this rule are unusual. In addition, aerial images are acquired regularly and a full set of orthomosaic can be easily obtained each five years (at least in Switzerland). For Geneva and Neuch\u00e2tel , it is not impossible to obtain a set of images each two years. Nevertheless, using aerial images come with drawbacks. The main one is of course resolution ( GSD ). Aerial image sets used to compose orthomosaics are acquired to cover the whole territory. It follows that the resolution is limited. For a large amount of applications, the available resolution is sufficient. But for thermal panels, the resolution starts to become challenging. Illustration of the resolution at which thermal panels can be viewed on aerial images - Data : swisstopo, SITG (GSD ~ 10 cm/pixel) Despite the resolution, aerial images are selected to train a deep learning network. Mainly SWISSIMAGE from swisstopo are considered for this research project. At the time, the 2020 version of the orthomosaic is considered for both Neuch\u00e2tel and Geneva . For both cases, a test area is defined. On the side of Neuch\u00e2tel , a large test area is chosen in order to cover a large portion of the territory that mixes constructed zones and more rural ones. On the side of Geneva , the test area is defined by the domain expert and consists of a rectangular zone. Illustration of the test areas defined on Neuch\u00e2tel (left) and Geneva (right) - Data : swisstopo The research project is then only focusing on portion of territory to keep the scale realistic for such demonstrator according to the available time.","title":"Research Data &amp; Selected Areas"},{"location":"PROJ-TPNL/#deep-learning-model-initial-training","text":"In this project, it is not possible to extract a ground truth, that is annotations on aerial images, from the domain expert databases. Thankfully, the FHNW , partner of the STDL , conducted some year ago annotations for thermal panels on the States of Aargau . The set consists of thousands of annotated tiles of 80x80m in size made on the SWISSIMAGE images set ( 2020 ). The annotation work was made by students of the FHNW and supervised by the D. Jordan scientists team. Such data-set is exactly the required bootstrap data to train an initial deep learning model. The only constraint is coming from the fact that the ground truth is defined by the 80x80m wide tiles on which annotations are made. Illustration of the FHNW ground truth - Labels in white, tiles in red - Data : swisstopo, FHNW Several training sessions are conducted in order to determine which sub-tiling system lead to the best performances scores. Due to the predefined ground truth, only sub-tiles of the 80x80m original tiles are possible. As a result, 80x80m , 40x40m and 26x26m tiles are considered for the network training. In all training sessions, the results are quite stable around a F1-score of 0.8-0.85 , with always a non-negligible proportion of false positives. The best results are obtained for the smaller tiles : 26x26m . It is unfortunate as small tiles comes with drawbacks. Indeed, using small tiles impose important tiling strategy to cover a large area. In addition, using small tiles also induce larger amount of cuts that have to be merged afterwards to create a usable geographical layer. Despite these drawbacks, as a demonstrator is desired, the performances are favored. The following plot shows the precision, recall and F1-score obtained for the initial training using the data of the FHNW . These values are computed over the test set, that consists of 15% of the total data-set. Scores obtained with the FHNW ground truth - Precision, Recall and F1-score On the previous plot, the scores are all computed entity-wise and not pixel-wised. This choice is made to fit the main necessity of domain experts, which is to inventory thermal panel installations more than estimating their surfaces, which is a secondary goal. One can see that encouraging results are obtained, but one can also see that the F1-score plateau is not significantly marked, a sign that the model is not yet optimal, despite the large amount of data. As we are working with domain experts, presenting F1-score according to threshold can be challenging and difficult to understand. During other research projects, it has been clear that efforts have to be put on our side to present the performances of our tools in a way that is informative and understandable by the domain exerts, in order to ensure a working collaboration and dialog, without which, such research projects can be difficult to conduct. It is the reason why an alternate representation of the performances are introduced. It shows the performances of the neural network in a more compact and readable way, focusing on elements that are interesting for the domain experts and their real-world necessities. The proposed plot is as follows : Simplified representation used with domain experts of the obtained scores - The green area is the true positives, the yellow one is false negatives and the red on is the false positive. The upper percentage give the inventory capacity, the lower one adding the false positive to the percentage. The bar is containing three proportions : the true positives, the false negatives and the false positives. The two first proportions are grouped into one in order to represent the capacity of the network to create a reliable inventory. It shows the amount of thermal panels detected over their total amount (recall). The overall bar adds the proportion of false positive, that are seen by domain experts as pollution of the obtained inventory. Showing this proportions indicates to the domain experts, in a simple way, how usable the inventory is.","title":"Deep Learning Model Initial Training"},{"location":"PROJ-TPNL/#assessment-and-improvement-of-the-model","text":"This section is split into two separated parts, one for the Geneva case and the other for the Neuch\u00e2tel one, as the chosen strategy is different. The case of Geneva , with a more direct approach (not considering the domain expert pre-existing database), is presented first.","title":"Assessment and Improvement of the Model"},{"location":"PROJ-TPNL/#case-of-geneva","text":"In the case of Geneva , the choice is made to not consider existing databases and to proceed on detecting thermal panel installations directly on images to create an inventory that can then be assessed by the domain expert to extract reliable performance scores.","title":"Case of Geneva"},{"location":"PROJ-TPNL/#case-of-neuchatel","text":"The case of Neuch\u00e2tel is clearly more complex than the case of Geneva . In this case, the database of the domain expert is considered in order to try to link the predictions with the entries of the existing database. This choice is made to demonstrate the ability to integrate data science technology in existing pipeline, in order to avoid creating disruptive effect.","title":"Case of Neuch\u00e2tel"},{"location":"PROJ-TPNL/#conclusion-and-perspectives","text":"As a main conclusion, this project, performed in two stage with Geneva and Neuch\u00e2tel states, is a complex task. The nature of the object of interest is the main source of difficulty. The current available aerial images made the detection of such object possible, but the resolution of the images (GSD) makes the task very difficult. Indeed, as mentioned, the thermal panel installations visible on the image are at the limit of resolution. This forces the deep learning model to learn more with the context than with the object features themselves. To add complexity, thermal panels appear very alike electrical panels on images, leading to a major source of confusion. The fact that the deep learning model is relying more on context than on object features lead the electrical panel to be reported as a thermal one, reducing the efficiency of inventory, leading to large amount of false positive. Despite that, interesting results are obtained and cannot lead to the conclusion that inventory such object is currently impossible. It remains very challenging, but data science can already bring help in the tracking and surveillance of the thermal panel installations. The collaboration with the domain experts is here a necessity. Indeed, such installations, especially with the image resolution, are extremely complex to confirm as such (mainly due to the confusion with electrical panels and other roof elements ). Even for the domain expert, determining if a prediction is a true positive or not is challenging and time-consuming. Without the help of domain experts, data scientists are not able to tackle such problem. Another positive outcome is the demonstration that data science can be interfaced smoothly with existing processes. This is shown with the Neuch\u00e2tel case, where the predictions can instantly be linked to the entries of the pre-existing domain expert database. This eases the domain expert assessment procedure and can also participate to assess the synchronization between the database and the reality. As a final word, the obtained deep learning model is not formally able to enter the management of the territory. It is demonstrated that the nature of the object and the available data makes the model unstable from a situation to another. This shows that the current data available is not formally enough to lead to the production of a fully working prototype able to satisfy the specifications of the domain experts. Nevertheless, such model can already perform pre-processes to ease the work of domain expert in the complex task of tracking the deployment of thermal energy generators on the Swiss territory.","title":"Conclusion and Perspectives"},{"location":"PROJ-TREEDET/","text":"Tree Detection from Point Clouds over the Canton of Geneva \u00b6 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET May 2021 to March 2022 - Published on April 22, 2022 Abstract : Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. 1. Introduction \u00b6 1.1 Context \u00b6 Human societies benefits from the presence of trees in cities and their surroundings. More specifically, as far as urban contexts are concerned, trees deliver many ecosystem services such as: the reduction of heat islands, by shading and cooling their direct environment; the mitigation of flood risks, by intercepting precipitation through their foliage and increasing soil infiltration; the reduction of atmospheric pollution; the reduction of noise pollution; a positive contribution to the physical, mental and social health of the population. Moreover, they play an important role of support of the biodiversity by offering resources and shelter to numerous animal, plant and fungus species. The quality and quantity of such benefits depend on various parameters, such as the height, the age, the leaf area, the species diversity within a given population of trees. Therefore, the preservation and the development of a healthy and functional tree population is one of the key elements of those public policies which aim at increasing resilience against climate change. For these reasons, the Canton of Geneva has set the ambitious goal of increasing its canopy cover (= ratio between the area covered by foliage and the total area) from 21% (as estimated in 2019) to 30% by 2050. In order to reach this goal, the concerned authorities ( i.e. the Office cantonal de l\u2019agriculture et de la nature ) need detailed data and tools to keep track of the cantonal tree population and drive its development. The Inventaire Cantonal des Arbres Isol\u00e9s (ICA) is the most extensive and detailed source of data on isolated trees (= trees that do not grow in forests) within the Canton of Geneva. Such dataset is maintained by a joint effort of several public administrations (green spaces departments of various municipalities, the Office cantonal de l\u2019agriculture et de la nature , the Geneva Conservatory and Botanical Garden, etc.). For each tree, several attributes are provided: geographical coordinates, species, height, plantation date, trunk diameter, crown diameter, etc. To date, the ICA includes data about more than 237 000 trees. However, it comes with a host of known limitations: only the public domain is covered (no records about trees which are found within private properties); moreover, the coverage of the public domain is partial (business experts estimate that half of the actual trees are missing). The freshness of data is not consistent among the various records, as it relies on sporadic ground surveys and manual updates. Trees tagged as \"historical\" lack precision in terms of geolocation and taxonomical information. In light of Geneva's ambitions in terms of the canopy growth, the latter observations call for the need of a more efficient methodology to improve the exhaustivity and veracity of the ICA. Over the last few years, several joint projects of the Canton, the City and the University of Geneva explored the potential of using LiDAR point clouds and tailored software to characterize trees in a semi-automatic way, following practices that are already established in forestry. Yet, forest and urban settings are quite different from each other: forests exhibit higher tree density, which can hinder tree detection; forests exhibit lower heterogeneity in terms of species and morphology, which can facilitate tree detection. Hence, the task of automatic detection is likely to be harder in urban contexts than in forests. The study reported in this page, proposed by the Office cantonal de l\u2019agriculture et de la nature (OCAN) and carried out by the STDL, represents a further yet modest step ahead towards the semi-automatic digitalisation of urban trees. 1.2 Objectives \u00b6 The objectives of this project was fixed by the OCAN domain experts and, in one sentence, amount to designing a robust and reproducible semi-automatic methodology allowing one to \"know everything\" about each and every isolated tree of the Canton of Geneva, which means: detecting all the trees (exhaustivity); geolocating the trunk and the top of every tree; measuring all the properties of every tree: height, trunk and crown diameter, canopy area and volume; identify species. Regarding quality, the following requirements were fixed: Property Expected precision Trunk geolocation 1 m Top geolocation 1 m Height 2 m Trunk diameter at 1m height 10 cm Crown diameter 1 m Canopy area 1 m\u00b2 Canopy volume 1 m\u00b3 In spite of such thorough and ambitious objectives, the time span of this project was not long enough to address them all. As a matter of fact, the STDL team only managed to tackle the tree detection and trunk geolocation. 1.3 Methodology \u00b6 As shown in Figure 1.1 here below, algorithms and software exist, which can detect individual trees from point clouds. Figure 1.1: The two panels represent a sample of a point cloud before (top panel) and after (bottom) tree detection. Not only such tools take point cloud as input data, but also the values of a bunch of parameters have to be chosen by users. The quality of results depend both on input data and on input parameters. The application of some pre-processing to the input point cloud have an impact, too. Therefore, it becomes clear that in order to find the optimal configuration for a given context, one should be able to measure the quality of results as a function of the chosen parameters as well as of the pre-processing operations. To this end, the STDL team called for the acquisition of ground truth data. Further details about input data (point cloud and ground truth), software and methodology will be provided shortly. 1.4 Input data \u00b6 1.4.1 LiDAR data \u00b6 A high-density point cloud dataset was produced by the Flotron Ingenieure company, through Airborne Laser Scanning (ALS, also commonly known by the acronym LiDAR - Light Detection And Ranging). Thanks to a lateral overlap of flight lines of ~80%, more than 200 pts/m\u00b2 were collected, quite a high density when compared to more conventional acquisitions (30 \u2013 40 pts/m\u00b2). Flotron Ingenieure took care of the point cloud classification, too. The following table summarizes the main features of the dataset: LIDAR 2021 - OCAN, Flotron Ingenieure Coverage Municipalities of Ch\u00eane-Bourg and Th\u00f4nex (GE) Date of acquisition March 10, 2021 Density > 200 pts/m\u00b2 Planimetric precision 20 mm Altimetric precision 50 mm Tiles 200 tiles of 200 m x 200 m Format LAS 1.2 Classes 0 - Unclassified 2 - Ground 4 - Medium vegetation (0.5 - 3m) 5 - High vegetation (> 3m) 6 - Building 7 - Low points 10 - Error points 13 - Bridges 16 - Noise / Vegetation < 0.5m Figs. 1.2 and 1.3 represent the coverage of the dataset and a sample, respectively. Figure 1.2: Coverage and tiling of the 2021 high-density point cloud dataset. Figure 1.3: A sample of the 2021 high-density point cloud. Colors correspond to different classes: green = vegetation (classes 4 and 5), orange = buildings (class 6), grey = ground or unclassified points (class 2 and 0, respectively). 1.4.2 Test sectors and ground truth data \u00b6 In order to be able to assess the exhaustivity and quality of our results, we needed reference (or \"ground truth\") data to compare with. Following the advice of domain experts, it was decided to acquire ground truth data regarding trees within three test sectors, which represent three different types of contexts: [1] alignment of trees, [2] park, [3] a mix of [1] and [2]. Of course, these types can also be found elsewhere within the Canton of Geneva. Ground truth data was acquired through surveys conducted by geometers, who recorded the (x, y) coordinates of the trunk at 1 m above the ground; the trunk diameter at 1 m above the ground, for every tree having a trunk diameter larger than 10 cm. Details about the three test sectors are provided in the following, where statistics on species, height, age and crown diameter stem from the ICA. Avenue de Bel-Air (Ch\u00eane-Bourg, GE) \u00b6 Property Value Type Alignment of trees Trees 135 individuals Species monospecific ( Tilia tomentosa ) Height range 6 - 15 m Age range 17 - 28 yo Crown diameters 3 - 10 m Comments Well separated trees, heights and morphologies are relatively homogenous, no underlying vegetation (bushes) around the trunks. Figure 1.4: \"Avenue de Bel-Air\" test sector in Ch\u00eane-Bourg (GE). Orange dots represents ground truth trees as recorded by geometers. Parc Floraire (Ch\u00eane-Bourg, GE) \u00b6 Property Value Type Park with ornemental trees Trees 95 individuals Species 65 species Height range 1.5 - 28 m Age range Unknown Crown diameters 1 - 23 m Comments Many ornemental species of all sizes and shapes, most of them not well separated. Very heterogenous vegetation structure. Figure 1.5: \"Parc Floraire\" test sector in Ch\u00eane-Bourg (GE). Orange dots represents ground truth trees as recorded by geometers. Adrien-Jeandin (Th\u00f4nex, GE) \u00b6 Property Value Type Mixed (park, alignment of tree, tree hedges, etc.) Trees 362 individuals Species 43 species Height range 1 - 34 m Age range Unknown Crown diameters 1 - 21 m Comments Mix of different vegetation structures, such as homogenous tree alignments, dense tree hedges and park with a lot of underlying vegetation under big trees. Figure 1.6: \"Adrien-Jeandin\" test sector in Th\u00f4nex (GE). Orange dots represents ground truth trees as recorded by the geometers. 1.5 Off-the-shelf software \u00b6 Two off-the-shelf software products were used to detect trees from LiDAR data, namely TerraScan and the Digital Forestry Toolbox (DFT). The following table summarizes the main similarities and differences between the two: Feature Terrascan DFT Licence Proprietary (*) Open Source (GPL-3.0) Price See here Free Standalone No: requires MicroStation or Spatix No: requires Octave or MATLAB Graphical User Interface Yes No In-app point cloud visualization Yes (via MicroStation or Spatix ) No (**) Scriptable Partly (via macros ) Yes Hackable No Yes (*) Unfortunately, we must acknowledge that using network licenses turned out to be quite problematic. Weeks of unexpected downtime were experienced, due to puzzling issues related to the interplay between the self-hosted license server, firewalls, VPN and end-devices. (**) We used the excellent Potree Free and Open Source software for visualization. The following sections are devoted to brief descriptions of these two tools; further details will be provided in Section 4 and Section 5 . 1.5.1 Terrascan \u00b6 Terrascan is a proprietary software, developed and commercialized by Terrasolid , a MicroStation and Spatix plugin which is capable of performing several tasks on point clouds, including visualisation, classification. As far as tree detection is concerned, Terrascan offers multiple options to manually, semi- or fully-automatically detect and segment trees in point clouds; estimate the value of a host of properties (height, trunk diameter, etc.). Two methods are provided to group (one may also say \"to segment\") points into individual trees: the so-called \"highest point\" (aka \"watershed\") method, suitable for airborne point clouds. the so-called \"trunk\" method, which requires a high amount of points from trunks and hence is suitable for very high-density airborne point clouds, for mobile data and point clouds from static scanners. For further details on these two methods, we refer the reader to the official documentation . 1.5.2 Digital Forestry Toolbox (DFT) \u00b6 The Digital Forestry Toolbox (DFT) is a collection of tools and tutorials for Matlab/Octave designed to help process and analyze remote sensing data related to forests (source: official website ) developed and maintained by Matthew Parkan, released under an Open Source license (GPL-3.0). The DFT implements algorithms allowing one to perform tree top detection, via a marker-controlled watershed segmentation (cf. this tutorial ); stem detection (cf. this other tutorial ). We refer the reader to the official documentation for further information. 2. Method \u00b6 As already stated, in spite of the thorough and ambitious objectives of this project (cf. here ), only the tree detection and trunk geolocation sub-tasks could be tackled given the resources (time, humans) which were allocated to the STDL. The method we followed goes through several steps, pre-processing, running Terrascan or DFT, post-processing, which are documented here-below. 2.1 Pre-processing: point cloud reclassification and cleaning \u00b6 [1] In some cases, points corresponding to trunks may be misclassified and lay in class 0 \u2013 Unclassified instead of class 4 \u2013 Medium vegetation . As the segmentation process only takes vegetation classes (namely classes 4 and 5) into account, the lack of trunk points can make some trees \"invisibles\". [2] We suspected that the standard classification of vegetation in LiDAR point clouds could be too basic for the task at hand. Indeed, vegetation points found at less (more) than 3 m above the ground are classified as 4 \u2013 Medium Vegetation ( 5 \u2013 High Vegetation ). This may cause one potential issue: all the points of a given tree that are located at up to 3 meters above the ground (think about the trunk!) belong to a class (namely class no. 4) which can also be populated by bushes and hedges. The \"contamination\" by bushes and hedges may spoil the segmentation process, especially in situations where dense low vegetation exists around higher trees. Indeed, it was acknowledged that in such situations the segmentation algorithm fails to properly identify trunk locations and distinguish one tree from another. Issues [1] and [2] can be solved or at least mitigated by reclassifying and cleaning the input point cloud, respectively. Figures 2.1 and 2.2 show how tree grouping (or \"segmentation\") yields better results if pre-processed pointclouds are used. Figure 2.1: Tree grouping (or \"segmentation\") applied to the original (top panel) vs pre-processed (bottom) point cloud. Without pre-processing, two trees connected by a hedge are segmented as one single individual. Therefore, only one detection is made (green circle slightly above the ground). With pre-processing, we get rid of the hedge and recover the lowest trunk points belonging to the tree on the left. Eventually, both trees are properly segmented and we end up having two detections (green circles). Figure 2.2: Tree grouping (or \"segmentation\") applied to the original (left panel) vs reclassified (right) point cloud. Without pre-processing, segmentation yields a spurious detection (= false positive, red circle slightly above the ground), resulting from the combination of a pole and a hedge. With pre-processing, we get rid of most of the points belonging to the hedge and the pole; no false positive shows up. 2.1.1 Reclassification with Terrascan and FME Desktop \u00b6 The reclassification step aims at recovering trunk points which might be misclassified and hence found in some class other than class 4 \u2013 Medium Vegetation ( e.g. class 0 - Unclassified ). It was carried out with Terrascan using the Classify by normal vectors tool, which identifies linear features generated by groups of class 0 and 4 points; moves the concerned points to an empty class (here: class 10). Finally, during the cleaning process with FME Desktop (cf. Chapter 2.1.2 here below), these points are reclassified in class 4. The outcome of this reclassification step is shown in Figure 2.3. Figure 2.3: Outcome of reclassification. In the upper picture, the trunk of the tree on the left is partially misclassified, while the trunk of the tree in the middle is completely misclassified. After reclassification, almost all the points belonging to trunks are back in class 4. Let us note that the reclassification process may also recover some unwanted objects enjoying linear features similar to trees (poles, power lines, etc.). However, such spurious objects can at least partly filtered out by cleaning step described here below. 2.1.2 Cleaning point clouds with FME Desktop \u00b6 The cleaning step aims to filter as many \"non-trunk\" points as possible out of class 4 \u2013 Medium Vegetation , in order to isolate trees from other types of vegetation. Vegetation is considered as part of a tree if higher than 3 m. Cleaning consists in two steps: Every point of class 4 which is NOT vertically covered by any class 5 point ( i.e. any class 4 point which is not under a tree) is moved to another class. This filters out an important part of bushes and hedges. Only those bushes and hedges which are actually under a tree remain in class 4. Every point of class 4 which is located above a wall is moved to another class. Actually, it was noticed that many hedges were located on or against walls. This filters out some additional \"hedge points\", which may escape the first cleaning step if found straight under a tree. Note that in case the point cloud is reclassified in order to recover missing trunks, the cleaning step also allow to get rid of unwanted linear objects (poles, electric lines, etc) that have been recovered during the reclassification. The class containing reclassified points (class 10) will simply be process together with class 4 and receive the same treatment. Eventually, reclassified points that are kept (discarded) by the cleaning process will be integrated in class 4 (3). Figure 2.4: Outcome of the cleaning process. Red points correspond to the \"cleaned\" points that were moved to class 3. Figure 2.5: Outcome of the cleaning process. Red points correspond to the \"cleaned\" points that were moved to class 3. Hedges under trees escape the cleaning. 2.1.3 FME files and documentation of pre-processing steps \u00b6 More detailed information about the reclassification and cleaning of the point cloud can be found here . FME files can be downloaded by following these links: FME Workbench File (requires a Canopy Cover Layer) Alternative FME Workbench File (does not require a Canopy Cover Layer Further information on the generation of a Canopy Cover Layer can be found here . 2.2 Running Terrascan \u00b6 Terrascan offers multiple ways to detect trees from point clouds. In this project, we focused on the fully automatic segmentation, which is available through the \"Assign Groups\" command. As already said (cf. here ), two methods are available: highest point (aka \"watershed\") method and trunk method. In what follows, we introduce the reader to the various parameters that are involved in such methods. 2.2.1 Watershed method parameters \u00b6 Group planar surfaces \u00b6 Quoting the official documentation , If on, points that fit to planes are grouped. Points fitting to the same plane get the same group number. Min height \u00b6 This parameter defines a minimum threshold on the distance from the ground that the highest of a group of points must have, in order for the group to be considered as a tree. The default value is 4 meters. The Inventaire Cantonal des Arbres Isol\u00e9s includes trees which are at least 3 m high. This parameter ranged from 2 to 6 m in our tests. Figure 2.6: Cross-section view of two detected trees. The left tree would not be detected if the parameter \"Min height\" were larger than 3.5 m. Require \u00b6 This parameter defines the minimum number of points which are required to form a group ( i.e. a tree). The default value is 20 points, which is very low in light of the high density of the dataset we used. Probably, the default value is meant to be used with point clouds having a one order of magnitude smaller density. In our analysis, we tested the following values: 20 (default), 50, 200, 1000, 2000, 4000, 6000. 2.2.2 Trunk method parameters \u00b6 Group planar surfaces \u00b6 See here . Min Height \u00b6 Same role as in the watershed method, see here . Max diameter \u00b6 This parameter defines the maximum diameter (in meters) which a group of points identified as trunk can reach. Default value is 0.6 meters. Knowing that very few trees of the ICA exceed this value; yet, older trees can exhibit larger diameters, we used the following values: 0.20, 0.30, 0.40, 0.60 (default), 0.80, 1.00, 1.50 meters. Min trunk \u00b6 This parameter defines a minimum threshold on the length of tree trunks. Default value is 2 m. We tested the following values: 0.50, 1.00, 1.50, 2.00 (default), 2.50, 3.00, 4.00, 5.00 meters. Group by density \u00b6 Quoting the official documentation , If on, points are grouped based on their distance to each other. Close-by points get the same group number. Gap \u00b6 Quoting the official documentation , Distance between consecutive groups: Automatic: the software decides what points belong to one group or to another. This is recommended for objects with variable gaps, such as moving objects on a road. User fixed: the user can define a fixed distance value in the text field. This is suited for fixed objects with large distances in between, such as powerline towers. We did not attempt the optimization of this parameter but kept the default value (Auto). 2.2.3 Visualizing results \u00b6 Terrascan allows the user to visualize the outcome of the tree segmentation straight from within the Graphical User Interface. Points belonging to the same group ( i.e. to the same tree) are assigned the same random color, which allows the user to perform intuitive, quick, qualitative in-app assessments. An example is provided in Figure 2.7. Figure 2.7: Three examples of tree segmentations. From a qualitative point of view, we can acknowledge that the leftmost (rightmost) example is affected by undersegmentation (oversegmentation). The example in the middle seems to be a good compromise. 2.2.4 Exporting results \u00b6 As already said, Terrascan takes point clouds as input data and can run algorithms which form group out of these points, each group corresponding to an individual tree. A host of \"features\" (or \"measurements\"/ \"attributes\"/...) are generated for each group, which the user can export to text files using the \"Write group info\" command. The set of exported features can be customized through a dedicated configuration panel which can be found within the software settings (\"File formats / User group formats\"). The list and documentation of all the exportable features can be found here . Let us note that depending on the segmentation method, not all the features can be populated; multiple geolocation information can exist. The following table summarizes the features which the watershed and trunk methods can export: Feature Watershed Method Trunk Method Group ID Yes Yes Point Count Yes Yes Average XY Coordinates Yes Yes Ground Z at Avg. XY Yes Yes Trunk XY No Yes Ground Z at Trunk XY No Yes Trunk Diameter See here below See here below Canopy Width Yes Yes Biggest Distance above Ground (Max. Height) Yes Yes Smallest Distance above Ground Yes Yes Length Yes Yes Width Yes Yes Height Yes Yes 2.2.5 Trunk Diameters \u00b6 Terrascan integrates a functionality allowing users to measure trunk diameters (see Figure 2.8). Figure 2.8: Screenshots of the trunk diameter measurement function. Let us note that the measurement of trunk diameters can be feasible or not, depending on the number of points which sample a given trunk. We performed some rapid experiments, which showed that some diameters could actually be estimated, given the high density of the point cloud we used (cf. here ). Still, we did not analyzed the reliability of such estimations against reference/ground truth data. 2.3 Running DFT \u00b6 As already said, DFT consists of a collection of functions which can be run either with Octave or MATLAB . The former software was used in the frame of this context. A few custom Octave scripts were written to automatize the exploration of the parameter space. Our preliminary, warm-up tests showed that we could not obtain satisfactory results by using the \"tree top detection method\" (cf. here ). Indeed, upon using this method the F1-score topped at around 40%. Therefore, we devoted our efforts to exploring the parameter space of the other available method, namely the \"tree stem detection method\" (cf. this tutorial ). In the following, we provide a brief description of the various parameters involved in such a detection method. 2.3.2 Parameters concerned by the tree stem detection method \u00b6 Quoting the official tutorial , The stem detection algorithm uses the planimetric coordinates and height of the points above ground as an input. To compute the height, DFT provides a function called elevationModels , which takes the classified 3D point cloud as input, as well as some parameters. Regarding these parameters, we stuck to the values suggested by the official tutorial, except for the cellSize parameter (= size of the raster cells) which was set to 0.8 (meters); the searchRadius parameter which was set to 10 (meters). Once that each point is assigned an height above the ground, the actual tree stem detection algorithm can be invoked ( treeStems DFT function, cf. DFT Tree Stem Detection Tutorial / Step 4 - Detect the stems ), which takes a host of parameters. While referring the reader to the official tutorial for the definition of these parameters, we provide the list of values we used (unit = meters): Parameter Value cellSize 0.9 bandWidth 0.7 verticalStep 0.15 searchRadius from 1 to 6, step = 0.5 minLength from 1 to 6, step = 0.5 searchRadius ( minLength ) was fixed to 4 (meters) when minLength ( searchRadius ) was let vary between 1 and 6 meters. 2.3.3 Visualizing results \u00b6 DFT does not include any specific Graphical User Interface. Still, users can rely on Octave/MATLAB to generate plots, something useful and clever especially when performing analysis in an interactive way. In our case, DFT was used in a non-interactive way and visualisation was delayed until the assessment step, which we describe in Section 2.4 . 2.3.4 Exporting results \u00b6 Thanks to the vast Octave/MATLAB ecosystem, DFT results can be output to disk in several ways and using data formats. More specifically, we used the ESRI Shapefile file format to export the average (x, y) coordinates of the detected stems/peaks. 2.3.5 Trunk diameters \u00b6 This feature is missing in DFT. 2.4 Post-processing: assessment algorithm and metrics computation \u00b6 As already said, the STDL used a couple of third-party tools, namely TerraScan and the Digital Forestry Toolbox (DFT) , in order to detect trees from point clouds. Both tools can output a segmented point cloud, in which points associated to the same tree are assigned the same identifier; one (X, Y, Z) triplet per detected tree, where the X, Y and Z (optional) coordinates are computed either as the centroid of all the points which get associated to a given tree, or - under some conditions - as the centroid of the trunk only; expressed in the same reference system as the input point cloud. As the ground truth data the STDL was provided with take the form of one (X', Y') pair per tree, with Z' implicitly equal to 1 meter above the ground, the comparison between detections and ground truth trees could only be performed on the common ground of 2D space. In other words, we could not assess the 3D point clouds segmentations obtained by either TerraScan or DFT against reference/ground truth segmentations in the 3D space. The problem which needed to be solved amounts to finding matching and unmatching items between two sets of 2D points: a 1st set including the (X', Y') coordinates of ground truth trees; a 2nd set including the (X, Y) coordinates of detected trees. In order to fulfill the requirement of a 1 meter accuracy which was set by the beneficiaries of this project, the following matching rule was adopted: a detection (D) matches a ground truth tree (GT) (and vice versa) if and only if the Cartesian distance between D and GT is less or equal to 1 meter Figure 2.9 shows how such a rule would allow one to tag detections as either True Positives (TPs) or False Positives (FPs) ground truth trees as either True Positives (TPs) or False Negatives (FNs) in the most trivial case. Figure 2.9: Tagging as True Positive (TP), False Positive (FP), False Negative (FN) ground truth and detected trees in the most trivial case. Actually, far less trivial cases can arise, such as the one illustrated in Figure 2.10. Figure 2.10: Only one detection can exist for two candidate ground truth trees, or else two detections can exist for only one candidate ground truth tree. The STDL designed and implemented an algorithm, which would produce relevant TP, FP, FN tags and counts even in such more complex cases. For instance, in a setting like the one in the image here above, one would expect the algorithm to count 2 TPs, 1 FP, 1 FN. Details are provided here below. 2.4.1 The tagging and counting algorithm \u00b6 1st step: geohash detections and ground truth trees \u00b6 In order to keep track of the various detections and ground truth trees all along the execution of the assessment algorithm, each item is given a unique identifier, computed as the geohash of its coordinates, using the pygeohash Python module. Such identifier is not only unique (as far as a sufficiently high precision is used), but also stable across subsequent executions. The latter property allows analysts to \"synchronise\" the concerned objects between the output of the (Python) code and the views generated with GIS tools such as QGIS , which turns out to be quite useful especially at development and debugging time. 2nd step: convert point detections to circles \u00b6 As a 2nd step, each detection is converted to a circle, centered on the (X, Y) coordinates of the detection; having a 1 m radius. This operation can be accomplished by generating a 1 m buffer around each detection. For the sake of precision, this method was used, which generates a polygonal surface approximating the intended circle. 3rd step: perform left and right outer spatial joins \u00b6 As a 3rd step, the following two spatial joins are computed: left outer join between the circles generated at the previous step and ground truth trees; right outer join between the same two operands. In both cases, the \"intersects\" operation is used (cf. this page for more technical details). 4th step: tag trivial False Positives and False Negatives \u00b6 All those detections output by the left outer join for which no right attribute exists (in particular, we focus on the right geohash) can trivially be tagged as FPs. As a matter of fact, this means that the 1 m circular buffer surrounding the detection does not intersect any ground truth tree; in other words, that no ground truth tree can be found within 1 m from the detection. The same reasoning leads to trivially tagging as FNs all those ground truth trees output by the right outer join for which no left attribute exists. These cases correspond to the two rightmost items in Fig. 6.1. For reasons which will be clarified here below, the algorithm does not actually tag items as either FPs or FNs; instead, TP and FP \"charges\" are assigned to detected trees; TP and FN charges are assigned to ground truth trees. Here's how: for FP detected trees: TP charge FP charge 0 1 for FN ground truth trees: TP charge FN charge 0 1 5th step: tag non-trivial False Positives and False Negatives \u00b6 The left outer spatial join performed at step 3 establishes relations between each detection and those ground truth trees which are located no further than 1 meter, as shown in Figure 2.11. Figure 2.11: The spatial join between buffered detections and ground truth trees establishes relations between groups of items of these two populations. In the sample setting depicted in this picture, two unrelated groups can be found. The example here above shows 4 relations, D1 - GT1, D1 - GT2, D2 - GT3, D3 - GT3 which can be split (see the red dashed line) into two unrelated, independent groups: {D1 - GT1, D1 - GT2} {D2 - GT3, D3 - GT3} In order to generate this kind of groups in a programmatic way, the algorithm first builds a graph out of the relations established by the left outer spatial join, then it extracts the connected components of such a graph (cf. this page ). The tagging and counting of TPs, FPs, FNs is performed on a per-group basis, according to the following strategy: if a group contains more ground truth than detected trees, then the group is assigned an excess \"FN charge\", equal to the difference between the number of ground truth trees and detected trees. This excess charge is then divided by the number of ground truth trees and the result assigned to each of them. For instance, the {D1 - GT1, D1 - GT2} group in the image here above would be assigned an FN charge equal to 1; then, each ground truth tree would be assigned an FN charge equal to 1/2. Similarly, if a group contains more detected trees than ground truth trees, then the group is assigned an excess FP charge, equal to the difference between the number of detected trees and ground truth trees. This excess charge is then divided by the number of detections and the result assigned to each of them. For instance, the {D2 - GT3, D3 - GT3} group in the image here above would be assigned an excess FN charge equal to 1; then, each detection would be assigned an FP charge equal to 1/2. In case the number of ground truth trees be the same as the number of detections, no excess FN/FP charge is assigned to the group. Concerning the assignment of TP charges, the per-group budget is established as the minimum between the number of ground truth and detected trees, then equally split between the items of these two populations. In the example above, both groups would be assigned TP charge = 1. Wrapping things up, here are the charges which the algorithm would assign to the various items of the example here above: item TP charge FP charge Total charge D1 1 0 1 D2 1/2 1/2 1 D3 1/2 1/2 1 Sum 2 1 3 item TP charge FN charge Total charge GT1 1/2 1/2 1 GT2 1/2 1/2 1 GT3 1 0 1 Sum 2 1 3 Let us note that: the count of TPs yields the same result, whether we consider detections or ground truth trees, which makes sense; the \"Total charge\" column allows one to check the consistency of the algorithm; as expected, we obtain 2 FPs, 1 FP, 1 FN; the algorithm does not even attempt to establish 1:1 relations, \"optimal\" in a given sense, between ground truth and detected trees. As a matter of fact, the algorithm is designed to produce meaningful counts and tags only; of course, the algorithm also works in far more complex settings than the one depicted in Figs. 6.2 and 6.3. 2.4.2 From counts to metrics \u00b6 TP, FP, FN counts are extensive properties, out of which we can compute some standard metrics such as precision recall F1-score which are intensive, instead. While referring the reader to this paragraph for the definition of these metrics, let us state the interpretation which holds in the present use case: precision is optimal (= 1.0) if and only if (iff) all the detections are matched by ground truth trees (no FPs); recall is optimal (= 1.0) iff all the ground truth trees are detected (no FNs). Typically, one cannot optimize both precision and recall for the same values of a set of parameters. Instead, they can exhibit opposite trends as a function of a given parameter ( e.g. precision increases while recall decreases). In such cases, the F1-score would exhibit convexity and could be optimized. 3. Results and discussion \u00b6 Figure 3.1 shows some of the tree detection trials we performed, using Terrascan and DFT. Each trial corresponds to a different set of parameters and is represented either by gray dots or colored diamonds in a precision-recall plot (see the image caption for further details). Figure 3.1: Precision vs. Recall of a subset of the tree detections we attempted, using different parameters in Terrascan and DFT. Colored diamonds represent the starting point (red) as well as our \"last stops\" in the parameter space, with (yellow, green) and without (orange) pre-processing. All the three test sectors are here combined. Let us note that: the DFT parameter space can be conveniently explored by scripting the batch execution of various runs; on the contrary, the exploration of the Terrascan parameter space is more laborious, has to be performed manually, trying out one specific set of parameters after another, with repeated manual export of features (including geographical coordinates) in between. Indeed, although Terrascan let users define macros, unfortunately the \"Write Group Info\" command cannot be used in macros; in both cases, the parameter space was explored in quite an heuristic and partial way; we aimed at optimizing the F1-score all sectors combined. More detailed comments follow, concerning the best trials made with Terrascan and DFT. 3.1 The best trial made with Terrascan \u00b6 Among the trials we ran with Terrascan, the one which yielded the best F1-score was obtained using the following parameters: Parameter Value Method / Algorithm Trunk Classes 4+5, cleaned and reclassified Group planar surfaces Off Min height 3.00 m Max diameter 0.40 m Min trunk 3.00 m Group by density On Gap Auto Require 1500 pts This trial corresponds to the green diamond shown in Figure 3.1. Figure 3.2: Test sectors as segmented by the best trial made with Terrascan. Figure 3.2 provides a view of the outcome on the three test sectors. Metrics read as follows: Sector TP FP FN Detectable (TP+FN) Precision Recall F1-Score Global 323 137 234 557 70.2% 58.0% 63.5% Adrien-Jeandin 177 69 160 337 72.0% 52.5% 60.7% Bel-Air 114 15 11 125 88.4% 91.2% 89.8% Floraire 32 53 63 89 37.6% 33.7% 35.6% Figure 3.3 provides a graphical representation of the same findings, with the addition of the metrics we computed before cleaning and reclassifying the LiDAR point cloud. Figure 3.3: Cleaning and reclassifying the point cloud has a positive influence on precision and recall, although modest. Our results confirm that the tree detection task is more or less hard depending on the sector at hand. Without any surprise, we acknowledge that: the \"Avenue de Bel-Air\" test sector (BEL), enjoying an alley of well-separated trees, is easily tackled by Terrascan. Quite decent precision and recall are obtained. In contrast, the \"Parc Floraire\" test sector (FLO) turns out to be the hardest one, given the vegetation density and heterogeneity. The \"Adrien-Jeandin\" (ADR) is actually a mix of dense and sparse contexts and turns out to be a good proxy for the global performance. Cleaning and Reclassification have a benificial impact on Precision and Recall for all sectors as well as the global context (TOT). While for BEL mainly Recall profited from preprocessing, ADR and FLO showed a stronger increase in Precision. For the global context both, Precision and Recall, could be increased slighty. Figure 3.4: The F1-score attained by our best Terrascan trial. Figure 3.4 shows how our best Terrascan trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that pre-processing slightly improves the F1-score for the global context as well as for the individual sectors. The largest impact was observed for the Bel-Air sector, especially for preprocessing including Reclassification. 3.2 The best trial made with DFT \u00b6 The DFT trial yielding the highest global F1-score was obtained using the stem detection method and the following parameters: Parameter Value Method / Algorithm Stem detection Classes 4+5, cleaned and reclassified Search radius 4.00 Minimum length 4.00 Here's a summary of the resulting metrics: Sector Precision Recall F1-score Adrien-Jeandin 75.4% 36.5% 49.2% Bel-Air 88.0% 82.4% 85.1% Floraire 47.9% 36.8% 41.7% Global 74.0% 46.6% 57.2% Similar comments to those formulated here apply: the \"Avenue de Bel-Air\" sector remains the easiest to process; \"Parc Floraire\" the hardest. However, here we acknowledge a bigger gap between the global F1-score and the F1-score related to the \"Adrien-Jeandin\" test sector. Figure 3.5 shows how our best DFT trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that the impact of point cloud reclassification can be slightly positive or negative depending on the test sector. Figure 3.5: The F1-score attained by our best DFT trial. 3.3 Comparison: Terrascan vs. DFT \u00b6 Figure 3.6: Comparison of Terrascan and DFT in terms of F1-score. The comparison of the best Terrascan trial vs. the best DFT trial in terms of F1-score shows that there is no clear winner (see Figure 3.6). Still, we can notice that: DFT reaches the best F1-score ever in the \"Parc Floraire\" (\"Avenue de Bel-Air\") sector, without (with) pre-processing. Terrascan performs slightly better on global scores and substantially better on the mixed context of the Adrien-Jeandin sector,especially after pre-processing. 3.4 Trials with standard-density datasets \u00b6 In addition to applying our method to the 2021 high-density (HD) LiDAR dataset, we also tried using two other datasets exhibiting a by far more standard point density (20-30 pt/m\u00b2): Nuage de points LiDAR 2017 Nuage de points LiDAR 2019 The goal was twofold: finding evidence for the added value of high-density (HD) datasets, despite their higher cost; checking whether the parameters which turned out to yield optimal scores with HD LiDAR data could also yield acceptable results if used with standard-density (SD) datasets. Concerning the 1st point, lower point densities make the \"trunk method\" unreliable (if not completely unusable). In Figure 3.7, we report results obtained with the watershed method, along with results related to the best performing trials obtained with the 2021 HD dataset. The scores we obtained with the SD dataset are far below the best we obtained with the HD dataset, confirming the interest of high-density acquisitions. Figure 3.7: Comparison of F1-scores of the best performing trials. Parameters were optimized for each model individually. Concerning the 2nd point, without any surprise we confirmed that parameters must be re-optimized for SD datasets. The usage of the set of parameters which were optimized on the basis of the HD dataset yielded poor results, as shown in Figure 3.8. Figure 3.8: Using the parameters which were optimized for the high-density dataset leads to poor results (strong under-segmentation) on SD datasets. In accordance with the TS documentation we can see that the trunk method is unusable for lower and medium density datasets. The watershed algorithm produces a more realistic segmentation pattern on the SD dataset but still cannot reach the performance levels of the trunk or the watershed method on the HD dataset. After optimizing parameters, we could obtain quite decent results though (see Figure 3.9). Figure 3.9: After a dataset-specific parameter optimization, convincing results can be achieved on the medium-density 2019 dataset (Terrascan's watershed method was used). 3.5 Tree detection over the full 2021 high-density LiDAR dataset \u00b6 Clearly, from a computational point of view processing large point cloud dataset is not the same as processing small datasets. Given the extremely high density of the 2021 LiDAR datasets, we wanted to check whether and how Terrascan could handle such a resource-intensive task. Thanks to Terrascan's macro actions, one can split the task into a set of smaller sub-tasks, each sub-task dealing with a \"tile\" of the full dataset. Additionally, Terrascan integrates quite a smart feature, which automatically merges groups of points ( i.e. trees) spanning multiple tiles. Figure 3.10 provides a static view of the results we obtained, using the parameters which globally performed the best on the three sectors. We refer the reader to this Potree viewer (kindly hosted by the G\u00e9oportail du SITN ) for an interactive view. Figure 3.10: Result of the application of the best performing Terrascan parameters to the full dataset. 4. Conclusion and outlook \u00b6 Despite all the efforts documented here above, the results we obtained are not as satisfactory as expected. Indeed, the metrics we managed to attain all sectors combined indicate that tree detections are neither reliable (low precision) nor exhaustive (low recall). Still, we think that results may be improved by further developing some ideas, which we sketch in the following. 4.1 Further the DFT parameter space exploration \u00b6 We devoted much more time to exploring Terrascan's parameter space than DFT's. Indeed, as already stated here , we only explored the two parameters searchRadius and minLenght . Other parameters such as cellSize , bandwidth and verticalStep were not explored at all (we kept default values). We think it is definitely worth exploring these other parameters, too. Moreover, we did not try feeding all the LiDAR returns to the stem detection method, we only used the last returns. It is surely worth checking whether the usage of the other returns could be beneficial. Upon using the peak detection method, we did not manage to reach a better F1-score than ~40%, as opposed to the 57% obtained with the stem detection method. However, the peak detection method is particularly interesting because it can also delimit canopies. Hence, it may be worth trying to improve the F1-score, for instance by tuning the parameters of the power law equation relating the crown radius to the tree height (cf. here ). 4.2 Exploit contextual information \u00b6 We showed that the algorithms implemented by TerraScan and DFT yield much better results in sparse contexts (ex.: the \"Avenue de Bel-Air\" test sector) than in dense ones (ex.: the \"Parc Floraire\" test sector). This means that precision may be improved (at the expense of recall, though) if one could restrain the tree detection to sparse contexts only, either as a pre- or post-processing step. We can think of at least a couple of methods which would allow one to (semi-)automatically tell sparse from dense contexts: intrinsic method: after segmenting the point cloud into individual trees, one could analyze how close (far) each individual is to (from) the nearest neighbor and estimate the density of trees on some 2D or 3D grid; extrinsic method: territorial data exist (see for instance the dataset \"Carte de couverture du sol selon classification OTEMO\" distributed by the SITG ), providing information about urban planning and land use ( e.g . roads, parks, sidewalks, etc.). These data may be analyzed in order to extract hints on how likely it is for a tree to be in close proximity with another, according to its position. 4.3 Combine detections stemming from two or more independent trials \u00b6 Detections coming from two or more independent trials (obtained with different software or else with the same software but different parameters) could be combined in order to improve either precision or recall: recall would be improved (i.e. the number of false negatives would be reduced) if detections coming from multiple trials were merged. In order to prevent double counting, two or more detections coming from two or more sources could be counted as just one if they were found within a given distance from each other. The algorithm would follow along similar lines as the ones which led us to the \"tagging and counting algorithm\" presented here above ; precision would be improved (i.e. the number of false positives would be reduced) if we considered only those detections for which a consensus could be established among two or more trials, and discarded the rest. A distance-based criterion could be used to establish such consensus, along similar lines as those leading to our \"tagging and counting algorithm\" . 4.4 Use generic point cloud segmentation algorithms \u00b6 Generic ( i.e. not tailored for tree detection) clustering algorithms exist, such as DBSCAN (\"Density-Based Spatial Clustering of Applications with Noise\", see e.g. here ), which could be used to segment a LiDAR point cloud into individual trees. We think it would be worth giving these algorithms a try! 4.5 Use Machine Learning \u00b6 The segmentation algorithms we used in this project do not rely on Machine Learning. Yet, alternative/complementary approaches might me investigated, in which a point cloud segmentation model would be first trained on reference data, then used to infer tree segmentations within a given area of interest. For instance, it would be tempting to test this Deep Learning model published by ESRI and usable with their ArcGIS Pro software. It would be also worth deep diving into this research paper and try replicating the proposed methodology. Regarding training data, we could generate a ground truth dataset by using our best TerraScan/DFT model to segment the 3D point cloud; using 2D ground truth data to filter out wrong segmentations. 5. Other resources \u00b6 The work documented here was the object of a Forum SITG which took place online on March 29, 2022. Videos and presentation materials can be found here . 6. Acknowledgements \u00b6 This project was made possible thanks to a tight collaboration between the STDL team and some experts of the Canton of Neuch\u00e2tel (NE), the Canton of Geneva (GE), the Conservatoire et Jardin botaniques de la Ville de Gen\u00e8ve (CJBG) and the University of Geneva (UNIGE). The STDL team acknowledges key contributions from Marc Riedo (SITN, NE), Bertrand Favre (OCAN, GE), Nicolas Wyler (CJBG) and Gregory Giuliani (UNIGE). We also wish to warmly thank Matthew Parkan for developing, maintaining and advising us on the Digital Forestry Toolbox .","title":"<span style=\"text-transform:uppercase;\"> Tree Detection from Point Clouds over the Canton of Geneva </span>"},{"location":"PROJ-TREEDET/#tree-detection-from-point-clouds-over-the-canton-of-geneva","text":"Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET May 2021 to March 2022 - Published on April 22, 2022 Abstract : Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement.","title":" Tree Detection from Point Clouds over the Canton of Geneva "},{"location":"PROJ-TREEDET/#1-introduction","text":"","title":"1. Introduction"},{"location":"PROJ-TREEDET/#11-context","text":"Human societies benefits from the presence of trees in cities and their surroundings. More specifically, as far as urban contexts are concerned, trees deliver many ecosystem services such as: the reduction of heat islands, by shading and cooling their direct environment; the mitigation of flood risks, by intercepting precipitation through their foliage and increasing soil infiltration; the reduction of atmospheric pollution; the reduction of noise pollution; a positive contribution to the physical, mental and social health of the population. Moreover, they play an important role of support of the biodiversity by offering resources and shelter to numerous animal, plant and fungus species. The quality and quantity of such benefits depend on various parameters, such as the height, the age, the leaf area, the species diversity within a given population of trees. Therefore, the preservation and the development of a healthy and functional tree population is one of the key elements of those public policies which aim at increasing resilience against climate change. For these reasons, the Canton of Geneva has set the ambitious goal of increasing its canopy cover (= ratio between the area covered by foliage and the total area) from 21% (as estimated in 2019) to 30% by 2050. In order to reach this goal, the concerned authorities ( i.e. the Office cantonal de l\u2019agriculture et de la nature ) need detailed data and tools to keep track of the cantonal tree population and drive its development. The Inventaire Cantonal des Arbres Isol\u00e9s (ICA) is the most extensive and detailed source of data on isolated trees (= trees that do not grow in forests) within the Canton of Geneva. Such dataset is maintained by a joint effort of several public administrations (green spaces departments of various municipalities, the Office cantonal de l\u2019agriculture et de la nature , the Geneva Conservatory and Botanical Garden, etc.). For each tree, several attributes are provided: geographical coordinates, species, height, plantation date, trunk diameter, crown diameter, etc. To date, the ICA includes data about more than 237 000 trees. However, it comes with a host of known limitations: only the public domain is covered (no records about trees which are found within private properties); moreover, the coverage of the public domain is partial (business experts estimate that half of the actual trees are missing). The freshness of data is not consistent among the various records, as it relies on sporadic ground surveys and manual updates. Trees tagged as \"historical\" lack precision in terms of geolocation and taxonomical information. In light of Geneva's ambitions in terms of the canopy growth, the latter observations call for the need of a more efficient methodology to improve the exhaustivity and veracity of the ICA. Over the last few years, several joint projects of the Canton, the City and the University of Geneva explored the potential of using LiDAR point clouds and tailored software to characterize trees in a semi-automatic way, following practices that are already established in forestry. Yet, forest and urban settings are quite different from each other: forests exhibit higher tree density, which can hinder tree detection; forests exhibit lower heterogeneity in terms of species and morphology, which can facilitate tree detection. Hence, the task of automatic detection is likely to be harder in urban contexts than in forests. The study reported in this page, proposed by the Office cantonal de l\u2019agriculture et de la nature (OCAN) and carried out by the STDL, represents a further yet modest step ahead towards the semi-automatic digitalisation of urban trees.","title":"1.1 Context"},{"location":"PROJ-TREEDET/#12-objectives","text":"The objectives of this project was fixed by the OCAN domain experts and, in one sentence, amount to designing a robust and reproducible semi-automatic methodology allowing one to \"know everything\" about each and every isolated tree of the Canton of Geneva, which means: detecting all the trees (exhaustivity); geolocating the trunk and the top of every tree; measuring all the properties of every tree: height, trunk and crown diameter, canopy area and volume; identify species. Regarding quality, the following requirements were fixed: Property Expected precision Trunk geolocation 1 m Top geolocation 1 m Height 2 m Trunk diameter at 1m height 10 cm Crown diameter 1 m Canopy area 1 m\u00b2 Canopy volume 1 m\u00b3 In spite of such thorough and ambitious objectives, the time span of this project was not long enough to address them all. As a matter of fact, the STDL team only managed to tackle the tree detection and trunk geolocation.","title":"1.2 Objectives"},{"location":"PROJ-TREEDET/#13-methodology","text":"As shown in Figure 1.1 here below, algorithms and software exist, which can detect individual trees from point clouds. Figure 1.1: The two panels represent a sample of a point cloud before (top panel) and after (bottom) tree detection. Not only such tools take point cloud as input data, but also the values of a bunch of parameters have to be chosen by users. The quality of results depend both on input data and on input parameters. The application of some pre-processing to the input point cloud have an impact, too. Therefore, it becomes clear that in order to find the optimal configuration for a given context, one should be able to measure the quality of results as a function of the chosen parameters as well as of the pre-processing operations. To this end, the STDL team called for the acquisition of ground truth data. Further details about input data (point cloud and ground truth), software and methodology will be provided shortly.","title":"1.3 Methodology"},{"location":"PROJ-TREEDET/#14-input-data","text":"","title":"1.4 Input data"},{"location":"PROJ-TREEDET/#15-off-the-shelf-software","text":"Two off-the-shelf software products were used to detect trees from LiDAR data, namely TerraScan and the Digital Forestry Toolbox (DFT). The following table summarizes the main similarities and differences between the two: Feature Terrascan DFT Licence Proprietary (*) Open Source (GPL-3.0) Price See here Free Standalone No: requires MicroStation or Spatix No: requires Octave or MATLAB Graphical User Interface Yes No In-app point cloud visualization Yes (via MicroStation or Spatix ) No (**) Scriptable Partly (via macros ) Yes Hackable No Yes (*) Unfortunately, we must acknowledge that using network licenses turned out to be quite problematic. Weeks of unexpected downtime were experienced, due to puzzling issues related to the interplay between the self-hosted license server, firewalls, VPN and end-devices. (**) We used the excellent Potree Free and Open Source software for visualization. The following sections are devoted to brief descriptions of these two tools; further details will be provided in Section 4 and Section 5 .","title":"1.5 Off-the-shelf software"},{"location":"PROJ-TREEDET/#2-method","text":"As already stated, in spite of the thorough and ambitious objectives of this project (cf. here ), only the tree detection and trunk geolocation sub-tasks could be tackled given the resources (time, humans) which were allocated to the STDL. The method we followed goes through several steps, pre-processing, running Terrascan or DFT, post-processing, which are documented here-below.","title":"2. Method"},{"location":"PROJ-TREEDET/#21-pre-processing-point-cloud-reclassification-and-cleaning","text":"[1] In some cases, points corresponding to trunks may be misclassified and lay in class 0 \u2013 Unclassified instead of class 4 \u2013 Medium vegetation . As the segmentation process only takes vegetation classes (namely classes 4 and 5) into account, the lack of trunk points can make some trees \"invisibles\". [2] We suspected that the standard classification of vegetation in LiDAR point clouds could be too basic for the task at hand. Indeed, vegetation points found at less (more) than 3 m above the ground are classified as 4 \u2013 Medium Vegetation ( 5 \u2013 High Vegetation ). This may cause one potential issue: all the points of a given tree that are located at up to 3 meters above the ground (think about the trunk!) belong to a class (namely class no. 4) which can also be populated by bushes and hedges. The \"contamination\" by bushes and hedges may spoil the segmentation process, especially in situations where dense low vegetation exists around higher trees. Indeed, it was acknowledged that in such situations the segmentation algorithm fails to properly identify trunk locations and distinguish one tree from another. Issues [1] and [2] can be solved or at least mitigated by reclassifying and cleaning the input point cloud, respectively. Figures 2.1 and 2.2 show how tree grouping (or \"segmentation\") yields better results if pre-processed pointclouds are used. Figure 2.1: Tree grouping (or \"segmentation\") applied to the original (top panel) vs pre-processed (bottom) point cloud. Without pre-processing, two trees connected by a hedge are segmented as one single individual. Therefore, only one detection is made (green circle slightly above the ground). With pre-processing, we get rid of the hedge and recover the lowest trunk points belonging to the tree on the left. Eventually, both trees are properly segmented and we end up having two detections (green circles). Figure 2.2: Tree grouping (or \"segmentation\") applied to the original (left panel) vs reclassified (right) point cloud. Without pre-processing, segmentation yields a spurious detection (= false positive, red circle slightly above the ground), resulting from the combination of a pole and a hedge. With pre-processing, we get rid of most of the points belonging to the hedge and the pole; no false positive shows up.","title":"2.1 Pre-processing: point cloud reclassification and cleaning"},{"location":"PROJ-TREEDET/#22-running-terrascan","text":"Terrascan offers multiple ways to detect trees from point clouds. In this project, we focused on the fully automatic segmentation, which is available through the \"Assign Groups\" command. As already said (cf. here ), two methods are available: highest point (aka \"watershed\") method and trunk method. In what follows, we introduce the reader to the various parameters that are involved in such methods.","title":"2.2 Running Terrascan"},{"location":"PROJ-TREEDET/#23-running-dft","text":"As already said, DFT consists of a collection of functions which can be run either with Octave or MATLAB . The former software was used in the frame of this context. A few custom Octave scripts were written to automatize the exploration of the parameter space. Our preliminary, warm-up tests showed that we could not obtain satisfactory results by using the \"tree top detection method\" (cf. here ). Indeed, upon using this method the F1-score topped at around 40%. Therefore, we devoted our efforts to exploring the parameter space of the other available method, namely the \"tree stem detection method\" (cf. this tutorial ). In the following, we provide a brief description of the various parameters involved in such a detection method.","title":"2.3 Running DFT"},{"location":"PROJ-TREEDET/#24-post-processing-assessment-algorithm-and-metrics-computation","text":"As already said, the STDL used a couple of third-party tools, namely TerraScan and the Digital Forestry Toolbox (DFT) , in order to detect trees from point clouds. Both tools can output a segmented point cloud, in which points associated to the same tree are assigned the same identifier; one (X, Y, Z) triplet per detected tree, where the X, Y and Z (optional) coordinates are computed either as the centroid of all the points which get associated to a given tree, or - under some conditions - as the centroid of the trunk only; expressed in the same reference system as the input point cloud. As the ground truth data the STDL was provided with take the form of one (X', Y') pair per tree, with Z' implicitly equal to 1 meter above the ground, the comparison between detections and ground truth trees could only be performed on the common ground of 2D space. In other words, we could not assess the 3D point clouds segmentations obtained by either TerraScan or DFT against reference/ground truth segmentations in the 3D space. The problem which needed to be solved amounts to finding matching and unmatching items between two sets of 2D points: a 1st set including the (X', Y') coordinates of ground truth trees; a 2nd set including the (X, Y) coordinates of detected trees. In order to fulfill the requirement of a 1 meter accuracy which was set by the beneficiaries of this project, the following matching rule was adopted: a detection (D) matches a ground truth tree (GT) (and vice versa) if and only if the Cartesian distance between D and GT is less or equal to 1 meter Figure 2.9 shows how such a rule would allow one to tag detections as either True Positives (TPs) or False Positives (FPs) ground truth trees as either True Positives (TPs) or False Negatives (FNs) in the most trivial case. Figure 2.9: Tagging as True Positive (TP), False Positive (FP), False Negative (FN) ground truth and detected trees in the most trivial case. Actually, far less trivial cases can arise, such as the one illustrated in Figure 2.10. Figure 2.10: Only one detection can exist for two candidate ground truth trees, or else two detections can exist for only one candidate ground truth tree. The STDL designed and implemented an algorithm, which would produce relevant TP, FP, FN tags and counts even in such more complex cases. For instance, in a setting like the one in the image here above, one would expect the algorithm to count 2 TPs, 1 FP, 1 FN. Details are provided here below.","title":"2.4 Post-processing: assessment algorithm and metrics computation"},{"location":"PROJ-TREEDET/#3-results-and-discussion","text":"Figure 3.1 shows some of the tree detection trials we performed, using Terrascan and DFT. Each trial corresponds to a different set of parameters and is represented either by gray dots or colored diamonds in a precision-recall plot (see the image caption for further details). Figure 3.1: Precision vs. Recall of a subset of the tree detections we attempted, using different parameters in Terrascan and DFT. Colored diamonds represent the starting point (red) as well as our \"last stops\" in the parameter space, with (yellow, green) and without (orange) pre-processing. All the three test sectors are here combined. Let us note that: the DFT parameter space can be conveniently explored by scripting the batch execution of various runs; on the contrary, the exploration of the Terrascan parameter space is more laborious, has to be performed manually, trying out one specific set of parameters after another, with repeated manual export of features (including geographical coordinates) in between. Indeed, although Terrascan let users define macros, unfortunately the \"Write Group Info\" command cannot be used in macros; in both cases, the parameter space was explored in quite an heuristic and partial way; we aimed at optimizing the F1-score all sectors combined. More detailed comments follow, concerning the best trials made with Terrascan and DFT.","title":"3. Results and discussion"},{"location":"PROJ-TREEDET/#31-the-best-trial-made-with-terrascan","text":"Among the trials we ran with Terrascan, the one which yielded the best F1-score was obtained using the following parameters: Parameter Value Method / Algorithm Trunk Classes 4+5, cleaned and reclassified Group planar surfaces Off Min height 3.00 m Max diameter 0.40 m Min trunk 3.00 m Group by density On Gap Auto Require 1500 pts This trial corresponds to the green diamond shown in Figure 3.1. Figure 3.2: Test sectors as segmented by the best trial made with Terrascan. Figure 3.2 provides a view of the outcome on the three test sectors. Metrics read as follows: Sector TP FP FN Detectable (TP+FN) Precision Recall F1-Score Global 323 137 234 557 70.2% 58.0% 63.5% Adrien-Jeandin 177 69 160 337 72.0% 52.5% 60.7% Bel-Air 114 15 11 125 88.4% 91.2% 89.8% Floraire 32 53 63 89 37.6% 33.7% 35.6% Figure 3.3 provides a graphical representation of the same findings, with the addition of the metrics we computed before cleaning and reclassifying the LiDAR point cloud. Figure 3.3: Cleaning and reclassifying the point cloud has a positive influence on precision and recall, although modest. Our results confirm that the tree detection task is more or less hard depending on the sector at hand. Without any surprise, we acknowledge that: the \"Avenue de Bel-Air\" test sector (BEL), enjoying an alley of well-separated trees, is easily tackled by Terrascan. Quite decent precision and recall are obtained. In contrast, the \"Parc Floraire\" test sector (FLO) turns out to be the hardest one, given the vegetation density and heterogeneity. The \"Adrien-Jeandin\" (ADR) is actually a mix of dense and sparse contexts and turns out to be a good proxy for the global performance. Cleaning and Reclassification have a benificial impact on Precision and Recall for all sectors as well as the global context (TOT). While for BEL mainly Recall profited from preprocessing, ADR and FLO showed a stronger increase in Precision. For the global context both, Precision and Recall, could be increased slighty. Figure 3.4: The F1-score attained by our best Terrascan trial. Figure 3.4 shows how our best Terrascan trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that pre-processing slightly improves the F1-score for the global context as well as for the individual sectors. The largest impact was observed for the Bel-Air sector, especially for preprocessing including Reclassification.","title":"3.1 The best trial made with Terrascan"},{"location":"PROJ-TREEDET/#32-the-best-trial-made-with-dft","text":"The DFT trial yielding the highest global F1-score was obtained using the stem detection method and the following parameters: Parameter Value Method / Algorithm Stem detection Classes 4+5, cleaned and reclassified Search radius 4.00 Minimum length 4.00 Here's a summary of the resulting metrics: Sector Precision Recall F1-score Adrien-Jeandin 75.4% 36.5% 49.2% Bel-Air 88.0% 82.4% 85.1% Floraire 47.9% 36.8% 41.7% Global 74.0% 46.6% 57.2% Similar comments to those formulated here apply: the \"Avenue de Bel-Air\" sector remains the easiest to process; \"Parc Floraire\" the hardest. However, here we acknowledge a bigger gap between the global F1-score and the F1-score related to the \"Adrien-Jeandin\" test sector. Figure 3.5 shows how our best DFT trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that the impact of point cloud reclassification can be slightly positive or negative depending on the test sector. Figure 3.5: The F1-score attained by our best DFT trial.","title":"3.2 The best trial made with DFT"},{"location":"PROJ-TREEDET/#33-comparison-terrascan-vs-dft","text":"Figure 3.6: Comparison of Terrascan and DFT in terms of F1-score. The comparison of the best Terrascan trial vs. the best DFT trial in terms of F1-score shows that there is no clear winner (see Figure 3.6). Still, we can notice that: DFT reaches the best F1-score ever in the \"Parc Floraire\" (\"Avenue de Bel-Air\") sector, without (with) pre-processing. Terrascan performs slightly better on global scores and substantially better on the mixed context of the Adrien-Jeandin sector,especially after pre-processing.","title":"3.3 Comparison: Terrascan vs. DFT"},{"location":"PROJ-TREEDET/#34-trials-with-standard-density-datasets","text":"In addition to applying our method to the 2021 high-density (HD) LiDAR dataset, we also tried using two other datasets exhibiting a by far more standard point density (20-30 pt/m\u00b2): Nuage de points LiDAR 2017 Nuage de points LiDAR 2019 The goal was twofold: finding evidence for the added value of high-density (HD) datasets, despite their higher cost; checking whether the parameters which turned out to yield optimal scores with HD LiDAR data could also yield acceptable results if used with standard-density (SD) datasets. Concerning the 1st point, lower point densities make the \"trunk method\" unreliable (if not completely unusable). In Figure 3.7, we report results obtained with the watershed method, along with results related to the best performing trials obtained with the 2021 HD dataset. The scores we obtained with the SD dataset are far below the best we obtained with the HD dataset, confirming the interest of high-density acquisitions. Figure 3.7: Comparison of F1-scores of the best performing trials. Parameters were optimized for each model individually. Concerning the 2nd point, without any surprise we confirmed that parameters must be re-optimized for SD datasets. The usage of the set of parameters which were optimized on the basis of the HD dataset yielded poor results, as shown in Figure 3.8. Figure 3.8: Using the parameters which were optimized for the high-density dataset leads to poor results (strong under-segmentation) on SD datasets. In accordance with the TS documentation we can see that the trunk method is unusable for lower and medium density datasets. The watershed algorithm produces a more realistic segmentation pattern on the SD dataset but still cannot reach the performance levels of the trunk or the watershed method on the HD dataset. After optimizing parameters, we could obtain quite decent results though (see Figure 3.9). Figure 3.9: After a dataset-specific parameter optimization, convincing results can be achieved on the medium-density 2019 dataset (Terrascan's watershed method was used).","title":"3.4 Trials with standard-density datasets"},{"location":"PROJ-TREEDET/#35-tree-detection-over-the-full-2021-high-density-lidar-dataset","text":"Clearly, from a computational point of view processing large point cloud dataset is not the same as processing small datasets. Given the extremely high density of the 2021 LiDAR datasets, we wanted to check whether and how Terrascan could handle such a resource-intensive task. Thanks to Terrascan's macro actions, one can split the task into a set of smaller sub-tasks, each sub-task dealing with a \"tile\" of the full dataset. Additionally, Terrascan integrates quite a smart feature, which automatically merges groups of points ( i.e. trees) spanning multiple tiles. Figure 3.10 provides a static view of the results we obtained, using the parameters which globally performed the best on the three sectors. We refer the reader to this Potree viewer (kindly hosted by the G\u00e9oportail du SITN ) for an interactive view. Figure 3.10: Result of the application of the best performing Terrascan parameters to the full dataset.","title":"3.5 Tree detection over the full 2021 high-density LiDAR dataset"},{"location":"PROJ-TREEDET/#4-conclusion-and-outlook","text":"Despite all the efforts documented here above, the results we obtained are not as satisfactory as expected. Indeed, the metrics we managed to attain all sectors combined indicate that tree detections are neither reliable (low precision) nor exhaustive (low recall). Still, we think that results may be improved by further developing some ideas, which we sketch in the following.","title":"4. Conclusion and outlook"},{"location":"PROJ-TREEDET/#41-further-the-dft-parameter-space-exploration","text":"We devoted much more time to exploring Terrascan's parameter space than DFT's. Indeed, as already stated here , we only explored the two parameters searchRadius and minLenght . Other parameters such as cellSize , bandwidth and verticalStep were not explored at all (we kept default values). We think it is definitely worth exploring these other parameters, too. Moreover, we did not try feeding all the LiDAR returns to the stem detection method, we only used the last returns. It is surely worth checking whether the usage of the other returns could be beneficial. Upon using the peak detection method, we did not manage to reach a better F1-score than ~40%, as opposed to the 57% obtained with the stem detection method. However, the peak detection method is particularly interesting because it can also delimit canopies. Hence, it may be worth trying to improve the F1-score, for instance by tuning the parameters of the power law equation relating the crown radius to the tree height (cf. here ).","title":"4.1 Further the DFT parameter space exploration"},{"location":"PROJ-TREEDET/#42-exploit-contextual-information","text":"We showed that the algorithms implemented by TerraScan and DFT yield much better results in sparse contexts (ex.: the \"Avenue de Bel-Air\" test sector) than in dense ones (ex.: the \"Parc Floraire\" test sector). This means that precision may be improved (at the expense of recall, though) if one could restrain the tree detection to sparse contexts only, either as a pre- or post-processing step. We can think of at least a couple of methods which would allow one to (semi-)automatically tell sparse from dense contexts: intrinsic method: after segmenting the point cloud into individual trees, one could analyze how close (far) each individual is to (from) the nearest neighbor and estimate the density of trees on some 2D or 3D grid; extrinsic method: territorial data exist (see for instance the dataset \"Carte de couverture du sol selon classification OTEMO\" distributed by the SITG ), providing information about urban planning and land use ( e.g . roads, parks, sidewalks, etc.). These data may be analyzed in order to extract hints on how likely it is for a tree to be in close proximity with another, according to its position.","title":"4.2 Exploit contextual information"},{"location":"PROJ-TREEDET/#43-combine-detections-stemming-from-two-or-more-independent-trials","text":"Detections coming from two or more independent trials (obtained with different software or else with the same software but different parameters) could be combined in order to improve either precision or recall: recall would be improved (i.e. the number of false negatives would be reduced) if detections coming from multiple trials were merged. In order to prevent double counting, two or more detections coming from two or more sources could be counted as just one if they were found within a given distance from each other. The algorithm would follow along similar lines as the ones which led us to the \"tagging and counting algorithm\" presented here above ; precision would be improved (i.e. the number of false positives would be reduced) if we considered only those detections for which a consensus could be established among two or more trials, and discarded the rest. A distance-based criterion could be used to establish such consensus, along similar lines as those leading to our \"tagging and counting algorithm\" .","title":"4.3 Combine detections stemming from two or more independent trials"},{"location":"PROJ-TREEDET/#44-use-generic-point-cloud-segmentation-algorithms","text":"Generic ( i.e. not tailored for tree detection) clustering algorithms exist, such as DBSCAN (\"Density-Based Spatial Clustering of Applications with Noise\", see e.g. here ), which could be used to segment a LiDAR point cloud into individual trees. We think it would be worth giving these algorithms a try!","title":"4.4 Use generic point cloud segmentation algorithms"},{"location":"PROJ-TREEDET/#45-use-machine-learning","text":"The segmentation algorithms we used in this project do not rely on Machine Learning. Yet, alternative/complementary approaches might me investigated, in which a point cloud segmentation model would be first trained on reference data, then used to infer tree segmentations within a given area of interest. For instance, it would be tempting to test this Deep Learning model published by ESRI and usable with their ArcGIS Pro software. It would be also worth deep diving into this research paper and try replicating the proposed methodology. Regarding training data, we could generate a ground truth dataset by using our best TerraScan/DFT model to segment the 3D point cloud; using 2D ground truth data to filter out wrong segmentations.","title":"4.5 Use Machine Learning"},{"location":"PROJ-TREEDET/#5-other-resources","text":"The work documented here was the object of a Forum SITG which took place online on March 29, 2022. Videos and presentation materials can be found here .","title":"5. Other resources"},{"location":"PROJ-TREEDET/#6-acknowledgements","text":"This project was made possible thanks to a tight collaboration between the STDL team and some experts of the Canton of Neuch\u00e2tel (NE), the Canton of Geneva (GE), the Conservatoire et Jardin botaniques de la Ville de Gen\u00e8ve (CJBG) and the University of Geneva (UNIGE). The STDL team acknowledges key contributions from Marc Riedo (SITN, NE), Bertrand Favre (OCAN, GE), Nicolas Wyler (CJBG) and Gregory Giuliani (UNIGE). We also wish to warmly thank Matthew Parkan for developing, maintaining and advising us on the Digital Forestry Toolbox .","title":"6. Acknowledgements"},{"location":"TASK-4RAS/","text":"TASK-4RAS - HR, NH \u00b6 Schedule : September 2020 to February 2021 (initially planned from August 2021 February 2022) This document describe the state of an ongoing task (DIFF) and is subject to daily revision and evolution Context \u00b6 The 4D platform developed at EPFL with the collaboration of Cadastre Suisse is able to ingest both large scale point-based and vector-based models. During the previous development, the possibility to have this different type of data in a single framework lead to interesting results, showing the interest to have the possibility to put this different type of data into perspectives. Illustrations of mixed models in the 4D platform : INTERLIS, Mesh and LIDAR - Data : SITN Taking into account point-based and vector-based model allows to almost cover all type of data that are traditionally considered for land registering. The only type of data that is currently missing is the two-dimensional rasters. Indeed, due to their nature, image are more complicated to put in perspective of other three-dimensional data. The goal of this task is then to address the management of the raster by the platform in order to be able to ingest, store and broadcast any type of data with the 4D platform. Specifications \u00b6 In order to address this task, a step-by-step approach is defined. In the first place, a set of data has to be gathered from the STDL partners : Gathering a dataset of geo-referenced ortho-photography of a chosen place of reasonable size The dataset has to provide ortho-photography for at least two different times The format of the dataset has to be analyzed in order to be able to extract the image pixels with their position (CH1903+) As the platform indexation formalism is not straightforward, the images are treated as point-based model, each pixel being one colored point of the model. This will allow to provide a way of starting to analyze and understand the indexation formalism while having first results on image integration : Transform images into simple point-based models (each pixel being one point) Injection of the point-based model in an experimental instance of the platform Understanding the indexation formalism for point-based models and, subsequently, its adaptation for the vector-based models As the indexation formalism is understood for point-based models, the following adaptation will be performed : removing the third dimension from the point-based indexation specifically for the image (flat indexation) At this point, a first reporting is required : Is there an advantage to add raster to such a platform in perspective of the other types of model (points, vectors, meshes) ? How the adaptation of the point-based indexation performs for images ? How taking advantage of color accumulation enrich the image integration ? What is the cost of rendering the image with the adaptation of the point-based indexation ? Based on the formulated answer, the following strategical choice has to be discussed : Would it be more efficient to integrate image keeping them as raster (deviation from the current indexation) ? Depending on the answer, a new set of specification will be decided (if this direction is favored). Depending on the remaining time and on the obtained results, the question of the time management in the platform will be addressed. Currently, the time is treated linearly in the platform and a multi-scale approach, as for the spatial dimensions, could be interesting. The specifications will be decided as the previous points will be fulfilled. Resources \u00b6 List of the resources initially linked to the task : liberatosthene - Platform and indexation back-end eratosthene-suite - Platform front-end Other resources will be provided according to requirements.","title":"**TASK-4RAS** - HR, NH"},{"location":"TASK-4RAS/#task-4ras-hr-nh","text":"Schedule : September 2020 to February 2021 (initially planned from August 2021 February 2022) This document describe the state of an ongoing task (DIFF) and is subject to daily revision and evolution","title":"TASK-4RAS - HR, NH"},{"location":"TASK-4RAS/#context","text":"The 4D platform developed at EPFL with the collaboration of Cadastre Suisse is able to ingest both large scale point-based and vector-based models. During the previous development, the possibility to have this different type of data in a single framework lead to interesting results, showing the interest to have the possibility to put this different type of data into perspectives. Illustrations of mixed models in the 4D platform : INTERLIS, Mesh and LIDAR - Data : SITN Taking into account point-based and vector-based model allows to almost cover all type of data that are traditionally considered for land registering. The only type of data that is currently missing is the two-dimensional rasters. Indeed, due to their nature, image are more complicated to put in perspective of other three-dimensional data. The goal of this task is then to address the management of the raster by the platform in order to be able to ingest, store and broadcast any type of data with the 4D platform.","title":"Context"},{"location":"TASK-4RAS/#specifications","text":"In order to address this task, a step-by-step approach is defined. In the first place, a set of data has to be gathered from the STDL partners : Gathering a dataset of geo-referenced ortho-photography of a chosen place of reasonable size The dataset has to provide ortho-photography for at least two different times The format of the dataset has to be analyzed in order to be able to extract the image pixels with their position (CH1903+) As the platform indexation formalism is not straightforward, the images are treated as point-based model, each pixel being one colored point of the model. This will allow to provide a way of starting to analyze and understand the indexation formalism while having first results on image integration : Transform images into simple point-based models (each pixel being one point) Injection of the point-based model in an experimental instance of the platform Understanding the indexation formalism for point-based models and, subsequently, its adaptation for the vector-based models As the indexation formalism is understood for point-based models, the following adaptation will be performed : removing the third dimension from the point-based indexation specifically for the image (flat indexation) At this point, a first reporting is required : Is there an advantage to add raster to such a platform in perspective of the other types of model (points, vectors, meshes) ? How the adaptation of the point-based indexation performs for images ? How taking advantage of color accumulation enrich the image integration ? What is the cost of rendering the image with the adaptation of the point-based indexation ? Based on the formulated answer, the following strategical choice has to be discussed : Would it be more efficient to integrate image keeping them as raster (deviation from the current indexation) ? Depending on the answer, a new set of specification will be decided (if this direction is favored). Depending on the remaining time and on the obtained results, the question of the time management in the platform will be addressed. Currently, the time is treated linearly in the platform and a multi-scale approach, as for the spatial dimensions, could be interesting. The specifications will be decided as the previous points will be fulfilled.","title":"Specifications"},{"location":"TASK-4RAS/#resources","text":"List of the resources initially linked to the task : liberatosthene - Platform and indexation back-end eratosthene-suite - Platform front-end Other resources will be provided according to requirements.","title":"Resources"},{"location":"TASK-DIFF/","text":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT \u00b6 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF September 2020 to November 2020 - Published on December 7, 2020 Abstract : Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Task Context : Difference Detection \u00b6 As the implemented indexation formalism is based on equivalences classes defined on space and time, a natural discretization along all the four dimensions is obtained. In the field of difference detection, it allowed implementing simple logical operators on the four-dimensional space. The OR , AND and XOR operators were then implemented allowing the platform to compute, in real time , convolutions to compare models with each others across the time. The implementation of these operators was simple due to the natural spatio-temporal discretization obtained from the indexation formalism. Nevertheless, two major drawbacks appeared : the first one is that such operators only works for point-based models. Having the opportunity to compute and render differences and similarities between any type of data is not possible with such formal operators. The second drawback comes from the nature of the point-based capturing devices. Indeed, taking the example of a building, even without any change to its structure, two digitization campaigns can lead to disparities only due to measures sampling. The XOR operator is the natural choice to detect and render differences, but this operator is very sensitive to sampling disparities. Computing the XOR convolution between two point-based models leads the rendering to be dominated by sampling variations rather than the desired structural differences. This drawback was partially solved by considering the AND operator. Indeed, the AND operator allows to only shows constant structural elements from two different positions in time and is insensitive to sampling disparities. As shown on the following images, the AND operator shows differences as black spots (missing parts) : AND convolution between two LIDAR models : Geneva 2005 and 2009 - Data : SITG As one can see, AND convolutions allow detecting, through the black spots, large area of structural changes between the two times and also, with more care, allow guessing smaller differences. Nevertheless, reading and interpreting such representation remains complex for users. The goal of this task is then to tackle these two drawbacks, allowing the platform to detect changes not only for point-based models but also for vector-based models and to implement a variation of the XOR operator for point-based models allowing to efficiently highlight the structural evolution. The task consists then in the implementation, testing and validation of a difference detection algorithm suitable for any type of model and to conduct a formal analysis on the best rendering techniques. Methodology \u00b6 A step by step methodology is defined to address the problem of difference detection in the platform. In a first phase, the algorithm will be developed and validated on vector-based models as follows : Obtaining a large scale vector-based model on which synthetic variation are introduced Development of the algorithm using the synthetic variations model Testing and validation of the algorithm (using the known synthetic variations) First conclusion In a second phase, true land register data will be used to formally detect real evolutions of the territory : Obtaining true land register vector-based models (INTERLIS) at different times Analysis of the difference detection algorithm on true land register vector-based models Second conclusion In a third phase, the algorithm will be validated and adapted to work on point-based models : Obtaining true land register point-based models (LAS) at different position in time Verifying the performances of the vector-based detection algorithm on point-based data Adaptation of the algorithm for point-based models Analysis of the difference detection algorithm on true land register point-based models Comparison of the detected differences on point-based models and on their corresponding land register vector-based models (INTERLIS) Third conclusion In addition, the development of difference detection algorithm has to be conducted keeping in mind the possible future evolutions of the platform such as addition of layers (separation of data), implementation of a multi-scale approach of the time dimension and addition of raster data in the platform. First Phase : Synthetic Variations \u00b6 In order to implements the vector-based difference detection algorithm, sets of data are considered as base on which synthetic differences are applied to simulate the evolution of the territory. This approach allows focusing on well controlled data to formally benchmark the results of the implemented algorithm. Experiments are conducted using these data to formally evaluate the performance of the developed algorithm. Selected Resources and Models \u00b6 Vector Models : Line-based \u00b6 In this first phase, line-based data are gathered from openstreetmap in order to create simple models used during the implementation and validation of the detection algorithm. A first set of vector-based models are considered made only of lines. Three sets are created each with a different scale, from city to the whole Switzerland. The line-based sets of data are extracted from openstreetmap shapefiles and the elevations are restored using the SRTM geotiff data. The EGM96-5 geoid model is then used to convert the elevation from MSL to ellipsoid heights. The following images give an illustration of these sets of data : Line-based data-sets : Switzerland - Data : OSM The following table gives a summary of the models sizes and primitives count : Model Size (UV3) Primitive Count Frauenfeld 5.0 Mio 93.3 K-Lines Neuch\u00e2tel 33.1 Mio 620.2 K-Lines Switzerland 1.3 Gio 25.0 M-Lines In order to simulate evolution of the territory in time, synthetic variations are added to these models. A script is developed and used to insert controlled variations on selected primitives. The script works by randomly selecting a user-defined amount of primitives of a model and by adding a variation on one of its vertex position using a user-specified amplitude. The variation is applied on the three dimensions of space. Vector Models : Triangle-based \u00b6 A second set of triangle-based models is also considered for implementing and validating the difference detection algorithm. The selected model is a mesh model of the Swiss buildings provided by swisstopo . It comes aligned in the CH1903+ frame with elevations. It is simply converted into the WGS84 frame using again the EGM96-5 geoid model : Triangle-based data-sets : Switzerland - Data : swisstopo The following table gives a summary of the models sizes and primitives count : Model Size (UV3) Primitive Count Frauenfeld 116.9 Mio 1.4 M-Triangles Neuch\u00e2tel 842.2 Mio 10.5 M-Triangles Switzerland 30.5 Gio 390.6 M-Triangles These models are very interesting for difference detection as the ratio between primitive size and model amplitude is very low. It means that all the primitives are small according to the model coverage, especially for the Switzerland one. The developed script for line-based models is also used here to add synthetic variations to the models primitives in order to simulate an evolution of the territory. Models : Statistical Analysis \u00b6 Before using the models in the following developments, a statistical analysis is performed on the two Switzerland models, line and triangle-based. Each primitive of these two models are considered and their edges size are computed to deduce their distribution : Statistical analysis : Models primitive edge size distribution, in meters, for the Switzerland models : line-based (left) and triangle-based (right) One can see that the line-based model comes with a much more broad distribution of the primitives size . Most of the model is made from lines between zero and twenty meters. In the case of the triangle-based models, the primitives are much smaller. As most of them are less than ten meters, a significant fraction of primitives is below one meter. Implementation of the Algorithm \u00b6 In order to compare two models at two different positions in time to detect differences, the solution is of course to search for each primitive of the primary time if it has a corresponding one in the secondary time. In such case, the primitives can be concluded as static in time and only the primitives that have no correspondence will be highlighted as differences. A first approach was initially tested : a vertex-based comparison. As every primitive (points, lines and triangles) is supported by vertexes, it can be seen as a common denominator on which comparison can take place. Unfortunately, it is not a relevant approach as it leads to an asymmetric detection algorithm. To illustrate the issue, the following image shows the situation of a group of line-based primitives at two different times with an evolution on one of the primitive vertex : Asymmetric approach : The variation is detected only when comparing backward in time When the comparison occurs between the second time and the first one, the modified vertex correspondence is not found, and the vertex can be highlighted as a difference. The asymmetry appears as the first time is compared to the second one. In this case, despite the primitive vertex changed, the vertex-based approach is able to find another vertex, part of another primitive, and interprets it as a vertex identity, leading the modified primitive to be considered as static. In order to obtain a fully symmetric algorithm, that does not depend on the way models are compared in times, a primitive-attached approach is considered. The implemented algorithm then treats the correspondence problem from the whole primitive point of view, by checking that the whole primitive can be found in the other model to which it is compared to. This allows to highlight any primitive showing a modification, regardless of the way models are compared and the nature of the modification. In addition to highlighting the primitives that changed through time, the implemented algorithm also renders the primitives that have not changed. The primitives are then shown by modulating their color to emphasize the modifications by keeping their original color for the modified one, while the static primitives are shown in dark gray. This allows to not only show the modifications but also to keep the context of the modifications, helping the user to fully understand the nature of the territory evolution. In addition to color modulation, a variation of difference rendering is analyzed. In addition to color modulation, a visual and artificial marker is added to ease their search. The visual marker is a simple line emanating from the primitive and goes straight up with a size of 512 meters. Such markers are introduced to ease the detection of small primitives that can be difficult to spot according to large point of views. Additional developments were required for triangle-based models : indeed, such models need to be subjected to a light source during rendering for the user to understand the model (face shading). The previously implemented lighting model is then modified to take into account color modulation in order to correctly render the triangle that are highlighted. Moreover, the lighting model was modified to light both face of the triangles in order to light them regardless of the point of view. In addition, as mesh models are made of triangles, primitives can hide themselves. It can then be difficult for the user to spot the highlighted primitives as they can be hidden by others. An option was added to the rendering client allowing the user to ask the rendering of triangles as line-loops or points in order to make them transparent. Finally, an option allowing the user to enable or disable the render face culling was added for him to be able to see the primitive from backward. Results and Experiments \u00b6 With the implemented algorithm, a series of experiments are conducted in order to validate its results and to analyze the efficiency of the difference detection and rendering from a user point of view. In addition, experiments are also conducted to quantify the efficiency of the difference detection for automated processes. Difference Detection : Overview \u00b6 Considering the selected data-sets, each original model is injected at a given time and synthetic variations are added to a copy of it to create a second model injected at another time. The synthetic variations are randomly added to a small amount of primitives of the original model and are of the order of one meter. On the following examples, the detection is operated considering the original model as primary and the modified one as secondary. The following images show examples of how the detection algorithm allows to highlight the detected differences while keeping the rest of the model using a darker color in case of line-based models : Example of difference detection on line-based Frauenfeld (left) and Neuch\u00e2tel (right) models - Data : OSM One can see how the modified primitives are highlighted while keeping the context of the modifications. The highlighted primitive is the one belonging to the primary time. Comparing the models in the other way around would lead the secondary model primitives to be highlighted. Considering the Frauenfeld example, the following images show the situation in the primary time (original model) and the secondary time (model with synthetic variations) : Primary model (left) and secondary one (right) showing the formal situations - The modified primitive is circled in read - Data : OSM As a result, the user can choose between the differences highlighting with the choice of model as primary and can also switch back and worth between the models themselves though the platform interface. Of course, the readability of the difference detection models depends on the size of the modified primitive and the scale at which the model is looked at by the user. If the user adopts a large scale point of view, the differences, even highlighted, can become difficult to spot. This issue can be worsened as triangle-based models are considered. In addition to primitive size, triangles also bring occlusions. The visual markers added to the highlighted primitives can considerably improve ease of differences search by the user. The following images give an example of difference detection without and with the visual markers added by the algorithm : Example of highlighted primitives without (left) and with (right) visual markers - Data : OSM Considering the triangle-based models, difference detection is made more complicated by at least three aspects : the first one is that 3D vector models are more complex than 2D ones in the way primitives (triangles) are more densely packed in the same regions of space in order to correctly model the buildings. The second one is that triangles are solid primitives that bring occlusions in the rendering, hiding other primitives. The last aspect is that such a model can contain very small primitives in order to model the details of the buildings. In such a case, the primitives can be difficult to see, even when highlighted. The following images show an example of highlighted triangles on the Frauenfeld model : Example of highlighted primitive on the Frauenfeld building model - Data : swisstopo On the right image above, the highlighted triangle is underneath the roof of the house, forcing the user to adopt an unconventional point of view (from above the house) to see it. In addition, some primitives can be defined fully inside a volume close by triangles, making them impossible to see without going inside the volume or playing with triangle rendering mode. In such a context, the usage of the visual markers become very important for such models coming with large amount of occlusion and small primitives : Example of highlighted primitives without (left) and with (right) visual markers - Data : swisstopo In case of triangle-based models, the usage of markers appears to be mandatory in order for the user to be able to locate the position of the detected differences in a reasonable amount of time. Difference Detection : User-Based Experiments \u00b6 In any case, for both line and triangle-based models, the difference detection algorithm is only able to highlight visible primitives. Depending on the point of view of the user, part of the primitives are not provided by the platform because of their small size. Indeed, the whole point of the platform is to allow the user to browse through arbitrary large models, which implies to provided only the relevant primitives according to its point of view. As a result, the detection algorithm will not be able to highlight the variations as the involved primitives are not considered as a query answer by the platform. The user has then to reduce is point of view in order to zoom on the small primitives to make them appear, and so, allowing the algorithm to highlight them. In order to show this limitation, an experiment is performed. For each model, a copy is made on which eight synthetic differences are randomly introduced. The variations are of the order of one meter. The models and their modulated copy are injected in the platform. The rule is the following : the user uses the detection algorithm on each model and its modulated copy and has five minutes to detect the eight differences. Each time a difference is seen by the user, the detection time is kept. The user is allowed to use the platform in the way he wants. In each case, the experiment is repeated five times to get a mean detection rate. As one could ask, these measures are made by the user and are difficult to understand without a reference. In order to provide such reference, the following additional experiment is conducted : each model and its modulated copy are submitted to a naive automated detection process. This process parses each primitive of the original model to search in its modulated copy if the primitive appear. If the primitive is not found, the process trigger a difference detection. This process is called naive as it simply implements two nested loops, which is the simplest searching algorithm implementation. The process is written in C with full code optimization and executed by a single thread. Starting with the line-based models, the following figures shows the difference detection rates according to time. For each of the three models, the left plots show the rate without visual markers, the middle ones with visual markers and the right ones the naive process detection rate : Frauenfeld : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Canton of Neuch\u00e2tel : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Switzerland : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process As expected, the larger the model is, the more difficult it is for the user to find the highlighted differences, with or without visual markers. Considering a city, the differences, even of the order of one meter, are easy to spot quickly. As the model gets larger, the more time it takes for the user to find the differences. On a model covering a whole canton (Neuch\u00e2tel), one can see that most of the differences are detected in a reasonable amount of time despite their small size according to the overall model. On the Swiss model, things get more complicated, as simply looking at each part of the country is already complicated in only five minutes, leading the detection rate to be lower, even using the visual markers. These results are consistent with the statistical analysis made on the line-based Switzerland model. Detection on a city or even a whole canton lead the user to adopt a point of view sufficiently close to make most of the primitives appearing. For the Switzerland model, the user is forced to adopt a larger point of view, leading to a significant proportion of primitives to stay hidden. These results also show that adding visual markers to the highlighted primitives increases the user detection rate, meaning that the markers lead to a more suitable rendering from the user experience point of view. Considering the user results and the naive detection process, one can see that the user obtains at least similar results but most of the time outperforms the automated process. This allows to demonstrate how the implementation and data broadcasting strategy of the platform is able to provide an efficient way to access models and composite models, here in the context of difference detection. The following figures show the experiments results for the triangle-based models, which were not performed on the whole Switzerland model due to limited rendering capabilities : Frauenfeld : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Canton of Neuch\u00e2tel : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Similar conclusions apply for the triangle-based models : the larger the model is, the more difficult the difference detection is. These results also confirm that adding visual markers in addition to primitives highlighting significantly helps the user, particularly in case of triangle-based models. The obtained results on triangle-based models are lower than for line-based models. A first explanation is the greater amount of primitive that lead the user to spend more time at each successive point of view. The occlusion problem also seems to play a role, but to a lesser extent as the visual markers seems to largely solve it. The differences between detection on line and triangle-based models have to be searched in the statistical analysis of the triangle-based models. Indeed, for these models, a large proportion of the primitives are very small (less than a meter), leading them to be rendered only as the user adopts a close point of view, making the detection much more complicated in such a small amount of time. The triangle-based models being larger than the line-based one, the results of the naive process are very poor. As for the line-based models experiments, the user outperforms this automated process, in a much more significant way. Difference Detection : Process-Based Experiments \u00b6 In the previous experiments, the user ability to find the differences on the data-sets, using synthetic variations, was benchmark in perspective of the results provided by a naive automated process. The user performs quite well using the platform, but start to struggle as the data-sets get bigger according to the sizes of their primitives. In this second set of experiments, the platform is used through an automated process instead of a user. The process has the same task as the user, that is, finding the eight synthetic differences introduced in the models copy. The process starts with a list of index (the discretization cells of the platform) in order to query the corresponding data to the platform before to search for differences in each cell. The process implements, then, a systematic difference detection covering the whole model. In order for the process to work, it requires an input index list. To create it, the primitive injection condition of the platform is used to determine the maximal depth of these index. The following formula gives the poly-vertex (lines and triangles) primitives injection condition according to the platform scale. In other words, the formula gives the shallowest scale at which the primitive is considered through queries according to its size : where s gives the shallowest scale, R being the WGS84 major semi-axis and e is the largest distance, in meters, between the primitive first vertex and its other ones. For example, choosing s = 26 allows the index to reach any primitive that is greater than ~30 cm over the whole model covered by the index. The scale 26 is then chosen as the deepest search scale in the following experiments. This value can be adapted according to the primitives size and to the nature of the detection process. The larger it is, the more data are broadcast by the platform increasing the processing time. In order to compare the user-based experiments, the naive automated approach and this process-based exhaustive search, the same protocol is considered. The process addresses queries to the platform, based on the index list, and save the detection time of each difference. The detection rate is plot in the same way as for the previous experiments. Again, eight synthetic differences are randomly introduced and the experiment is repeated five times for the line-based model and only two times for the triangle-based model. As the scale 26 is chosen as the deepest search scale, the index list can be built in different ways. Indeed, as a query is made of one spatial index, that points at the desired cell, and an additional depth ( span ), to specify the density of data, the only constraint to maintain the deepest search scale at 26 is the following : where the two left hand side terms are the spatial index size and span value. In these experiments, a first list of index is built using a span of 9 and a second with a span of 10 . As the deepest scale is maintained constant, increasing the span reduces the index list size, but the queried cells contain more data to analyze. The following figures show the mean detection rate for the Switzerland lined-based model with the deepest scale at 26 and span at 9 and 10 . The plots are scaled in the same way as for the user-based experiments : Switzerland : The black curve shows the mean detection rate while the blue area gives the worst and best rates - Span at 9 (left) and 10 (right) One can see that the detection rate on such a model is much better than the user-based or naive approach ones. In a manner of five minutes, for the span set to 10 , the eight differences can be detected and reported. The full detection process took ~5 minutes with span set to 10 and ~8 minutes with the span set to 9 . This shows how the platform can be used by automated processes as an efficient data provider. In addition, as the data are queried by the automated process, the detected primitive geometry is directly available, allowing all sorts of subsequent processes to take place. As the deepest scale was set to 26 , in one of the five measures session, one of the eight differences was not detected (at all). It means that the primitive on which a synthetic variation was introduced is smaller than 30cm and was then not reached by any index. This shows the importance of defining the spatial index and spans according to the processes needs. For example, increasing the deepest scale to 27 would allow reaching primitive down to ~15 cm over the whole Switzerland, and so on. The following figures show the mean detection rate for the Switzerland triangle-based model. In this case, only two measure sessions were made to limit the time spent on this analysis : Switzerland : The black curve shows the mean detection rate while the blue area gives the worst and best rates - Span at 9 (left) and 10 (right) The conclusion remain, but the rate is slower in this case as the model contains much more primitives than the line-based one. In this case, the full detection process took ~15 minutes with span set to 10 and ~20 minutes with the span set to 9 . Again, in one of the two measure session, one difference was not detected due to the size of the primitive. Nevertheless, these results shows how the platform, seen as a process data provider, allows outperforming user-based and classic detection algorithms. Such process-based strategy can be performed in many ways depending on the needs. For example, the index list can be limited to a specific area or set to focus on spread and defined locations (for example at the intersection of the Swiss hectometric grid). The following image gives a simple example of how the detected differences can be leveraged. As the geometry of the differences is known by the process, a summary of the differences can be provided through a simple map : Example of a differences map based on the results of the detection process - Data : SRTM The eight synthetic differences are easily presented allowing a user to analyze them more in detail in the platform interface for example. This map was created detecting the eight differences on the line-based Switzerland model in about 5 minutes with a span set to 10 . Conclusion : First Phase \u00b6 During this first phase, the difference detection algorithm was developed and validated on both line-based and triangle-based data. An efficient algorithm is then implemented in the platform allowing emphasizing differences between models at different temporal positions. The algorithm is able to perform the detection on the fly with good performances allowing the users to dynamically browse the data to detect and analyze the territory evolutions. The performances of the detection algorithm allow the platform to be suitable for automated detection processes, as a data provider, answering large amounts of queries in an efficient and remote manner. Two variations of the difference detection algorithm are implemented. The first version consists in highlighting the primitives that are subject to modifications over a time. This variation is suitable for automated processes that can rely on simple search methods to list the differences. For the users, this first variation can lead to more difficult visual detection of the differences, especially in case the highlighted primitives are small or hidden by others. For this reason, visual markers were added on top of the highlighted primitives in order to be seen from far away, regardless of the primitives size. The measures sessions made during the user-based experiments showed a clear improvement of the detection rate when using the visual markers. This was especially true for triangle-based models, where the primitives bring occlusions. The user-based experiments showed that using the platform interface, a human can significantly outperform the result of a naive automated process operating on the models themselves. The experiments showed that the user is able to efficiently search and find through space and time the evolutions of the territory appearing in the data. Of course, as the model size and complexity increases, the user-driven interface starts to show its limits. In such a case, the process-based experiments showed that automated processes can take over these more complicated searches through methods allowing performing exhaustive detection over wide models in a matter of several minutes. At this point, the developments and validations of the algorithm, and its variations, were conducted on synthetic modifications introduced in models using controlled procedures. The next phase focuses on formal data extracted from land registers. Second Phase : True Variations \u00b6 In this second phase, also dedicated to vector-based models, the focus is set on applying the developed difference detection algorithm on true land register models. Two sets of data are considered in order to address short-term and long-term difference detection. Selected Resources and Models \u00b6 In both cases, short-term and long-term, INTERLIS data are considered. A selection of tables in different topics is performed to extract the most interesting geometries of the land registering. For all models, the following colors are used to distinguish the extracted layers : INTERLIS selected topics and tables colors - Official French and German designations The layers are chosen according to their geometric content. The color assignation is arbitrary and does not correspond to any official colorization standard. Short-Term Difference Detection : Thurgau \u00b6 For the short-term application of the difference detection algorithm, the case of the Thurgau canton is considered. Two set of INTERLIS data are considered that are very close in time, of the order of days. The selected layers are extracted from the source files before to be converted to the WGS84 frame using the EGM95-6 geoid model. The heights are restored using the SRTM topographic model. The following images give an illustration of the considered data : Canton of Thurgau (left) and close view of Frauenfeld (right) - Data : Kanton Thurgau Two INTERLIS models are considered with times 2020-10-13 and 2020-10-17, corresponding to the models gathering time. The following table gives the models size and primitives count : Model Size (UV3) Primitive Count Thurgau 2020-10-13 203.7 Mio 3.8 M-Lines Thurgau 2020-10-17 203.8 Mio 3.8 M-Lines As the two models are very close in time, they are very similar in size and content as the corrections count made during the considered time range is small. Long-Term Difference Detection : Geneva \u00b6 For the long-term difference detection analysis, the Geneva case is selected as the canton of Geneva keeps a copy of each land register model for each month from at least 2009 . This allows to compare INTERLIS models that are further away from each other from a temporal point of view. The selected layers are extracted and converted to the WGS84 coordinates system using the EGM96-6 geoid model. Again, the SRTM model is used to restore the heights. The following images give an illustration of the selected models : Canton of Geneva in 2019-04 (left) and close view of Geneva in 2013-04 (right) - Data : SITG The selected models are not chosen randomly along the time dimension. Models that corresponds to the Geneva LIDAR campaigns are selected as they are used in the next phase. In addition, as the LIDAR campaigns are well spread along the time dimension, the selected models are far away from each other in time, of the order of at least two years. The following table summarize the models size and primitives count : Model Size (UV3) Primitive Count Geneva 2009-10 (MN03) 550.2 Mio 10.3 M-Lines Geneva 2013-04 407.0 Mio 7.6 M-Lines Geneva 2017-04 599.6 Mio 11.2 M-Lines Geneva 2019-04 532.6 Mio 9.9 M-Lines As the temporal gaps between the models are much larger than for the Thurgau models, the size and primitive count show larger variations across the time, indicating that numerous differences should be detected on these data. Models : Statistical Analysis \u00b6 As in the first phase, a statistical analysis of the Thurgau and Geneva models is conducted. The following figures show the line length distribution of the two Thurgau models : Statistical analysis : Primitive size distribution, in meters, for the Thurgau 2020-10-13 (left) and 2020-10-17 (right) As expected, as the models are very similar, the distribution between both models is almost identical. In both cases, the distribution is centered around two meters and is mostly contained within the [0,5] range. The following figures show the same statistical analysis for the Geneva models, more spread along the time dimension : Statistical analysis : Primitive size distribution, in meters, for the Geneva 2009-10 (top-left), 2013-04 (top-right), 2017-04 (bottom-left) and 2019-04 (bottom-right) One can see that the distribution varies more from a time to another. In addition, in comparison with the Thurgau models, the Geneva models tend to have smaller primitive, mostly distributed in the [0,1] range with a narrower distribution. Results and Analysis \u00b6 Short-Term : Thurgau \u00b6 In the case of Thurgau data, the models are only separated in time by a few days. It follows that only a small amount of differences is expected. As an introduction, the following images show the overall situation of the difference detection between the two models. The differences are highlighted by keeping the primitive original color while identities are shown in dark gray to allow context conservation : Overall view of difference detection : Thurgau (right) and Amriswil (left) As expected, as the two models are very close in time, only a limited amount of differences is detected. Such situation allows to have a clear view and understanding of each difference. In order to analyze the results of the difference detection algorithm on real cases , selected differences, using the algorithm itself, are studied more in detail to emphasize the ability of the algorithm to detect and make the difference understandable for the user. As a first example, the case of the Bielackerstrasse in Amriswil is considered and illustrated by the following images : Example of difference detection : Bielackerstrasse in Amriswil - 2020-10-17 (right) and 2020-10-13 (left) as primary time In this case, new buildings are added to the official land register. As the 2020-10-17 is selected as primary, the highlighted elements correspond the footprint of the added buildings. When the 2020-10-13 time is set as primary, as it does not contain the building footprints, the highlighted elements only corresponds to the re-measured elements for land register correction. This illustrates the asymmetry of the difference detection algorithm that only highlight primitives of the primary time. In addition, by keeping the color of the highlighted primitives, the difference detection algorithm allows to immediately see that three layers of the land register have been affected by the modification (German : Einzelobjekte, Flaechenelement Geometrie; Bodenbedeckung, BoFlaeche Geometrie; Einzelobjekte, Linienelement). The following images show the respective situation of the 2020-10-13 and 2020-10_17 models : Situation of Bielackerstrasse in Amriswil - 2020-10-17 (right) and 2020-10-13 (left) This confirms the analysis deduced from the difference detection algorithm that a group of new buildings are added to the land register. In this example, if the inner road was not re-measured, at least on some portion, the difference detection with 2020-10-13 as primary time would have shown noting. To illustrate the asymmetry of the algorithm more clearly, the example of Mammern is considered. On the following image, the result of the difference detection is illustrated with both time chosen successively as primary : Example of difference detection : Mammern - 2020-10-17 (right) and 2020-10-13 (left) as primary time On this specific example, one can see that choosing the 2020-10-17 time as primary, which is the most recent time, nothing is highlighted by the detection algorithm. But when the 2020-10-13 time is set as primary, a specific element appears as highlighted, showing an evolution of the land register. This example illustrates the deletion of a sequence of primitive of the property (German : Liegenschaften, ProjLiegenschaft Geometrie) layer of the land register, which then only appear as the oldest time is set as primary. The following images show both time situation : Situation of Mammern - 2020-10-17 (right) and 2020-10-13 (left) This example shows the opposite situation of the previous one, where elements were deleted from the land register instead of added. As a last example, an in-between situation is selected. The case of the Trungerstrasse in M\u00fcnchwilen is considered and illustrated by the following images showing both time as primary : Example of difference detection : Trungerstrasse in M\u00fcnchwilen - 2020-10-17 (right) and 2020-10-13 (left) as primary time This situation is in-between the two previous one as nothing really appeared and nothing really disappeared from the land register. A modification was made on the situation of this specific property and so, appear no matter which of the two times is selected as primary. The following images show the formal situation of the land register for the two times : Situation of Trungerstrasse in M\u00fcnchwilen - 2020-10-17 (right) and 2020-10-13 (left) One can see that the correction made are around the pointed house, as the access road of the rear delimitation. For this type of situation, the algorithm recover some kind of symmetry, as the selected time as primary does is not relevant to detect the difference. To conclude this short-term difference detection analysis, the efficiency of visual markers is illustrated on the region of Romanshorn and Amriswil on the following images. Both images show the difference detection rendering without and with the visual markers : Illustration of difference detection without (right) and with (left) visual markers - 2020-10-17 as primary time for both images One can see that, for small highlighted primitive, the usage of visual markers eases the differences view for the user. Of course, as the highlighted primitive are big enough, or if the point of view is very close to the model, the efficiency of the visual markers decreases. Long-Term : Geneva \u00b6 Considering the Geneva land register, the compared model are much more spread along the time dimension, leading to a much richer difference model. Starting with the 2019-04 and 2017-04 models, the following images gives an overview of the detected differences on the whole canton : Overall view of difference detection between Geneva 2019-04 and 2017-04 models with 2019-04 as primary On this example, one can see that a much larger amount of differences is detected as the model are separated by two years. As the first observation, one can see that large portions of the model seems to have entirely moved between the two dates. Three of these zones are clearly visible on the images above as all their content is highlighted by the difference detection algorithm : the superior half of the Geneva commune , the Carouge commune and the left half of the Plan-les-Ouates commune , but more can be seen, looking more closely. These zones have been subjected to correction during the time interval separating the two models. These corrections mainly comes from the FINELTRA [1] adjustment used to ensure conversion between the old Swiss coordinates system MN03 and the MN95 current standard. As these corrections operate on each coordinate, the whole area is then modified of the order of a few centimeters. In these condition, the whole area is then highlighted by the difference detection algorithm as illustrated by the following image on the Carouge commune : Closer view of the Carouge 2019-04 and 2017-04 differences with 2019-04 as primary On this closer view, one can see that almost all the primitive of this specific commune have been corrected. Some exceptions remain. It is the case of the train tracks for example, that appear as static between the two models. Looking more closely, one can also observe that some primitive were not affected by the correction. Looking at the areas that have not been corrected through the FINELTRA triangular model, one can see that a lot of modification appear. For example, the following two images gives the differences of the Geneva historical part and the Verbois dam : Closer view of the Historical city (left) and Verbois dam (right) 2019-04 and 2017-04 differences with 2019-04 as primary One can see that, despite very few elements truly changed, a lot of primitives are highlighted as differences. This can be explained by a constant work of correction based on in-situ measurement. Some other factors can also explain these large amount of differences such as scripts used to correct the data to bring them in the expected Swiss standards. In such context, detected real changes of the territory is made much more complicated, as large amounts of detected differences are due to corrections of the model itself, without underlying true modification on the territory. Nevertheless, differences that corresponds to a true territory modification can be found. The following images show an example on the Chemin du Signal in Bernex : Differences on Chemin du Signal in Bernex with 2019-04 (left) and 2017-04 (right) as primary These differences can be detected by the user on the difference model as they appear more clearly due to an accumulation of highlighted primitives. Indeed, in case of simple correction, the highlighted primitive appear more isolated. The following images give the formal situation for the two times : Situation of Chemin du Signal in Bernex in 2019-04 (left) and 2017-04 (right) On this example, one can see that, with both time as primary, the territory evolution can be seen by the user as the highlighted primitives are more consistent. Nevertheless, territory changes are more difficult to list in such a case than in the previous short-term analysis. The following images give two example of visible territory changes in the difference model : La Gradelle (left) and Puplinge (right) 2019-04 and 2017-04 differences with 2019-04 as primary On the previous left image, a clear block of buildings can be seen as more highlighted than the rest of the difference model and correspond to new building. On the right of this block, a smaller one can also be seen that also corresponds to new buildings. On the right images, a clear block of new buildings is also visible, as more highlighted. In such a case, the user has more effort to perform in order to detect the differences that correspond to true changes in the territory, the differences model showing the land register modification in the first place rather than of the proper territory evolution. Considering the 2013-04 model, similar observations apply with stronger effect due to the larger temporal gap. The difference models are dominated by correction made to the model rather than proper territory changes. Comparing the 2017-04 and 2013-04 lead to even more difficult detection of these true modification, as the correction are widely dominating the difference models. The case of the 2009-10 model is made even worse by its coordinates system, as it is expressed in the old MN03 coordinates system. This model is made very difficult to compare with the three others, expressed in the MN95 frame, as all its primitives are highlighted in difference models due to the conversion performed between the MN03 and MN95 frames. Comparing the 2009-10 model with the 2013-04 lead to no primitive detected as identity, leaving only differences. Conclusion : Second Phase \u00b6 Two cases have been addressed in this phase showing each specific interesting application of the difference detection applied on land register data through the INTERLIS format. Indeed, short and long term differences emphasize two different points of view according to the analysis of the land register and its evolution in time. In the first place, the short term application clearly showed how difference detection and their representation opens a new point of view on the evolution of the land register as it allows focusing on clear and well identified modifications. As the compared models are close in time, one is able to produced differences models allowing to clearly see, modification by modification, what happened between the two compare situations, allowing focusing on each evolution to fully understand the modification. It follows that this short-term difference detection can provide a useful approach for the user of the land register that are more interested in the evolution of the model rather than in the model itself. The difference models can provide users a clear a simple view on what to search and to analyze to understand the evolution of such complex models. In some way, the differences on land register models can be seen as an additional layer proposed to the user to allow him to reach information that are not easy to extract from the models themselves. The case of Geneva , illustrating the long-term difference detection case, showed another interesting point of view. In the first place, one has to understand that land register models are complex and living models, not only affected by the transcription of the real-world situation across the time. Indeed, on the Geneva models, a large amount of differences is detected even on a relative short period of time (two years). In addition to the regular updates, following the territory evolution, a large amount of corrections is made to keep the model in the correct reference frame. The Swiss federal system can also add complexity, as all Cantons have to align themselves on a common set of expectations. In such a case, the difference detection turned out to be an interesting tool to understand and follows the corrections made to the model in addition to the regular updates. On the Geneva case, we illustrated that, by detecting it in the difference model, the correction on the coordinates frame on large pieces of the territory. This shows how the difference detection can be seen as a service that can help to keep track of the life of the model by detecting and checking these type of modifications. As a result, difference detection can be a tool for the user of the land register but can also be a tool for the land register authorities themselves. The difference models can be used to check and audit the evolution of the models, helping the required follow-up on the applied correction and updates. Third Phase : Point-Based Models \u00b6 In this third and last phase, the developed algorithm for difference detection on vector models is tested on point-based ones. As mentioned in the introduction, the platform was already implementing logical operators allowing comparing point-based models across time. As illustrated in the introduction, only the AND operator allowed emphasizing differences, but rendering them as missing part of the composite models. It was then difficult for the user to determine and analyze those differences. The goal of this last phase is to determine in which extend the developed algorithm is able to improve the initial results of point-based logical operators and how it can be adapted to provide better detection of differences. Selected Resources and Models \u00b6 Point-Based Models : LIDAR \u00b6 Smaller data-sets are considered as point-based models are usually much larger. The city of Geneva is chosen as an example. Four identical chunks of LIDAR data are considered covering the railway station and its surroundings. The four models correspond to the digitization campaigns of 2005, 2009, 2013 and 2017. The data are converted from LAS to UV3 and brought to WGS84 using the EGM96-5 geoid model. The following images give an overview of the selected models : Point-based data-sets : Geneva LIDAR of 2005 (left) and 2009 (right) - Data : SITG The following table gives a summary of the models sizes and primitive count : Model Size (UV3) Primitive Count Geneva 2005 663.2 Mio 24.8 M-Points Geneva 2009 1.2 Gio 46.7 M-Points Geneva 2013 3.9 Gio 4.2 G-Points Geneva 2017 7.0 Gio 7.5 G-Points The color of the models corresponds to the point classification. In addition, the models have a density that considerably increases with time, from 1 points/m^2 (2005) to 25 points/m^2 (2017). This disparity of density is considered as part of the sampling disparity, leading to a set of data very interesting to analyze and benchmark the difference detection algorithm. Models : Statistical Analysis \u00b6 As for line and triangle-based models, a statistical analysis of the point-based models is performed. The analysis consists in computing an approximation of the nearest neighbor distance distribution of points. The following figure shows the distribution of the 2005 and 2009 models : Statistical analysis : Nearest neighbor distribution approximation of the 2005 (left) and 2009 (right) models and the following figure shows the results for the 2013 and 2017 models : Statistical analysis : Nearest neighbor distribution approximation of the 2013 (left) and 2017 (right) models The nearest neighbor distribution tends to go toward zeros with the year of acquisition, showing that modern models are significantly denser that the older ones, making these models interesting for the difference detection algorithm analysis. Differences Detection Algorithm : Direct Application on Point-Based Models \u00b6 In order to determine the performances of the difference detection algorithm on the selected point-based models, the algorithm is simply applied without any adaptation on the data-sets and the results are analyzed. The following images give an overview of the obtained results comparing the 2005 and 2009 models : Application of the difference detection algorithm on point-based models : Geneva model of 2005 and 2009 with 2005 as primary (left) and inversely (right) - Data SITG One can see that the obtained results are very similar to the results obtained with the previously implemented XOR logical operator. The only differences is that the identical points are shown (in dark gray) along with the highlighted points (showing the differences). The same conclusion applies : the obtained composite model is difficult to read as it is dominated by sampling disparities. One can, by carefully looking at the model, ending up detecting large modifications by searching for highlighted points accumulation. In addition, taking one model or the other as primary for the algorithm does not really help as shown on the images above. The same conclusion applies even when the two compared models comes with a similar point density as the 2013 and 2017 models : Application of the difference detection algorithm on point-based models : Geneva model of 2013 and 2017 with 2013 as primary (left) and inversely (right) - Data SITG One can nevertheless observe that choosing the less dense model as primary leads to results a bit more clear for difference detection, but remaining very hard to interpret for a user, and much more for automated processes. In addition, the performances of the algorithm are very poor as point-based models are much denser in terms of primitives than line or triangle-based models. These reasons lead to the conclusion that the algorithm can not be directly used for point-based models and need a more specific approach. Differences Detection Algorithm : Adaptation for Point-Based Models \u00b6 In order to adapt the difference detection algorithm for point-based models, two aspects have to be addressed : the efficiency of the detection and the reduction of the sampling disparities over-representation, which are both server-side operations. The problem of efficiency can be solved quite easily if the adaptation of the difference detection algorithm goes in the direction of logical operators, for which an efficient methodology is already implemented. Solving the sampling disparity over-representation is more complicated. The adopted solution is inspired from a simple observation : the less deep (density of cells) the queries are, the clearer the obtained representation is. This can be illustrated by the following images showing the 2005 model compared with the 2009 one with depth equal to 7, 6 and 5, from left to right : Example of decreasing query depth on the comparison of 2005 and 2009 models - Data SITG This is expected, as the sampling disparities can only appear at scales corresponding to the nearest neighbor distribution. Nevertheless, as the depth is decreased, the models become less and less dense. The increase of difference readability is then compensated by the lack of density, making the structures more difficult to identify, and then, their subsequent modifications. The goal of the algorithm adaptation is to keep both readability and density. To achieve this goal, the implementation of the previous XOR operator is considered as a base, mostly for its efficiency. As the XOR simply detects if a cell of the space-time discretization at a given time is in a different state as its counterpart at another time, it can be modulated to introduce a scale delay mechanism that only applies detection on low-valued scales, broadcasting their results to their daughter cells. This allows to preserve the density and to perform the detection only on sufficiently shallow scales to avoid sampling disparities to become dominant. The question is how to operate the scale delay according to the scale itself. Indeed, with large points of view, the delay is not necessary as the model is viewed from far away. The necessity of the scale delay appears as the point of view is reduced, and, the more it is reduced, the larger the scale delay needs to be. A scale-attached delay is then defined to associate a specific value for each depth. Results and Experiments \u00b6 The adaptation of the difference detection algorithm for point-based models is analyzed using the selected data-sets. An overview of its result is presented before a more formal analysis is made using difference detection made on line-based official land register data to be compared with the differences on point-based models. Differences Detection : Overview \u00b6 Considering the two first models, from 2005 and 2009 campaigns, the following images shows the results of the initial version of the difference detection algorithm (similar to XOR operator) and its adapted version implementing the scale delay : Differences detection on 2005 and 2009 models with 2005 as primary - Left : without scale delay - Right : with scale delay - Data SITG One can see how scale delay is able to drastically reduce the effect of sampling disparities while comparing two point-based models. The effect is more obvious as the 2009 model is set as primary for difference detection : Differences detection on 2005 and 2009 models with 2009 as primary - Left : without scale delay - Right : with scale delay - Data SITG This improvement gets more clear as the point of view is reduced. The following image shows the initial algorithm and the scale delay algorithm on a specific area of the city with 2005 as primary model : Differences detection on 2005 and 2009 models with 2005 as primary - Left : without scale delay - Right : with scale delay - Data SITG By inverting the model roles and making the 2009 model primary for difference detection lead to similar results : Differences detection on 2005 and 2009 models with 2009 as primary - Left : without scale delay - Right : with scale delay - Data SITG Considering the denser models of 2013 and 2017 campaigns, the results of the scale delay introduction also lead to a better understanding of the differences as shown on the following images : Differences detection on 2013 and 2017 models with scale delay - Left : 2013 as primary - Right : 2017 as primary - Data SITG Nevertheless, one can see that scale delay is not able to get rid entirely of sampling disparities. The right image above, comparing the 2017 model to the 2013 one, shows sampling disparities being highlighted as differences on the wall of the building in the background. This does not affect too much the user readability, but still make the model a bit more complicated to understand. In addition, the models play an important role in the way differences can be detected through classic approach. For example, focusing on a specific building, the obtained highlighted differences : Differences detection on 2013 and 2017 models with scale delay with 2013 (left) and 2017 (right) as primary - Data SITG could lead the user to consider the building wall as a difference. Looking at the formal situation in both 2013 and 2017 models : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can see that the detected difference comes from the missing wall on the 2013, and not from a formal evolution of the building. This example illustrates that sampling disparity is not the only factor that could reduce the readability of the model for the user. Differences Detection : Comparison with Land Register Differences \u00b6 As the algorithm is already tested for land register models, one can use its results on these data in order to put them into perspective of the detected differences on point cloud. As the methodology is not the same for vector-based and point-based models, it is interesting to see the coherence and deviations of both approaches. One important thing to underline, is that difference detection in land register model does not detect changes in the environment directly, but detects the revision of the land register itself, as discussed in the previous phase. Of course, land register models evolve with environment, but come also with a large amount of modifications that only represent corrections of the model and not formal changes in the environment. This reason reinforces the interest to but point-based model difference detection with the land register models ones. In the previous phase, the land register models of Geneva were selected to be the closest to the LIDAR campaigns. It follows, that these models can be directly used here, as each corresponding to the compared point-based model of this phase. As a first example, the following case is studied : Rue de Bourgogne and Rue de Lyon . In this case, looking at the following images giving the situation in 2013-04 and 2017-04 through the LIDAR models, that an industrial building was partially demolished. Structural situation in 2013 (left) and 2017 (right) - Data SITG The following images show the differences computed on both point-based and line-based models : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG One can clearly see that the difference detection on the LIDAR models correctly emphasized a true structural difference between the two times. The situation is much less clear on the land register model. Indeed, as the time separating the two models is quite high, four years in such a case, a large mount of corrections dominates the difference model, leading to a difficult interpretation of the building situation change. The following images give the situation of the land register model in 2013 and 2017 that lead to the difference model above : Land register situation in 2013 (left) and 2017 (right) - Data SITG Looking at the land register models, one can also see that such large scale modification of the building situation does not appear clearly. Indeed, it takes some effort to detect minor changes on the two models, without leading to a clear indication of the modification. This shows how the LIDAR and its differences can help to detect and analyze differences in complement to the land register itself. Considering the second example, Avenue de France and Avenue Blanc , the following images give the structural situation of the two times as capture by the LIDAR campaigns : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can clearly see the destruction of the two 2013 buildings replaced by a parking lot in 2017 . The detected differences on the LIDAR and land register models are presented on the following images : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG Again, despite the differences are clearly and correctly highlighted on the LIDAR differences model, the situation remains unclear on the differences model of the land register. Again, one can observe that the land register was highly corrected between the two dates, leading to difficulties to understand the modification and its nature. Looking at the land register respective models : Land register situation in 2013 (left) and 2017 (right) - Data SITG the modification appears a bit more clearly. One can clearly see the disappearance of the two 2013 buildings in the land register replaced by a big empty area. Again, the difference detection on LIDAR seems clearly more relevant to detect and analyze structural differences than the land register itself. An interesting example is provided by the situation just east of the Basilique Notre-Dame . The two situations as captured by the LIDAR campaigns are presented on the following images : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can observe two structure mounted on top of two buildings roof in the 2013 situation. These structures are used to ease the work that has to be performed on the roofs. These structures are no more present in the 2017 situation. The following images give the difference detection models for the LIDAR and land register : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG In such a case, as the structural modification between 2013 and 2017 occurs on top of the buildings, their footprints is not affected and the differences have no chance to appear in the land register models, even looking at them individually as in the following images : Land register situation in 2013 (left) and 2017 (right) - Data SITG This is another example where the LIDAR difference detection lead to more and clearer information on the structural modification that appear on Geneva between the two times. Conclusion : Third Phase \u00b6 The main element of this third phase conclusion is that difference detection on point-based models is less straightforward than for other models. Indeed, applied naively, the algorithm is dominated by the sampling disparities of the compared models. This illustrate that point-based models, being a close mirror of the true territory state, have a large information density that is more difficult to reach, especially from their evolution point of view. Nevertheless, we showed that the algorithm can be adapted, with relatively simple adjustments, to perform well on point-based models difference detection problem. The implemented algorithm is able to track and represent the differences appearing between the models in a useful and comprehensive way for users. The proposed example showed that the differences models are able to guide the user toward interesting structural changes in the territory, with a clear view of the third dimension. Of course, the highlighted differences in point-based models are more complex and required a trained user that is able to interpret correctly the detail of the highlighted part of the model. The trees are a good example. As the tree re-grow each year, they will always appear as a differences in the compared models. A user only interested in building changes has to be aware of that and be able to separate the relevant differences from the others. Following the comparison between LIDAR and land register ( INTERLIS ) differences models, a very surprising conclusion appear. In the first place, one could stand that land register is the proper way of detected changes that can be then analyzed more in detail in point-based differences models. In turns out that to opposite is true. Several reason explain this surprising situation. In the first place, LIDAR are available only with large temporal gaps between them, at least two/three years. This allows the land register models to be filled with large amount of updates and correction, leading the differences model on this temporal gap to be filled with much more than structural modification. In addition, the LIDAR models come with the third dimension where the land register models are flat. The third dimension comes with large amount of differences that can not be seen in the land register. To some extend, the land register, and its evolution, is the reflect of the way the territory is surveyed, not the reflect of the formal territory evolution. In the opposite, as LIDAR models are a structural snapshot of a territory situation, the analyze of their differences across the time lead to a better tracking of the formal modification of the real world . Conclusion \u00b6 First Phase \u00b6 In the first phase, the difference detection algorithm was implemented for vector models and tested using synthetic differences on selected models. The results showed the interest of the obtained differences models to emphasize evolution of models from both user and process points of view. It was demonstrated that the information between models exists and can be extracted and represented in a relevant way for both users and processes. Second Phase \u00b6 In the second phase, the difference detection algorithm was tested on the Swiss land register models on which the results obtained during the first phase were confirmed. The differences models are able to provide both user and process a clear and understandable view of the modification brought to the models. In addition, through the short and long-term perspectives, it was possible to demonstrate how the difference detection algorithm is able to provide different points of view on the model evolution. From a short-term perspective, the differences models are able to provide a clear and individual view of the modification while the long-term perspective allows to see the large scale evolution and transformation of the models. It follows that the difference models can be used as a tool for various actors using or working with the land register models. Third Phase \u00b6 In the third phase, the difference detection algorithm, developed on vector models, was applied on point-based models, showing that a direct application on these models lead to the same issue as the logical operators : the differences models are dominated by sampling disparities, making them complicated to read. The solution of scale delay brought to the algorithm allowed to produce much clearer differences models for point-based data, allowing to generalize the difference detection on any models. In addition to these results, the comparison of difference models on land register and on their corresponding LIDAR point-based models showed an interesting result : for structural changes, the point-based models lead to much more interesting results through the highlighted differences. Indeed, as land register models, considered long term perspective, are dominated by a large amount of corrections and adjustments in addition to territory evolution updates, making the structural changes not easy to detect and understand. The differences models are more clear with point-based models form this point of view. In addition, as point-based models, such as LIDAR , come with the third dimension, a large amount of structural differences can only be seen through such data as many structural changes are made along the third dimension. It then follows that difference detection applied to point-based models offers a very interesting point of view for the survey of territory structural changes. Synthesis \u00b6 As a synthesis, it is clear that models are carrying a large amount of richness themselves, that is already a challenge to exploit, but it is also clear that a large amount of information can be found between the versions of the models. The difference detection algorithm brings a first tool that demonstrate the ability to reach and start to exploit these informations. More than the content of the models itself, the understanding of the evolution of this content is a major topic especially in the field of geodata as they represent, transcript, the evolution of the surveyed territory. It then appears clear that being able to reach and exploit the information contained in-between the models is a major advantage as it allows understanding what are these models, that is four dimensional objects. Perspectives \u00b6 Many perspectives are opened following the implementation and analysis of the difference detection. Several perspectives, mostly technical, are presented here as a final section. In the first place, as raster are entering the set of data that can be injected in the platform, evolution of the difference detection could be applied to the platform, taking advantage of the evolution of machine learning. The possibility of detected differences in images could lead to very interesting perspective through the data communication features of the platform. Another perspective could be to allow the platform to separate the data into formal layers, the separation being only currently ensure by type and times. Splitting data into layers would allow applying difference detection in a much more controlled manner, leading to difference models focused on very specific elements of the model temporal evolution. The addition of layer could also be the starting point to the notion of data convolution micro language . Currently, data communication and difference detection only apply through the specification of two different and parallel navigation time. The users, or processes, have to specify each of the two time position in order to obtain the mixed of differences models they need. An interesting evolution would be to replace these two navigation time by a small and simple micro language allowing the user to compare more than two times in a more complex manner. This could also benefit from data separation through layer. Such micro language could allow to compare two, three or more models, or layers, and would also open the access the mixed models of differences models such as comparing the difference detection between point-based and vector-based models, which would then be a comparison of a comparison. Reproduction Resources \u00b6 To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Only part of the considered datasets are publicly available. For the OpenStreetMap datasets, you can download them from the following source : Shapefile layers, OpenStreetMap For the Swiss 3D buildings model, you can contact swisstopo : Shapefile 3D buildings, swisstopo For the land register datasets of Geneva and Thurgau , you can contact the SITG and the Thurgau Kanton : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) The point-based models of Geneva can be downloaded from the SITG online extractor : LAS MNS, SITG (Geneva) To extract and convert the data from planimetric shapefiles , the following code is used : Shapefile CSV export to UV3 (csv-wkt-to-uv3), STDL where the README gives all the information needed. In case of shapefile containing 3D models, please ask the STDL for advice and tools. To extract and convert the data from INTERLIS and LAS , the following codes are used : INTERLIS to UV3 (dalai-suite), STDL/EPFL LAS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results. Auxiliary Developments & Corrections \u00b6 In addition to the main developments made, some additional scripts and other corrections have been made to solve auxiliary problems or to improve the code according to the developed features during this task. The auxiliary developments are summarized here : Correction of socket read function to improve server-client connectivity. Creation of scripts that allows to insert synthetic modifications (random displacements on the vertex coordinates) on UV3 models. Creation of a script to convert CSV export from shapefile to UV3 format. The script code is available here . Adding temporary addresses (space-time index) exportation in platform 3D interface. Correction of the cell enumeration process in platform 3D interface (wrong depth limit implementation). Creation of a script allowing segmenting UV3 model according to geographical bounding box. Creation of C codes to perform statistical analysis of the point, line and triangle-based models : computation of edge size and nearest neighbor distributions. Creation of a C code allowing enumerating non-empty cell index over the Switzerland models injected in the platform. Creation of a C code allowing to automate the difference detection based on an index list and by searching in the data queried from the platform. Developments of various scripts for plots and figures creations. References \u00b6 [1] REFRAME, SwissTopo, https://www.swisstopo.admin.ch/de/karten-daten-online/calculation-services.html","title":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT"},{"location":"TASK-DIFF/#automatic-detection-of-changes-in-the-environment","text":"Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF September 2020 to November 2020 - Published on December 7, 2020 Abstract : Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds.","title":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT"},{"location":"TASK-DIFF/#task-context-difference-detection","text":"As the implemented indexation formalism is based on equivalences classes defined on space and time, a natural discretization along all the four dimensions is obtained. In the field of difference detection, it allowed implementing simple logical operators on the four-dimensional space. The OR , AND and XOR operators were then implemented allowing the platform to compute, in real time , convolutions to compare models with each others across the time. The implementation of these operators was simple due to the natural spatio-temporal discretization obtained from the indexation formalism. Nevertheless, two major drawbacks appeared : the first one is that such operators only works for point-based models. Having the opportunity to compute and render differences and similarities between any type of data is not possible with such formal operators. The second drawback comes from the nature of the point-based capturing devices. Indeed, taking the example of a building, even without any change to its structure, two digitization campaigns can lead to disparities only due to measures sampling. The XOR operator is the natural choice to detect and render differences, but this operator is very sensitive to sampling disparities. Computing the XOR convolution between two point-based models leads the rendering to be dominated by sampling variations rather than the desired structural differences. This drawback was partially solved by considering the AND operator. Indeed, the AND operator allows to only shows constant structural elements from two different positions in time and is insensitive to sampling disparities. As shown on the following images, the AND operator shows differences as black spots (missing parts) : AND convolution between two LIDAR models : Geneva 2005 and 2009 - Data : SITG As one can see, AND convolutions allow detecting, through the black spots, large area of structural changes between the two times and also, with more care, allow guessing smaller differences. Nevertheless, reading and interpreting such representation remains complex for users. The goal of this task is then to tackle these two drawbacks, allowing the platform to detect changes not only for point-based models but also for vector-based models and to implement a variation of the XOR operator for point-based models allowing to efficiently highlight the structural evolution. The task consists then in the implementation, testing and validation of a difference detection algorithm suitable for any type of model and to conduct a formal analysis on the best rendering techniques.","title":"Task Context : Difference Detection"},{"location":"TASK-DIFF/#methodology","text":"A step by step methodology is defined to address the problem of difference detection in the platform. In a first phase, the algorithm will be developed and validated on vector-based models as follows : Obtaining a large scale vector-based model on which synthetic variation are introduced Development of the algorithm using the synthetic variations model Testing and validation of the algorithm (using the known synthetic variations) First conclusion In a second phase, true land register data will be used to formally detect real evolutions of the territory : Obtaining true land register vector-based models (INTERLIS) at different times Analysis of the difference detection algorithm on true land register vector-based models Second conclusion In a third phase, the algorithm will be validated and adapted to work on point-based models : Obtaining true land register point-based models (LAS) at different position in time Verifying the performances of the vector-based detection algorithm on point-based data Adaptation of the algorithm for point-based models Analysis of the difference detection algorithm on true land register point-based models Comparison of the detected differences on point-based models and on their corresponding land register vector-based models (INTERLIS) Third conclusion In addition, the development of difference detection algorithm has to be conducted keeping in mind the possible future evolutions of the platform such as addition of layers (separation of data), implementation of a multi-scale approach of the time dimension and addition of raster data in the platform.","title":"Methodology"},{"location":"TASK-DIFF/#first-phase-synthetic-variations","text":"In order to implements the vector-based difference detection algorithm, sets of data are considered as base on which synthetic differences are applied to simulate the evolution of the territory. This approach allows focusing on well controlled data to formally benchmark the results of the implemented algorithm. Experiments are conducted using these data to formally evaluate the performance of the developed algorithm.","title":"First Phase : Synthetic Variations"},{"location":"TASK-DIFF/#selected-resources-and-models","text":"","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#implementation-of-the-algorithm","text":"In order to compare two models at two different positions in time to detect differences, the solution is of course to search for each primitive of the primary time if it has a corresponding one in the secondary time. In such case, the primitives can be concluded as static in time and only the primitives that have no correspondence will be highlighted as differences. A first approach was initially tested : a vertex-based comparison. As every primitive (points, lines and triangles) is supported by vertexes, it can be seen as a common denominator on which comparison can take place. Unfortunately, it is not a relevant approach as it leads to an asymmetric detection algorithm. To illustrate the issue, the following image shows the situation of a group of line-based primitives at two different times with an evolution on one of the primitive vertex : Asymmetric approach : The variation is detected only when comparing backward in time When the comparison occurs between the second time and the first one, the modified vertex correspondence is not found, and the vertex can be highlighted as a difference. The asymmetry appears as the first time is compared to the second one. In this case, despite the primitive vertex changed, the vertex-based approach is able to find another vertex, part of another primitive, and interprets it as a vertex identity, leading the modified primitive to be considered as static. In order to obtain a fully symmetric algorithm, that does not depend on the way models are compared in times, a primitive-attached approach is considered. The implemented algorithm then treats the correspondence problem from the whole primitive point of view, by checking that the whole primitive can be found in the other model to which it is compared to. This allows to highlight any primitive showing a modification, regardless of the way models are compared and the nature of the modification. In addition to highlighting the primitives that changed through time, the implemented algorithm also renders the primitives that have not changed. The primitives are then shown by modulating their color to emphasize the modifications by keeping their original color for the modified one, while the static primitives are shown in dark gray. This allows to not only show the modifications but also to keep the context of the modifications, helping the user to fully understand the nature of the territory evolution. In addition to color modulation, a variation of difference rendering is analyzed. In addition to color modulation, a visual and artificial marker is added to ease their search. The visual marker is a simple line emanating from the primitive and goes straight up with a size of 512 meters. Such markers are introduced to ease the detection of small primitives that can be difficult to spot according to large point of views. Additional developments were required for triangle-based models : indeed, such models need to be subjected to a light source during rendering for the user to understand the model (face shading). The previously implemented lighting model is then modified to take into account color modulation in order to correctly render the triangle that are highlighted. Moreover, the lighting model was modified to light both face of the triangles in order to light them regardless of the point of view. In addition, as mesh models are made of triangles, primitives can hide themselves. It can then be difficult for the user to spot the highlighted primitives as they can be hidden by others. An option was added to the rendering client allowing the user to ask the rendering of triangles as line-loops or points in order to make them transparent. Finally, an option allowing the user to enable or disable the render face culling was added for him to be able to see the primitive from backward.","title":"Implementation of the Algorithm"},{"location":"TASK-DIFF/#results-and-experiments","text":"With the implemented algorithm, a series of experiments are conducted in order to validate its results and to analyze the efficiency of the difference detection and rendering from a user point of view. In addition, experiments are also conducted to quantify the efficiency of the difference detection for automated processes.","title":"Results and Experiments"},{"location":"TASK-DIFF/#conclusion-first-phase","text":"During this first phase, the difference detection algorithm was developed and validated on both line-based and triangle-based data. An efficient algorithm is then implemented in the platform allowing emphasizing differences between models at different temporal positions. The algorithm is able to perform the detection on the fly with good performances allowing the users to dynamically browse the data to detect and analyze the territory evolutions. The performances of the detection algorithm allow the platform to be suitable for automated detection processes, as a data provider, answering large amounts of queries in an efficient and remote manner. Two variations of the difference detection algorithm are implemented. The first version consists in highlighting the primitives that are subject to modifications over a time. This variation is suitable for automated processes that can rely on simple search methods to list the differences. For the users, this first variation can lead to more difficult visual detection of the differences, especially in case the highlighted primitives are small or hidden by others. For this reason, visual markers were added on top of the highlighted primitives in order to be seen from far away, regardless of the primitives size. The measures sessions made during the user-based experiments showed a clear improvement of the detection rate when using the visual markers. This was especially true for triangle-based models, where the primitives bring occlusions. The user-based experiments showed that using the platform interface, a human can significantly outperform the result of a naive automated process operating on the models themselves. The experiments showed that the user is able to efficiently search and find through space and time the evolutions of the territory appearing in the data. Of course, as the model size and complexity increases, the user-driven interface starts to show its limits. In such a case, the process-based experiments showed that automated processes can take over these more complicated searches through methods allowing performing exhaustive detection over wide models in a matter of several minutes. At this point, the developments and validations of the algorithm, and its variations, were conducted on synthetic modifications introduced in models using controlled procedures. The next phase focuses on formal data extracted from land registers.","title":"Conclusion : First Phase"},{"location":"TASK-DIFF/#second-phase-true-variations","text":"In this second phase, also dedicated to vector-based models, the focus is set on applying the developed difference detection algorithm on true land register models. Two sets of data are considered in order to address short-term and long-term difference detection.","title":"Second Phase : True Variations"},{"location":"TASK-DIFF/#selected-resources-and-models_1","text":"In both cases, short-term and long-term, INTERLIS data are considered. A selection of tables in different topics is performed to extract the most interesting geometries of the land registering. For all models, the following colors are used to distinguish the extracted layers : INTERLIS selected topics and tables colors - Official French and German designations The layers are chosen according to their geometric content. The color assignation is arbitrary and does not correspond to any official colorization standard.","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#results-and-analysis","text":"","title":"Results and Analysis"},{"location":"TASK-DIFF/#conclusion-second-phase","text":"Two cases have been addressed in this phase showing each specific interesting application of the difference detection applied on land register data through the INTERLIS format. Indeed, short and long term differences emphasize two different points of view according to the analysis of the land register and its evolution in time. In the first place, the short term application clearly showed how difference detection and their representation opens a new point of view on the evolution of the land register as it allows focusing on clear and well identified modifications. As the compared models are close in time, one is able to produced differences models allowing to clearly see, modification by modification, what happened between the two compare situations, allowing focusing on each evolution to fully understand the modification. It follows that this short-term difference detection can provide a useful approach for the user of the land register that are more interested in the evolution of the model rather than in the model itself. The difference models can provide users a clear a simple view on what to search and to analyze to understand the evolution of such complex models. In some way, the differences on land register models can be seen as an additional layer proposed to the user to allow him to reach information that are not easy to extract from the models themselves. The case of Geneva , illustrating the long-term difference detection case, showed another interesting point of view. In the first place, one has to understand that land register models are complex and living models, not only affected by the transcription of the real-world situation across the time. Indeed, on the Geneva models, a large amount of differences is detected even on a relative short period of time (two years). In addition to the regular updates, following the territory evolution, a large amount of corrections is made to keep the model in the correct reference frame. The Swiss federal system can also add complexity, as all Cantons have to align themselves on a common set of expectations. In such a case, the difference detection turned out to be an interesting tool to understand and follows the corrections made to the model in addition to the regular updates. On the Geneva case, we illustrated that, by detecting it in the difference model, the correction on the coordinates frame on large pieces of the territory. This shows how the difference detection can be seen as a service that can help to keep track of the life of the model by detecting and checking these type of modifications. As a result, difference detection can be a tool for the user of the land register but can also be a tool for the land register authorities themselves. The difference models can be used to check and audit the evolution of the models, helping the required follow-up on the applied correction and updates.","title":"Conclusion : Second Phase"},{"location":"TASK-DIFF/#third-phase-point-based-models","text":"In this third and last phase, the developed algorithm for difference detection on vector models is tested on point-based ones. As mentioned in the introduction, the platform was already implementing logical operators allowing comparing point-based models across time. As illustrated in the introduction, only the AND operator allowed emphasizing differences, but rendering them as missing part of the composite models. It was then difficult for the user to determine and analyze those differences. The goal of this last phase is to determine in which extend the developed algorithm is able to improve the initial results of point-based logical operators and how it can be adapted to provide better detection of differences.","title":"Third Phase : Point-Based Models"},{"location":"TASK-DIFF/#selected-resources-and-models_2","text":"","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#differences-detection-algorithm-direct-application-on-point-based-models","text":"In order to determine the performances of the difference detection algorithm on the selected point-based models, the algorithm is simply applied without any adaptation on the data-sets and the results are analyzed. The following images give an overview of the obtained results comparing the 2005 and 2009 models : Application of the difference detection algorithm on point-based models : Geneva model of 2005 and 2009 with 2005 as primary (left) and inversely (right) - Data SITG One can see that the obtained results are very similar to the results obtained with the previously implemented XOR logical operator. The only differences is that the identical points are shown (in dark gray) along with the highlighted points (showing the differences). The same conclusion applies : the obtained composite model is difficult to read as it is dominated by sampling disparities. One can, by carefully looking at the model, ending up detecting large modifications by searching for highlighted points accumulation. In addition, taking one model or the other as primary for the algorithm does not really help as shown on the images above. The same conclusion applies even when the two compared models comes with a similar point density as the 2013 and 2017 models : Application of the difference detection algorithm on point-based models : Geneva model of 2013 and 2017 with 2013 as primary (left) and inversely (right) - Data SITG One can nevertheless observe that choosing the less dense model as primary leads to results a bit more clear for difference detection, but remaining very hard to interpret for a user, and much more for automated processes. In addition, the performances of the algorithm are very poor as point-based models are much denser in terms of primitives than line or triangle-based models. These reasons lead to the conclusion that the algorithm can not be directly used for point-based models and need a more specific approach.","title":"Differences Detection Algorithm : Direct Application on Point-Based Models"},{"location":"TASK-DIFF/#differences-detection-algorithm-adaptation-for-point-based-models","text":"In order to adapt the difference detection algorithm for point-based models, two aspects have to be addressed : the efficiency of the detection and the reduction of the sampling disparities over-representation, which are both server-side operations. The problem of efficiency can be solved quite easily if the adaptation of the difference detection algorithm goes in the direction of logical operators, for which an efficient methodology is already implemented. Solving the sampling disparity over-representation is more complicated. The adopted solution is inspired from a simple observation : the less deep (density of cells) the queries are, the clearer the obtained representation is. This can be illustrated by the following images showing the 2005 model compared with the 2009 one with depth equal to 7, 6 and 5, from left to right : Example of decreasing query depth on the comparison of 2005 and 2009 models - Data SITG This is expected, as the sampling disparities can only appear at scales corresponding to the nearest neighbor distribution. Nevertheless, as the depth is decreased, the models become less and less dense. The increase of difference readability is then compensated by the lack of density, making the structures more difficult to identify, and then, their subsequent modifications. The goal of the algorithm adaptation is to keep both readability and density. To achieve this goal, the implementation of the previous XOR operator is considered as a base, mostly for its efficiency. As the XOR simply detects if a cell of the space-time discretization at a given time is in a different state as its counterpart at another time, it can be modulated to introduce a scale delay mechanism that only applies detection on low-valued scales, broadcasting their results to their daughter cells. This allows to preserve the density and to perform the detection only on sufficiently shallow scales to avoid sampling disparities to become dominant. The question is how to operate the scale delay according to the scale itself. Indeed, with large points of view, the delay is not necessary as the model is viewed from far away. The necessity of the scale delay appears as the point of view is reduced, and, the more it is reduced, the larger the scale delay needs to be. A scale-attached delay is then defined to associate a specific value for each depth.","title":"Differences Detection Algorithm : Adaptation for Point-Based Models"},{"location":"TASK-DIFF/#results-and-experiments_1","text":"The adaptation of the difference detection algorithm for point-based models is analyzed using the selected data-sets. An overview of its result is presented before a more formal analysis is made using difference detection made on line-based official land register data to be compared with the differences on point-based models.","title":"Results and Experiments"},{"location":"TASK-DIFF/#conclusion-third-phase","text":"The main element of this third phase conclusion is that difference detection on point-based models is less straightforward than for other models. Indeed, applied naively, the algorithm is dominated by the sampling disparities of the compared models. This illustrate that point-based models, being a close mirror of the true territory state, have a large information density that is more difficult to reach, especially from their evolution point of view. Nevertheless, we showed that the algorithm can be adapted, with relatively simple adjustments, to perform well on point-based models difference detection problem. The implemented algorithm is able to track and represent the differences appearing between the models in a useful and comprehensive way for users. The proposed example showed that the differences models are able to guide the user toward interesting structural changes in the territory, with a clear view of the third dimension. Of course, the highlighted differences in point-based models are more complex and required a trained user that is able to interpret correctly the detail of the highlighted part of the model. The trees are a good example. As the tree re-grow each year, they will always appear as a differences in the compared models. A user only interested in building changes has to be aware of that and be able to separate the relevant differences from the others. Following the comparison between LIDAR and land register ( INTERLIS ) differences models, a very surprising conclusion appear. In the first place, one could stand that land register is the proper way of detected changes that can be then analyzed more in detail in point-based differences models. In turns out that to opposite is true. Several reason explain this surprising situation. In the first place, LIDAR are available only with large temporal gaps between them, at least two/three years. This allows the land register models to be filled with large amount of updates and correction, leading the differences model on this temporal gap to be filled with much more than structural modification. In addition, the LIDAR models come with the third dimension where the land register models are flat. The third dimension comes with large amount of differences that can not be seen in the land register. To some extend, the land register, and its evolution, is the reflect of the way the territory is surveyed, not the reflect of the formal territory evolution. In the opposite, as LIDAR models are a structural snapshot of a territory situation, the analyze of their differences across the time lead to a better tracking of the formal modification of the real world .","title":"Conclusion : Third Phase"},{"location":"TASK-DIFF/#conclusion","text":"","title":"Conclusion"},{"location":"TASK-DIFF/#first-phase","text":"In the first phase, the difference detection algorithm was implemented for vector models and tested using synthetic differences on selected models. The results showed the interest of the obtained differences models to emphasize evolution of models from both user and process points of view. It was demonstrated that the information between models exists and can be extracted and represented in a relevant way for both users and processes.","title":"First Phase"},{"location":"TASK-DIFF/#second-phase","text":"In the second phase, the difference detection algorithm was tested on the Swiss land register models on which the results obtained during the first phase were confirmed. The differences models are able to provide both user and process a clear and understandable view of the modification brought to the models. In addition, through the short and long-term perspectives, it was possible to demonstrate how the difference detection algorithm is able to provide different points of view on the model evolution. From a short-term perspective, the differences models are able to provide a clear and individual view of the modification while the long-term perspective allows to see the large scale evolution and transformation of the models. It follows that the difference models can be used as a tool for various actors using or working with the land register models.","title":"Second Phase"},{"location":"TASK-DIFF/#third-phase","text":"In the third phase, the difference detection algorithm, developed on vector models, was applied on point-based models, showing that a direct application on these models lead to the same issue as the logical operators : the differences models are dominated by sampling disparities, making them complicated to read. The solution of scale delay brought to the algorithm allowed to produce much clearer differences models for point-based data, allowing to generalize the difference detection on any models. In addition to these results, the comparison of difference models on land register and on their corresponding LIDAR point-based models showed an interesting result : for structural changes, the point-based models lead to much more interesting results through the highlighted differences. Indeed, as land register models, considered long term perspective, are dominated by a large amount of corrections and adjustments in addition to territory evolution updates, making the structural changes not easy to detect and understand. The differences models are more clear with point-based models form this point of view. In addition, as point-based models, such as LIDAR , come with the third dimension, a large amount of structural differences can only be seen through such data as many structural changes are made along the third dimension. It then follows that difference detection applied to point-based models offers a very interesting point of view for the survey of territory structural changes.","title":"Third Phase"},{"location":"TASK-DIFF/#synthesis","text":"As a synthesis, it is clear that models are carrying a large amount of richness themselves, that is already a challenge to exploit, but it is also clear that a large amount of information can be found between the versions of the models. The difference detection algorithm brings a first tool that demonstrate the ability to reach and start to exploit these informations. More than the content of the models itself, the understanding of the evolution of this content is a major topic especially in the field of geodata as they represent, transcript, the evolution of the surveyed territory. It then appears clear that being able to reach and exploit the information contained in-between the models is a major advantage as it allows understanding what are these models, that is four dimensional objects.","title":"Synthesis"},{"location":"TASK-DIFF/#perspectives","text":"Many perspectives are opened following the implementation and analysis of the difference detection. Several perspectives, mostly technical, are presented here as a final section. In the first place, as raster are entering the set of data that can be injected in the platform, evolution of the difference detection could be applied to the platform, taking advantage of the evolution of machine learning. The possibility of detected differences in images could lead to very interesting perspective through the data communication features of the platform. Another perspective could be to allow the platform to separate the data into formal layers, the separation being only currently ensure by type and times. Splitting data into layers would allow applying difference detection in a much more controlled manner, leading to difference models focused on very specific elements of the model temporal evolution. The addition of layer could also be the starting point to the notion of data convolution micro language . Currently, data communication and difference detection only apply through the specification of two different and parallel navigation time. The users, or processes, have to specify each of the two time position in order to obtain the mixed of differences models they need. An interesting evolution would be to replace these two navigation time by a small and simple micro language allowing the user to compare more than two times in a more complex manner. This could also benefit from data separation through layer. Such micro language could allow to compare two, three or more models, or layers, and would also open the access the mixed models of differences models such as comparing the difference detection between point-based and vector-based models, which would then be a comparison of a comparison.","title":"Perspectives"},{"location":"TASK-DIFF/#reproduction-resources","text":"To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Only part of the considered datasets are publicly available. For the OpenStreetMap datasets, you can download them from the following source : Shapefile layers, OpenStreetMap For the Swiss 3D buildings model, you can contact swisstopo : Shapefile 3D buildings, swisstopo For the land register datasets of Geneva and Thurgau , you can contact the SITG and the Thurgau Kanton : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) The point-based models of Geneva can be downloaded from the SITG online extractor : LAS MNS, SITG (Geneva) To extract and convert the data from planimetric shapefiles , the following code is used : Shapefile CSV export to UV3 (csv-wkt-to-uv3), STDL where the README gives all the information needed. In case of shapefile containing 3D models, please ask the STDL for advice and tools. To extract and convert the data from INTERLIS and LAS , the following codes are used : INTERLIS to UV3 (dalai-suite), STDL/EPFL LAS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results.","title":"Reproduction Resources"},{"location":"TASK-DIFF/#auxiliary-developments-corrections","text":"In addition to the main developments made, some additional scripts and other corrections have been made to solve auxiliary problems or to improve the code according to the developed features during this task. The auxiliary developments are summarized here : Correction of socket read function to improve server-client connectivity. Creation of scripts that allows to insert synthetic modifications (random displacements on the vertex coordinates) on UV3 models. Creation of a script to convert CSV export from shapefile to UV3 format. The script code is available here . Adding temporary addresses (space-time index) exportation in platform 3D interface. Correction of the cell enumeration process in platform 3D interface (wrong depth limit implementation). Creation of a script allowing segmenting UV3 model according to geographical bounding box. Creation of C codes to perform statistical analysis of the point, line and triangle-based models : computation of edge size and nearest neighbor distributions. Creation of a C code allowing enumerating non-empty cell index over the Switzerland models injected in the platform. Creation of a C code allowing to automate the difference detection based on an index list and by searching in the data queried from the platform. Developments of various scripts for plots and figures creations.","title":"Auxiliary Developments &amp; Corrections"},{"location":"TASK-DIFF/#references","text":"[1] REFRAME, SwissTopo, https://www.swisstopo.admin.ch/de/karten-daten-online/calculation-services.html","title":"References"},{"location":"TASK-IDET/","text":"Object Detection Framework \u00b6 Alessandro Cerioni, Etat de Geneve - Cl\u00e9mence Herny, Exolabs - Adrian F. Meyer, FHNW - Gwena\u00eblle Salamin, Exolabs Published on November 22, 2021 Updated on December 12, 2023 Abstract : The STDL develops a framework allowing users to train and use deep learning models to detect objects in aerial images. While relying on a generic-purpose third-party open-source library, the STDL's framework implements a somewhat opinionated workflow, targeting georeferenced aerial images and labels. After a brief introduction to object detection, this article provides detailed information on the STDL's object detection framework and the opinions it implements. References to successful applications are provided along with concluding remarks. Introduction \u00b6 Object detection is a computer vision task which aims at detecting instances of objects of some target classes ( e.g. buildings, swimming pools, solar panels, ...) in digital images and videos. According to the commonly adopted terminology, a distinction is made between the following tasks: object detection , in which the goal is to determine the rectangular \"bounding box\" surrounding each detected object; instance segmentation , in which one aims at finding the pixels belonging to each detected object. This distinction is well illustrated by the bottom half of the following image: Object Detection vs Instance Segmentation. Image credit: Waleed Abdulla . Significant progress has been made over the past decades in the domain of object detection and instance segmentation (cf. e.g. this review paper ). Applications of object detection methods are today popular also in real-world products: for instance, some cars are already capable of detecting and reading speed limit signs; social media applications integrate photo and video effects based on face and pose detection. All these applications usually rely on deep learning methods, which are the subset of machine learning methods leveraging deep neural networks. While referring the reader to other sources for further information on machine and deep learning methods (cf. e.g. these lecture notes ), we wish to highlight a key point in all these approaches based on learning: no rigid, static, human-engineered rule is given to the machine to accomplish the task. Instead, the machine is provided with a collection of input-output pairs, where the output represents the outcome of a properly solved task. As far as object detection is concerned, we provide deep learning algorithms with a set of images accompanied by reference annotations (\"ground truth labels\"), which the machine is expected to reproduce. Clearly, things become interesting when the machine learns how to generate acceptable detections/segmentation on previously unseen images; such a crucial ability is referred to as \"generalization\". A generic framework was developed within the STDL, allowing the usage of state-of-the-art machine learning methods to detect objects in aerial images. Such framework allows one to leverage aerial images e.g. to provide valuable hints towards the update of cadastral information. At least as far as Switzerland is concerned, high-resolution (< 30 cm Ground Sample Distance) are acquired at the cantonal and federal scales on a regular basis. An inventory of the STDL's applications will be provided at the end of this article. The STDL's object detection framework is powered at its core by Detectron2 , a Python library developed by the Facebook Artificial Intelligence Research group and released under the Apache 2.0 open-source license . Detectron2 includes methods to train models performing various tasks, object detection and instance segmentation to name a few. Specific pieces of code were written by the STDL to pre-process data to be input to Detectron2, as well as to post-process outputs and turn them into meaningful information for the projects being developed. More precisely, our developments enable the usage of Detectron2 with georeferenced images and labels. Our workflow goes through the steps described here-below. Workflow \u00b6 1. Tileset generation \u00b6 Typically, aerial coverages are made accessible through Web Services, publicly or privately. While making opaque to the user the server-side tiling and file-based structure, these Web Services can efficiently generate raster images on-demand depending on the parameters sent by the requesting client. These parameters include: the bounding box of the requested area; the image width and height (in pixels); the reference system of both the bounding box (input) and the requested image (output). GIS tools such as QGIS and ArcGIS Pro as well as Web Applications powered by Web Mapping clients such as Leaflet , OpenLayers , MapLibre GL , etc. actually rely on this mechanism to let end-users navigating through tons of bits in quite a seamless, fluent, reactive way. As a matter of fact, zooming in and out in such 2D scenes amounts to fetching and visualizing different images depending on the zoom level, instead of \"simply\" increasing/decreasing the size of the various image pixels as displayed on screen. Through this 1st step of our workflow, several requests are issued against a Web Service in order to generate a consistent set of tiled images (\"tileset\") covering the so-called \" area of interest \" (AoI), namely the area over which the user intend to train a detection model and/or to perform the actual object detection. Connectors for the following two Web Services have been developed so far: OGC's Web Mapping Service (WMS) ; ESRI's Map Image Layer . XYZ link Except when using the XYZ connector that requires the EPSG:3857, our framework is agnostic with respect to the tiling scheme. The user has to provide as a input file compliant with some requirements. We refer the user to the code documentation for detailed information about these requirements. Concerning the AoI and its extension, the following scenarios are supported: training-only scenarios, i.e. the user intends to train a model to be used for detection at a later stage. In this case, the AoI would only cover the area for which reference, ground truth data exist. Detection-only (or \"inference-only\") scenarios, in which the user wishes to carry out object detection leveraging a previously trained model. In this case, the AoI would cover areas for which no reference data is available. Training AND detection scenarios, namely the composition of tasks 1 and 2. In the case of scenarios no. 1 and 3, ground truth labels are necessary. Provided by the user as polygons in some geographic coordinate system, the spatial coordinates of the vertices of these polygons must be mapped onto each image coordinate system - the latter ranging from (0, 0) to (<image width in pixels> - 1, <image height in pixels> - 1) - in order to generate reference, ground truth instance segmentations. Technically, such a mapping can be achieved through an affine transformation . Labels can optionally be provided in the case of inference-only scenarios as well, should the user be willing to check non-ground truth labels against detections and vice-versa. At least two somewhat \"standard\" data formats exist, which allow one to formalize the link between images and instance segmentations (cf. e.g. this article for further information): Pascal VOC, COCO . Since Detectron2 natively supports the latter but not the former, we made the obvious choice to opt for the COCO format. As mentioned above, machine learning models are valuable as far as they do not \"overfit\" to the training data; in other words, as far as they generalize well to new, unseen data. One of the techniques which are commonly used in order to prevent machine learning algorithms from overfitting is the \"train, validation, test split\". While referring the interested reader to this Wikipedia page for further details, let us note that a 70%-15%-15% split is currently hard-coded in our framework. Various independent COCO tilesets are generated, depending on the scenario: in training-only scenarios, three COCO tilesets are generated: training tileset, abbreviated as trn ; validation tileset ( val ); test tileset ( tst ). For now, training, validation and test tiles are chosen exclusively among the tiles of the AoI including one or more ground truth labels. Having realized that some of our models tend to produce false detections, we will shortly improve our framework in order to allow for unlabeled tiles within the training, validation, test tilesets. In inference-only scenarios, a single COCO tileset labeled as \"other\" is generated ( oth is the abbreviation we use). In training + inference scenarios, the full collection of tilesets is generated: trn , val , tst , oth . 2. Model training \u00b6 The 1st step provides a collection of consistent ( i.e. same size and resolution) tiled images and corresponding COCO files ( trn + val + tst and/or oth depending on the scenario). The 2nd step consists in training a prediction model by iterating over the training dataset, as customarily done in machine and deep learning. As already mentioned, we delegate this crucial part of the process to the Detectron2 library; support for other libraries may be implemented in the future, if suitable. Detectron2 comes with a large collection of pre-trained models tailored for various tasks. In particular, as far as instance segmentation is concerned, pre-trained models can be selected from this list . In our workflow, we setup Detectron2 in such a way that inference is made on the validation dataset every N training iterations, being N a user-defined parameter. By doing this, we can monitor both the training and validation losses all along the iterative learning and decide when to stop. Typically, learning is stopped when the validation loss reaches a minimum (cf. e.g. this article for further information on early stopping). As training and validation loss curves are somewhat noisy, typically an on-the-fly smoothing is applied in order to reveal steady trends. Other metrics may be tracked and used to decide when to stop. For now, within our framework (early) stopping can be done manually and is left to the user; it will be made automatic in the future, following some suitable criterion. Training and validation losses in a sample object detection task. In this case, one could stop the training after the first ~1400 iterations. Note that, in this example, the validation loss is evaluated every 200 iterations. Let us note that the learning process is regulated by several parameters, which are usually called \"hyper-parameters\" in order to distinguish them from the learned \"parameters\", the latter being - in our deep learning context - the coefficients of the many neurons populating the various layers of the deep neural network. In successful scenarios, the iterative learning process does actually lower the validation loss until a minimum value is reached. Yet, such a minimum is likely to be a \"local\" one ( i.e. relative to a given set of hyper-parameters); indeed, the global minimum may be found along a different trajectory, corresponding to a different set of hyper-parameters. Actually, even finding the global minimum of the validation loss could be not as relevant as checking how different models resulting from different choices of the hyper-parameters compare with each other on the common ground of more meaningful \"business metrics\". Even though currently our code does not implement any automatic hyper-parameter tuning, neither in terms of expert metrics nor in terms of business ones, we have already setup everything that is needed to produce business metrics, as explained here-below. 3. Detection \u00b6 The model trained at the preceding step can be used to perform the actual object detection or instance segmentation over the various tilesets concerned by a given study: in training-only scenarios, detections can be made on the training, validation and test sets, for model assessment purposes (cf. next section); in inference-only scenarios, detections can be made over the tileset which we call \"other\", for now. Depending on the configuration, Detectron2 is capable to perform either object detection AND instance segmentation at once, or object detection only. In both cases, every detection is accompanied by the following information: the class the detected object belongs to; a confidence score, ranging from 0 to 1. In the case of object detection only, a bounding box is output as a list of vertices relative to the image coordinate system. In case instance segmentation is demanded, detections are also output under the form of binary (\"monochromatic\") masks, one per input tile/image, in which pixels belonging to target objects are encoded with ones whereas background pixels are encoded with zeros. Detectron2 output is then converted into a georeferenced vector. Polygon geometry can be simplified using the Ramer-Douglas-Peucker algorithm (RDP) by tuning the epsilon parameter. 4. Assessment \u00b6 The results are evaluated by matching the detections and the ground truth labels, i.e. by finding detections overlapping with ground truth labels. To be considered a match, the intersection over union (IoU) between the detection polygon and label polygon must be greater than a threshold set by the user, with a default value = 0.25. In addition, if there are intersections between several detections and ground truth labels, only the pair with the largest IoU is considered to be a valid match. Intersection over union between a label and a detection is defined as: \\(\\mbox{IoU} = \\frac{A_{label \\cap detection}}{A_{label \\cup detection}}\\) The spatial intersection between the vectorized detections and the ground truth labels is computed to tag detections according to the following classification: true positive (TP): detections matching correctly a ground truth object; false positive (FP): detections not matching any ground truth object; false negative (FN): missing detections, namely objects of the ground truth which are not detected; wrong class: detections matching a ground truth object of another class. The reader may wonder why there are no true negatives (TN) in the list. Actually, all the image pixels which are rightly not associated with the target class can be considered as \"true negatives\". Yet, as far as object detection and instance segmentation are concerned, we do not need to group leftover pixels into some sort of \"dummy objects\". Should the user need to model such a scenario, one idea might consist in introducing a dummy class ( e.g. \"background\" or \"other\"), to which all the (ir)relevant pixels would be associated. The metrics are calculated per-class to take into account possible imbalances between classes. The detections in the wrong class will be classified as FN, i.e. missed object, or false positive (FP), i.e. detections not matching any object, depending on the target class we are calculating for. Precision and recall by class are used here: \\(\\mbox{precision}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FP}_{class}}\\) \\(\\mbox{recall}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FN}_{class}}\\) While referring the reader to this page for further information on these metrics, let us note that: Precision is optimal when it equals one, i.e. when the count of FPs is equal to zero. This metric measures how good the model is in detecting only objects with the class of interest; Recall is optimal when it equals one, i.e. when the count of FNs is equal to zero. This metric measures how good the model is in detecting all objects of the class of interest without missing any. Each metric can be aggregated to keep only one value per dataset, rather than one per class. \\(\\mbox{precision} = \\frac{\\sum_{class}\\mbox{precision}_{class}}{\\mbox{nbr of classes}}\\) \\(\\mbox{recall} = \\frac{\\sum_{class}\\mbox{recall}_{class}}{\\mbox{nbr of classes}}\\) As already mentioned, each detection is assigned a confidence score, ranging from 0 to 1. By filtering out all the detections exhibiting a score smaller than some cut-off/threshold value, one would end up having more or less detections to compare against ground truth data; the higher the threshold, the smaller the number of detections, the better their quality in terms of the confidence score. Sampling the threshold from a minimal user-defined value to a maximum value ( e.g. 0.95) and counting TPs, FPs, FNs at each sampling step, meaningful curves can be obtained representing counts and/or metrics like precision and recall as a function of the threshold. Typically, precision (recall) is monotonically increasing (decreasing) as a function of the threshold. As such, neither the precision nor the recall can be used to determine the optimal value of the threshold, which is why precision and recall are customarily aggregated in order to form a third metric which can be convex if computed as a function of the threshold or, at least, it can exhibit local minima. This metric is named \" \\(F_1\\) score\" and is defined as follows: \\(F_1 = 2\\times \\frac{\\mbox{precision}\\;\\times\\;\\mbox{recall}}{\\mbox{precision}\\; +\\; \\mbox{recall}}\\) Different models can then be compared with each other in terms of \\(F_1\\) scores; the best model can be selected as the one exhibiting the maximum \\(F_1\\) over the validation dataset. At last, the test dataset can be used to assess the selected model and provide the end-user with an objective figures concerning its reliability. Other approaches exist, allowing one to summarize metrics and eventually come up with threshold-independent scores. One of these approaches consist in computing the \"Area Under the ROC curve\" (AUC, cf. this page ) and will be soon implemented by the STDL. 5. Iterate until results are satisfactory \u00b6 Several training sessions can be executed, using different values of the various hyper-parameters involved in the process. As a matter of fact, reviewing and improving ground truth data is also part of the hyper-parameter tuning (cf. \" From Model-centric to Data-centric Artificial Intelligence ''). Keeping track of the above-mentioned metrics across multiple realizations, eventually an optimal model should be found (at least, a local optimum). The exploration of the hyper-parameter space is a tedious task, which consumes time as well as human and computing resources. It can be performed in a more or less systematic/heuristic way, depending on the experience of the operator as well as on the features offered by the code. Typically, a partial exploration is enough to obtain acceptable results. Within the STDL team, it is customary to first perform some iterations until \"decent scores\" are obtained, then to involve beneficiaries and domain experts in the continuous evaluation and improvement of results, until satisfactory results are obtained. These exchanges between data scientists and domain experts are also key to raise both communities' awareness of the virtues and flaws of machine learning approaches. Use cases \u00b6 Here is a list of the successful applications of the object detection framework described in this article: Automatic detection of quarries Swimming Pool Detection for the Canton of Geneva Swimming Pool Detection for the Canton of Thurgau Classification of road surfaces Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau Concluding remarks \u00b6 The STDL's object detection framework is still under development and receives updates as new use cases are tackled.","title":"<span style=\"text-transform:uppercase;\"> Object Detection Framework </span>"},{"location":"TASK-IDET/#object-detection-framework","text":"Alessandro Cerioni, Etat de Geneve - Cl\u00e9mence Herny, Exolabs - Adrian F. Meyer, FHNW - Gwena\u00eblle Salamin, Exolabs Published on November 22, 2021 Updated on December 12, 2023 Abstract : The STDL develops a framework allowing users to train and use deep learning models to detect objects in aerial images. While relying on a generic-purpose third-party open-source library, the STDL's framework implements a somewhat opinionated workflow, targeting georeferenced aerial images and labels. After a brief introduction to object detection, this article provides detailed information on the STDL's object detection framework and the opinions it implements. References to successful applications are provided along with concluding remarks.","title":" Object Detection Framework "},{"location":"TASK-IDET/#introduction","text":"Object detection is a computer vision task which aims at detecting instances of objects of some target classes ( e.g. buildings, swimming pools, solar panels, ...) in digital images and videos. According to the commonly adopted terminology, a distinction is made between the following tasks: object detection , in which the goal is to determine the rectangular \"bounding box\" surrounding each detected object; instance segmentation , in which one aims at finding the pixels belonging to each detected object. This distinction is well illustrated by the bottom half of the following image: Object Detection vs Instance Segmentation. Image credit: Waleed Abdulla . Significant progress has been made over the past decades in the domain of object detection and instance segmentation (cf. e.g. this review paper ). Applications of object detection methods are today popular also in real-world products: for instance, some cars are already capable of detecting and reading speed limit signs; social media applications integrate photo and video effects based on face and pose detection. All these applications usually rely on deep learning methods, which are the subset of machine learning methods leveraging deep neural networks. While referring the reader to other sources for further information on machine and deep learning methods (cf. e.g. these lecture notes ), we wish to highlight a key point in all these approaches based on learning: no rigid, static, human-engineered rule is given to the machine to accomplish the task. Instead, the machine is provided with a collection of input-output pairs, where the output represents the outcome of a properly solved task. As far as object detection is concerned, we provide deep learning algorithms with a set of images accompanied by reference annotations (\"ground truth labels\"), which the machine is expected to reproduce. Clearly, things become interesting when the machine learns how to generate acceptable detections/segmentation on previously unseen images; such a crucial ability is referred to as \"generalization\". A generic framework was developed within the STDL, allowing the usage of state-of-the-art machine learning methods to detect objects in aerial images. Such framework allows one to leverage aerial images e.g. to provide valuable hints towards the update of cadastral information. At least as far as Switzerland is concerned, high-resolution (< 30 cm Ground Sample Distance) are acquired at the cantonal and federal scales on a regular basis. An inventory of the STDL's applications will be provided at the end of this article. The STDL's object detection framework is powered at its core by Detectron2 , a Python library developed by the Facebook Artificial Intelligence Research group and released under the Apache 2.0 open-source license . Detectron2 includes methods to train models performing various tasks, object detection and instance segmentation to name a few. Specific pieces of code were written by the STDL to pre-process data to be input to Detectron2, as well as to post-process outputs and turn them into meaningful information for the projects being developed. More precisely, our developments enable the usage of Detectron2 with georeferenced images and labels. Our workflow goes through the steps described here-below.","title":"Introduction"},{"location":"TASK-IDET/#workflow","text":"","title":"Workflow"},{"location":"TASK-IDET/#1-tileset-generation","text":"Typically, aerial coverages are made accessible through Web Services, publicly or privately. While making opaque to the user the server-side tiling and file-based structure, these Web Services can efficiently generate raster images on-demand depending on the parameters sent by the requesting client. These parameters include: the bounding box of the requested area; the image width and height (in pixels); the reference system of both the bounding box (input) and the requested image (output). GIS tools such as QGIS and ArcGIS Pro as well as Web Applications powered by Web Mapping clients such as Leaflet , OpenLayers , MapLibre GL , etc. actually rely on this mechanism to let end-users navigating through tons of bits in quite a seamless, fluent, reactive way. As a matter of fact, zooming in and out in such 2D scenes amounts to fetching and visualizing different images depending on the zoom level, instead of \"simply\" increasing/decreasing the size of the various image pixels as displayed on screen. Through this 1st step of our workflow, several requests are issued against a Web Service in order to generate a consistent set of tiled images (\"tileset\") covering the so-called \" area of interest \" (AoI), namely the area over which the user intend to train a detection model and/or to perform the actual object detection. Connectors for the following two Web Services have been developed so far: OGC's Web Mapping Service (WMS) ; ESRI's Map Image Layer . XYZ link Except when using the XYZ connector that requires the EPSG:3857, our framework is agnostic with respect to the tiling scheme. The user has to provide as a input file compliant with some requirements. We refer the user to the code documentation for detailed information about these requirements. Concerning the AoI and its extension, the following scenarios are supported: training-only scenarios, i.e. the user intends to train a model to be used for detection at a later stage. In this case, the AoI would only cover the area for which reference, ground truth data exist. Detection-only (or \"inference-only\") scenarios, in which the user wishes to carry out object detection leveraging a previously trained model. In this case, the AoI would cover areas for which no reference data is available. Training AND detection scenarios, namely the composition of tasks 1 and 2. In the case of scenarios no. 1 and 3, ground truth labels are necessary. Provided by the user as polygons in some geographic coordinate system, the spatial coordinates of the vertices of these polygons must be mapped onto each image coordinate system - the latter ranging from (0, 0) to (<image width in pixels> - 1, <image height in pixels> - 1) - in order to generate reference, ground truth instance segmentations. Technically, such a mapping can be achieved through an affine transformation . Labels can optionally be provided in the case of inference-only scenarios as well, should the user be willing to check non-ground truth labels against detections and vice-versa. At least two somewhat \"standard\" data formats exist, which allow one to formalize the link between images and instance segmentations (cf. e.g. this article for further information): Pascal VOC, COCO . Since Detectron2 natively supports the latter but not the former, we made the obvious choice to opt for the COCO format. As mentioned above, machine learning models are valuable as far as they do not \"overfit\" to the training data; in other words, as far as they generalize well to new, unseen data. One of the techniques which are commonly used in order to prevent machine learning algorithms from overfitting is the \"train, validation, test split\". While referring the interested reader to this Wikipedia page for further details, let us note that a 70%-15%-15% split is currently hard-coded in our framework. Various independent COCO tilesets are generated, depending on the scenario: in training-only scenarios, three COCO tilesets are generated: training tileset, abbreviated as trn ; validation tileset ( val ); test tileset ( tst ). For now, training, validation and test tiles are chosen exclusively among the tiles of the AoI including one or more ground truth labels. Having realized that some of our models tend to produce false detections, we will shortly improve our framework in order to allow for unlabeled tiles within the training, validation, test tilesets. In inference-only scenarios, a single COCO tileset labeled as \"other\" is generated ( oth is the abbreviation we use). In training + inference scenarios, the full collection of tilesets is generated: trn , val , tst , oth .","title":"1. Tileset generation"},{"location":"TASK-IDET/#2-model-training","text":"The 1st step provides a collection of consistent ( i.e. same size and resolution) tiled images and corresponding COCO files ( trn + val + tst and/or oth depending on the scenario). The 2nd step consists in training a prediction model by iterating over the training dataset, as customarily done in machine and deep learning. As already mentioned, we delegate this crucial part of the process to the Detectron2 library; support for other libraries may be implemented in the future, if suitable. Detectron2 comes with a large collection of pre-trained models tailored for various tasks. In particular, as far as instance segmentation is concerned, pre-trained models can be selected from this list . In our workflow, we setup Detectron2 in such a way that inference is made on the validation dataset every N training iterations, being N a user-defined parameter. By doing this, we can monitor both the training and validation losses all along the iterative learning and decide when to stop. Typically, learning is stopped when the validation loss reaches a minimum (cf. e.g. this article for further information on early stopping). As training and validation loss curves are somewhat noisy, typically an on-the-fly smoothing is applied in order to reveal steady trends. Other metrics may be tracked and used to decide when to stop. For now, within our framework (early) stopping can be done manually and is left to the user; it will be made automatic in the future, following some suitable criterion. Training and validation losses in a sample object detection task. In this case, one could stop the training after the first ~1400 iterations. Note that, in this example, the validation loss is evaluated every 200 iterations. Let us note that the learning process is regulated by several parameters, which are usually called \"hyper-parameters\" in order to distinguish them from the learned \"parameters\", the latter being - in our deep learning context - the coefficients of the many neurons populating the various layers of the deep neural network. In successful scenarios, the iterative learning process does actually lower the validation loss until a minimum value is reached. Yet, such a minimum is likely to be a \"local\" one ( i.e. relative to a given set of hyper-parameters); indeed, the global minimum may be found along a different trajectory, corresponding to a different set of hyper-parameters. Actually, even finding the global minimum of the validation loss could be not as relevant as checking how different models resulting from different choices of the hyper-parameters compare with each other on the common ground of more meaningful \"business metrics\". Even though currently our code does not implement any automatic hyper-parameter tuning, neither in terms of expert metrics nor in terms of business ones, we have already setup everything that is needed to produce business metrics, as explained here-below.","title":"2. Model training"},{"location":"TASK-IDET/#3-detection","text":"The model trained at the preceding step can be used to perform the actual object detection or instance segmentation over the various tilesets concerned by a given study: in training-only scenarios, detections can be made on the training, validation and test sets, for model assessment purposes (cf. next section); in inference-only scenarios, detections can be made over the tileset which we call \"other\", for now. Depending on the configuration, Detectron2 is capable to perform either object detection AND instance segmentation at once, or object detection only. In both cases, every detection is accompanied by the following information: the class the detected object belongs to; a confidence score, ranging from 0 to 1. In the case of object detection only, a bounding box is output as a list of vertices relative to the image coordinate system. In case instance segmentation is demanded, detections are also output under the form of binary (\"monochromatic\") masks, one per input tile/image, in which pixels belonging to target objects are encoded with ones whereas background pixels are encoded with zeros. Detectron2 output is then converted into a georeferenced vector. Polygon geometry can be simplified using the Ramer-Douglas-Peucker algorithm (RDP) by tuning the epsilon parameter.","title":"3. Detection"},{"location":"TASK-IDET/#4-assessment","text":"The results are evaluated by matching the detections and the ground truth labels, i.e. by finding detections overlapping with ground truth labels. To be considered a match, the intersection over union (IoU) between the detection polygon and label polygon must be greater than a threshold set by the user, with a default value = 0.25. In addition, if there are intersections between several detections and ground truth labels, only the pair with the largest IoU is considered to be a valid match. Intersection over union between a label and a detection is defined as: \\(\\mbox{IoU} = \\frac{A_{label \\cap detection}}{A_{label \\cup detection}}\\) The spatial intersection between the vectorized detections and the ground truth labels is computed to tag detections according to the following classification: true positive (TP): detections matching correctly a ground truth object; false positive (FP): detections not matching any ground truth object; false negative (FN): missing detections, namely objects of the ground truth which are not detected; wrong class: detections matching a ground truth object of another class. The reader may wonder why there are no true negatives (TN) in the list. Actually, all the image pixels which are rightly not associated with the target class can be considered as \"true negatives\". Yet, as far as object detection and instance segmentation are concerned, we do not need to group leftover pixels into some sort of \"dummy objects\". Should the user need to model such a scenario, one idea might consist in introducing a dummy class ( e.g. \"background\" or \"other\"), to which all the (ir)relevant pixels would be associated. The metrics are calculated per-class to take into account possible imbalances between classes. The detections in the wrong class will be classified as FN, i.e. missed object, or false positive (FP), i.e. detections not matching any object, depending on the target class we are calculating for. Precision and recall by class are used here: \\(\\mbox{precision}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FP}_{class}}\\) \\(\\mbox{recall}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FN}_{class}}\\) While referring the reader to this page for further information on these metrics, let us note that: Precision is optimal when it equals one, i.e. when the count of FPs is equal to zero. This metric measures how good the model is in detecting only objects with the class of interest; Recall is optimal when it equals one, i.e. when the count of FNs is equal to zero. This metric measures how good the model is in detecting all objects of the class of interest without missing any. Each metric can be aggregated to keep only one value per dataset, rather than one per class. \\(\\mbox{precision} = \\frac{\\sum_{class}\\mbox{precision}_{class}}{\\mbox{nbr of classes}}\\) \\(\\mbox{recall} = \\frac{\\sum_{class}\\mbox{recall}_{class}}{\\mbox{nbr of classes}}\\) As already mentioned, each detection is assigned a confidence score, ranging from 0 to 1. By filtering out all the detections exhibiting a score smaller than some cut-off/threshold value, one would end up having more or less detections to compare against ground truth data; the higher the threshold, the smaller the number of detections, the better their quality in terms of the confidence score. Sampling the threshold from a minimal user-defined value to a maximum value ( e.g. 0.95) and counting TPs, FPs, FNs at each sampling step, meaningful curves can be obtained representing counts and/or metrics like precision and recall as a function of the threshold. Typically, precision (recall) is monotonically increasing (decreasing) as a function of the threshold. As such, neither the precision nor the recall can be used to determine the optimal value of the threshold, which is why precision and recall are customarily aggregated in order to form a third metric which can be convex if computed as a function of the threshold or, at least, it can exhibit local minima. This metric is named \" \\(F_1\\) score\" and is defined as follows: \\(F_1 = 2\\times \\frac{\\mbox{precision}\\;\\times\\;\\mbox{recall}}{\\mbox{precision}\\; +\\; \\mbox{recall}}\\) Different models can then be compared with each other in terms of \\(F_1\\) scores; the best model can be selected as the one exhibiting the maximum \\(F_1\\) over the validation dataset. At last, the test dataset can be used to assess the selected model and provide the end-user with an objective figures concerning its reliability. Other approaches exist, allowing one to summarize metrics and eventually come up with threshold-independent scores. One of these approaches consist in computing the \"Area Under the ROC curve\" (AUC, cf. this page ) and will be soon implemented by the STDL.","title":"4. Assessment"},{"location":"TASK-IDET/#5-iterate-until-results-are-satisfactory","text":"Several training sessions can be executed, using different values of the various hyper-parameters involved in the process. As a matter of fact, reviewing and improving ground truth data is also part of the hyper-parameter tuning (cf. \" From Model-centric to Data-centric Artificial Intelligence ''). Keeping track of the above-mentioned metrics across multiple realizations, eventually an optimal model should be found (at least, a local optimum). The exploration of the hyper-parameter space is a tedious task, which consumes time as well as human and computing resources. It can be performed in a more or less systematic/heuristic way, depending on the experience of the operator as well as on the features offered by the code. Typically, a partial exploration is enough to obtain acceptable results. Within the STDL team, it is customary to first perform some iterations until \"decent scores\" are obtained, then to involve beneficiaries and domain experts in the continuous evaluation and improvement of results, until satisfactory results are obtained. These exchanges between data scientists and domain experts are also key to raise both communities' awareness of the virtues and flaws of machine learning approaches.","title":"5. Iterate until results are satisfactory"},{"location":"TASK-IDET/#use-cases","text":"Here is a list of the successful applications of the object detection framework described in this article: Automatic detection of quarries Swimming Pool Detection for the Canton of Geneva Swimming Pool Detection for the Canton of Thurgau Classification of road surfaces Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau","title":"Use cases"},{"location":"TASK-IDET/#concluding-remarks","text":"The STDL's object detection framework is still under development and receives updates as new use cases are tackled.","title":"Concluding remarks"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Swiss Territorial Data Lab - STDL \u00b6 The STDL aims to promote collective innovation around the Swiss territory and its digital copy. It mainly explores the possibilities provided by data science to improve official land registering. A multidisciplinary team composed of cantonal, federal and academic partners is reinforced by engineers specialized in geographical data science to tackle the challenges around the management of territorial data-sets. The developed STDL platform codes and documentation are published under open licenses to allow partners and Swiss territory management actors to leverage the developed technologies. Exploratory Projects \u00b6 Exploratory projects in the field of the Swiss territorial data are conducted at the demand of institutions or actors of the Swiss territory. The exploratory projects are conducted with the supervision of the principal in order to closely analyze the answers to the specifications along the project. The goal of exploratory project aims to provide proof-of-concept and expertise in the application of technologies to Swiss territorial data. Automatic detection and observation of mineral extraction sites in Switzerland January 2024 Cl\u00e9mence Herny (ExoLabs) - Shanci Li (Uzufly) - Alessandro Cerioni (Etat de Gen\u00e8ve) - Roxane Pott (Swisstopo) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY The study of the evolution of mineral extraction sites (MES) is primordial for the management of mineral resources and the assessment of their environmental impact. In this context, swisstopo has solicited the STDL to automate the vectorisation of MES over the years. This tedious task was previously carried out manually and was not regularly updated. Automatic object detection using a deep learning method was applied to SWISSIMAGE RGB orthophotos with a spatial resolution of 1.6 m px -1 . The trained model proved its ability to accurately detect MES, achieving a f1-score of 82%. Detection by inference was performed on images from 1999 to 2021, enabling us to track the evolution of potential MES over several years. Although the results are satisfactory, a careful examination of the detections must be carried out by experts to validate them as true MES. Despite this remaining manual work involved, the process is faster than a full manual vectorisation and can be used in the future to keep MES information up-to-date. Full article Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds August 2023 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Republic and Canton of Jura - PROJ-HETRES Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. Full article Using spatio-temporal neighbor data information to detect changes in land use and land cover April 2023 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used.It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. Full article Classification of road surfaces March 2023 Gwena\u00eblle Salamin (swisstopo) - Cl\u00e9mence Herny (Exolabs) - Roxane Pott (swisstopo) - Alessandro Cerioni (Canton of Geneva) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. Full article Tree Detection from Point Clouds for the Canton of Geneva March 2022 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. Full article Detection of thermal panels on canton territory to follow renewable energy deployment February 2022 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Full article Automatic detection of quarries and the lithology below them in Switzerland January 2022 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been mode manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an f1-score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. Full article Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau June 2021 Adrian Meyer (FHNW) - Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGLN The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. Full article Swimming Pool Detection for the Canton of Thurgau April 2021 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Full article Completion of the federal register of buildings and dwellings February 2021 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL The Swiss Federal Statistical Office is in charge of the national Register of of Buildings and Dwellings (RBD) which keep tracks of every existing building in Switzerland. Currently, the register is being completed with building in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issue dues to missing information and their difficulty to be collected. The construction years of the building is one missing information for large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Full article Swimming Pool Detection from Aerial Images over the Canton of Geneva January 2021 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Full article Difference models applied to the land register November 2020 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - TASK-DTRK Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Full article Research Developments \u00b6 Research developments are conducted aside of the research projects to provide a framework of tools and expertise around the Swiss territorial data and related technologies. The research developments are conducted according to the research plan established by the data scientists and validated by the steering committee. OBJECT DETECTION FRAMEWORK November 2021 Alessandro Cerioni (Canton of Geneva) - Cl\u00e9mence Herny (Exolabs) - Adrian Meyer (FHNW) - Gwena\u00eblle Salamin (Exolabs) Project scheduled in the STDL research roadmap - TASK-IDET This strategic component of the STDL consists of the automated analysis of geospatial images using deep learning while providing practical applications for specific use cases. The overall goal is the extraction of vectorized semantic information from remote sensing data. The involved case studies revolve around concrete object detection use cases deploying modern machine learning methods and utilizing a multitude of available datasets. The goal is to arrive at a prototypical platform for object detection which is highly useful not only for cadastre specialists and authorities but also for stakeholders at various contact points in society. Full article AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT November 2020 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Full article Steering Committee \u00b6 The steering committee of the Swiss Territorial Data Lab is composed of Swiss public administrations bringing their expertise and competences to guide the conducted projects and developments. Members of the STDL steering committee Submitting a project \u00b6 To submit a project to the STDL, simply fill this form . To contact the STDL, please write an email to info@stdl.ch . We will reply as soon as possible!","title":"Homepage"},{"location":"#swiss-territorial-data-lab-stdl","text":"The STDL aims to promote collective innovation around the Swiss territory and its digital copy. It mainly explores the possibilities provided by data science to improve official land registering. A multidisciplinary team composed of cantonal, federal and academic partners is reinforced by engineers specialized in geographical data science to tackle the challenges around the management of territorial data-sets. The developed STDL platform codes and documentation are published under open licenses to allow partners and Swiss territory management actors to leverage the developed technologies.","title":"Swiss Territorial Data Lab - STDL"},{"location":"#exploratory-projects","text":"Exploratory projects in the field of the Swiss territorial data are conducted at the demand of institutions or actors of the Swiss territory. The exploratory projects are conducted with the supervision of the principal in order to closely analyze the answers to the specifications along the project. The goal of exploratory project aims to provide proof-of-concept and expertise in the application of technologies to Swiss territorial data. Automatic detection and observation of mineral extraction sites in Switzerland January 2024 Cl\u00e9mence Herny (ExoLabs) - Shanci Li (Uzufly) - Alessandro Cerioni (Etat de Gen\u00e8ve) - Roxane Pott (Swisstopo) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY The study of the evolution of mineral extraction sites (MES) is primordial for the management of mineral resources and the assessment of their environmental impact. In this context, swisstopo has solicited the STDL to automate the vectorisation of MES over the years. This tedious task was previously carried out manually and was not regularly updated. Automatic object detection using a deep learning method was applied to SWISSIMAGE RGB orthophotos with a spatial resolution of 1.6 m px -1 . The trained model proved its ability to accurately detect MES, achieving a f1-score of 82%. Detection by inference was performed on images from 1999 to 2021, enabling us to track the evolution of potential MES over several years. Although the results are satisfactory, a careful examination of the detections must be carried out by experts to validate them as true MES. Despite this remaining manual work involved, the process is faster than a full manual vectorisation and can be used in the future to keep MES information up-to-date. Full article Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds August 2023 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Republic and Canton of Jura - PROJ-HETRES Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. Full article Using spatio-temporal neighbor data information to detect changes in land use and land cover April 2023 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used.It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. Full article Classification of road surfaces March 2023 Gwena\u00eblle Salamin (swisstopo) - Cl\u00e9mence Herny (Exolabs) - Roxane Pott (swisstopo) - Alessandro Cerioni (Canton of Geneva) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. Full article Tree Detection from Point Clouds for the Canton of Geneva March 2022 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. Full article Detection of thermal panels on canton territory to follow renewable energy deployment February 2022 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Full article Automatic detection of quarries and the lithology below them in Switzerland January 2022 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Proposed by the Federal Office of Topography swisstopo - TASK-DQRY Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been mode manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an f1-score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. Full article Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau June 2021 Adrian Meyer (FHNW) - Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGLN The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. Full article Swimming Pool Detection for the Canton of Thurgau April 2021 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Full article Completion of the federal register of buildings and dwellings February 2021 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL The Swiss Federal Statistical Office is in charge of the national Register of of Buildings and Dwellings (RBD) which keep tracks of every existing building in Switzerland. Currently, the register is being completed with building in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issue dues to missing information and their difficulty to be collected. The construction years of the building is one missing information for large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Full article Swimming Pool Detection from Aerial Images over the Canton of Geneva January 2021 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Full article Difference models applied to the land register November 2020 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - TASK-DTRK Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Full article","title":"Exploratory Projects"},{"location":"#research-developments","text":"Research developments are conducted aside of the research projects to provide a framework of tools and expertise around the Swiss territorial data and related technologies. The research developments are conducted according to the research plan established by the data scientists and validated by the steering committee. OBJECT DETECTION FRAMEWORK November 2021 Alessandro Cerioni (Canton of Geneva) - Cl\u00e9mence Herny (Exolabs) - Adrian Meyer (FHNW) - Gwena\u00eblle Salamin (Exolabs) Project scheduled in the STDL research roadmap - TASK-IDET This strategic component of the STDL consists of the automated analysis of geospatial images using deep learning while providing practical applications for specific use cases. The overall goal is the extraction of vectorized semantic information from remote sensing data. The involved case studies revolve around concrete object detection use cases deploying modern machine learning methods and utilizing a multitude of available datasets. The goal is to arrive at a prototypical platform for object detection which is highly useful not only for cadastre specialists and authorities but also for stakeholders at various contact points in society. Full article AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT November 2020 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Full article","title":"Research Developments"},{"location":"#steering-committee","text":"The steering committee of the Swiss Territorial Data Lab is composed of Swiss public administrations bringing their expertise and competences to guide the conducted projects and developments. Members of the STDL steering committee","title":"Steering Committee"},{"location":"#submitting-a-project","text":"To submit a project to the STDL, simply fill this form . To contact the STDL, please write an email to info@stdl.ch . We will reply as soon as possible!","title":"Submitting a project"},{"location":"PROJ-DQRY/","text":"Automatic Detection of Quarries and the Lithology below them in Switzerland \u00b6 Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Supervision : Nils Hamel (UNIGE) - Raphael Rollier (swisstopo) Proposed by swisstopo - PROJ-DQRY June 2021 to January 2022 - Published on January 30th, 2022 Abstract : Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been made manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an F1 Score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result. 1 - Introduction \u00b6 Mining is an important economic activity worldwide and this is also the case in Switzerland. The Confederation topographic office (swisstopo) is responsible for monitoring the presence of quarries and also the materials being explored. This is extremely relevant for planning the demand and shortage of explored materials and also their transportation through the country. As this of federal importance the mapping of these features is already done. Although this work is very detailed and accurate, quarries have a very characteristical updating pattern. Quarries can appear and disappear in a matter of a few months, in especial when they are relatively small, as in Switzerland. Therefore it is of interest of swisstopo to make an automatic detection of quarries in a way that it is also reproducible in time. A strategy offen offered by the Swiss Territorial Data Lab is the automatic detection of several objects in aerial imagery through deep learning, following our Object Detection Framework . In this case it is fully applicable as quarries in Switzerland are relatively small, so high resolution imagery is required, which is something our Neural Network has proven to tackle with mastery in past projects. This high resolution imagery is also reachable through SWISSIMAGE , aerial images from swisstopo that cover almost the whole country with a 10cm pixel size (GSD). Nevertheless, in order to train our neural network, and as it's usually the case in deep learning, several labelled images are required. These data work as ground truth so that the neural network \"learns\" what's the object to be detected and which should not. For this purpose, the work from the topographic landscape model ( TLM ) team of swisstopo has been of extreme importance. Among different surface features, quarries have been mapped all over Switzerland with a highly detailed scale. Although the high quality and precision of the labels from TLM, quarries are constantly changing, appearing and disappearing, and therefore the labels are not always synchronized with the images from SWISSIMAGE. This lack of of synchronization between these sets of data can be seen in Figure 1, where in the left one has the year of mapping of TLM and on the right the year of the SWISSIMAGE flights. Figure 1 : Comparison of TLM (left) and SWISSIMAGE (right) temporality. For this purpose, a two-times interaction was necessary with the domain expert. In order to have a ground truth that was fully synchronized with SWISSIMAGE we required two stages of training : one making use of the TLM data and a second one with a manual correction of the predicted labels from the first interaction. It is of crucial importance to state that this correction needed to be made by the domain expert so that he could carefully check each detection in pre-defined tiles. With that in hands, we could go further with a more trustworthy training. As stated, it is of interest of swisstopo to also identify the material being explored by every quarry. For that purpose, it was recommended the usage of the GeoCover dataset from swisstopo as well. This dataset a vector layer of the the geological cover of the whole Switzerland, which challenged us to cross the detector predictions with such vector information. In summary, the challenge of the STDL was to investigate to which extent is it possible to automatically detect quarries using Deep Learning considering their high update ratio using aerial imagery. 2 - Methodology \u00b6 First of all the \"area of interest\" must be identified. This is where the detection and training took place. In this case, a polygon of the whole Switzerland was used. After that, the area of interest is divided in several tiles of fixed size. This is then defining the slicing of SWISSIMAGE (given as WMS). For this study, tiles of different sizes were tested, being 500x500m tiles defined for final usage. Following the resolution of the images must be defined, which, again, after several tests, was defined as 512x512 pixels. For validation purposes the data is then split into Training, Validation and Testing. The training data-set is used inside the network for its learning; the validation is completely apart from training and used only to check results and testing is used for cross-validation. 70% of the data was used for training, 15% for validation and 15% for testing. To what concerns the labels, the ones from TLM were manually checked so that a group of approximately 250 labels with full synchronization with the SWISSIMAGE were found and recorded. Following, the first row training passes through the same framework from former STDL projects. We make use of a predictive Recursive-Convolutional Neural Network with ResNet-50 backbone provided by Detectron2 . A deeper explanation of the network functionality can be found here and here . Even with different parameters set, it was observed that predictions were including too much false positives, which were mainly made of snow. Most probably the reflectance of snow is similar to the one of quarries and this needed a special treatment. For this purpose, a filtering of the results was used. First of all the features were filtered based on the score values (0.9) and then by elevation, using the SRTM digital elevation model. As snow usually does not precipitate below around 1155 m, this was used as threshold. Finally an area threshold is also passed (using smallest predictions area) and predictions are merged. A more detailed description of how to operate this first filter can be seen here . Once several tests were performed, the new predictions were sent back to the domain expert for detailed revision with a rigid protocol. This included the removal of false positives and the inclusion of false negatives, mainly. This was performed by 4 different experts from swisstopo in 4 regions with the same amount of tiles to be analyzed. It is important to the state again the importance of domain expertise in this step, as a very careful and manual evaluation of what is and what is not a quarry must be made. Once the predictions were corrected, a new session of training was performed using different parameters. Once again, the same resolution and tile size were used as in the first iteration (512x512m tiles with 512x512 pixels of resolution), although this time a new filtering was developed. Very similar to the first one, but in a different order, allowing more aesthetical predictions in the end, something the domain expert was also carrying about. This procedure is summarized in figure 2. Figure 2 : Methodology applied for the detection of quarries and new training sessions. In the end, in order to also include the geological information of the detected quarries, a third layer resulting of the intersection of both the predictions and the GeoCover labels is created. This was done in a way that the final user can click to obtain both information on the quarry (when not a pure prediction) and the information of the geology/lithology on this part of the quarry. As a result, each resulting intersection poylgon contains both information from quarry and GeoCover. In order to evaluate the obtained results, the F1 Score was computed and also the final predictions were compared to the corrected labels from the domain expert side. This was done visually by acquiring the centroid of each quarry detected and by a heat-map, allowing one to detect the spatial pattern of detections. The heat-map was computed using 10'000 m radius and a 100 m pixel size. 3 - Results & Discussion \u00b6 In the first iteration, when the neural was trained with some labels of the TLM vector data, an optimal F1 score of approximately 0.78 was obtained. The figure 3 shows the behavior of the precision, recall and F1 score for the final model selected. Figure 3 : Precision, Recall and F1 score of the first iteration (using TLM data). Given the predictions resulting from the correction by the domain experts, there was an outstanding improve in the F1 score obtained, which was of approximately 0.85 in its optimal, as seen in figure 4. A total of 1265 were found in Switzerland after filtering. Figure 4 : Precision, Recall and F1 score of the second iteration (using data corrected by the domain expert). Figure 5 demonstrates some examples of detected quarries and this one can have some notion of the quality of the shape of the detections and how they mark the real-world quarries. Examples of false positives and false negatives, unfortunately still present in the detections are also shown. This is also an interesting demonstration of how some objects that are very similar to quarries, in the point of view of non-experts and how they may influence the results. These examples of errors are also an interesting indication of the importance of domain expertise in evaluating machine made results. Figure 5 : Examples of detected quarries, with true positive, false negative and false positive. To check on the validity of the new predictions generated, the centroid of them was plot along the centroid of the corrected labels, so one could check the spatial pattern of them and this way evaluate if they were respecting the same behavior. Figure 6 shows this plot. Figure 6 : Disposition of the centroids of assessed predictions and final predictions. One can see that despite some slight differences, the overall pattern is very similar among the disposition of the predictions. A very similar result can be seen with the computed heat-map of these points, seen in figure 7. Figure 7 : Heatmap of assessed predictions and final predictions. There is a small area to the west of the country where there were less detections than desired and in general there were more predictions than before. The objective of the heat-map is more to give a general view of the results than giving an exact comparison, as a point is created for every feature and the new filter used tended to smooth the results and join many features into a single one too. At the end the results were also intersected with GeoCover, which provide the Swiss soil detailed lithology, and an example of the results can be seen below using the QGIS Software. Figure 8 : Intersection of predictions with GeoCover seen in QGIS. Finally and most important, the domain expert was highly satisfied with this work, due to the support it can give to swisstopo and the TLM team in mapping the future quarries. The domain expert also demonstrated interest in pursuing the work by investigating the temporal pattern of quarries and detecting the volume of material in each quarry. 4 - Conclusion \u00b6 Through this collaboration with swisstopo, we managed to demonstrate that data science is able to provide relevant and efficient tool to ease complex and time-consuming task. With the produced inventory of the quarries on the whole Swiss territory, we were able to provide a quasi-exhaustive view of the situation to the domain expert, leading him to have a better view of the exploitation sites. This is of importance and a major step forward compared to the previous situation. Indeed, before this project, the only solution available to the domain expert was to gather all the federal and cantonal data, through non-standardized and time-consuming process, to hope having a beginning of an inventory, with temporality issues. With the developed prototype, within hours, the entire SWISSIMAGE data-set can be processed and turn into a full scale inventory, guiding the domain expert directly toward its interests. The resulting geographical layer can then be seen as the result of this demonstrator, able to turn the aerial images into a simple polygonal layer representing the quarries, with little false positive and false negative, providing the required view for the domain expert understanding of the Swiss situation. With such a result, it is possible to convolve it with all the other existing data, with the GeoCover in the first place. This lithology model of the Swiss soil can be intersected with the produced quarries layer in order to create a secondary geographical layer merging both quarries location and quarries soil type, leading to a powerful analyzing tool for the domain expert. The produced demonstrator shows that it is possible, in hours, to deduce a simple and reliable geographical layer based on a simple set of orthomosaic. The STDL then was able to prove the possibility to repeat the process along the time dimension, for future and past images, opening the way to build and rebuild the history and evolution of the quarries. With such a process, it will be possible to compute statistical quantities on the long term to catch the evolution and the resources, leading to more reliable strategical understanding of the Swiss resources and sovereignty.","title":"Automatic Detection of Quarries and the Lithology below them in Switzerland"},{"location":"PROJ-DQRY/#automatic-detection-of-quarries-and-the-lithology-below-them-in-switzerland","text":"Huriel Reichel (FHNW) - Nils Hamel (UNIGE) Supervision : Nils Hamel (UNIGE) - Raphael Rollier (swisstopo) Proposed by swisstopo - PROJ-DQRY June 2021 to January 2022 - Published on January 30th, 2022 Abstract : Mining is an important economic activity in Switzerland and therefore it is monitored by the Confederation through swisstopo. To this points, the identification of quarries has been made manually, which even being done with very high quality, unfortunately does not follow the constant changing and updating pattern of these features. For this reason, swisstopo contacted the STDL to automatically detect quarries through the whole country. The training was done using SWISSIMAGE with 10cm spatial resolution and the Deep Learning Framework from the STDL. Moreover there were two iteration steps with the domain expert which included the manual correction of detection for new training. Interaction with the domain expert was very relevant for final results and summing to his appreciation, an F1 Score of 85% was obtained in the end, which due to peculiar characteristics of quarries can be considered an optimal result.","title":"Automatic Detection of Quarries and the Lithology below them in Switzerland"},{"location":"PROJ-DQRY/#1-introduction","text":"Mining is an important economic activity worldwide and this is also the case in Switzerland. The Confederation topographic office (swisstopo) is responsible for monitoring the presence of quarries and also the materials being explored. This is extremely relevant for planning the demand and shortage of explored materials and also their transportation through the country. As this of federal importance the mapping of these features is already done. Although this work is very detailed and accurate, quarries have a very characteristical updating pattern. Quarries can appear and disappear in a matter of a few months, in especial when they are relatively small, as in Switzerland. Therefore it is of interest of swisstopo to make an automatic detection of quarries in a way that it is also reproducible in time. A strategy offen offered by the Swiss Territorial Data Lab is the automatic detection of several objects in aerial imagery through deep learning, following our Object Detection Framework . In this case it is fully applicable as quarries in Switzerland are relatively small, so high resolution imagery is required, which is something our Neural Network has proven to tackle with mastery in past projects. This high resolution imagery is also reachable through SWISSIMAGE , aerial images from swisstopo that cover almost the whole country with a 10cm pixel size (GSD). Nevertheless, in order to train our neural network, and as it's usually the case in deep learning, several labelled images are required. These data work as ground truth so that the neural network \"learns\" what's the object to be detected and which should not. For this purpose, the work from the topographic landscape model ( TLM ) team of swisstopo has been of extreme importance. Among different surface features, quarries have been mapped all over Switzerland with a highly detailed scale. Although the high quality and precision of the labels from TLM, quarries are constantly changing, appearing and disappearing, and therefore the labels are not always synchronized with the images from SWISSIMAGE. This lack of of synchronization between these sets of data can be seen in Figure 1, where in the left one has the year of mapping of TLM and on the right the year of the SWISSIMAGE flights. Figure 1 : Comparison of TLM (left) and SWISSIMAGE (right) temporality. For this purpose, a two-times interaction was necessary with the domain expert. In order to have a ground truth that was fully synchronized with SWISSIMAGE we required two stages of training : one making use of the TLM data and a second one with a manual correction of the predicted labels from the first interaction. It is of crucial importance to state that this correction needed to be made by the domain expert so that he could carefully check each detection in pre-defined tiles. With that in hands, we could go further with a more trustworthy training. As stated, it is of interest of swisstopo to also identify the material being explored by every quarry. For that purpose, it was recommended the usage of the GeoCover dataset from swisstopo as well. This dataset a vector layer of the the geological cover of the whole Switzerland, which challenged us to cross the detector predictions with such vector information. In summary, the challenge of the STDL was to investigate to which extent is it possible to automatically detect quarries using Deep Learning considering their high update ratio using aerial imagery.","title":"1 - Introduction"},{"location":"PROJ-DQRY/#2-methodology","text":"First of all the \"area of interest\" must be identified. This is where the detection and training took place. In this case, a polygon of the whole Switzerland was used. After that, the area of interest is divided in several tiles of fixed size. This is then defining the slicing of SWISSIMAGE (given as WMS). For this study, tiles of different sizes were tested, being 500x500m tiles defined for final usage. Following the resolution of the images must be defined, which, again, after several tests, was defined as 512x512 pixels. For validation purposes the data is then split into Training, Validation and Testing. The training data-set is used inside the network for its learning; the validation is completely apart from training and used only to check results and testing is used for cross-validation. 70% of the data was used for training, 15% for validation and 15% for testing. To what concerns the labels, the ones from TLM were manually checked so that a group of approximately 250 labels with full synchronization with the SWISSIMAGE were found and recorded. Following, the first row training passes through the same framework from former STDL projects. We make use of a predictive Recursive-Convolutional Neural Network with ResNet-50 backbone provided by Detectron2 . A deeper explanation of the network functionality can be found here and here . Even with different parameters set, it was observed that predictions were including too much false positives, which were mainly made of snow. Most probably the reflectance of snow is similar to the one of quarries and this needed a special treatment. For this purpose, a filtering of the results was used. First of all the features were filtered based on the score values (0.9) and then by elevation, using the SRTM digital elevation model. As snow usually does not precipitate below around 1155 m, this was used as threshold. Finally an area threshold is also passed (using smallest predictions area) and predictions are merged. A more detailed description of how to operate this first filter can be seen here . Once several tests were performed, the new predictions were sent back to the domain expert for detailed revision with a rigid protocol. This included the removal of false positives and the inclusion of false negatives, mainly. This was performed by 4 different experts from swisstopo in 4 regions with the same amount of tiles to be analyzed. It is important to the state again the importance of domain expertise in this step, as a very careful and manual evaluation of what is and what is not a quarry must be made. Once the predictions were corrected, a new session of training was performed using different parameters. Once again, the same resolution and tile size were used as in the first iteration (512x512m tiles with 512x512 pixels of resolution), although this time a new filtering was developed. Very similar to the first one, but in a different order, allowing more aesthetical predictions in the end, something the domain expert was also carrying about. This procedure is summarized in figure 2. Figure 2 : Methodology applied for the detection of quarries and new training sessions. In the end, in order to also include the geological information of the detected quarries, a third layer resulting of the intersection of both the predictions and the GeoCover labels is created. This was done in a way that the final user can click to obtain both information on the quarry (when not a pure prediction) and the information of the geology/lithology on this part of the quarry. As a result, each resulting intersection poylgon contains both information from quarry and GeoCover. In order to evaluate the obtained results, the F1 Score was computed and also the final predictions were compared to the corrected labels from the domain expert side. This was done visually by acquiring the centroid of each quarry detected and by a heat-map, allowing one to detect the spatial pattern of detections. The heat-map was computed using 10'000 m radius and a 100 m pixel size.","title":"2 - Methodology"},{"location":"PROJ-DQRY/#3-results-discussion","text":"In the first iteration, when the neural was trained with some labels of the TLM vector data, an optimal F1 score of approximately 0.78 was obtained. The figure 3 shows the behavior of the precision, recall and F1 score for the final model selected. Figure 3 : Precision, Recall and F1 score of the first iteration (using TLM data). Given the predictions resulting from the correction by the domain experts, there was an outstanding improve in the F1 score obtained, which was of approximately 0.85 in its optimal, as seen in figure 4. A total of 1265 were found in Switzerland after filtering. Figure 4 : Precision, Recall and F1 score of the second iteration (using data corrected by the domain expert). Figure 5 demonstrates some examples of detected quarries and this one can have some notion of the quality of the shape of the detections and how they mark the real-world quarries. Examples of false positives and false negatives, unfortunately still present in the detections are also shown. This is also an interesting demonstration of how some objects that are very similar to quarries, in the point of view of non-experts and how they may influence the results. These examples of errors are also an interesting indication of the importance of domain expertise in evaluating machine made results. Figure 5 : Examples of detected quarries, with true positive, false negative and false positive. To check on the validity of the new predictions generated, the centroid of them was plot along the centroid of the corrected labels, so one could check the spatial pattern of them and this way evaluate if they were respecting the same behavior. Figure 6 shows this plot. Figure 6 : Disposition of the centroids of assessed predictions and final predictions. One can see that despite some slight differences, the overall pattern is very similar among the disposition of the predictions. A very similar result can be seen with the computed heat-map of these points, seen in figure 7. Figure 7 : Heatmap of assessed predictions and final predictions. There is a small area to the west of the country where there were less detections than desired and in general there were more predictions than before. The objective of the heat-map is more to give a general view of the results than giving an exact comparison, as a point is created for every feature and the new filter used tended to smooth the results and join many features into a single one too. At the end the results were also intersected with GeoCover, which provide the Swiss soil detailed lithology, and an example of the results can be seen below using the QGIS Software. Figure 8 : Intersection of predictions with GeoCover seen in QGIS. Finally and most important, the domain expert was highly satisfied with this work, due to the support it can give to swisstopo and the TLM team in mapping the future quarries. The domain expert also demonstrated interest in pursuing the work by investigating the temporal pattern of quarries and detecting the volume of material in each quarry.","title":"3 - Results &amp; Discussion"},{"location":"PROJ-DQRY/#4-conclusion","text":"Through this collaboration with swisstopo, we managed to demonstrate that data science is able to provide relevant and efficient tool to ease complex and time-consuming task. With the produced inventory of the quarries on the whole Swiss territory, we were able to provide a quasi-exhaustive view of the situation to the domain expert, leading him to have a better view of the exploitation sites. This is of importance and a major step forward compared to the previous situation. Indeed, before this project, the only solution available to the domain expert was to gather all the federal and cantonal data, through non-standardized and time-consuming process, to hope having a beginning of an inventory, with temporality issues. With the developed prototype, within hours, the entire SWISSIMAGE data-set can be processed and turn into a full scale inventory, guiding the domain expert directly toward its interests. The resulting geographical layer can then be seen as the result of this demonstrator, able to turn the aerial images into a simple polygonal layer representing the quarries, with little false positive and false negative, providing the required view for the domain expert understanding of the Swiss situation. With such a result, it is possible to convolve it with all the other existing data, with the GeoCover in the first place. This lithology model of the Swiss soil can be intersected with the produced quarries layer in order to create a secondary geographical layer merging both quarries location and quarries soil type, leading to a powerful analyzing tool for the domain expert. The produced demonstrator shows that it is possible, in hours, to deduce a simple and reliable geographical layer based on a simple set of orthomosaic. The STDL then was able to prove the possibility to repeat the process along the time dimension, for future and past images, opening the way to build and rebuild the history and evolution of the quarries. With such a process, it will be possible to compute statistical quantities on the long term to catch the evolution and the resources, leading to more reliable strategical understanding of the Swiss resources and sovereignty.","title":"4 - Conclusion"},{"location":"PROJ-DQRY-TM/","text":"Automatic detection and observation of mineral extraction sites in Switzerland \u00b6 Cl\u00e9mence Herny (Exolabs), Shanci Li (Uzufly), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve), Roxane Pott (swisstopo) Proposed by swisstopo - PROJ-DQRY-TM October 2022 to February 2023 - Published on January 2024 Abstract : Studying the evolution of mineral extraction sites (MES) is of primary importance for assessing the availability of mineral resources, managing MES and evaluating the impact of mining activity on the environment. In Switzerland, MES are inventoried at local level by the cantons and at federal level by swisstopo. The latter performs manual vectorisation of MES boundaries. Unfortunately, although the data is of high quality, it is not regularly updated. To automate this tedious task and to better observe the evolution of MES, swisstopo has solicited the STDL to carry out an automatic detection of MES in Switzerland over the years. We performed instance segmentation using a deep learning method to automatically detect MES in RGB aerial images with a spatial resolution of 1.6 m px -1 . The detection model was trained with 266 labels and orthophotos from the SWISSIMAGE RGB mosaic published in 2020. The selected trained model achieved a f1-score of 82% on the validation dataset. The model was used to do detection by inference of potential MES in SWISSIMAGE RGB orthophotos from 1999 to 2021. The model shows good ability to detect potential MES with about 82% of labels detected for the 2020 SWISSIMAGE mosaic. The detections obtained with SWISSIMAGE orthophotos acquired over different years can be tracked to observe their temporal evolution. The framework developed can perform detection in an area of interest (about a third of Switzerland at the most) in just a few hours, which is a major advantage over manual mapping. We acknowledge that there are some missed and false detections in the final product, and the results need to be reviewed and validated by domain experts before being analysed and interpreted. The results can be used to perform statistics over time and update MES evolution in future image acquisitions. 1. Introduction \u00b6 1.1 Context \u00b6 Mineral extraction constitutes a strategic activity worldwide, including in Switzerland. Demand for mineral resources has been growing significantly in recent decades 1 , mainly due to the rapid increase in the production of batteries and electronic chips, or buildings construction, for example. As a result, the exploitation of some resources, such as rare earth elements, lithium, or sand, is putting pressure on their availability. Being able to observe the development of mineral extraction sites (MES) is of primary importance to adapting mining strategy and anticipating demand and shortage. Mining has also strong environmental and societal impact 2 3 . It implies the extraction of rocks and minerals from water ponds, cliffs, and quarries. The surface affected, initially natural areas, can reach up to thousands of square kilometres 1 . The extraction of some minerals could lead to soil and water pollution and involves polluting truck transport. Economic and political interests of some resources might overwhelm land protection, and conflicts are gradually intensifying 2 . MES are dynamic features that can evolve according to singular patterns, especially if they are small, as is the case in Switzerland. A site can expand horizontally and vertically or be filled to recover the site 4 2 3 5 . Changes can happen quickly, in a couple of months. As a results, updating the MES inventory can be challenging. There is a significant demand for effective MES observation of development worldwide. Majority of MES mapping is performed manually by visual inspection of images 1 . Alternatively, recent improvements in the availability of high spatial and temporal resolution space/airborne imagery and computational methods have encouraged the development of automated image processing. Supervised classification of spectral images is an effective method but requires complex workflow 6 4 2 . More recently, few studies have implemented deep learning algorithms to train models to detect extraction sites in images and have shown high levels of accuracy 3 . In Switzerland, MES management is historically regulated on a canton-based level using GIS data, including information about the MES location, extent, and extracted materials among others. At the federal level, swisstopo and the Federal Office of Statistics (FSO) observe the development of MES. swisstopo has carried out a detailed manual delineation of MES based on SWISSIMAGE dataset over Switzerland. In the scope to fasten and improving the process of MES mapping in Switzerland, we developed a method for automating MES detection over the years. Ultimately, the goal is to keep the database up to date when new images are acquired. The results can be statistically process to better assess the MES evolution over time in Switzerland. 1.2. Approach \u00b6 The STDL has developed a framework named object-detector to automatically detect objects in a georeferenced imagery dataset based on deep learning method. The framework can be adapted to detect MES (also referred as quarry in the project) in Switzerland. A project to automatically detect MES in Switzerland 7 has been carried out by the STDL in 2021 ( detector-interface framework). Detection of potential MES obtained by automatic detection on the 2020 SWISSIMAGE mosaic has already been delivered to swisstopo (layer 2021_10_STDL_QC1 ). The method has proven its efficiency detecting MES. The numerical model trained with the object detector achieved a f1-score of 82% and detected about 1200 potential MES over Switzerland. In this project, we aim to continue this work and extend it to a second objective, that of observing MES evolution over time. The main challenge is to prove the algorithm reliability for detecting objects in a multi-year dataset images acquired with different sensors. The project workflow is synthesised in Figure 1. First, a deep learning algorithm is trained using a manually mapped MES dataset that serves as ground truth (GT). After evaluating the performance of the trained model, the selected one was used to perform inference detection for a given year dataset and area of interest (AoI). The results were filtered to discard irrelevant detection. The operation was repeated over several years. Finally, each potential MES detected was tracked over the years to observe its evolution. Figure 1: Workflow diagram for automatic MES detection. In this report, we first describe the data used, including the image description and the definition of AoI. Then we explain the model training, evaluation and object detection procedure. Next, we present the results of potential MES detection and the MES tracking strategy. Finally, we provide conclusion and perspectives. 2. Data \u00b6 2.1 Images and area of interest \u00b6 Automatic detection of potential MES over the years in Switzerland was performed with aerial orthophotos from the swisstopo product SWISSIMAGE Journey . Images are georeferenced RGB TIF tiles with a size of 256 x 256 pixels (1 km 2 ). Product Year Coordinate system Spatial resolution SWISSIMAGE 10 cm 2017 - current CH1903+/MN95 (EPSG:2056) 0.10 m ( \\(\\sigma\\) \\(\\pm\\) 0.15 m) - 0.25 m SWISSIMAGE 25 cm 2005 - 2016 MN03 (2005 - 2007) and MN95 (since 2008) 0.25 m ( \\(\\sigma\\) \\(\\pm\\) 0.25 m) - 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 3.00 - 5.00 m) SWISSIMAGE 50 cm 1998 - 2004 MN03 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 0.50 m) Table 1: SWISSIMAGE products characteristics. Several SWISSIMAGE products exist, produced from different instrumentation (Table 1). SWISSIMAGE mosaics are built and published yearly. The year of the mosaic corresponds to the last year of the dataset publication, and the most recent orthophotos datasets available are then used to complete the mosaic. For example the 2020 SWISSIMAGE mosaic is a combination of 2020, 2019 and 2018 images acquisition. The 1998 mosaic release corresponds to a year of transition from black and white images ( SWISSIMAGE HIST ) to RGB images. For this study, only RGB data from 1999 to 2021 were considered. Figure 2: Acquisition footprint of SWISSIMAGE aerial orthophotos for the years 2016 to 2021. The SWISSIMAGE Journey mosaic in the background is the 2020 release. Acquisition footprints of yearly acquired orthophotos were used as AoI to perform MES detection through time. Over the years, the footprints may spatially overlap (Fig. 2). Since 2017, the geometry of the acquisition footprints has been quasi-constant, dividing Switzerland into three more or less equal areas, ensuring that the orthophotos are updated every three years. For the years before 2017, the acquisition footprints were not systematic and do not guarantee a periodically update of the orthophotos. The acquisition footprint may also not be spatially contiguous. Figure 3: Illustration of the combination of SWISSIMAGE images and FSO images for the 2007 SWISSIMAGE mosaic. (a) Overview of the 2007 SWISSIMAGE mosaic. The red polygon corresponds to the provided SWISSIMAGE acquisition footprint for 2007. The orange polygon corresponds to the surface covered by the new SWISSIMAGE for 2007. The remaining area of the red polygon corresponds to the FSO image dataset acquired in 2007. The black box indicates the panel (b) location, and the white box indicates the panel (c) location. (b) Side-by-side comparison of image composition in 2006 and 2007 SWISSIMAGE mosaics. (c) Examples of detection polygons (white polygons) obtained by inference on the 2007 SWISSIMAGE dataset (red box) and FSO images 2007 (outlined by black box). SWISSIMAGE Journey mosaics of 2005, 2006, and 2007 present a particularity as it is composed not only of 25 cm resolution SWISSIMAGE but also of orthophotos acquired for the FSO. These are tiff RGB orthophotos with a spatial resolution of 50 cm px -1 (coordinate system: CH1903/LV03 (EPSG:21781)) and have been integrated into the SWISSIMAGE Journey products. However, these images were discarded (modification of the footprint shape) from our dataset because they were causing issues in the MES automatic detection producing odd segmented detection shapes (Fig. 3). This is probably due to the different stretching of pixel colour between datasets. It also has to be noted that there are currently missing images (about 88 tiles at zoom level 16) in the 2020 SWISSIMAGE dataset. 2.2 Image fetching \u00b6 Pre-rendered SWISSIMAGE tiles (256 x 256 px, 1 km 2 ) are downloaded using the Web Map Tile Service (WMTS) wmts.geo.admin.ch via an XYZ connector. Tiles are served on a cartesian coordinates grid using a Web Mercator Quad projection and a coordinate reference system EPGS 3857. Position of a tile on the grid is defined by x and y coordinates and the pixel resolution of the image is defined by z , its zoom level. Changing the zoom level affects the resolution by a factor of 2 (Fig. 4). For instance a zoom level of 17 corresponds to a resolution of 0.8 m px -1 and a zoom level of 16 to a resolution of 1.6 m px -1 . Figure 4: Examples of tiles geometry at zoom level 16 (z16, black polygons) and at zoom level 17 (z17, blue polygons). The number of tiles for each zoom level is indicated in square brackets. The tiles are selected for model training, i.e. only tiles intersecting swissTLM3D labels (tlm-hr-trn-topo, yellow polygons). Note that in the subsequent project carried out by Reichel and Hamel (2021) 7 , the tiling method adopted was slightly different from the one adopted for this project. Custom size and resolution tiles were built. A sensitivity analysis of these two parameters was conducted and led to the choice of tiles with a size of about 500 m and a pixel resolution of about 1 m (above, the performance was not significantly improved). 2.3 Ground truth \u00b6 The MES labels originate from the swiss Topographic Landscape Model 3D ( swissTLM3D ) produced by swisstopo . swissTLM3D is a large-scale topographic landscape model of Switzerland, including manually drawn and georeferenced vectors of objects of interest at a high resolution, including MES features. Domain experts from swisstopo have carried out extensive work to review the labeled MES and to synchronise them with the 2020 SWISSIMAGE mosaic to improve the quality of the labeled dataset. A total of 266 labels are available. The mapped MES reveal the diversity of MES characteristics, such as the presence or absence of buildings/infrastructures, trucks, water pounds, and vegetation (Fig. 5). Figure 5: Examples of MES mapped in swissTLM3D and synchronised to 2020 SWISSIMAGE mosaic. These labels are used as the ground truth (GT) i.e. the reference dataset indicating the presence of a MES in an image. The GT is used both as input to train the model to detect MES and to evaluate the model performance. 3. Automatic detection methodology \u00b6 3.1 Deep learning algorithm for object detection \u00b6 Training and inference detection of potential MES in SWISSIMAGE were performed with the object detector framework. This project is based on the open source detectron2 framework 8 implemented with PyTorch by the Facebook Artificial Intelligence Research group (FAIR). Instance segmentation (delineation of object) was performed with a Mask R-CNN deep learning algorithm 9 . It is based on a Recursive-Convolutional Neural Network (CNN) with a backbone pre-trained model ResNet-50 (50 layers deep residual network). Images were annotated with custom COCO object based on the labels (class 'Quarry'). The model is trained with this dataset to later perform inference detection on images. If the object is detected by the algorithm, a pixel mask is produced with a confidence score (0 to 1) attributed to the detection (Fig. 6). Figure 6: Example of detection mask. The pink rectangle corresponds to the bounding box of the object, the object is segmented by the pink polygons associated with the detection class ('Quarry') and a confidence score. The object detector framework permits to convert detection mask to georeferenced polygon that can be used in GIS softwares. The implementation of the Ramer-Douglas-Peucker ( RDP ) algorithm, allows the simplification of the derived polygons by discarding non-essential points based on a smoothing parameter. This allow to considerably reduces the amount of data to be stored and prevent potential memory saturation while deriving detection polygons on large areas as it is the case for this study. 3.2 Model training \u00b6 Orthophotos from the 2020 SWISSIMAGE mosaic, for which the GT has been defined, were chosen to proceed the model training. Tiles intersecting labels were selected and split randomly into three datasets: the training dataset (70%), the validation dataset (15%), and the test dataset (15%). Addition of empty tiles (no annotation) to confront the model to landscapes not containing the target object has been tested ( Appendix A.1 ) but did not provide significant improvement in the model performance to be adopted. Figure 7: Training curves obtained at zoom level 16 on the 2020 SWISSIMAGE mosaic. The curves were obtained for the trained model 'replicate 3'. (a) Learning rate in function of iteration. The step was defined every 500 iterations. The initial learning rate was 5.0 x 10 -3 with a weight and bias decay of 1.0 x 10 -4 . (b) The total loss is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. (c) The validation loss curve is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. The vertical dashed black lines indicate the iteration minimising the validation loss curve, i.e. 3000. Models were trained with two images per batch ( Appendix A.2 ), a learning rate of 5 x 10 -3 , and a learning rate decay of 1 x 10 -4 every 500 steps (Fig. 7 (a)). For the given model, parameters and a zoom level of 16 ( Section 3.3.3 ), the training is performed over 7000 iterations and lasts about 1 hour on a 16 GiB GPU (NVIDIA Tesla T4) machine compatible with CUDA . The total (train and validation loss) loss curve decreases until reaching a quasi-steady state around 6000 iterations (Fig. 7 (b)). The optimal detection model corresponds to the one minimising the validation loss curve. This minimum is reached between 2000 and 3000 iterations (Fig. 7 (c)). 3.3 Metrics \u00b6 The model performance and detection reliability were assessed by comparing the results to the GT. The detection performed by the model can be either (1) a True Positive (TP), i.e. the detection is real (spatially intersecting the GT) ; (2) a False Positive i.e. the detection is not real (not spatially intersecting the GT) or (3) a False Negative (FN) i.e. the labeled object is not detected by the algorithm (Fig. 8). Tagging the detection (Fig. 9(a)) allows to calculate several metrics (Fig. 9(b)) such as: Figure 8: Examples of different detection cases. Label is represented with a yellow polygon and detection with a red polygon. (a) True Positive (TP) detection intersecting the GT, (b) a potential True Positive (TP?) detection with no GT, (c) False Negative (FN) case with no detection while GT exists, (d) False Positive (FP) detection of object that is not a MES. the recall , translating the amount of TP detections predicted by the model: \\[recall = \\frac{TP}{(TP + FN)}\\] the precision , translating the number of well-predicted TP among all the detections: \\[precision = \\frac{TP}{(TP + FP)}\\] the f1-score , the harmonic average of the precision and the recall: \\[f1 = 2 \\times \\frac{recall \\times precision}{recall + precision}\\] Figure 9: Evaluation of the trained model performance obtained at zoom level 16 for the trained model 'replicate 3' (Table 2). (a) Number of TP (blue), FN (red), and FP (green) as a function of detection score threshold for the validation dataset. (b) Metrics value, precision (blue), recall (red), and f1-score (green) as a function of the detection score threshold for the validation dataset. The maximum f1-score value is 82%. 4. Automatic detection model analysis \u00b6 4.1. Model performance and replicability \u00b6 Trained models reached f1-scores of about 80% with a standard deviation of 2% (Table 2). The performances are similar to the model trained by Reichel and Hamel (2021) 7 . model precision recall f1 replicate 1 0.84 0.79 0.82 replicate 2 0.77 0.76 0.76 replicate 3 0.83 0.81 0.82 replicate 4 0.89 0.77 0.82 replicate 5 0.78 0.82 0.80 Table 2: Metrics value computed for the validation dataset for trained models replicates with the 2020 SWISSIMAGE mosaic at zoom level 16. A variability is expected as the deep learning algorithm displays some random behavior, but it is supposed to be negligible. However, the observed model variability is enough to affect final results that might slightly change by using different trained models with same input parameters (Fig. 10). Figure 10: Detection polygons obtained for the different trained model replicates (Table 2) highlighting results variability. The labels correspond to orange polygons. The number in the square bracket corresponds to the number of polygons. The inference detections have been performed on a subset of 2000 tiles for the 2020 SWISSIMAGE at zoom level 16. Detections have been filtered according to the parameters defined in Section 5.1. To reduce the variability of the trained models, the random seeds of both detectron2 and python have been fixed. Neither of these attempts have been successful, and the variability remains. The nondeterministic behavior of detectron2 has been recognised ( issue 1 , issue 2 ), but no suitable solution has been provided yet. Further investigation on the model performance and consistency should be performed in the future. To mitigate the results variability of model replicates, we could consider in the future to combine the results of several model replicates to remove FP while preserving the TP and potential TP detection. The choice and number of models used should be evaluated. This method is tedious as it requires inference detection from several models, which can be time-consuming and computationally intensive. 4.2 Sensitivity to the zoom level \u00b6 Image resolution is dependent on the zoom level ( Section 2.2 ). To select the most suitable zoom level for MES detection, we performed a sensitivity analysis on trained model performance. Increasing the zoom level increases the value of the metrics following a global linear trend (Fig. 11). Figure 11: Metrics values (precision, recall and f1) as function of zoom level for the validation dataset. The results of the replicates performed at each zoom level are included (Table A1). Models trained at a higher zoom level performed better. However, a higher zoom level implies smaller tile and thus, a larger number of tiles to fill the AoI. For a typical AoI, i.e up to a third of Switzerland, this can lead to a large number of tiles to be stored and processed, leading to potential RAM and/or disk space saturation. For 2019 AoI, 89'290 tiles are required at zoom level 16 while 354'867 tiles are required at zoom level 17, taking respectively 3 hours and 11 hours to process on a 30 GiB RAM machine with a 16 GiB GP. Visual comparison of inference detection reveals that there was no significant improvement in the object detection quality from zoom level 16 to zoom level 17. Both zoom level present a similar proportion of detections intersecting labels (82% and 79% for zoom level 16 and zoom level 17 respectively). On the other hand, the quality of object detection at zoom level 15 was depreciated. Indeed, detection scores were lower, with only tens of detection scores above 0.95 while it was about 400 at zoom level 16 and about 64% of detection intersecting labels. 4.3 Model choice \u00b6 Based on tests performed, we selected the 'replicate 3' model, obtained (Tables 2 and A1) at zoom level 16, to perform inference detection. Models trained at zoom level 16 (1.6 m px -1 pixel resolution) have shown satisfying results in accurately detecting MES contour and limiting the number of FP with high detection score (Fig. 11). It represents a good trade-off between results reliability (f1-score between 76% and 82% on the validation dataset) and computational resources. Then, among all the replicates performed at zoom level 16, we selected the trained model 'replicate 3' (Table 2) because it combines both the highest metrics values (for the validation dataset but also the train and test datasets), close precision and recall values and a rather low amount of low score detections. 5. Automatic detection of MES \u00b6 5.1 Detection post-processing \u00b6 Detection by inference was performed over AoIs with a threshold detection score of 0.3 (Fig. 12). The low score filtering results in a large amount of detections. Several detections may overlap, potentially segmenting a single object. In addition a detection might be split into multiple tiles. To improve the pertinence and the aesthetics of the raw detection polygons, a post-processing procedure was applied. First, a large proportion of FP occurred in mountainous areas (rock outcrops and snow, Fig. 12(a)). We assumed MES are not present (or at least sparse) above a given altitude. An elevation filtering was applied using a Switzerland Digital Elevation Model (about 25 m px -1 ) derived from the SRTM instrument ( USGS - SRTM ). The maximum elevation of the labeled MES is about 1100 m. Second, detection aggregation was applied: - polygons were clustered ( K-means ) according to their centroid position. The method involves setting a predefined number k of clusters. Manual tests performed by Reichel and Hamel (2021) 7 concluded to set k equal to the number of detection divided by three. The highest detection score was assigned to the clustered detection. This method preserves the final integrity of detection polygons by retaining detection that has potentially a low confidence score but belongs to a cluster with a higher confidence score improving the final segmentation of the detected object. The value of the threshold score must be kept relatively low ( i.e. 0.3) when performing the detection to prevent removing too many polygons that could potentially be part of the detected object. We acknowledge that determining the optimal number of clusters by clustering validation indices rather than manual adjustment would be more robust. In addition, exploring other clustering methods, such as DBSCAN , based on local density, can be considered in the future. - score filtering was applied. - spatially close polygons were assumed to belong to the same MES and are merged according to a distance threshold. The averaged score of the merged detection polygons was ultimately computed. Finally, we assumed that a MES covers a minimal area. Detection with an area smaller than a given threshold were filtered out. The minimum MES area in the GT is 2270 m 2 . Figure 12: MES detection filtering. (a) Overview of the automatic detection of MES obtained with 2020 SWISSIMAGE at zoom level 16. Transparent red polygons (with associated confidence score in white) correspond to the raw object detection output and the red line polygons (with associated confidence score in red) correspond to the final filtered detection. The black box outlines the location of the (b) and (c) panel zoom. Note the large number of detection in the mountains (right area of the image). (b) Zoom on several raw detections polygons of a single object with their respective confidence score. (c) Zoom on a filtered detection polygon of a single object with the resulting score. Sensitivity of detections to these filters was investigated (Table 3). The quantitative evaluation of filter combination relevance is tricky as potential MES presence is performed by inference, and the GT provided by swissTLM3D constitutes an incomplete portion of the MES in Switzerland (2020). As indication, we computed the number of spatial intersection between ground truth and detection obtained with the 2020 SWISSIMAGE mosaic. Filter combination number 3 was adopted, allowing to detect about 82% of the GT with a relatively limited amount of FP detection compared to filter combinations 1 and 2 (from visual inspection). filters combination score threshold elevation threshold (m) area threshold (m 2 ) distance threshold (m) number of detection label detection (%) 1 0.95 2000 1100 10 1745 85.1 2 0.95 2000 1200 10 1862 86.6 3 0.95 5000 1200 10 1347 82.1 4 0.96 2000 1100 10 1331 81.3 5 0.96 2000 1200 8 1445 78.7 6 0.96 5000 1200 10 1004 74.3 Table 3: Threshold values of filtering parameters and their respective number of detections and intersection proportion with swissTLM3D labels. The detections have been obtained for the 2020 SWISSIMAGE mosaic. We acknowledged that for the selected filter combination, the area threshold value is higher than the smallest area value of the GT polygons. However, reducing the area value increases significantly the presence of FP. Thirteen labels display an area below 5000 m 2 . 5.2 Inference detections \u00b6 The trained model was used to perform inference detection on SWISSIMAGE orthophotos from 1999 to 2021. The automatic detection model shows good capabilities to detect MES in different years orthophotos (Fig. 13), despite being trained on the 2020 SWISSIMAGE mosaic. The model also demonstrates capabilities to detect potential MES that have not been mapped yet but are strong candidates. However, the model misses some labeled MES or potential MES (FN, Fig. 8). However, when the model process FSO images, with different colour stretching, it failed to correctly detect potential MES (Fig. 3). It reveals that images must have characteristics close to the training dataset for optimal results with a deep learning model. Figure 13: Examples of object detection segmented by polygons in different year orthophotos. The yellow polygon for the year 2020 panel of object ID 3761 corresponds to the label. Other coloured polygons correspond to the algorithm detection. Then, we acknowledge that a significant amount of FP detection can still be observed in our filtered detection dataset (Figs. 8 and 14). The main sources of FP are the presence of large rock outcrops, mountainous areas without vegetation, snow, river sand beds, brownish-coloured fields, or construction areas. MES present a large variety of features (buildings, water pounds, trucks, vegetation) (Fig. 5) which can be a source of confusion for the algorithm but even sometimes for human eye. Therefore, the robustness of the GT is crucial for reliable detection. The algorithm's results should be taken carefully. Figure 14: Examples of FP detection. (a) Snow patches (2019) ; (b) River sand beds and gullies (2019); (c) Brownish field (2020); (d) vineyards (2005); (e) Airport tarmac (2020); (f) Construction site (2008). The detections produced by the algorithm are potential MES, but the final results must be reviewed by experts in the field to discard remaining FP detection and correct FN before any processing or interpretation. 6. Observation of MES evolution \u00b6 6.1 Object tracking strategy \u00b6 Switzerland is covered by RGB SWISSIMAGE product over more than 20 years (1999 to actual), allowing changes to be detected (Fig. 13). Figure 15: Strategy for MES tracking over time. ID assignment to detection. Spatially intersecting polygons share the same ID allowing the MES to be tracked in a multi-year dataset. We assumed that detection polygons that overlap from one year to another describe a single object (Fig. 15). Overlapping detections and unique detections (which do not overlap with polygons from other years) in the multi-year dataset were assigned a unique object identifier (ID). A new object ID in the timeline indicates: - the first occurrence of the object detected in the dataset of the first year available for the area. It does not mean that the object was not present before, - the creation of a potential new MES. The disappearance of an object ID indicates its potential refill. Therefore, the chronology of MES, creation, evolution and filling, can be constrained. 6.2 Evolution of MES over years \u00b6 Figures 13 and 16 illustrate the ability of the trained model to detect and track a single object in a multi-year dataset. The detection over the years appears reliable and consistent, although object detection may be absent from a year dataset ( e.g. due to shadows or colour changes in the surroundings). Remember that the image coverage of a given area is not renewed every year. Characteristics of the potential MES, such as surface evolution (extension or retreat), can be quantified. For example, the surfaces of object IDs 239 and 3861 have more than doubled in about 20 years. Tracking object ID along with image visualisation allows observation of the opening and the closing of potential MES, as object IDs 31, 44, and 229. Figure 16: Detection area (m 2 ) as a function of years for several object ID. Figure 13 provides the visualisation of the object IDs selected. Each point corresponds to an object ID occurrence in the corresponding year dataset. The presence of an object in several years dataset strengthens the likeliness of the detected object to be an actual MES. On the other hand, object detection of only one occurrence is more likely a FP detection. 7. Conclusion and perspectives \u00b6 The project demonstrated the ability to automatically, quickly (a matter of hours for one AoI), and reliably detect potential MES in orthophotos of Switzerland with an automatic detection algorithm (deep learning). The selected trained model achieved a f1-score of 82% on the validation dataset. The final detection polygons accurately delineate the potential MES. We can track single MES through multiple years, emphasising the robustness of the method to detect objects in multi-year datasets despite the detection model being trained on a single dataset (2020 SWISSIMAGE mosaic). However, image colour stretching different from that used to train the model can significantly affect the model's ability to provide reliable detection, as was the case with the FSO images. Although the performance of the trained model is satisfactory, FP and FN are present in the datasets. They are mainly due to confusion of the algorithm between MES and rock outcrops, river sandbeds or construction sites. A manual verification of the relevance of the detection by experts in the field is necessary before processing and interpreting the data. Revision of all the detections from 1999 to 2021 is a time-consuming effort but is necessary to guarantee detection reliability. Despite the required manual checks, the provided framework and detection results constitute a valuable contribution that can greatly assist the inventory and the observation of MES evolution in Switzerland. It provides state-wide detection in a matter of hours, which is a considerable time-saving compared with manual mapping. It also enables MES detection with a standardised method, independent of the information or method adopted by the cantons. Further model improvements could be consider, such as increasing the metrics by improving GT quality, improving model learning strategy, mitigating the model learning variability, or test supervised clustering methods to find relevant detection. This work can be used to compute statistics to study long-term MES in Switzerland and better management of resources and land use in the future. MES detection can be combined with other data, such as the geologic layer, to identify the mineral/rocks exploited and high-resolution DEM ( swissALTI3D ) to infer elevation changes and observe excavation or filling of MES 5 . So far only RGB SWISSIMAGE orthophotos from 1999 to 2021 were processed. Prior to 1999, black and white orthophotos exist but the model trained on RGB images could not be applied trustfully to black and white images. Image colourisation tests (with the help of deep learning algorithm[@farella_colour_2022]) were performed and provided encouraging detection results. This avenue needs to be explored. Finally, automatic detection of MES is rare 1 3 , and most studies perform manual mapping. Therefore, the framework could be the extended to other datasets and/or other countries to provide a valuable asset to the community. A global mapping of MES has been completed with over 21'000 polygons 1 and can be used as a GT database to train an automatic detection model. Code availability \u00b6 The codes are stored and available on the STDL's github repository: proj-dqry : mineral extraction site framework object-detector : object detector framework Acknowledgements \u00b6 This project was made possible thanks to a tight collaboration between the STDL team and swisstopo . In particular, the STDL team acknowledges key contribution from Thomas Galfetti ( swisstopo ). This project has been funded by \"Strategie Suisse pour la G\u00e9oinformation\". Appendix \u00b6 A.1 Influence of empty tiles addition to model performance \u00b6 By selecting tiles intersecting only labels, the detection model is mainly confronted with the presence of the targeted object to be detected. Addition of non-label-intersecting tiles, i.e. empty tiles, provides landscape diversity that might help to improve the object detection performance. In order to evaluate the influence of adding empty tiles to the dataset used for the model performance, empty tiles were chosen randomly (not intersecting labels) within Switzerland boundaries and added to the tile dataset used for the model training (Fig. A1). Empty tiles were added to (1) the whole dataset split as for the initial dataset (training: 70%, test: 15%, and validation: 15%) and (2) only to the training dataset. A visual inspection must be performed to prevent a potential unlabeled MES to be present in the image and disturbing the algorithm learning. Figure A1: View of tiles intersecting (black) labels (yellow) and randomly selected empty tiles (red) in Switzerland. This case correspond to the addition of 35% empty tiles. Figure A1 reveals that adding empty tiles to the dataset does not significantly influence the metrics values. The number of TP, FP, and FN do not show significant variation. However, when performing an inference detection test on a subset of tiles (2000) for an AOI, it appears that the number of raw detections (unfiltered) is reduced as the number of empty tiles increases. However, visual inspection of the final detection after applying filters does not show significant improvement compared to a model trained without adding empty tiles. Figure A1: Influence of the addition of empty tiles (relative to the number of tiles intersecting labels) on trained performance for zoom levels 16 and 17 with (a) the F1-score as a function of the percentage of added empty tiles and (b) the normalised (by the number of tiles sampled = 2000) number of detection as a function of added empty tiles. Empty tiles have been added to only the train dataset for the 5% and 30% cases and to all datasets for 9%, 35%, 70%, and 140% cases. A considered solution to improve the results could be to specifically select tiles for which FP occurred and include them in the training dataset as empty tiles. This way, the model could be trained with relevant confounding features such as snow patches, river sandbeds, or gullies not labeled as GT. A.2 Sensitivity of the model to the number of images per batch \u00b6 During the model learning phase, the trained model is updated after each batch of samples was processed. Adding more samples, i.e. in our case images, to the batch can influence the model learning capacity. We investigated the role of adding more images per batch for a dataset with and without adding a portion of empty tiles to the learning dataset. Adding more images per batch speeds up the model learning (Table A1), and the minimum of the loss curve is reached for a smaller number of iterations. Figure A2: Metrics (precision, recall and f1-score) evolution with the number of images per batch during the model training. Results have been obtained on a dataset without empty tiles addition (red) and with the addition of 23% of empty tiles to the training dataset. Figure A2 reveals that the metrics values remain in a range of constant values while adding extra images to the batch in all cases (with or without empty tiles). A potential effect of adding more images to the batch is the reduction of the metrics variability between replicates of trained models as the range of metrics values is smaller for 8 images per batch than 2 images per batch. However, this observation has to be taken carefully as fewer replicates have been performed with 8 images per batch than for 2 or 4 images per batch. Further investigation would provide stronger insights on this effect. A.3 Evaluation of trained models \u00b6 Table A1 sumup metrics value obtained for all the configuration tested for the project. zoom level model empty tiles (%) image per batch optimum iteration precision recall f1 15 replicate 1 0 2 1000 0.727 0.810 0.766 16 replicate 1 0 2 2000 0.842 0.793 0.817 16 replicate 2 0 2 2000 0.767 0.760 0.763 16 replicate 3 0 2 3000 0.831 0.810 0.820 16 replicate 4 0 2 2000 0.886 0.769 0.826 16 replicate 5 0 2 2000 0.780 0.818 0.798 16 replicate 6 0 2 3000 0.781 0.826 0.803 16 replicate 7 0 4 1000 0.748 0.860 0.800 16 replicate 8 0 4 1000 0.779 0.785 0.782 16 replicate 9 0 8 1500 0.800 0.793 0.797 16 replicate 10 0 4 1000 0.796 0.744 0.769 16 replicate 11 0 8 1000 0.802 0.769 0.785 16 ET-250_allDS_1 34.2 2 2000 0.723 0.770 0.746 16 ET-250_allDS_2 34.2 2 3000 0.748 0.803 0.775 16 ET-1000_allDS_1 73.8 2 6000 0.782 0.815 0.798 16 ET-1000_allDS_2 69.8 2 6000 0.786 0.767 0.776 16 ET-1000_allDS_3 70.9 2 6000 0.777 0.810 0.793 16 ET-1000_allDS_4 73.8 2 6000 0.768 0.807 0.787 16 ET-2000_allDS_1 143.2 2 6000 0.761 0.748 0.754 16 ET-80_trnDS_1 5.4 2 2000 0.814 0.793 0.803 16 ET-80_trnDS_2 5.4 2 2000 0.835 0.752 0.791 16 ET-80_trnDS_3 5.4 2 2000 0.764 0.802 0.782 16 ET-400_trnDS_1 29.5 2 6000 0.817 0.777 0.797 16 ET-400_trnDS_2 29.5 2 5000 0.848 0.785 0.815 16 ET-400_trnDS_3 29.5 2 4000 0.758 0.802 0.779 16 ET-400_trnDS_4 29.5 4 2000 0.798 0.818 0.808 16 ET-400_trnDS_5 29.5 4 1000 0.825 0.777 0.800 16 ET-1000_trnDS_1 0 2 4000 0.758 0.802 0.779 17 replicate 1 0 2 5000 0.819 0.853 0.835 17 replicate 1 0 2 5000 0.803 0.891 0.845 17 replicate 1 0 2 5000 0.872 0.813 0.841 17 ET-250_allDS_1 16.8 2 3000 0.801 0.794 0.797 17 ET-1000_allDS_1 72.2 2 7000 0.743 0.765 0.754 18 replicate 1 0 2 10000 0.864 0.855 0.859 Table A1: Metrics value computed for the validation dataset for all the trained models with the 2020 SWISSIMAGE Journey mosaic at zoom level 16. Victor Maus, Stefan Giljum, Jakob Gutschlhofer, Dieison M. Da Silva, Michael Probst, Sidnei L. B. Gass, Sebastian Luckeneder, Mirko Lieber, and Ian McCallum. A global-scale data set of mining areas. Scientific Data , 7(1):289, September 2020. URL: https://www.nature.com/articles/s41597-020-00624-w , doi:10.1038/s41597-020-00624-w . \u21a9 \u21a9 \u21a9 \u21a9 \u21a9 Vicen\u00e7 Carabassa, Pau Montero, Marc Crespo, Joan-Cristian Padr\u00f3, Xavier Pons, Jaume Balagu\u00e9, Llu\u00eds Brotons, and Josep Maria Alca\u00f1iz. Unmanned aerial system protocol for quarry restoration and mineral extraction monitoring. Journal of Environmental Management , 270:110717, September 2020. URL: https://linkinghub.elsevier.com/retrieve/pii/S0301479720306496 , doi:10.1016/j.jenvman.2020.110717 . \u21a9 \u21a9 \u21a9 \u21a9 Chunsheng Wang, Lili Chang, Lingran Zhao, and Ruiqing Niu. Automatic Identification and Dynamic Monitoring of Open-Pit Mines Based on Improved Mask R-CNN and Transfer Learning. Remote Sensing , 12(21):3474, January 2020. URL: https://www.mdpi.com/2072-4292/12/21/3474 , doi:10.3390/rs12213474 . \u21a9 \u21a9 \u21a9 \u21a9 Haoteng Zhao, Yong Ma, Fu Chen, Jianbo Liu, Liyuan Jiang, Wutao Yao, and Jin Yang. Monitoring Quarry Area with Landsat Long Time-Series for Socioeconomic Study. Remote Sensing , 10(4):517, April 2018. URL: https://www.mdpi.com/2072-4292/10/4/517 , doi:10.3390/rs10040517 . \u21a9 \u21a9 Valentin Tertius Bickel and Andrea Manconi. Decadal Surface Changes and Displacements in Switzerland. Journal of Geovisualization and Spatial Analysis , 6(2):24, December 2022. URL: https://link.springer.com/10.1007/s41651-022-00119-9 , doi:10.1007/s41651-022-00119-9 . \u21a9 \u21a9 George P. Petropoulos, Panagiotis Partsinevelos, and Zinovia Mitraka. Change detection of surface mining activity and reclamation based on a machine learning approach of multi-temporal Landsat TM imagery. Geocarto International , 28(4):323\u2013342, July 2013. URL: http://www.tandfonline.com/doi/abs/10.1080/10106049.2012.706648 , doi:10.1080/10106049.2012.706648 . \u21a9 Huriel Reichel and Nils Hamel. Automatic Detection of Quarries and the Lithology below them in Switzerland. 2022. URL: file:///C:/Users/Clemence/Documents/STDL/Projects/proj-quarries/01_Documentation/Bibliography/Automatic%20Detection%20of%20Quarries%20and%20the%20Lithology%20below%20them%20in%20Switzerland%20-%20Swiss%20Territorial%20Data%20Lab.htm . \u21a9 \u21a9 \u21a9 \u21a9 Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2. 2019. URL: https://github.com/facebookresearch/detectron2 . \u21a9 Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross Girshick. Mask R-CNN. January 2018. arXiv:1703.06870 [cs]. URL: http://arxiv.org/abs/1703.06870 , doi:10.48550/arXiv.1703.06870 . \u21a9","title":"Automatic detection and observation of mineral extraction sites in Switzerland"},{"location":"PROJ-DQRY-TM/#automatic-detection-and-observation-of-mineral-extraction-sites-in-switzerland","text":"Cl\u00e9mence Herny (Exolabs), Shanci Li (Uzufly), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve), Roxane Pott (swisstopo) Proposed by swisstopo - PROJ-DQRY-TM October 2022 to February 2023 - Published on January 2024 Abstract : Studying the evolution of mineral extraction sites (MES) is of primary importance for assessing the availability of mineral resources, managing MES and evaluating the impact of mining activity on the environment. In Switzerland, MES are inventoried at local level by the cantons and at federal level by swisstopo. The latter performs manual vectorisation of MES boundaries. Unfortunately, although the data is of high quality, it is not regularly updated. To automate this tedious task and to better observe the evolution of MES, swisstopo has solicited the STDL to carry out an automatic detection of MES in Switzerland over the years. We performed instance segmentation using a deep learning method to automatically detect MES in RGB aerial images with a spatial resolution of 1.6 m px -1 . The detection model was trained with 266 labels and orthophotos from the SWISSIMAGE RGB mosaic published in 2020. The selected trained model achieved a f1-score of 82% on the validation dataset. The model was used to do detection by inference of potential MES in SWISSIMAGE RGB orthophotos from 1999 to 2021. The model shows good ability to detect potential MES with about 82% of labels detected for the 2020 SWISSIMAGE mosaic. The detections obtained with SWISSIMAGE orthophotos acquired over different years can be tracked to observe their temporal evolution. The framework developed can perform detection in an area of interest (about a third of Switzerland at the most) in just a few hours, which is a major advantage over manual mapping. We acknowledge that there are some missed and false detections in the final product, and the results need to be reviewed and validated by domain experts before being analysed and interpreted. The results can be used to perform statistics over time and update MES evolution in future image acquisitions.","title":"Automatic detection and observation of mineral extraction sites in Switzerland"},{"location":"PROJ-DQRY-TM/#1-introduction","text":"","title":"1. Introduction"},{"location":"PROJ-DQRY-TM/#11-context","text":"Mineral extraction constitutes a strategic activity worldwide, including in Switzerland. Demand for mineral resources has been growing significantly in recent decades 1 , mainly due to the rapid increase in the production of batteries and electronic chips, or buildings construction, for example. As a result, the exploitation of some resources, such as rare earth elements, lithium, or sand, is putting pressure on their availability. Being able to observe the development of mineral extraction sites (MES) is of primary importance to adapting mining strategy and anticipating demand and shortage. Mining has also strong environmental and societal impact 2 3 . It implies the extraction of rocks and minerals from water ponds, cliffs, and quarries. The surface affected, initially natural areas, can reach up to thousands of square kilometres 1 . The extraction of some minerals could lead to soil and water pollution and involves polluting truck transport. Economic and political interests of some resources might overwhelm land protection, and conflicts are gradually intensifying 2 . MES are dynamic features that can evolve according to singular patterns, especially if they are small, as is the case in Switzerland. A site can expand horizontally and vertically or be filled to recover the site 4 2 3 5 . Changes can happen quickly, in a couple of months. As a results, updating the MES inventory can be challenging. There is a significant demand for effective MES observation of development worldwide. Majority of MES mapping is performed manually by visual inspection of images 1 . Alternatively, recent improvements in the availability of high spatial and temporal resolution space/airborne imagery and computational methods have encouraged the development of automated image processing. Supervised classification of spectral images is an effective method but requires complex workflow 6 4 2 . More recently, few studies have implemented deep learning algorithms to train models to detect extraction sites in images and have shown high levels of accuracy 3 . In Switzerland, MES management is historically regulated on a canton-based level using GIS data, including information about the MES location, extent, and extracted materials among others. At the federal level, swisstopo and the Federal Office of Statistics (FSO) observe the development of MES. swisstopo has carried out a detailed manual delineation of MES based on SWISSIMAGE dataset over Switzerland. In the scope to fasten and improving the process of MES mapping in Switzerland, we developed a method for automating MES detection over the years. Ultimately, the goal is to keep the database up to date when new images are acquired. The results can be statistically process to better assess the MES evolution over time in Switzerland.","title":"1.1 Context"},{"location":"PROJ-DQRY-TM/#12-approach","text":"The STDL has developed a framework named object-detector to automatically detect objects in a georeferenced imagery dataset based on deep learning method. The framework can be adapted to detect MES (also referred as quarry in the project) in Switzerland. A project to automatically detect MES in Switzerland 7 has been carried out by the STDL in 2021 ( detector-interface framework). Detection of potential MES obtained by automatic detection on the 2020 SWISSIMAGE mosaic has already been delivered to swisstopo (layer 2021_10_STDL_QC1 ). The method has proven its efficiency detecting MES. The numerical model trained with the object detector achieved a f1-score of 82% and detected about 1200 potential MES over Switzerland. In this project, we aim to continue this work and extend it to a second objective, that of observing MES evolution over time. The main challenge is to prove the algorithm reliability for detecting objects in a multi-year dataset images acquired with different sensors. The project workflow is synthesised in Figure 1. First, a deep learning algorithm is trained using a manually mapped MES dataset that serves as ground truth (GT). After evaluating the performance of the trained model, the selected one was used to perform inference detection for a given year dataset and area of interest (AoI). The results were filtered to discard irrelevant detection. The operation was repeated over several years. Finally, each potential MES detected was tracked over the years to observe its evolution. Figure 1: Workflow diagram for automatic MES detection. In this report, we first describe the data used, including the image description and the definition of AoI. Then we explain the model training, evaluation and object detection procedure. Next, we present the results of potential MES detection and the MES tracking strategy. Finally, we provide conclusion and perspectives.","title":"1.2. Approach"},{"location":"PROJ-DQRY-TM/#2-data","text":"","title":"2. Data"},{"location":"PROJ-DQRY-TM/#21-images-and-area-of-interest","text":"Automatic detection of potential MES over the years in Switzerland was performed with aerial orthophotos from the swisstopo product SWISSIMAGE Journey . Images are georeferenced RGB TIF tiles with a size of 256 x 256 pixels (1 km 2 ). Product Year Coordinate system Spatial resolution SWISSIMAGE 10 cm 2017 - current CH1903+/MN95 (EPSG:2056) 0.10 m ( \\(\\sigma\\) \\(\\pm\\) 0.15 m) - 0.25 m SWISSIMAGE 25 cm 2005 - 2016 MN03 (2005 - 2007) and MN95 (since 2008) 0.25 m ( \\(\\sigma\\) \\(\\pm\\) 0.25 m) - 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 3.00 - 5.00 m) SWISSIMAGE 50 cm 1998 - 2004 MN03 0.50 m ( \\(\\sigma\\) \\(\\pm\\) 0.50 m) Table 1: SWISSIMAGE products characteristics. Several SWISSIMAGE products exist, produced from different instrumentation (Table 1). SWISSIMAGE mosaics are built and published yearly. The year of the mosaic corresponds to the last year of the dataset publication, and the most recent orthophotos datasets available are then used to complete the mosaic. For example the 2020 SWISSIMAGE mosaic is a combination of 2020, 2019 and 2018 images acquisition. The 1998 mosaic release corresponds to a year of transition from black and white images ( SWISSIMAGE HIST ) to RGB images. For this study, only RGB data from 1999 to 2021 were considered. Figure 2: Acquisition footprint of SWISSIMAGE aerial orthophotos for the years 2016 to 2021. The SWISSIMAGE Journey mosaic in the background is the 2020 release. Acquisition footprints of yearly acquired orthophotos were used as AoI to perform MES detection through time. Over the years, the footprints may spatially overlap (Fig. 2). Since 2017, the geometry of the acquisition footprints has been quasi-constant, dividing Switzerland into three more or less equal areas, ensuring that the orthophotos are updated every three years. For the years before 2017, the acquisition footprints were not systematic and do not guarantee a periodically update of the orthophotos. The acquisition footprint may also not be spatially contiguous. Figure 3: Illustration of the combination of SWISSIMAGE images and FSO images for the 2007 SWISSIMAGE mosaic. (a) Overview of the 2007 SWISSIMAGE mosaic. The red polygon corresponds to the provided SWISSIMAGE acquisition footprint for 2007. The orange polygon corresponds to the surface covered by the new SWISSIMAGE for 2007. The remaining area of the red polygon corresponds to the FSO image dataset acquired in 2007. The black box indicates the panel (b) location, and the white box indicates the panel (c) location. (b) Side-by-side comparison of image composition in 2006 and 2007 SWISSIMAGE mosaics. (c) Examples of detection polygons (white polygons) obtained by inference on the 2007 SWISSIMAGE dataset (red box) and FSO images 2007 (outlined by black box). SWISSIMAGE Journey mosaics of 2005, 2006, and 2007 present a particularity as it is composed not only of 25 cm resolution SWISSIMAGE but also of orthophotos acquired for the FSO. These are tiff RGB orthophotos with a spatial resolution of 50 cm px -1 (coordinate system: CH1903/LV03 (EPSG:21781)) and have been integrated into the SWISSIMAGE Journey products. However, these images were discarded (modification of the footprint shape) from our dataset because they were causing issues in the MES automatic detection producing odd segmented detection shapes (Fig. 3). This is probably due to the different stretching of pixel colour between datasets. It also has to be noted that there are currently missing images (about 88 tiles at zoom level 16) in the 2020 SWISSIMAGE dataset.","title":"2.1 Images and area of interest"},{"location":"PROJ-DQRY-TM/#22-image-fetching","text":"Pre-rendered SWISSIMAGE tiles (256 x 256 px, 1 km 2 ) are downloaded using the Web Map Tile Service (WMTS) wmts.geo.admin.ch via an XYZ connector. Tiles are served on a cartesian coordinates grid using a Web Mercator Quad projection and a coordinate reference system EPGS 3857. Position of a tile on the grid is defined by x and y coordinates and the pixel resolution of the image is defined by z , its zoom level. Changing the zoom level affects the resolution by a factor of 2 (Fig. 4). For instance a zoom level of 17 corresponds to a resolution of 0.8 m px -1 and a zoom level of 16 to a resolution of 1.6 m px -1 . Figure 4: Examples of tiles geometry at zoom level 16 (z16, black polygons) and at zoom level 17 (z17, blue polygons). The number of tiles for each zoom level is indicated in square brackets. The tiles are selected for model training, i.e. only tiles intersecting swissTLM3D labels (tlm-hr-trn-topo, yellow polygons). Note that in the subsequent project carried out by Reichel and Hamel (2021) 7 , the tiling method adopted was slightly different from the one adopted for this project. Custom size and resolution tiles were built. A sensitivity analysis of these two parameters was conducted and led to the choice of tiles with a size of about 500 m and a pixel resolution of about 1 m (above, the performance was not significantly improved).","title":"2.2 Image fetching"},{"location":"PROJ-DQRY-TM/#23-ground-truth","text":"The MES labels originate from the swiss Topographic Landscape Model 3D ( swissTLM3D ) produced by swisstopo . swissTLM3D is a large-scale topographic landscape model of Switzerland, including manually drawn and georeferenced vectors of objects of interest at a high resolution, including MES features. Domain experts from swisstopo have carried out extensive work to review the labeled MES and to synchronise them with the 2020 SWISSIMAGE mosaic to improve the quality of the labeled dataset. A total of 266 labels are available. The mapped MES reveal the diversity of MES characteristics, such as the presence or absence of buildings/infrastructures, trucks, water pounds, and vegetation (Fig. 5). Figure 5: Examples of MES mapped in swissTLM3D and synchronised to 2020 SWISSIMAGE mosaic. These labels are used as the ground truth (GT) i.e. the reference dataset indicating the presence of a MES in an image. The GT is used both as input to train the model to detect MES and to evaluate the model performance.","title":"2.3 Ground truth"},{"location":"PROJ-DQRY-TM/#3-automatic-detection-methodology","text":"","title":"3. Automatic detection methodology"},{"location":"PROJ-DQRY-TM/#31-deep-learning-algorithm-for-object-detection","text":"Training and inference detection of potential MES in SWISSIMAGE were performed with the object detector framework. This project is based on the open source detectron2 framework 8 implemented with PyTorch by the Facebook Artificial Intelligence Research group (FAIR). Instance segmentation (delineation of object) was performed with a Mask R-CNN deep learning algorithm 9 . It is based on a Recursive-Convolutional Neural Network (CNN) with a backbone pre-trained model ResNet-50 (50 layers deep residual network). Images were annotated with custom COCO object based on the labels (class 'Quarry'). The model is trained with this dataset to later perform inference detection on images. If the object is detected by the algorithm, a pixel mask is produced with a confidence score (0 to 1) attributed to the detection (Fig. 6). Figure 6: Example of detection mask. The pink rectangle corresponds to the bounding box of the object, the object is segmented by the pink polygons associated with the detection class ('Quarry') and a confidence score. The object detector framework permits to convert detection mask to georeferenced polygon that can be used in GIS softwares. The implementation of the Ramer-Douglas-Peucker ( RDP ) algorithm, allows the simplification of the derived polygons by discarding non-essential points based on a smoothing parameter. This allow to considerably reduces the amount of data to be stored and prevent potential memory saturation while deriving detection polygons on large areas as it is the case for this study.","title":"3.1 Deep learning algorithm for object detection"},{"location":"PROJ-DQRY-TM/#32-model-training","text":"Orthophotos from the 2020 SWISSIMAGE mosaic, for which the GT has been defined, were chosen to proceed the model training. Tiles intersecting labels were selected and split randomly into three datasets: the training dataset (70%), the validation dataset (15%), and the test dataset (15%). Addition of empty tiles (no annotation) to confront the model to landscapes not containing the target object has been tested ( Appendix A.1 ) but did not provide significant improvement in the model performance to be adopted. Figure 7: Training curves obtained at zoom level 16 on the 2020 SWISSIMAGE mosaic. The curves were obtained for the trained model 'replicate 3'. (a) Learning rate in function of iteration. The step was defined every 500 iterations. The initial learning rate was 5.0 x 10 -3 with a weight and bias decay of 1.0 x 10 -4 . (b) The total loss is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. (c) The validation loss curve is a function of iteration. Raw measurement (light red) and smoothed curve (0.6 factor, solid red) are superposed. The vertical dashed black lines indicate the iteration minimising the validation loss curve, i.e. 3000. Models were trained with two images per batch ( Appendix A.2 ), a learning rate of 5 x 10 -3 , and a learning rate decay of 1 x 10 -4 every 500 steps (Fig. 7 (a)). For the given model, parameters and a zoom level of 16 ( Section 3.3.3 ), the training is performed over 7000 iterations and lasts about 1 hour on a 16 GiB GPU (NVIDIA Tesla T4) machine compatible with CUDA . The total (train and validation loss) loss curve decreases until reaching a quasi-steady state around 6000 iterations (Fig. 7 (b)). The optimal detection model corresponds to the one minimising the validation loss curve. This minimum is reached between 2000 and 3000 iterations (Fig. 7 (c)).","title":"3.2 Model training"},{"location":"PROJ-DQRY-TM/#33-metrics","text":"The model performance and detection reliability were assessed by comparing the results to the GT. The detection performed by the model can be either (1) a True Positive (TP), i.e. the detection is real (spatially intersecting the GT) ; (2) a False Positive i.e. the detection is not real (not spatially intersecting the GT) or (3) a False Negative (FN) i.e. the labeled object is not detected by the algorithm (Fig. 8). Tagging the detection (Fig. 9(a)) allows to calculate several metrics (Fig. 9(b)) such as: Figure 8: Examples of different detection cases. Label is represented with a yellow polygon and detection with a red polygon. (a) True Positive (TP) detection intersecting the GT, (b) a potential True Positive (TP?) detection with no GT, (c) False Negative (FN) case with no detection while GT exists, (d) False Positive (FP) detection of object that is not a MES. the recall , translating the amount of TP detections predicted by the model: \\[recall = \\frac{TP}{(TP + FN)}\\] the precision , translating the number of well-predicted TP among all the detections: \\[precision = \\frac{TP}{(TP + FP)}\\] the f1-score , the harmonic average of the precision and the recall: \\[f1 = 2 \\times \\frac{recall \\times precision}{recall + precision}\\] Figure 9: Evaluation of the trained model performance obtained at zoom level 16 for the trained model 'replicate 3' (Table 2). (a) Number of TP (blue), FN (red), and FP (green) as a function of detection score threshold for the validation dataset. (b) Metrics value, precision (blue), recall (red), and f1-score (green) as a function of the detection score threshold for the validation dataset. The maximum f1-score value is 82%.","title":"3.3 Metrics"},{"location":"PROJ-DQRY-TM/#4-automatic-detection-model-analysis","text":"","title":"4. Automatic detection model analysis"},{"location":"PROJ-DQRY-TM/#41-model-performance-and-replicability","text":"Trained models reached f1-scores of about 80% with a standard deviation of 2% (Table 2). The performances are similar to the model trained by Reichel and Hamel (2021) 7 . model precision recall f1 replicate 1 0.84 0.79 0.82 replicate 2 0.77 0.76 0.76 replicate 3 0.83 0.81 0.82 replicate 4 0.89 0.77 0.82 replicate 5 0.78 0.82 0.80 Table 2: Metrics value computed for the validation dataset for trained models replicates with the 2020 SWISSIMAGE mosaic at zoom level 16. A variability is expected as the deep learning algorithm displays some random behavior, but it is supposed to be negligible. However, the observed model variability is enough to affect final results that might slightly change by using different trained models with same input parameters (Fig. 10). Figure 10: Detection polygons obtained for the different trained model replicates (Table 2) highlighting results variability. The labels correspond to orange polygons. The number in the square bracket corresponds to the number of polygons. The inference detections have been performed on a subset of 2000 tiles for the 2020 SWISSIMAGE at zoom level 16. Detections have been filtered according to the parameters defined in Section 5.1. To reduce the variability of the trained models, the random seeds of both detectron2 and python have been fixed. Neither of these attempts have been successful, and the variability remains. The nondeterministic behavior of detectron2 has been recognised ( issue 1 , issue 2 ), but no suitable solution has been provided yet. Further investigation on the model performance and consistency should be performed in the future. To mitigate the results variability of model replicates, we could consider in the future to combine the results of several model replicates to remove FP while preserving the TP and potential TP detection. The choice and number of models used should be evaluated. This method is tedious as it requires inference detection from several models, which can be time-consuming and computationally intensive.","title":"4.1. Model performance and replicability"},{"location":"PROJ-DQRY-TM/#42-sensitivity-to-the-zoom-level","text":"Image resolution is dependent on the zoom level ( Section 2.2 ). To select the most suitable zoom level for MES detection, we performed a sensitivity analysis on trained model performance. Increasing the zoom level increases the value of the metrics following a global linear trend (Fig. 11). Figure 11: Metrics values (precision, recall and f1) as function of zoom level for the validation dataset. The results of the replicates performed at each zoom level are included (Table A1). Models trained at a higher zoom level performed better. However, a higher zoom level implies smaller tile and thus, a larger number of tiles to fill the AoI. For a typical AoI, i.e up to a third of Switzerland, this can lead to a large number of tiles to be stored and processed, leading to potential RAM and/or disk space saturation. For 2019 AoI, 89'290 tiles are required at zoom level 16 while 354'867 tiles are required at zoom level 17, taking respectively 3 hours and 11 hours to process on a 30 GiB RAM machine with a 16 GiB GP. Visual comparison of inference detection reveals that there was no significant improvement in the object detection quality from zoom level 16 to zoom level 17. Both zoom level present a similar proportion of detections intersecting labels (82% and 79% for zoom level 16 and zoom level 17 respectively). On the other hand, the quality of object detection at zoom level 15 was depreciated. Indeed, detection scores were lower, with only tens of detection scores above 0.95 while it was about 400 at zoom level 16 and about 64% of detection intersecting labels.","title":"4.2 Sensitivity to the zoom level"},{"location":"PROJ-DQRY-TM/#43-model-choice","text":"Based on tests performed, we selected the 'replicate 3' model, obtained (Tables 2 and A1) at zoom level 16, to perform inference detection. Models trained at zoom level 16 (1.6 m px -1 pixel resolution) have shown satisfying results in accurately detecting MES contour and limiting the number of FP with high detection score (Fig. 11). It represents a good trade-off between results reliability (f1-score between 76% and 82% on the validation dataset) and computational resources. Then, among all the replicates performed at zoom level 16, we selected the trained model 'replicate 3' (Table 2) because it combines both the highest metrics values (for the validation dataset but also the train and test datasets), close precision and recall values and a rather low amount of low score detections.","title":"4.3 Model choice"},{"location":"PROJ-DQRY-TM/#5-automatic-detection-of-mes","text":"","title":"5. Automatic detection of MES"},{"location":"PROJ-DQRY-TM/#51-detection-post-processing","text":"Detection by inference was performed over AoIs with a threshold detection score of 0.3 (Fig. 12). The low score filtering results in a large amount of detections. Several detections may overlap, potentially segmenting a single object. In addition a detection might be split into multiple tiles. To improve the pertinence and the aesthetics of the raw detection polygons, a post-processing procedure was applied. First, a large proportion of FP occurred in mountainous areas (rock outcrops and snow, Fig. 12(a)). We assumed MES are not present (or at least sparse) above a given altitude. An elevation filtering was applied using a Switzerland Digital Elevation Model (about 25 m px -1 ) derived from the SRTM instrument ( USGS - SRTM ). The maximum elevation of the labeled MES is about 1100 m. Second, detection aggregation was applied: - polygons were clustered ( K-means ) according to their centroid position. The method involves setting a predefined number k of clusters. Manual tests performed by Reichel and Hamel (2021) 7 concluded to set k equal to the number of detection divided by three. The highest detection score was assigned to the clustered detection. This method preserves the final integrity of detection polygons by retaining detection that has potentially a low confidence score but belongs to a cluster with a higher confidence score improving the final segmentation of the detected object. The value of the threshold score must be kept relatively low ( i.e. 0.3) when performing the detection to prevent removing too many polygons that could potentially be part of the detected object. We acknowledge that determining the optimal number of clusters by clustering validation indices rather than manual adjustment would be more robust. In addition, exploring other clustering methods, such as DBSCAN , based on local density, can be considered in the future. - score filtering was applied. - spatially close polygons were assumed to belong to the same MES and are merged according to a distance threshold. The averaged score of the merged detection polygons was ultimately computed. Finally, we assumed that a MES covers a minimal area. Detection with an area smaller than a given threshold were filtered out. The minimum MES area in the GT is 2270 m 2 . Figure 12: MES detection filtering. (a) Overview of the automatic detection of MES obtained with 2020 SWISSIMAGE at zoom level 16. Transparent red polygons (with associated confidence score in white) correspond to the raw object detection output and the red line polygons (with associated confidence score in red) correspond to the final filtered detection. The black box outlines the location of the (b) and (c) panel zoom. Note the large number of detection in the mountains (right area of the image). (b) Zoom on several raw detections polygons of a single object with their respective confidence score. (c) Zoom on a filtered detection polygon of a single object with the resulting score. Sensitivity of detections to these filters was investigated (Table 3). The quantitative evaluation of filter combination relevance is tricky as potential MES presence is performed by inference, and the GT provided by swissTLM3D constitutes an incomplete portion of the MES in Switzerland (2020). As indication, we computed the number of spatial intersection between ground truth and detection obtained with the 2020 SWISSIMAGE mosaic. Filter combination number 3 was adopted, allowing to detect about 82% of the GT with a relatively limited amount of FP detection compared to filter combinations 1 and 2 (from visual inspection). filters combination score threshold elevation threshold (m) area threshold (m 2 ) distance threshold (m) number of detection label detection (%) 1 0.95 2000 1100 10 1745 85.1 2 0.95 2000 1200 10 1862 86.6 3 0.95 5000 1200 10 1347 82.1 4 0.96 2000 1100 10 1331 81.3 5 0.96 2000 1200 8 1445 78.7 6 0.96 5000 1200 10 1004 74.3 Table 3: Threshold values of filtering parameters and their respective number of detections and intersection proportion with swissTLM3D labels. The detections have been obtained for the 2020 SWISSIMAGE mosaic. We acknowledged that for the selected filter combination, the area threshold value is higher than the smallest area value of the GT polygons. However, reducing the area value increases significantly the presence of FP. Thirteen labels display an area below 5000 m 2 .","title":"5.1 Detection post-processing"},{"location":"PROJ-DQRY-TM/#52-inference-detections","text":"The trained model was used to perform inference detection on SWISSIMAGE orthophotos from 1999 to 2021. The automatic detection model shows good capabilities to detect MES in different years orthophotos (Fig. 13), despite being trained on the 2020 SWISSIMAGE mosaic. The model also demonstrates capabilities to detect potential MES that have not been mapped yet but are strong candidates. However, the model misses some labeled MES or potential MES (FN, Fig. 8). However, when the model process FSO images, with different colour stretching, it failed to correctly detect potential MES (Fig. 3). It reveals that images must have characteristics close to the training dataset for optimal results with a deep learning model. Figure 13: Examples of object detection segmented by polygons in different year orthophotos. The yellow polygon for the year 2020 panel of object ID 3761 corresponds to the label. Other coloured polygons correspond to the algorithm detection. Then, we acknowledge that a significant amount of FP detection can still be observed in our filtered detection dataset (Figs. 8 and 14). The main sources of FP are the presence of large rock outcrops, mountainous areas without vegetation, snow, river sand beds, brownish-coloured fields, or construction areas. MES present a large variety of features (buildings, water pounds, trucks, vegetation) (Fig. 5) which can be a source of confusion for the algorithm but even sometimes for human eye. Therefore, the robustness of the GT is crucial for reliable detection. The algorithm's results should be taken carefully. Figure 14: Examples of FP detection. (a) Snow patches (2019) ; (b) River sand beds and gullies (2019); (c) Brownish field (2020); (d) vineyards (2005); (e) Airport tarmac (2020); (f) Construction site (2008). The detections produced by the algorithm are potential MES, but the final results must be reviewed by experts in the field to discard remaining FP detection and correct FN before any processing or interpretation.","title":"5.2 Inference detections"},{"location":"PROJ-DQRY-TM/#6-observation-of-mes-evolution","text":"","title":"6. Observation of MES evolution"},{"location":"PROJ-DQRY-TM/#61-object-tracking-strategy","text":"Switzerland is covered by RGB SWISSIMAGE product over more than 20 years (1999 to actual), allowing changes to be detected (Fig. 13). Figure 15: Strategy for MES tracking over time. ID assignment to detection. Spatially intersecting polygons share the same ID allowing the MES to be tracked in a multi-year dataset. We assumed that detection polygons that overlap from one year to another describe a single object (Fig. 15). Overlapping detections and unique detections (which do not overlap with polygons from other years) in the multi-year dataset were assigned a unique object identifier (ID). A new object ID in the timeline indicates: - the first occurrence of the object detected in the dataset of the first year available for the area. It does not mean that the object was not present before, - the creation of a potential new MES. The disappearance of an object ID indicates its potential refill. Therefore, the chronology of MES, creation, evolution and filling, can be constrained.","title":"6.1 Object tracking strategy"},{"location":"PROJ-DQRY-TM/#62-evolution-of-mes-over-years","text":"Figures 13 and 16 illustrate the ability of the trained model to detect and track a single object in a multi-year dataset. The detection over the years appears reliable and consistent, although object detection may be absent from a year dataset ( e.g. due to shadows or colour changes in the surroundings). Remember that the image coverage of a given area is not renewed every year. Characteristics of the potential MES, such as surface evolution (extension or retreat), can be quantified. For example, the surfaces of object IDs 239 and 3861 have more than doubled in about 20 years. Tracking object ID along with image visualisation allows observation of the opening and the closing of potential MES, as object IDs 31, 44, and 229. Figure 16: Detection area (m 2 ) as a function of years for several object ID. Figure 13 provides the visualisation of the object IDs selected. Each point corresponds to an object ID occurrence in the corresponding year dataset. The presence of an object in several years dataset strengthens the likeliness of the detected object to be an actual MES. On the other hand, object detection of only one occurrence is more likely a FP detection.","title":"6.2 Evolution of MES over years"},{"location":"PROJ-DQRY-TM/#7-conclusion-and-perspectives","text":"The project demonstrated the ability to automatically, quickly (a matter of hours for one AoI), and reliably detect potential MES in orthophotos of Switzerland with an automatic detection algorithm (deep learning). The selected trained model achieved a f1-score of 82% on the validation dataset. The final detection polygons accurately delineate the potential MES. We can track single MES through multiple years, emphasising the robustness of the method to detect objects in multi-year datasets despite the detection model being trained on a single dataset (2020 SWISSIMAGE mosaic). However, image colour stretching different from that used to train the model can significantly affect the model's ability to provide reliable detection, as was the case with the FSO images. Although the performance of the trained model is satisfactory, FP and FN are present in the datasets. They are mainly due to confusion of the algorithm between MES and rock outcrops, river sandbeds or construction sites. A manual verification of the relevance of the detection by experts in the field is necessary before processing and interpreting the data. Revision of all the detections from 1999 to 2021 is a time-consuming effort but is necessary to guarantee detection reliability. Despite the required manual checks, the provided framework and detection results constitute a valuable contribution that can greatly assist the inventory and the observation of MES evolution in Switzerland. It provides state-wide detection in a matter of hours, which is a considerable time-saving compared with manual mapping. It also enables MES detection with a standardised method, independent of the information or method adopted by the cantons. Further model improvements could be consider, such as increasing the metrics by improving GT quality, improving model learning strategy, mitigating the model learning variability, or test supervised clustering methods to find relevant detection. This work can be used to compute statistics to study long-term MES in Switzerland and better management of resources and land use in the future. MES detection can be combined with other data, such as the geologic layer, to identify the mineral/rocks exploited and high-resolution DEM ( swissALTI3D ) to infer elevation changes and observe excavation or filling of MES 5 . So far only RGB SWISSIMAGE orthophotos from 1999 to 2021 were processed. Prior to 1999, black and white orthophotos exist but the model trained on RGB images could not be applied trustfully to black and white images. Image colourisation tests (with the help of deep learning algorithm[@farella_colour_2022]) were performed and provided encouraging detection results. This avenue needs to be explored. Finally, automatic detection of MES is rare 1 3 , and most studies perform manual mapping. Therefore, the framework could be the extended to other datasets and/or other countries to provide a valuable asset to the community. A global mapping of MES has been completed with over 21'000 polygons 1 and can be used as a GT database to train an automatic detection model.","title":"7. Conclusion and perspectives"},{"location":"PROJ-DQRY-TM/#code-availability","text":"The codes are stored and available on the STDL's github repository: proj-dqry : mineral extraction site framework object-detector : object detector framework","title":"Code availability"},{"location":"PROJ-DQRY-TM/#acknowledgements","text":"This project was made possible thanks to a tight collaboration between the STDL team and swisstopo . In particular, the STDL team acknowledges key contribution from Thomas Galfetti ( swisstopo ). This project has been funded by \"Strategie Suisse pour la G\u00e9oinformation\".","title":"Acknowledgements"},{"location":"PROJ-DQRY-TM/#appendix","text":"","title":"Appendix"},{"location":"PROJ-DQRY-TM/#a1-influence-of-empty-tiles-addition-to-model-performance","text":"By selecting tiles intersecting only labels, the detection model is mainly confronted with the presence of the targeted object to be detected. Addition of non-label-intersecting tiles, i.e. empty tiles, provides landscape diversity that might help to improve the object detection performance. In order to evaluate the influence of adding empty tiles to the dataset used for the model performance, empty tiles were chosen randomly (not intersecting labels) within Switzerland boundaries and added to the tile dataset used for the model training (Fig. A1). Empty tiles were added to (1) the whole dataset split as for the initial dataset (training: 70%, test: 15%, and validation: 15%) and (2) only to the training dataset. A visual inspection must be performed to prevent a potential unlabeled MES to be present in the image and disturbing the algorithm learning. Figure A1: View of tiles intersecting (black) labels (yellow) and randomly selected empty tiles (red) in Switzerland. This case correspond to the addition of 35% empty tiles. Figure A1 reveals that adding empty tiles to the dataset does not significantly influence the metrics values. The number of TP, FP, and FN do not show significant variation. However, when performing an inference detection test on a subset of tiles (2000) for an AOI, it appears that the number of raw detections (unfiltered) is reduced as the number of empty tiles increases. However, visual inspection of the final detection after applying filters does not show significant improvement compared to a model trained without adding empty tiles. Figure A1: Influence of the addition of empty tiles (relative to the number of tiles intersecting labels) on trained performance for zoom levels 16 and 17 with (a) the F1-score as a function of the percentage of added empty tiles and (b) the normalised (by the number of tiles sampled = 2000) number of detection as a function of added empty tiles. Empty tiles have been added to only the train dataset for the 5% and 30% cases and to all datasets for 9%, 35%, 70%, and 140% cases. A considered solution to improve the results could be to specifically select tiles for which FP occurred and include them in the training dataset as empty tiles. This way, the model could be trained with relevant confounding features such as snow patches, river sandbeds, or gullies not labeled as GT.","title":"A.1 Influence of empty tiles addition to model performance"},{"location":"PROJ-DQRY-TM/#a2-sensitivity-of-the-model-to-the-number-of-images-per-batch","text":"During the model learning phase, the trained model is updated after each batch of samples was processed. Adding more samples, i.e. in our case images, to the batch can influence the model learning capacity. We investigated the role of adding more images per batch for a dataset with and without adding a portion of empty tiles to the learning dataset. Adding more images per batch speeds up the model learning (Table A1), and the minimum of the loss curve is reached for a smaller number of iterations. Figure A2: Metrics (precision, recall and f1-score) evolution with the number of images per batch during the model training. Results have been obtained on a dataset without empty tiles addition (red) and with the addition of 23% of empty tiles to the training dataset. Figure A2 reveals that the metrics values remain in a range of constant values while adding extra images to the batch in all cases (with or without empty tiles). A potential effect of adding more images to the batch is the reduction of the metrics variability between replicates of trained models as the range of metrics values is smaller for 8 images per batch than 2 images per batch. However, this observation has to be taken carefully as fewer replicates have been performed with 8 images per batch than for 2 or 4 images per batch. Further investigation would provide stronger insights on this effect.","title":"A.2 Sensitivity of the model to the number of images per batch"},{"location":"PROJ-DQRY-TM/#a3-evaluation-of-trained-models","text":"Table A1 sumup metrics value obtained for all the configuration tested for the project. zoom level model empty tiles (%) image per batch optimum iteration precision recall f1 15 replicate 1 0 2 1000 0.727 0.810 0.766 16 replicate 1 0 2 2000 0.842 0.793 0.817 16 replicate 2 0 2 2000 0.767 0.760 0.763 16 replicate 3 0 2 3000 0.831 0.810 0.820 16 replicate 4 0 2 2000 0.886 0.769 0.826 16 replicate 5 0 2 2000 0.780 0.818 0.798 16 replicate 6 0 2 3000 0.781 0.826 0.803 16 replicate 7 0 4 1000 0.748 0.860 0.800 16 replicate 8 0 4 1000 0.779 0.785 0.782 16 replicate 9 0 8 1500 0.800 0.793 0.797 16 replicate 10 0 4 1000 0.796 0.744 0.769 16 replicate 11 0 8 1000 0.802 0.769 0.785 16 ET-250_allDS_1 34.2 2 2000 0.723 0.770 0.746 16 ET-250_allDS_2 34.2 2 3000 0.748 0.803 0.775 16 ET-1000_allDS_1 73.8 2 6000 0.782 0.815 0.798 16 ET-1000_allDS_2 69.8 2 6000 0.786 0.767 0.776 16 ET-1000_allDS_3 70.9 2 6000 0.777 0.810 0.793 16 ET-1000_allDS_4 73.8 2 6000 0.768 0.807 0.787 16 ET-2000_allDS_1 143.2 2 6000 0.761 0.748 0.754 16 ET-80_trnDS_1 5.4 2 2000 0.814 0.793 0.803 16 ET-80_trnDS_2 5.4 2 2000 0.835 0.752 0.791 16 ET-80_trnDS_3 5.4 2 2000 0.764 0.802 0.782 16 ET-400_trnDS_1 29.5 2 6000 0.817 0.777 0.797 16 ET-400_trnDS_2 29.5 2 5000 0.848 0.785 0.815 16 ET-400_trnDS_3 29.5 2 4000 0.758 0.802 0.779 16 ET-400_trnDS_4 29.5 4 2000 0.798 0.818 0.808 16 ET-400_trnDS_5 29.5 4 1000 0.825 0.777 0.800 16 ET-1000_trnDS_1 0 2 4000 0.758 0.802 0.779 17 replicate 1 0 2 5000 0.819 0.853 0.835 17 replicate 1 0 2 5000 0.803 0.891 0.845 17 replicate 1 0 2 5000 0.872 0.813 0.841 17 ET-250_allDS_1 16.8 2 3000 0.801 0.794 0.797 17 ET-1000_allDS_1 72.2 2 7000 0.743 0.765 0.754 18 replicate 1 0 2 10000 0.864 0.855 0.859 Table A1: Metrics value computed for the validation dataset for all the trained models with the 2020 SWISSIMAGE Journey mosaic at zoom level 16. Victor Maus, Stefan Giljum, Jakob Gutschlhofer, Dieison M. Da Silva, Michael Probst, Sidnei L. B. Gass, Sebastian Luckeneder, Mirko Lieber, and Ian McCallum. A global-scale data set of mining areas. Scientific Data , 7(1):289, September 2020. URL: https://www.nature.com/articles/s41597-020-00624-w , doi:10.1038/s41597-020-00624-w . \u21a9 \u21a9 \u21a9 \u21a9 \u21a9 Vicen\u00e7 Carabassa, Pau Montero, Marc Crespo, Joan-Cristian Padr\u00f3, Xavier Pons, Jaume Balagu\u00e9, Llu\u00eds Brotons, and Josep Maria Alca\u00f1iz. Unmanned aerial system protocol for quarry restoration and mineral extraction monitoring. Journal of Environmental Management , 270:110717, September 2020. URL: https://linkinghub.elsevier.com/retrieve/pii/S0301479720306496 , doi:10.1016/j.jenvman.2020.110717 . \u21a9 \u21a9 \u21a9 \u21a9 Chunsheng Wang, Lili Chang, Lingran Zhao, and Ruiqing Niu. Automatic Identification and Dynamic Monitoring of Open-Pit Mines Based on Improved Mask R-CNN and Transfer Learning. Remote Sensing , 12(21):3474, January 2020. URL: https://www.mdpi.com/2072-4292/12/21/3474 , doi:10.3390/rs12213474 . \u21a9 \u21a9 \u21a9 \u21a9 Haoteng Zhao, Yong Ma, Fu Chen, Jianbo Liu, Liyuan Jiang, Wutao Yao, and Jin Yang. Monitoring Quarry Area with Landsat Long Time-Series for Socioeconomic Study. Remote Sensing , 10(4):517, April 2018. URL: https://www.mdpi.com/2072-4292/10/4/517 , doi:10.3390/rs10040517 . \u21a9 \u21a9 Valentin Tertius Bickel and Andrea Manconi. Decadal Surface Changes and Displacements in Switzerland. Journal of Geovisualization and Spatial Analysis , 6(2):24, December 2022. URL: https://link.springer.com/10.1007/s41651-022-00119-9 , doi:10.1007/s41651-022-00119-9 . \u21a9 \u21a9 George P. Petropoulos, Panagiotis Partsinevelos, and Zinovia Mitraka. Change detection of surface mining activity and reclamation based on a machine learning approach of multi-temporal Landsat TM imagery. Geocarto International , 28(4):323\u2013342, July 2013. URL: http://www.tandfonline.com/doi/abs/10.1080/10106049.2012.706648 , doi:10.1080/10106049.2012.706648 . \u21a9 Huriel Reichel and Nils Hamel. Automatic Detection of Quarries and the Lithology below them in Switzerland. 2022. URL: file:///C:/Users/Clemence/Documents/STDL/Projects/proj-quarries/01_Documentation/Bibliography/Automatic%20Detection%20of%20Quarries%20and%20the%20Lithology%20below%20them%20in%20Switzerland%20-%20Swiss%20Territorial%20Data%20Lab.htm . \u21a9 \u21a9 \u21a9 \u21a9 Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2. 2019. URL: https://github.com/facebookresearch/detectron2 . \u21a9 Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross Girshick. Mask R-CNN. January 2018. arXiv:1703.06870 [cs]. URL: http://arxiv.org/abs/1703.06870 , doi:10.48550/arXiv.1703.06870 . \u21a9","title":"A.3 Evaluation of trained models"},{"location":"PROJ-DTRK/","text":"DIFFERENCE MODELS APPLIED ON LAND REGISTER \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - PROJ-DTRK September 2020 to November 2020 - Published on April 23, 2021 Abstract : Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed. Introduction \u00b6 Land register models are probably to most living of the geographical models as they are constantly updated to offer a rigorous and up-to-date view of the territory. The applied corrections are always the result of a complex process, involving different territory actors, until the decision is made to integrate them into the land register. In addition, land register models comes with an additional constraint linked to political decisions. Indeed, the land register models are the result of a political mission conducted under federal laws making these models of high importance and requiring constant care. We show in this research project how differences detection tool [1] of the STDL 4D framework can be used to emphasize and analyze these corrections along the time dimension. In addition to the constant updates of the models, changes in the reference frame can also lead to large-scale corrections of the land register models. These global corrections are then made even more complex by the federal laws that impose a high degree of correctness and accuracy. In the context of the introduction of the new reference frame DM.flex [2] for the Swiss land register, being able to assess the applied changes on the geographical model appear as an important aspect. Indeed, changing the reference frame for the land register models is a long and complex technical process that can be error prompt. We also show in this research project how the difference detection algorithm can be helpful to assess and verify the performed corrections. Research Project Specifications \u00b6 In this research project, the difference detection algorithm implemented in the STDL 4D framework is applied on INTERLIS data containing the official land register models of different Swiss Canton . As introduced, two main directions are considered for the difference detection algorithm : Demonstrating the ability to extract information in between land register models Demonstrating the ability of difference models to be used as an assessment tool Through the first direction, the difference detection algorithm is presented. Considering the difference models it allows computing, it is shown how such model are able to extract information in between the models in order to emphasize the ability to represent, and then, to verify the evolution of the land register models. The second direction focuses on demonstrating that difference models are a helpful representation of the large-scale corrections that can be applied to land register during reference frame modification and how they can be used as a tool to assess the modifications and to help to fulfil the complex task of the verification of the corrected models. Research Project Data \u00b6 For the first research direction, the land register models of the Thurgau Kanton are considered. They are selected in order to have a small temporal distance allowing to focus on a small amount of well-defined differences : Thurgau Kanton , 2020-10-13 , INTERLIS Thurgau Kanton , 2020-10-17 , INTERLIS For the second direction, which focus on more complex differences, the models of the Canton of Geneva land register are considered with a much larger temporal gap between them : Canton of Geneva , 2009-10 , INTERLIS Canton of Geneva , 2013-04 , INTERLIS Canton of Geneva , 2017-04 , INTERLIS Canton of Geneva , 2019-04 , INTERLIS Difference Models : A Temporal Derivative \u00b6 This first section focuses on short-term differences to show how difference models work and how they are able to represent the modifications extracted out of the two compared models. The following images give an illustration of the considered dataset, which are the land register models of Thurgau Kanton : Illustration of Thurgau Kanton INTERLIS models - Data : Kanton Thurgau The models are made of vector lines, well geo-referenced in the Swiss coordinates frame EPSG:2056 . The models are also made of different layers that are colored differently with the following correspondences : INTERLIS selected topics and tables colors - Official French and German designations These legends are used all along this research project. Considering two temporal versions of this geographical model, separated of a few days, one is able to extract difference models using the 4D framework algorithm. As an example, one can consider this very specific view of the land register, focusing on a few houses : Close view of the Thurgau INTERLIS model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It is clear that most of the close view is identical for the two models, except for a couple of houses that were added to the land register model between these two temporal versions. By applying the difference detection algorithm, one is able to obtain a difference model comparing the two previous models. The following image gives an illustration of the obtained difference models considering the most recent temporal version as reference : Difference model obtained comparing the two temporal versions - Data : Kanton Thrugau One can see how the difference algorithm is able to emphasize the differences and to represent them in a human-readable third model. The algorithm also displays the identical parts in dark gray to offer the context of the differences to the operator. Of course, in such close view, differences detection can appear as irrelevant, as one is clearly able to see that something changed on the selected example without any help. But difference models can be computed at any scale. For example, taking the example of the Amriswil city : View of Amriswil model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It becomes more complicated to track down the differences that can appear between the two temporal versions. By computing their difference model , one is able to access a third model that ease the analysis of the evolution at the scale of the city itself as illustrated on the following image : Difference model computed for the city of Amriswil - Data : Kanton Thrugau One can see how difference models can be used to track down modifications brought to the land register in a simple manner, while keeping the information of the unchanged elements between the two compared models. This demonstrates that information that exists between models can be extracted and represented for further users or automated processes. In addition, such difference models can be computed at any scale, considering small area up to the whole countries. Difference Models : An Assessment Tool \u00b6 On the previous section, the difference models are computed using two models only separated of a few days, containing only a small amount of clear and simple modifications. This section focuses on detecting differences on larger models, separated by several years. In this case, the land register of the Canton of Geneva is considered : Illustration of the Geneva land register in 2017-04 (left) and 2019-04 (right) - Data : Canton of Geneva One can see that at such a scale, taking into account that the Canton of Geneva is one of the smallest in Switzerland, having a vision and a clear understanding of the modifications made between these two models is difficult by considering the two models separately. It's precisely where differences models can be useful to understand and analyze the evolution of the land register, along both the space and time dimensions. Large-Scale Analysis \u00b6 A first large-scale evaluation can be made on the overall models. A difference model can be computed considering the land register of Geneva in 2019 and 2017 as illustrated on the following image : Difference model on Geneva land register between 2019-04 and 2017-04 - Data : Canton of Geneva Two observations can be already made by looking at the difference model . In the first place, one can see that the amount of modifications brought to the land register is large in only two years. A large portion of the land register were subject to modifications or corrections, the unchanged parts being mostly limited outside the populated area. In the second place, one can observe large portions where differences seem to be accumulating over this period of time. Looking at them more closely leads to the conclusion that these zones were actually completely modified, as all elements are highlighted by the difference detection algorithm. The following image gives a closer view of such an area of differences accumulation : Focus on Carouge area of the 2019-04 and 2017-04 difference model - Data : Canton of Geneva Despite the amount of modifications outside this specific zone is also high, it is clear that the pointed zone contains more of them. Looking at it more closely leads to the conclusion that everything changed. In order to understand these areas of differences accumulation, the the land register experts of the Canton of Geneva ( SITG ) were questioned. They provided an explanation for these specific areas. Between 2017 and 2019 , these areas were subjected to a global correction in order to release the tension between the old reference frame LV03 [3] and the current one LV95 [4]. These corrections were made using the FINELTRA algorithm to modify the elements of the land register of the order of a few centimeters. The land register of Geneva provided the following illustration summarizing these reference frame corrections made between 2017 and 2019 on the Geneva territory : Reference frame corrections performed between 2017 and 2019 - Data : SITG Comparing this map from the land register with the computed model allows seeing how differences detection can emphasize this type of corrections efficiently, as the corrected zones on this previous image corresponds to the difference accumulation areas on the computed difference model . Small-Scale Analysis \u00b6 One can also dive deep into the details of the difference models . As we saw on the large scale analysis, two types of areas can be seen on the 2019-04-2017-04 difference model of Geneva : regular evolution with an accumulation of corrections and areas on which global corrections were applied. The following images propose a close view of these two types of situation : Illustration of the two observed type of evolutions of the land register - Data : Canton of Geneva On the left image above, one can observe the regular evolution of the land register where modifications are brought to the model in order to follow the evolution of the territory. On the right image above, one can see a close view of an area subjected to a global correction (reference frame), leading to a difference model highlighting all the elements. Analyzing more closely the right image above lead the observer to conclude that not all the elements are actually highlighted by the difference detection algorithm. Indeed, some elements are rendered in gray on the difference model , indicating their lack of modification between the two compared times. The following image emphasizes the unchanged elements that can be observed : Unchanged elements in the land register after reference frame correction - Data : SITG These unchanged elements can be surprising as they're found in an area that was subject to a global reference frame correction. This shows how difference models can be helpful to track down these type of events in order to check whether these unchanged elements are expected or are the results of a discrepancy in the land register evolution. Other example can be found in this very same area of the Geneva city. The following images give an illustration of two other close view where the unchanged element can be seen despite the reference frame correction : Unchanged elements in the land register after reference frame correction - Data : SITG On the left image above, one can observe that the unchanged elements are the railway tracks within the commune of Carouge . This is an interesting observation, as railway tracks can be considered as specific elements that can be subjected to different legislations regarding the land register. But it is clear that railway tracks were not considered in the reference frame correction. On the right image above, one can see another example of unchanged elements that are more complicated to explain, as they're in the middle of modified other elements. This clearly demonstrate how difference models can be helpful for analyzing and assessing the evolution of the land register models. Such models are able to drive users or automated processes and lead them to focus on relevant aspects and to define the good question in the context of analyzing the evolution of the land register. Conclusion \u00b6 The presented difference models computed based on two temporal versions of the land register and using the 4D framework algorithm showed how differences can be emphasized for users and automated processes [1]. Difference models can be helpful to determine the amount and nature of changes that appear in the land register. Applying such an algorithm on land register is especially relevant as it is a highly living model, that evolves jointly with the territory it describes. Two main applications can be considered using difference models applied on the land register. In the first place, the difference models can be used to assess and analyze the regular evolution of the territory. Indeed, updating the land register is not a simple task. Such modifications involve a whole chain of decisions and verifications, from surveyors to the highest land register authority before to be integrated in the model. Being able to assess and analyze the modifications in the land register through difference models could be one interesting strengthening of the overall process. The second application of difference models could be as an assessment tool of global corrections applied to the land register or parts of it. These modifications are often linked to the reference frame and its evolution. Being able to assess the corrections through the difference models could add a helpful tool in order to verify that the elements of the land register where correctly processed. In this direction, difference models could be used during the introduction of the DM.flex reference frame for both analyzing its introduction and demonstrating that difference models can be an interesting point of view. Reproduction Resources \u00b6 To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Unfortunately, the used data are not currently public. In both cases, the land register INTERLIS datasets were provided to the STDL directly. You can contact both Thurgau Kanton and SITG : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) to query the data. In order to extract and convert the data from the INTERLIS models, the following code is used : INTERLIS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results. References \u00b6 [1] Automatic Detection of Changes in the Environment, N. Hamel, STDL 2020 [2] DM.flex reference frame [3] LV03 Reference frame [4] LV95 Reference frame","title":"DIFFERENCE MODELS APPLIED ON LAND REGISTER"},{"location":"PROJ-DTRK/#difference-models-applied-on-land-register","text":"Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Project scheduled in the STDL research roadmap - PROJ-DTRK September 2020 to November 2020 - Published on April 23, 2021 Abstract : Being able to track modifications in the evolution of geographical datasets is one important aspect in territory management, as a large amount of information can be extracted out of differences models. Differences detection can also be a tool used to assess the evolution of a geographical model through time. In this research project, we apply differences detection on INTERLIS models of the official Swiss land registers in order to emphasize and follow its evolution and to demonstrate that change in reference frames can be detected and assessed.","title":"DIFFERENCE MODELS APPLIED ON LAND REGISTER"},{"location":"PROJ-DTRK/#introduction","text":"Land register models are probably to most living of the geographical models as they are constantly updated to offer a rigorous and up-to-date view of the territory. The applied corrections are always the result of a complex process, involving different territory actors, until the decision is made to integrate them into the land register. In addition, land register models comes with an additional constraint linked to political decisions. Indeed, the land register models are the result of a political mission conducted under federal laws making these models of high importance and requiring constant care. We show in this research project how differences detection tool [1] of the STDL 4D framework can be used to emphasize and analyze these corrections along the time dimension. In addition to the constant updates of the models, changes in the reference frame can also lead to large-scale corrections of the land register models. These global corrections are then made even more complex by the federal laws that impose a high degree of correctness and accuracy. In the context of the introduction of the new reference frame DM.flex [2] for the Swiss land register, being able to assess the applied changes on the geographical model appear as an important aspect. Indeed, changing the reference frame for the land register models is a long and complex technical process that can be error prompt. We also show in this research project how the difference detection algorithm can be helpful to assess and verify the performed corrections.","title":"Introduction"},{"location":"PROJ-DTRK/#research-project-specifications","text":"In this research project, the difference detection algorithm implemented in the STDL 4D framework is applied on INTERLIS data containing the official land register models of different Swiss Canton . As introduced, two main directions are considered for the difference detection algorithm : Demonstrating the ability to extract information in between land register models Demonstrating the ability of difference models to be used as an assessment tool Through the first direction, the difference detection algorithm is presented. Considering the difference models it allows computing, it is shown how such model are able to extract information in between the models in order to emphasize the ability to represent, and then, to verify the evolution of the land register models. The second direction focuses on demonstrating that difference models are a helpful representation of the large-scale corrections that can be applied to land register during reference frame modification and how they can be used as a tool to assess the modifications and to help to fulfil the complex task of the verification of the corrected models.","title":"Research Project Specifications"},{"location":"PROJ-DTRK/#research-project-data","text":"For the first research direction, the land register models of the Thurgau Kanton are considered. They are selected in order to have a small temporal distance allowing to focus on a small amount of well-defined differences : Thurgau Kanton , 2020-10-13 , INTERLIS Thurgau Kanton , 2020-10-17 , INTERLIS For the second direction, which focus on more complex differences, the models of the Canton of Geneva land register are considered with a much larger temporal gap between them : Canton of Geneva , 2009-10 , INTERLIS Canton of Geneva , 2013-04 , INTERLIS Canton of Geneva , 2017-04 , INTERLIS Canton of Geneva , 2019-04 , INTERLIS","title":"Research Project Data"},{"location":"PROJ-DTRK/#difference-models-a-temporal-derivative","text":"This first section focuses on short-term differences to show how difference models work and how they are able to represent the modifications extracted out of the two compared models. The following images give an illustration of the considered dataset, which are the land register models of Thurgau Kanton : Illustration of Thurgau Kanton INTERLIS models - Data : Kanton Thurgau The models are made of vector lines, well geo-referenced in the Swiss coordinates frame EPSG:2056 . The models are also made of different layers that are colored differently with the following correspondences : INTERLIS selected topics and tables colors - Official French and German designations These legends are used all along this research project. Considering two temporal versions of this geographical model, separated of a few days, one is able to extract difference models using the 4D framework algorithm. As an example, one can consider this very specific view of the land register, focusing on a few houses : Close view of the Thurgau INTERLIS model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It is clear that most of the close view is identical for the two models, except for a couple of houses that were added to the land register model between these two temporal versions. By applying the difference detection algorithm, one is able to obtain a difference model comparing the two previous models. The following image gives an illustration of the obtained difference models considering the most recent temporal version as reference : Difference model obtained comparing the two temporal versions - Data : Kanton Thrugau One can see how the difference algorithm is able to emphasize the differences and to represent them in a human-readable third model. The algorithm also displays the identical parts in dark gray to offer the context of the differences to the operator. Of course, in such close view, differences detection can appear as irrelevant, as one is clearly able to see that something changed on the selected example without any help. But difference models can be computed at any scale. For example, taking the example of the Amriswil city : View of Amriswil model in 2020-10-13 (left) and 2020-10-17 (right) - Data : Kanton Thurgau It becomes more complicated to track down the differences that can appear between the two temporal versions. By computing their difference model , one is able to access a third model that ease the analysis of the evolution at the scale of the city itself as illustrated on the following image : Difference model computed for the city of Amriswil - Data : Kanton Thrugau One can see how difference models can be used to track down modifications brought to the land register in a simple manner, while keeping the information of the unchanged elements between the two compared models. This demonstrates that information that exists between models can be extracted and represented for further users or automated processes. In addition, such difference models can be computed at any scale, considering small area up to the whole countries.","title":"Difference Models : A Temporal Derivative"},{"location":"PROJ-DTRK/#difference-models-an-assessment-tool","text":"On the previous section, the difference models are computed using two models only separated of a few days, containing only a small amount of clear and simple modifications. This section focuses on detecting differences on larger models, separated by several years. In this case, the land register of the Canton of Geneva is considered : Illustration of the Geneva land register in 2017-04 (left) and 2019-04 (right) - Data : Canton of Geneva One can see that at such a scale, taking into account that the Canton of Geneva is one of the smallest in Switzerland, having a vision and a clear understanding of the modifications made between these two models is difficult by considering the two models separately. It's precisely where differences models can be useful to understand and analyze the evolution of the land register, along both the space and time dimensions.","title":"Difference Models : An Assessment Tool"},{"location":"PROJ-DTRK/#large-scale-analysis","text":"A first large-scale evaluation can be made on the overall models. A difference model can be computed considering the land register of Geneva in 2019 and 2017 as illustrated on the following image : Difference model on Geneva land register between 2019-04 and 2017-04 - Data : Canton of Geneva Two observations can be already made by looking at the difference model . In the first place, one can see that the amount of modifications brought to the land register is large in only two years. A large portion of the land register were subject to modifications or corrections, the unchanged parts being mostly limited outside the populated area. In the second place, one can observe large portions where differences seem to be accumulating over this period of time. Looking at them more closely leads to the conclusion that these zones were actually completely modified, as all elements are highlighted by the difference detection algorithm. The following image gives a closer view of such an area of differences accumulation : Focus on Carouge area of the 2019-04 and 2017-04 difference model - Data : Canton of Geneva Despite the amount of modifications outside this specific zone is also high, it is clear that the pointed zone contains more of them. Looking at it more closely leads to the conclusion that everything changed. In order to understand these areas of differences accumulation, the the land register experts of the Canton of Geneva ( SITG ) were questioned. They provided an explanation for these specific areas. Between 2017 and 2019 , these areas were subjected to a global correction in order to release the tension between the old reference frame LV03 [3] and the current one LV95 [4]. These corrections were made using the FINELTRA algorithm to modify the elements of the land register of the order of a few centimeters. The land register of Geneva provided the following illustration summarizing these reference frame corrections made between 2017 and 2019 on the Geneva territory : Reference frame corrections performed between 2017 and 2019 - Data : SITG Comparing this map from the land register with the computed model allows seeing how differences detection can emphasize this type of corrections efficiently, as the corrected zones on this previous image corresponds to the difference accumulation areas on the computed difference model .","title":"Large-Scale Analysis"},{"location":"PROJ-DTRK/#small-scale-analysis","text":"One can also dive deep into the details of the difference models . As we saw on the large scale analysis, two types of areas can be seen on the 2019-04-2017-04 difference model of Geneva : regular evolution with an accumulation of corrections and areas on which global corrections were applied. The following images propose a close view of these two types of situation : Illustration of the two observed type of evolutions of the land register - Data : Canton of Geneva On the left image above, one can observe the regular evolution of the land register where modifications are brought to the model in order to follow the evolution of the territory. On the right image above, one can see a close view of an area subjected to a global correction (reference frame), leading to a difference model highlighting all the elements. Analyzing more closely the right image above lead the observer to conclude that not all the elements are actually highlighted by the difference detection algorithm. Indeed, some elements are rendered in gray on the difference model , indicating their lack of modification between the two compared times. The following image emphasizes the unchanged elements that can be observed : Unchanged elements in the land register after reference frame correction - Data : SITG These unchanged elements can be surprising as they're found in an area that was subject to a global reference frame correction. This shows how difference models can be helpful to track down these type of events in order to check whether these unchanged elements are expected or are the results of a discrepancy in the land register evolution. Other example can be found in this very same area of the Geneva city. The following images give an illustration of two other close view where the unchanged element can be seen despite the reference frame correction : Unchanged elements in the land register after reference frame correction - Data : SITG On the left image above, one can observe that the unchanged elements are the railway tracks within the commune of Carouge . This is an interesting observation, as railway tracks can be considered as specific elements that can be subjected to different legislations regarding the land register. But it is clear that railway tracks were not considered in the reference frame correction. On the right image above, one can see another example of unchanged elements that are more complicated to explain, as they're in the middle of modified other elements. This clearly demonstrate how difference models can be helpful for analyzing and assessing the evolution of the land register models. Such models are able to drive users or automated processes and lead them to focus on relevant aspects and to define the good question in the context of analyzing the evolution of the land register.","title":"Small-Scale Analysis"},{"location":"PROJ-DTRK/#conclusion","text":"The presented difference models computed based on two temporal versions of the land register and using the 4D framework algorithm showed how differences can be emphasized for users and automated processes [1]. Difference models can be helpful to determine the amount and nature of changes that appear in the land register. Applying such an algorithm on land register is especially relevant as it is a highly living model, that evolves jointly with the territory it describes. Two main applications can be considered using difference models applied on the land register. In the first place, the difference models can be used to assess and analyze the regular evolution of the territory. Indeed, updating the land register is not a simple task. Such modifications involve a whole chain of decisions and verifications, from surveyors to the highest land register authority before to be integrated in the model. Being able to assess and analyze the modifications in the land register through difference models could be one interesting strengthening of the overall process. The second application of difference models could be as an assessment tool of global corrections applied to the land register or parts of it. These modifications are often linked to the reference frame and its evolution. Being able to assess the corrections through the difference models could add a helpful tool in order to verify that the elements of the land register where correctly processed. In this direction, difference models could be used during the introduction of the DM.flex reference frame for both analyzing its introduction and demonstrating that difference models can be an interesting point of view.","title":"Conclusion"},{"location":"PROJ-DTRK/#reproduction-resources","text":"To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Unfortunately, the used data are not currently public. In both cases, the land register INTERLIS datasets were provided to the STDL directly. You can contact both Thurgau Kanton and SITG : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) to query the data. In order to extract and convert the data from the INTERLIS models, the following code is used : INTERLIS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results.","title":"Reproduction Resources"},{"location":"PROJ-DTRK/#references","text":"[1] Automatic Detection of Changes in the Environment, N. Hamel, STDL 2020 [2] DM.flex reference frame [3] LV03 Reference frame [4] LV95 Reference frame","title":"References"},{"location":"PROJ-GEPOOL/","text":"Swimming Pool Detection from Aerial Images over the Canton of Geneva \u00b6 Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL September 2020 to January 2021 - Published on May 18, 2021 Abstract : Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date. Introduction \u00b6 The Canton of Geneva manages a register of swimming pools, counting - in principle - all and only those swimming pools that are in-ground or, at least, permanently fixed to the ground. The swimming pool register is part of a far more general cadastre, including several other classes of objects (cf. this page ). Typically the swimming pool register is updated either by taking building/demolition permits into account, or by manually checking its multiple records (4000+ to date) against aerial images, which is quite a long and tedious task. Exploring the opportunity of leveraging Machine Learning to help domain experts in such an otherwise tedious tasks was one of the main motivations behind this study. As such, no prior requirements/expectations were set by the recipients. The study was autonomously conducted by the STDL team, using Open Source software and Open Data published by the Canton of Geneva. Domain experts were asked for feedback only at a later stage. In the following, details are provided regarding the various steps we followed. We refer the reader to this page for a thorough description of the generic STDL Object Detection Framework. Method \u00b6 Several steps are required to set the stage for object detection and eventually reach the goal of obtaining - ideally - even more than decent results. Despite the linear presentation that the reader will find here-below, multiple back-and-forths are actually required, especially through steps 2-4. 1. Data preparation \u00b6 As a very first step , one has to define the geographical region over which the study has to be conducted, the so-called \" Area of Interest \" (AoI). In the case of this specific application, the AoI was chosen and obtained as the geometric subtraction between the following two polygons: the unary union of all the polygons of the Canton of Geneva's cadastral parcels dataset, published as Open Data by the SITG , cf. PARCELLES DE LA MENSURATION ; the polygon corresponding to the Lake Geneva (\" lac L\u00e9man \" in French), included in the EMPRISE DU LAC LEMAN (Complet) open dataset, published by the SITG as well. The so-defined AoI covers both the known \"ground-truth\" labels and regions over which hypothetical unknown objects are expected to be detected. The second step consists in downloading aerial images from a remote server, following an established tiling strategy. We adopted the so-called \" Slippy Map \" tiling scheme. Aerial images were fetched from a raster web service hosted by the SITG and powered by ESRI ArcGIS Server. More precisely, the following dataset was used: ORTHOPHOTOS AGGLO 2018 . According to our configuration, this second step produces a folder including one GeoTIFF image per tile, each image having a size of 256x256 pixels. In terms of resolution - or better, in terms of \" Ground Sampling Distance \" (GSD) - the combination of 256x256 pixels images and zoom level 18 Slippy Map Tiles yields approximately a GSD of ~ 60 cm/pixel. The tests we performed at twice the resolution showed little gain in terms of predictive power, surely not enough to support the interest in engaging 4x more resources (storage, CPU/GPU, ...). The third step amounts to splitting the tiles covering the AoI (let's label them \"AoI tiles\") twice: first, tiles are partitioned into two subsets, according to whether they include ( GT tiles) or not ( oth tiles) ground-truth labels: \\(\\mbox{AoI tiles} = (\\mbox{GT tiles}) \\cup (\\mbox{oth tiles}),\\; \\mbox{with}\\; (\\mbox{GT tiles}) \\cap (\\mbox{oth tiles}) = \\emptyset\\) Then, ground-truth tiles are partitioned into three other subsets, namely the training ( trn ), validation ( val ) and test ( tst ) datasets: \\(\\mbox{GT tiles} = (\\mbox{trn tiles}) \\cup (\\mbox{val tiles}) \\cup (\\mbox{tst tiles})\\) with \\(A \\neq B \\Rightarrow A \\cap B = \\emptyset, \\quad \\forall A, B \\in \\{\\mbox{trn tiles}, \\mbox{val tiles}, \\mbox{tst tiles}, \\mbox{oth tiles}\\}\\) We opted for the 70%-15%-15% dataset splitting strategy. Slippy Map Tiles at zoom level 18 covering the Area of Interest, partitioned into several subsets: ground-truth (GT = trn + val + tst), other (oth). Zoom over a portion of the previous image. Concerning ground-truth labels, the final results of this study rely on a curated subset of the public dataset including polygons corresponding to the Canton of Geneva's registered swimming pools, cf. PISCINES . Indeed, some \"warming-up\" iterations of this whole process allowed us to semi-automatically identify tiles where the swimming pool register was inconsistent with aerial images, and viceversa. By manually inspecting the tiles displaying inconsistency, we discarded those tiles for which the swimming pool register seemed to be wrong (at least through the eyes of a Data Scientist; in a further iteration, this data curation step should be performed together with domain experts). While not having the ambition to return a \"100% ground-truth\" training dataset, this data curation step yielded a substantial gain in terms of \\(F_1\\) score (from ~82% to ~90%, to be more precise). 2. Model training \u00b6 A predictive model was trained, stemming from one of the pre-trained models provided by Detectron2 . In particular, the \"R50-FPN\" baseline was used (cf. this page ), which implements a Mask R-CNN architecture leveraging a ResNet-50 backbone along with a Feature Pyramid Network (FPN). We refer the reader e.g. to this blog article for further information about this kind of Deep Learning methods. Training a (Deep) Neural Network model means running an algorithm which iteratively adjusts the various parameters of a Neural Network (40+ million parameters in our case), in order to minimize the value of some \"loss function\". In addition to the model parameters (otherwise called \"weights\", too), multiple \"hyper-parameters\" exist, affecting the model and the way how the optimization is performed. In theory, one should automatize the hyper-parameters tuning , in order to eventually single out the best setting among all the possible ones. In practice, the hyper-parameters space is never fully explored; a minima , a systematic search should be performed, in order to find a \"sweet spot\" among a finite, discrete collection of settings. In our case, no systematic hyper-parameters tuning was actually performed. Instead, a few man hours were spent in order to manually tune the hyper-parameters, until a setting was found which the STDL team judged to be reasonably good (~90% \\(F_1\\) score on the test dataset, see details here-below). The optimal number of iterations was chosen so as to approximately minimize the loss on the validation dataset. 3. Prediction \u00b6 Each image resulting from the tiling of the AoI constitutes - let's say - the \"basic unit of computation\" of this analysis. Thus, the model optimized at the previous step was used to make predictions over: the oth images, meaning images covering no already known swimming pools; the trn , val and tst images, meaning images covering already known swimming pools. The combination of predictions 1 and 2 covers the entire AoI and allows us to discover potential new objects as well as to check whether some of the known objects are outdated, respectively. Image by image, the model produces one segmentation mask per detected object, accompanied by a score ranging from a custom minimum value (5% in our setting) to 100%. The higher the score, the most the model is confident about a given prediction. Sample detections of swimming pools, accompanied by scores. Note that multiple detections can concern the same object, if the latter extends over multiple tiles. Let us note that not only swimming pools exhibiting only \"obvious\" features (bluish color, rectangular shape, ...) were detected, but also: swimming pools covered by some tarp; empty swimming pools; etc. As a matter of fact, the training dataset was rich enough to also include samples of such somewhat tricky cases. 4. Prediction assessment \u00b6 As described here in more detail, in order to assess the reliability of the predictive model predictions have to be post-processed so as to switch from the image coordinates - ranging from (0, 0) to (255, 255) in our case, where 256x256 pixel images were used - to geographical coordinates. This amounts to applying an affine transformation to the various predictions, yielding a vector layer which we can compare with ground-truth ( GT ) data by means of spatial joins: objects which are detected and can also be found in GT data are referred to as \"true positives\" (TPs); objects which are detected but cannot be found in GT data are referred to as \"false positives\" (FPs); GT objects which are not detected are referred to as \"false negatives\" (FNs). Example of a true positive (TP), a false positive (FP) and a false negative (FN). Note that both the TP and the FP object are detected twice, as they extend over multiple tiles. The counting of TPs, FPs, FNs allow us to compute some standard metrics such as precision, recall and \\(F_1\\) score (cf. this Wikipedia page for further information). Actually, one count (hence one set of metrics) can be produced per choice of the minimum score that one is willing to accept. Choosing a threshold value (= thr ) means keeping all the predictions having a score >= thr and discarding the rest. Intuitively, a low threshold should yield a few false negatives; a high threshold should yield a few false positives. Such intuitions can be confirmed by the following diagram, which we obtained by sampling the values of thr by steps of 0.05 (= 5%), from 0.05 to 0.95. True positives (TPs), false negatives (FNs), and false positives (FPs) counted over the test dataset, as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. Performance metrics computed over the test dataset as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. The latter figure was obtained by evaluating the predictions of our best model over the test dataset. Inferior models exhibited a similar behavior, with a downward offset in terms of \\(F_1\\) score. In practice, upon iterating over multiple realizations (with different hyper-parameters, training data and so on) we aimed at maximizing the value of the \\(F_1\\) score on the validation dataset, and stopped when the \\(F_1\\) score went over the value of 90%. As the ground-truth data we used turned out not to be 100% accurate, the responsibility for mismatching predictions has to be shared between ground-truth data and the predictive model, at least in some cases. In a more ideal setting, ground-truth data would be 100% accurate and differences between a given metric (precision, recall, \\(F_1\\) score) and 100% should be imputed to the model. Domain experts feedback \u00b6 All the predictions having a score \\(\\geq\\) 5% obtained by our best model were exported to Shapefile and shared with the experts in charge of the cadastre of the Canton of Geneva, who carried out a thorough evaluation. By checking predictions against the swimming pool register as well as aerial images, it was empirically found that the threshold on the minimum score (= thr ) should be set as high as 97%, in order not to have too many false positives to deal with. In spite of such a high threshold, 562 potentially new objects were detected (over 4652 objects which were known when this study started), of which: 128 items are objects other than swimming pools (let's say an \"actual false positives\"); 211 items are swimming pools that are NOT subject to registration (temporary, above-ground, on top of a building, ...); 223 items are swimming pools that are subject to registration. This figures show that: on the one hand, the model performs quite well on the task it was trained for, in particular when an appropriate threshold is used; on the other hand, the meticulous review of results by domain experts remain essential. This said, automatic detections can surely be used to drive the domain experts' attention towards the areas which might require some. Examples of \"actual false positives\": a fountain (left) and a tunnel (right). Examples of detected swimming pools which are not subject to registration: placed on top of a building (left), inflatable hence temporary (right). Conclusion \u00b6 The analysis reported in this document confirms the opportunity of using state-of-the-art Deep Learning approaches to assist experts in some of their tasks, in this case that of keeping the cadastre up to date. Not only the opportunity was explored and actually confirmed, but valuable results were also produced, leading to the detection of previously unknown objects. At the same time, our study also shows how essential domain expertise still remains, despite the usage of such advanced methods. As a concluding remark, let us note that our predictive model may be further improved. In particular, it may be rendered less prone to false positives, for instance by: leveraging 3D data ( e.g. point clouds), in order to potentially remove temporary, above-ground swimming pools from the set of detected objects; injecting into the training dataset those predictions which were classified by domain experts as other objects or temporary swimming pools; leveraging some other datasets, already available through the SITG portal : buildings , miscellaneous objects , etc.","title":"<span style=\"text-transform:uppercase;\"> Swimming Pool Detection from Aerial Images over the Canton of Geneva </span>"},{"location":"PROJ-GEPOOL/#swimming-pool-detection-from-aerial-images-over-the-canton-of-geneva","text":"Alessandro Cerioni (Canton of Geneva) - Adrian Meyer (FHNW) Proposed by the Canton of Geneva - PROJ-GEPOOL September 2020 to January 2021 - Published on May 18, 2021 Abstract : Object detection is one of the computer vision tasks which can benefit from Deep Learning methods. The STDL team managed to leverage state-of-art methods and already existing open datasets to first build a swimming pool detector, then to use it to potentially detect unregistered swimming pools over the Canton of Geneva. Despite the success of our approach, we will argue that domain expertise still remains key to post-process detections in order to tell objects which are subject to registration from those which aren't. Pairing semi-automatic Deep Learning methods with domain expertise turns out to pave the way to novel workflows allowing administrations to keep cadastral information up to date.","title":" Swimming Pool Detection from Aerial Images over the Canton of Geneva "},{"location":"PROJ-GEPOOL/#introduction","text":"The Canton of Geneva manages a register of swimming pools, counting - in principle - all and only those swimming pools that are in-ground or, at least, permanently fixed to the ground. The swimming pool register is part of a far more general cadastre, including several other classes of objects (cf. this page ). Typically the swimming pool register is updated either by taking building/demolition permits into account, or by manually checking its multiple records (4000+ to date) against aerial images, which is quite a long and tedious task. Exploring the opportunity of leveraging Machine Learning to help domain experts in such an otherwise tedious tasks was one of the main motivations behind this study. As such, no prior requirements/expectations were set by the recipients. The study was autonomously conducted by the STDL team, using Open Source software and Open Data published by the Canton of Geneva. Domain experts were asked for feedback only at a later stage. In the following, details are provided regarding the various steps we followed. We refer the reader to this page for a thorough description of the generic STDL Object Detection Framework.","title":"Introduction"},{"location":"PROJ-GEPOOL/#method","text":"Several steps are required to set the stage for object detection and eventually reach the goal of obtaining - ideally - even more than decent results. Despite the linear presentation that the reader will find here-below, multiple back-and-forths are actually required, especially through steps 2-4.","title":"Method"},{"location":"PROJ-GEPOOL/#1-data-preparation","text":"As a very first step , one has to define the geographical region over which the study has to be conducted, the so-called \" Area of Interest \" (AoI). In the case of this specific application, the AoI was chosen and obtained as the geometric subtraction between the following two polygons: the unary union of all the polygons of the Canton of Geneva's cadastral parcels dataset, published as Open Data by the SITG , cf. PARCELLES DE LA MENSURATION ; the polygon corresponding to the Lake Geneva (\" lac L\u00e9man \" in French), included in the EMPRISE DU LAC LEMAN (Complet) open dataset, published by the SITG as well. The so-defined AoI covers both the known \"ground-truth\" labels and regions over which hypothetical unknown objects are expected to be detected. The second step consists in downloading aerial images from a remote server, following an established tiling strategy. We adopted the so-called \" Slippy Map \" tiling scheme. Aerial images were fetched from a raster web service hosted by the SITG and powered by ESRI ArcGIS Server. More precisely, the following dataset was used: ORTHOPHOTOS AGGLO 2018 . According to our configuration, this second step produces a folder including one GeoTIFF image per tile, each image having a size of 256x256 pixels. In terms of resolution - or better, in terms of \" Ground Sampling Distance \" (GSD) - the combination of 256x256 pixels images and zoom level 18 Slippy Map Tiles yields approximately a GSD of ~ 60 cm/pixel. The tests we performed at twice the resolution showed little gain in terms of predictive power, surely not enough to support the interest in engaging 4x more resources (storage, CPU/GPU, ...). The third step amounts to splitting the tiles covering the AoI (let's label them \"AoI tiles\") twice: first, tiles are partitioned into two subsets, according to whether they include ( GT tiles) or not ( oth tiles) ground-truth labels: \\(\\mbox{AoI tiles} = (\\mbox{GT tiles}) \\cup (\\mbox{oth tiles}),\\; \\mbox{with}\\; (\\mbox{GT tiles}) \\cap (\\mbox{oth tiles}) = \\emptyset\\) Then, ground-truth tiles are partitioned into three other subsets, namely the training ( trn ), validation ( val ) and test ( tst ) datasets: \\(\\mbox{GT tiles} = (\\mbox{trn tiles}) \\cup (\\mbox{val tiles}) \\cup (\\mbox{tst tiles})\\) with \\(A \\neq B \\Rightarrow A \\cap B = \\emptyset, \\quad \\forall A, B \\in \\{\\mbox{trn tiles}, \\mbox{val tiles}, \\mbox{tst tiles}, \\mbox{oth tiles}\\}\\) We opted for the 70%-15%-15% dataset splitting strategy. Slippy Map Tiles at zoom level 18 covering the Area of Interest, partitioned into several subsets: ground-truth (GT = trn + val + tst), other (oth). Zoom over a portion of the previous image. Concerning ground-truth labels, the final results of this study rely on a curated subset of the public dataset including polygons corresponding to the Canton of Geneva's registered swimming pools, cf. PISCINES . Indeed, some \"warming-up\" iterations of this whole process allowed us to semi-automatically identify tiles where the swimming pool register was inconsistent with aerial images, and viceversa. By manually inspecting the tiles displaying inconsistency, we discarded those tiles for which the swimming pool register seemed to be wrong (at least through the eyes of a Data Scientist; in a further iteration, this data curation step should be performed together with domain experts). While not having the ambition to return a \"100% ground-truth\" training dataset, this data curation step yielded a substantial gain in terms of \\(F_1\\) score (from ~82% to ~90%, to be more precise).","title":"1. Data preparation"},{"location":"PROJ-GEPOOL/#2-model-training","text":"A predictive model was trained, stemming from one of the pre-trained models provided by Detectron2 . In particular, the \"R50-FPN\" baseline was used (cf. this page ), which implements a Mask R-CNN architecture leveraging a ResNet-50 backbone along with a Feature Pyramid Network (FPN). We refer the reader e.g. to this blog article for further information about this kind of Deep Learning methods. Training a (Deep) Neural Network model means running an algorithm which iteratively adjusts the various parameters of a Neural Network (40+ million parameters in our case), in order to minimize the value of some \"loss function\". In addition to the model parameters (otherwise called \"weights\", too), multiple \"hyper-parameters\" exist, affecting the model and the way how the optimization is performed. In theory, one should automatize the hyper-parameters tuning , in order to eventually single out the best setting among all the possible ones. In practice, the hyper-parameters space is never fully explored; a minima , a systematic search should be performed, in order to find a \"sweet spot\" among a finite, discrete collection of settings. In our case, no systematic hyper-parameters tuning was actually performed. Instead, a few man hours were spent in order to manually tune the hyper-parameters, until a setting was found which the STDL team judged to be reasonably good (~90% \\(F_1\\) score on the test dataset, see details here-below). The optimal number of iterations was chosen so as to approximately minimize the loss on the validation dataset.","title":"2. Model training"},{"location":"PROJ-GEPOOL/#3-prediction","text":"Each image resulting from the tiling of the AoI constitutes - let's say - the \"basic unit of computation\" of this analysis. Thus, the model optimized at the previous step was used to make predictions over: the oth images, meaning images covering no already known swimming pools; the trn , val and tst images, meaning images covering already known swimming pools. The combination of predictions 1 and 2 covers the entire AoI and allows us to discover potential new objects as well as to check whether some of the known objects are outdated, respectively. Image by image, the model produces one segmentation mask per detected object, accompanied by a score ranging from a custom minimum value (5% in our setting) to 100%. The higher the score, the most the model is confident about a given prediction. Sample detections of swimming pools, accompanied by scores. Note that multiple detections can concern the same object, if the latter extends over multiple tiles. Let us note that not only swimming pools exhibiting only \"obvious\" features (bluish color, rectangular shape, ...) were detected, but also: swimming pools covered by some tarp; empty swimming pools; etc. As a matter of fact, the training dataset was rich enough to also include samples of such somewhat tricky cases.","title":"3. Prediction"},{"location":"PROJ-GEPOOL/#4-prediction-assessment","text":"As described here in more detail, in order to assess the reliability of the predictive model predictions have to be post-processed so as to switch from the image coordinates - ranging from (0, 0) to (255, 255) in our case, where 256x256 pixel images were used - to geographical coordinates. This amounts to applying an affine transformation to the various predictions, yielding a vector layer which we can compare with ground-truth ( GT ) data by means of spatial joins: objects which are detected and can also be found in GT data are referred to as \"true positives\" (TPs); objects which are detected but cannot be found in GT data are referred to as \"false positives\" (FPs); GT objects which are not detected are referred to as \"false negatives\" (FNs). Example of a true positive (TP), a false positive (FP) and a false negative (FN). Note that both the TP and the FP object are detected twice, as they extend over multiple tiles. The counting of TPs, FPs, FNs allow us to compute some standard metrics such as precision, recall and \\(F_1\\) score (cf. this Wikipedia page for further information). Actually, one count (hence one set of metrics) can be produced per choice of the minimum score that one is willing to accept. Choosing a threshold value (= thr ) means keeping all the predictions having a score >= thr and discarding the rest. Intuitively, a low threshold should yield a few false negatives; a high threshold should yield a few false positives. Such intuitions can be confirmed by the following diagram, which we obtained by sampling the values of thr by steps of 0.05 (= 5%), from 0.05 to 0.95. True positives (TPs), false negatives (FNs), and false positives (FPs) counted over the test dataset, as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. Performance metrics computed over the test dataset as a function of the threshold on the score: for a given threshold, all and only the predictions exhibiting a bigger score are kept. The latter figure was obtained by evaluating the predictions of our best model over the test dataset. Inferior models exhibited a similar behavior, with a downward offset in terms of \\(F_1\\) score. In practice, upon iterating over multiple realizations (with different hyper-parameters, training data and so on) we aimed at maximizing the value of the \\(F_1\\) score on the validation dataset, and stopped when the \\(F_1\\) score went over the value of 90%. As the ground-truth data we used turned out not to be 100% accurate, the responsibility for mismatching predictions has to be shared between ground-truth data and the predictive model, at least in some cases. In a more ideal setting, ground-truth data would be 100% accurate and differences between a given metric (precision, recall, \\(F_1\\) score) and 100% should be imputed to the model.","title":"4. Prediction assessment"},{"location":"PROJ-GEPOOL/#domain-experts-feedback","text":"All the predictions having a score \\(\\geq\\) 5% obtained by our best model were exported to Shapefile and shared with the experts in charge of the cadastre of the Canton of Geneva, who carried out a thorough evaluation. By checking predictions against the swimming pool register as well as aerial images, it was empirically found that the threshold on the minimum score (= thr ) should be set as high as 97%, in order not to have too many false positives to deal with. In spite of such a high threshold, 562 potentially new objects were detected (over 4652 objects which were known when this study started), of which: 128 items are objects other than swimming pools (let's say an \"actual false positives\"); 211 items are swimming pools that are NOT subject to registration (temporary, above-ground, on top of a building, ...); 223 items are swimming pools that are subject to registration. This figures show that: on the one hand, the model performs quite well on the task it was trained for, in particular when an appropriate threshold is used; on the other hand, the meticulous review of results by domain experts remain essential. This said, automatic detections can surely be used to drive the domain experts' attention towards the areas which might require some. Examples of \"actual false positives\": a fountain (left) and a tunnel (right). Examples of detected swimming pools which are not subject to registration: placed on top of a building (left), inflatable hence temporary (right).","title":"Domain experts feedback"},{"location":"PROJ-GEPOOL/#conclusion","text":"The analysis reported in this document confirms the opportunity of using state-of-the-art Deep Learning approaches to assist experts in some of their tasks, in this case that of keeping the cadastre up to date. Not only the opportunity was explored and actually confirmed, but valuable results were also produced, leading to the detection of previously unknown objects. At the same time, our study also shows how essential domain expertise still remains, despite the usage of such advanced methods. As a concluding remark, let us note that our predictive model may be further improved. In particular, it may be rendered less prone to false positives, for instance by: leveraging 3D data ( e.g. point clouds), in order to potentially remove temporary, above-ground swimming pools from the set of detected objects; injecting into the training dataset those predictions which were classified by domain experts as other objects or temporary swimming pools; leveraging some other datasets, already available through the SITG portal : buildings , miscellaneous objects , etc.","title":"Conclusion"},{"location":"PROJ-HETRES/","text":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds \u00b6 Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Canton of Jura - PROJ-HETRES October 2022 to August 2023 - Published on November 13, 2023 All scripts are available on GitHub . Abstract : Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors. 1. Introduction \u00b6 Since the drought episode of 2018, the canton of Jura and other cantons have noticed dieback of the beech trees in their forests 1 . In the canton of Jura, this problem mainly concerns the Ajoie region, where 1000 hectares of deciduous trees are affected 2 . This is of concern for the productivity and management of the forest, as well as for the security of walkers. In this context, the R\u00e9publique et Canton du Jura has contacted the Swiss Territorial Data Lab to develop a new monitoring solution based on data science, airborne images and LiDAR point clouds. The dieback symptoms are observable in the mortality of branches, the transparency of the tree crown and the leaf mass partition 3 . The vegetation health state influences the reflectance in images (airborne and satellite), which is often used as a monitoring tool, in particular under the form of vegetation indices: Normalized Difference Vegetation Index (NDVI), a combination of the near-infrared and red bands quantifying vegetation health; Vegetation Health Index (VHI), an index quantifying the decrease or increase of vegetation in comparison to a reference state. For instance, Brun et al. studied early-wilting in Central European forests with time series of the Normalized Difference Vegetation Index (NDVI) and estimate the surface concerned by early leaf-shedding 4 . Another technology used to monitor forests is light detection and ranging (LiDAR) as it penetrates the canopy and gives 3D information on trees and forest structures. Several forest and tree descriptors such as the canopy cover 5 or the standard deviation of crown return intensity 6 can be derived from the LiDAR point cloud to monitor vegetation health state. In 5 , the study was conducted at tree level, whereas in 6 stand level was studied. To work at tree level, it is necessary to segment individual trees in the LiDAR point cloud. On complex forests, like with a dense understory near tree stems, it is challenging to get correct segments without manual corrections. The aim of this project is to provide foresters with a map to help plan the felling of beech trees in the Ajoie's forests. To do so, we developed a combined method using LiDAR point clouds and airborne and satellite multispectral images to determine the health state of beech trees. 2. Study area \u00b6 The study was conducted in two areas of interest in the Ajoie region (Fig. 1.A); one near Mi\u00e9court (Fig. 1.B), the other one near Beurnev\u00e9sin (Fig. 1.C). Altogether they cover 5 km 2 , 1.4 % of the Canton of Jura's forests 7 . Mi\u00e9court sub-area is west-south and south oriented, whereas Beurnev\u00e9sin sub-area is rather east-south and south oriented. They are in the same altitude range (600-700 m) and are 2 km away from each other, thus near the same weather station. Figure 1: The study area is composed of two areas of interest. 3. Data \u00b6 The project makes use of different data types: LiDAR point cloud, airborne and satellite imagery, and ground truth data. Table 1 gives an overview of the data and their characteristics. Data have been acquired in late summer 2022 to have an actual and temporally correlated information on the health state of beech trees. Table 1: Overview of the data used in the project. Resolution Acquisition time Proprietary LiDAR 50-100 pts/m 2 08.2022 R\u00e9publique et Canton du Jura Airborne images 0.03 m 08.2022 R\u00e9publique et Canton du Jura Yearly variation of NDVI 10 m 06.2015-08.2022 Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) Weekly vegetation health index 10 m 06.2015-08.2022 ExoLabs Ground truth - (point data) 08.-10.2022 R\u00e9publique et Canton du Jura 3.1 LiDAR point cloud \u00b6 The LiDAR dataset was acquired on the 16th of August 2023 and its point density is 50-100 pts/m\u00b2. It is classified in the following classes: ground, low vegetation (2-10m), middle vegetation (10-20m) and high vegetation (20 m and above). It was delivered in the LAS format and had reflectance values 8 in the intensity storage field. 3.2 Airborne images \u00b6 The airborne images have a ground resolution of 3 cm and were acquired simultaneously to the LiDAR dataset. The camera captured the RGB bands, as well as the near infrared (NIR) one. The acquisition of images with a lot of overlap and oblique views allowed the production of a true orthoimage for a perfect match with the LiDAR point cloud and the data of the ground truth. 3.3 Satellite images \u00b6 The Sentinel-2 mission from the European Space Agency is passing every 6 days over Switzerland and allows free temporal monitoring at a 10 m resolution. The archives are available back to the beginning of beech tree dieback in 2018. 3.3.1 Yearly variation of NDVI \u00b6 The Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) have developed Web Services for vegetation monitoring derived from Sentinel-2 images. For this project, the yearly variation of NDVI 9 between two successive years is used. It measures the decrease in vegetation activity between August of one year (e.g. 2018) and June of the following year (e.g. 2019). The decrease is derived from rasters made of maximum values of the NDVI in June, July or August. The data are downloaded from the WCS service which delivers \"row\" indices: the NDVI values are not cut for a minimal threshold. 3.3.2 VHI \u00b6 The Vegetation Health Index (VHI) was generated by ETHZ, WSL and ExoLab within the SILVA project 10 which proposes several indices for forest monitoring. VHI from 2016 to 2022 is used. It is computed mainly out of Sentinel-2 images, but also out of images from other satellite missions, in order to have data to obtain a weekly index with no time gap. 3.4 Ground truth \u00b6 The ground truth was collected between August and October 2022 by foresters. They assessed the health of the beech trees based on four criteria 3 : mortality of branches; transparency of the tree crown; leaf mass partition; trunk condition and other health aspects. In addition, each tree was associated with its coordinates and pictures as illustrated in Figure 1 and Figure 2 respectively. The forester surveyed: 75 healthy, 77 unhealthy and 56 dead trees. Tree locations were first identified in the field with a GPS-enabled tablet on which the 2022 SWISSIMAGE mosaic was displayed. Afterwards, the tree locations were precisely adjusted on the trunk locations by visually locating the corresponding stems in the LiDAR point cloud with the help of the pictures taken in the field. The location and health status of a further 18 beech trees were added in July 2023. These 226 beeches - under which are 76 healthy, 77 affected and 73 dead trees - surveyed at the two dates are defined as the ground truth for this project. Figure 2: Examples of the three health states: left, a healthy tree with a dense green tree crown; center, an unhealthy tree with dead twigs and a scarce foliage; right, a dead tree completely dry. 4. Method \u00b6 The method developed is based on the processing of LiDAR point clouds and of airborne images . Ready-made vegetation indices derived from satellite imagery were also used. First, a segmentation of the trees in the LiDAR point cloud was carried out using the Digital-Forestry-Toolbox (DFT) 11 . Then, descriptors for the health state of the beech trees were derived from each dataset. Boxplots and corresponding t-test are computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. Finally, the descriptors were used jointly with the ground truth to train a random forest (RF) algorithm, before inferring for the study area. Figure 3: Overview of the methodology, which processes the data into health descriptors for beech trees, before training and evaluating a random forest. 4.1 LiDAR processing \u00b6 At the beginning of LiDAR processing, exploration of the data motivated the segmentation and descriptors computation. 4.1.2 Data exploration \u00b6 In order to get an understanding of the available information at the tree level, we manually segmented three healthy, five unhealthy and three dead trees. More unhealthy trees have been segmented to better represent dieback symptoms. Vertical slices of each tree were rotary extracted, providing visual information on the health state. 4.1.3 Segmentation \u00b6 To be able to describe the health state of each tree, segmentation of the forest was performed using the DFT. Parameters have been tuned to find an appropriate segmentation. Two strategies for peak isolation were tested on the canopy height model (CHM): Maxima smoothing: a height difference is set below which all local maxima are suppressed. Local maxima within search radius: the size of the dilation window for identification of maxima is dependent on the height. Each peak isolation method was tested on a range of parameters and on different cell resolutions for the CHM computation. The detailed plan of the simulation is given in Appendix 1 . The minimum tree height was set to 10 m. For computation time reasons, only 3 LiDAR tiles with 55 ground truth (GT) trees located on them were processed. To find the best segmentation, the locations of the GT trees were compared to the location of the segment peaks. GT trees with a segmented peak less than 4 m away were considered as True Positive (TP). The best segmentation was the one with the most TP. 4.1.4 Structural descriptors \u00b6 An alternative to the segmentation is to change of paradigm and perform the analyses at the stand level. Meng et al. 6 derived structural descriptors for acacia dieback at the stand level based on LiDAR point cloud. By adapting their method to the present case, the following descriptors were derived from the LiDAR point cloud using the LidR library from R 12 : Canopy maximal height. Scale and shape parameters of the Weibull density function fitted for the point distribution along the height. Coefficient of variation of leaf area density (cvLAD) describing the distribution of the vertical structure of photosynthetic tissue along the height. Vertical Complexity Index (VCI): Entropy measure of the vertical distribution of vegetation. Standard deviation of the canopy height model (sdCHM), reflects canopy height variations. Canopy cover (CC) and standard deviation (sdCC), reflects foliage density and coverage. Above ground biomass height (AGH), reflects the understory height until 10 m. Descriptors 1 to 6 are directly overtaken from Meng et al. All the descriptors were first computed for three grid resolutions: 10 m, 5 m and 2.5 m. In a second time, the DFT segments were considered as an adaptive grid around the trees, with the assumption that it is still more natural than a regular grid. Then, structural descriptors for vertical points distribution (descriptors 1 to 4) were computed on each segment, whereas descriptors for horizontal points distribution (descriptors 5 to 7) have been processed for 2.5 m grid. A weight was applied to the value of the latter descriptors according to the area of grid cells included in the footprint of the segments. Furthermore, LiDAR reflectance mean and standard deviation (sd) were computed for the segment crowns to differentiate them by their reflectance. 4.2 Image processing \u00b6 For the image processing, an initial step was to compute the normalized difference vegetation index (NDVI) for each raster image. The normalized difference vegetation index (NDVI) is an index commonly used for the estimation of the health state of vegetation 5 13 14 . \\[\\begin{align} \\ NDVI = {NIR-R \\over NIR+R} \\ \\end{align}\\] where NIR and R are the value of the pixel in the near-infrared and red band respectively. To uncover potential distinctive features between the classes, boxplots and principal component analysis were used on the images four bands (RGB-NIR) and the NDVI. Firstly, we tested if the brute pixel values allowed the distinction between classes at a pixel level. This method avoids the pit of the forest segmentation into trees. Secondly, we tested the same method, but with some low-pass filter to reduce the noise in the data. Thirdly, we tried to find distinct statistical features at the tree level. This approach allows decreasing the noise that can be present in high-resolution information. However, it necessitates having a reasonably good segmentation of the trees. Finally, color filtering and edge detection were tested in order to highlight and extract the linear structure of the branches. For each treatment, it is possible to do it with or without a mask on the tree height. As only trees between 20 m and 40 m tall are affected by dieback, a mask based on the Canopy Height Model (CHM) raster derived from the LiDAR point cloud was tested. Figure 4: Overview of different possible data treatments for the the statistical analysis. 4.2.1 Statistical tests on the original and filtered pixels \u00b6 The statistical tests were performed on the original and filtered pixels. Two low pass filters were tested: Gaussian with a sigma of 5; Bilinear downsampling with scale factors of 1/3, 1/5 and 1/17, corresponding to resolutions of 9, 15 and 50 cm. In the original and the filtered cases, the pixels for each GT tree were extracted from the images and sorted by class. Then, the corresponding NDVI is computed. Each pixel has 5 attributes corresponding to its value on the four bands (R, G, B, NIR) and its NDVI. First, the per-class boxplots of the attributes were executed to see if the distinction between classes was possible on one or several bands or on the NDVI. Then, the principal component analysis (PCA) was computed on the same values to see if their linear combination allowed the distinction of the classes. 4.2.2. Statistical tests at the tree level \u00b6 For the tests at the tree level, the GT trees were segmented by hand. For each tree, the statistics of the pixels were calculated over its polygon, on each band and for the NDVI. Then, the results were sorted by class. Each tree has five attributes per band or index corresponding to the statistics of its pixels: minimum (min), maximum (max), mean, median and standard deviation (std). Like with the pixels, the per-class boxplots of the attributes were executed to see if the distinction between classes was possible. Then, the PCA was computed. 4.2.3 Extraction of branches \u00b6 One of the beneficiaries noted that the branches are clearly visible on the RGB images. Therefore, it may be possible to isolate them with color filtering based on the RGB bands. We calibrated an RGB filter through trial and error to produce a binary mask indicating the location of the branches. A sieve filter was used to reduce the noise due to the lighter parts of the foliage. Then, a binary dilation was performed on the mask to highlight the results. Otherwise, they would be too thin to be visible at a 1:5'000 scale. A mask based on the CHM is integrated to the results to limit the influence of the ground. The branches have a characteristic linear structure. In addition, the branches of dead trees tend to be very light line on the dark forest ground and understory. Therefore, we thought that we may detect the dead branches thanks to edge detection. We used the canny edge detector and tested the python functions of the libraries openCV and skimage . 4.3 Satellite-based indices \u00b6 The yearly variation of NDVI and the VHI were used to take account of historical variations of NDVI from 2015 to 2022. For the VHI, the mean for each year is computed over the months considered for the yearly variation of NDVI. The pertinence of using these indices was explored: the values for each tree in the ground truth were extracted and observed in boxplots per health class in 2022 per year pair over the time span from 2015 to 2022. 4.4 Random Forest \u00b6 In R 12 , the caret and randomForest packages were used to train the random forest and make predictions. First, the ground truth was split into the training and the test datasets, with each class being split 70 % into the training set and 30 % into the test set. Health classes with not enough samples were completed with copies. Optimization of the RF was performed on the number of trees to develop and on the number of randomly sampled descriptors to test at each split. In addition, 5-fold cross-validation was used to ensure the use of different parts of the dataset. The search parameter space was from 100 to 1000 decision trees and from 4 to 10 descriptors as the default value is the square root of all descriptors, i.e. 7. RF was assessed using a custom metric, which is an adaptation of the false positive rate for the healthy class. It minimizes the amount of false healthy detections and of dead trees predicted as unhealthy (false unhealthy). It is called custom false positive rate (cFPR) in the text. It was preferred to have a model with more unhealthy predictions to control on the field, than missing unhealthy or dead trees. The cFPR goes from 0 (best) to 1 (worse). Table 2: Confusion matrix for the three health classes. Ground truth Healthy Unhealthy Dead Prediction Healthy A B C Unhealthy D E F Dead G H I According to the confusion matrix in Table 2, the cFPR is computed as follows: \\[\\begin{align} \\ cFPR = {(\ud835\udc35+\ud835\udc36+\ud835\udc39)\\over(\ud835\udc35+\ud835\udc36+\ud835\udc38+\ud835\udc39+\ud835\udc3b+\ud835\udc3c)}. \\ \\end{align}\\] In addition, the overall accuracy (OA), i.e. the ratio of correct predictions over all the predictions, and the sensitivity, which is, per class, the number of correct predictions divided by the number of samples from that class, are used. An ablation study was performed on descriptors to assess the contribution of the different data sources to the final performance. An \u201cimportant\u201d descriptor is having a strong influence on the increase in prediction errors in the case of random reallocation of the descriptor values in the training set. After the optimization, predictions for each DFT segments were computed using the best model according to the cFPR. The inferences were delivered as a thematic map with colors indicating the health state and hue indicating the fraction of decision trees in the RF having voted for the class (vote fraction). The purpose is to give a confidence information, with high vote fraction indicating robust predictions. Furthermore, the ground truth was evaluated for quantity and quality by two means: Removal of samples and its impact on the metric evaluation Splitting the training set into training subsets to evaluate on the original test set. Finally, after having developed the descriptors and the routine on high-quality data, we downgraded them to have resolutions similar to the ones of the swisstopo products (LiDAR: 20 pt/m 2 , orthoimage: 10 cm) and performed again the optimization and prediction steps. Indeed, the data acquisition was especially commissioned for this project and only covers the study area. If in the future the method should be extended, one would like to test if a lower resolution as the one of the standard national-wide product SWISSIMAGE could be sufficient. 5 Results and discussion \u00b6 In this section, the results obtained during the processing of each data source into descriptors are presented and discussed, followed by a section on the random forest results. 5.1 LiDAR processing \u00b6 For the LiDAR data, the reader will first discover the aspect of beech trees in the LiDAR point cloud according to their health state as studied in the data exploration. Then, the segmentation results and the obtained LiDAR-based descriptors will be presented. 5.1.2 Data exploration for 11 beech trees \u00b6 The vertical slices of 11 beech trees provided visual information on health state: branch shape, clearer horizontal and vertical point distribution. In Figure 5, one can appreciate the information shown by these vertical slices. The linear structure of the dead branches, the denser foliage of the healthy tree and the already smaller tree crown of the dead tree are well recognizable. Figure 5: Slices for three trees with different health state. Vertical slices of each tree were rotary extracted, providing visual information on the health state. Dead twigs and density of foliage are particularly distinctive. Some deep learning image classifier could treat LiDAR point cloud slices as artificial images and learn from them before classifying any arbitrary slice from the LiDAR point cloud. However, the subject is not adapted to transfer learning because 200 samples are not enough to train a model to classify three new classes, especially via images without resemblance to datasets used to pre-train deep learning models. 5.1.3 Segmentation \u00b6 Since the tree health classes were visually recognizable for the 11 trees, it was very interesting to individuate each tree in the LiDAR point cloud. After having searched for optimal parameters in the DFT, the best realization of each peak isolation method either slightly oversegmented or slightly undersegmented the forest. The forest has a complex structure with dominant and co-dominant trees, and with understory. A simple yet frequent example is the situation of a small pine growing in the shadow of a beech tree. It is difficult for an algorithm to differentiate between the points belonging to the pine and those belonging to the beech. Complex tree crowns (not spheric, with two maxima) especially lead to oversegmentation. As best segmentation, the smoothing of maxima on a 0.5 m resolution CHM was identified. Out of 55 GT trees, 52 were within a 4 m distance from the centroid of a segment. The total number of segments is 7347. This corresponds to 272 trees/ha. Report of a forest inventory in the Jura forest between 2003 and 2005 indicated a density of 286 trees/ha in high forest 7 . Since the ground truth is only made of point coordinates, it is difficult to assess quantitatively the correctness of the segments, i.e. the attribution of each point to the right segment. Therefore, the work at the tree level is only approximate. 5.1.4 Structural descriptors \u00b6 Nevertheless, the structural descriptors for each tree were computed from the segmented LiDAR point cloud. The t-test between health classes for each descriptor at each resolution (10 m, 5 m, 2.5 m and per-tree grid) are given in Appendices 2 , 3 , 4 and 5 . The number of significant descriptors per resolution is indicated to understand better the effect on the RF: at 10 m: 13 at 5 m: 17 at 2.5 m: 18 per tree: 15 The simulations at 5 m and at 2.5 m seemed a priori the most promising. In both constellations, t-tests indicated a significant different distribution for: maximal height, between the three health states, sdCHM, between the three health states, cvLAD, healthy trees against the others, mean reflectance, healthy trees against the others, VCI, healthy trees against unhealthy trees, canopy cover, healthy trees against dead trees, standard deviation of the reflectance, dead trees against the others, sdCC, dead trees against the others. The maximal height and the sdCHM appear to be the most suited descriptors to separate the three health states. The other descriptors are differentiating healthy trees from the others or dead trees from the others. From the 11 LiDAR-based descriptors, 8 are at least significant for the comparison between two classes. 5.2 Image processing \u00b6 Boxplots and PCA are given to illustrate the results of the image processing exploration. As the masking of pixels below and above the affected height made no difference in the interpretation of the results, they are presented here with the height mask. 5.2.1 Boxplots and PCA over the pixel values of the original images \u00b6 When the pixel values of the original images per health class are compared in boxplots (ex. Fig. 6), the sole brute value of the pixel is not enough to clearly distinguish between classes. Figure 6: Boxplots of the unfiltered pixel values on the different bands and the NDVI index by health class. The PCA in Figure 7 shows that it is not possible to distinguish the groups based on a linear combination of the brute pixel values of the band and NDVI. Figure 7: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI. 5.2.2 Boxplots and PCA over the pixel values of the filtered images \u00b6 A better separation of the different classes is noticeable after the application of a Gaussian filter. The most promising band is the NIR one for a separation of the healthy and dead classes. On the NDVI, the distinction between those two classes should also be possible as illustrated in Figure 8. In all cases, there is no possible distinction between the healthy and unhealthy classes. The separation between the healthy and dead trees on the NIR band would be around 130 and the slight overlap on the NDVI band is between approx. 0.04 and approx. 0.07. Figure 8: Boxplots of the pixel values on the different bands and the NDVI by health class after a Gaussian filter with sigma=5. As for the brute pixels, the overlap between the different classes is still very present in the PCA (Fig. 9). Figure 9: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI after a Gaussian filter with sigma=5. The boxplots produced on the resampled images (Figure 10) give similar results to the ones with the Gaussian filter. The healthy and dead classes are separated on the NIR band around 130. The unhealthy class stays similar to the healthy one. Figure 10: Boxplots of the pixel values on the different bands and the NDVI by health class after a downsampling filter with a factor 1/3. According to the PCA in Figure 11, it seems indeed not possible to distinguish between the classes only with the information presented in this section. Figure 11: Distribution of the pixels in the space of the principal components based on the pixel values on the different branches and the NDVI after a downsampling filter with a factor 1/3. When the factor for the resampling is decreased, i.e. when the resulting resolution increases, the separation on the NIR band becomes stronger. With a factor of 1/17, the healthy and dead classes on the NDVI are almost entirely separated around the value of 0.04. 5.2.3 Boxplots and PCA over the tree statistics \u00b6 As an example for the per-tree statistics, the boxplots and PCA for the blue band are presented in Figures 12 to 14. On the mean and on the standard deviation, healthy and dead classes are well differentiated on the blue band as visible on Figure 12. The same is observed on the mean, median, and minimum of the NDVI, as well as on the maximum, mean, and median of the NIR band. However, there is no possible differentiation on the red and green bands. Figure 12: Boxplots of the statistics values for each tree on the blue band by health class. In the PCA in Figure 13, the groups of the healthy and dead trees are quite well separated, mostly along the first component. Figure 13: Distribution of the trees in the space of the principal components based on their statistical values on the blue band. On Figure 14, the first principal component is influenced principally by the standard deviation of the blue band. The mean, the median and the max have an influence too. This is in accordance with the boxplots where the standard deviation values presented the largest gap between classes. Figure 14: Influence of the statistics for the blue band on the first and second principal components. The point clouds of the dead and healthy classes are also well separated on the PCA of the NIR band and of the NDVI. No separation is visible on the PCA of the green and red bands. 5.2.4 Extraction of branches \u00b6 Finally, the extraction of dead branches was performed. Use of an RGB filter \u00b6 The result of the RGB filter is displayed in Figure 15. It is important to include the binary CHM in the visualization. Otherwise, the ground can have a significant influence on certain zones and distract from the dead trees. Some interferences can still be seen among the coniferous trees that have a similar light color as dead trees. Figure 15: Results produced by the RGB filter for the detection and highlight of dead branches over a zone with coniferous, healthy deciduous and dead deciduous trees. The parts in grey are the zones masked by the filter on the height. Use of the canny edge detector \u00b6 Figure 16 presents the result for the blue band which was the most promising one. The dead branches are well captured. However, there is a lot of noise around them due to the high contrasts in some parts of the foliage. The result is not usable as is. Using a stricter filter decreased the noise, but it also decreased the captured pixels of the branches. In addition, using a sieve filter or trying to combine the results with the ones of the RGB filter did not improve the situation. Figure 16: Test of the canny edge detector from sklearn over a dead tree by using only the blue band. The parts in grey are the zones masked by the CHM filter on the height. The results for the other bands, RGB images or the NDVI were not usable either. 5.2.5 Discussion \u00b6 The results at the tree level are the most promising ones. They are integrated into the random forest. Choosing to work at the tree-level means that all the trees must be segmented with the DFT. This adds uncertainties to the results. As explained in the dedicated section , the DFT has a tendency of over/under-segmenting the results. The procedures at the pixel level, whether on filtered or unfiltered images, are abandoned. For the branch detection, the results were compared with some observations on the terrain by a forest expert. He assessed the result as incorrect in several parts of the forest. Therefore, the use of dead branch detection was not integrated in the random forest. In addition, the edge detection was maybe not the right choice for dead branches and maybe we should have taken an approach more focused on detection of straight lines or graphs. The chance of success of such methods are difficult to predict as there can be a lot of variations in the form of the dead branches. 5.3 Vegetation indices from satellite imagery \u00b6 The t-test used to evaluate the ability of satellite indices to differentiate between health states are given in Appendices 6 and 7 . In the following two subsections, solely the significant tested groups are mentioned for understanding the RF performance. 5.3.1 Yearly variation of NDVI \u00b6 t-test on the yearly variation of NDVI indicated significance between: all health states in 2018-2019: 2018 was an especially dry and hot year, whereas 2019 was in the seasonal normals. The recovery in 2019 may have differed according to the health classes. healthy and other trees in 2016-2017 and 2019-2020: maybe healthy trees are responding diversely to environmental factors than affected trees. healthy and dead trees in 2021-2022: this reflects a higher increase of NDVI for the dead trees. Is the understory benefitting from clearer forest structure? 5.3.2 Vegetation Healthy Index \u00b6 t-test on the VHI indicated significance between: dead and other trees in 2017 healthy and dead trees in 2018 healthy and other trees in 2019 unhealthy and other trees in 2021 dead and unhealthy trees in 2020 and 2022 Explanations similar to those for NDVI may partly explain the significance obtained. In any case,it is encouraging that the VHI helps to differentiate health classes thanks to different evolution through the years. 5.4 Random Forest \u00b6 The results of the RF that are presented and discussed are: (1) the optimization and ablation study, (2) the ground truth analysis, (3) the predictions for the AOI and (4) the performance with downgraded data. 5.4.1 Optimization and ablation study \u00b6 In Table 3, performance for VHI and yearly variation of NDVI (yvNDVI) descriptors using their value at the location of the GT trees are compared. VHI (cFPR = 0.24, OA = 0.63) performed better than the yearly variation of NDVI (cFPR = 0.39, OA = 0.5). Both groups of descriptors are mostly derived from satellite data with the same resolution (10 m). A conceptual difference is that the VHI is a deviation to a long-term reference value; whereas the yearly variation of NDVI reflects the change between two years. For the latter, values can be high or low independently of the actual health state. Example, a succession of two bad years will indicate few to no differences in NDVI. Table 3: RF performance with satellite-based descriptors. Descriptors cFPR OA VHI 0.24 0.63 yvNDVI 0.39 0.5 Nonetheless, only the yearly variation of NDVI is used hereafter as it is available free of charge. Regarding the LiDAR descriptors, the tested resolutions indicated that the 5 m resolution (cFPR = 0.2 and OA = 0.65) was performing the best for the cFPR, but that the per-tree descriptors had the higher OA (cFPR = 0.33, OA = 0.67). At 5 m resolution, fewer affected trees are missed, but there are more errors in the classification, so more control on the field would have to be done. The question of which grid resolution to use on the forest is a complex one, as the forest consists of trees of different sizes. Further, even if dieback affects some areas more severely than others, it's not a continuous phenomenon, and it is important to be able to clearly delimit each tree. However, a grid, as the 2.5 m one, can also hinder to capture the entirety of some trees and the performance may decrease (LiDAR, 2.5 m, OA=0.63). Table 4: RF performance with LiDAR-based descriptors at different resolutions. Descriptors cFPR OA LiDAR, 10 m 0.3 0.6 LiDAR, 5 m 0.2 0.65 LiDAR, 2.5 m 0.28 0.63 LiDAR, per tree 0.33 0.67 Then, the 5 m resolution descriptors are kept for the rest of the analysis according to the decision of reducing missed dying trees. The ablation study performed on the descriptor sources is summarized in Table 5.A and Table 5.B. The two tables reflect performance for two different partitions of the samples in training and test sets. Since the performance is varying form several percents, the performance is impacted by the repartition of the samples. Following those values, the best setups for each partition respectively are the full model (cFPR = 0.13, OA = 0.76) and the airborne-based model (cFPR = 0.11, OA = 0.79). One notices that all the health classes are not predicted with the same accuracy. The airborne-based model, as described in Section 5.2.3 , is less sensitive to the healthy class; whereas the satellite-based model and the LiDAR-based model is more polarized to healthy and dead classes, with low sensitivity performance in the unhealthy class. Table 5.A: Ablation study results, partition A of the dataset. Descriptor sources cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead LiDAR 0.2 0.65 0.65 0.61 0.71 Airborne images 0.18 0.63 0.43 0.61 0.94 yvNDVI 0.4 0.49 0.78 0.26 0.41 LiDAR and yvNDVI 0.23 0.7 0.74 0.61 0.76 Airborne images and yvNDVI 0.15 0.73 0.65 0.7 0.88 LiDAR, airborne images and yvNDVI 0.13 0.76 0.65 0.74 0.94 Table 5.B: Ablation study results, partition B of the dataset. Descriptor sources cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead LiDAR 0.19 0.71 0.76 0.5 0.88 Airborne images 0.11 0.79 0.62 0.8 1 yvdNDVI 0.38 0.62 0.81 0.4 0.65 LiDAR and yvNDVI 0.27 0.74 0.86 0.5 0.88 Airborne images and yvNDVI 0.14 0.78 0.62 0.8 0.94 LiDAR, airborne images and yvNDVI 0.14 0.79 0.71 0.7 1 Even if the performance varies according to the dataset partition, the important descriptors remain quite similar between the two partitions as displayed in Figure 17.A and Figure 17.B. The yearly difference of NDVI between 2018 and 2019 ( NDVI_diff_1918 ) is the most important descriptor; standard deviation on the blue band ( b_std ) and the mean on the NIR band and NDVI ( nir_mean and ndvi_mean ) are standing out in both cases; from the LiDAR, the standard deviation of canopy cover ( sdcc ) and of the LiDAR reflectance ( i_sd_seg ) are the most important descriptors. The order of magnitude explains the better performance on partition B with the airborne-based model: for instance, the b_std has the magnitude of 7.6 instead of 4.6 with Partition B. Figure 17.A: Important descriptors for the full model, dataset partition A. Figure 17.B: Important descriptors for the full model, dataset partition B. The most important descriptor of the full model resulted to be the yearly variation of NDVI between 2018 and 2019. The former was a year with a dry and hot summer which has stressed beech trees and probably participated to cause forest damages 1 . This corroborates the ability of our RF method to monitor the response of trees to extreme drought events. However, the 10 m resolution of the index and the different adaptability of individual beech trees to drought may make the relationship between current health status and the index weak. This can explain that the presence of this descriptor in the full model doesn't offer better performance than the airborne-based model to predict the health state. Both the mean on the NIR band and the standard deviation on the blue band play an important role. Statistical study in Section 5.2.3 indicated that the models might confuse healthy and unhealthy classes. On one hand, airborne imagery only sees the top of the crown and may miss useful information on hidden part. On the other hand, airborne imagery has a good ability to detect dead trees thanks to different reflectance values in NIR and blue bands. One argument that could explain the lower performance of the model based on LiDAR-based descriptors is the difficulty to find the right scale to perform the analysis as beech trees can show a wide range of crown diameters. 5.4.2 Ground truth analysis \u00b6 With progressive removal of sample individuals from the training set, impact of individual beech trees on the performance is further analyzed. The performance variation is shown in Figure 18. The performance is rather stable in the sense that the sensitivities stay in a range of values similar to the initial one up to 40 samples removed, but with each removal, a slight instability in the metrics is visible. The size of the peaks indicates variations of 1 prediction for the dead class, but up to 6 predictions for the unhealthy class and up to 7 for the healthy class. During the sample removal, some samples were always predicted correctly, whereas others were often misclassified leading to the peaks in Figure 18. With the large number of descriptors in the full model, there is no straightforward profile of outliers to identify. Figure 18: Evolution of the per-class sensitivity with removal of samples. In addition, the subsampling of the training set in Table 6 shows that the OA varies only by max. 3% according to the subset used. It indicated again that the amount of ground truth allows to reach a stable OA range, but the characteristics of the samples does not allow a stable OA value. The sensitivity for the dead classes is stable, whereas sensitivity for healthy and unhealthy class are varying. Table 6: Performance according to different random seed for the creation of the training subset. Training set subpartition cFPR OA Sensitivity healthy Sensitivity unhealthy Sensitivity dead Random seed = 2 0.13 0.76 0.61 0.83 0.88 Random seed = 22 0.15 0.78 0.70 0.78 0.88 Random seed = 222 0.18 0.75 0.65 0.74 0.88 Random seed = 2222 0.13 0.76 0.65 0.78 0.88 Random seed = 22222 0.10 0.78 0.65 0.83 0.88 5.4.3 Predictions \u00b6 The full model and the airborne-based-model were used to infer the health state of trees in the study area (Fig. 19). As indicated in Table 7, with the full model, 35.1 % of the segments were predicted as healthy, 53 % as unhealthy and 11.9 % as dead. With the airborne-based model, 42.6 % of the segments were predicted as healthy, 46.2 % as unhealthy and 11.2 % as dead. The two models agree on 74.3 % of the predictions. In the 25.6 % of disagreement, it is about 77.1% of disagreement between healthy and unhealthy predictions. Finally, 1.5% are critical disagreement (between healthy and dead classes). Table 7: Percentage of health in the AOI. Model Healthy [%] Unhealth [%] Dead [%] Full 35.1 53 11.9 Airborne-based 42.6 46.2 11.2 Control by forestry experts reported that the predictions mostly correspond to the field situation and that a weak vote fraction often corresponds to false predictions. They confirmed that the map is delivering useful information to help plan beech tree felling. The final model retained after excursion on the field is the full model. Figure 19: Extract of the predicted thematic health map. Green is for healthy, yellow for unhealthy, and red for dead trees. Hues indicate the RF fraction of votes. The predictions can be compared with the true orthophoto in the background. The polygons approximating the tree crowns correspond to the delimitation of segmented trees. 5.4.4 Downgraded data \u00b6 Finally, random forest models are trained and tested on downgraded data with the partition A of the ground truth for all descriptors and by descriptor sources. With this partition, RF have a better cFPR for the full model (0.08 instead of 0.13), the airborne-based model (0.08 instead of 0.21) and the LiDAR-based model (0.28 instead of 0.31). The OA is also better (full model: 0.84 instead of 0.76, airborne-based model: 0.77 instead of 0.63), except in the case of the LiDAR-based model (0.63 instead of 0.66). It indicated that the resolution of 10 cm in the aerial imagery does not weaken the model and can even improve it. For the LiDAR point cloud, a reduction by a factor 5 of the density has not changed much the performance. Table 7.A: Performance for RF trained and tested with the partition A of the dataset of downgraded data. Simulation cFPR OA Full 0.08 0.84 Airborne-based 0.08 0.77 LiDAR-based 0.28 0.63 Table 7.A: Performance for RF trained and tested with the partition A of the dataset for original data. Simulation cFPR OA Full 0.13 0.76 Airborne-based 0.21 0.63 LiDAR-based 0.31 0.66 When the important descriptors are compared between the original and downgraded model, one notices that the airborne descriptors gained in importance in the full model when data are downgraded. The downgraded model showed sufficient accuracy for the objective of the project. 6 Conclusion and outlook \u00b6 The study has demonstrated the ability of a random forest algorithm to learn from structural descriptors derived from LiDAR point clouds and from vegetation reflectance in airborne and satellite images to predict the health state of beech trees. Depending on the used datasets for training and test, the optimized full model including all descriptors reached an OA of 0.76 or of 0.79, with corresponding cFPR values of 0.13 and 0.14 respectively. These metrics are sufficient for the purpose of prioritizing beech tree felling. The produced map, with the predicted health state and the corresponding votes for the segments, delivers useful information for forest management. The cantonal foresters validated the outcomes of this proof-of-concept and explained how the location of affected beech trees as individuals or as groups are used to target high-priority areas. The full model highlighted the importance of the yearly variation of NDVI between a drought year (2018) and a normal year (2019). The airborne imagery showed good ability to predict dead trees, whereas confusion remained between healthy and unhealthy trees. The quality of the LiDAR point cloud segmentation may explain the limited performance of the LiDAR-based model. Finally, the model trained and tested on downgraded data gave an OA of 0.84 and a cFPR of 0.08. In this model, the airborne-based descriptors gained in importance. It was concluded that a 10 cm resolution may help the model by reducing the noise in the image. Outlooks for improving results include improving the ground truth representativeness of symptoms in the field and continuing research into descriptors for differentiating between healthy and unhealthy trees: For the image processing, suggestions are the integration of more statistics like the skewness and kurtosis of the reflectance as in Junttila et al. (2022) 15 . LiDAR-based descriptors had limited impact on the final results. To better valorize them for an application on beech trees, further research would be needed. Beside producing a cleaner segmentation and finding additional descriptors, it could consist in mixing the descriptors at the different resolutions and, with the help of the importance analysis, estimate at which resolution each descriptor brings the most information to the classification. The results showed the important contribution of vegetation indices derived from satellite imagery reflecting the drought year of 2018. If available, using historical image data of higher resolution to derive more descriptors could help improve individual tree health assessment. The possibility of further developments put aside, the challenge is now the extension of the methodology to a larger area. The simultaneity of the data is necessary to an accurate analysis. It has been shown that the representativeness of the ground truth has to be improved to obtain better and more stable results. Thus, for an extension to further areas, we recommend collecting additional ground truth measurements. The health state of the trees showed some autocorrelation that could have boosted our results and make them less representative of the whole forest. They should be more scattered in the forest. Furthermore, required data are a true orthophoto and a LiDAR point cloud for per-tree analysis. It should be possible to use an old LiDAR acquisition to produce a CHM and renounce to use LiDAR-based descriptors without degrading the performance of the model too much. 7 Appendixes \u00b6 7.1 Simulation plan for DFT parameter tuning \u00b6 Table 8: parameter tuning for DFT. CHM cell size [m] Maxima smoothing Local maxima within search radius 0.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 2.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 7.2 t-tests \u00b6 t-test were computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. 7.2.1 t-tests on LiDAR-based descriptors at 10 m \u00b6 Table 9: t-test on LiDAR-based descriptors at 10 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.002 1.12E-11 3.23E-04 scale parameter 0.005 0.014 0.964 shape parameter 0.037 0.002 0.269 cvLAD 0.001 2.22E-04 0.353 VCI 0.426 0.094 0.358 mean reflectance 4.13E-05 0.002 0.164 sd of reflectance 0.612 3.33E-06 9.21E-05 canopy cover 0.009 0.069 0.340 sdCC 0.002 0.056 0.324 sdCHM 0.316 0.262 0.892 AGH 0.569 0.055 0.120 7.2.2 t-test on LiDAR-based descriptors at 5 m \u00b6 Table 10: t-test on LiDAR-based descriptors at 5 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.001 4.67E-12 1.73E-04 scale parameter 0.072 0.831 0.204 shape parameter 0.142 0.654 0.361 cvLAD 9.14E-06 3.22E-05 0.667 VCI 0.006 0.104 0.485 mean reflectance 6.60E-05 2.10E-06 0.249 sd of reflectance 0.862 2.26E-08 9.24E-08 canopy cover 0.288 0.001 0.003 sdCC 1.42E-05 1.94E-11 0.001 sdCHM 0.004 1.94E-08 0.002 AGH 0.783 0.071 0.095 7.2.3 t-test on LiDAR-based descriptors at 2.5 m \u00b6 Table 11: t-test on LiDAR-based descriptors at 2.5 m. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 3.76E-04 7.28E-11 4.80E-04 scale parameter 0.449 0.283 5.60E-01 shape parameter 0.229 0.087 0.462 cvLAD 3.59E-04 1.06E-07 0.012 VCI 0.004 1.99E-05 0.072 mean reflectance 3.15E-04 5.27E-07 0.068 sd of reflectance 0.498 1.10E-10 4.66E-11 canopy cover 0.431 0.004 0.019 sdCC 0.014 1.94E-13 6.94E-09 sdCHM 0.003 5.56E-07 0.006 AGH 0.910 0.132 0.132 7.2.4 t-test on LiDAR-based descriptors per tree \u00b6 Table 12: t-test on LiDAR-based descriptors per tree. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead maximal height 0.001 1.98E-11 2.61E-04 scale parameter 0.726 0.618 0.413 shape parameter 0.739 0.795 0.564 cvLAD 0.001 4.23E-04 0.526 VCI 0.145 0.312 0.763 mean reflectance 1.19E-04 0.001 0.949 sd of reflectance 0.674 3.70E-07 4.79E-07 canopy cover 0.431 0.005 0.023 sdCC 0.014 4.43E-13 1.10E-08 sdCHM 0.003 2.71E-07 0.004 AGH 0.910 0.090 0.087 7.2.5 t-tests on yearly variation of NDVI \u00b6 Table 13: t-test on yearly variation of NDVI. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead 2016 0.177 0.441 0.037 2017 0.079 2.20E-06 0.004 2018 0.093 1.57E-04 0.132 2019 0.003 0.001 0.816 2020 0.536 0.041 0.005 2021 0.002 0.894 0.003 2022 0.131 0.103 0.002 7.2.6 t-test on VHI \u00b6 Table 14: t-test on VHI. Descriptors healthy vs. unhealthy healthy vs. dead unhealthy vs. dead 2015-2016 0.402 0.572 0.767 2016-2017 0.005 0.002 0.885 2017-2018 0.769 0.329 0.505 2018-2019 2.64E-05 3.98E-14 0.001 2019-2020 7.86E-06 9.55E-05 0.427 2020-2021 0.028 0.790 0.018 2021-2022 0.218 0.001 0.080 8 Sources and references \u00b6 Indications on software and hardware requirements, as well as the code used to perform the project, are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-hetres/tree/main. Other sources of information mentioned in this documentation are listed here: OFEV et al. (\u00e9d.). La canicule et la s\u00e9cheresse de l\u2019\u00e9t\u00e9 2018. Impacts sur l\u2019homme et l\u2019environnement. Technical Report 1909, Office f\u00e9d\u00e9ral de l\u2019environnement, Berne, 2019. \u21a9 \u21a9 Beno\u00eet Grandclement and Daniel Bachmann. 19h30 - En Suisse, la s\u00e9cheresse qui s\u00e9vit depuis plusieurs semaines frappe durement les arbres - Play RTS. February 2023. URL: https://www.rts.ch/play/tv/19h30/video/en-suisse-la-secheresse-qui-sevit-depuis-plusieurs-semaines-frappe-durement-les-arbres?urn=urn:rts:video:13829524 (visited on 2023-03-28). \u21a9 Xavier Gauquelin, editor. Guide de gestion des for\u00eats en crise sanitaire . Office National des For\u00eats, Institut pour le D\u00e9veloppement Forestier, Paris, 2010. ISBN 978-2-84207-344-2. \u21a9 \u21a9 Philipp Brun, Achilleas Psomas, Christian Ginzler, Wilfried Thuiller, Massimiliano Zappa, and Niklaus E. Zimmermann. Large-scale early-wilting response of Central European forests to the 2018 extreme drought. Global Change Biology , 26(12):7021\u20137035, 2020. _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/gcb.15360. URL: https://onlinelibrary.wiley.com/doi/abs/10.1111/gcb.15360 (visited on 2022-10-13), doi:10.1111/gcb.15360 . \u21a9 Run Yu, Youqing Luo, Quan Zhou, Xudong Zhang, Dewei Wu, and Lili Ren. A machine learning algorithm to detect pine wilt disease using UAV-based hyperspectral imagery and LiDAR data at the tree level. International Journal of Applied Earth Observation and Geoinformation , 101:102363, September 2021. URL: https://www.sciencedirect.com/science/article/pii/S0303243421000702 (visited on 2022-10-13), doi:10.1016/j.jag.2021.102363 . \u21a9 \u21a9 \u21a9 Pengyu Meng, Hong Wang, Shuhong Qin, Xiuneng Li, Zhenglin Song, Yicong Wang, Yi Yang, and Jay Gao. Health assessment of plantations based on LiDAR canopy spatial structure parameters. International Journal of Digital Earth , 15(1):712\u2013729, December 2022. URL: https://www.tandfonline.com/doi/full/10.1080/17538947.2022.2059114 (visited on 2022-12-07), doi:10.1080/17538947.2022.2059114 . \u21a9 \u21a9 \u21a9 Patrice Eschmann, Pascal Kohler, Vincent Brahier, and Jo\u00ebl Theubet. La for\u00eat jurassienne en chiffres, R\u00e9sultats et interpr\u00e9tation de l'inventaire forestier cantonal 2003 - 2005. Technical Report, R\u00e9publique et Canton du Jura, St-Ursanne, 2006. URL: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjHuZyfhoSBAxU3hP0HHeBtC4sQFnoECDcQAQ&url=https%3A%2F%2Fwww.jura.ch%2FHtdocs%2FFiles%2FDepartements%2FDEE%2FENV%2FFOR%2FDocuments%2Fpdf%2Frapportinventfor0305.pdf%3Fdownload%3D1&usg=AOvVaw0yr9WOtxMyY-87avVMS9YM&opi=89978449However . \u21a9 \u21a9 Agnieska Ptak. (5) Amplitude vs Reflectance \\textbar LinkedIn. June 2020. URL: https://www.linkedin.com/pulse/amplitude-vs-reflectance-agnieszka-ptak/ (visited on 2023-08-11). \u21a9 BFH-HAFL and BAFU. Waldmonitoring.ch : wcs_ndvi_diff_2016_2015, wcs_ndvi_diff_2017_2016, wcs_ndvi_diff_2018_2017, wcs_ndvi_diff_2019_2018, wcs_ndvi_diff_2020_2019, wcs_ndvi_diff_2021_2020, wcs_ndvi_diff_2022_2021. URL: https://geoserver.karten-werk.ch/wfs?request=GetCapabilities . \u21a9 Reik Leiterer, Gillian Milani, Jan Dirk Wegner, and Christian Ginzler. ExoSilva - ein Multi\u00ad-Sensor\u00ad-Ansatz f\u00fcr ein r\u00e4umlich und zeitlich hochaufgel\u00f6stes Monitoring des Waldzustandes. In Neue Fernerkundungs\u00adtechnologien f\u00fcr die Umweltforschung und Praxis , 17\u201322. Swiss Federal Institute for Forest, Snow and Landscape Research, WSL, April 2023. URL: https://www.dora.lib4ri.ch/wsl/islandora/object/wsl%3A33057 (visited on 2023-11-13), doi:10.55419/wsl:33057 . \u21a9 Matthew Parkan. Mparkan/Digital-Forestry-Toolbox: Initial release. April 2018. URL: https://zenodo.org/record/1213013 (visited on 2023-08-11), doi:10.5281/ZENODO.1213013 . \u21a9 R Core Team. R: A Language and Environment for Statistical Computing. 2023. URL: https://www.R-project.org/ . \u21a9 \u21a9 Olga Brovkina, Emil Cienciala, Peter Surov\u00fd, and P\u0159emysl Janata. Unmanned aerial vehicles (UAV) for assessment of qualitative classification of Norway spruce in temperate forest stands. Geo-spatial Information Science , 21(1):12\u201320, January 2018. URL: https://www.tandfonline.com/doi/full/10.1080/10095020.2017.1416994 (visited on 2022-07-15), doi:10.1080/10095020.2017.1416994 . \u21a9 N.K. Gogoi, Bipul Deka, and L.C. Bora. Remote sensing and its use in detection and monitoring plant diseases: A review. Agricultural Reviews , December 2018. doi:10.18805/ag.R-1835 . \u21a9 Samuli Junttila, Roope N\u00e4si, Niko Koivum\u00e4ki, Mohammad Imangholiloo, Ninni Saarinen, Juha Raisio, Markus Holopainen, Hannu Hyypp\u00e4, Juha Hyypp\u00e4, P\u00e4ivi Lyytik\u00e4inen-Saarenmaa, Mikko Vastaranta, and Eija Honkavaara. Multispectral Imagery Provides Benefits for Mapping Spruce Tree Decline Due to Bark Beetle Infestation When Acquired Late in the Season. Remote Sensing , 14(4):909, February 2022. URL: https://www.mdpi.com/2072-4292/14/4/909 (visited on 2023-10-27), doi:10.3390/rs14040909 . \u21a9","title":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds"},{"location":"PROJ-HETRES/#dieback-of-beech-trees-methodology-for-determining-the-health-state-of-beech-trees-from-airborne-images-and-lidar-point-clouds","text":"Clotilde Marmy (ExoLabs) - Gwena\u00eblle Salamin (ExoLabs) - Alessandro Cerioni (Canton of Geneva) - Roxane Pott (swisstopo) Proposed by the Canton of Jura - PROJ-HETRES October 2022 to August 2023 - Published on November 13, 2023 All scripts are available on GitHub . Abstract : Beech trees are sensitive to drought and repeated episodes can cause dieback. This issue affects the Jura forests requiring the development of new tools for forest management. In this project, descriptors for the health state of beech trees were derived from LiDAR point clouds, airborne images and satellite images to train a random forest predicting the health state per tree in a study area (5 km\u00b2) in Ajoie. A map with three classes was produced: healthy, unhealthy, dead. Metrics computed on the test dataset revealed that the model trained with all the descriptors has an overall accuracy up to 0.79, as well as the model trained only with descriptors derived from airborne imagery. When all the descriptors are used, the yearly difference of NDVI between 2018 and 2019, the standard deviation of the blue band, the mean of the NIR band, the mean of the NDVI, the standard deviation of the canopy cover and the LiDAR reflectance appear to be important descriptors.","title":"Dieback of beech trees: methodology for determining the health state of beech trees from airborne images and LiDAR point clouds"},{"location":"PROJ-HETRES/#1-introduction","text":"Since the drought episode of 2018, the canton of Jura and other cantons have noticed dieback of the beech trees in their forests 1 . In the canton of Jura, this problem mainly concerns the Ajoie region, where 1000 hectares of deciduous trees are affected 2 . This is of concern for the productivity and management of the forest, as well as for the security of walkers. In this context, the R\u00e9publique et Canton du Jura has contacted the Swiss Territorial Data Lab to develop a new monitoring solution based on data science, airborne images and LiDAR point clouds. The dieback symptoms are observable in the mortality of branches, the transparency of the tree crown and the leaf mass partition 3 . The vegetation health state influences the reflectance in images (airborne and satellite), which is often used as a monitoring tool, in particular under the form of vegetation indices: Normalized Difference Vegetation Index (NDVI), a combination of the near-infrared and red bands quantifying vegetation health; Vegetation Health Index (VHI), an index quantifying the decrease or increase of vegetation in comparison to a reference state. For instance, Brun et al. studied early-wilting in Central European forests with time series of the Normalized Difference Vegetation Index (NDVI) and estimate the surface concerned by early leaf-shedding 4 . Another technology used to monitor forests is light detection and ranging (LiDAR) as it penetrates the canopy and gives 3D information on trees and forest structures. Several forest and tree descriptors such as the canopy cover 5 or the standard deviation of crown return intensity 6 can be derived from the LiDAR point cloud to monitor vegetation health state. In 5 , the study was conducted at tree level, whereas in 6 stand level was studied. To work at tree level, it is necessary to segment individual trees in the LiDAR point cloud. On complex forests, like with a dense understory near tree stems, it is challenging to get correct segments without manual corrections. The aim of this project is to provide foresters with a map to help plan the felling of beech trees in the Ajoie's forests. To do so, we developed a combined method using LiDAR point clouds and airborne and satellite multispectral images to determine the health state of beech trees.","title":"1. Introduction"},{"location":"PROJ-HETRES/#2-study-area","text":"The study was conducted in two areas of interest in the Ajoie region (Fig. 1.A); one near Mi\u00e9court (Fig. 1.B), the other one near Beurnev\u00e9sin (Fig. 1.C). Altogether they cover 5 km 2 , 1.4 % of the Canton of Jura's forests 7 . Mi\u00e9court sub-area is west-south and south oriented, whereas Beurnev\u00e9sin sub-area is rather east-south and south oriented. They are in the same altitude range (600-700 m) and are 2 km away from each other, thus near the same weather station. Figure 1: The study area is composed of two areas of interest.","title":"2. Study area"},{"location":"PROJ-HETRES/#3-data","text":"The project makes use of different data types: LiDAR point cloud, airborne and satellite imagery, and ground truth data. Table 1 gives an overview of the data and their characteristics. Data have been acquired in late summer 2022 to have an actual and temporally correlated information on the health state of beech trees. Table 1: Overview of the data used in the project. Resolution Acquisition time Proprietary LiDAR 50-100 pts/m 2 08.2022 R\u00e9publique et Canton du Jura Airborne images 0.03 m 08.2022 R\u00e9publique et Canton du Jura Yearly variation of NDVI 10 m 06.2015-08.2022 Bern University of Applied Science (HAFL) and the Federal Office for Environment (BAFU) Weekly vegetation health index 10 m 06.2015-08.2022 ExoLabs Ground truth - (point data) 08.-10.2022 R\u00e9publique et Canton du Jura","title":"3. Data"},{"location":"PROJ-HETRES/#31-lidar-point-cloud","text":"The LiDAR dataset was acquired on the 16th of August 2023 and its point density is 50-100 pts/m\u00b2. It is classified in the following classes: ground, low vegetation (2-10m), middle vegetation (10-20m) and high vegetation (20 m and above). It was delivered in the LAS format and had reflectance values 8 in the intensity storage field.","title":"3.1 LiDAR point cloud"},{"location":"PROJ-HETRES/#32-airborne-images","text":"The airborne images have a ground resolution of 3 cm and were acquired simultaneously to the LiDAR dataset. The camera captured the RGB bands, as well as the near infrared (NIR) one. The acquisition of images with a lot of overlap and oblique views allowed the production of a true orthoimage for a perfect match with the LiDAR point cloud and the data of the ground truth.","title":"3.2 Airborne images"},{"location":"PROJ-HETRES/#33-satellite-images","text":"The Sentinel-2 mission from the European Space Agency is passing every 6 days over Switzerland and allows free temporal monitoring at a 10 m resolution. The archives are available back to the beginning of beech tree dieback in 2018.","title":"3.3 Satellite images"},{"location":"PROJ-HETRES/#34-ground-truth","text":"The ground truth was collected between August and October 2022 by foresters. They assessed the health of the beech trees based on four criteria 3 : mortality of branches; transparency of the tree crown; leaf mass partition; trunk condition and other health aspects. In addition, each tree was associated with its coordinates and pictures as illustrated in Figure 1 and Figure 2 respectively. The forester surveyed: 75 healthy, 77 unhealthy and 56 dead trees. Tree locations were first identified in the field with a GPS-enabled tablet on which the 2022 SWISSIMAGE mosaic was displayed. Afterwards, the tree locations were precisely adjusted on the trunk locations by visually locating the corresponding stems in the LiDAR point cloud with the help of the pictures taken in the field. The location and health status of a further 18 beech trees were added in July 2023. These 226 beeches - under which are 76 healthy, 77 affected and 73 dead trees - surveyed at the two dates are defined as the ground truth for this project. Figure 2: Examples of the three health states: left, a healthy tree with a dense green tree crown; center, an unhealthy tree with dead twigs and a scarce foliage; right, a dead tree completely dry.","title":"3.4 Ground truth"},{"location":"PROJ-HETRES/#4-method","text":"The method developed is based on the processing of LiDAR point clouds and of airborne images . Ready-made vegetation indices derived from satellite imagery were also used. First, a segmentation of the trees in the LiDAR point cloud was carried out using the Digital-Forestry-Toolbox (DFT) 11 . Then, descriptors for the health state of the beech trees were derived from each dataset. Boxplots and corresponding t-test are computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes. Finally, the descriptors were used jointly with the ground truth to train a random forest (RF) algorithm, before inferring for the study area. Figure 3: Overview of the methodology, which processes the data into health descriptors for beech trees, before training and evaluating a random forest.","title":"4. Method"},{"location":"PROJ-HETRES/#41-lidar-processing","text":"At the beginning of LiDAR processing, exploration of the data motivated the segmentation and descriptors computation.","title":"4.1 LiDAR processing"},{"location":"PROJ-HETRES/#42-image-processing","text":"For the image processing, an initial step was to compute the normalized difference vegetation index (NDVI) for each raster image. The normalized difference vegetation index (NDVI) is an index commonly used for the estimation of the health state of vegetation 5 13 14 . \\[\\begin{align} \\ NDVI = {NIR-R \\over NIR+R} \\ \\end{align}\\] where NIR and R are the value of the pixel in the near-infrared and red band respectively. To uncover potential distinctive features between the classes, boxplots and principal component analysis were used on the images four bands (RGB-NIR) and the NDVI. Firstly, we tested if the brute pixel values allowed the distinction between classes at a pixel level. This method avoids the pit of the forest segmentation into trees. Secondly, we tested the same method, but with some low-pass filter to reduce the noise in the data. Thirdly, we tried to find distinct statistical features at the tree level. This approach allows decreasing the noise that can be present in high-resolution information. However, it necessitates having a reasonably good segmentation of the trees. Finally, color filtering and edge detection were tested in order to highlight and extract the linear structure of the branches. For each treatment, it is possible to do it with or without a mask on the tree height. As only trees between 20 m and 40 m tall are affected by dieback, a mask based on the Canopy Height Model (CHM) raster derived from the LiDAR point cloud was tested. Figure 4: Overview of different possible data treatments for the the statistical analysis.","title":"4.2 Image processing"},{"location":"PROJ-HETRES/#43-satellite-based-indices","text":"The yearly variation of NDVI and the VHI were used to take account of historical variations of NDVI from 2015 to 2022. For the VHI, the mean for each year is computed over the months considered for the yearly variation of NDVI. The pertinence of using these indices was explored: the values for each tree in the ground truth were extracted and observed in boxplots per health class in 2022 per year pair over the time span from 2015 to 2022.","title":"4.3 Satellite-based indices"},{"location":"PROJ-HETRES/#44-random-forest","text":"In R 12 , the caret and randomForest packages were used to train the random forest and make predictions. First, the ground truth was split into the training and the test datasets, with each class being split 70 % into the training set and 30 % into the test set. Health classes with not enough samples were completed with copies. Optimization of the RF was performed on the number of trees to develop and on the number of randomly sampled descriptors to test at each split. In addition, 5-fold cross-validation was used to ensure the use of different parts of the dataset. The search parameter space was from 100 to 1000 decision trees and from 4 to 10 descriptors as the default value is the square root of all descriptors, i.e. 7. RF was assessed using a custom metric, which is an adaptation of the false positive rate for the healthy class. It minimizes the amount of false healthy detections and of dead trees predicted as unhealthy (false unhealthy). It is called custom false positive rate (cFPR) in the text. It was preferred to have a model with more unhealthy predictions to control on the field, than missing unhealthy or dead trees. The cFPR goes from 0 (best) to 1 (worse). Table 2: Confusion matrix for the three health classes. Ground truth Healthy Unhealthy Dead Prediction Healthy A B C Unhealthy D E F Dead G H I According to the confusion matrix in Table 2, the cFPR is computed as follows: \\[\\begin{align} \\ cFPR = {(\ud835\udc35+\ud835\udc36+\ud835\udc39)\\over(\ud835\udc35+\ud835\udc36+\ud835\udc38+\ud835\udc39+\ud835\udc3b+\ud835\udc3c)}. \\ \\end{align}\\] In addition, the overall accuracy (OA), i.e. the ratio of correct predictions over all the predictions, and the sensitivity, which is, per class, the number of correct predictions divided by the number of samples from that class, are used. An ablation study was performed on descriptors to assess the contribution of the different data sources to the final performance. An \u201cimportant\u201d descriptor is having a strong influence on the increase in prediction errors in the case of random reallocation of the descriptor values in the training set. After the optimization, predictions for each DFT segments were computed using the best model according to the cFPR. The inferences were delivered as a thematic map with colors indicating the health state and hue indicating the fraction of decision trees in the RF having voted for the class (vote fraction). The purpose is to give a confidence information, with high vote fraction indicating robust predictions. Furthermore, the ground truth was evaluated for quantity and quality by two means: Removal of samples and its impact on the metric evaluation Splitting the training set into training subsets to evaluate on the original test set. Finally, after having developed the descriptors and the routine on high-quality data, we downgraded them to have resolutions similar to the ones of the swisstopo products (LiDAR: 20 pt/m 2 , orthoimage: 10 cm) and performed again the optimization and prediction steps. Indeed, the data acquisition was especially commissioned for this project and only covers the study area. If in the future the method should be extended, one would like to test if a lower resolution as the one of the standard national-wide product SWISSIMAGE could be sufficient.","title":"4.4 Random Forest"},{"location":"PROJ-HETRES/#5-results-and-discussion","text":"In this section, the results obtained during the processing of each data source into descriptors are presented and discussed, followed by a section on the random forest results.","title":"5 Results and discussion"},{"location":"PROJ-HETRES/#51-lidar-processing","text":"For the LiDAR data, the reader will first discover the aspect of beech trees in the LiDAR point cloud according to their health state as studied in the data exploration. Then, the segmentation results and the obtained LiDAR-based descriptors will be presented.","title":"5.1 LiDAR processing"},{"location":"PROJ-HETRES/#52-image-processing","text":"Boxplots and PCA are given to illustrate the results of the image processing exploration. As the masking of pixels below and above the affected height made no difference in the interpretation of the results, they are presented here with the height mask.","title":"5.2 Image processing"},{"location":"PROJ-HETRES/#53-vegetation-indices-from-satellite-imagery","text":"The t-test used to evaluate the ability of satellite indices to differentiate between health states are given in Appendices 6 and 7 . In the following two subsections, solely the significant tested groups are mentioned for understanding the RF performance.","title":"5.3 Vegetation indices from satellite imagery"},{"location":"PROJ-HETRES/#54-random-forest","text":"The results of the RF that are presented and discussed are: (1) the optimization and ablation study, (2) the ground truth analysis, (3) the predictions for the AOI and (4) the performance with downgraded data.","title":"5.4 Random Forest"},{"location":"PROJ-HETRES/#6-conclusion-and-outlook","text":"The study has demonstrated the ability of a random forest algorithm to learn from structural descriptors derived from LiDAR point clouds and from vegetation reflectance in airborne and satellite images to predict the health state of beech trees. Depending on the used datasets for training and test, the optimized full model including all descriptors reached an OA of 0.76 or of 0.79, with corresponding cFPR values of 0.13 and 0.14 respectively. These metrics are sufficient for the purpose of prioritizing beech tree felling. The produced map, with the predicted health state and the corresponding votes for the segments, delivers useful information for forest management. The cantonal foresters validated the outcomes of this proof-of-concept and explained how the location of affected beech trees as individuals or as groups are used to target high-priority areas. The full model highlighted the importance of the yearly variation of NDVI between a drought year (2018) and a normal year (2019). The airborne imagery showed good ability to predict dead trees, whereas confusion remained between healthy and unhealthy trees. The quality of the LiDAR point cloud segmentation may explain the limited performance of the LiDAR-based model. Finally, the model trained and tested on downgraded data gave an OA of 0.84 and a cFPR of 0.08. In this model, the airborne-based descriptors gained in importance. It was concluded that a 10 cm resolution may help the model by reducing the noise in the image. Outlooks for improving results include improving the ground truth representativeness of symptoms in the field and continuing research into descriptors for differentiating between healthy and unhealthy trees: For the image processing, suggestions are the integration of more statistics like the skewness and kurtosis of the reflectance as in Junttila et al. (2022) 15 . LiDAR-based descriptors had limited impact on the final results. To better valorize them for an application on beech trees, further research would be needed. Beside producing a cleaner segmentation and finding additional descriptors, it could consist in mixing the descriptors at the different resolutions and, with the help of the importance analysis, estimate at which resolution each descriptor brings the most information to the classification. The results showed the important contribution of vegetation indices derived from satellite imagery reflecting the drought year of 2018. If available, using historical image data of higher resolution to derive more descriptors could help improve individual tree health assessment. The possibility of further developments put aside, the challenge is now the extension of the methodology to a larger area. The simultaneity of the data is necessary to an accurate analysis. It has been shown that the representativeness of the ground truth has to be improved to obtain better and more stable results. Thus, for an extension to further areas, we recommend collecting additional ground truth measurements. The health state of the trees showed some autocorrelation that could have boosted our results and make them less representative of the whole forest. They should be more scattered in the forest. Furthermore, required data are a true orthophoto and a LiDAR point cloud for per-tree analysis. It should be possible to use an old LiDAR acquisition to produce a CHM and renounce to use LiDAR-based descriptors without degrading the performance of the model too much.","title":"6 Conclusion and outlook"},{"location":"PROJ-HETRES/#7-appendixes","text":"","title":"7 Appendixes"},{"location":"PROJ-HETRES/#71-simulation-plan-for-dft-parameter-tuning","text":"Table 8: parameter tuning for DFT. CHM cell size [m] Maxima smoothing Local maxima within search radius 0.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 1.50 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2 2.00 0.1 (3.09632 + 0.00895 * h^2)/2 0.3 (1.7425 * h^0.5566)/2 0.5 (1.2 + 0.16 * h)/2","title":"7.1 Simulation plan for DFT parameter tuning"},{"location":"PROJ-HETRES/#72-t-tests","text":"t-test were computed to evaluate the ability of descriptors to differentiate the three health states. A t-test value below 0.01 indicates that there is a significant difference between the means of two classes.","title":"7.2 t-tests"},{"location":"PROJ-HETRES/#8-sources-and-references","text":"Indications on software and hardware requirements, as well as the code used to perform the project, are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-hetres/tree/main. Other sources of information mentioned in this documentation are listed here: OFEV et al. (\u00e9d.). La canicule et la s\u00e9cheresse de l\u2019\u00e9t\u00e9 2018. Impacts sur l\u2019homme et l\u2019environnement. Technical Report 1909, Office f\u00e9d\u00e9ral de l\u2019environnement, Berne, 2019. \u21a9 \u21a9 Beno\u00eet Grandclement and Daniel Bachmann. 19h30 - En Suisse, la s\u00e9cheresse qui s\u00e9vit depuis plusieurs semaines frappe durement les arbres - Play RTS. February 2023. URL: https://www.rts.ch/play/tv/19h30/video/en-suisse-la-secheresse-qui-sevit-depuis-plusieurs-semaines-frappe-durement-les-arbres?urn=urn:rts:video:13829524 (visited on 2023-03-28). \u21a9 Xavier Gauquelin, editor. Guide de gestion des for\u00eats en crise sanitaire . Office National des For\u00eats, Institut pour le D\u00e9veloppement Forestier, Paris, 2010. ISBN 978-2-84207-344-2. \u21a9 \u21a9 Philipp Brun, Achilleas Psomas, Christian Ginzler, Wilfried Thuiller, Massimiliano Zappa, and Niklaus E. Zimmermann. Large-scale early-wilting response of Central European forests to the 2018 extreme drought. Global Change Biology , 26(12):7021\u20137035, 2020. _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/gcb.15360. URL: https://onlinelibrary.wiley.com/doi/abs/10.1111/gcb.15360 (visited on 2022-10-13), doi:10.1111/gcb.15360 . \u21a9 Run Yu, Youqing Luo, Quan Zhou, Xudong Zhang, Dewei Wu, and Lili Ren. A machine learning algorithm to detect pine wilt disease using UAV-based hyperspectral imagery and LiDAR data at the tree level. International Journal of Applied Earth Observation and Geoinformation , 101:102363, September 2021. URL: https://www.sciencedirect.com/science/article/pii/S0303243421000702 (visited on 2022-10-13), doi:10.1016/j.jag.2021.102363 . \u21a9 \u21a9 \u21a9 Pengyu Meng, Hong Wang, Shuhong Qin, Xiuneng Li, Zhenglin Song, Yicong Wang, Yi Yang, and Jay Gao. Health assessment of plantations based on LiDAR canopy spatial structure parameters. International Journal of Digital Earth , 15(1):712\u2013729, December 2022. URL: https://www.tandfonline.com/doi/full/10.1080/17538947.2022.2059114 (visited on 2022-12-07), doi:10.1080/17538947.2022.2059114 . \u21a9 \u21a9 \u21a9 Patrice Eschmann, Pascal Kohler, Vincent Brahier, and Jo\u00ebl Theubet. La for\u00eat jurassienne en chiffres, R\u00e9sultats et interpr\u00e9tation de l'inventaire forestier cantonal 2003 - 2005. Technical Report, R\u00e9publique et Canton du Jura, St-Ursanne, 2006. URL: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjHuZyfhoSBAxU3hP0HHeBtC4sQFnoECDcQAQ&url=https%3A%2F%2Fwww.jura.ch%2FHtdocs%2FFiles%2FDepartements%2FDEE%2FENV%2FFOR%2FDocuments%2Fpdf%2Frapportinventfor0305.pdf%3Fdownload%3D1&usg=AOvVaw0yr9WOtxMyY-87avVMS9YM&opi=89978449However . \u21a9 \u21a9 Agnieska Ptak. (5) Amplitude vs Reflectance \\textbar LinkedIn. June 2020. URL: https://www.linkedin.com/pulse/amplitude-vs-reflectance-agnieszka-ptak/ (visited on 2023-08-11). \u21a9 BFH-HAFL and BAFU. Waldmonitoring.ch : wcs_ndvi_diff_2016_2015, wcs_ndvi_diff_2017_2016, wcs_ndvi_diff_2018_2017, wcs_ndvi_diff_2019_2018, wcs_ndvi_diff_2020_2019, wcs_ndvi_diff_2021_2020, wcs_ndvi_diff_2022_2021. URL: https://geoserver.karten-werk.ch/wfs?request=GetCapabilities . \u21a9 Reik Leiterer, Gillian Milani, Jan Dirk Wegner, and Christian Ginzler. ExoSilva - ein Multi\u00ad-Sensor\u00ad-Ansatz f\u00fcr ein r\u00e4umlich und zeitlich hochaufgel\u00f6stes Monitoring des Waldzustandes. In Neue Fernerkundungs\u00adtechnologien f\u00fcr die Umweltforschung und Praxis , 17\u201322. Swiss Federal Institute for Forest, Snow and Landscape Research, WSL, April 2023. URL: https://www.dora.lib4ri.ch/wsl/islandora/object/wsl%3A33057 (visited on 2023-11-13), doi:10.55419/wsl:33057 . \u21a9 Matthew Parkan. Mparkan/Digital-Forestry-Toolbox: Initial release. April 2018. URL: https://zenodo.org/record/1213013 (visited on 2023-08-11), doi:10.5281/ZENODO.1213013 . \u21a9 R Core Team. R: A Language and Environment for Statistical Computing. 2023. URL: https://www.R-project.org/ . \u21a9 \u21a9 Olga Brovkina, Emil Cienciala, Peter Surov\u00fd, and P\u0159emysl Janata. Unmanned aerial vehicles (UAV) for assessment of qualitative classification of Norway spruce in temperate forest stands. Geo-spatial Information Science , 21(1):12\u201320, January 2018. URL: https://www.tandfonline.com/doi/full/10.1080/10095020.2017.1416994 (visited on 2022-07-15), doi:10.1080/10095020.2017.1416994 . \u21a9 N.K. Gogoi, Bipul Deka, and L.C. Bora. Remote sensing and its use in detection and monitoring plant diseases: A review. Agricultural Reviews , December 2018. doi:10.18805/ag.R-1835 . \u21a9 Samuli Junttila, Roope N\u00e4si, Niko Koivum\u00e4ki, Mohammad Imangholiloo, Ninni Saarinen, Juha Raisio, Markus Holopainen, Hannu Hyypp\u00e4, Juha Hyypp\u00e4, P\u00e4ivi Lyytik\u00e4inen-Saarenmaa, Mikko Vastaranta, and Eija Honkavaara. Multispectral Imagery Provides Benefits for Mapping Spruce Tree Decline Due to Bark Beetle Infestation When Acquired Late in the Season. Remote Sensing , 14(4):909, February 2022. URL: https://www.mdpi.com/2072-4292/14/4/909 (visited on 2023-10-27), doi:10.3390/rs14040909 . \u21a9","title":"8 Sources and references"},{"location":"PROJ-LANDSTATS/","text":"Using spatio-temporal neighbor data information to detect changes in land use and land cover \u00b6 Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS September 2022 to March 2023 - Published on April 2023 All scripts are available on GitHub . Abstract : From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used. It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation. 1. Introduction \u00b6 The introduction presents the background and the objectives of the projects, but also introduces the input data and its specific features. 1.1 Background \u00b6 Since 1979, the Swiss Federal Statistical Office (FSO) provides detailed and accurate information on the state and evolution of the land use and the land cover in Switzerland. It is a crucial tool for long-term spatial observation. With these statistics, it is possible to determine whether and to what extent changes in land cover and land use are consistent with the goals of Swiss spatial development policies ( FSO ). Figure 1: Visualization of the land cover and land use classification. Every few years, the FSO carries out a survey on aerial or satellite images all over Switzerland. A grid with sample points spaced 100 meters apart overlays the images, providing 4.1 million sample points on which the statistics are based. The classification of the hectare tile is assigned on the center dot, as shown in Figure 1. Currently, a time series of four surveys is accessible, based on aerial images captured in the following years: 1979\u20131985 (1st survey, 1985) 1992\u20131997 (2nd survey, 1997) 2004\u20132009 (3rd survey, 2009) 2013\u20132018 (4th survey, 2018) The first two surveys of the land statistics in 1979 and 1992 were made by visual interpretation of aerial analogue photos using stereoscopes. Since the 2004 survey, the methodology was deeply renewed, in particular through the use of digital aerial photographs, which are observed stereoscopically on workstations using specific photogrammetry software . A new nomenclature (2004 NOAS04) has also been introduced in 2004 which systematically distinguishes 46 land use categories and 27 land cover categories. A numerical label from this catalogue is assigned to each point by a team of trained interpreters. The 1979 and 1992 surveys have been revised according to the nomenclature NOAS04, so that all readings (1979, 1992, 2004, 2013) are comparable. On this page you will find the geodata of the Land Use Statistics at the hectare level since 1979, as well as documentation on the data and the methodology used to produce these data. Detailed information on basic categories and principal domains can be found in Appendix 1 . 1.2 Objectives \u00b6 It is known that manual interpretation work is time-consuming and expensive. However, in a feasibility study , the machine learning technique showed great potential capacity to help speed up the interpretation, especially with deep learning algorithms. According to the study, 50% of the estimated interpretation workload could be saved. Therefore, FSO is currently carrying out a project to assess the relevance of learning and mastering the use of artificial intelligence (AI) technologies to automate (even partially) the interpretation of aerial images for change detection and classification. The project is called Area Statistics Deep Learning (ADELE). FSO had already developed tools for change detection and multi-class classification using the image data. However, the current workflow does not exploit the spatial and temporal dependencies between different points in the surveys. The aim of this project is therefore to evaluate the potential of spatial-temporal neighbors in predicting whether or not points in the land statistics will change class. The methodolgy will be focused on change detection, by finding as many unchanged tiles as possible (automatized capacity) and miss as few changed tiles as possible. The detailed objectives of this project are to: explore the internal transformation patterns of tile classification from a data analytics perspective build a prototype that performs change detection for tiles in the next survey help the domain experts to integrate the prototype within the OFS workflow 1.3 Input data \u00b6 The raw data delivered by the domain experts is a table with 4'163'496 records containing the interpretation results of both land cover and land use from survey 1 to survey 4. An example record is shown in Table 1 and gives following information: RELI: 8-digit number composed by the EAST hectare number concatenated with the NORTH hectare number EAST: EAST coordinates (EPSG:2056) NORTH: NORTH coordinates (EPSG:2056) LUJ: Land Use label for survey J LCJ: Land Cover label for survey J training: value 0 or 1. A value of 1 means that the point can be included in the training or validation set Table 1: Example record of raw data delivered by the domain experts. RELI EAST NORTH LU4* LC4 LU3 LC3 LU2 LC2 LU1 LC1 training 74222228 2742200 1222800 242 21 242 21 242 21 242 21 0 75392541 2753900 1254100 301 41 301 41 301 41 301 41 0 73712628 2737100 1262800 223 46 223 46 223 46 223 46 0 * The shortened LC1/LU1 to LC4/LU4 will be used to simplify the notation of Land Cover/Use of survey 1 to survey 4 in the following documentation. For machine learning, training data quality has strong influence on model performance. With the training label, domain experts from FSO selected data points that are more reliable and representative. These 348'474 tiles and their neighbors composed the training and testing dataset for machine learning methodology. 2. Exploratory data analysis \u00b6 As suggested by domain experts, exploratory data analysis (EDA) is of significance to understand the data statistics and find the potential internal patterns of class transformation. The EDA is implemented from three different perspectives: distribution, quantity and probability. With the combination of the three, we can find that there do exist certain trends in the transformation of both land cover and land use classes. For the land cover, main findings are: distribution: most surface of Switzerland is covered by vegetation or forest, bare land and water areas take up a considerable portion as well, artificial areas take up a small portion of the land cover probability: transformation between some classes had never happened during the past four decades, all classes of land cover are most likely to keep their status rather than to change quantity: there are some clear patterns in quantitative changes Open Forest goes to Closed Forest Brush Meadows go to Shrubs Garden Plants go to Grass and Herb Vegetation Shrubs go to Closed Forest Cluster of Tree goes to Grass and Herb Vegetation For the land use, main findings are: distribution: agricultural and forest areas are the main land uses, unused area also stands out from others classes. probability: transformation between some classes had never happened during the past four decades; on the contrary, construction site, non-exploited urban areas and forest areas tend to change to other classes rather than keep unchanged quantity: the most transformations happened inside the superclasses of Arable and Grassland and of Forest not Agricultural . Readers particularly interested by the change detection methods can directly go to Section 3 ; otherwise, readers are welcomed to read the illustrated and detailed EDA given hereafter. 2.1 Distribution statistics \u00b6 Figure 2: Land cover distribution plot. Figure 3: Land use distribution plot. First, a glance at the overall distribution of land cover and land use is shown in Figure 2 and 3. The X-axis is the label of each class while the Y-axis is the number of tiles in the Log scale. The records of the four surveys are plotted in different colors chronologically. By observation, some trends can be found across the four surveys. Artificial areas only take up a small portion of the land cover (labels between 10 to 20), while most surface of Switzerland is covered by vegetation or forest (20 - 50). Bare land (50 - 60) and water areas (60 - 70) take up a considerable portion as well. For land use, it is obvious that the agricultural (200 - 250) and forest (300 - 310) areas are the main components while the unused area (421) also stands out from others. Most classes kept the same tendency during the past 40 years. There are 11 out of 27 land cover classes and 32 out of 46 land use classes which are continuously increasing or decreasing all the time. Especially for land use, compared with 10 classes rising with time, 22 classes dropping, which indicates that there is some transformation patterns that caused the leakage from some classes to those 10 classes. We will dive into these patterns in the following sections. 2.2 Quantity statistics \u00b6 The data are explored in a quantitative way by three means: visualization of transformations between 2 surveys visualization of sequential transformation over time identifying patterns and most occured transformations in different periods. 2.2.1 Transformation visualization \u00b6 Figure 4: Land cover transformation from 1985 to 2018. The analysis of the transformation patterns in quantitative perspective has been implemented in the interactive visualization in Figure 4. The nodes of the same color belong to a common superclass (principle domain). The size of the node represents the number of tiles for the class and the width of the link reflects the number of transformations in log scale. When hanging over your mouse on these elements, detailed information such as the class label code and the number of transformations will be shown. Clicking the legend will enable you to select the superclasses in which the transformation should be analyzed. Pre-processing had been done for the transformation data. To simplify the graph and stand out the major transformations, links with the number of transformations less than 0.1% of the total were removed from the graph. The filter avoids too many trivial links (580) connecting nearly all the nodes, leaving significant links (112) only. The process filtered 6.5% of the transformations in land cover and 11.5% in land use, which is acceptable considering it is a quantitative analysis focusing on the major transformation. 2.2.2 Sequential transformation visualization \u00b6 Figure 5: Land cover sequential transformation. In addition to the transformation between the 2 surveys, the sequential transformation over time had also been visualized. Here, a similar filter is implemented as well to simplify the result and only tiles that had changed during the 4 surveys are visualized. In Figure 5, the box of a class in column 1985 (survey 1) is composed of different colors while the box of a class in column 2018 (survey 4) only has one color. This is caused by the color of the link showing a kind of sequential transformation. The different colors of a class in the first column show the end status (classification) of the tiles in survey 4. There are some clear patterns we can find in the graph. For example, the red lines point out four diamond patterns in the graph. The diamond pattern with the edges in the same color illustrates the continuous trend that one class of tiles is transferred to the other class. In this figure, it is obvious that the Tree Clusters are degraded to the Grass and Herb , while Grass and Herb are transferred to the Consolidated Surfaces , showing the expansion of urban areas and the destruction to the natural environment. 2.2.3 Quantity statistics analysis \u00b6 Comparing the visualization of different periods, a constant pattern has been spotted in both land cover and land use. For example in land cover, the most transformation happened between the superclass of Tree Vegetation and Brush Vegetation . Also, a visible bi-direction transformation between Grass and Herb Vegetation and Clusters of Trees is witnessed. Greenhouses, wetlands and reedy marshes hardly have edges linked to them all over time, which illustrates that either they have a limited area or they hardly change. A similar property can also be captured in land use classes. The most transformation happened inside the superclass of Arable and Grassland and Forest not Agricultural . Also, a visible transformation from Unused to Forest is highlighted by others. Combining the findings above, it is clear that the transformation related to the Forest and Vegetation is the main part of the story. The forest shrinks or expands over time, changing to shrubs and getting back later. The Arable and Grassland keeps changing based on the need for agriculture or animal husbandry during the survey year. Different kinds of forests interconvert with each other which is a rational natural phenomenon. 2.3 Probability matrix \u00b6 The above analysis demonstrates the occurrence of transformation with quantitative statistics. However, the number of tiles for different classes is not a uniform distribution as shown in the distribution analysis. The largest class is thousands of times more than the smallest one. Sometimes, the quantity of a transformation is trivial compared with the majority, but it is caused by the small amount of tiles for the class. Even if the negligible class would not have a significant impact on the performance of change detection, it is of great importance to reveal the internal transformation pattern of the land statistics and support the multi-class classification task. Therefore, the probability analysis is designed as below: The probability analysis for land cover/use contains 3 parts: The probability matrix presents the probability of transformation from the source class (Y-axis) to the destination class (X-axis). The value of the probability is illustrated by the depth of the color in the log scale. The distribution of the probability that a class does not change, which is a more detailed visualization of the diagonal value of the probability matrix. The distribution of the maximum probability that a class changes to another certain class. This is a deeper inspection to look for a fixed transformation pattern that exists between two classes. The probability is calculated by the status change between the beginning survey and the end survey stated in the figure title. For example Figure 6 is calculated by the transformation between survey 1 and survey 4, without taking into account possible intermediate changes in survey 2 and 3. 2.3.1 Land cover analysis \u00b6 Figure 6: Land cover probability matrix from LC1 to LC4. The first information that the matrix provides is the blank blocks with zero probability of conversion. This discloses that transformation between some classes had never happened during the past four decades. Besides, all the diagonal blocks are with distinct color depth, illustrating that all classes of land cover are most likely to keep their status rather than to change. Another evident features of this matrix are the columns with destination classes Grass and Herb Vegetation (21) and Closed Forest (41) . There are a few classes such as Shrubs (31) , Fruit Tree (33) , Garden Plants (35) and Open Forest (44) which have a noticeable trend to convert to these two classes, which is partially consistent with the quantity analysis while revealing some new findings. Figure 7: Land cover transformation probability without change. When it comes to the refined visualization of the diagonal blocks, it is clear that half of the classes have more than an 80% probability of not transforming, while the minimum one only has about 35%. This is caused by the accumulation of the 4 surveys together which lasts 40 years. For a single decade, as the first 3 sub-graphs of Figure 23 in the Appendix A2.1 , the majority are over 90% probability and the minimum rises to 55%. Figure 8: Maximum transformation probability to a certain class when land cover changes. For those transformed tiles, the maximum probability of converting into another class is shown in Figure 8. This graph together with the matrix in Figure 6 can point out the internal transformation pattern. The top 5 possible transformations between the first survey and the forth survey are: 1. 38% Open Forest (44) --> Closed Forest (41) 2. 36% Brush Meadows (32) --> Shrubs (31) 3. 34% Garden Plants (35) --> Grass and Herb Vegetation (21) 4. 29% Shrubs (31) --> Closed Forest (41) 5. 26% Cluster of Tree (47) --> Grass and Herb Vegetation (21) In this case, the accumulation takes effect as well. For a single decade, the maximum probability decreases to 25%, but the general distribution of the probability is consistent between the four surveys according to Figure 24 in the Appendix A2.1 . 2.3.2 Land use analysis \u00b6 Figure 9: Land use probability matrix from LU1 to LU4. The land use probability matrix has different features compared with the land cover probability matrix. Although most diagonal blocks are with the deepest color depth, there are two areas highlighted by the red line presenting different statistics. The upper area is related to Construction sites (146) and Unexploited Urban areas (147) . These two classes tend to change to other classes rather than keep unchanged, which is reasonable since the construction time of buildings or infrastructures hardly exceeds 10 years. This is confirmed by the left side of the red-edged rectangular block, which has a deeper color depth. This illustrates that construction and unexploited areas ended in the Settlement and Urban Areas (superclass of 100 - 170). The lower red area account for the pattern concerning the Forest Areas (301 -304) . The Afforestation (302) , Lumbering areas (303) and Damaged Forest (304) would thrive and recover between the surveys, and finally become Forest (301) again. Figure 10: Land use transformation probability without change. Figure 10 further validates the assumptions. With most classes with a high probability of not changing, there are two deep valleys for classes 144 to 147 and 302 to 304, which are exactly the results of the stories mentioned above. Figure 11: Maximum transformation probability to a certain class when land use changes. Figure 11 tells the difference in the diversity of transformation destination. The construction and unexploited areas would turn into all kinds of urban areas, with more than 95% changed and the maximum probability to a fixed class is less than 35%. While the Afforestation , Lumbering areas and Damaged Forest returned to Forest with a probability of more than 90%, the transformation pattern within these four classes is fairly fixed. The distribution statistics, the quantity statistics and the probability matrices have shown to validate and complement each other during the exploratory analysis of the data. 3. Methods \u00b6 The developed method should be integrated in the OFS framework for change detection and classification of land use and land cover illustrated in Figure 12. The interesting parts for this project are highlighted in orange and will be presented in the following. Figure 12: Planned structure in FSO framework for final prediction. Figure 12 shows on the left the input data type in the OFS framework. The current project work on the LC/LU neighbors introduced in Section 1.3 . The main objective of the project - to detect change by means of these neighbors - is the temporal-spatial module in Figure 12. As proposed by the feasibility study, FSO had implement studies on change detection and multi-class classification on swisstopo aerial images time series to accelerate the efficiency of the interpretation work. The predicted LC and LU probabilities and information obtained by deep learning are defined as the image-level module. In a second stage of the project, the best model for combining the temporal-spatial and the image-level module outputs is explored to evaluate the gain in performance after integration of the spatial-temporal module in the OFS framework. This is the so-called integration module. The rest of the input data will not be part of the performance evaluation. 3.1 Temporal-spatial module \u00b6 Figure 13: Time and space structure of a tile and its neighbors. The input data to the temporal-spatial module will be the historical interpretation results of the tile to predict and its 8 neighbors. The first three surveys are used as inputs to train the models while the forth survey serves as the ground truth of the prediction. This utilizes both the time and space information in the dataset like depicted in Figure 13. During the preprocessing, the tiles with missing neighbors were discarded from the dataset to keep the data format consistent, which is insignificant (about 400 out of 348'868). The determination of change is influenced by both land cover and land use. When there is a disparity between the classifications in the fourth survey and the third one for a specific tile, it is identified as altered (positive) in change detection. The joint prediction of land cover and land use is based on the assumption that a correlation may exist between them. If the land cover of a tile undergoes a change, it is probable that its land use will also change. Moreover, the tile is assigned numerical labels. Nevertheless, the model does not desire a numerical association between classes, even when they belong to the same superclass and are closely related. To address this, we employ one-hot encoding, which transforms a single land cover column into 26 columns, with all values set to '0' except for one column marked as '1' to indicate the class. Despite increasing the model's complexity with almost two thousand input columns, this is a necessary trade-off to eliminate the risk of numerical misinterpretation. 3.2 Change detection \u00b6 Usually, spatial change detection is a remote sensing application performed on aerial or satellite images for multiclass change detection. However, in this project, a table of point records is used for binary classification into changed and not changed classes. Different traditional and new deep learning approach have been explored to perform this task. The motivations to use them are given hereinafter. An extended version of this section with detailed introduction to the machine learning models is available in Appendix A3 . Three traditional classification models, logistic regression (LR) , XGBoost and random forest (RF) , are tested. The three models represent the most popular approaches in the field - the linear, boosting, and bagging models. In this project, logistic regression is well adapted because it can explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. Concerning XGBoost, it has the advantage that weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling, while misclassified observations would receive extra weight during training. Finally, in random forest, higher accuracy may be obtained and overfitting still avoided through the larger number of trees and the sampling process. Beyond these traditional popular approaches, another two deep learning algorithms are explored as well: fully connected network and convolutional recurrent neural network . Different from the traditional machine learning algorithms, deep learning does not require manual feature extraction or engineering. Deep neural networks capture the desired feature with back-propagation optimization process. Besides, these deep neural networks have some special design for temporal or spatial inputs, because it is assumed that the internal pattern of the dataset would match with the network structure and the model will have better performance. 3.2.1 Focal loss \u00b6 Deep neural networks need differentiable loss function for optimization training. For this project with imbalanced classification task, the local loss was chosen rather than the traditional (binary) cross entropy loss . \\[\\begin{align} \\\\ FL(p_t) = -{\\alpha}(1-p_t)^{\\gamma} \\ log(p_t) \\\\ \\end{align}\\] where \\(p_t\\) is the probability of predicting the correct class, \\(\\alpha\\) is a balance factor between positive and negative classes, and \\(\\gamma\\) is a modulation factor that controls how much weight is given to examples hard to classify. Focal loss is a type of loss function that aims to solve the problem of class imbalance in tasks like classification. Focal loss modifies the cross entropy loss by adding a factor that reduces the loss for easy examples and increases the loss for examples hard to classify. This way, focal loss focuses more on learning from misclassified examples. Compared with other loss functions such as cross entropy, binary cross entropy and dice loss, some advantages of focal loss are: it can reduce the dominance of well-classified examples and prevent them from overwhelming the gradient it can adaptively adjust the weight of each example based on its difficulty level it can improve the accuracy and recall of rare classes by adjusting \\(\\alpha\\) to give more weight to them \\(\\alpha\\) should be chosen based on the class frequency. A common choice is to set \\(\\alpha_t\\) is 1 minus the frequency of class t. This way, rare classes get more weight than frequent classes. \\(\\gamma\\) should be chosen based on how much you want to focus on hard samples. A larger gamma means more focus on hard samples, while a smaller gamma means less focus. The original paper suggested that a gamma equal to 2 is an effective value for most cases. 3.2.2 Fully connected network (FCN) \u00b6 Fully connected network (FCN) in deep learning is a type of neural network that consists of a series of fully connected layers. The major advantage of fully connected networks for this project is that they are structure agnostic. That is, no special assumptions need to be made about the input (for example, that the input consists of images or videos). A disadvantage of FCN is that it can be very computationally expensive and prone to overfitting due to the large number of parameters involved. Another disadvantage is that it does not exploit any spatial or temporal structure in the input data, which can lead to poor performance for some tasks. For implementation, the FCN employ 4 hidden layers (2048, 2048, 1024, 512 neurons respectively) besides the input and output layer. Relu activation function are chosen before the output layer while sigmoid function is applied at the end to scale the result to probability representation. 3.2.3 Convolutional recurrent neural network (ConvRNN) \u00b6 Convolutional recurrent neural network (ConvRNN) is a type of neural network that combines convolutional neural networks (CNNs) and recurrent neural networks (RNNs). CNNs are good at extracting spatial features from images, while RNNs are good at capturing temporal features from sequences. ConvRNNs can be used for tasks that require both spatial and temporal features as it is meant to be achieved in this project. Furthermore, the historical data of the land cover and land use can be translated to some synthetic images. The synthetic images use channels to represent sequence of surveys and the pixel value represents ground truth label. Thus, the spatial relationship of the neighbour tiles could be extracted from the data structure with the CNN. Figure 14: Convolutional Recurrent Neural Network Pipeline. In this project, we explored ConvRNN with structure shown in Figure 14. The sequence of surveys are treated as sequence of input \\(x^t\\) . With the recurrent structure and hidden states \\(h^t\\) to transmit information, the temporal information could be extracted. Different from the traditional RNN, the function \\(f\\) in hidden layers of the recurrent structure use convolutional operation instead of matrix computation and an additional CNN module is applied to the sequence output to detect the spatial information. 3.3 Performance metric \u00b6 Once the different machine learning models are trained for the respective module, comparison has to be made on the test set to evaluate their performance. This will be performed with the help of metrics. 3.3.1 Traditional metrics \u00b6 As discovered in the distribution analysis , the dataset is strongly unbalanced. Some class is thousands of others. This is of importance to change detection. Moreover, among 348'474 tiles in the dataset, only 58'737 (16.86%) tiles have changed. If the overall accuracy is chosen as the performance metric, the biased distribution would make the model tend to predict everything unchanged. In that case, the accuracy of the model can achieve 83.1%, which is a quite high value achieved without any effort. Therefore, avoiding the problem during the model training and selecting the suitable metric that can represent the desired performance are the initial steps. The constant model is defined as a model which predicts the third survey interpretation values as the prediction of the forth survey. In simple words, the constant model predicts that everything does not change. By this definition, we can calculate all kinds of metrics for other change detection models and compare them to the constant model metrics to indentify models with better performance. For change detection with the constant model, the performance is as below: Figure 15: Confusion matrix of constant distribution as prediction: TP=True Positive, TN=True Negative, FP=False Positive, FN=False Negative. Table 2: Metrics evaluation for constant model. Models Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Constant 0.831 0.500 Positive Negative 0.000 0.831 0.000 1.000 0.000 0.907 Definition of abbreviations: For positive case: Precision = TP / (TP + FP) Recall = TP / (TP + FN) (Positive predictive value, PPV) (True positive rate, TPR) For negative case: Precision = TN / (TN + FN) Recall = TN / (TN + FP) (Negative predictive value, NPV) (True negative rate, TNR) Detailed metrics definition can be found here The aim of the change detection is to predict the tiles of high confidence that do not change, so that the interpretation from the last survey can be used directly. However, the negative-case-related metrics above and the accuracy are not suitable for the present task because of the imbalance nature of the problem. Indeed, they indicate a high performance for the constant model, which we know is not depicting the reality, because of the large amount of unchanged tiles. After the test, the balanced accuracy which is the mean of the true positive rate and the true negative rate is considered a suitable metric for change detection. 3.3.2 Specific weighted metric for change detection \u00b6 In theory, true negative rate is equivalent to 1 minus false positive rate. Optimizing balanced accuracy typically results in minimizing the false positive rate. However, our primary objective is to reduce false negative instances (i.e., changed cases labeled as unchanged), while maximizing the true positive rate and true negative rate. False positives are of lesser concern, as they will be manually identified in subsequent steps. Consequently, balanced accuracy does not adequately reflect the project's primary objective. With the help of FSO interpretation team, an additionnal, specific metric targeting on the objective has been designed to measure the model performance. Reminding the Exploratory Data Analysis , some transformation patterns have been found and applied in this metric as well. Figure 16: Workflow with multiple input to define a weighted metric. As depicted in Figure 16, the FSO interpretation team designed two filters to derive a custom metric. The first filter combines inputs from all the possible modules (in this case, the image-level and temporal-spatial modules). The input modules give the probability of change detection or multi-class classification prediction with confidence. As prediction from modules might be different, the first filter will set the final prediction of a tile as positive if any input module gives a positive prediction. Here the threshold to define positive is a significant hyperparameter to finetune. The Weights Matrix defined by the human experts is the core of the entire metric. Based on professional experience and observation of EDA, the experts assigned different weights to all possible transformations. These weights demonstrate the importance of the transformation to the overall statistics. Besides, part of the labels is defined as Small Classes , which means that these classes are negligible or we do not consider them in this study. The second filter removes all the transformations related to the small classes and apply the weights matrix to all the remained tiles. Finally, the weighted metric is calculated as below: \\[\\begin{align} Automatized \\ Tiles &= {\\#Predicted \\ Negatives} \\\\ \\\\ Automatized \\ Capacity &= {{\\#Automatized \\ Tiles} \\over {\\#Negatives \\ (ground \\ truth)}} \\\\ \\\\ Missed \\ Weighted \\ Changed \\ Ratio &= {{\\sum \\{Missed \\ Change \\times Weight\\}} \\over {\\sum \\{All \\ Change \\times Weight\\}}} \\\\ \\\\ Weighted \\ Metric &= Automatized \\ Capacity \\times (0.1 - Missed \\ Weighted \\ Changed \\ Ratio) \\ / \\ 0.1 \\end{align}\\] From now on, we will still calculate metrics like balanced accuracy and recall for reference and analysis; however, the Weighted Metric is the decisive metric for model selection. 3.4 Training and testing plan \u00b6 Introduced in Section 1.3 , the 348'474 tiles with temporal-spatial information are selected for training. The 80%-20% split is applied to the selected tiles to create the train set and the test set respectively. Adam optimizer and multi-step learning rate scheduler are deployed for better convergence. For the temporal-spatial module, metrics for ablation study on the descriptors and descriptor importance are first computed. The descriptor importance is taken from XGBoost simulations. The ablation study is performed with the logistic regression and consists of training the model with: 8 neighbors and time activated, \"baseline\" 4 neighbors (northern, western, southern, eastern neighbors) no spatial-neighbors, \"space deactivate\" no temporal-neighbors, \"time deactivate\" Then, the baseline configuration is used to trained the traditional algorithms and the deep learning ones. Metrics are compared and the best performing models are kept for the integration module. Finally, the performance of several configurations are compared for the integration module. direct outputs of the image-level module direct outputs of the best performing temporal-spatial module outputs of the best performing temporal-spatial module, followed by RF training for the integration module. outputs of the best performing temporal-spatial module, followed by FCN training for the integration module. The extra information gain from the temporal-spatial module will be studied by comparison with image-level performance only. The image-level data contain multi-class classification prediction and its confidence. We can calculate the change probability according to the probability of each class. Therefore, the weighted metric can also be applied at the image-level only. Then, the RF and FCN are tested for the integration module which combines various types of information sources. 4. Experiments \u00b6 The Experiments section covers the results obtained when performing the planned simulations for the temporal-spatial module and the integration module. 4.1 Temporal-spatial module \u00b6 4.1.1 Feature engineering (time and space deactivation) \u00b6 In the temporal-spatial module, the studied models take advantages of both the space (the neighbors) and the time (different surveys) information as introduced in Section 3.1 . Ablation study is performed here to acknowledge the feature importance and which information really matters in the model. Table 3: Model metrics for ablation plan. Logistic Regression Best threshold Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Time deactivate 0.515 0.704 0.718 Positive Negative 0.330 0.930 0.740 0.696 0.457 0.796 Space deactivate 0.505 0.684 0.711 Positive Negative 0.316 0.930 0.752 0.670 0.445 0.779 4 neighbors 0.525 0.707 0.718 Positive Negative 0.332 0.929 0.734 0.701 0.458 0.799 Baseline* 0.525 0.711 0.720 Positive Negative 0.337 0.928 0.734 0.706 0.462 0.802 *Baseline: 8 neighbors with time and space activated Table 3 reveals the performance change when time or space information is totally or partially (4-neighbors instead of 8-neighbors) deactivated. While time deactivation and less-neighbors hardly have an influence on the balanced accuracy (only 0.2% decrease), the one for space deactivation decreased by about 1%. The result demonstrates that space information is more vital to the algorithm than time information, even though both have a minor impact. Figure 17: Feature importance analysis comparasion of 4 (left) and 8 (right) neighbors. Figure 18: Feature importance analysis comparasion of time (left) and space (right) deactivation. Figure 17 and 18 give the feature importance analysis from the XGBoost model. The sum of feature importance from variables all related to the tile itself and its neighbors are plotted in the charts. The 4-neighbor and 8-neighbor have similar capacities but the importance of neighbors for the latter is much more than for the former. This is caused by the number of variables. With more neighbors, the number of variables related to the neighbor increases and the sum of the feature importance grows as well. The feature importance illustrates the weight assigned to the input variables. From Figure 17, it is obvious that the variable related to the tile itself from past surveys is the most critical. Furthermore, the more recent, the more important. The neighbor on the east and west (neighbors 3 and 4) are more significant than others and even more than the land use of the tile in the first survey. In conclusion, the feature importance is not evenly distributed. However, the ablation study shows that the model with all the features as input achieved the best performance. 4.1.2 Baseline models with probability or tree models \u00b6 Utilizing the time and space information from the neighbors, three baseline methods with probability or tree model are fine-tuned. The logistic regression outperforms the other two, achieving 72.0% balanced accuracy. As result, more than 41'000 tiles are correctly predicted as unchanged while only about 3'000 changed tiles are missed as they are the false negatives. Detailed metrics of each method are listed in Table 4. Table 4: Performance metrics for traditional machine learning simulation of spatial-temporal model. Models Accuracy Balanced Accuracy Precision (PPV/NPV) Recall (TPR/TNR) F1-score Logistic Regression 0.711 0.720 Positive Negative 0.337 0.928 0.734 0.706 0.462 0.802 Random Forest 0.847 0.715 Positive Negative 0.775 0.849 0.134 0.992 0.229 0.915 XGBoost 0.837 0.715 Positive Negative 0.533 0.869 0.297 0.947 0.381 0.906 Constant 0.830 0.500 Positive Negative 0.000 0.830 0.000 1.000 0.000 0.907 21: Metric changes with different threshold for logistic regression. Besides the optimal performance with balanced accuracy, logistic regression can manually adjust its ability by changing the decision threshold as its output is the probability to change instead of prediction only. For example, we can trade off between the true positive rate and the negative predictive value. As shown in Figure 19, if we decrease the threshold probability, the precision of the negative case (NPV) will increase while the true negative rate goes down. This means more tiles need manual checks; however, fewer changed tiles are missed. Considering both the performance and the characteristics, Logistic Regression is selected as the baseline model. 4.1.3 Neural networks: FCN and ConvRNN \u00b6 FCN and ConvRNN work differently: FCN does not have special structure designed for temporal-spatial data while ConvRNN has specific designation for time and space information respectively. To study these two extreme situations, we explored their performance and compared with the logistic regression which is the best of the baseline models. Table 5: Performance metrics for deep machine learning simulation of spatial-temporal model Models Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity LR (Macro)* 0.237 0.197 0.655 0.954 349 0.046 18995 0.035 14516 0.364 LR (BA)* 0.249 0.207 0.656 0.957 326 0.043 17028 0.031 14478 0.363 FCN 0.259 0.21 0.656 0.958 322 0.042 15563 0.029 14490 0.363 ConvRNN 0.176 0.133 0.606 0.949 388 0.051 19026 0.035 10838 0.272 Constant -10.717 -10.72 0.500 0.000 7607 1.000 542455 1.00 47491 1.191 *Macro: the model is trained with Macro F1-score ; BA: the model is trained with Balanced Accuracy. As a result of its implementation (see Section 3.2.2 ), FCN outperforms all the models with a value of 0.259 for the weighted metric, slightly above the logistic regression with 0.249. ConvRNN does not perform well even if we have increased the size of hidden states to 1024. Following deliberation, we posit that the absence of one-hot encoding during the generation of synthetic images may be the cause, given that an increased number of channels could substantially explodes computational expenses. Since the ground truth label is directly applied to pixel values, the model may attempt to discern numerical relationships among distinct pixel values that, in reality, do not exist. This warrants further investigation in subsequent phases of our research. 4.2 Integration module \u00b6 Table 5 compares the performance of FCN or image-level only to several configurations for the integration module. Table 5: Performance metrics for the integration model in combination with a spatial-temporal model. Model Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity FCN 0.259 0.210 0.656 0.958 322 0.042 15563 0.029 14490 0.363 image-level 0.374 0.305 0.737 0.958 323 0.042 15735 0.029 20895 0.524 LR + RF 0.434 0.372 0.752 0.969 241 0.031 10810 0.020 21567 0.541 FCN + RF 0.438 0.373 0.757 0.968 250 0.032 11277 0.021 22010 0.552 FCN + FCN 0.438 0.376 0.750 0.970 229 0.030 9902 0.018 21312 0.534 LR + FCN 0.423 0.354 0.745 0.967 255 0.033 10993 0.020 21074 0.528 The study demonstrates that the image-level contains more information related to change detection compared with temporal-spatial neighbors ( FCN row in the Table 5). However, performance improvement from the temporal-spatial module when combined with image-level data, achieving 0.438 in weighted metric in the end ( FCN+RF and FCN+FCN ). Regarding the composition of different models for the two modules, FCN is proved to be the best one for the temporal-spatial module, while RF and FCN have similar performance in the integration module. The choice of integration module could be influenced by the data format of other potential modules. This will be further studied by the FSO team. 5. Conclusion and outlook \u00b6 This project studied the potential of historical and spatial neighbor data in change detection task for the fifth interpretation process of the areal statistic of FSO. For the evaluation of this specific project, a weighted metric was defined by the FSO team. The temporal-spatial information was proved not to be as powerful as image-level information which directly detects change within visual data. However, an efficient prototype was built with 6% performance improvement in weighted metric combining the temporal-spatial module and the image-level module. It is validated that integration of modules with different source information can help to enhance the final capacity of the entire workflow. The next research step of the project would be to modify the current implementation of ConvRNN. If the numerical relationship is removed from the synthetic image data, ConvRNN should have similar performance as FCN theoretically. Also, CNN is worth trying to validate whether the temporal pattern matters in this dataset. Besides, by changing the size of the synthetic images, we can figure out how does the number of neighbour tiles impact the model performance. Appendix \u00b6 A1. Classes of land cover and land use \u00b6 Figure 20: Land Cover classification labels. Figure 21: Land Use classification labels. A2. Probability analysis of different periods \u00b6 A2.1 Land cover \u00b6 Figure 22: Land cover probability matrix. Figure 23: Land cover transformation probability without change. Figure 24: Maximum transformation probability to a certain class when land cover changes. A2.2 Land use \u00b6 Figure 25: Land use probability matrix. Figure 26: Land use transformation probability without change. Figure 27: Maximum transformation probability to a certain class when land use changes. A3 Alternative version of Section 3.2 \u00b6 A3.1 Logistic regression \u00b6 Logistic regression is a kind of Generalized Linear Model . It is the appropriate regression analysis to conduct when the dependent variable is dichotomous (binary). Like all regression analyses, logistic regression is a predictive analysis in this project. Logistic regression is used to describe data and to explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. A3.2 XGBoost & random forest \u00b6 Figure 28: Comparison of boosting and bagging models. XGBoost and Random Forest both originate from the tree model, while one is the sequential variant and the other is the parallel variant. Extreme Gradient Boosting (XGBoost) is a distributed, scalable gradient-boosted decision tree (GBDT) machine learning algorithm. Gradient boosting is a flexible method used for regression, multi-class classification, and other tasks since it is compatible with all kinds of loss functions. It recasts boosting as a numerical optimization problem with the goal of reducing the loss function of the model by adding weak classifiers while employing gradient descent. Later, a first-order iterative approach, gradient descent, is used to find the local optimal of its differentiable function. Weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling while misclassified observations would receive extra weight during training. Random Forest is a bagging technique that contains a number of decision trees generated from the dataset. Instead of relying solely on one decision tree, it takes the average of a number of trees to improve the predictive accuracy. For each tree, the input feature is a different sampled subset from all the features, making the model more robust and avoiding overfitting. Then, these trees are trained with a bootstrapping-sampled subset of the dataset respectively. Finally, the random forest takes the prediction from each tree and based on the majority votes makes the final decision. Higher accuracy is obtained and overfitting is avoided through the larger number of trees and the sampling process. A3.3 Focal loss \u00b6 The next two methods are Deep Neural Networks which need differentiable loss function for optimization training. Here we first tell the difference between the loss function and evaluation metric. The choice of loss function and evaluation metric depends on the task and data. The loss function should be chosen based on whether it is suitable for the model architecture and output type, while the evaluation metric should be relevant for the problem domain and application objectives. The loss function and the evaluation metric are two different concepts in deep learning. The loss function is used to optimize the model parameters during training, while the evaluation metric is used to measure the performance of the model on a test set. The loss function and the evaluation metric may not be the same. For example, Here we use focal loss to train a classification model, but use balanced accuracy or specific defined metric to evaluate its performance. The reason for this is that some evaluation metrics may not be differentiable or easy to optimize, or they may not match with the objective of the model. For this project with imbalanced classification task, we think the Focal Loss is a better choice than the traditional (binary) Cross Entropy Loss. \\[\\begin{align} \\\\ FL(p_t) = -{\\alpha}(1-p_t)^{\\gamma} \\ log(p_t) \\\\ \\end{align}\\] where p_t is the probability of predicting the correct class, \\(\\alpha\\) is a balance factor between positive and negative classes, and \\(\\gamma\\) is a modulation factor that controls how much weight is given to examples hard to classify. Focal loss is a type of loss function that aims to solve the problem of class imbalance in tasks like classification. Focal loss modifies the cross entropy loss by adding a factor that reduces the loss for easy examples and increases the loss for examples hard to classify. This way, focal loss focuses more on learning from misclassified examples. Compared with other loss functions such as cross entropy, binary cross entropy and dice loss, some advantages of focal loss are: It can reduce the dominance of well-classified examples and prevent them from overwhelming the gradient. It can adaptively adjust the weight of each example based on its difficulty level. It can improve the accuracy and recall of rare classes by adjusting \\(\\alpha\\) to give more weight to them. \\(\\alpha\\) should be chosen based on the class frequency. A common choice is to set \\(\\alpha_t\\) = 1 - frequency of class t. This way, rare classes get more weight than frequent classes. \\(\\gamma\\) should be chosen based on how much you want to focus on hard samples. A larger gamma means more focus on hard samples, while a smaller gamma means less focus. The original paper suggested gamma = 2 as an effective value for most cases. A3.4 Fully connected network (FCN) \u00b6 Figure 29: Network structure of FCN. The fully connected network (FCN) in deep learning is a type of neural network that consists of a series of fully connected layers. A fully connected layer is a function from \\(\\mathbb{R}_m\\) to \\(\\mathbb{R}_n\\) that maps each input dimension to each output dimension. The FCN can learn complex patterns and features from data using backpropagation algorithm. The major advantage of fully connected networks is that they are \u201cstructure agnostic.\u201d That is, no special assumptions need to be made about the input (for example, that the input consists of images or videos). Fully connected networks are used for thousands of applications, such as image recognition, natural language processing, and recommender systems. A disadvantage of FCN is that it can be very computationally expensive and prone to overfitting due to the large number of parameters involved. Another disadvantage is that it does not exploit any spatial or temporal structure in the input data, which can lead to poor performance for some tasks. A possible alternative to fully connected network is convolutional neural network (CNN), which uses convolutional layers that apply filters to local regions of the input data, reducing the number of parameters and capturing spatial features. A3.5 Convolutional neural network (CNN) \u00b6 CNN stands for convolutional neural network, which is a type of deep learning neural network designed for processing structured arrays of data such as images. CNNs are very good at detecting patterns in the input data, such as lines, shapes, colors, or even faces and objects. CNNs use a special technique called convolution, which is a mathematical operation that applies a filter (also called a kernel) to each part of the input data and produces an output called a feature map. Convolution helps to extract features from the input data and reduce its dimensionality. CNNs usually have multiple layers of convolution, followed by other types of layers such as pooling (which reduces the size of the feature maps), activation (which adds non-linearity to the network), dropout (which prevents overfitting), and fully connected (which performs classification or regression tasks). CNNs can be trained using backpropagation and gradient descent algorithms. CNNs are widely used in computer vision and have become the state of the art for many visual applications such as image classification, object detection, face recognition, semantic segmentation, etc. They have also been applied to other domains such as natural language processing for text analysis. Figure 30: Workflow of Convolutional Neural Network. In this project, the historical data of the land cover and land use can be translated to some synthetic images. The synthetic images use channels to represent sequence of surveys and the pixel value represents ground truth label. Thus, the spatial relationship of the neighbour tiles could be extracted from the data structure with the CNN. A3.6 Convolutional recurrent neural network (ConvRNN) \u00b6 A convolutional recurrent neural network (ConvRNN) is a type of neural network that combines convolutional neural networks (CNNs) and recurrent neural networks (RNNs). CNNs are good at extracting spatial features from images, while RNNs are good at capturing temporal features from sequences. ConvRNNs can be used for tasks that require both spatial and temporal features, such as image captioning and speech recognition. A ConvRNN consists of two main parts: a CNN part and an RNN part. The CNN part takes an input image or signal and applies convolutional filters to extract features. The RNN part takes these features as a sequence and processes them with recurrent units that have memory. The output of the RNN part can be a single vector or a sequence of vectors, depending on the task. A ConvRNN can learn both spatial and temporal patterns from data that have both dimensions, such as audio signals or video frames. For example, a ConvRNN can detect multiple sound events from an audio signal by extracting frequency features with CNNs and capturing temporal dependencies with RNNs. Figure 31: Convolutional Recurrent Neural Network Pipeline. In this project, we explored ConvRNN with structure shown in Figure 31. The sequence of surveys are treated as sequence of input \\(x^t\\) . With the recurrent structure and hidden states \\(h^t\\) to transmit information, the temporal information could be extracted. Different from the traditional Recurrent Neural Network, the function \\(f\\) in hidden layers of the recurrent structure use Convolutional operation instead of matrix computation and an additional CNN module is applied to the sequence output to detect the spatial information.","title":"Using spatio-temporal neighbor data information to detect changes in land use and land cover"},{"location":"PROJ-LANDSTATS/#using-spatio-temporal-neighbor-data-information-to-detect-changes-in-land-use-and-land-cover","text":"Shanci Li (Uzufly) - Alessandro Cerioni (Canton of Geneva) - Clotilde Marmy (ExoLabs) - Roxane Pott (swisstopo) Proposed by the Swiss Federal Statistical Office - PROJ-LANDSTATS September 2022 to March 2023 - Published on April 2023 All scripts are available on GitHub . Abstract : From 2020 on, the Swiss Federal Statistical Office started to update the land use/cover statistics over Switzerland for the fifth time. To help and lessen the heavy workload of the interpretation process, partially or fully automated approaches are being considered. The goal of this project was to evaluate the role of spatio-temporal neighbors in predicting class changes between two periods for each survey sample point. The methodolgy focused on change detection, by finding as many unchanged tiles as possible and miss as few changed tiles as possible. Logistic regression was used to assess the contribution of spatial and temporal neighbors to the change detection. While time deactivation and less-neighbors have a 0.2% decrease on the balanced accuracy, the space deactivation causes 1% decrease. Furthermore, XGBoost, random forest (RF), fully convolutional network (FCN) and recurrent convolutional neural network (RCNN) performance are compared by the means of a custom metric, established with the help of the interpretation team. For the spatial-temporal module, FCN outperforms all the models with a value of 0.259 for the custom metric, whereas the logistic regression indicates a custom metrics of 0.249. Then, FCN and RF are tested to combine the best performing model with the model trained by OFS on image data only. When using temporal-spatial neighors and image data as inputs, the final integration module achieves 0.438 in custom metric, against 0.374 when only the the image data is used. It was conclude that temporal-spatial neighbors showed that they could light the process of tile interpretation.","title":"Using spatio-temporal neighbor data information to detect changes in land use and land cover"},{"location":"PROJ-LANDSTATS/#1-introduction","text":"The introduction presents the background and the objectives of the projects, but also introduces the input data and its specific features.","title":"1. Introduction"},{"location":"PROJ-LANDSTATS/#11-background","text":"Since 1979, the Swiss Federal Statistical Office (FSO) provides detailed and accurate information on the state and evolution of the land use and the land cover in Switzerland. It is a crucial tool for long-term spatial observation. With these statistics, it is possible to determine whether and to what extent changes in land cover and land use are consistent with the goals of Swiss spatial development policies ( FSO ). Figure 1: Visualization of the land cover and land use classification. Every few years, the FSO carries out a survey on aerial or satellite images all over Switzerland. A grid with sample points spaced 100 meters apart overlays the images, providing 4.1 million sample points on which the statistics are based. The classification of the hectare tile is assigned on the center dot, as shown in Figure 1. Currently, a time series of four surveys is accessible, based on aerial images captured in the following years: 1979\u20131985 (1st survey, 1985) 1992\u20131997 (2nd survey, 1997) 2004\u20132009 (3rd survey, 2009) 2013\u20132018 (4th survey, 2018) The first two surveys of the land statistics in 1979 and 1992 were made by visual interpretation of aerial analogue photos using stereoscopes. Since the 2004 survey, the methodology was deeply renewed, in particular through the use of digital aerial photographs, which are observed stereoscopically on workstations using specific photogrammetry software . A new nomenclature (2004 NOAS04) has also been introduced in 2004 which systematically distinguishes 46 land use categories and 27 land cover categories. A numerical label from this catalogue is assigned to each point by a team of trained interpreters. The 1979 and 1992 surveys have been revised according to the nomenclature NOAS04, so that all readings (1979, 1992, 2004, 2013) are comparable. On this page you will find the geodata of the Land Use Statistics at the hectare level since 1979, as well as documentation on the data and the methodology used to produce these data. Detailed information on basic categories and principal domains can be found in Appendix 1 .","title":"1.1 Background"},{"location":"PROJ-LANDSTATS/#12-objectives","text":"It is known that manual interpretation work is time-consuming and expensive. However, in a feasibility study , the machine learning technique showed great potential capacity to help speed up the interpretation, especially with deep learning algorithms. According to the study, 50% of the estimated interpretation workload could be saved. Therefore, FSO is currently carrying out a project to assess the relevance of learning and mastering the use of artificial intelligence (AI) technologies to automate (even partially) the interpretation of aerial images for change detection and classification. The project is called Area Statistics Deep Learning (ADELE). FSO had already developed tools for change detection and multi-class classification using the image data. However, the current workflow does not exploit the spatial and temporal dependencies between different points in the surveys. The aim of this project is therefore to evaluate the potential of spatial-temporal neighbors in predicting whether or not points in the land statistics will change class. The methodolgy will be focused on change detection, by finding as many unchanged tiles as possible (automatized capacity) and miss as few changed tiles as possible. The detailed objectives of this project are to: explore the internal transformation patterns of tile classification from a data analytics perspective build a prototype that performs change detection for tiles in the next survey help the domain experts to integrate the prototype within the OFS workflow","title":"1.2 Objectives"},{"location":"PROJ-LANDSTATS/#13-input-data","text":"The raw data delivered by the domain experts is a table with 4'163'496 records containing the interpretation results of both land cover and land use from survey 1 to survey 4. An example record is shown in Table 1 and gives following information: RELI: 8-digit number composed by the EAST hectare number concatenated with the NORTH hectare number EAST: EAST coordinates (EPSG:2056) NORTH: NORTH coordinates (EPSG:2056) LUJ: Land Use label for survey J LCJ: Land Cover label for survey J training: value 0 or 1. A value of 1 means that the point can be included in the training or validation set Table 1: Example record of raw data delivered by the domain experts. RELI EAST NORTH LU4* LC4 LU3 LC3 LU2 LC2 LU1 LC1 training 74222228 2742200 1222800 242 21 242 21 242 21 242 21 0 75392541 2753900 1254100 301 41 301 41 301 41 301 41 0 73712628 2737100 1262800 223 46 223 46 223 46 223 46 0 * The shortened LC1/LU1 to LC4/LU4 will be used to simplify the notation of Land Cover/Use of survey 1 to survey 4 in the following documentation. For machine learning, training data quality has strong influence on model performance. With the training label, domain experts from FSO selected data points that are more reliable and representative. These 348'474 tiles and their neighbors composed the training and testing dataset for machine learning methodology.","title":"1.3 Input data"},{"location":"PROJ-LANDSTATS/#2-exploratory-data-analysis","text":"As suggested by domain experts, exploratory data analysis (EDA) is of significance to understand the data statistics and find the potential internal patterns of class transformation. The EDA is implemented from three different perspectives: distribution, quantity and probability. With the combination of the three, we can find that there do exist certain trends in the transformation of both land cover and land use classes. For the land cover, main findings are: distribution: most surface of Switzerland is covered by vegetation or forest, bare land and water areas take up a considerable portion as well, artificial areas take up a small portion of the land cover probability: transformation between some classes had never happened during the past four decades, all classes of land cover are most likely to keep their status rather than to change quantity: there are some clear patterns in quantitative changes Open Forest goes to Closed Forest Brush Meadows go to Shrubs Garden Plants go to Grass and Herb Vegetation Shrubs go to Closed Forest Cluster of Tree goes to Grass and Herb Vegetation For the land use, main findings are: distribution: agricultural and forest areas are the main land uses, unused area also stands out from others classes. probability: transformation between some classes had never happened during the past four decades; on the contrary, construction site, non-exploited urban areas and forest areas tend to change to other classes rather than keep unchanged quantity: the most transformations happened inside the superclasses of Arable and Grassland and of Forest not Agricultural . Readers particularly interested by the change detection methods can directly go to Section 3 ; otherwise, readers are welcomed to read the illustrated and detailed EDA given hereafter.","title":"2. Exploratory data analysis"},{"location":"PROJ-LANDSTATS/#21-distribution-statistics","text":"Figure 2: Land cover distribution plot. Figure 3: Land use distribution plot. First, a glance at the overall distribution of land cover and land use is shown in Figure 2 and 3. The X-axis is the label of each class while the Y-axis is the number of tiles in the Log scale. The records of the four surveys are plotted in different colors chronologically. By observation, some trends can be found across the four surveys. Artificial areas only take up a small portion of the land cover (labels between 10 to 20), while most surface of Switzerland is covered by vegetation or forest (20 - 50). Bare land (50 - 60) and water areas (60 - 70) take up a considerable portion as well. For land use, it is obvious that the agricultural (200 - 250) and forest (300 - 310) areas are the main components while the unused area (421) also stands out from others. Most classes kept the same tendency during the past 40 years. There are 11 out of 27 land cover classes and 32 out of 46 land use classes which are continuously increasing or decreasing all the time. Especially for land use, compared with 10 classes rising with time, 22 classes dropping, which indicates that there is some transformation patterns that caused the leakage from some classes to those 10 classes. We will dive into these patterns in the following sections.","title":"2.1 Distribution statistics"},{"location":"PROJ-LANDSTATS/#22-quantity-statistics","text":"The data are explored in a quantitative way by three means: visualization of transformations between 2 surveys visualization of sequential transformation over time identifying patterns and most occured transformations in different periods.","title":"2.2 Quantity statistics"},{"location":"PROJ-LANDSTATS/#23-probability-matrix","text":"The above analysis demonstrates the occurrence of transformation with quantitative statistics. However, the number of tiles for different classes is not a uniform distribution as shown in the distribution analysis. The largest class is thousands of times more than the smallest one. Sometimes, the quantity of a transformation is trivial compared with the majority, but it is caused by the small amount of tiles for the class. Even if the negligible class would not have a significant impact on the performance of change detection, it is of great importance to reveal the internal transformation pattern of the land statistics and support the multi-class classification task. Therefore, the probability analysis is designed as below: The probability analysis for land cover/use contains 3 parts: The probability matrix presents the probability of transformation from the source class (Y-axis) to the destination class (X-axis). The value of the probability is illustrated by the depth of the color in the log scale. The distribution of the probability that a class does not change, which is a more detailed visualization of the diagonal value of the probability matrix. The distribution of the maximum probability that a class changes to another certain class. This is a deeper inspection to look for a fixed transformation pattern that exists between two classes. The probability is calculated by the status change between the beginning survey and the end survey stated in the figure title. For example Figure 6 is calculated by the transformation between survey 1 and survey 4, without taking into account possible intermediate changes in survey 2 and 3.","title":"2.3 Probability matrix"},{"location":"PROJ-LANDSTATS/#3-methods","text":"The developed method should be integrated in the OFS framework for change detection and classification of land use and land cover illustrated in Figure 12. The interesting parts for this project are highlighted in orange and will be presented in the following. Figure 12: Planned structure in FSO framework for final prediction. Figure 12 shows on the left the input data type in the OFS framework. The current project work on the LC/LU neighbors introduced in Section 1.3 . The main objective of the project - to detect change by means of these neighbors - is the temporal-spatial module in Figure 12. As proposed by the feasibility study, FSO had implement studies on change detection and multi-class classification on swisstopo aerial images time series to accelerate the efficiency of the interpretation work. The predicted LC and LU probabilities and information obtained by deep learning are defined as the image-level module. In a second stage of the project, the best model for combining the temporal-spatial and the image-level module outputs is explored to evaluate the gain in performance after integration of the spatial-temporal module in the OFS framework. This is the so-called integration module. The rest of the input data will not be part of the performance evaluation.","title":"3. Methods"},{"location":"PROJ-LANDSTATS/#31-temporal-spatial-module","text":"Figure 13: Time and space structure of a tile and its neighbors. The input data to the temporal-spatial module will be the historical interpretation results of the tile to predict and its 8 neighbors. The first three surveys are used as inputs to train the models while the forth survey serves as the ground truth of the prediction. This utilizes both the time and space information in the dataset like depicted in Figure 13. During the preprocessing, the tiles with missing neighbors were discarded from the dataset to keep the data format consistent, which is insignificant (about 400 out of 348'868). The determination of change is influenced by both land cover and land use. When there is a disparity between the classifications in the fourth survey and the third one for a specific tile, it is identified as altered (positive) in change detection. The joint prediction of land cover and land use is based on the assumption that a correlation may exist between them. If the land cover of a tile undergoes a change, it is probable that its land use will also change. Moreover, the tile is assigned numerical labels. Nevertheless, the model does not desire a numerical association between classes, even when they belong to the same superclass and are closely related. To address this, we employ one-hot encoding, which transforms a single land cover column into 26 columns, with all values set to '0' except for one column marked as '1' to indicate the class. Despite increasing the model's complexity with almost two thousand input columns, this is a necessary trade-off to eliminate the risk of numerical misinterpretation.","title":"3.1 Temporal-spatial module"},{"location":"PROJ-LANDSTATS/#32-change-detection","text":"Usually, spatial change detection is a remote sensing application performed on aerial or satellite images for multiclass change detection. However, in this project, a table of point records is used for binary classification into changed and not changed classes. Different traditional and new deep learning approach have been explored to perform this task. The motivations to use them are given hereinafter. An extended version of this section with detailed introduction to the machine learning models is available in Appendix A3 . Three traditional classification models, logistic regression (LR) , XGBoost and random forest (RF) , are tested. The three models represent the most popular approaches in the field - the linear, boosting, and bagging models. In this project, logistic regression is well adapted because it can explain the relationship between one dependent binary variable and one or more nominal, ordinal, interval or ratio-level independent variables. Concerning XGBoost, it has the advantage that weaker classifiers are introduced sequentially to focus on the areas where the current model is struggling, while misclassified observations would receive extra weight during training. Finally, in random forest, higher accuracy may be obtained and overfitting still avoided through the larger number of trees and the sampling process. Beyond these traditional popular approaches, another two deep learning algorithms are explored as well: fully connected network and convolutional recurrent neural network . Different from the traditional machine learning algorithms, deep learning does not require manual feature extraction or engineering. Deep neural networks capture the desired feature with back-propagation optimization process. Besides, these deep neural networks have some special design for temporal or spatial inputs, because it is assumed that the internal pattern of the dataset would match with the network structure and the model will have better performance.","title":"3.2 Change detection"},{"location":"PROJ-LANDSTATS/#33-performance-metric","text":"Once the different machine learning models are trained for the respective module, comparison has to be made on the test set to evaluate their performance. This will be performed with the help of metrics.","title":"3.3 Performance metric"},{"location":"PROJ-LANDSTATS/#34-training-and-testing-plan","text":"Introduced in Section 1.3 , the 348'474 tiles with temporal-spatial information are selected for training. The 80%-20% split is applied to the selected tiles to create the train set and the test set respectively. Adam optimizer and multi-step learning rate scheduler are deployed for better convergence. For the temporal-spatial module, metrics for ablation study on the descriptors and descriptor importance are first computed. The descriptor importance is taken from XGBoost simulations. The ablation study is performed with the logistic regression and consists of training the model with: 8 neighbors and time activated, \"baseline\" 4 neighbors (northern, western, southern, eastern neighbors) no spatial-neighbors, \"space deactivate\" no temporal-neighbors, \"time deactivate\" Then, the baseline configuration is used to trained the traditional algorithms and the deep learning ones. Metrics are compared and the best performing models are kept for the integration module. Finally, the performance of several configurations are compared for the integration module. direct outputs of the image-level module direct outputs of the best performing temporal-spatial module outputs of the best performing temporal-spatial module, followed by RF training for the integration module. outputs of the best performing temporal-spatial module, followed by FCN training for the integration module. The extra information gain from the temporal-spatial module will be studied by comparison with image-level performance only. The image-level data contain multi-class classification prediction and its confidence. We can calculate the change probability according to the probability of each class. Therefore, the weighted metric can also be applied at the image-level only. Then, the RF and FCN are tested for the integration module which combines various types of information sources.","title":"3.4 Training and testing plan"},{"location":"PROJ-LANDSTATS/#4-experiments","text":"The Experiments section covers the results obtained when performing the planned simulations for the temporal-spatial module and the integration module.","title":"4. Experiments"},{"location":"PROJ-LANDSTATS/#41-temporal-spatial-module","text":"","title":"4.1 Temporal-spatial module"},{"location":"PROJ-LANDSTATS/#42-integration-module","text":"Table 5 compares the performance of FCN or image-level only to several configurations for the integration module. Table 5: Performance metrics for the integration model in combination with a spatial-temporal model. Model Weighted Metric Raw Metric Balanced Accuracy Recall Missed Changes Missed Changes Ratio Missed Weighted Changes Missed Weighted Changes Ratio Automatized Points Automatized Capacity FCN 0.259 0.210 0.656 0.958 322 0.042 15563 0.029 14490 0.363 image-level 0.374 0.305 0.737 0.958 323 0.042 15735 0.029 20895 0.524 LR + RF 0.434 0.372 0.752 0.969 241 0.031 10810 0.020 21567 0.541 FCN + RF 0.438 0.373 0.757 0.968 250 0.032 11277 0.021 22010 0.552 FCN + FCN 0.438 0.376 0.750 0.970 229 0.030 9902 0.018 21312 0.534 LR + FCN 0.423 0.354 0.745 0.967 255 0.033 10993 0.020 21074 0.528 The study demonstrates that the image-level contains more information related to change detection compared with temporal-spatial neighbors ( FCN row in the Table 5). However, performance improvement from the temporal-spatial module when combined with image-level data, achieving 0.438 in weighted metric in the end ( FCN+RF and FCN+FCN ). Regarding the composition of different models for the two modules, FCN is proved to be the best one for the temporal-spatial module, while RF and FCN have similar performance in the integration module. The choice of integration module could be influenced by the data format of other potential modules. This will be further studied by the FSO team.","title":"4.2 Integration module"},{"location":"PROJ-LANDSTATS/#5-conclusion-and-outlook","text":"This project studied the potential of historical and spatial neighbor data in change detection task for the fifth interpretation process of the areal statistic of FSO. For the evaluation of this specific project, a weighted metric was defined by the FSO team. The temporal-spatial information was proved not to be as powerful as image-level information which directly detects change within visual data. However, an efficient prototype was built with 6% performance improvement in weighted metric combining the temporal-spatial module and the image-level module. It is validated that integration of modules with different source information can help to enhance the final capacity of the entire workflow. The next research step of the project would be to modify the current implementation of ConvRNN. If the numerical relationship is removed from the synthetic image data, ConvRNN should have similar performance as FCN theoretically. Also, CNN is worth trying to validate whether the temporal pattern matters in this dataset. Besides, by changing the size of the synthetic images, we can figure out how does the number of neighbour tiles impact the model performance.","title":"5. Conclusion and outlook"},{"location":"PROJ-LANDSTATS/#appendix","text":"","title":"Appendix"},{"location":"PROJ-LANDSTATS/#a1-classes-of-land-cover-and-land-use","text":"Figure 20: Land Cover classification labels. Figure 21: Land Use classification labels.","title":"A1. Classes of land cover and land use"},{"location":"PROJ-LANDSTATS/#a2-probability-analysis-of-different-periods","text":"","title":"A2. Probability analysis of different periods"},{"location":"PROJ-LANDSTATS/#a3-alternative-version-of-section-32","text":"","title":"A3 Alternative version of Section 3.2"},{"location":"PROJ-REGBL/","text":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL December 2020 to February 2021 - Published on March 2, 2021 Abstract : The Swiss Federal Statistical Office is in charge of the national Register of Buildings and Dwellings (RBD) which keeps track of every existing building in Switzerland. Currently, the register is being completed with buildings in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issues due to missing information and their difficulty to be collected. The construction year of the buildings is one missing information for a large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results. Introduction \u00b6 The Swiss Federal Statistical Office [1] is responsible of maintaining the Federal Register of Buildings and Dwellings ( RBD ) in which a collection of information about buildings and homes are stored. Currently, a completion operation of the register is being conducted to include to it any type of construction on the Swiss territory. Such completion operation comes with many challenges including the gathering of the information related to the construction being currently integrated to the register. In this set of information are the construction years of the buildings. Such information is important to efficiently characterise each Swiss building and to allow the Statistical Office to provide a reliable register to all actors relying on it. The construction year of buildings turns out to be complicated to gather, as adding new buildings to the register already impose an important workload even for the simple information. In addition, in many cases, the construction year of the building is missing or can not be easily collected to update the register. The Statistical Office mandated the STDL to perform researches on the possibility to automatically gather the construction year by analysing the swisstopo [3] National Maps [4]. Indeed, the Swiss national maps are known for their excellency, their availability on any geographical area, and for their temporal cover. The national maps are made with a rigorous and well controlled methodology from the 1950s and therefore they can be used as a reliable source of information to determine the buildings' construction year. The STDL was then responsible for performing the researches and developing a proof-of-concept to provide all the information needed to the Statistical Office for them to take the right decision on considering national maps as a reliable way of assigning a construction year for the buildings lacking information. Research Project Specifications \u00b6 Extracting the construction date out of the national maps is a real challenge, as the national maps are a heavy dataset, they are not easy to be considered as a whole. In addition, the Statistical Office needs the demonstration that it can be done in a reliable way and within a reasonable amount of time to limit the cost of such process. They are also subjected to strict tolerances on the efficiency of the construction years extraction through an automated process. The goal of at least 80 % of overall success was then provided as a constraint to the STDL . As a result, the research specifications for the STDL were: Gathering and understanding the data related to the problem Developing a proof-of-concept demonstrating the possibility to extract the construction years from the national maps Assessing the results with a reliable metric to allow demonstrating the quality and reliability of the obtained construction years Research Data & Selected Areas \u00b6 In this research project, two datasets were considered: the building register itself and the national maps. As both datasets are heavy and complex, considering them entirely for such a research project would have been too complicated and unnecessary. It was then decided to focus on four areas selected for their representativeness of Swiss landscape: Basel (BS): Urban area Bern (BE): Urban and peri-urban area Biasca (TI): Rural and mountainous Caslano (TI): Peri-urban and rural The following images give a geographical illustration of the selected areas through their most recent map: Illustration of the selected areas: Basel (2015), Bern (2010), Biasca (2012) and Caslano (2009) Data: swisstopo Basel was selected as it was one example of an area on which the building register was already well filled in terms of construction years. The four regions are 6km by 6km squared areas which allows up to twenty thousand buildings to be considered on a single one. Federal Register of Buildings and Dwellings \u00b6 The register of buildings is a formal database composed with entries, each of them representing a specific building. Each entry comes with a set of information related to the building they describe. In this project, a sub-set of these informations was considered: Federal identifier of the building (EGID) The position of the building, expressed in the EPGS:2056 (GKODE, GKODN) The building construction year, when available (GBAUJ) The surface of the building, when available, expressed in square metres (GAREA) In addition, tests were conducted by considering the position of the entries of each building. In turned out rapidly that they were not useful in this research project as they were missing on a large fraction on the register and only providing a redundant information according to the position of the buildings. The following table gives a summary of the availability of the construction year in the register according to the selected areas: Area Buildings Available years Missing fraction Basel 17\u2019088 16\u2019584 3% Bern 21\u2019251 4\u2019499 79% Biasca 3\u2019774 1\u2019346 64% Caslano 5\u2019252 2\u2019452 53% One can see that the amount of missing construction year can be large depending on the considered area. National Maps \u00b6 On the side of the national maps, the dataset is more complex. In addition to the large number of available maps, variations of them can also be considered. Indeed, maps are made for different purposes and come with variations in their symbology to emphasise elements on which they focus. Moreover, for modern years, sets of vector data can also be considered in parallel to maps. Vector data are interesting as they allow to directly access the desired information, that is the footprint of the building without any processing required. The drawback of the vector data is their temporal coverage which is limited to the last ten to twenty years. The following images give an illustration of the aspect of the available maps and vector datasets considering the example of the Bern area. Starting with the traditional maps : Available map variations: KOMB, KGRS and KREL - Data: swisstopo and the more specific and vector ones: Available map variations: SITU, GEB and DKM25-GEB (vector) - Data: swisstopo In addition to the number of available variations and data types, they all come with their specific temporal coverage. In the case of this research project, we tried to go back in time as much as possible, simplifying the choice for the older maps. The question still remains for more modern times. As we are mostly interesting in buildings, the availability of already extracted building layers, that can be either raster or vector data, is highly interesting. But the problem of data selection is complex in our case. Indeed, no matter the choice, on the older times, the only available maps have to be considered. In addition to building footprint access, the question of the continuity of the data as to be considered with care. More than building footprints, we are interested in the continuity of these footprints, in order to be able to safely assume the cycle of life of the tracker buildings. This consideration led us to discover variation in methodologies depending on the considered set of data. Indeed, buildings are not shaped in the same way on traditional maps than they are in layer focusing on them. It follows that variation of the symbology, so do the shape of the building, appears between traditional maps and building layers (raster and vector). These variations can lead to shocks going from a map to the one preceding it in time. This can break the continuity of the building footprints along time, making them much more difficult to track safely. This is the reason we choose to focus on the KOMB variation of the maps. These maps are very stable and covers the largest temporal ranges. The methodology was kept very similar along the years, making this dataset much more reliable to work with when the time dimension is considered. Only considering the KOMB variation of the maps also allows to ensure that all source data is treated the same in the processing pipeline, easing the assessment of the results. In addition, the KOMB maps are dense in information and come with colorimetry of their symbology. This opens the possibility to more easily extract the information we need in this project, that are the building footprints. One exception was made concerning the KOMB maps: in their very latest version, the methodology changed, causing the symbology to be different with the older KOMB maps. In their latest version, texts are much more numerous and tend to cover a large amount of the buildings, making them invisible . For this reason, their latest version was dropped, slightly reducing the temporal coverage on the 2015-2020 period. Selecting the KOMB variation allowed us to obtain the following temporal coverage for the four selected areas: Area Oldest map Latest map Mean separation Basel 1955 2015 5.5 Years Bern 1954 2010 5.6 Years Biasca 1970 2012 6.0 Years Caslano 1953 2009 6.2 Years One can see that a large portion of the 20th century can be covered using the maps with a very good resolution of around five to six years between the maps. Research Approaches \u00b6 In this research project, the main focus was put on the national maps to extract the construction year of buildings as the maps are sources on which we can rely and assess the results. The only drawback of the maps is their limited temporal coverage, as they only start to be available in the 1950s . This is the reason why another experimental approach was also added to address the cases of building being built before the 1950s . This secondary approach focused on a statistical methodology to verify to which extent it could be possible to assign a construction date even in the case no maps are available. National Maps : This main approach focuses on the national maps from which the construction year of a building is deduced from a temporal analysis of the maps. Each building is tracked until it disappears or change its shape on a given map allowing to deduce that the construction of the building was made in the gap separating the map and its successor one. Statistical Analysis : This method is based on the principle of spatial dependence and furthermore on concentric zones of urban development. This is technically an interpolator which deduces construction years based first on different searching radii for difference variances, second by splitting the data in quantiles and, finally, by a gaussian mixture model unsupervised learning technique to gather the final predictions. The statistical analysis allows then to consider buildings that were detected on all maps, meaning their construction is older than the oldest available map, to assign them an estimation of their construction year, knowing they had to be older than the oldest map. Research Approach: National Maps \u00b6 In order to detect construction year of buildings, we need to be able to track them down on the maps across the temporal coverage. The RBD is providing the reference list of the building, each coming with a federal identifier ( EGID ) and a position. This position can then be used to track down the building on maps for its appearance or morphological change. As the maps are already selected, as the research areas, this research approach can be summarised in the following way: Translating maps into binary images containing only building Extracting the RBD buildings related to the analysed area Detection procedure of the buildings on the maps Detection of the morphological variation of the buildings Assessment of the obtained results The four first points are related to the development of the proof-of-concept. The last one concern a very sensitive and complicated question relative to the considered problem: how to analyse and assess the obtained results. This question was to most difficult question in this research, and finding a clear and reliable answer is mandatory before to develop anything. For this reason, it is considered in the first place. Reliability of the Data \u00b6 Assessing the results is essentially having a strong reference allowing to compare both in order to obtain a reliable characterisation of the success rate in the deduction of the construction years. This question leads to the discovery that this problem is much more complex that and can appear in the first place. Indeed, we were warned by the Statistical Office that the RBD , considering the construction years it already gives, can be unreliable on some of its portions. This can be explained by the fact that collecting such information is a long and complicated administrative process. As an example, the following image gives an illustration of a building tracked on each of the available selected maps: Temporal track of a selected building On this illustration, one can see two things: the RBD announce a construction year in 1985 ; the maps are clearly indicating something different, locating its construction year between 1963 and 1969 . So both datasets are contradicting each other. In order to solve the contradiction, we manually searched for historical aerial images. The following images illustrate what was found: Aerial view of the building situation: 1963, 1967 and 1987 - Data: swisstopo One can clearly see that the maps seem to give the correct answer concerning the construction date of this specific building, the RBD being contradicted by two other sources. This illustrates the fact that the RBD can not be directly considered as a reliable reference to assess the results. The same question applies for the maps. Even if it is believed that they are highly reliable, one has to be careful with such consideration. Indeed, looking at the following example: Temporal track of a selected building In this case, the RBD gives 1986 as the construction date of the pointed building. The maps are giving a construction year between 1994 and 2000 . Again, the two datasets are contradicting each other. The same procedure was conducted to solve the contradiction: Aerial view of the building situation: 1970, 1986 and 1988 - Data: swisstopo Looking at the aerial images, it seems that the tracked building was there in 1988 . One can see that the map in 1994 continue to represent the four old buildings instead on the new one. It's only in 2000 that the maps are correctly representing the new building. This shows that despite maps are a reliable source of geo-information, they can also be subjected to delay in their symbology. The maps also come with the problem of the consistency of the building footprint symbology. Looking at the following example: Temporal track of a selected building one can see that the maps seem to indicate a strange evolution of the situation: a first building appears in 1987 and it is destroyed and replaced by a larger one in 1993 . Then, this new large building seems to have been destroyed right after its construction to be replaced by a new one in 1998 . Considering aerial images of the building situation: Aerial image view of the building situation: 1981, 1987 and 1993 - Data: swisstopo one can clearly see that a first building was constructed and completed by an extension between 1987 and 1993 . This shows an illustration where the symbology of the building footprints can be subjected to variation than can be de-synchronised regarding the true situation. Metric \u00b6 In such context, neither the RBD or the national maps can be formally considered as a reference. It follows that we are left without a solution to assess our results, and more problematically, without any metric able to guide the developments of the proof-of-concept in the right direction. To solve the situation, one hypothesis is made in this research project. Taking into account both the RBD and the national maps, one can observe that both are built using methodologies that are very different. On one hand, the RBD is built out of a complex administrative process, gathering the required information in a step by step process, going from communes to cantons , and finally to the Statistical Office . On the other hand, the national maps are built using regular aerial image campaigns conducted over the whole Switzerland. The process of establishing maps is quite old and can then be considered as well controlled and stable. Both datasets are then made with methodologies that can be considered as fully independent from each other. This led us to the formulation of our hypothesis: Hypothesis : As the RBD and national maps are the results of independent methodologies, an error in one dataset is very unlikely to compensate an error in the other. In other words, if the RBD and the national maps agree on the construction year of a building, this information can be considered as a reliable reference, as it would be very unlikely to have two errors leading to such agreement. One should remain careful with this hypothesis, despite it sounds reasonable. It would be very difficult to assess it as requiring to gather complex confirmation data that would have to be independent of the RBD , the national maps and the aerial images (as maps are based on them). This assumption is the only one made in this research project. Accepting this assumption leads us to the possibility to establish a formal reference that can be used as a metric to assess the results and to guide the development of the proof-of-concept. But such reference has to be made with care, as the problem remains complex. To illustrate this complexity, the following figure gives a set representation of our problem: Set representation of the RBD completion problem The two rectangles represent the set of buildings for a considered area. On the left, one can see the building set from the RBD point of view. The grey area shows the building without the information of their construction year. Its complementary set is split in two sub-sets that are the buildings having a construction year that is absolutely correct and absolutely incorrect (the limit between both is subject to a bit of interpretation, as the construction year is not a strong concept). If a reference can be extracted, it should be in the green sub-set. The problem is that we have no way of knowing which building are in which sub-set. So the national maps were considered to define another sub-set: the synchronous sub-set where both RBD and national maps agree. To build the metric, the RBD sub-set of buildings coming with the information of the construction year is randomly sub-sampled to extract a representative sub-set: the potentials . This sub-set of potentials is then manually analysed to separate the building on which both datasets agree and to reject the other. At the end of the process, the metric sub-set is obtained and should remain representative. On the right of the set representation is the view of the buildings set through the national maps. One can see that the same sub-set appears but it replaces the construction years by the representation of the building on the maps. The grey part is then representing the building that are not represented on the maps because of their size or because they can be hidden by the symbology for example. The difference is that the maps do not give access to the construction years directly, but they are read from the maps through our developed detector. The detector having a success rate, it cuts the whole set of sub-sets in half, which is exactly what we need for out metric. If the metric sub-set remains representative, the success rate of the detector evaluated on it should generalise to the whole represented buildings. This set representation demonstrates that the problem is very complex and has to be handled with care. Considering only the six most important sub-set and considering construction year are extracted by the detector from the maps, it means that up to 72 specific case can apply on each building randomly selected. To perform the manual selection, a random selection of potential buildings was made on the RBD set of buildings coming with a construction year. The following table summarises the selection and manual validation: Area Potentials Metric Basel 450 EGIDs 209 EGIDs Bern 450 EGIDs 180 EGIDs Biasca 336 EGIDs 209 EGIDs Caslano 450 EGIDs 272 EGIDs The previous table gives the result of the second manual validation. Indeed, two manual validation sessions were made, with several weeks in-between, to check the validation process and how it evolved with the increase of the view of the problem. Three main critics can then be addressed to the metric: the first one is that establishing validation criterion is not simple as the number of cases in which buildings can fall is very high. Understanding the problem takes time and requires to see a lot of these cases. It then follows that the second validation session was more stable and rigorous than the first one. The second critic that can be made on our metric is the selection bias. As the process is made by a human, it is affected by its way of applying the criterion and more specifically on by its severity on their application. Considering the whole potentials sub-set, one can conclude that a few buildings could be rejected and validated depending on the person doing the selection. The last critic concerns specific cases for which the asynchronous criterion to reject them is weak. Indeed, for some buildings, the situation is very unclear in the way the RBD and the maps give information that can not be understood. This is the case for example when the building is not represented on the map. This can be the position in the RBD or the lack of information on the maps that lead to such an unclear situation. These cases are then rejected, but without being fully sure of the asynchronous aspect regarding the maps and the RBD . Methodology \u00b6 With a reliable metric, results can be assessed and the development of the proof-of-concept can be properly guided. As mentioned above, the proof-of-concept can be split in four major steps that are the processing of the maps, the extraction of the RBD buildings, detection of the building on the maps and detection in morphological changes. National Maps Processing \u00b6 In order to perform the detection of building on the maps, a reliable methodology is required. Indeed, one could perform the detection directly on the source maps but this would lead to a complicated process. Indeed, maps are mostly the result of the digitisation of paper maps creating a large number of artefacts on the digital images. This would lead to an unreliable way of detecting building as a complicated decision process would have to be implemented each time a RBD position is checked on each map. A map processing step was then introduced in the first place allowing to translate the color digitised images into reliable binary images on which building detection can be made safely and easily. The goal of this process is then to create a binary version of each map with black pixels indicating the building presence. A method of extracting buildings on maps was then designed. Considering the following example of a map cropped according to a defined geographical area ( Basel ): Example of a considered map: Basel in 2005 and closer view - Data: swisstopo The first step of the map processing methodology is to correct and standardise the exposure of the digitised maps. Indeed, as maps mostly result of a digitisation process, they are subjected to exposure variation due to the digitisation process. A simple standardisation is then applied. The next step consists in black pixel extraction. Each pixel of the input map is tested to determine whether or not it can be considered as black using specific thresholds. As the building are drawn in black, extracting black pixels is a first way of separating the buildings from the rest of the symbology. The following result is obtained: Result of the black extraction process As one can see on the result of the black extraction process, the buildings are still highly connected to other symbological elements and to each others in some cases. Having the building footprints well separated and well defined is an important point for subsequent processes responsible of construction years deduction. To achieve it, two steps are added. The first one uses a variation of the Conway game of life [5] to implement a morphological operator able to disconnect pixel groups. The following image gives the results of this separation process along with the previous black extraction result on which it is based: Result of the morphological operator (right) compare to the previous black extraction (left) As the morphological operator provides the desired result, it also shrinks the footprint of the elements. It allows to eliminate a lot of structures that are not buildings, but it also reduces the footprint of the buildings themselves, which can increase the amount of work to perform by the subsequent processes to properly detect a building. To solve this issue and to obtain building footprints that are as close as possible to the original map, a controlled re-growing step is added. It uses a region threshold and the black extraction result to re-grow the buildings without going any further of their original definition. The following images give a view of the final result along with the original map: Final result of the building footprints extraction (right) compared to the original map As the Conway morphological operator is not able to get rid of all the non-building elements, such as large and bold texts, the re-growing final step also thickening them along with the building footprints. Nevertheless, the obtained binary image is able to keep most of the building footprint intact while eliminating most of the other element of the map as illustrated on the following image: Extracted building footprints, in pink, superimposed on the Bern map The obtained binary images are then used for both detection of building and detection of morphological changes as the building are easy to access and to analyse on such representation. Building Extraction from RBD \u00b6 In the case of limited geographical areas as in this research project, extracting the relevant buildings from the RBD was straightforward. Indeed, the RBD is a simple DSV database that is very easy to understand and to process. The four areas were packed into a single DSV file and the relevant building were selected through a very simple geographical filtering. Each area being defined by a simple geographical square, selecting the buildings was only a question of checking if their position was in the square or not. Building Detection Process \u00b6 Based on the computed binary images, each area can be temporally covered with maps on which building can be detected. Thanks to the processed maps, this detection is made easily, as it was reduced to detect black pixels in a small area around the position of the building provided in the RBD . For each building in the RBD , its detection on each temporal version of the map is made to create a presence table of the building. Such table is simply a Boolean value indicating whether a building was there or not according to the position provided in the RBD . The following images give an illustration of the building detection process on a given temporal version of a selected map: Detection overlay superimposed on its original map (left) and on its binary counterpart (right) One can see that for each building and for each temporal version of the map, the decision of a building presence can be made. At the end of this process, each building is associated to a list of presence at each year corresponding to an available map. Morphological Change Detection \u00b6 Detecting the presence of a building on each temporal version of the map is a first step but is not enough to determine whether or not it is the desired building. Indeed, a building can be replaced by another along the time dimension without creating a discontinuity in the presence timeline. This would lead to misinterpret the presence of building with another one, leading the construction year to be deduced too far in time. This can be illustrated by the following example: Example of building being replaced by another one without introducing a gap in the presence table In case the detection of the presence of the building is not enough to correctly deduce a construction year, a morphological criterion is added. Many different methodologies have been tried in this project, going from signature to various quantities deduce out of the footprint of the building. The most simple and most reliable way was to focus on the pixel count of the building footprint, which corresponds to its surface in geographical terms. A morphological change is considered as the surface of the building footprint changes up to a given threshold along the building presence timeline. In such a case, the presence timeline is broken at the position of the morphological change, interpreting it in the same way as a formal appearance of a building. Introducing such criteria allowed to significantly improve our results, especially in the case of urban centers. Indeed, in modern cities, large number of new buildings were built just after a previous building was being destroyed due to the lack of spaces left for new constructions. Results \u00b6 The developed proof-of-concept is applied on the four selected areas to deduce construction year for each building appearing in the RBD . With the defined metric, it is possible to assess the result in a reliable manner. Nevertheless, assessing the results with clear representations is not straightforward. In this research project, two representations were chosen: Histogram of the success rate : For this representation, the building of the metric are assigned to temporal bins of ten years in size and the success rate of the construction year is computed for each bins. Distance and pseudo-distance distribution : As the previous representation only gives access to a binary view of the results, a distance representation is added to understand to which extent mistakes are made on the deduction of a construction year. For buildings detected between two maps, the temporal middle is assumed as the guessed construction year, allowing to compute a formal distance with its reference. In case a building is detected before or beyond the map range, a pseudo-distance of zero is assigned in case the result is correct according to the reference. Otherwise, the deduced year (that is necessarily between two maps) is compared to its reference extremal map date to obtain an error pseudo-distance. In addition to the manually defined metric, the full RBD metric is also considered. As the construction years provided in the RBD have to be considered with care, as part of them are incorrect, comparing the results obtained the full RBD metric and the metric we manually defined opens the important question of the synchronisation between the maps and the RBD , viewed from the construction perspective. Results: Basel Area \u00b6 The following figures give the Basel area result using the histogram representation. The left plot uses the full RBD metric while the right one uses the manually validated one: Histogram of the success rate - Ten years bins One can see one obvious element that is the result provided by the full RBD metric (left) and the manually validated metric (right) are different. This is a clear sign that the RBD and the maps are de-synchronised on a large fraction of the building set of Basel . The other element that can be seen on the right plot is that the deduction of the construction year are more challenging where maps are available. Indeed on the temporal range covered by the maps (vertical white lines), the results drops from the overall results to 50-60 % on some of the histogram bins. The following figures show the distance and pseudo-distance distribution of the error made on the deduced construction year according to the chosen metric: Distance (red and blue) and pseudo-distance (red) of the error on the construction years The same differences as previously observed between the two metrics can also be seen here. Another important observation is that the distribution seems mostly symmetrical. This indicates that no clear deduction bias can be observed in the results provided by the proof-of-concept. Results: Bern Area \u00b6 The following figures give the histogram view of the results obtained on the Bern area: Histogram of the success rate - Ten years bins One can observe that the results are similar to the result of Basel whilst being a bit better. In addition, one can clearly see that the difference between the full RBD metric and the manually validated metric huge here. This is probably the sign that the RBD is mostly incorrect in the case of Bern . The following figures show the distance distributions for the case of Bern : Distance (red and blue) and pseudo-distance (red) of the error on the construction years Again, the distribution of the error on the deduced construction year is symmetrical in the case of Bern . Results: Biasca Area \u00b6 The following figures give the histogram view of the success rate for the case of Biasca : Histogram of the success rate - Ten years bins In this case, the results are much better according to the manually validated metric. This can be explained by the fact that Biasca is a rural/mountainous area in which growing of the urban areas are much simpler as buildings once built tend to remain unchanged, limiting the difficulty to deduce a reliable construction year. The following figures show the distance distribution for Biasca : Distance (red and blue) and pseudo-distance (red) of the error on the construction years This confirms the results seen on the histogram figure and shows that the results are very good on such areas. Results: Caslano Area \u00b6 Finally, the following figures show the histogram view of the success rate of the proof-of-concept on the case of Caslano : Histogram of the success rate - Ten years bins The same consideration applies as for the Biasca case. The results are very good as part of the Caslano area can be considered as rural or at least peri-urban. The results are a bit less good than in the Biasca case, drawing the picture that urban centres are more difficult to infer than rural areas. The following figures show the error distribution for Caslano : Distance (red and blue) and pseudo-distance (red) of the error on the construction years Results: Synthesis \u00b6 In order to synthesise the previous results, that were a bit dense due to the consideration of two representations and two metrics, the following summary is given: Basel : 78.0% of sucess rate and 80.4% of building correctly placed within \u00b15.5 years Bern : 84.4% of sucess rate and 85.0% of building correctly placed within \u00b15.6 years Biasca : 93.5% of sucess rate and 93.9% of building correctly placed within \u00b16.0 years Caslano : 90.8% of sucess rate and 91.2% of building correctly placed within \u00b16.2 years These results only consider the manually validated metric for all of the four areas. By weighting each area with their amount of buildings, one can deduce the following numbers: Switzerland : 83.9% of success rate and 84.7% of building correctly place within \u00b15.8 years These last numbers can be considered as a reasonable extrapolation of the proof-of-concept performance on the overall Switzerland. Conclusion \u00b6 As a main conclusion to the national maps approach, one can consider the results as good. It was possible to develop a proof-of-concept and to apply it on selected and representative areas of Switzerland. In this approach, it turns out that developing the proof-of-concept was the easy part. Indeed, finding a metric and demonstrating its representativeness and reliability was much more complicated. Indeed, as the two datasets can not be considered as fully reliable in the first place, a strategy had to be defined in order to be able to demonstrate that the chosen metric was able to assess our result in the way expected by the Statistical Office . In addition, the metric only required one additional hypothesis on top of the two datasets. This hypothesis, consisting in assuming that the synchronous sub-set was a quasi-sub-set of the absolutely correct construction years , can be assumed to be reasonable. Nevertheless it is important to emphasise that it was necessary to make it, leading us to remains critic and careful whilst reading the results given by our metric. The developed proof-of-concept was developed in C++ , leading to an efficient code able to be used for the whole processing of Switzerland without the necessity to deeply modify it. Research Approach: Statistical \u00b6 As the availability of the topographic/national maps does not reach the integrity of all building's year of construction in the registry, an add-on was developed to infer this information, whenever there was this need for extrapolation. Usually, the maps availability reaches the 1950s, whilst in some cities the minimum year of construction can be in the order of the 12th century, e.g. The core of this statistical model is based on the Concentric Zones Model (Park and Burgess, 1925)[6] extended to the idea of the growth of the city from the a centre (Central Business District - CBD) to all inner areas. The concept behind this statistical approach can be seen below using the example of a crop of Basel city: Illustration of the Burgess concentric zone model Although it is well known the limits of this model, which are strongly described in other famous urban models such as from Hoyt (1939)[7] and Harris and Ullman (1945)[8]. In general those critics refer to the simplicity of the model, which is considered and compensated for this application, especially by the fact that the main prediction target are older buildings that are assumed to follow the concentric zones pattern, differently than newer ones (Duncan et al., 1962)[9]. Commonly this is the pattern seen in many cities, hence older buildings were built in these circular patterns to some point in time when reconstructions and reforms are almost randomly placed in spatial and temporal terms. Moreover processes like gentrification are shown to be dispersed and quite recent (R\u00e9rat et al, 2010)[10]. In summary, a first predictor is built on the basis that data present a spatial dependence, as in many geostatistical models (Kanevski and Maignan, 2004[11]; Diggle and Ribeiro, 2007[12]; Montero and Mateu, 2015[13]). This way we are assuming that closer buildings are more related to distant buildings (Tobler, 1970[14]) in terms of year of construction and ergo the time dimension is being interpolated based on the principles of spatial models. We are here also demonstrating how those two dimensions interact. After that concentric zones are embedded through the use of quantiles, which values will be using in a probabilistic unsupervised learning technique. Finally, the predicted years are computed from the clusters generated. Metric \u00b6 Similar to the detection situation, generating a validation dataset was an especially challenging task. First of all, the dates in the RBD database could not be trusted in their integrity and the topographic maps used did not reach this time frame. In order to ascertain the construction year in the database, aerial images from swisstopo (Swiss Federal Office of Topography) were consulted and this way buildings were manually selected to compound a validation dataset. References extraction from aerial images manual analysis One of the problems related to this approach was the fact that a gap between the surveys necessary for the images exists. This way it is not able to state with precision the construction date. These gaps between surveys were approximately in the range of 5 years, although in Basel , for some areas, it reached 20 years. An example of this methodology to create a trustworthy validation set can be seen below. In the left-hand side one can see the year of the first image survey (up) and the year registered in the RBD (down) and in the right-hand side, one can see the year of the next image survey in the same temporal resolution. Methodology \u00b6 First of all, a prior searching radius is defined as half of the largest distance (between random variables). For every prediction location, the variance between all points in the prior searching radius will be used to create a posterior searching radius. This way, the higher the variance, the smaller the searching radius, as we tend to trust data less. This is mainly based on the principle of spatial dependence used in many geostatistical interpolators. The exception to this rule is for variances that are higher than 2 x the mean distance between points. In this case, the searching radius increases again in order to avoid clusters of very old houses that during tests caused underestimation. The figure below demonstrates the logic being the creation of searching radii. Searching radii computation process being d the distance between points, \u03bc the mean and s\u00b2 the variance of random variable values within the prior searching radius. It is important to mention that in case of very large number of missing data, if the searching radius does not find enough information, the posterior mean will be the same as the prior mean, possibly causing over/underestimation in those areas. This first procedure is used to fill the gaps in the entry database so clustering can be computed. The next step is then splitting the data in 10 quantiles, what could give the idea of concentric growth zones, inspired, in Burgess Model (1925)[7]. Every point in the database will then assume the value of its quantile. It is also possible to ignore this step and pass to clustering directly, what can be useful in two situations, if a more general purpose is intended or if the concentric zones pattern is not observed in the study area. As default, this step is used, which will be followed by an unsupervised learning technique. A gaussian mixture model, which does not only segments data into clusters, but indicates the probability of each point belonging to every cluster is then performed. The number of components computed is a linear function to the total number of points being used, including the ones that previously had gaps. The function to find the number of components is the following: being np the number of components/clusters, and nc the total number of points used. The number of clusters shall usually be very large compared to a standard clustering exercise. To avoid this, this value is being divided by ten, but the number of clusters will never be smaller than five. An example of clustering performed by the embedded gaussian mixture model can be seen below: Example of clustering process on the Basel area Hence the matrix of probabilities of every point belonging to each cluster (\u03bb - what can be considered a matrix of weights) is multiplied by the mean of each cluster ( 1 x nc matrix mc ), forming the A matrix: or in matrices: Finally, the predictions can then be made using the sum of each row in the A matrix. It is important to state that the same crops (study areas) were used for this test. Although Caslano was not used in this case, as it possesses too few houses with a construction date below the oldest map available. Using the metric above explained a hold out cross-validation was performed, this way a group of points was only used for validation and not for training. After that, the RMSE (Root Mean Squared Error) was calculated using the difference between the date in the RBD database and the predicted one. This RMSE was also extrapolated to the whole Switzerland, so one could have a notion of what the overall error could be, using the following equation (for the expected error): where E is the error and n the number of buildings in each region. In addition to the RMSE , the 95th percentile was computed for every study area and using all combined as well. Hence, one could discuss the spread and predictability of errors. Results \u00b6 The first case analysed was Basel , where the final RMSE was 9.78 years. The density plot below demonstrates the distribution of errors in Basel , considering the difference between the year of construction in the RBD database and the predicted one. Distribution of error on construction year extrapolation Among the evaluated cases, Basel presented a strong visible spatial dependence, and it was also the case which the largest estimated proportion of houses with construction years older than (1955) the oldest map ( 11336 or approximately 66 % of buildings). Based on the validation dataset only, there was an overall trend of underestimation and the 95th percentile reached was 20 years, showing a not so spread and flat distribution of errors. Bern was the second case evaluated, and it demonstrated to be an atypical case. This starts from the fact that a big portion of the dates seemed incongruent with reality, based on the aerial images observed and as seen in the previous detection approach. Not only that, but almost 80 % of the buildings in Bern had missing data to what refers to the year of construction. This is especially complicated as the statistical method here presented is in essence an interpolator (intYEARpolator). Basically, as in any inference problem, data that is known is used to fill unknown data, therefore a reasonable split among known and unknown inputs is expected, as well as a considerable confidence on data. In the other hand, an estimated number of 1079 (approximately 27 % of the buildings) buildings was probably older than the oldest map available (1954) in Bern crop. Therefore, in one way liability was lower in this case, but the number of prediction points was smaller too. The following figure displays the density of errors in Bern, where an RMSE of 20.64 years was computed. Distribution of error on construction year extrapolation There was an overall trend for overestimation, though there was still enough lack of spread in errors, especially if one considers the 95th percentile of 42 . Finally, the crop on Biasca was evaluated. The computed RMSE was of 13.13 years, which is closer to the Basel case and the 95th percentile was 17 years, this way presenting the least spread error distribution. In Biasca an estimated 1007 ( 32 %) buildings were found, which is not much more than the proportion in Bern, but Biasca older topographic map used was from 1970, making of it an especially interesting case. The density plot below demonstrates the concentrated error case of Biasca : Distribution of error on construction year extrapolation Once the RMSE was computed for the three regions, it was extrapolated to the whole Switzerland by making consideration the size of each dataset: Extrapolation of the error distribution on the whole Switzerland The expected extrapolated error calculated was 15.6 years and the 95th percentile was then 31 years. Conclusion \u00b6 This add-on allows extrapolating the predictions to beyond the range of the topographical maps. Its predictions are limited, but the accuracy reached can be considered reasonable, once there is a considerable lack of information in this prediction range. Nor the dates in the RBD , nor the topographic maps can be fully trusted, ergo 15.6 years of error for the older buildings is acceptable, especially by considering the relative lack of spread in errors distribution. If a suggestion for improvement were to be given, a method for smoothing the intYEARpolator predictions could be interesting. This would possibly shift the distribution of the error into closer to a gaussian with mean zero. The dangerous found when searching for such an approach is that the year of construction of buildings does not seem to present a smooth surface, despite the spatial dependence. Hence, if this were to be considered, a balance between smoothing and variability would need to found. We also demonstrated a completely different perspective on how the spatial and temporal dimensions can be joined as the random variable predicted through spatial methodology was actually time. Therefore a strong demonstration of the importance of time in spatially related models and approaches was also given. The code for the intYEARpolator was developed in Python and it runs smoothly even with this quite big proportion of data. The singular case it can be quite time-demanding is in the case of high proportion of prediction points (missing values). It should also be reproducible to the whole Switzerland with no need for modification. A conditional argument is the use of concentric zones, that can be excluded in case of a total different pattern of processing time. Reproduction Resources \u00b6 The source code of the proof-of-concept for national maps can be found here : National maps approach proof-of-concept (regbl-poc), STDL The README provides all the information needed to compile and use the proof-of-concept. The presented results and plots can be computed using the following tools suite : National maps approach results and plots (regbl-poc-analysis), STDL with again the README giving the instructions. The proof-of-concept source code for the statistical approach can be found here : Statistical approach proof-of-concept (regbl-poc-intyearpolator), STDL with its README giving the procedure to follow. The data needed to reproduce the national maps approach are not publicly available. For the national maps, a temporal series of the 1:25'000 maps of the same location are needed. They can be asked to swisstopp : GeoTIFF National Maps 1:25'000 rasters temporal sequence, swisstopo With the maps, you can follow the instruction for cutting and preparing them on the proof-of-concept README . The RBD data, used for both approaches, are not publicly available either. You can query them using the request form on the website of the Federal Statistical Office : DSV RBD data request form , Federal Statistical Office Both proof-of-concepts READMEs provide the required information to use these data. References \u00b6 [1] Federal Statistical Office [2] Federal Register of Buildings and Dwellings [3] Federal Office of Topography [4] National Maps (1:25'000) [5] Conway, J. (1970), The game of life. Scientific American, vol. 223, no 4, p. 4. [6] Park, R. E.; Burgess, E. W. (1925). \"The Growth of the City: An Introduction to a Research Project\". The City (PDF). University of Chicago Press. pp. 47\u201362. ISBN 9780226148199. [7] Hoyt, H. (1939), The structure and growth of residential neighborhoods in American cities (Washington, DC). [8] Harris, C. D., and Ullman, E. L. (1945), \u2018The Nature of Cities\u2019, Annals of the American Academy of Political and Social Science, 242/Nov.: 7\u201317. [9] Duncan, B., Sabagh, G., & Van Arsdol,, M. D. (1962). Patterns of City Growth. American Journal of Sociology, 67(4), 418\u2013429. doi:10.1086/223165 [10] R\u00e9rat, P., S\u00f6derstr\u00f6m, O., Piguet, E., & Besson, R. (2010). From urban wastelands to new\u2010build gentrification: The case of Swiss cities. Population, Space and Place, 16(5), 429-442. [11] Kanevski, M., & Maignan, M. (2004). Analysis and modelling of spatial environmental data (Vol. 6501). EPFL press. [12] Diggle, P. J. Ribeiro Jr., P. J. (2007). Model-based Geostatistics. Springer Series in Statistics. [13] Montero, J. M., & Mateu, J. (2015). Spatial and spatio-temporal geostatistical modeling and kriging (Vol. 998). John Wiley & Sons. [14] Tobler, W. R. (1970). A computer movie simulating urban growth in the Detroit region. Economic geography, 46(sup1), 234-240.","title":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS"},{"location":"PROJ-REGBL/#completion-of-the-federal-register-of-buildings-and-dwellings","text":"Nils Hamel (UNIGE) - Huriel Reichel (swisstopo) Proposed by the Federal Statistical Office - TASK-REGBL December 2020 to February 2021 - Published on March 2, 2021 Abstract : The Swiss Federal Statistical Office is in charge of the national Register of Buildings and Dwellings (RBD) which keeps track of every existing building in Switzerland. Currently, the register is being completed with buildings in addition to regular dwellings to offer a reliable and official source of information. The completion of the register introduced issues due to missing information and their difficulty to be collected. The construction year of the buildings is one missing information for a large amount of register entries. The Statistical Office mandated the STDL to investigate on the possibility to use the Swiss National Maps to extract this missing information using an automated process. A research was conducted in this direction with the development of a proof-of-concept and a reliable methodology to assess the obtained results.","title":"COMPLETION OF THE FEDERAL REGISTER OF BUILDINGS AND DWELLINGS"},{"location":"PROJ-REGBL/#introduction","text":"The Swiss Federal Statistical Office [1] is responsible of maintaining the Federal Register of Buildings and Dwellings ( RBD ) in which a collection of information about buildings and homes are stored. Currently, a completion operation of the register is being conducted to include to it any type of construction on the Swiss territory. Such completion operation comes with many challenges including the gathering of the information related to the construction being currently integrated to the register. In this set of information are the construction years of the buildings. Such information is important to efficiently characterise each Swiss building and to allow the Statistical Office to provide a reliable register to all actors relying on it. The construction year of buildings turns out to be complicated to gather, as adding new buildings to the register already impose an important workload even for the simple information. In addition, in many cases, the construction year of the building is missing or can not be easily collected to update the register. The Statistical Office mandated the STDL to perform researches on the possibility to automatically gather the construction year by analysing the swisstopo [3] National Maps [4]. Indeed, the Swiss national maps are known for their excellency, their availability on any geographical area, and for their temporal cover. The national maps are made with a rigorous and well controlled methodology from the 1950s and therefore they can be used as a reliable source of information to determine the buildings' construction year. The STDL was then responsible for performing the researches and developing a proof-of-concept to provide all the information needed to the Statistical Office for them to take the right decision on considering national maps as a reliable way of assigning a construction year for the buildings lacking information.","title":"Introduction"},{"location":"PROJ-REGBL/#research-project-specifications","text":"Extracting the construction date out of the national maps is a real challenge, as the national maps are a heavy dataset, they are not easy to be considered as a whole. In addition, the Statistical Office needs the demonstration that it can be done in a reliable way and within a reasonable amount of time to limit the cost of such process. They are also subjected to strict tolerances on the efficiency of the construction years extraction through an automated process. The goal of at least 80 % of overall success was then provided as a constraint to the STDL . As a result, the research specifications for the STDL were: Gathering and understanding the data related to the problem Developing a proof-of-concept demonstrating the possibility to extract the construction years from the national maps Assessing the results with a reliable metric to allow demonstrating the quality and reliability of the obtained construction years","title":"Research Project Specifications"},{"location":"PROJ-REGBL/#research-data-selected-areas","text":"In this research project, two datasets were considered: the building register itself and the national maps. As both datasets are heavy and complex, considering them entirely for such a research project would have been too complicated and unnecessary. It was then decided to focus on four areas selected for their representativeness of Swiss landscape: Basel (BS): Urban area Bern (BE): Urban and peri-urban area Biasca (TI): Rural and mountainous Caslano (TI): Peri-urban and rural The following images give a geographical illustration of the selected areas through their most recent map: Illustration of the selected areas: Basel (2015), Bern (2010), Biasca (2012) and Caslano (2009) Data: swisstopo Basel was selected as it was one example of an area on which the building register was already well filled in terms of construction years. The four regions are 6km by 6km squared areas which allows up to twenty thousand buildings to be considered on a single one.","title":"Research Data &amp; Selected Areas"},{"location":"PROJ-REGBL/#federal-register-of-buildings-and-dwellings","text":"The register of buildings is a formal database composed with entries, each of them representing a specific building. Each entry comes with a set of information related to the building they describe. In this project, a sub-set of these informations was considered: Federal identifier of the building (EGID) The position of the building, expressed in the EPGS:2056 (GKODE, GKODN) The building construction year, when available (GBAUJ) The surface of the building, when available, expressed in square metres (GAREA) In addition, tests were conducted by considering the position of the entries of each building. In turned out rapidly that they were not useful in this research project as they were missing on a large fraction on the register and only providing a redundant information according to the position of the buildings. The following table gives a summary of the availability of the construction year in the register according to the selected areas: Area Buildings Available years Missing fraction Basel 17\u2019088 16\u2019584 3% Bern 21\u2019251 4\u2019499 79% Biasca 3\u2019774 1\u2019346 64% Caslano 5\u2019252 2\u2019452 53% One can see that the amount of missing construction year can be large depending on the considered area.","title":"Federal Register of Buildings and Dwellings"},{"location":"PROJ-REGBL/#national-maps","text":"On the side of the national maps, the dataset is more complex. In addition to the large number of available maps, variations of them can also be considered. Indeed, maps are made for different purposes and come with variations in their symbology to emphasise elements on which they focus. Moreover, for modern years, sets of vector data can also be considered in parallel to maps. Vector data are interesting as they allow to directly access the desired information, that is the footprint of the building without any processing required. The drawback of the vector data is their temporal coverage which is limited to the last ten to twenty years. The following images give an illustration of the aspect of the available maps and vector datasets considering the example of the Bern area. Starting with the traditional maps : Available map variations: KOMB, KGRS and KREL - Data: swisstopo and the more specific and vector ones: Available map variations: SITU, GEB and DKM25-GEB (vector) - Data: swisstopo In addition to the number of available variations and data types, they all come with their specific temporal coverage. In the case of this research project, we tried to go back in time as much as possible, simplifying the choice for the older maps. The question still remains for more modern times. As we are mostly interesting in buildings, the availability of already extracted building layers, that can be either raster or vector data, is highly interesting. But the problem of data selection is complex in our case. Indeed, no matter the choice, on the older times, the only available maps have to be considered. In addition to building footprint access, the question of the continuity of the data as to be considered with care. More than building footprints, we are interested in the continuity of these footprints, in order to be able to safely assume the cycle of life of the tracker buildings. This consideration led us to discover variation in methodologies depending on the considered set of data. Indeed, buildings are not shaped in the same way on traditional maps than they are in layer focusing on them. It follows that variation of the symbology, so do the shape of the building, appears between traditional maps and building layers (raster and vector). These variations can lead to shocks going from a map to the one preceding it in time. This can break the continuity of the building footprints along time, making them much more difficult to track safely. This is the reason we choose to focus on the KOMB variation of the maps. These maps are very stable and covers the largest temporal ranges. The methodology was kept very similar along the years, making this dataset much more reliable to work with when the time dimension is considered. Only considering the KOMB variation of the maps also allows to ensure that all source data is treated the same in the processing pipeline, easing the assessment of the results. In addition, the KOMB maps are dense in information and come with colorimetry of their symbology. This opens the possibility to more easily extract the information we need in this project, that are the building footprints. One exception was made concerning the KOMB maps: in their very latest version, the methodology changed, causing the symbology to be different with the older KOMB maps. In their latest version, texts are much more numerous and tend to cover a large amount of the buildings, making them invisible . For this reason, their latest version was dropped, slightly reducing the temporal coverage on the 2015-2020 period. Selecting the KOMB variation allowed us to obtain the following temporal coverage for the four selected areas: Area Oldest map Latest map Mean separation Basel 1955 2015 5.5 Years Bern 1954 2010 5.6 Years Biasca 1970 2012 6.0 Years Caslano 1953 2009 6.2 Years One can see that a large portion of the 20th century can be covered using the maps with a very good resolution of around five to six years between the maps.","title":"National Maps"},{"location":"PROJ-REGBL/#research-approaches","text":"In this research project, the main focus was put on the national maps to extract the construction year of buildings as the maps are sources on which we can rely and assess the results. The only drawback of the maps is their limited temporal coverage, as they only start to be available in the 1950s . This is the reason why another experimental approach was also added to address the cases of building being built before the 1950s . This secondary approach focused on a statistical methodology to verify to which extent it could be possible to assign a construction date even in the case no maps are available. National Maps : This main approach focuses on the national maps from which the construction year of a building is deduced from a temporal analysis of the maps. Each building is tracked until it disappears or change its shape on a given map allowing to deduce that the construction of the building was made in the gap separating the map and its successor one. Statistical Analysis : This method is based on the principle of spatial dependence and furthermore on concentric zones of urban development. This is technically an interpolator which deduces construction years based first on different searching radii for difference variances, second by splitting the data in quantiles and, finally, by a gaussian mixture model unsupervised learning technique to gather the final predictions. The statistical analysis allows then to consider buildings that were detected on all maps, meaning their construction is older than the oldest available map, to assign them an estimation of their construction year, knowing they had to be older than the oldest map.","title":"Research Approaches"},{"location":"PROJ-REGBL/#research-approach-national-maps","text":"In order to detect construction year of buildings, we need to be able to track them down on the maps across the temporal coverage. The RBD is providing the reference list of the building, each coming with a federal identifier ( EGID ) and a position. This position can then be used to track down the building on maps for its appearance or morphological change. As the maps are already selected, as the research areas, this research approach can be summarised in the following way: Translating maps into binary images containing only building Extracting the RBD buildings related to the analysed area Detection procedure of the buildings on the maps Detection of the morphological variation of the buildings Assessment of the obtained results The four first points are related to the development of the proof-of-concept. The last one concern a very sensitive and complicated question relative to the considered problem: how to analyse and assess the obtained results. This question was to most difficult question in this research, and finding a clear and reliable answer is mandatory before to develop anything. For this reason, it is considered in the first place.","title":"Research Approach: National Maps"},{"location":"PROJ-REGBL/#reliability-of-the-data","text":"Assessing the results is essentially having a strong reference allowing to compare both in order to obtain a reliable characterisation of the success rate in the deduction of the construction years. This question leads to the discovery that this problem is much more complex that and can appear in the first place. Indeed, we were warned by the Statistical Office that the RBD , considering the construction years it already gives, can be unreliable on some of its portions. This can be explained by the fact that collecting such information is a long and complicated administrative process. As an example, the following image gives an illustration of a building tracked on each of the available selected maps: Temporal track of a selected building On this illustration, one can see two things: the RBD announce a construction year in 1985 ; the maps are clearly indicating something different, locating its construction year between 1963 and 1969 . So both datasets are contradicting each other. In order to solve the contradiction, we manually searched for historical aerial images. The following images illustrate what was found: Aerial view of the building situation: 1963, 1967 and 1987 - Data: swisstopo One can clearly see that the maps seem to give the correct answer concerning the construction date of this specific building, the RBD being contradicted by two other sources. This illustrates the fact that the RBD can not be directly considered as a reliable reference to assess the results. The same question applies for the maps. Even if it is believed that they are highly reliable, one has to be careful with such consideration. Indeed, looking at the following example: Temporal track of a selected building In this case, the RBD gives 1986 as the construction date of the pointed building. The maps are giving a construction year between 1994 and 2000 . Again, the two datasets are contradicting each other. The same procedure was conducted to solve the contradiction: Aerial view of the building situation: 1970, 1986 and 1988 - Data: swisstopo Looking at the aerial images, it seems that the tracked building was there in 1988 . One can see that the map in 1994 continue to represent the four old buildings instead on the new one. It's only in 2000 that the maps are correctly representing the new building. This shows that despite maps are a reliable source of geo-information, they can also be subjected to delay in their symbology. The maps also come with the problem of the consistency of the building footprint symbology. Looking at the following example: Temporal track of a selected building one can see that the maps seem to indicate a strange evolution of the situation: a first building appears in 1987 and it is destroyed and replaced by a larger one in 1993 . Then, this new large building seems to have been destroyed right after its construction to be replaced by a new one in 1998 . Considering aerial images of the building situation: Aerial image view of the building situation: 1981, 1987 and 1993 - Data: swisstopo one can clearly see that a first building was constructed and completed by an extension between 1987 and 1993 . This shows an illustration where the symbology of the building footprints can be subjected to variation than can be de-synchronised regarding the true situation.","title":"Reliability of the Data"},{"location":"PROJ-REGBL/#metric","text":"In such context, neither the RBD or the national maps can be formally considered as a reference. It follows that we are left without a solution to assess our results, and more problematically, without any metric able to guide the developments of the proof-of-concept in the right direction. To solve the situation, one hypothesis is made in this research project. Taking into account both the RBD and the national maps, one can observe that both are built using methodologies that are very different. On one hand, the RBD is built out of a complex administrative process, gathering the required information in a step by step process, going from communes to cantons , and finally to the Statistical Office . On the other hand, the national maps are built using regular aerial image campaigns conducted over the whole Switzerland. The process of establishing maps is quite old and can then be considered as well controlled and stable. Both datasets are then made with methodologies that can be considered as fully independent from each other. This led us to the formulation of our hypothesis: Hypothesis : As the RBD and national maps are the results of independent methodologies, an error in one dataset is very unlikely to compensate an error in the other. In other words, if the RBD and the national maps agree on the construction year of a building, this information can be considered as a reliable reference, as it would be very unlikely to have two errors leading to such agreement. One should remain careful with this hypothesis, despite it sounds reasonable. It would be very difficult to assess it as requiring to gather complex confirmation data that would have to be independent of the RBD , the national maps and the aerial images (as maps are based on them). This assumption is the only one made in this research project. Accepting this assumption leads us to the possibility to establish a formal reference that can be used as a metric to assess the results and to guide the development of the proof-of-concept. But such reference has to be made with care, as the problem remains complex. To illustrate this complexity, the following figure gives a set representation of our problem: Set representation of the RBD completion problem The two rectangles represent the set of buildings for a considered area. On the left, one can see the building set from the RBD point of view. The grey area shows the building without the information of their construction year. Its complementary set is split in two sub-sets that are the buildings having a construction year that is absolutely correct and absolutely incorrect (the limit between both is subject to a bit of interpretation, as the construction year is not a strong concept). If a reference can be extracted, it should be in the green sub-set. The problem is that we have no way of knowing which building are in which sub-set. So the national maps were considered to define another sub-set: the synchronous sub-set where both RBD and national maps agree. To build the metric, the RBD sub-set of buildings coming with the information of the construction year is randomly sub-sampled to extract a representative sub-set: the potentials . This sub-set of potentials is then manually analysed to separate the building on which both datasets agree and to reject the other. At the end of the process, the metric sub-set is obtained and should remain representative. On the right of the set representation is the view of the buildings set through the national maps. One can see that the same sub-set appears but it replaces the construction years by the representation of the building on the maps. The grey part is then representing the building that are not represented on the maps because of their size or because they can be hidden by the symbology for example. The difference is that the maps do not give access to the construction years directly, but they are read from the maps through our developed detector. The detector having a success rate, it cuts the whole set of sub-sets in half, which is exactly what we need for out metric. If the metric sub-set remains representative, the success rate of the detector evaluated on it should generalise to the whole represented buildings. This set representation demonstrates that the problem is very complex and has to be handled with care. Considering only the six most important sub-set and considering construction year are extracted by the detector from the maps, it means that up to 72 specific case can apply on each building randomly selected. To perform the manual selection, a random selection of potential buildings was made on the RBD set of buildings coming with a construction year. The following table summarises the selection and manual validation: Area Potentials Metric Basel 450 EGIDs 209 EGIDs Bern 450 EGIDs 180 EGIDs Biasca 336 EGIDs 209 EGIDs Caslano 450 EGIDs 272 EGIDs The previous table gives the result of the second manual validation. Indeed, two manual validation sessions were made, with several weeks in-between, to check the validation process and how it evolved with the increase of the view of the problem. Three main critics can then be addressed to the metric: the first one is that establishing validation criterion is not simple as the number of cases in which buildings can fall is very high. Understanding the problem takes time and requires to see a lot of these cases. It then follows that the second validation session was more stable and rigorous than the first one. The second critic that can be made on our metric is the selection bias. As the process is made by a human, it is affected by its way of applying the criterion and more specifically on by its severity on their application. Considering the whole potentials sub-set, one can conclude that a few buildings could be rejected and validated depending on the person doing the selection. The last critic concerns specific cases for which the asynchronous criterion to reject them is weak. Indeed, for some buildings, the situation is very unclear in the way the RBD and the maps give information that can not be understood. This is the case for example when the building is not represented on the map. This can be the position in the RBD or the lack of information on the maps that lead to such an unclear situation. These cases are then rejected, but without being fully sure of the asynchronous aspect regarding the maps and the RBD .","title":"Metric"},{"location":"PROJ-REGBL/#methodology","text":"With a reliable metric, results can be assessed and the development of the proof-of-concept can be properly guided. As mentioned above, the proof-of-concept can be split in four major steps that are the processing of the maps, the extraction of the RBD buildings, detection of the building on the maps and detection in morphological changes.","title":"Methodology"},{"location":"PROJ-REGBL/#results","text":"The developed proof-of-concept is applied on the four selected areas to deduce construction year for each building appearing in the RBD . With the defined metric, it is possible to assess the result in a reliable manner. Nevertheless, assessing the results with clear representations is not straightforward. In this research project, two representations were chosen: Histogram of the success rate : For this representation, the building of the metric are assigned to temporal bins of ten years in size and the success rate of the construction year is computed for each bins. Distance and pseudo-distance distribution : As the previous representation only gives access to a binary view of the results, a distance representation is added to understand to which extent mistakes are made on the deduction of a construction year. For buildings detected between two maps, the temporal middle is assumed as the guessed construction year, allowing to compute a formal distance with its reference. In case a building is detected before or beyond the map range, a pseudo-distance of zero is assigned in case the result is correct according to the reference. Otherwise, the deduced year (that is necessarily between two maps) is compared to its reference extremal map date to obtain an error pseudo-distance. In addition to the manually defined metric, the full RBD metric is also considered. As the construction years provided in the RBD have to be considered with care, as part of them are incorrect, comparing the results obtained the full RBD metric and the metric we manually defined opens the important question of the synchronisation between the maps and the RBD , viewed from the construction perspective.","title":"Results"},{"location":"PROJ-REGBL/#conclusion","text":"As a main conclusion to the national maps approach, one can consider the results as good. It was possible to develop a proof-of-concept and to apply it on selected and representative areas of Switzerland. In this approach, it turns out that developing the proof-of-concept was the easy part. Indeed, finding a metric and demonstrating its representativeness and reliability was much more complicated. Indeed, as the two datasets can not be considered as fully reliable in the first place, a strategy had to be defined in order to be able to demonstrate that the chosen metric was able to assess our result in the way expected by the Statistical Office . In addition, the metric only required one additional hypothesis on top of the two datasets. This hypothesis, consisting in assuming that the synchronous sub-set was a quasi-sub-set of the absolutely correct construction years , can be assumed to be reasonable. Nevertheless it is important to emphasise that it was necessary to make it, leading us to remains critic and careful whilst reading the results given by our metric. The developed proof-of-concept was developed in C++ , leading to an efficient code able to be used for the whole processing of Switzerland without the necessity to deeply modify it.","title":"Conclusion"},{"location":"PROJ-REGBL/#research-approach-statistical","text":"As the availability of the topographic/national maps does not reach the integrity of all building's year of construction in the registry, an add-on was developed to infer this information, whenever there was this need for extrapolation. Usually, the maps availability reaches the 1950s, whilst in some cities the minimum year of construction can be in the order of the 12th century, e.g. The core of this statistical model is based on the Concentric Zones Model (Park and Burgess, 1925)[6] extended to the idea of the growth of the city from the a centre (Central Business District - CBD) to all inner areas. The concept behind this statistical approach can be seen below using the example of a crop of Basel city: Illustration of the Burgess concentric zone model Although it is well known the limits of this model, which are strongly described in other famous urban models such as from Hoyt (1939)[7] and Harris and Ullman (1945)[8]. In general those critics refer to the simplicity of the model, which is considered and compensated for this application, especially by the fact that the main prediction target are older buildings that are assumed to follow the concentric zones pattern, differently than newer ones (Duncan et al., 1962)[9]. Commonly this is the pattern seen in many cities, hence older buildings were built in these circular patterns to some point in time when reconstructions and reforms are almost randomly placed in spatial and temporal terms. Moreover processes like gentrification are shown to be dispersed and quite recent (R\u00e9rat et al, 2010)[10]. In summary, a first predictor is built on the basis that data present a spatial dependence, as in many geostatistical models (Kanevski and Maignan, 2004[11]; Diggle and Ribeiro, 2007[12]; Montero and Mateu, 2015[13]). This way we are assuming that closer buildings are more related to distant buildings (Tobler, 1970[14]) in terms of year of construction and ergo the time dimension is being interpolated based on the principles of spatial models. We are here also demonstrating how those two dimensions interact. After that concentric zones are embedded through the use of quantiles, which values will be using in a probabilistic unsupervised learning technique. Finally, the predicted years are computed from the clusters generated.","title":"Research Approach: Statistical"},{"location":"PROJ-REGBL/#metric_1","text":"Similar to the detection situation, generating a validation dataset was an especially challenging task. First of all, the dates in the RBD database could not be trusted in their integrity and the topographic maps used did not reach this time frame. In order to ascertain the construction year in the database, aerial images from swisstopo (Swiss Federal Office of Topography) were consulted and this way buildings were manually selected to compound a validation dataset. References extraction from aerial images manual analysis One of the problems related to this approach was the fact that a gap between the surveys necessary for the images exists. This way it is not able to state with precision the construction date. These gaps between surveys were approximately in the range of 5 years, although in Basel , for some areas, it reached 20 years. An example of this methodology to create a trustworthy validation set can be seen below. In the left-hand side one can see the year of the first image survey (up) and the year registered in the RBD (down) and in the right-hand side, one can see the year of the next image survey in the same temporal resolution.","title":"Metric"},{"location":"PROJ-REGBL/#methodology_1","text":"First of all, a prior searching radius is defined as half of the largest distance (between random variables). For every prediction location, the variance between all points in the prior searching radius will be used to create a posterior searching radius. This way, the higher the variance, the smaller the searching radius, as we tend to trust data less. This is mainly based on the principle of spatial dependence used in many geostatistical interpolators. The exception to this rule is for variances that are higher than 2 x the mean distance between points. In this case, the searching radius increases again in order to avoid clusters of very old houses that during tests caused underestimation. The figure below demonstrates the logic being the creation of searching radii. Searching radii computation process being d the distance between points, \u03bc the mean and s\u00b2 the variance of random variable values within the prior searching radius. It is important to mention that in case of very large number of missing data, if the searching radius does not find enough information, the posterior mean will be the same as the prior mean, possibly causing over/underestimation in those areas. This first procedure is used to fill the gaps in the entry database so clustering can be computed. The next step is then splitting the data in 10 quantiles, what could give the idea of concentric growth zones, inspired, in Burgess Model (1925)[7]. Every point in the database will then assume the value of its quantile. It is also possible to ignore this step and pass to clustering directly, what can be useful in two situations, if a more general purpose is intended or if the concentric zones pattern is not observed in the study area. As default, this step is used, which will be followed by an unsupervised learning technique. A gaussian mixture model, which does not only segments data into clusters, but indicates the probability of each point belonging to every cluster is then performed. The number of components computed is a linear function to the total number of points being used, including the ones that previously had gaps. The function to find the number of components is the following: being np the number of components/clusters, and nc the total number of points used. The number of clusters shall usually be very large compared to a standard clustering exercise. To avoid this, this value is being divided by ten, but the number of clusters will never be smaller than five. An example of clustering performed by the embedded gaussian mixture model can be seen below: Example of clustering process on the Basel area Hence the matrix of probabilities of every point belonging to each cluster (\u03bb - what can be considered a matrix of weights) is multiplied by the mean of each cluster ( 1 x nc matrix mc ), forming the A matrix: or in matrices: Finally, the predictions can then be made using the sum of each row in the A matrix. It is important to state that the same crops (study areas) were used for this test. Although Caslano was not used in this case, as it possesses too few houses with a construction date below the oldest map available. Using the metric above explained a hold out cross-validation was performed, this way a group of points was only used for validation and not for training. After that, the RMSE (Root Mean Squared Error) was calculated using the difference between the date in the RBD database and the predicted one. This RMSE was also extrapolated to the whole Switzerland, so one could have a notion of what the overall error could be, using the following equation (for the expected error): where E is the error and n the number of buildings in each region. In addition to the RMSE , the 95th percentile was computed for every study area and using all combined as well. Hence, one could discuss the spread and predictability of errors.","title":"Methodology"},{"location":"PROJ-REGBL/#results_1","text":"The first case analysed was Basel , where the final RMSE was 9.78 years. The density plot below demonstrates the distribution of errors in Basel , considering the difference between the year of construction in the RBD database and the predicted one. Distribution of error on construction year extrapolation Among the evaluated cases, Basel presented a strong visible spatial dependence, and it was also the case which the largest estimated proportion of houses with construction years older than (1955) the oldest map ( 11336 or approximately 66 % of buildings). Based on the validation dataset only, there was an overall trend of underestimation and the 95th percentile reached was 20 years, showing a not so spread and flat distribution of errors. Bern was the second case evaluated, and it demonstrated to be an atypical case. This starts from the fact that a big portion of the dates seemed incongruent with reality, based on the aerial images observed and as seen in the previous detection approach. Not only that, but almost 80 % of the buildings in Bern had missing data to what refers to the year of construction. This is especially complicated as the statistical method here presented is in essence an interpolator (intYEARpolator). Basically, as in any inference problem, data that is known is used to fill unknown data, therefore a reasonable split among known and unknown inputs is expected, as well as a considerable confidence on data. In the other hand, an estimated number of 1079 (approximately 27 % of the buildings) buildings was probably older than the oldest map available (1954) in Bern crop. Therefore, in one way liability was lower in this case, but the number of prediction points was smaller too. The following figure displays the density of errors in Bern, where an RMSE of 20.64 years was computed. Distribution of error on construction year extrapolation There was an overall trend for overestimation, though there was still enough lack of spread in errors, especially if one considers the 95th percentile of 42 . Finally, the crop on Biasca was evaluated. The computed RMSE was of 13.13 years, which is closer to the Basel case and the 95th percentile was 17 years, this way presenting the least spread error distribution. In Biasca an estimated 1007 ( 32 %) buildings were found, which is not much more than the proportion in Bern, but Biasca older topographic map used was from 1970, making of it an especially interesting case. The density plot below demonstrates the concentrated error case of Biasca : Distribution of error on construction year extrapolation Once the RMSE was computed for the three regions, it was extrapolated to the whole Switzerland by making consideration the size of each dataset: Extrapolation of the error distribution on the whole Switzerland The expected extrapolated error calculated was 15.6 years and the 95th percentile was then 31 years.","title":"Results"},{"location":"PROJ-REGBL/#conclusion_1","text":"This add-on allows extrapolating the predictions to beyond the range of the topographical maps. Its predictions are limited, but the accuracy reached can be considered reasonable, once there is a considerable lack of information in this prediction range. Nor the dates in the RBD , nor the topographic maps can be fully trusted, ergo 15.6 years of error for the older buildings is acceptable, especially by considering the relative lack of spread in errors distribution. If a suggestion for improvement were to be given, a method for smoothing the intYEARpolator predictions could be interesting. This would possibly shift the distribution of the error into closer to a gaussian with mean zero. The dangerous found when searching for such an approach is that the year of construction of buildings does not seem to present a smooth surface, despite the spatial dependence. Hence, if this were to be considered, a balance between smoothing and variability would need to found. We also demonstrated a completely different perspective on how the spatial and temporal dimensions can be joined as the random variable predicted through spatial methodology was actually time. Therefore a strong demonstration of the importance of time in spatially related models and approaches was also given. The code for the intYEARpolator was developed in Python and it runs smoothly even with this quite big proportion of data. The singular case it can be quite time-demanding is in the case of high proportion of prediction points (missing values). It should also be reproducible to the whole Switzerland with no need for modification. A conditional argument is the use of concentric zones, that can be excluded in case of a total different pattern of processing time.","title":"Conclusion"},{"location":"PROJ-REGBL/#reproduction-resources","text":"The source code of the proof-of-concept for national maps can be found here : National maps approach proof-of-concept (regbl-poc), STDL The README provides all the information needed to compile and use the proof-of-concept. The presented results and plots can be computed using the following tools suite : National maps approach results and plots (regbl-poc-analysis), STDL with again the README giving the instructions. The proof-of-concept source code for the statistical approach can be found here : Statistical approach proof-of-concept (regbl-poc-intyearpolator), STDL with its README giving the procedure to follow. The data needed to reproduce the national maps approach are not publicly available. For the national maps, a temporal series of the 1:25'000 maps of the same location are needed. They can be asked to swisstopp : GeoTIFF National Maps 1:25'000 rasters temporal sequence, swisstopo With the maps, you can follow the instruction for cutting and preparing them on the proof-of-concept README . The RBD data, used for both approaches, are not publicly available either. You can query them using the request form on the website of the Federal Statistical Office : DSV RBD data request form , Federal Statistical Office Both proof-of-concepts READMEs provide the required information to use these data.","title":"Reproduction Resources"},{"location":"PROJ-REGBL/#references","text":"[1] Federal Statistical Office [2] Federal Register of Buildings and Dwellings [3] Federal Office of Topography [4] National Maps (1:25'000) [5] Conway, J. (1970), The game of life. Scientific American, vol. 223, no 4, p. 4. [6] Park, R. E.; Burgess, E. W. (1925). \"The Growth of the City: An Introduction to a Research Project\". The City (PDF). University of Chicago Press. pp. 47\u201362. ISBN 9780226148199. [7] Hoyt, H. (1939), The structure and growth of residential neighborhoods in American cities (Washington, DC). [8] Harris, C. D., and Ullman, E. L. (1945), \u2018The Nature of Cities\u2019, Annals of the American Academy of Political and Social Science, 242/Nov.: 7\u201317. [9] Duncan, B., Sabagh, G., & Van Arsdol,, M. D. (1962). Patterns of City Growth. American Journal of Sociology, 67(4), 418\u2013429. doi:10.1086/223165 [10] R\u00e9rat, P., S\u00f6derstr\u00f6m, O., Piguet, E., & Besson, R. (2010). From urban wastelands to new\u2010build gentrification: The case of Swiss cities. Population, Space and Place, 16(5), 429-442. [11] Kanevski, M., & Maignan, M. (2004). Analysis and modelling of spatial environmental data (Vol. 6501). EPFL press. [12] Diggle, P. J. Ribeiro Jr., P. J. (2007). Model-based Geostatistics. Springer Series in Statistics. [13] Montero, J. M., & Mateu, J. (2015). Spatial and spatio-temporal geostatistical modeling and kriging (Vol. 998). John Wiley & Sons. [14] Tobler, W. R. (1970). A computer movie simulating urban growth in the Detroit region. Economic geography, 46(sup1), 234-240.","title":"References"},{"location":"PROJ-ROADSURF/","text":"Classification of road surfaces \u00b6 Gwena\u00eblle Salamin (swisstopo), Cl\u00e9mence Herny (Exolabs), Roxane Pott (swisstopo), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF August 2022 to March 2023 - Published on August 28, 2023 All scripts are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-roadsurf Abstract : The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. In terms of balanced F1 score, we obtained a global score of 0.74 over the training, validation and test area, 0.56 over the inference-only area. 1. Introduction \u00b6 The Swiss road network extends over 83'274 km 1 . Not only cyclists and hikers can be interested in knowing whether a given road section is covered by a natural or an artificial surface, but also the Swiss Federal Roads Office, which is in charge of road maintenance, and engineering companies. This information is found within the swissTLM3D 2 dataset, the large-scale topographic model of Switzerland produced by the Federal Office of Topography (swisstopo). Keeping the swissTLM3D dataset up to date is a time-consuming work that has to be done methodically. Operators draw and georeference new elements and fill in their attributes based on the visual interpretation of stereoscopic aerial images. The update of existing elements also follows this manual approach. Data science can help by autmatizing this time-consuming and systematic tasks. So far, the majority of data science studies on the identification of the road surface type, in particular those based on artificial intelligence, have been conducted in the context of improving the driving and security of autonomous vehicles 3 4 5 6 . These works rely on images shot by cameras mounted at the front of the moving vehicle itself. To our knowledge, only one study, carried out by Mansourmoghaddam et al. (2022) 7 , proposed a method based on object-based classification from aerial imagery, which could successfully tell artificial roads from natural ones. Another possible approach is to use spectral indices, as done by Zhao & Zhu (2022) 8 working on the distinction between artificial surfaces and bare land. However, their method is not specifically designed for road surfaces. The goal of this project was to determine whether the road cover is artificial or natural with the development of data science tools. For this first test, only the roads of the class \"3m Strasse\" are considered. Figure 1: Overview of the workflow for this project. As the location of roads was known, we faced a problem of supervised classification. Two approaches were tested to address it: machine learning (ML) and deep learning (DL). Both approaches used the same input data, aerial images and vector road location. 2. Data \u00b6 As input data, this project used two datasets produced by the Federal Office of Topography: swissTLM3D and SWISSIMAGE RS. We worked with data for the year 2018, for which the images and ground truth, i.e. the manually vectorized and classified roads, are available for the area of interest (AOI). Coordinates are expressed in the EPSG:2056 reference system. 2.1. Area of interest \u00b6 Figure 2: Delimitation of the area of interest with the tile numbers of the 1:25'000 Swiss national map. The area of interest (AOI) defined for this study was represented by the tiles 1168, 1188, 1208 and 1228 of the Swiss national map at a scale of 1:25'000. This zone covers an area of 840 km 2 and was chosen because of its representativeness of the Swiss territory. 2.2. swissTLM3D \u00b6 The swissTLM3D 2 dataset is a large-scale topographic model of Switzerland. It contains geospatial data necessary o the national map, such as roads, buildings and land cover. Periodical updates rely on the manual work of specialized operators. They interpret stereoscopic images and fill in attributes with the help of some additional information, like cadastral surveys and terrestrial images. The specification of aerial imagery is similar to the SWISSIMAGE RS product. The road layer contains lines with the identifier, the structure (none, bridge, tunnel, etc.), the object type (highways, 8m roads, 1 m paths, etc.) and the surface type as attributes. The two possible classes of the surface type are defined in the metadata: artificial (German: Hart) and natural (Natur). The artificial class contains surfaces of hard artificial materials like asphalt, concrete or slabs. The natural class contains roads with a surface of natural materials like gravel or dirt, and untreated surfaces. In this project, it was decided to test the classification for the type \"3m Strasse\" (3 m roads). This class encompasses roads that are between 2.81 m and 4.20 m wide. Within this subset, 6486 roads have an artificial surface and 289 a natural one. The dataset is heavily unbalanced toward the artificial roads. In addition, the swissTLM3D dataset was used to identify the forests. Indeed, they prevent us from observing roads from aerial images; hence those roads cannot be used in our study. As no layer in the swissTLM3D is specifically devoted to forested areas, they were deduced from the land cover classes. A filter was applied to only keep forests (\"Wald\") and open forests (\"Wald offen\"). Over the AOI, all the roads in quarries have a natural surface. We used our own layer from the project on the detection of mineral extraction sites to know their location. However, it is possible to use the information on the area of use from the swissTLM3D dataset which has a class on gravel quarries and one on stone quarries. 2.3. SWISSIMAGE RS \u00b6 The product SWISSIMAGE RS 9 contains aerial images of Switzerland composed by four bands: near-infrared (NIR), red (R), green (G) and blue (B). The ground resolution equals 0.10 m over the area of interest, except in some high altitude regions or regions with complex topography, where a resolution of 0.25 m is deemed sufficient. The standard deviation is +/- 0.15 m (1 sigma) for a ground resolution of 0.10 m and +/- 0.25 m (1 sigma) for a ground resolution of 0.25 m, +/- 3-5 m (1 sigma). The dataset is composed of a collection of 16-bit encoded GeoTIFF orthorectified images. The overlap between images varies, but stays always present. 3. Preprocessing \u00b6 Both the swissTLM3D and SWISSIMAGE RS dataset were processed to be suitable for the algorithms we wanted to develop. This was achieved with two procedures: the generation of the road domain and the creation of a raster mosaic. 3.1. Generation of the Road Domain \u00b6 The swissTLM3D contains a vector layer representing every road section as a 3D line with some attached attributes. As a first test, the beneficiaries requested us to perform the analysis only on roads of the type \"3m Strasse\", i.e the roads wider than 2.81 m and thinner than 4.20 m. The engineered structures were excluded based on the attribute \"KUNSTBAUTE\". Only bridges and road sections without structures were kept. Data preparation differs slightly between the two performed analyses, machine and deep learning. Results for both approaches are shown here below. Figure 3: Resulting labels (left) from the initial TLM lines (right) in the case of the machine learning. Figure 4: Resulting labels (left) from the initial TLM lines (right) in the case of deep learning. For the machine learning analysis, only the 3m roads were kept (figure 3). For the deep learning analysis, we judged safer to keep all the visible roads (figure 4). Therefore, the neighboring roads were also considered. We made the hypothesis that we would obtain better results by training the model on all the visible roads, rather than on the 3m ones only. Still, the focus on \"3m Strasse\" class was enforced through the selection of raster tiles: only those tiles containing the specific class were used as input data. Road geometries, originally linear, were transformed into polygons by adding a buffer with a flat cap style. This procedure generated unwanted overlapping areas in the neighborhood of the intersection points between contiguous road sections. Such artifacts were handled differently depending on the road types: in the case of roads with different widths, the zone of the overlap inherited the class of the widest road section among the intersecting ones. in the case of roads with the same width, in the case of the machine learning analysis, overlapping parts were discarded; in the case of the deep learning analysis, it was supposed that leaving the overlapping parts would produce more understandable labels for the algorithm than suppressing the overlap. Once that the polygons were generated, sections hidden by a forest canopy were excluded. A buffer of 2 m was also added around forests as the canopy was often seen to be extending beyond the forest delimitation as recorded in the swissTLM3D dataset. We considered adding some information about the altitude of the length of the roads to the labels. Natural and artificial roads share pretty much the same distribution in terms of altitude. For the length, the longest roads all had an artificial surface. However, the experts could not tell us if it was the case for all Switzerland or a coincidence on our AOI. For the deep learning analysis, we tried to improve the overlap between labels and images by taking cadastral data into account. A larger buffer was used on the lines for the TLM. Then, only the parts of the buffer intersecting the road surfaces from cadastral surveying were kept. As described in the deep learning analysis section , we tested the labels straight out of the TLM and the ones augmented by the cadastral surveying. We also tried to merge the labels by width type or by surface type. After the pre-processing step described here above, for the machine learning analysis, 2'781 road sections were obtained, including 110 natural ones; for the deep learning analysis, 12'208 road sections were obtained, including 3078 natural ones. Let us remind that there were many more roads labeled in the second case as we considered all the visible roads. Especially for natural roads, the vast majority did not belong to the class of interest, but rather to the \"1m Weg\" and \"2m Weg\" classes. 3.2. Raster Mosaic Generation \u00b6 As said in the description of SWISSIMAGE RS , a large overlap between images is present in the dataset. To remove this overlap, a mosaic was created. Instead of merging all the images into one, we decided to set up a XYZ raster tile service, allowing us to work at different resolutions. The first step consists in reprojecting images in the EPSG:3857 projection, compliant with standard tile map services . Then, to save memory and disk space, images were converted from 16 to 8 bits. Besides, normalization was performed to optimize the usage of the available dynamic range. Finally, images were exported to the Cloud-Optimized GeoTIFF (COG) format. COG files can then be loaded by the TiTiler application, an Open Source dynamic tile server application 10 . The MosaicJSON specification was used to store image metadata 11 . Zoom levels were bound between 17 and 20, corresponding to resolutions between 1.20 m and 0.15 m. 4. Machine Learning Analysis \u00b6 4.1. Methodology \u00b6 Before delving into machine learning, we performed some exploratory data analysis, aiming at checking whether already existing features were discriminant enough to tell natural roads from artificial ones. Additional predictive features were also generated, based on ratios between pixel values in different bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR); one spectral index; per-band statistics (mean, median, minimum, maximum, standard deviation). The machine learning analysis was performed only on the two middle tiles of the AOI. The most promising spectral index we found in the literature is the Artificial Surface Index (ASI) defined by Zhao & Zhu (2022) 12 . Unfortunately, the computation of the ASI requires the shortwave infrared (SWIR) band which is not available in the SWISSIMAGE RS data. The SWIR band can be available in satellite imagery (e.g.: Landsat 8, Sentinel 2), yet spatial resolution (20-30 m/px) is not enough for the problem at hand. Instead, the VgNIR-BI index 13 could be computed in our case, since it combines the green and NIR bands: \\[\\begin{align} \\ \\mbox{VgNIR-BI} = {\\rho_{green} - \\rho_{NIR} \\over \\rho_{green} + \\rho_{NIR}} \\ \\end{align}\\] where \u03c1 stands for the atmospherically corrected surface reflectance values of the band. In our case, no atmospheric correction was applied, because we dealt with aerial imagery instead of satellite imagery. Boxplots were generated to visualize the distribution of the aforementioned predictive features. Principal component analysis (PCA) were performed, too. The group of values passed to the PCA were the following: - pixel values: Each pixel displays 11 attributes corresponding to (1) its values on the different bands (R, G, B, NIR), (2) the ratio between bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR), and (3) the VgNIR-BI spectral index 13 . - summary statistics: Each road has 5 attributes for each band: the mean, the median, the minimum (min), the maximum (max), and the standard deviation (std). Let us note that: these two analyses were carried out on a curated selection of input data, which was ought to maximize the separation between natural and artificial roads. The road sections were filtered by pixel number and margin of error on their mean to avoid small or crowded road sections. Were the results promising, the analysis would have been carried out on the entire dataset. We confirmed that results were not biased by performing each analysis on the entire dataset and a balanced subset. We also confirmed that results were stable with respect to the chosen zoom level. 4.2. Results \u00b6 In order not to make the presentation too cumbersome, here we only show results produced at zoom level 18, on the entire dataset, and considering road sections corresponding to the following criteria: covering at least 10 pixels; enjoying a margin of error (MOE) on the mean below 12.5, computed with a coefficient level of 0.95. Figure 5: Boxplots of the statistical distribution of pixel values on each band for each surface type. Each graph represents a band and each boxplot a surface type. We can see on the figure 5 that both the median and the upper quartile are systematically higher for natural than for artificial roads across all the bands, meaning the natural roads have brighter parts. Unfortunately, we have that pixel value statistics do not allow a sharp distinction between the two classes, as the lower quartile are very close. Figure 6: Boxplots of the pixel distribution on the VgNIR-BI index and the ratios between bands. Each graph represents a ratio or the index and each boxplot a surface type. Figure 6bis: Boxplots of the pixel distribution on the ratios between bands. Each graph represents a ratio and each boxplot a surface type. The ratios between bands and the VgNIR-BI present similar values for the artificial and natural roads, allowing no distinction between the classes. Figure 7: Boxplots of the distribution for the road summary statistics on the blue band. Each graph represents a statistic and each boxplot a type of road surface. Boxplots produced with the summary statistics computed per band and per road section lead to similar conclusions. Natural roads tend to be lighter than artificial ones. However, the difference is not strong enough to affect the lower quartiles and allow a sharp distinction between classes. Figure 8: PCA of the pixels based on their value on each band. Figure 9: PCA of the roads based on their statistics on the blue band. The figures 8 and 9 present respectively the results of the PCA on the pixel values and on the statistics over road sections. Once more, we have to acknowledge that, unfortunately, artificial and natural roads cannot be separated. 4.3. Discussion \u00b6 Although boxplots reveal that some natural roads can be brighter than artificial roads, statistical indicators overlap in such a way that no sharp distinction between the two classes can be drawn. The PCA confirms such an unfortunate finding. Those results are not surprising. As a matter of fact, natural roads which are found in the \"3m Strasse\" type are mainly made by gravel or similar materials which, color-wise, make them very similar to artificial roads. 5. Deep Learning Analysis \u00b6 5.1. Methodology \u00b6 To perform the detection and classification of roads, the object detector (OD) framework developed by the STDL 14 was used. It is described in details in the dedicated page . The two central parts of the AOI constitute the training zone, i.e. the zone for the training, validation and test datasets. The two exterior parts constitute the inference-only zone, i.e. for the \"other\" dataset, to test the trained model on an entirely new zone. To assess the predictions, a script was written, final_metrics.py instead of using the one directly from the STDL's OD. We decided to take advantage that: 1. Predictions are not exclusive between classes. Every road section was detected several times with predictions of different class overlapping. 2. The delimitation of the roads are already known. Therefore, rather than choosing one correct prediction, we aggregated the predictions in a natural and an artificial index over each label. Those indices were defined as follows: \\[\\begin{align} \\ \\mbox{index}_{class} = \\frac{\\sum_{i=1}^{n} (A_{\\%,i} \\cdot \\mbox{score}_{class,i})}{\\sum_{i=1}^{n} A_{\\%,i}} \\ \\end{align}\\] where n is the number of predictions belonging to the class, \\(A_{\\%, i}\\) is the percentage of overlapping area between the label and the prediction, \\(\\mbox{score}_{class,i}\\) is its confidence score. \\[\\begin{align} \\ \\text{final class} = \\begin{cases} \\mbox{artificial} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\gt \\mbox{index}_{natural}\\\\ \\mbox{natural} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\lt \\mbox{index}_{natural} \\\\ \\mbox{undetected} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = 0 \\; \\text{ and } \\; \\mbox{index}_{natural} = 0 \\\\ \\mbox{undetermined} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = \\mbox{index}_{natural} \\; \\text{ and }\\; \\mbox{index}_{artificial} \\neq 0\\\\ \\end{cases} \\ \\end{align}\\] The largest index indicates the right class as better predictions are supporting it. Once every road has an attributed class, the result was evaluated in terms of recall, precision and balanced F1 score. \\[\\begin{align} \\ P_{class} = \\frac{TP_{class}}{TP_{class}+FP_{class}} \\text{ and } P = \\frac{P_{natural} + P_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ R_{class} = \\frac{TP_{class}}{TP_{class}+FN_{class}} \\text{ and } R = \\frac{R_{natural} + R_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ F1\\text{ }score = \\frac{2PR}{P + R} \\ \\end{align}\\] where \\(FN_{class}\\) is the number of roads that are not detected or wrongly assigned to the other class, \\(FP_{class}\\) is the number of roads from the other class wrongly attributed to the considered class, \\(P_{class}\\) is the precision, i.e. the percentage of correct roads in the detected class, \\(R_{class}\\) is the recall, i.e. the percentage of correctly found and classified roads from a class, \\(TP_{class}\\) is the number of roads correctly found in the class. The predictions are not necessarily all taken into account. They are filtered based on their confidence score. Thresholds were tested over the balanced F1 score of the validation dataset. The current dataset exhibits a very strong class imbalance. Therefore, we decided to use balanced metrics, giving the same weight to both classes. The balanced F1 score was chosen as the determining criterion between the different tested models. As it gives equal weight to both classes, the quality of the classification for the natural road was well taken into consideration. However, we have to keep in mind that we gave great importance to this class compared to its number of individuals. A great risk exists that the model would be biased toward artificial roads, because of the imbalance between classes. Therefore, we decided on a baseline model (BLM) where all the roads in the training zone are classified as artificial. Its metrics are the following: Artificial Natural Global Precision 0.97 0 0.49 Recall 1 0 0.5 F1 score 0.98 0 0.49 Table 1: Metrics for the BLM with all the roads classified as artificial The trained models should improve the global F1 score of 0.49 to be considered as an improvement. Finally, we wanted to know if the artificial and natural index could constitute a confidence score for their respective classes. The reliability diagram has been plotted to visualize the accuracy of the classification at different levels of those indices. Figure 10: Listing of the various tests carried out. To achieve the best possible results, several input parameters and files for the model training were tested. 1. We tried to improve the quality of the labels by integrating data from cadastral surveying and by merging the roads based on their cover, on their type, or not at all. 2. We trained the model with different zoom level images, from 17 to 20. 3. The influence of different band combinations on the model performance was investigated: true colors (RGB) and false colors (NirRG). For each test, the best configuration was chosen based on the global balanced F1 score. This method supposes that the best choice for one parameter did not depend on the others. 5.2. Results \u00b6 When testing different procedures to create the labels, using only the TLM and excluding the data from the cadastral survey gave the best metrics. Besides, cutting the label corresponding to the road sections and not merging them by road type or surface gave better metrics. Increasing the zoom level improved the balanced F1 score. Using the bands RGB and RG with NIR gave very similar results and an equal F1 score. Therefore, the best model is based on labels deduced from the TLM and using the RGB bands at a zoom level 20. Artificial Natural Global Precision 0.99 0.74 0.87 Recall 0.97 0.74 0.86 F1 score (1) 0.98 0.74 0.86 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) 0 0.74 0.32 Table 2: metrics for the best model over the training, test and validation area. The F1 score for the natural roads and the global one outperformed the BLM. The per-class F1 scores has been judged as satisfying by the beneficiaries. Artificial Natural Global Precision 0.98 0.22 0.60 Recall 0.95 0.26 0.61 F1 score (1) 0.96 0.24 0.60 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) -0.02 0.24 0.11 Table 3: metrics for the best model over the inference-only area. Those metrics are worse than the ones obtained over the training area. The global F1 score is still higher than for the BLM. However, the natural F1 score is not high enough. Figure 11: Absolute and relative repartition of the roads in the inference-only zone. 93.2% of the roads are correctly classified, 4.2% are in the wrong class and 2.6% are undetected or undetermined. Nearly half of the natural roads are either undetected or in the wrong class, but as they represent a tiny proportion of the dataset, they impact little the accuracy. In the training zone, only 2% of the roads are in the wrong class and 1.7% are undetected or undetermined. Figure 12: Reliability curves for the training and the inference-only zone. The artificial index can be used as confidence score for the artificial roads. The natural index can be used as confidence score for the natural ones. Indeed, the accuracy of the results for each class increases with their value. 5.3. Discussion \u00b6 The F1 score obtained is 0.86 over the area to train and validate the model and 0.60 over the rest of the AOI. The difference is essentially due to the decrease in the F1 score of the natural roads, passing from 0.74 to 0.24. The first intuition is that we were facing a case of overfitting. However, the validation loss was controlled in order to stop the training on time and avoid this problem. Another possibility would be that the two zones differ significantly and that a model trained on one cannot apply on the other. Hence, we also split the tiles randomly between the training and the inference-only zone. The gap between the balanced F1 score of the training and inference-only zone passed from 0.25 to 0.19 with the same hyper-parameters. The high recall for artificial roads indicates that the model properly detects them. However, once the artificial recall is high, the high artificial precision is in this case necessarily due. As the roads have a known location, the false positives not due to a class confusion are eliminated from our assessment. Then, only the roads classified in the wrong class can affect precision. As there are not a lot of natural roads, even if they were all wrongly classified as artificial like in the BLM, the precision would still remain well at 0.97. In the current case, the precision of the trained model is 0.01 higher than the one of the BLM. The drop in the natural F1 score is due to all the roads predicted in the wrong class. As they are only a few natural roads, errors of the model affect them more heavily. The part of the misclassified road increased by 44% between the training and the inference-only zone. Meanwhile, the part of undetermined roads only increased by 1% The F1 score could maybe be further improved by focusing more strictly on the 3m roads. Indeed, we considered it would be safer to teach the algorithm to differentiate only between surfaces and not between road types, which are defined by width. Therefore, the tiles were selected because they intersected 3m roads, but then all the roads on the tiles were transformed into labels. Because of the rarity of 3m natural roads, most of the natural roads seen by the algorithm are 2m roads and those often have a surface with grass, where the 3m natural roads have a surface made only of gravel or dirt. Over the training zone, 110 natural roads are 3m ones and 1183 ones are 2 m and 1 m paths. Maybe, labelling only the 3m roads would give better results than labelling all the visible roads. We did not tune the hyperparameter used by the deep learning model once we found a satisfying enough combination. In addition, as the algorithm is based on detectron2, not everything can easily be tuned. Using an entirely new framework and tuning the loss weights would allow better handling the class imbalance. A new framework could also allow integrating an attention mask and take advantage of the known road location like recommended by Epel (2018) 15 . Using a new framework could also allow to use images with 4 bands and integrating the NIR. However, we decided here to first try the tools we already had in our team. We can say that there is a bias in the model encouraging it to predict artificial roads. However, it is still better than the BLM. Therefore, this model is adapted for its purpose. 5.3.1. Elements specific to the application on the SwissTLM3D product \u00b6 All these findings seem negative, which is why it is appropriate to recall the significant imbalance between the classes. If we look at the percentages, 93.2% of the dataset is correctly classified over the inference-only zone. This could represent a significant gain of time compared to an operator who would do the classification manually. Indeed, once the model trained, the procedure documented here only needs 20 minutes to classify the roads of the AOI. Besides, the artificial and natural indices allow us to find most of the misclassified roads and limit the time needed for a visual verification. In addition, the information of the road surface type is already available for the whole Switzerland. When using the algorithm to update the swissTLM3D dataset, it would be possible to perform change detection between the previous and new surface type. Then, those changes could be visually verified. 6. Conclusion \u00b6 Keeping the swissTLM3D dataset up to date is a time consuming and methodical task. This project aimed at finding a method to automatize the determination of the road surface type (artificial vs. natural). We focused on roads belonging to the \"3m Strasse\" class and discovered that statistics stemming from pixel values are not enough discriminating to tell artificial roads from natural ones. Therefore, we decided not to attempt any supervised classification based on machine learning. Instead, deep learning methods are performed. With 93% of the roads classified correctly, this method gave better results in regard to the global F1 score than a baseline model classifying all the roads as artificial. However, the model classifies 4.2% of the roads in the wrong class and has difficulties performing new zones. To ensure the quality of the swissTLM3D product, we advise to first perform a classification with the algorithm, then to check roads with a low class index or a change in surface type compared to the previous version years. It could represent a huge time saver for the operators who currently classify and check a second time all the roads. Despite our investigations, we could not find the cause of the gap between the metrics for the training and the inference-only zone. Further investigation is needed. The next step for this project would be to extend the algorithm to paths of 1 to 2 m wide. The natural roads of 3 m are mostly made of gravel, which strongly resembles asphalt, while natural paths are mostly made of dirt and can grow grass. Therefore, when mixing the two road width classes in one model, the natural roads of 3 m could be too difficult to distinguish from artificial roads and end up neglected. 7. References \u00b6 Office f\u00e9d\u00e9ral de la statistique. Longueur des routes en 2020 | Office f\u00e9d\u00e9ral de la statistique. https://www.bfs.admin.ch/news/fr/2020-0273, November 2020. \u21a9 swisstopo. swissTLM3D. https://www.swisstopo.admin.ch/de/geodata/landscape/tlm3d.html. \u21a9 \u21a9 Lushan Cheng, Xu Zhang, and Jie Shen. Road surface condition classification using deep learning. Journal of Visual Communication and Image Representation , 64:102638, October 2019. doi:10.1016/j.jvcir.2019.102638 . \u21a9 Susi Marianingsih, Fitri Utaminingrum, and Fitra Abdurrachman Bachtiar. Road Surface Types Classification Using Combination of K-Nearest Neighbor and Na\u00efve Bayes Based on GLCM. International Journal of Advanced Software Computer Application , 11(2):15\u201327, 2019. \u21a9 Marcus Nolte, Nikita Kister, and Markus Maurer. Assessment of Deep Convolutional Neural Networks for Road Surface Classification. In 2018 21st International Conference on Intelligent Transportation Systems (ITSC) , 381\u2013386. Maui, HI, November 2018. IEEE. doi:10.1109/ITSC.2018.8569396 . \u21a9 Viktor Slavkovikj, Steven Verstockt, Wesley De Neve, Sofie Van Hoecke, and Rik Van De Walle. Image-Based Road Type Classification. In 2014 22nd International Conference on Pattern Recognition , 2359\u20132364. Stockholm, August 2014. IEEE. doi:10.1109/ICPR.2014.409 . \u21a9 Mohammad Mansourmoghaddam, Hamid Reza Ghafarian Malamiri, Fahime Arabi Aliabad, Mehdi Fallah Tafti, Mohamadreza Haghani, and Saeed Shojaei. The Separation of the Unpaved Roads and Prioritization of Paving These Roads Using UAV Images. Air, Soil and Water Research , 15:117862212210862, January 2022. doi:10.1177/11786221221086285 . \u21a9 Hailing Zhou, Hui Kong, Lei Wei, Douglas Creighton, and Saeid Nahavandi. On Detecting Road Regions in a Single UAV Image. IEEE Transactions on Intelligent Transportation Systems , 18(7):1713\u20131722, July 2017. doi:10.1109/TITS.2016.2622280 . \u21a9 swisstopo. SWISSIMAGE RS. https://www.swisstopo.admin.ch/fr/geodata/images/ortho/swissimage-rs.html. \u21a9 TiTiler. https://developmentseed.org/titiler/. \u21a9 Vincent Sarago, Sean Harkins, and Drew Bollinger. Developmentseed / mosaicjson-spec. https://github.com/developmentseed/mosaicjson-spec, 2021. \u21a9 Yongquan Zhao and Zhe Zhu. ASI: An artificial surface Index for Landsat 8 imagery. International Journal of Applied Earth Observation and Geoinformation , 107:102703, March 2022. doi:10.1016/j.jag.2022.102703 . \u21a9 Ronald C. Estoque and Yuji Murayama. Classification and change detection of built-up lands from Landsat-7 ETM+ and Landsat-8 OLI/TIRS imageries: A comparative assessment of various spectral indices. Ecological Indicators , 56:205\u2013217, September 2015. doi:10.1016/j.ecolind.2015.03.037 . \u21a9 \u21a9 Swiss Territorial Data Lab. Object detector. February 2023. URL: https://github.com/swiss-territorial-data-lab/object-detector . \u21a9 Sagi Eppel. Classifying a specific image region using convolutional nets with an ROI mask as input. December 2018. arXiv:1812.00291 . \u21a9","title":"Classification of road surfaces"},{"location":"PROJ-ROADSURF/#classification-of-road-surfaces","text":"Gwena\u00eblle Salamin (swisstopo), Cl\u00e9mence Herny (Exolabs), Roxane Pott (swisstopo), Alessandro Cerioni (\u00c9tat de Gen\u00e8ve) Proposed by the Federal Office of Topography swisstopo - PROJ-ROADSURF August 2022 to March 2023 - Published on August 28, 2023 All scripts are available on GitHub: https://github.com/swiss-territorial-data-lab/proj-roadsurf Abstract : The Swiss road network extends over 83\u2019274 km. Information about the type of road surface is useful not only for the Swiss Federal Roads Office and engineering companies, but also for cyclists and hikers. Currently, the data creation and update is entirely done manually at the Swiss Federal Office of Topography. This is a time-consuming and methodical task, potentially suitable to automation by data science methods. The goal of this project is classifying Swiss roads according to their surface type, natural or artificial. We first searched for statistical differences between these two classes, in order to then perform supervised classification based on machine-learning methods. As we could not find any discriminant feature, we used deep learning methods. In terms of balanced F1 score, we obtained a global score of 0.74 over the training, validation and test area, 0.56 over the inference-only area.","title":"Classification of road surfaces"},{"location":"PROJ-ROADSURF/#1-introduction","text":"The Swiss road network extends over 83'274 km 1 . Not only cyclists and hikers can be interested in knowing whether a given road section is covered by a natural or an artificial surface, but also the Swiss Federal Roads Office, which is in charge of road maintenance, and engineering companies. This information is found within the swissTLM3D 2 dataset, the large-scale topographic model of Switzerland produced by the Federal Office of Topography (swisstopo). Keeping the swissTLM3D dataset up to date is a time-consuming work that has to be done methodically. Operators draw and georeference new elements and fill in their attributes based on the visual interpretation of stereoscopic aerial images. The update of existing elements also follows this manual approach. Data science can help by autmatizing this time-consuming and systematic tasks. So far, the majority of data science studies on the identification of the road surface type, in particular those based on artificial intelligence, have been conducted in the context of improving the driving and security of autonomous vehicles 3 4 5 6 . These works rely on images shot by cameras mounted at the front of the moving vehicle itself. To our knowledge, only one study, carried out by Mansourmoghaddam et al. (2022) 7 , proposed a method based on object-based classification from aerial imagery, which could successfully tell artificial roads from natural ones. Another possible approach is to use spectral indices, as done by Zhao & Zhu (2022) 8 working on the distinction between artificial surfaces and bare land. However, their method is not specifically designed for road surfaces. The goal of this project was to determine whether the road cover is artificial or natural with the development of data science tools. For this first test, only the roads of the class \"3m Strasse\" are considered. Figure 1: Overview of the workflow for this project. As the location of roads was known, we faced a problem of supervised classification. Two approaches were tested to address it: machine learning (ML) and deep learning (DL). Both approaches used the same input data, aerial images and vector road location.","title":"1. Introduction"},{"location":"PROJ-ROADSURF/#2-data","text":"As input data, this project used two datasets produced by the Federal Office of Topography: swissTLM3D and SWISSIMAGE RS. We worked with data for the year 2018, for which the images and ground truth, i.e. the manually vectorized and classified roads, are available for the area of interest (AOI). Coordinates are expressed in the EPSG:2056 reference system.","title":"2. Data"},{"location":"PROJ-ROADSURF/#21-area-of-interest","text":"Figure 2: Delimitation of the area of interest with the tile numbers of the 1:25'000 Swiss national map. The area of interest (AOI) defined for this study was represented by the tiles 1168, 1188, 1208 and 1228 of the Swiss national map at a scale of 1:25'000. This zone covers an area of 840 km 2 and was chosen because of its representativeness of the Swiss territory.","title":"2.1. Area of interest"},{"location":"PROJ-ROADSURF/#22-swisstlm3d","text":"The swissTLM3D 2 dataset is a large-scale topographic model of Switzerland. It contains geospatial data necessary o the national map, such as roads, buildings and land cover. Periodical updates rely on the manual work of specialized operators. They interpret stereoscopic images and fill in attributes with the help of some additional information, like cadastral surveys and terrestrial images. The specification of aerial imagery is similar to the SWISSIMAGE RS product. The road layer contains lines with the identifier, the structure (none, bridge, tunnel, etc.), the object type (highways, 8m roads, 1 m paths, etc.) and the surface type as attributes. The two possible classes of the surface type are defined in the metadata: artificial (German: Hart) and natural (Natur). The artificial class contains surfaces of hard artificial materials like asphalt, concrete or slabs. The natural class contains roads with a surface of natural materials like gravel or dirt, and untreated surfaces. In this project, it was decided to test the classification for the type \"3m Strasse\" (3 m roads). This class encompasses roads that are between 2.81 m and 4.20 m wide. Within this subset, 6486 roads have an artificial surface and 289 a natural one. The dataset is heavily unbalanced toward the artificial roads. In addition, the swissTLM3D dataset was used to identify the forests. Indeed, they prevent us from observing roads from aerial images; hence those roads cannot be used in our study. As no layer in the swissTLM3D is specifically devoted to forested areas, they were deduced from the land cover classes. A filter was applied to only keep forests (\"Wald\") and open forests (\"Wald offen\"). Over the AOI, all the roads in quarries have a natural surface. We used our own layer from the project on the detection of mineral extraction sites to know their location. However, it is possible to use the information on the area of use from the swissTLM3D dataset which has a class on gravel quarries and one on stone quarries.","title":"2.2. swissTLM3D"},{"location":"PROJ-ROADSURF/#23-swissimage-rs","text":"The product SWISSIMAGE RS 9 contains aerial images of Switzerland composed by four bands: near-infrared (NIR), red (R), green (G) and blue (B). The ground resolution equals 0.10 m over the area of interest, except in some high altitude regions or regions with complex topography, where a resolution of 0.25 m is deemed sufficient. The standard deviation is +/- 0.15 m (1 sigma) for a ground resolution of 0.10 m and +/- 0.25 m (1 sigma) for a ground resolution of 0.25 m, +/- 3-5 m (1 sigma). The dataset is composed of a collection of 16-bit encoded GeoTIFF orthorectified images. The overlap between images varies, but stays always present.","title":"2.3. SWISSIMAGE RS"},{"location":"PROJ-ROADSURF/#3-preprocessing","text":"Both the swissTLM3D and SWISSIMAGE RS dataset were processed to be suitable for the algorithms we wanted to develop. This was achieved with two procedures: the generation of the road domain and the creation of a raster mosaic.","title":"3. Preprocessing"},{"location":"PROJ-ROADSURF/#31-generation-of-the-road-domain","text":"The swissTLM3D contains a vector layer representing every road section as a 3D line with some attached attributes. As a first test, the beneficiaries requested us to perform the analysis only on roads of the type \"3m Strasse\", i.e the roads wider than 2.81 m and thinner than 4.20 m. The engineered structures were excluded based on the attribute \"KUNSTBAUTE\". Only bridges and road sections without structures were kept. Data preparation differs slightly between the two performed analyses, machine and deep learning. Results for both approaches are shown here below. Figure 3: Resulting labels (left) from the initial TLM lines (right) in the case of the machine learning. Figure 4: Resulting labels (left) from the initial TLM lines (right) in the case of deep learning. For the machine learning analysis, only the 3m roads were kept (figure 3). For the deep learning analysis, we judged safer to keep all the visible roads (figure 4). Therefore, the neighboring roads were also considered. We made the hypothesis that we would obtain better results by training the model on all the visible roads, rather than on the 3m ones only. Still, the focus on \"3m Strasse\" class was enforced through the selection of raster tiles: only those tiles containing the specific class were used as input data. Road geometries, originally linear, were transformed into polygons by adding a buffer with a flat cap style. This procedure generated unwanted overlapping areas in the neighborhood of the intersection points between contiguous road sections. Such artifacts were handled differently depending on the road types: in the case of roads with different widths, the zone of the overlap inherited the class of the widest road section among the intersecting ones. in the case of roads with the same width, in the case of the machine learning analysis, overlapping parts were discarded; in the case of the deep learning analysis, it was supposed that leaving the overlapping parts would produce more understandable labels for the algorithm than suppressing the overlap. Once that the polygons were generated, sections hidden by a forest canopy were excluded. A buffer of 2 m was also added around forests as the canopy was often seen to be extending beyond the forest delimitation as recorded in the swissTLM3D dataset. We considered adding some information about the altitude of the length of the roads to the labels. Natural and artificial roads share pretty much the same distribution in terms of altitude. For the length, the longest roads all had an artificial surface. However, the experts could not tell us if it was the case for all Switzerland or a coincidence on our AOI. For the deep learning analysis, we tried to improve the overlap between labels and images by taking cadastral data into account. A larger buffer was used on the lines for the TLM. Then, only the parts of the buffer intersecting the road surfaces from cadastral surveying were kept. As described in the deep learning analysis section , we tested the labels straight out of the TLM and the ones augmented by the cadastral surveying. We also tried to merge the labels by width type or by surface type. After the pre-processing step described here above, for the machine learning analysis, 2'781 road sections were obtained, including 110 natural ones; for the deep learning analysis, 12'208 road sections were obtained, including 3078 natural ones. Let us remind that there were many more roads labeled in the second case as we considered all the visible roads. Especially for natural roads, the vast majority did not belong to the class of interest, but rather to the \"1m Weg\" and \"2m Weg\" classes.","title":"3.1. Generation of the Road Domain"},{"location":"PROJ-ROADSURF/#32-raster-mosaic-generation","text":"As said in the description of SWISSIMAGE RS , a large overlap between images is present in the dataset. To remove this overlap, a mosaic was created. Instead of merging all the images into one, we decided to set up a XYZ raster tile service, allowing us to work at different resolutions. The first step consists in reprojecting images in the EPSG:3857 projection, compliant with standard tile map services . Then, to save memory and disk space, images were converted from 16 to 8 bits. Besides, normalization was performed to optimize the usage of the available dynamic range. Finally, images were exported to the Cloud-Optimized GeoTIFF (COG) format. COG files can then be loaded by the TiTiler application, an Open Source dynamic tile server application 10 . The MosaicJSON specification was used to store image metadata 11 . Zoom levels were bound between 17 and 20, corresponding to resolutions between 1.20 m and 0.15 m.","title":"3.2. Raster Mosaic Generation"},{"location":"PROJ-ROADSURF/#4-machine-learning-analysis","text":"","title":"4. Machine Learning Analysis"},{"location":"PROJ-ROADSURF/#41-methodology","text":"Before delving into machine learning, we performed some exploratory data analysis, aiming at checking whether already existing features were discriminant enough to tell natural roads from artificial ones. Additional predictive features were also generated, based on ratios between pixel values in different bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR); one spectral index; per-band statistics (mean, median, minimum, maximum, standard deviation). The machine learning analysis was performed only on the two middle tiles of the AOI. The most promising spectral index we found in the literature is the Artificial Surface Index (ASI) defined by Zhao & Zhu (2022) 12 . Unfortunately, the computation of the ASI requires the shortwave infrared (SWIR) band which is not available in the SWISSIMAGE RS data. The SWIR band can be available in satellite imagery (e.g.: Landsat 8, Sentinel 2), yet spatial resolution (20-30 m/px) is not enough for the problem at hand. Instead, the VgNIR-BI index 13 could be computed in our case, since it combines the green and NIR bands: \\[\\begin{align} \\ \\mbox{VgNIR-BI} = {\\rho_{green} - \\rho_{NIR} \\over \\rho_{green} + \\rho_{NIR}} \\ \\end{align}\\] where \u03c1 stands for the atmospherically corrected surface reflectance values of the band. In our case, no atmospheric correction was applied, because we dealt with aerial imagery instead of satellite imagery. Boxplots were generated to visualize the distribution of the aforementioned predictive features. Principal component analysis (PCA) were performed, too. The group of values passed to the PCA were the following: - pixel values: Each pixel displays 11 attributes corresponding to (1) its values on the different bands (R, G, B, NIR), (2) the ratio between bands (G/R, B/R, NIR/R, G/B, G/NIR, B/NIR), and (3) the VgNIR-BI spectral index 13 . - summary statistics: Each road has 5 attributes for each band: the mean, the median, the minimum (min), the maximum (max), and the standard deviation (std). Let us note that: these two analyses were carried out on a curated selection of input data, which was ought to maximize the separation between natural and artificial roads. The road sections were filtered by pixel number and margin of error on their mean to avoid small or crowded road sections. Were the results promising, the analysis would have been carried out on the entire dataset. We confirmed that results were not biased by performing each analysis on the entire dataset and a balanced subset. We also confirmed that results were stable with respect to the chosen zoom level.","title":"4.1. Methodology"},{"location":"PROJ-ROADSURF/#42-results","text":"In order not to make the presentation too cumbersome, here we only show results produced at zoom level 18, on the entire dataset, and considering road sections corresponding to the following criteria: covering at least 10 pixels; enjoying a margin of error (MOE) on the mean below 12.5, computed with a coefficient level of 0.95. Figure 5: Boxplots of the statistical distribution of pixel values on each band for each surface type. Each graph represents a band and each boxplot a surface type. We can see on the figure 5 that both the median and the upper quartile are systematically higher for natural than for artificial roads across all the bands, meaning the natural roads have brighter parts. Unfortunately, we have that pixel value statistics do not allow a sharp distinction between the two classes, as the lower quartile are very close. Figure 6: Boxplots of the pixel distribution on the VgNIR-BI index and the ratios between bands. Each graph represents a ratio or the index and each boxplot a surface type. Figure 6bis: Boxplots of the pixel distribution on the ratios between bands. Each graph represents a ratio and each boxplot a surface type. The ratios between bands and the VgNIR-BI present similar values for the artificial and natural roads, allowing no distinction between the classes. Figure 7: Boxplots of the distribution for the road summary statistics on the blue band. Each graph represents a statistic and each boxplot a type of road surface. Boxplots produced with the summary statistics computed per band and per road section lead to similar conclusions. Natural roads tend to be lighter than artificial ones. However, the difference is not strong enough to affect the lower quartiles and allow a sharp distinction between classes. Figure 8: PCA of the pixels based on their value on each band. Figure 9: PCA of the roads based on their statistics on the blue band. The figures 8 and 9 present respectively the results of the PCA on the pixel values and on the statistics over road sections. Once more, we have to acknowledge that, unfortunately, artificial and natural roads cannot be separated.","title":"4.2. Results"},{"location":"PROJ-ROADSURF/#43-discussion","text":"Although boxplots reveal that some natural roads can be brighter than artificial roads, statistical indicators overlap in such a way that no sharp distinction between the two classes can be drawn. The PCA confirms such an unfortunate finding. Those results are not surprising. As a matter of fact, natural roads which are found in the \"3m Strasse\" type are mainly made by gravel or similar materials which, color-wise, make them very similar to artificial roads.","title":"4.3. Discussion"},{"location":"PROJ-ROADSURF/#5-deep-learning-analysis","text":"","title":"5. Deep Learning Analysis"},{"location":"PROJ-ROADSURF/#51-methodology","text":"To perform the detection and classification of roads, the object detector (OD) framework developed by the STDL 14 was used. It is described in details in the dedicated page . The two central parts of the AOI constitute the training zone, i.e. the zone for the training, validation and test datasets. The two exterior parts constitute the inference-only zone, i.e. for the \"other\" dataset, to test the trained model on an entirely new zone. To assess the predictions, a script was written, final_metrics.py instead of using the one directly from the STDL's OD. We decided to take advantage that: 1. Predictions are not exclusive between classes. Every road section was detected several times with predictions of different class overlapping. 2. The delimitation of the roads are already known. Therefore, rather than choosing one correct prediction, we aggregated the predictions in a natural and an artificial index over each label. Those indices were defined as follows: \\[\\begin{align} \\ \\mbox{index}_{class} = \\frac{\\sum_{i=1}^{n} (A_{\\%,i} \\cdot \\mbox{score}_{class,i})}{\\sum_{i=1}^{n} A_{\\%,i}} \\ \\end{align}\\] where n is the number of predictions belonging to the class, \\(A_{\\%, i}\\) is the percentage of overlapping area between the label and the prediction, \\(\\mbox{score}_{class,i}\\) is its confidence score. \\[\\begin{align} \\ \\text{final class} = \\begin{cases} \\mbox{artificial} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\gt \\mbox{index}_{natural}\\\\ \\mbox{natural} \\quad \\mbox{ if } \\quad \\mbox{index}_{artificial} \\lt \\mbox{index}_{natural} \\\\ \\mbox{undetected} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = 0 \\; \\text{ and } \\; \\mbox{index}_{natural} = 0 \\\\ \\mbox{undetermined} \\quad \\text{ if } \\quad \\mbox{index}_{artificial} = \\mbox{index}_{natural} \\; \\text{ and }\\; \\mbox{index}_{artificial} \\neq 0\\\\ \\end{cases} \\ \\end{align}\\] The largest index indicates the right class as better predictions are supporting it. Once every road has an attributed class, the result was evaluated in terms of recall, precision and balanced F1 score. \\[\\begin{align} \\ P_{class} = \\frac{TP_{class}}{TP_{class}+FP_{class}} \\text{ and } P = \\frac{P_{natural} + P_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ R_{class} = \\frac{TP_{class}}{TP_{class}+FN_{class}} \\text{ and } R = \\frac{R_{natural} + R_{artificial}}{2} \\ \\end{align}\\] \\[\\begin{align} \\ F1\\text{ }score = \\frac{2PR}{P + R} \\ \\end{align}\\] where \\(FN_{class}\\) is the number of roads that are not detected or wrongly assigned to the other class, \\(FP_{class}\\) is the number of roads from the other class wrongly attributed to the considered class, \\(P_{class}\\) is the precision, i.e. the percentage of correct roads in the detected class, \\(R_{class}\\) is the recall, i.e. the percentage of correctly found and classified roads from a class, \\(TP_{class}\\) is the number of roads correctly found in the class. The predictions are not necessarily all taken into account. They are filtered based on their confidence score. Thresholds were tested over the balanced F1 score of the validation dataset. The current dataset exhibits a very strong class imbalance. Therefore, we decided to use balanced metrics, giving the same weight to both classes. The balanced F1 score was chosen as the determining criterion between the different tested models. As it gives equal weight to both classes, the quality of the classification for the natural road was well taken into consideration. However, we have to keep in mind that we gave great importance to this class compared to its number of individuals. A great risk exists that the model would be biased toward artificial roads, because of the imbalance between classes. Therefore, we decided on a baseline model (BLM) where all the roads in the training zone are classified as artificial. Its metrics are the following: Artificial Natural Global Precision 0.97 0 0.49 Recall 1 0 0.5 F1 score 0.98 0 0.49 Table 1: Metrics for the BLM with all the roads classified as artificial The trained models should improve the global F1 score of 0.49 to be considered as an improvement. Finally, we wanted to know if the artificial and natural index could constitute a confidence score for their respective classes. The reliability diagram has been plotted to visualize the accuracy of the classification at different levels of those indices. Figure 10: Listing of the various tests carried out. To achieve the best possible results, several input parameters and files for the model training were tested. 1. We tried to improve the quality of the labels by integrating data from cadastral surveying and by merging the roads based on their cover, on their type, or not at all. 2. We trained the model with different zoom level images, from 17 to 20. 3. The influence of different band combinations on the model performance was investigated: true colors (RGB) and false colors (NirRG). For each test, the best configuration was chosen based on the global balanced F1 score. This method supposes that the best choice for one parameter did not depend on the others.","title":"5.1. Methodology"},{"location":"PROJ-ROADSURF/#52-results","text":"When testing different procedures to create the labels, using only the TLM and excluding the data from the cadastral survey gave the best metrics. Besides, cutting the label corresponding to the road sections and not merging them by road type or surface gave better metrics. Increasing the zoom level improved the balanced F1 score. Using the bands RGB and RG with NIR gave very similar results and an equal F1 score. Therefore, the best model is based on labels deduced from the TLM and using the RGB bands at a zoom level 20. Artificial Natural Global Precision 0.99 0.74 0.87 Recall 0.97 0.74 0.86 F1 score (1) 0.98 0.74 0.86 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) 0 0.74 0.32 Table 2: metrics for the best model over the training, test and validation area. The F1 score for the natural roads and the global one outperformed the BLM. The per-class F1 scores has been judged as satisfying by the beneficiaries. Artificial Natural Global Precision 0.98 0.22 0.60 Recall 0.95 0.26 0.61 F1 score (1) 0.96 0.24 0.60 F1 score for the BLM (2) 0.98 0 0.49 Improvement: (1)-(2) -0.02 0.24 0.11 Table 3: metrics for the best model over the inference-only area. Those metrics are worse than the ones obtained over the training area. The global F1 score is still higher than for the BLM. However, the natural F1 score is not high enough. Figure 11: Absolute and relative repartition of the roads in the inference-only zone. 93.2% of the roads are correctly classified, 4.2% are in the wrong class and 2.6% are undetected or undetermined. Nearly half of the natural roads are either undetected or in the wrong class, but as they represent a tiny proportion of the dataset, they impact little the accuracy. In the training zone, only 2% of the roads are in the wrong class and 1.7% are undetected or undetermined. Figure 12: Reliability curves for the training and the inference-only zone. The artificial index can be used as confidence score for the artificial roads. The natural index can be used as confidence score for the natural ones. Indeed, the accuracy of the results for each class increases with their value.","title":"5.2. Results"},{"location":"PROJ-ROADSURF/#53-discussion","text":"The F1 score obtained is 0.86 over the area to train and validate the model and 0.60 over the rest of the AOI. The difference is essentially due to the decrease in the F1 score of the natural roads, passing from 0.74 to 0.24. The first intuition is that we were facing a case of overfitting. However, the validation loss was controlled in order to stop the training on time and avoid this problem. Another possibility would be that the two zones differ significantly and that a model trained on one cannot apply on the other. Hence, we also split the tiles randomly between the training and the inference-only zone. The gap between the balanced F1 score of the training and inference-only zone passed from 0.25 to 0.19 with the same hyper-parameters. The high recall for artificial roads indicates that the model properly detects them. However, once the artificial recall is high, the high artificial precision is in this case necessarily due. As the roads have a known location, the false positives not due to a class confusion are eliminated from our assessment. Then, only the roads classified in the wrong class can affect precision. As there are not a lot of natural roads, even if they were all wrongly classified as artificial like in the BLM, the precision would still remain well at 0.97. In the current case, the precision of the trained model is 0.01 higher than the one of the BLM. The drop in the natural F1 score is due to all the roads predicted in the wrong class. As they are only a few natural roads, errors of the model affect them more heavily. The part of the misclassified road increased by 44% between the training and the inference-only zone. Meanwhile, the part of undetermined roads only increased by 1% The F1 score could maybe be further improved by focusing more strictly on the 3m roads. Indeed, we considered it would be safer to teach the algorithm to differentiate only between surfaces and not between road types, which are defined by width. Therefore, the tiles were selected because they intersected 3m roads, but then all the roads on the tiles were transformed into labels. Because of the rarity of 3m natural roads, most of the natural roads seen by the algorithm are 2m roads and those often have a surface with grass, where the 3m natural roads have a surface made only of gravel or dirt. Over the training zone, 110 natural roads are 3m ones and 1183 ones are 2 m and 1 m paths. Maybe, labelling only the 3m roads would give better results than labelling all the visible roads. We did not tune the hyperparameter used by the deep learning model once we found a satisfying enough combination. In addition, as the algorithm is based on detectron2, not everything can easily be tuned. Using an entirely new framework and tuning the loss weights would allow better handling the class imbalance. A new framework could also allow integrating an attention mask and take advantage of the known road location like recommended by Epel (2018) 15 . Using a new framework could also allow to use images with 4 bands and integrating the NIR. However, we decided here to first try the tools we already had in our team. We can say that there is a bias in the model encouraging it to predict artificial roads. However, it is still better than the BLM. Therefore, this model is adapted for its purpose.","title":"5.3. Discussion"},{"location":"PROJ-ROADSURF/#6-conclusion","text":"Keeping the swissTLM3D dataset up to date is a time consuming and methodical task. This project aimed at finding a method to automatize the determination of the road surface type (artificial vs. natural). We focused on roads belonging to the \"3m Strasse\" class and discovered that statistics stemming from pixel values are not enough discriminating to tell artificial roads from natural ones. Therefore, we decided not to attempt any supervised classification based on machine learning. Instead, deep learning methods are performed. With 93% of the roads classified correctly, this method gave better results in regard to the global F1 score than a baseline model classifying all the roads as artificial. However, the model classifies 4.2% of the roads in the wrong class and has difficulties performing new zones. To ensure the quality of the swissTLM3D product, we advise to first perform a classification with the algorithm, then to check roads with a low class index or a change in surface type compared to the previous version years. It could represent a huge time saver for the operators who currently classify and check a second time all the roads. Despite our investigations, we could not find the cause of the gap between the metrics for the training and the inference-only zone. Further investigation is needed. The next step for this project would be to extend the algorithm to paths of 1 to 2 m wide. The natural roads of 3 m are mostly made of gravel, which strongly resembles asphalt, while natural paths are mostly made of dirt and can grow grass. Therefore, when mixing the two road width classes in one model, the natural roads of 3 m could be too difficult to distinguish from artificial roads and end up neglected.","title":"6. Conclusion"},{"location":"PROJ-ROADSURF/#7-references","text":"Office f\u00e9d\u00e9ral de la statistique. Longueur des routes en 2020 | Office f\u00e9d\u00e9ral de la statistique. https://www.bfs.admin.ch/news/fr/2020-0273, November 2020. \u21a9 swisstopo. swissTLM3D. https://www.swisstopo.admin.ch/de/geodata/landscape/tlm3d.html. \u21a9 \u21a9 Lushan Cheng, Xu Zhang, and Jie Shen. Road surface condition classification using deep learning. Journal of Visual Communication and Image Representation , 64:102638, October 2019. doi:10.1016/j.jvcir.2019.102638 . \u21a9 Susi Marianingsih, Fitri Utaminingrum, and Fitra Abdurrachman Bachtiar. Road Surface Types Classification Using Combination of K-Nearest Neighbor and Na\u00efve Bayes Based on GLCM. International Journal of Advanced Software Computer Application , 11(2):15\u201327, 2019. \u21a9 Marcus Nolte, Nikita Kister, and Markus Maurer. Assessment of Deep Convolutional Neural Networks for Road Surface Classification. In 2018 21st International Conference on Intelligent Transportation Systems (ITSC) , 381\u2013386. Maui, HI, November 2018. IEEE. doi:10.1109/ITSC.2018.8569396 . \u21a9 Viktor Slavkovikj, Steven Verstockt, Wesley De Neve, Sofie Van Hoecke, and Rik Van De Walle. Image-Based Road Type Classification. In 2014 22nd International Conference on Pattern Recognition , 2359\u20132364. Stockholm, August 2014. IEEE. doi:10.1109/ICPR.2014.409 . \u21a9 Mohammad Mansourmoghaddam, Hamid Reza Ghafarian Malamiri, Fahime Arabi Aliabad, Mehdi Fallah Tafti, Mohamadreza Haghani, and Saeed Shojaei. The Separation of the Unpaved Roads and Prioritization of Paving These Roads Using UAV Images. Air, Soil and Water Research , 15:117862212210862, January 2022. doi:10.1177/11786221221086285 . \u21a9 Hailing Zhou, Hui Kong, Lei Wei, Douglas Creighton, and Saeid Nahavandi. On Detecting Road Regions in a Single UAV Image. IEEE Transactions on Intelligent Transportation Systems , 18(7):1713\u20131722, July 2017. doi:10.1109/TITS.2016.2622280 . \u21a9 swisstopo. SWISSIMAGE RS. https://www.swisstopo.admin.ch/fr/geodata/images/ortho/swissimage-rs.html. \u21a9 TiTiler. https://developmentseed.org/titiler/. \u21a9 Vincent Sarago, Sean Harkins, and Drew Bollinger. Developmentseed / mosaicjson-spec. https://github.com/developmentseed/mosaicjson-spec, 2021. \u21a9 Yongquan Zhao and Zhe Zhu. ASI: An artificial surface Index for Landsat 8 imagery. International Journal of Applied Earth Observation and Geoinformation , 107:102703, March 2022. doi:10.1016/j.jag.2022.102703 . \u21a9 Ronald C. Estoque and Yuji Murayama. Classification and change detection of built-up lands from Landsat-7 ETM+ and Landsat-8 OLI/TIRS imageries: A comparative assessment of various spectral indices. Ecological Indicators , 56:205\u2013217, September 2015. doi:10.1016/j.ecolind.2015.03.037 . \u21a9 \u21a9 Swiss Territorial Data Lab. Object detector. February 2023. URL: https://github.com/swiss-territorial-data-lab/object-detector . \u21a9 Sagi Eppel. Classifying a specific image region using convolutional nets with an ROI mask as input. December 2018. arXiv:1812.00291 . \u21a9","title":"7. References"},{"location":"PROJ-TGLN/","text":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau \u00b6 Adrian Meyer (FHNW) Contributions to Background & Agricultural Law: Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGOBJ March 2021 to June 2021 - Published on July 7, 2021 Abstract : The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. 1 Introduction \u00b6 1.1 Background \u00b6 Switzerland's direct payment system is the basis for sustainable, market-oriented agriculture. The federal government supports local farms in the form of various types of contributions and enables farming families to claim an adequate income. (cf. Art. 104 BV) In the years 2014-2017 a new agricultural policy system was introduced in Switzerland. With specialized direct payment subsidies named \u00abLandscape Quality Contributions\u00bb (\u00abLQ\u00bb, Landschaftsqualit\u00e4tsbeitr\u00e4ge in German, Contributions \u00e0 la qualit\u00e9 du paysage in French) farms and agricultural businesses can be awarded for complying with measures that aim at increasing biodiversity and maintaining extensively cultivated open grasslands. Subsidies are calculated by area and the agricultural offices of the respective cantonal administration have to constantly monitor the landscape status as well as the compliance of the business operations in order to approve the requested amounts. Only certain land usage profiles are eligible for subsidies payment. According to Art. 104 \u00a71 BV, the agricultural sector, for its part, has to make a substantial decisive contribution to: Secure the supply of the population with goods and aliments. Preserve of the natural foundations of life and maintain the cultural landscape. Allow decentralized settlement throughout the territorial area. In order to be able to claim direct payments, farms are subject to various conditions. The Cultivable agricultural area layer (\u00abLN\u00bb, from German Landwirtschaftliche Nutzfl\u00e4che) is a GIS product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of contributions. (cf. Art. 35 DZV). The registration and adjustment of the LN is part of the periodic update (\u00abPNF\u00bb, Periodische Nachf\u00fchrung) within the framework of the official cadastral survey (\u00abAV\u00bb, Amtliche Vermessung) and is usually carried out every 6 years (Gamma 2021). Its correct determination is of immense importance, because if the LN area derived from the cadastral survey data deviates from the actual conditions on site, incorrect contribution amounts may be paid out (swisstopo/BLW/BUWAL 2000). Farm areas that are not eligible for contributions, in particular areas that are not usable for effective agriculture such as farmyards or storage areas (e.g. for silage hay bales), are constantly changing due to the high degree of mechanization in agriculture and often fall within the perimeter of the LN. The tracking of these areas with conventional surveying such as repeated field visits or the visual interpretation of current aerial imagery proves to be very time-consuming and costly. Possible alternative approaches are searched for in the context of this use case project. Artificial neural networks based on Deep Learning (DL) have been used for automated detection and classification of image features for quite some time. Reliable detection from aerial imagery using applications of DL would enable cost-effective detection of uneligible areas and provide added value to agricultural offices in all cantons. The Swiss Territorial Data Lab (STDL) is a project of co-creation and a space of experimentation which aims to solve concrete problems of public administrations by using data science applied to geodata. These characteristics make it the perfect environment to conduct this project. Research in the agricultural domain was already lead by project's partners at Fachhochschule Nordwestschweiz (FHNW) using machine learning. Furthermore, students are regularly involved in these projects, for example to automatically define the agricultural cultivation boundaries in collaboration with the Canton of Thurgau. 1.2 Silage Bales \u00b6 Photo of wrapped and stacked silage hay bales (Source Wikimedia). One of several features of interest specifically excluded from the subsidized cultivable LN area are silage hay bales. These bales are processed and compacted fermenting grass cuttings wrapped in plastic foil. They often roughly measure 1 - 2 cubic meters in volume and are weighed in at around 900kg. They are mainly used as animal food during winter when no fresh hay is available. Farmers are encouraged to compactly (\u00abdiscretely\u00bb) stack them in regular piles at few locations rather than keeping them in scattered collections consuming large areas. The agricultural office can assess the silage bale stack locations and sizes in order to approve the application for subsidies, since areas where silage bales are stored do not count into the cultivable LN area. Farmers can specify those areas where they must not receive contributions for in a specialized webGIS system by digitizing them manually with the attribute \u00abcode 898\u00bb. For validation purposes specialists are manually evaluating aerial imagery and conduct field visits. The process of aerial imagery evaluation is arduous and monotonous and could therefore greatly profit from automatization. The agricultural office of the Canton of Thurgau (LWA) requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area. The delivered dataset should be compatible with their webGIS workflow and should be made available with new aquisitions of aerial imaging campaigns. Having such detections readily available would reduce the workload of the responsible official by directing the monitoring to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. This project therefore aims at the development of an efficient silage bale detection algorithm which offers a highly accurate performance and can be quickly deployed over imaged areas as large as the complete canton of Thurgau (approx. 992 km\u00b2). 2 Method \u00b6 2.1 Overview \u00b6 Sileage bale stacks are clearly visible on the newest 2019 layer of the 10cm Swissimage orthophoto provided by Swisstopo. A few hundred of these stacks were manually digitized as vector polygons with QGIS in a semi-automatic approach. Following the structure of the STDL Object Detection Framework, an Area of Interest (AoI) was defined (most of the cantonal area of Thurgau) and tiled into smaller quadratic images (tiles). Those tiles containing an intersecting overlap with an annotation were subsequently fed to a neural object detection network for training in a process known as Transfer Learning. A random portion of the dataset was kept aside from the training process in order to allow an unbiased evaluation of the detector performance. Multiple iterations were performed in order to find out near-optimal input parameters such as tile size, zoom level, or network- and training-specific variables termed \u00abhyperparameters\u00bb. All detector models were evaluated for their prediction perforwmance on the reserved test dataset. The best model was chosen by means of its optimal overall performance. This model was used in turn to perform a prediction operation (\u00abInference\u00bb) on all tiles comprising the AoI \u2013 thereby detecting silage hay bale stacks over the whole canton of Thurgau. Postprocessing included filtering the resulting polygons by a high confidence score threshold provided by the detector for each detection in order to reduce the risk of false positive results (misidentification of an object as a silage bale stack). Subsequently adjacent polygons on seperate tiles were merged by standard vector operations. A spatial intersection with the known LN layer was performed to identify the specific areas occupied by silage stacks which should not receive contributions but potentially did in last years rolling payout. Only stacks covering more than 50m2 of LN area are considered \u00abrelevant\u00bb for the final delivery which translates to the equivalent of max. 10 CHF subsidy payment difference. For completeness, all LN-intersecting polygons of detections covering at least 20m2 are included in the finaly delivery. Filtering can be undertaken easily on the end user side by sorting the features with along a precalculated area column. 2.2 Aerial Imagery \u00b6 The prototypical implementation uses the publically available Swissimage dataset. It was last flown for Thurgau in spring 2019 and offers a maximum spatial resolution of 10cm GSD (Ground Sampling Distance) at 3 year intervals. As the direct subsidies are paid out yearly the periodicity of Swissimage in theory is insufficient for annual use. In this case the high quality imagery on the one hand can serve as a proof of concept though. On the other hand the cantons have the option to order own flight campaigns to increase the periodicity of available aerial imagery if sufficient need can shown from several relevant administrative stakeholders. For our approach aerial images need to be downloaded as small quadratic subsamples of the orthomosaic called \u00abtiles\u00bb to be used in the Deep Learning process. The used tiling grid system follows the slippy map standard with an edge length of 256 pixels and a zoom level system which is derived from a quadaratic division on a mercator-projected world map (whole world equals zoom level = 0). A zoom level = 18 in this system would roughly equal to a ground sampling distance (GSD) of 60 cm. 2.3 Labels / Annotations \u00b6 As no conducive vector dataset for silage bale locations exists in Thurgau or other sources known at this point, the annotations for this use case had to be created manually by the data scientists at STDL. A specific labeling strategy to obtain such a dataset was therefore implemented. Using Swissimage 10cm as a WMS bound basemap in QGIS, a few rural areas throughout the canton of Thurgau were selected and initially approximately 200 stacks of silage bales were manually digitized as polygons. Clearly disjunct stacks were digitized as two separate polygons. For partially visible stacks only visible parts were included. Loose collection of bales were connected into one common polygon if the distances between the single bales were not exceeding the diameter of a single bale. Ground imprints where silage bales were previously stored were not included. Also shadows on the ground were not part of the polygon. Plastic membrane rests were not included unless they seemed to cover additional bales. Most bales were of circular shape with an approximate diameter of 1.2 \u2013 1.5 m, but also smaller rectangular ones were common. Colours ranged from mostly white or green tinted over still common dark green or grey to also more exotic variants such as pink, light blue and yellow (the latter three are related to a specific cancer awareness program). Image: Example of the annotation rules. With these initial 200 annotations a preliminary detector was trained on a relatively high zoom level (18, 60cm GSD, tiling grid at about 150m) and predictions were generated over the whole cantonal area (See section \u00abTraining\u00bb for details). Subsequently, the 300 highest scoring new predictions (all above 99.5%) were checked visually in QGIS, precisely corrected and then transferred into the training dataset. Image: Example of label annotations manually drawn (left and top), as well as semiautomatically generated (right) \u2013 the pixel structure of the detector is visible in the label. All tiles containing labels were checked visually again at full zoom and missing labels were created manually. The resulting annotation dataset consists of approximately 700 silage bale stacks. Image: Positions of the Silage Bale Labels (red) within the borders of Thurgau. 2.4 Training \u00b6 Training of the model was performed with the STDL Object Detection Framework. The technology is based on a Mask RCNN architecture implemented with the High-Level API Detectron2 and the Deep Learning framework Pytorch. Parallelisation is achieved with CUDA-enabled GPUs on the High-Performance Computing cluster at the FHNW server facility in Muttenz. The Mask RCNN Backbone is formed by a ResNet-50 implementation and is accompanied by a Feature Pyramid Network (FPN). This combination of code elements results in a neural network leveraging more than 40 Mio. parameters. The dataset consists of RGB images and feature regions represented by pixel masks superimposing the imagery in the shape of the silage bale stack vectors. Training is performed iteratively by presenting subsets of the tiled dataset to modify \u00abedge weights\u00bb in the network graph. Progress is measured step by step by statistically minimizing the loss functions. Only tiles containing masks (labels) can be trained. Two smaller subsets of all label containing tiles are reserved from the training set (TRN), so a total of 70% of the trainable tiles are presented to the network for loss minimization. The validation set (VAL, 15%) and the test set (TST, 15%) also contain labels but are statistically independent from the TRN set. The VAL set is used to perform recurrent evaluation during training. Training can be stopped if the loss function on the validation set has reached a minimum since after that point further training would push the model into an overfitting scenario. The TST set serves as an unbiased reserve to evaluate the detector performance on previously \u00abunseen\u00bb, but labelled data. Tiles not containing a label yet were classified into a separate class called \u00abother\u00bb (OTH). This dataset was only used for generating predictions. Image: Dataset Split \u2013 Grey tiles are only used in prediction (OTH); they do not contain any labels during training. The colourful tiles contain labels, but are scattered relatively sparsely. Green tiles are used for training the model weights (TRN); orange tiles validate the learning progress during training to avoid overfitting (VAL) and blue tiles are reserved for unbiased post-training evaluation (TST). Multiple training runs were performed not only to optimize the network-specific variables called \u00abhyper-parameters\u00bb (such as batch size, learning rate or momentum), but also to test which zoom level (spatial resolution) would yield the best results. 2.5 Prediction and Assessment \u00b6 For the TRN, VAL and TST subset, confusion matrix counts and classification metrics calculations can be performed since they offer a comparison with the digitized \u00abground truth\u00bb. For all subsets (including the rest of the canton as OTH), predictions are generated as vectors covering those areas of a tile that the detector algorithm identifies as target objects and therefore attributes a confidence score. In case of the label containing tiles, the overlap between the predictions and the labels can be checked. Is an overlap found between a label and a prediction this detection is considered a \u00abTrue Positive\u00bb (TP). If the detector missed a label entirely this label can be considered as \u00abFalse Negative\u00bb (FN). Did the detector predict a silage bale stack that was not present in the labelled data it is considered \u00abFalse Positive\u00bb (FP). On the unlabelled OTH tiles, all detections are by definition therefore considered FP. The counting of TPs, FPs and FNs on the TST subset allows the calculation of standard metrics such as precision (user accuracy), recall (producer accuracy) and F1 score (a common overall performance metric calculated as the harmonic mean of precision and recall). The counts, as well as the metrics can be plotted as function of the minimum confidence score threshold (THR) which can be set to an acceptable percentage for a certain detection task. A low threshold should generally yield fewer FN errors, while a high threshold should yield fewer FP detections. The best performing model by means of maximum F1 score was used to perform a prediction run over the entire cantonal surface area. 2.6 Post-Processing \u00b6 In order to obtain a consistent result dataset, detections need to be postprocessed. Firstly, the confidence score threshold operation is applied. Here, a comparatively high threshold can be used for this operation. \u00abMissing\u00bb the detection of a silage bale stack (FN) is not as costly for the analysis of the resulting dataset at the agricultural office as analyzing large numbers of FP detections would be. Also missing single individual silage bales is much less problematic than missing whole large stacks. These larger stacks are typically attributed with high confidence scores though and are therefore less likely to be missed. In some cases, silage bale stacks cross the tiling grid and are therefore detected on multiple images. This results in edge artifacts along the tile boundaries intersecting detections that should be unified. For this resaon adjacent detection polygons need to merged into a single polygon. This is achieved by first buffering all detections with a 1.5m radius (about the diameter of a single bale). Then all touching polygons are dissolved into a single feature. Afterwards, negative buffering with -1.5m radius is applied to restore the original boundary. This process also leads to an edge smoothing by planing the pixel step derived vector boundary into curves. Image: Example of adjacent detection polygons that need to be unified (buffer dissolved). Curve polygons contain a high number of vertex points, which is why a simplification operation can be performed afterwards. The intersection with the LN layer required a preparation of that dataset. First, the perimeters of all LN polygons in Thurgau, stemming from the cadastre, were intersected with the layer \"LN difference\". Areas which contained the attribute \"No LN\" in the difference layer were therefore removed, areas with the attribute \"LN\" or \"To be checked\" were kept or if necessary (if not yet available) added to the LN dataset. Areas excluded by farmers from the subsidy themself (so-called \"layer code 898\") were removed from the LN polygons. The silage bale detections were now intersected (clipped) with all remaining LN areas such that only those portions of the detections remained that were present within the LN perimeter. For all these leftover detection polygons, the area is calculated and added as an attribute to the polygon. With a threshold operation all silo bale stacks with an area below 20 m2 are filtered out of the dataset in order to provide only economically relevant detections. 3 Results \u00b6 3.1 Metrics and Evaluation \u00b6 Figure: Performance of serveral detectors depending on zoom level (ground sampling distance) as measured by their maximum F1-Score. The model trained with tiles at zoom level = 19 (every pixel approx. 30cm GSD) showed the highest performance with a maximum F1 Score of 92.3%. Increasing the resolution even further by using 15 cm/px GSD did not result in a gain in overall detection performance while drastically increasing storage needs and computational load. Figure: Confusion matrix counts on the TST dataset in dependency of the minimum confidence score threshold. The detector model is performing very well on the independent TST dataset detecting the largest portion of silage bale stacks at any given confidence threshold. The number of FP reaches very low counts towards the higher end of the threshold percentage. Figure: Performance metrics on the TST dataset as a function of the minimum confidence score threshold. Precision, Recall and F1 Score all remain on very performant values throughout the threshold range. The F1 Score plateaus above 90% performance between 5% and 93% essentially allowing to choose any given threshold value to adapt the model performance to the end user needs. For delivery of the dataset a detector was subsequently used at a threshold of 96%. At this value 809 silage bale stacks were rediscovered in the TRN, TST and VAL subset. Just 10 FP detections were found in these subsets. 97 silage bale stacks were not rediscovered (FN). Hence, the model precision (user accuracy) was set at approx. 99% and the recall (hit rate, producer accuracy) was set at approx. 89%. The applied model detected a total of 2\u2019473 additional silage bale stacks over the rest of the canton of Thurgau (FP on OTH). 3.2 Examples \u00b6 Image: Raw detections (yellow) of silage bale stacks displaying very high confidence scores. Image: Raw detections (yellow) and postprocessed detections (red) \u2013 the area occupied by these silage bale stacks does not interesect with the Cultivable land (LN, green hatched). Direct subsidies are correctly paid out in this case. 3.3 Relevant Features for Delivery \u00b6 In total, 288 silage bale stack sections are placed within the subsidized LN area and exhibit an area consumption larger than 20m\u00b2. 87 silage bale stacks consume more than 50m\u00b2, 24 stacks consume more than 100m\u00b2. One has to keep in mind that many stacks only partially intersect with the LN layer. The overlap between all detected silage bale stacks over 20m\u00b2 and the LN layer amounts to 14\u2019200m\u00b2 or an estimated damage between CHF 1'420.- and CHF 2'840.- (assuming the subsidy payout ranges between CHF 10.- and CHF 20.- per 100m\u00b2). Considering only the overlap of the 87 largest stacks with the LN layer the area consumption amounts to 7\u2019900m\u00b2 or a damage between CHF 790.- and CHF 1'580.-. Image: Undeclared silage bale stack (red and yellow) that intersects with the cultivable land layer \u00abLN\u00bb (green). Image: The left side silage bale stack (red) is only touching the LN area (green). The center bottom silage bale stack is completely undeclared within the LN area. Image: Approximately half of the center silage bale stack (red) is undeclared and situated within the LN area. Image: This farm selfdeclared almost all areas needed (blue) for silage bales (red) to be excluded from direct subsidies areas (green). Pink areas are already pre-excluded by the agricultural office. Image: The intersection between the silage bale stack (red) and the LN area (green) is so minute, that it should not be found within the delivery dataset to the agricultural office. Image: Small silage bale stacks in the very left and very right of the image (yellow) are undeclared but each detection falls below the relevance threshold. 4 Discussion \u00b6 4.1 Feedback by the Agricultural Office \u00b6 The contact person at the agricultural office, Mr. T. Froehlich describes the detections as very accurate with a very low percentage of wrong detections. As a GIS product the detections layer can be used in the standard workflow in order to cross-check base datasets or to perform updates and corrections. On an economical scale the damage from misplaced sileage bale stacks in the LN areas is not negligible but also not extremely relevant. Federal annual direct agricultural subsidies of approx. 110 Mio. CHF stand in stark contrast to the estimated economical damage of maybe approx. CHF 2'000.- that misplaced silage bales might have caused for the Canton of Thurgau in 2019. Most farmers adhere to the policies and false declaration of areas followed by sanctions is extremely rare. Silage bales are therefore not the first priority when monitoring the advancements and updates considering the LN layer. Nevertheless these new detections allow the end users at the agricultural office to direct their eyes more quickly at relevant hotspots and spare them some aspects of the long and tidious manual search that was performed in the past. 4.2 Outlook \u00b6 Silage bales are by far not the only object limiting the extent of the cultivable subsidized land. A much larger area is consumed by farm yards \u2013 heterogenous spaces around the central farm buildings. Monitoring the growth of these spaces into the LN layer would greatly diminuish the manual workload at the agricultural office. As these spaces might also be detectable by a similar approach, this project will continue to investigate the potential of the STDL Object Detection Framework now into this direction. References \u00b6 Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau"},{"location":"PROJ-TGLN/#updating-the-cultivable-area-layer-of-the-agricultural-office-canton-of-thurgau","text":"Adrian Meyer (FHNW) Contributions to Background & Agricultural Law: Pascal Salath\u00e9 (FHNW) Proposed by the Canton of Thurgau - PROJ-TGOBJ March 2021 to June 2021 - Published on July 7, 2021 Abstract : The Cultivable agricultural area layer (\"LN, Landwirtschaftliche Nutzfl\u00e4che\") is a GIS vector product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of direct subsidy contributions to farms. The canton of Thurgau requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area, since areas used for silage bale storage are not eligible for subsidies. Having detections of such objects readily available greatly reduces the workload of the responsible official by directing the monitoring process to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions.","title":"Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau"},{"location":"PROJ-TGLN/#1-introduction","text":"","title":"1    Introduction"},{"location":"PROJ-TGLN/#11-background","text":"Switzerland's direct payment system is the basis for sustainable, market-oriented agriculture. The federal government supports local farms in the form of various types of contributions and enables farming families to claim an adequate income. (cf. Art. 104 BV) In the years 2014-2017 a new agricultural policy system was introduced in Switzerland. With specialized direct payment subsidies named \u00abLandscape Quality Contributions\u00bb (\u00abLQ\u00bb, Landschaftsqualit\u00e4tsbeitr\u00e4ge in German, Contributions \u00e0 la qualit\u00e9 du paysage in French) farms and agricultural businesses can be awarded for complying with measures that aim at increasing biodiversity and maintaining extensively cultivated open grasslands. Subsidies are calculated by area and the agricultural offices of the respective cantonal administration have to constantly monitor the landscape status as well as the compliance of the business operations in order to approve the requested amounts. Only certain land usage profiles are eligible for subsidies payment. According to Art. 104 \u00a71 BV, the agricultural sector, for its part, has to make a substantial decisive contribution to: Secure the supply of the population with goods and aliments. Preserve of the natural foundations of life and maintain the cultural landscape. Allow decentralized settlement throughout the territorial area. In order to be able to claim direct payments, farms are subject to various conditions. The Cultivable agricultural area layer (\u00abLN\u00bb, from German Landwirtschaftliche Nutzfl\u00e4che) is a GIS product maintained by the cantonal agricultural offices and serves as the key calculation index for the receipt of contributions. (cf. Art. 35 DZV). The registration and adjustment of the LN is part of the periodic update (\u00abPNF\u00bb, Periodische Nachf\u00fchrung) within the framework of the official cadastral survey (\u00abAV\u00bb, Amtliche Vermessung) and is usually carried out every 6 years (Gamma 2021). Its correct determination is of immense importance, because if the LN area derived from the cadastral survey data deviates from the actual conditions on site, incorrect contribution amounts may be paid out (swisstopo/BLW/BUWAL 2000). Farm areas that are not eligible for contributions, in particular areas that are not usable for effective agriculture such as farmyards or storage areas (e.g. for silage hay bales), are constantly changing due to the high degree of mechanization in agriculture and often fall within the perimeter of the LN. The tracking of these areas with conventional surveying such as repeated field visits or the visual interpretation of current aerial imagery proves to be very time-consuming and costly. Possible alternative approaches are searched for in the context of this use case project. Artificial neural networks based on Deep Learning (DL) have been used for automated detection and classification of image features for quite some time. Reliable detection from aerial imagery using applications of DL would enable cost-effective detection of uneligible areas and provide added value to agricultural offices in all cantons. The Swiss Territorial Data Lab (STDL) is a project of co-creation and a space of experimentation which aims to solve concrete problems of public administrations by using data science applied to geodata. These characteristics make it the perfect environment to conduct this project. Research in the agricultural domain was already lead by project's partners at Fachhochschule Nordwestschweiz (FHNW) using machine learning. Furthermore, students are regularly involved in these projects, for example to automatically define the agricultural cultivation boundaries in collaboration with the Canton of Thurgau.","title":"1.1 Background"},{"location":"PROJ-TGLN/#12-silage-bales","text":"Photo of wrapped and stacked silage hay bales (Source Wikimedia). One of several features of interest specifically excluded from the subsidized cultivable LN area are silage hay bales. These bales are processed and compacted fermenting grass cuttings wrapped in plastic foil. They often roughly measure 1 - 2 cubic meters in volume and are weighed in at around 900kg. They are mainly used as animal food during winter when no fresh hay is available. Farmers are encouraged to compactly (\u00abdiscretely\u00bb) stack them in regular piles at few locations rather than keeping them in scattered collections consuming large areas. The agricultural office can assess the silage bale stack locations and sizes in order to approve the application for subsidies, since areas where silage bales are stored do not count into the cultivable LN area. Farmers can specify those areas where they must not receive contributions for in a specialized webGIS system by digitizing them manually with the attribute \u00abcode 898\u00bb. For validation purposes specialists are manually evaluating aerial imagery and conduct field visits. The process of aerial imagery evaluation is arduous and monotonous and could therefore greatly profit from automatization. The agricultural office of the Canton of Thurgau (LWA) requested a spatial vector layer indicating locations and area consumption extent of the largest silage bale deposits intersecting with the known LN area. The delivered dataset should be compatible with their webGIS workflow and should be made available with new aquisitions of aerial imaging campaigns. Having such detections readily available would reduce the workload of the responsible official by directing the monitoring to the relevant hotspots. Ultimately public economical damage can be prevented which would result from the payout of unjustified subsidy contributions. This project therefore aims at the development of an efficient silage bale detection algorithm which offers a highly accurate performance and can be quickly deployed over imaged areas as large as the complete canton of Thurgau (approx. 992 km\u00b2).","title":"1.2 Silage Bales"},{"location":"PROJ-TGLN/#2-method","text":"","title":"2    Method"},{"location":"PROJ-TGLN/#21-overview","text":"Sileage bale stacks are clearly visible on the newest 2019 layer of the 10cm Swissimage orthophoto provided by Swisstopo. A few hundred of these stacks were manually digitized as vector polygons with QGIS in a semi-automatic approach. Following the structure of the STDL Object Detection Framework, an Area of Interest (AoI) was defined (most of the cantonal area of Thurgau) and tiled into smaller quadratic images (tiles). Those tiles containing an intersecting overlap with an annotation were subsequently fed to a neural object detection network for training in a process known as Transfer Learning. A random portion of the dataset was kept aside from the training process in order to allow an unbiased evaluation of the detector performance. Multiple iterations were performed in order to find out near-optimal input parameters such as tile size, zoom level, or network- and training-specific variables termed \u00abhyperparameters\u00bb. All detector models were evaluated for their prediction perforwmance on the reserved test dataset. The best model was chosen by means of its optimal overall performance. This model was used in turn to perform a prediction operation (\u00abInference\u00bb) on all tiles comprising the AoI \u2013 thereby detecting silage hay bale stacks over the whole canton of Thurgau. Postprocessing included filtering the resulting polygons by a high confidence score threshold provided by the detector for each detection in order to reduce the risk of false positive results (misidentification of an object as a silage bale stack). Subsequently adjacent polygons on seperate tiles were merged by standard vector operations. A spatial intersection with the known LN layer was performed to identify the specific areas occupied by silage stacks which should not receive contributions but potentially did in last years rolling payout. Only stacks covering more than 50m2 of LN area are considered \u00abrelevant\u00bb for the final delivery which translates to the equivalent of max. 10 CHF subsidy payment difference. For completeness, all LN-intersecting polygons of detections covering at least 20m2 are included in the finaly delivery. Filtering can be undertaken easily on the end user side by sorting the features with along a precalculated area column.","title":"2.1 Overview"},{"location":"PROJ-TGLN/#22-aerial-imagery","text":"The prototypical implementation uses the publically available Swissimage dataset. It was last flown for Thurgau in spring 2019 and offers a maximum spatial resolution of 10cm GSD (Ground Sampling Distance) at 3 year intervals. As the direct subsidies are paid out yearly the periodicity of Swissimage in theory is insufficient for annual use. In this case the high quality imagery on the one hand can serve as a proof of concept though. On the other hand the cantons have the option to order own flight campaigns to increase the periodicity of available aerial imagery if sufficient need can shown from several relevant administrative stakeholders. For our approach aerial images need to be downloaded as small quadratic subsamples of the orthomosaic called \u00abtiles\u00bb to be used in the Deep Learning process. The used tiling grid system follows the slippy map standard with an edge length of 256 pixels and a zoom level system which is derived from a quadaratic division on a mercator-projected world map (whole world equals zoom level = 0). A zoom level = 18 in this system would roughly equal to a ground sampling distance (GSD) of 60 cm.","title":"2.2 Aerial Imagery"},{"location":"PROJ-TGLN/#23-labels-annotations","text":"As no conducive vector dataset for silage bale locations exists in Thurgau or other sources known at this point, the annotations for this use case had to be created manually by the data scientists at STDL. A specific labeling strategy to obtain such a dataset was therefore implemented. Using Swissimage 10cm as a WMS bound basemap in QGIS, a few rural areas throughout the canton of Thurgau were selected and initially approximately 200 stacks of silage bales were manually digitized as polygons. Clearly disjunct stacks were digitized as two separate polygons. For partially visible stacks only visible parts were included. Loose collection of bales were connected into one common polygon if the distances between the single bales were not exceeding the diameter of a single bale. Ground imprints where silage bales were previously stored were not included. Also shadows on the ground were not part of the polygon. Plastic membrane rests were not included unless they seemed to cover additional bales. Most bales were of circular shape with an approximate diameter of 1.2 \u2013 1.5 m, but also smaller rectangular ones were common. Colours ranged from mostly white or green tinted over still common dark green or grey to also more exotic variants such as pink, light blue and yellow (the latter three are related to a specific cancer awareness program). Image: Example of the annotation rules. With these initial 200 annotations a preliminary detector was trained on a relatively high zoom level (18, 60cm GSD, tiling grid at about 150m) and predictions were generated over the whole cantonal area (See section \u00abTraining\u00bb for details). Subsequently, the 300 highest scoring new predictions (all above 99.5%) were checked visually in QGIS, precisely corrected and then transferred into the training dataset. Image: Example of label annotations manually drawn (left and top), as well as semiautomatically generated (right) \u2013 the pixel structure of the detector is visible in the label. All tiles containing labels were checked visually again at full zoom and missing labels were created manually. The resulting annotation dataset consists of approximately 700 silage bale stacks. Image: Positions of the Silage Bale Labels (red) within the borders of Thurgau.","title":"2.3 Labels / Annotations"},{"location":"PROJ-TGLN/#24-training","text":"Training of the model was performed with the STDL Object Detection Framework. The technology is based on a Mask RCNN architecture implemented with the High-Level API Detectron2 and the Deep Learning framework Pytorch. Parallelisation is achieved with CUDA-enabled GPUs on the High-Performance Computing cluster at the FHNW server facility in Muttenz. The Mask RCNN Backbone is formed by a ResNet-50 implementation and is accompanied by a Feature Pyramid Network (FPN). This combination of code elements results in a neural network leveraging more than 40 Mio. parameters. The dataset consists of RGB images and feature regions represented by pixel masks superimposing the imagery in the shape of the silage bale stack vectors. Training is performed iteratively by presenting subsets of the tiled dataset to modify \u00abedge weights\u00bb in the network graph. Progress is measured step by step by statistically minimizing the loss functions. Only tiles containing masks (labels) can be trained. Two smaller subsets of all label containing tiles are reserved from the training set (TRN), so a total of 70% of the trainable tiles are presented to the network for loss minimization. The validation set (VAL, 15%) and the test set (TST, 15%) also contain labels but are statistically independent from the TRN set. The VAL set is used to perform recurrent evaluation during training. Training can be stopped if the loss function on the validation set has reached a minimum since after that point further training would push the model into an overfitting scenario. The TST set serves as an unbiased reserve to evaluate the detector performance on previously \u00abunseen\u00bb, but labelled data. Tiles not containing a label yet were classified into a separate class called \u00abother\u00bb (OTH). This dataset was only used for generating predictions. Image: Dataset Split \u2013 Grey tiles are only used in prediction (OTH); they do not contain any labels during training. The colourful tiles contain labels, but are scattered relatively sparsely. Green tiles are used for training the model weights (TRN); orange tiles validate the learning progress during training to avoid overfitting (VAL) and blue tiles are reserved for unbiased post-training evaluation (TST). Multiple training runs were performed not only to optimize the network-specific variables called \u00abhyper-parameters\u00bb (such as batch size, learning rate or momentum), but also to test which zoom level (spatial resolution) would yield the best results.","title":"2.4 Training"},{"location":"PROJ-TGLN/#25-prediction-and-assessment","text":"For the TRN, VAL and TST subset, confusion matrix counts and classification metrics calculations can be performed since they offer a comparison with the digitized \u00abground truth\u00bb. For all subsets (including the rest of the canton as OTH), predictions are generated as vectors covering those areas of a tile that the detector algorithm identifies as target objects and therefore attributes a confidence score. In case of the label containing tiles, the overlap between the predictions and the labels can be checked. Is an overlap found between a label and a prediction this detection is considered a \u00abTrue Positive\u00bb (TP). If the detector missed a label entirely this label can be considered as \u00abFalse Negative\u00bb (FN). Did the detector predict a silage bale stack that was not present in the labelled data it is considered \u00abFalse Positive\u00bb (FP). On the unlabelled OTH tiles, all detections are by definition therefore considered FP. The counting of TPs, FPs and FNs on the TST subset allows the calculation of standard metrics such as precision (user accuracy), recall (producer accuracy) and F1 score (a common overall performance metric calculated as the harmonic mean of precision and recall). The counts, as well as the metrics can be plotted as function of the minimum confidence score threshold (THR) which can be set to an acceptable percentage for a certain detection task. A low threshold should generally yield fewer FN errors, while a high threshold should yield fewer FP detections. The best performing model by means of maximum F1 score was used to perform a prediction run over the entire cantonal surface area.","title":"2.5 Prediction and Assessment"},{"location":"PROJ-TGLN/#26-post-processing","text":"In order to obtain a consistent result dataset, detections need to be postprocessed. Firstly, the confidence score threshold operation is applied. Here, a comparatively high threshold can be used for this operation. \u00abMissing\u00bb the detection of a silage bale stack (FN) is not as costly for the analysis of the resulting dataset at the agricultural office as analyzing large numbers of FP detections would be. Also missing single individual silage bales is much less problematic than missing whole large stacks. These larger stacks are typically attributed with high confidence scores though and are therefore less likely to be missed. In some cases, silage bale stacks cross the tiling grid and are therefore detected on multiple images. This results in edge artifacts along the tile boundaries intersecting detections that should be unified. For this resaon adjacent detection polygons need to merged into a single polygon. This is achieved by first buffering all detections with a 1.5m radius (about the diameter of a single bale). Then all touching polygons are dissolved into a single feature. Afterwards, negative buffering with -1.5m radius is applied to restore the original boundary. This process also leads to an edge smoothing by planing the pixel step derived vector boundary into curves. Image: Example of adjacent detection polygons that need to be unified (buffer dissolved). Curve polygons contain a high number of vertex points, which is why a simplification operation can be performed afterwards. The intersection with the LN layer required a preparation of that dataset. First, the perimeters of all LN polygons in Thurgau, stemming from the cadastre, were intersected with the layer \"LN difference\". Areas which contained the attribute \"No LN\" in the difference layer were therefore removed, areas with the attribute \"LN\" or \"To be checked\" were kept or if necessary (if not yet available) added to the LN dataset. Areas excluded by farmers from the subsidy themself (so-called \"layer code 898\") were removed from the LN polygons. The silage bale detections were now intersected (clipped) with all remaining LN areas such that only those portions of the detections remained that were present within the LN perimeter. For all these leftover detection polygons, the area is calculated and added as an attribute to the polygon. With a threshold operation all silo bale stacks with an area below 20 m2 are filtered out of the dataset in order to provide only economically relevant detections.","title":"2.6 Post-Processing"},{"location":"PROJ-TGLN/#3-results","text":"","title":"3    Results"},{"location":"PROJ-TGLN/#31-metrics-and-evaluation","text":"Figure: Performance of serveral detectors depending on zoom level (ground sampling distance) as measured by their maximum F1-Score. The model trained with tiles at zoom level = 19 (every pixel approx. 30cm GSD) showed the highest performance with a maximum F1 Score of 92.3%. Increasing the resolution even further by using 15 cm/px GSD did not result in a gain in overall detection performance while drastically increasing storage needs and computational load. Figure: Confusion matrix counts on the TST dataset in dependency of the minimum confidence score threshold. The detector model is performing very well on the independent TST dataset detecting the largest portion of silage bale stacks at any given confidence threshold. The number of FP reaches very low counts towards the higher end of the threshold percentage. Figure: Performance metrics on the TST dataset as a function of the minimum confidence score threshold. Precision, Recall and F1 Score all remain on very performant values throughout the threshold range. The F1 Score plateaus above 90% performance between 5% and 93% essentially allowing to choose any given threshold value to adapt the model performance to the end user needs. For delivery of the dataset a detector was subsequently used at a threshold of 96%. At this value 809 silage bale stacks were rediscovered in the TRN, TST and VAL subset. Just 10 FP detections were found in these subsets. 97 silage bale stacks were not rediscovered (FN). Hence, the model precision (user accuracy) was set at approx. 99% and the recall (hit rate, producer accuracy) was set at approx. 89%. The applied model detected a total of 2\u2019473 additional silage bale stacks over the rest of the canton of Thurgau (FP on OTH).","title":"3.1 Metrics and Evaluation"},{"location":"PROJ-TGLN/#32-examples","text":"Image: Raw detections (yellow) of silage bale stacks displaying very high confidence scores. Image: Raw detections (yellow) and postprocessed detections (red) \u2013 the area occupied by these silage bale stacks does not interesect with the Cultivable land (LN, green hatched). Direct subsidies are correctly paid out in this case.","title":"3.2 Examples"},{"location":"PROJ-TGLN/#33-relevant-features-for-delivery","text":"In total, 288 silage bale stack sections are placed within the subsidized LN area and exhibit an area consumption larger than 20m\u00b2. 87 silage bale stacks consume more than 50m\u00b2, 24 stacks consume more than 100m\u00b2. One has to keep in mind that many stacks only partially intersect with the LN layer. The overlap between all detected silage bale stacks over 20m\u00b2 and the LN layer amounts to 14\u2019200m\u00b2 or an estimated damage between CHF 1'420.- and CHF 2'840.- (assuming the subsidy payout ranges between CHF 10.- and CHF 20.- per 100m\u00b2). Considering only the overlap of the 87 largest stacks with the LN layer the area consumption amounts to 7\u2019900m\u00b2 or a damage between CHF 790.- and CHF 1'580.-. Image: Undeclared silage bale stack (red and yellow) that intersects with the cultivable land layer \u00abLN\u00bb (green). Image: The left side silage bale stack (red) is only touching the LN area (green). The center bottom silage bale stack is completely undeclared within the LN area. Image: Approximately half of the center silage bale stack (red) is undeclared and situated within the LN area. Image: This farm selfdeclared almost all areas needed (blue) for silage bales (red) to be excluded from direct subsidies areas (green). Pink areas are already pre-excluded by the agricultural office. Image: The intersection between the silage bale stack (red) and the LN area (green) is so minute, that it should not be found within the delivery dataset to the agricultural office. Image: Small silage bale stacks in the very left and very right of the image (yellow) are undeclared but each detection falls below the relevance threshold.","title":"3.3 Relevant Features for Delivery"},{"location":"PROJ-TGLN/#4-discussion","text":"","title":"4    Discussion"},{"location":"PROJ-TGLN/#41-feedback-by-the-agricultural-office","text":"The contact person at the agricultural office, Mr. T. Froehlich describes the detections as very accurate with a very low percentage of wrong detections. As a GIS product the detections layer can be used in the standard workflow in order to cross-check base datasets or to perform updates and corrections. On an economical scale the damage from misplaced sileage bale stacks in the LN areas is not negligible but also not extremely relevant. Federal annual direct agricultural subsidies of approx. 110 Mio. CHF stand in stark contrast to the estimated economical damage of maybe approx. CHF 2'000.- that misplaced silage bales might have caused for the Canton of Thurgau in 2019. Most farmers adhere to the policies and false declaration of areas followed by sanctions is extremely rare. Silage bales are therefore not the first priority when monitoring the advancements and updates considering the LN layer. Nevertheless these new detections allow the end users at the agricultural office to direct their eyes more quickly at relevant hotspots and spare them some aspects of the long and tidious manual search that was performed in the past.","title":"4.1 Feedback by the Agricultural Office"},{"location":"PROJ-TGLN/#42-outlook","text":"Silage bales are by far not the only object limiting the extent of the cultivable subsidized land. A much larger area is consumed by farm yards \u2013 heterogenous spaces around the central farm buildings. Monitoring the growth of these spaces into the LN layer would greatly diminuish the manual workload at the agricultural office. As these spaces might also be detectable by a similar approach, this project will continue to investigate the potential of the STDL Object Detection Framework now into this direction.","title":"4.2 Outlook"},{"location":"PROJ-TGLN/#references","text":"Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"References"},{"location":"PROJ-TGPOOL/","text":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU \u00b6 Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL January 2021 to April 2021 - Published on April 21, 2021 Abstract : The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour. Introduction \u00b6 Until February 2021 the Swiss Territorial Data Lab developed an approach based on Mask RCNN Deep Learning algorithms for the detection of objects on aerial images, with swimming pools serving as a demonstration object. The official cadastres of the Canton of Thurgau include \u2013 among many other objects \u2013 the registration of larger private swimming pools that are permanently anchored in the ground. The challenge is to keep the cadastre up to date on a regular basis which is usually done manually by surveying or verification with aerial imagery. Because the Canton of Thurgau (unlike the Canton of Geneva) does not maintain an own specific register of swimming pools, this study primarily serves as a technology demonstration. A secondary goal encompasses detailed knowledge transfer from the data scientist team at the STDL to the cantonal authorities such as providing insight and interpretation guidance into the performance metrics and raising awareness for the prerequisites of the detector framework. Methodology \u00b6 Process Overview \u00b6 Generating a Model from Cadastral Vectors and Aerial Images to Predict Objects in the Same or a New Area of Interest (AoI). The STDL object detection framework is based on a bipartite approach of training and inference. This means that a predictive model is statistically adapted to known and verified data (\"training\") in order to then generate classification predictions on new, unknown data (\"inference\"). To achieve this we resample large high-resolution orthophoto mosaics by decomposing them into small square image tiles on which vectorized annotations of swimming pools are drawn. Verified vector annotation data (\"ground truth\") for the training process was available for the cantonal area of Geneva, as well as for a smaller part of the cantonal area of Neuch\u00e2tel covering a total of almost 5'000 swimming pools present in 2019. The predictive model used is a convolutional neural network developed for computer vision (Mask RCNN). It was trained on a high performance computing cluster at the University of Applied Sciences Northwestern Switzerland FHNW using the open source Detectron2 object detection library. During inference, pixel-precise vector contours (\u201csegments\u201d) are produced over the tiled imagery of the canton of Thurgau. Each segment is attributed a confidence score which indicates the certainty of the detections when applied to new data. Using this score as a threshold level, performance metrics are computed in post-classification assessment. Ground Truth Dataset \u00b6 Label annotations are derived from cadastral data and manually curated Vector ground truth annotations demarcating private swimming pools were available at two locations: A near-complete coverage of the cantonal area of Geneva which contains 4\u2019652 known objects, as well as a smaller subsection of the cantonal area of Neuchatel which contains 227 known objects. Label annotations in both cases are derived from cadastral surface vector datasets and then manually curated/verified. In case of the Geneva dataset the manual verification was performed by STDL data scientists in a previous study; in case of the Neuchatel dataset the manual verification was performed by the local cadastre experts. Reference Data and Area of Interest \u00b6 Approximately 5000 cross checked swimming pool annotations are available as vectorized shapes in the Cantons of Geneva and partially in Neuch\u00e2tel. They are compatible with orthophotos from 2018/19 such as the latest SWISSIMAGE 10cm layer. The Area of Interest (AoI) for all tests conducted in this study are divided into two main sections: Those areas in Geneva and Neuchatel containing vectorized ground truth labels are used as \u201cTraining AoI\u201d. The cantonal area of Thurgau is used as \u201cPrediction AoI\u201d. Only those parts of the cantonal surface of Thurgau are used as Prediction AoI which are designated as relevant settlement areas. For this purpose the STDL has received two additional reference datasets from the canton of Thurgau: Vector layer: List of all water basins from the official survey; 3'131 objects. Vector layer: Settlement areas / construction zones to delimit the study area. 2,895 objects from the water basin layer are located wholly or partially within the \u201cPrediction AoI\u201d. Only these objects were used for analysis (see Figure 4, light green objects). For each grid square, an image file with 256x256 pixels edge length and 60cm GSD was generated by WMS. Metadata and georeferencing were stored in an associated JSON. A quick qualitative review of the Thurgau datasets in QGIS revealed two limitations of the datasets. About 7,5% of the water basins are not located in the selected settlement area (e.g., on remote farmsteads or mixed industrial / commercial zones), so no detection attempt was initially undertaken for areas encompassing these objects. It is important to note that there are some objects in the water basin layer that are not comparable to private swimming pools in shape or size, such as public large scale swimming pools, but also sewage treatment plants, silos, tanks, reservoirs, or retention dams. By limiting the Prediction AoI to residential areas and adjacent land, the largest portion of these objects could be excluded. Example of a water treatment plant that appears in the \u201cwater basin layer\u201d and had to be excluded by limiting the \u201cPrediction AoI\u201d to residential and adjacent areas. To additionally calculate metrics on the quality of this reference dataset vs. the quality of the detections a small area over the city of Frauenfeld (Thurgau) containing approximately 100 swimming pools was manually curated and verified by the STDL data scientists. Orthocorrected Imagery \u00b6 Orthoimagery tiles of 150m/256px edge length containing labelled annotations Both AoIs are split by a regular checkerboard segmentation grid into squares (\u201ctiles\u201d), making use of the \u201cSlippy Map Tiles\u201d quadtree-style system. The image data used here was tested with different zoom level resampling resolutions (Ground Sampling Distance, GSD) between 30 cm and 480 cm edge length per pixel while maintaining a consistent extent of 256x256 pixels. Query of the imagery was undertaken using public web map services such using common protocols such as WMS or the MIL standard. Three separate imagery sources were used over the course of the study. The 10cm GSD RGB orthophotomosaic layer SWISSIMAGE of Swisstopo was the primary target of investigation as it was used as the basis of prediction generation over the cantonal area of Thurgau. SWISSIMAGE was also used as the imagery basis for most of the training test runs over the ground truth areas of Geneva and Neuchatel. Additionally, a model was trained leveraging combined cantonal orthophoto imagery from Geneva (SITG) and Neuchatel (SITN) to comparatively test the prediction performance of such a model on the unrelated SWISSIMAGE inference dataset in Thurgau. As it was known from the STDL\u2019s previous work, that the usage of tiles exhibiting a GSD of ~60cm/Px (tile zoom level 18) offered a decent tradeoff between reaching high accuracies during training while keeping computational effort manageable this approach was used for the test using the own cantonal imagery of Geneva and Neuchatel. Using SWISSIMAGE for training, zoom levels in a range between 15 (~480 cm/Px) and 19 (~30 cm/Px) were tested. Training \u00b6 Transfer Learning \u00b6 The choice of a relevant predictive approach fell on a \u201cCOCO-pretrained\u201d deep learning model of the type \"ResNet 50 FPN\" structured in a \u201cMask-RCNN\u201d architecture and implemented with Python and the Detectron2 API. In a transfer learning process about 44 million trainable statistical parameters are adapted (\u201cfinetuned\u201d) as edge weights in a pretrained neural network graph through a number of iterations trying to minimize the value of the so-called \u201closs function\u201d (which is a primary measure for inaccuracy in classification). Transfer Learning is common practice with Deep Learning models. The acquired knowledge gained from massive datasets allows an adaptation of the model to smaller new datasets. Training is performed through highly multithreaded GPU parallelisation of the necessary tensor / matrix operations to speed up training duration. For this purpose the vector annotations are converted into pixel-per-pixel binary masks which are aligned with the respective input image. Network- or Training-specific pre-set variables (\u201chyperparameters\u201d) such as learning rate, learning rate decay, optimizer momentum, batch size or weight decay were either used in their standard configuration or iteratively manually tuned until comparatively high accuracies (e.g. by means of the F1-Score) could be reached. More systematic approaches such as hyperparameter grid search or advanced (e.g. Bayesian) optimization strategies could be implemented in follow-up studies. Dataset Split \u00b6 Tiles falling into the \u201cTraining AoI\u201d but not exhibiting any intersecting area with the Ground Truth Labels are discarded. The remaining ground truth tile datasets are randomly sampled into three disjunct subsets: The \u201cTraining Subset\u201d consists of 70% of the ground truth tiles and is used to change the network graph edge weights. The \u201cValidation Subset\u201d consists of another 15% of the ground truth tiles and is used to validate the generalization performance of the network during training. The iteration cycling is stopped when the loss on the validation dataset is minimized. The \u201cTest Subset\u201d consists of the last 15% of the ground truth tiles and is entirely reserved from the training process to allow for independent and unbiased assessment in the post processing. Subdivision of Ground Truth Datasets Inference and Assessment \u00b6 After training, tile by tile the entire \u201cPrediction AoI\u201d as well as the ground truth datasets presented to the final model for prediction generation. From a minimum confidence threshold up to 100% the model produces a segmentation mask for each swimming pool detection delimiting its proposed outer boundary. This boundary can be vectorized and transformed back from image space into map coordinates during post-processing. Through this process we can accumulate a consistent GIS-compatible vector layer for visualization, counting and further analysis. In case of the ground truth data the resulting vector layer can be intersected with the original input data (especially the \u201cTest Subset\u201d) to obtain unbiased model performance metrics. In case of a well-performing model the resulting vector layer can then be intersected with the \u201cPrediction AoI\u201d-derived Thurgau dataset to identify missing or surplus swimming pools in the cadastre. Results \u00b6 Metrics and Model Selection \u00b6 Results of different training runs using SWISSIMAGE depending on the chosen zoom level The choice of a correct confidence threshold (\"THR\") is of central importance for the interpretation of the results. The division of a data set into true/false positives/negatives is a function of the confidence threshold. A high threshold means that the model is very confident of a detection; a low threshold means that as few detections as possible should be missed, but at the same time more false positive (\"FP\") detections should be triggered. Results of different training runs using SWISSIMAGE depending on the chosen zoom level There are several standardized metrics to evaluate model performance on unknown data. The most important are \"Precision\" (user accuracy), \"Recall\" (hit rate or producer accuracy) and \"F1 Score\" (the mathematical harmonic mean of the other two). \"Precision\" should increase with higher THR, \"Recall\" should decrease. The maximum F1 Score can be used as a measure of how well the model performs regardless of the viewing direction. Results of different training runs using SWISSIMAGE depending on the chosen zoom level Using the cantonal orthomosaics as training input with zoom level 18 the F1 Score reached a maximum of 81,0%. Using SWISSIMAGE as training input with zoom level 18 a slightly higher maximum F1 Score of 83,4% was achieved resulting in the choice of a \u201conly SWISSIMAGE\u201d approach for both, training and inference. The best detection by means of maximum F1 Score was reached using tiles with zoom level 19 displaying a GSD of approx. 30 cm/Px. Since the Slippy Map tile system is based on equal division of squares increasing the zoom level by one step results roughly in quadrupling the number of tiles presented for analysis. Hence also computational demand increases with an exponential factor in particular for file system read/write and sequential processing operations if the zoom level is increased. On the other hand increasing the zoom level (and therefor the GSD) also boosts visibility and size of the target objects which in turn increases detection accuracy. Comparatively slight increases in F1 Score between zoom levels 17, 18 and 19 suggest an asymptotic behaviour where the usage of massively higher amounts computing resources will not result in a much higher detection accuracy any longer. Zoom level 20 (GSD~15cm/Px) was not computed for this reason. True Positives \u00b6 A detection is considered \"True Positive\" (TP) if the algorithm detected a pool that was listed at the same position in the cadastral layer. Setting the threshold very low (THR \u2265 5%), 2'227 of 2\u2019959 swimming pools were detected. This corresponds to a detection proportion of 75% of the recorded water pools. Conversely, this could mean that 25% or 732 objects are False Negatives and therefore \"erroneously\" recorded in the cadastre as swimming pools or missed by the algorithm. \u201cTrue Positive\u201d detections \u2013 note that cases of empty and covered swimming pools are detected with a very high confidence threshold in this example. False Negatives \u00b6 FN describe those objects that the algorithm completely failed to detect, no matter what threshold is set. A total of 732 objects were not detected. FN easily occur when there are obvious discrepancies between orthophoto and cadastre - for example, a pool may have been constructed after the time of flight. The combined number from FN and TP corresponds to the number of analyzed labels from the water pool layer (2\u2019959 objects). Due to the splitting of pools at the segmentation grid boundaries, this value is slightly higher than the 2\u2019895 objects that were in the \u201cPrediction AoI\u201d. Here, only objects larger than 5m\u00b2 in area were counted, since the segmentation grid cuts some pools into several parts and tiny residual of only a few pixels in total area polygons might otherwise be counted as FN even though the largest part of a swimming pool was detected (and therefore counted as TP). \u201cFalse Negatives\u201d \u2013 (Left) An obvious mismatch between the cadastre and the orthophoto, an update should be considered. (Right) An ambiguous swimming pool which might be covered by a white canvas and was therefore missed by the detector. False Positives \u00b6 Swimming pools that were recognized as such in the orthophoto but are not found in the cadastre represent the FP group. If the threshold is set very low (e.g. THR \u2265 5%), a total of 9'427 additional pools would be found in the settlement area. However, this number is not realistic, since most of the detections at such a low threshold do not correspond to pools, but only mark image areas that are related to a pool in a very distant way. Therefore, to get a better estimation of objects that really represent private pools but are still missing in the cadastre, the choice of a very high threshold is recommended. For example, the geoinformation services of the Canton of Geneva work with a threshold of THR \u2265 97%. Applying this threshold, 271 unrecorded swimming pools remain in the dataset with an extremely high probability of correct redetection (9% of the cadastre). However, it is still worth looking at slightly less likely FP detections with a threshold of THR \u2265 90% here. Filtering with this value, a total of 672 unregistered swimming pools were found, which would correspond to 23% of the cadastre layer. At the same time the risk for clear errors by the object detector also increases at lower thresholds, leading to some misclassifications. \u201cFalse Positive\u201d detections \u2013 (Top) Two clear examples of detected swimming pools that are missing in the cadastre. (Bottom Left) More ambiguous examples of detected swimming pools which might be missing in the cadastre. (Bottom Right) A clear error of the detector misclassifying a photovoltaic installation as a swimming pool. Conclusion \u00b6 Manual Evaluation \u00b6 In the city of Frauenfeld a sample district was chosen for manual evaluation by a STDL data scientist. Even though this task should ideally be performed by a local expert this analysis does provide some insight on the potential errors currently existing within the cadastre as well as the object detection quality. Within the sampled area a total of 99 identifiable swimming pool objects were found to be present. Table: Manually evaluated dataset accuracy vs. detector performance comparison. Green indicates the preferred value. Overall, the STDL Detector was more accurate than the provided dataset with a F1 Score of ~90% vs. ~87%. Especially a lot fewer swimming pools (5 FN) were missing in the detections than in the cadastre (18 FN). Room for improvement exists with the False Positives, where our detector identified 16 surplus objects as potential swimming pools which could be falsified manually. At the same time only 9 surplus objects were found in the cadastre. Interpretation \u00b6 We can conclude that the use of annotation data gathered in another canton of Switzerland allows for highly accurate predictions in Thurgau using the freely and publicly available SWISSIMAGE dataset. We demonstrate that such a transferrable approach can therefore be applied within a relatively short time span to other cantons without the effort of manually digitizing objects in a new area. This is supported by the assumption that SWISSIMAGE is of the same consistent radiometrical and spatial quality we see in Thurgau over the whole country. Manual evaluation will stay paramount before authorities take for example legal action or perform updates and changes to the cadastre. Nevertheless a great amount of workload reduction can be achieved by redirecting the eyes of the experts to the detected or undetected areas that are worth looking at. References \u00b6 Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU"},{"location":"PROJ-TGPOOL/#swimming-pool-detection-for-the-canton-of-thurgau","text":"Adrian Meyer (FHNW) - Alessandro Cerioni (Canton of Geneva) Proposed by the Canton of Thurgau - PROJ-TGPOOL January 2021 to April 2021 - Published on April 21, 2021 Abstract : The Canton of Thurgau entrusted the STDL with the task of producing swimming pool detections over the cantonal area. Specifically interesting was to leverage the ground truth annotation data from the Canton of Geneva to generate a predictive model in Thurgau while using the publicly available SWISSIMAGE aerial imagery datasets provided by swisstopo. The STDL object detection framework produced highly accurate predictions of swimming pools in Thurgau and thereby proved transferability from one canton to another without having to manually redigitize annotations. These promising detections showcase the highly useful potential of this approach by greatly reducing the need of repetitive manual labour.","title":"SWIMMING POOL DETECTION FOR THE CANTON OF THURGAU"},{"location":"PROJ-TGPOOL/#introduction","text":"Until February 2021 the Swiss Territorial Data Lab developed an approach based on Mask RCNN Deep Learning algorithms for the detection of objects on aerial images, with swimming pools serving as a demonstration object. The official cadastres of the Canton of Thurgau include \u2013 among many other objects \u2013 the registration of larger private swimming pools that are permanently anchored in the ground. The challenge is to keep the cadastre up to date on a regular basis which is usually done manually by surveying or verification with aerial imagery. Because the Canton of Thurgau (unlike the Canton of Geneva) does not maintain an own specific register of swimming pools, this study primarily serves as a technology demonstration. A secondary goal encompasses detailed knowledge transfer from the data scientist team at the STDL to the cantonal authorities such as providing insight and interpretation guidance into the performance metrics and raising awareness for the prerequisites of the detector framework.","title":"Introduction"},{"location":"PROJ-TGPOOL/#methodology","text":"","title":"Methodology"},{"location":"PROJ-TGPOOL/#process-overview","text":"Generating a Model from Cadastral Vectors and Aerial Images to Predict Objects in the Same or a New Area of Interest (AoI). The STDL object detection framework is based on a bipartite approach of training and inference. This means that a predictive model is statistically adapted to known and verified data (\"training\") in order to then generate classification predictions on new, unknown data (\"inference\"). To achieve this we resample large high-resolution orthophoto mosaics by decomposing them into small square image tiles on which vectorized annotations of swimming pools are drawn. Verified vector annotation data (\"ground truth\") for the training process was available for the cantonal area of Geneva, as well as for a smaller part of the cantonal area of Neuch\u00e2tel covering a total of almost 5'000 swimming pools present in 2019. The predictive model used is a convolutional neural network developed for computer vision (Mask RCNN). It was trained on a high performance computing cluster at the University of Applied Sciences Northwestern Switzerland FHNW using the open source Detectron2 object detection library. During inference, pixel-precise vector contours (\u201csegments\u201d) are produced over the tiled imagery of the canton of Thurgau. Each segment is attributed a confidence score which indicates the certainty of the detections when applied to new data. Using this score as a threshold level, performance metrics are computed in post-classification assessment.","title":"Process Overview"},{"location":"PROJ-TGPOOL/#ground-truth-dataset","text":"Label annotations are derived from cadastral data and manually curated Vector ground truth annotations demarcating private swimming pools were available at two locations: A near-complete coverage of the cantonal area of Geneva which contains 4\u2019652 known objects, as well as a smaller subsection of the cantonal area of Neuchatel which contains 227 known objects. Label annotations in both cases are derived from cadastral surface vector datasets and then manually curated/verified. In case of the Geneva dataset the manual verification was performed by STDL data scientists in a previous study; in case of the Neuchatel dataset the manual verification was performed by the local cadastre experts.","title":"Ground Truth Dataset"},{"location":"PROJ-TGPOOL/#reference-data-and-area-of-interest","text":"Approximately 5000 cross checked swimming pool annotations are available as vectorized shapes in the Cantons of Geneva and partially in Neuch\u00e2tel. They are compatible with orthophotos from 2018/19 such as the latest SWISSIMAGE 10cm layer. The Area of Interest (AoI) for all tests conducted in this study are divided into two main sections: Those areas in Geneva and Neuchatel containing vectorized ground truth labels are used as \u201cTraining AoI\u201d. The cantonal area of Thurgau is used as \u201cPrediction AoI\u201d. Only those parts of the cantonal surface of Thurgau are used as Prediction AoI which are designated as relevant settlement areas. For this purpose the STDL has received two additional reference datasets from the canton of Thurgau: Vector layer: List of all water basins from the official survey; 3'131 objects. Vector layer: Settlement areas / construction zones to delimit the study area. 2,895 objects from the water basin layer are located wholly or partially within the \u201cPrediction AoI\u201d. Only these objects were used for analysis (see Figure 4, light green objects). For each grid square, an image file with 256x256 pixels edge length and 60cm GSD was generated by WMS. Metadata and georeferencing were stored in an associated JSON. A quick qualitative review of the Thurgau datasets in QGIS revealed two limitations of the datasets. About 7,5% of the water basins are not located in the selected settlement area (e.g., on remote farmsteads or mixed industrial / commercial zones), so no detection attempt was initially undertaken for areas encompassing these objects. It is important to note that there are some objects in the water basin layer that are not comparable to private swimming pools in shape or size, such as public large scale swimming pools, but also sewage treatment plants, silos, tanks, reservoirs, or retention dams. By limiting the Prediction AoI to residential areas and adjacent land, the largest portion of these objects could be excluded. Example of a water treatment plant that appears in the \u201cwater basin layer\u201d and had to be excluded by limiting the \u201cPrediction AoI\u201d to residential and adjacent areas. To additionally calculate metrics on the quality of this reference dataset vs. the quality of the detections a small area over the city of Frauenfeld (Thurgau) containing approximately 100 swimming pools was manually curated and verified by the STDL data scientists.","title":"Reference Data and Area of Interest"},{"location":"PROJ-TGPOOL/#orthocorrected-imagery","text":"Orthoimagery tiles of 150m/256px edge length containing labelled annotations Both AoIs are split by a regular checkerboard segmentation grid into squares (\u201ctiles\u201d), making use of the \u201cSlippy Map Tiles\u201d quadtree-style system. The image data used here was tested with different zoom level resampling resolutions (Ground Sampling Distance, GSD) between 30 cm and 480 cm edge length per pixel while maintaining a consistent extent of 256x256 pixels. Query of the imagery was undertaken using public web map services such using common protocols such as WMS or the MIL standard. Three separate imagery sources were used over the course of the study. The 10cm GSD RGB orthophotomosaic layer SWISSIMAGE of Swisstopo was the primary target of investigation as it was used as the basis of prediction generation over the cantonal area of Thurgau. SWISSIMAGE was also used as the imagery basis for most of the training test runs over the ground truth areas of Geneva and Neuchatel. Additionally, a model was trained leveraging combined cantonal orthophoto imagery from Geneva (SITG) and Neuchatel (SITN) to comparatively test the prediction performance of such a model on the unrelated SWISSIMAGE inference dataset in Thurgau. As it was known from the STDL\u2019s previous work, that the usage of tiles exhibiting a GSD of ~60cm/Px (tile zoom level 18) offered a decent tradeoff between reaching high accuracies during training while keeping computational effort manageable this approach was used for the test using the own cantonal imagery of Geneva and Neuchatel. Using SWISSIMAGE for training, zoom levels in a range between 15 (~480 cm/Px) and 19 (~30 cm/Px) were tested.","title":"Orthocorrected Imagery"},{"location":"PROJ-TGPOOL/#training","text":"","title":"Training"},{"location":"PROJ-TGPOOL/#inference-and-assessment","text":"After training, tile by tile the entire \u201cPrediction AoI\u201d as well as the ground truth datasets presented to the final model for prediction generation. From a minimum confidence threshold up to 100% the model produces a segmentation mask for each swimming pool detection delimiting its proposed outer boundary. This boundary can be vectorized and transformed back from image space into map coordinates during post-processing. Through this process we can accumulate a consistent GIS-compatible vector layer for visualization, counting and further analysis. In case of the ground truth data the resulting vector layer can be intersected with the original input data (especially the \u201cTest Subset\u201d) to obtain unbiased model performance metrics. In case of a well-performing model the resulting vector layer can then be intersected with the \u201cPrediction AoI\u201d-derived Thurgau dataset to identify missing or surplus swimming pools in the cadastre.","title":"Inference and Assessment"},{"location":"PROJ-TGPOOL/#results","text":"","title":"Results"},{"location":"PROJ-TGPOOL/#metrics-and-model-selection","text":"Results of different training runs using SWISSIMAGE depending on the chosen zoom level The choice of a correct confidence threshold (\"THR\") is of central importance for the interpretation of the results. The division of a data set into true/false positives/negatives is a function of the confidence threshold. A high threshold means that the model is very confident of a detection; a low threshold means that as few detections as possible should be missed, but at the same time more false positive (\"FP\") detections should be triggered. Results of different training runs using SWISSIMAGE depending on the chosen zoom level There are several standardized metrics to evaluate model performance on unknown data. The most important are \"Precision\" (user accuracy), \"Recall\" (hit rate or producer accuracy) and \"F1 Score\" (the mathematical harmonic mean of the other two). \"Precision\" should increase with higher THR, \"Recall\" should decrease. The maximum F1 Score can be used as a measure of how well the model performs regardless of the viewing direction. Results of different training runs using SWISSIMAGE depending on the chosen zoom level Using the cantonal orthomosaics as training input with zoom level 18 the F1 Score reached a maximum of 81,0%. Using SWISSIMAGE as training input with zoom level 18 a slightly higher maximum F1 Score of 83,4% was achieved resulting in the choice of a \u201conly SWISSIMAGE\u201d approach for both, training and inference. The best detection by means of maximum F1 Score was reached using tiles with zoom level 19 displaying a GSD of approx. 30 cm/Px. Since the Slippy Map tile system is based on equal division of squares increasing the zoom level by one step results roughly in quadrupling the number of tiles presented for analysis. Hence also computational demand increases with an exponential factor in particular for file system read/write and sequential processing operations if the zoom level is increased. On the other hand increasing the zoom level (and therefor the GSD) also boosts visibility and size of the target objects which in turn increases detection accuracy. Comparatively slight increases in F1 Score between zoom levels 17, 18 and 19 suggest an asymptotic behaviour where the usage of massively higher amounts computing resources will not result in a much higher detection accuracy any longer. Zoom level 20 (GSD~15cm/Px) was not computed for this reason.","title":"Metrics and Model Selection"},{"location":"PROJ-TGPOOL/#true-positives","text":"A detection is considered \"True Positive\" (TP) if the algorithm detected a pool that was listed at the same position in the cadastral layer. Setting the threshold very low (THR \u2265 5%), 2'227 of 2\u2019959 swimming pools were detected. This corresponds to a detection proportion of 75% of the recorded water pools. Conversely, this could mean that 25% or 732 objects are False Negatives and therefore \"erroneously\" recorded in the cadastre as swimming pools or missed by the algorithm. \u201cTrue Positive\u201d detections \u2013 note that cases of empty and covered swimming pools are detected with a very high confidence threshold in this example.","title":"True Positives"},{"location":"PROJ-TGPOOL/#false-negatives","text":"FN describe those objects that the algorithm completely failed to detect, no matter what threshold is set. A total of 732 objects were not detected. FN easily occur when there are obvious discrepancies between orthophoto and cadastre - for example, a pool may have been constructed after the time of flight. The combined number from FN and TP corresponds to the number of analyzed labels from the water pool layer (2\u2019959 objects). Due to the splitting of pools at the segmentation grid boundaries, this value is slightly higher than the 2\u2019895 objects that were in the \u201cPrediction AoI\u201d. Here, only objects larger than 5m\u00b2 in area were counted, since the segmentation grid cuts some pools into several parts and tiny residual of only a few pixels in total area polygons might otherwise be counted as FN even though the largest part of a swimming pool was detected (and therefore counted as TP). \u201cFalse Negatives\u201d \u2013 (Left) An obvious mismatch between the cadastre and the orthophoto, an update should be considered. (Right) An ambiguous swimming pool which might be covered by a white canvas and was therefore missed by the detector.","title":"False Negatives"},{"location":"PROJ-TGPOOL/#false-positives","text":"Swimming pools that were recognized as such in the orthophoto but are not found in the cadastre represent the FP group. If the threshold is set very low (e.g. THR \u2265 5%), a total of 9'427 additional pools would be found in the settlement area. However, this number is not realistic, since most of the detections at such a low threshold do not correspond to pools, but only mark image areas that are related to a pool in a very distant way. Therefore, to get a better estimation of objects that really represent private pools but are still missing in the cadastre, the choice of a very high threshold is recommended. For example, the geoinformation services of the Canton of Geneva work with a threshold of THR \u2265 97%. Applying this threshold, 271 unrecorded swimming pools remain in the dataset with an extremely high probability of correct redetection (9% of the cadastre). However, it is still worth looking at slightly less likely FP detections with a threshold of THR \u2265 90% here. Filtering with this value, a total of 672 unregistered swimming pools were found, which would correspond to 23% of the cadastre layer. At the same time the risk for clear errors by the object detector also increases at lower thresholds, leading to some misclassifications. \u201cFalse Positive\u201d detections \u2013 (Top) Two clear examples of detected swimming pools that are missing in the cadastre. (Bottom Left) More ambiguous examples of detected swimming pools which might be missing in the cadastre. (Bottom Right) A clear error of the detector misclassifying a photovoltaic installation as a swimming pool.","title":"False Positives"},{"location":"PROJ-TGPOOL/#conclusion","text":"","title":"Conclusion"},{"location":"PROJ-TGPOOL/#manual-evaluation","text":"In the city of Frauenfeld a sample district was chosen for manual evaluation by a STDL data scientist. Even though this task should ideally be performed by a local expert this analysis does provide some insight on the potential errors currently existing within the cadastre as well as the object detection quality. Within the sampled area a total of 99 identifiable swimming pool objects were found to be present. Table: Manually evaluated dataset accuracy vs. detector performance comparison. Green indicates the preferred value. Overall, the STDL Detector was more accurate than the provided dataset with a F1 Score of ~90% vs. ~87%. Especially a lot fewer swimming pools (5 FN) were missing in the detections than in the cadastre (18 FN). Room for improvement exists with the False Positives, where our detector identified 16 surplus objects as potential swimming pools which could be falsified manually. At the same time only 9 surplus objects were found in the cadastre.","title":"Manual Evaluation"},{"location":"PROJ-TGPOOL/#interpretation","text":"We can conclude that the use of annotation data gathered in another canton of Switzerland allows for highly accurate predictions in Thurgau using the freely and publicly available SWISSIMAGE dataset. We demonstrate that such a transferrable approach can therefore be applied within a relatively short time span to other cantons without the effort of manually digitizing objects in a new area. This is supported by the assumption that SWISSIMAGE is of the same consistent radiometrical and spatial quality we see in Thurgau over the whole country. Manual evaluation will stay paramount before authorities take for example legal action or perform updates and changes to the cadastre. Nevertheless a great amount of workload reduction can be achieved by redirecting the eyes of the experts to the detected or undetected areas that are worth looking at.","title":"Interpretation"},{"location":"PROJ-TGPOOL/#references","text":"Federal Office of Topography swisstopo (2020). SWISSIMAGE 10 cm - The Digital Color Orthophotomosaic of Switzerland. https://www.swisstopo.admin.ch/en/geodata/images/ortho/swissimage10.html Girshick, R. (2015). Fast r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 1440-1448). https://openaccess.thecvf.com/content_iccv_2015/html/Girshick_Fast_R-CNN_ICCV_2015_paper.html He, K., Gkioxari, G., Doll\u00e1r, P., & Girshick, R. (2017). Mask r-cnn. In Proceedings of the IEEE international conference on computer vision (pp. 2961-2969). https://arxiv.org/abs/1703.06870 OpenStreetMap Foundation (2021). Slippy Map. https://wiki.openstreetmap.org/wiki/Slippy_Map QGIS.org (2021). QGIS Geographic Information System. QGIS Association. https://qgis.org/en/site/ Wu, Y., Kirillov, A., Massa, F., Lo, W. Y., & Girshick, R. (2019). Detectron2. https://github.com/facebookresearch/detectron2","title":"References"},{"location":"PROJ-TPNL/","text":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT \u00b6 Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Supervision : Roxane Pott (swisstopo) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL July 2021 to February 2022 - Published on February 22, 2022 Abstract : Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased. Introduction \u00b6 For authorities, being able to track the deployment of renewable energy is becoming a major challenge in front of stakes of our societies. In addition, following the deployment of installations on territory is difficult, as construction permits are not sufficient evidences. Indeed, the construction permits materialize a will, but the actual deployment and its specifications can differ from paperwork to reality. In case of thermal panels, domain experts are then put in front of a major challenge, as they have to certify of the surface of solar thermal energy that is deployed and active on their territory on a regular basis. This reporting is made for politics that aim to deploy a certain amount of renewable energy, part of territories energetic politic. Mainly based on paperwork, the current survey of thermal panels deployment are affected by drawbacks. Indeed, it is currently complicated to determine whether a construction permit lead to the deployment of a thermal panel installation and if this installation is still in activity. The goal of this project is to determine if data science is able to provide new solutions for the survey of thermal energy production in order to report more accurate surface values to the politics. Research Project Specification \u00b6 In this project, the goal is to determine whether it is possible to track down thermal panels installation on territory by using aerial images and deep learning methods. The main axis are : Train a deep learning model on aerial images to detect thermal panels Assess the performances of the deep learning model Determine to which extent it is possible to link the predictions to existing domain expert database Research Project Strategy and Collaboration \u00b6 This research project was made in collaboration with the States of Neuch\u00e2tel and Geneva . Both domain experts are facing similar challenges and their needs are nearly identical, despite their current processes differs. For each collaboration, the goals are similar, but the methodology is different. With Neuch\u00e2tel , the domain expert database is considered while with Geneva , the database is not considered. Considering the database in the collaboration with Neuch\u00e2tel lead to a much larger amount of work, as the database need to be pre-processed before to put it into perspective of the deep learning network results. It is nevertheless important to be able to assess the possibility to insert our demonstrator in the existing procedures, that are used by domain expert to track thermal panels installations. Research Data & Selected Areas \u00b6 As mentioned, the best (and probably the only) solution to track down thermal panels is to use aerial images. Indeed, due to their nature, thermal panels are always visible on aerial images. Exceptions to this rule are unusual. In addition, aerial images are acquired regularly and a full set of orthomosaic can be easily obtained each five years (at least in Switzerland). For Geneva and Neuch\u00e2tel , it is not impossible to obtain a set of images each two years. Nevertheless, using aerial images come with drawbacks. The main one is of course resolution ( GSD ). Aerial image sets used to compose orthomosaics are acquired to cover the whole territory. It follows that the resolution is limited. For a large amount of applications, the available resolution is sufficient. But for thermal panels, the resolution starts to become challenging. Illustration of the resolution at which thermal panels can be viewed on aerial images - Data : swisstopo, SITG (GSD ~ 10 cm/pixel) Despite the resolution, aerial images are selected to train a deep learning network. Mainly SWISSIMAGE from swisstopo are considered for this research project. At the time, the 2020 version of the orthomosaic is considered for both Neuch\u00e2tel and Geneva . For both cases, a test area is defined. On the side of Neuch\u00e2tel , a large test area is chosen in order to cover a large portion of the territory that mixes constructed zones and more rural ones. On the side of Geneva , the test area is defined by the domain expert and consists of a rectangular zone. Illustration of the test areas defined on Neuch\u00e2tel (left) and Geneva (right) - Data : swisstopo The research project is then only focusing on portion of territory to keep the scale realistic for such demonstrator according to the available time. Deep Learning Model Initial Training \u00b6 In this project, it is not possible to extract a ground truth, that is annotations on aerial images, from the domain expert databases. Thankfully, the FHNW , partner of the STDL , conducted some year ago annotations for thermal panels on the States of Aargau . The set consists of thousands of annotated tiles of 80x80m in size made on the SWISSIMAGE images set ( 2020 ). The annotation work was made by students of the FHNW and supervised by the D. Jordan scientists team. Such data-set is exactly the required bootstrap data to train an initial deep learning model. The only constraint is coming from the fact that the ground truth is defined by the 80x80m wide tiles on which annotations are made. Illustration of the FHNW ground truth - Labels in white, tiles in red - Data : swisstopo, FHNW Several training sessions are conducted in order to determine which sub-tiling system lead to the best performances scores. Due to the predefined ground truth, only sub-tiles of the 80x80m original tiles are possible. As a result, 80x80m , 40x40m and 26x26m tiles are considered for the network training. In all training sessions, the results are quite stable around a F1-score of 0.8-0.85 , with always a non-negligible proportion of false positives. The best results are obtained for the smaller tiles : 26x26m . It is unfortunate as small tiles comes with drawbacks. Indeed, using small tiles impose important tiling strategy to cover a large area. In addition, using small tiles also induce larger amount of cuts that have to be merged afterwards to create a usable geographical layer. Despite these drawbacks, as a demonstrator is desired, the performances are favored. The following plot shows the precision, recall and F1-score obtained for the initial training using the data of the FHNW . These values are computed over the test set, that consists of 15% of the total data-set. Scores obtained with the FHNW ground truth - Precision, Recall and F1-score On the previous plot, the scores are all computed entity-wise and not pixel-wised. This choice is made to fit the main necessity of domain experts, which is to inventory thermal panel installations more than estimating their surfaces, which is a secondary goal. One can see that encouraging results are obtained, but one can also see that the F1-score plateau is not significantly marked, a sign that the model is not yet optimal, despite the large amount of data. As we are working with domain experts, presenting F1-score according to threshold can be challenging and difficult to understand. During other research projects, it has been clear that efforts have to be put on our side to present the performances of our tools in a way that is informative and understandable by the domain exerts, in order to ensure a working collaboration and dialog, without which, such research projects can be difficult to conduct. It is the reason why an alternate representation of the performances are introduced. It shows the performances of the neural network in a more compact and readable way, focusing on elements that are interesting for the domain experts and their real-world necessities. The proposed plot is as follows : Simplified representation used with domain experts of the obtained scores - The green area is the true positives, the yellow one is false negatives and the red on is the false positive. The upper percentage give the inventory capacity, the lower one adding the false positive to the percentage. The bar is containing three proportions : the true positives, the false negatives and the false positives. The two first proportions are grouped into one in order to represent the capacity of the network to create a reliable inventory. It shows the amount of thermal panels detected over their total amount (recall). The overall bar adds the proportion of false positive, that are seen by domain experts as pollution of the obtained inventory. Showing this proportions indicates to the domain experts, in a simple way, how usable the inventory is. Assessment and Improvement of the Model \u00b6 This section is split into two separated parts, one for the Geneva case and the other for the Neuch\u00e2tel one, as the chosen strategy is different. The case of Geneva , with a more direct approach (not considering the domain expert pre-existing database), is presented first. Case of Geneva \u00b6 In the case of Geneva , the choice is made to not consider existing databases and to proceed on detecting thermal panel installations directly on images to create an inventory that can then be assessed by the domain expert to extract reliable performance scores. Assessment by the Domain Expert \u00b6 In order to produce the predictions over the test area, in this case defined by the domain expert, the area is split into tiles with the chosen size. The tiles are then sent to the deep learning network in order to produce the predictions of thermal panel installations. The following image shows the tiling system over the test area : Illustration of the tiling system applied on the Geneva test area (26x26m tiles) A set of tiles is obtained with predictions on them. The optimal threshold, deduced from the initial training on the FHNW data-set, is used to filter the predictions over the test area of Geneva . The tiles containing no prediction are removed by an automated process. The other tiles are associated with the predictions geographical footprints that and stored in a shapefile to keep the format simple and easy to exchange with the domain expert. By defining a common language with the domain expert on how to validate the predictions, the shapefile containing the predictions are sent to the domain expert along with the aerial images on which predictions are made. The role of the domain expert is to assess the predictions to indicate, on the tiles containing at least a prediction, the true positives, the false positives and the false negatives. Illustration of the common language defined to assess the predictions - The domain expert simply puts a mark in the determined false positive and at the location of the false negative. The true positives are left untouched By assessing the prediction with a domain expert, ensure that the obtained scores are reliable, as thermal panels are difficult to identify on the aerial image for a non expert. Without assessing the predictions through a domain expert would lead to unreliable scores. Results \u00b6 The assessment of the predictions made by the domain expert lead to the following results on the test area. A total of 89 tiles are formally certified by the domain expert with the following counts : Category Count TP 47 FP 63 FN 35 On a total of 110 predictions on the certified tiles, 47 are true positives, 63 being false positives. A total of 35 missing predictions are pointed by the domain expert. It follows that 47 thermal panel installations are found over 47+35=82 . This leads to the performances score for the initial deep learning over the Geneva test area model of : Score Value Precision 0.43 Recall 0.57 F1 0.49 From the inventory point of view, nearly 60% of the thermal panel installations are found by the initial deep learning model on the test area. This is clearly below the initial model, showing that the data-set are not sufficient to obtain stable results at this stage. The following plot shows the results presented in the simplified form : Score obtained on Geneva with the initial deep learning model - Simple representation Taking into account the large amount of false positives, the initial training is clearly not at the desired level to be usable by the domain expert to produce a reliable geographical layer of thermal panel installations. But these number are important, as they are certified by a domain expert, ensuring the ground truth used to assess the prediction is reliable. Improvement of the Deep Learning Network \u00b6 With the assessment made by the domain expert, reliable scores are obtained. In addition, as predictions are marked as correct or incorrect, with addition of missing thermal panel installations on the certified tiles, it was possible to create an extension to the ground truth. Indeed, driven by the corrections of the domain expert, new annotations are made on the certified tiles, including true positives and false negatives. These annotations are made by STDL on the images used to produce the predictions. The predictions in themselves are not sufficiently reliable to be directly translated into labels, and the false negative have to be added anyway. Annotations created on the Geneva area driven by the assessment of the domain expert - The labels are in white and the certified tiles in red In the case of Geneva , the ground truth extension is made on the same images used to produce the prediction. As the number of certified tiles is low, a strategy is tested in order to improve the ground truth extension. The idea consist in looking along the time dimension. Indeed, in Switzerland , aerial images are acquired in a regular basis. It follows that a history of aerial images is available. The time range from 2000 to 2020 is then considered in terms of the available images. For each set of images, the annotation created on the 2020 image set are transferred to the older images. This process is not straightforward, as each prediction have to be checked to certify that the thermal panel installation is there on older images. In addition, each tile has to be checked individually in order to check that no older thermal panel installation was there and destroyed before 2020 . Illustration of the propagation of the ground truth along the time dimension - The image on the right illustrates the limit of the process By doing this exploration along the time dimension, it was possible to increase the ground truth extracted from the assessment procedure made by the domain expert. From only 41 tiles and 64 annotations extracted using the initial test zone on the year 2020 , 394 tiles and 623 annotations are obtained by considering the 2000 to 2020 time range for aerial images. Considering the time dimension allows to better leverage the assessment made by the domain expert, despite the procedure is time-consuming. One has to keep in mind that such process is not ideal, as the same examples are simply repeated. It has some interest as it allows showing the same examples under different condition of luminosity and orientation, which can improve the deep learning model detection ability. With this new ground truth, it was possible to re-train the initial network. This was done using both the FHNW initial ground truth and the annotations made on Geneva . The following results are obtained, shown using the simple representation : Scores obtained on Geneva with consideration of the new annotations certified by the domain expert - Simple representation This plot shows the results on the test set limited to the Geneva test area. Again, the test set contains 15% of the ground truth, and limiting it to the area of Geneva leads to only several tens of tiles. This amount of tiles is quite low to conclude on the encouraging results obtained with the extended ground truth. This is reinforced by the lack of stability already observed in the previous results. Conclusion \u00b6 It is clear that the initial deep learning model, trained with the FHNW ground truth is not satisfying for a real-world usage by domain experts. Its ability to produce an inventory is not optimal, and the amount of false positives make the produced geographical layer difficult to use. Nevertheless, reliable score are obtained and can be trusted on the Geneva area thanks to the domain expert assessment. In addition, the assessment made by the domain expert, as it also included the false negatives (at least on the considered tiles), allowed to extend the ground truth. The extension of the ground truth along the time dimension allows taking advantage of the work of the domain expert as much as possible, leading to more certified tiles. The new training allowed to improve the situation on the Geneva area quite clearly. The inventory capacity of the deep learning model went from around 60% to around 80% . The amount of false positives is also drastically reduced. These are encouraging results, but the small amount of new tiles and the multiplication of the same examples along the time dimension has to lead us to a certain care, especially due to the instabilities of the results. Case of Neuch\u00e2tel \u00b6 The case of Neuch\u00e2tel is clearly more complex than the case of Geneva . In this case, the database of the domain expert is considered in order to try to link the predictions with the entries of the existing database. This choice is made to demonstrate the ability to integrate data science technology in existing pipeline, in order to avoid creating disruptive effect. Processing and Linkage with the Domain Expert Database \u00b6 In the first stage, the domain expert database is analyzed in order to determine the best solution to link the prediction made by the deep learning model and the entries of the database. The database in itself is a simple Excel sheet, with each line corresponding to a subsidy query that goes along the construction permit. Subsidies are provided by the authorities to promote deployment of the renewable energy. This is also a reason explaining the necessity for authorities to track down the construction of thermal panel installations. The major issue with the database is the localization of the thermal panels installation. Along the years, the database being quite old, different ways of localizing the installation were used. Three different localization systems are then available : the postal addresses, the geographical coordinate and the EGID (federal building identifier). Unfortunately, these standards are mixed, and all entries are localized differently. Sometimes only one localization is available, sometimes two or three. In some cases, the different localization information are not consistent, which lead to contradictions in the installation position. For some entries, the localization information is also incorrect or only approximate, which can lead to difficulties to associate a geo-referenced prediction to an entry of the database. For these reason, lots of efforts are put on the pre-processing of the database to make the link between prediction and entries as reliable as possible. The RegBL (federal register of buildings and dwellings) is used to assess the EGID and the postal addresses and to track down contradiction. In addition, the post addresses of the State of Neuch\u00e2tel is also considered to match addresses with geographical positions for the same reason. By doing this, many potential positions are extracted for each entry of the database. This allows to assess the contradiction in order to retain the most probable and reliable localization for each entry of the database. Of course, in many cases, the assessment is quite weak as the amount of information on localization is low (this is especially the case for older installation, the new one being localized in a much more reliable manner using the EGID ). At the end of this complex and time-consuming task, almost all entries of the database are associated with a geographical position. This allows to match predictions, that are geographically localized, to the most probable entry of the database. This process is important as it allows the domain expert to not only have a geographical layer of the thermal panel installation but to have also the link with its pre-existing database. This allows to put into perspective prediction and database to track down construction and destruction of installations along the time dimension. Assessment by the Domain Expert \u00b6 After pre-processing of the domain expert database, a region of Neuch\u00e2tel state is defined. A tiling strategy is made to translate the defined area in tiles of the appropriated size according to the initial training of the deep learning model. Predictions are then made on each of the tiles. Again, the optimal threshold is selected according to the initial training to filter the predictions made on the test area. At this stage, the procedure differ from the case of Geneva . Here, tiles are not filtered based on their content of prediction or not. The database is considered, after its pre-processing, and the predictions are linked to the optimal entry according to its best localization. As a result, a set of predictions linked to a specific entry of the database is obtained. The other predictions are simply discarded for this specific assessment procedure. In order to serve as much as possible the interests of the domain expert, a specific assessment procedure is set. This is set to allow to assess the prediction on one side and to help the domain expert to correct the bad localization of the thermal panel installation in his database on the other side. The chosen approach is based on a dictionary of GeoTIFF images on which the prediction are shown and on which additional information are specified to help the domain expert to assess the localization provided by the database. Illustration of one page of the dictionary corresponding to one database entry - For each entry, such image is provided, showing information on the entry, its localization consistency and the prediction made by the model - Each image is a geo-referenced TIFF The dictionary is made of a GeoTIFF per prediction that is linked with a unique entry of the database. In addition to the prediction geometry drawn on the image, basic information on the linked database entry is provided. The optimal localization (between post addresses, coordinates or EGID) used to link the prediction and the entry of the database is also indicated to help the domain expert to understand the link. Information about the estimated quality of the localization of the thermal panel installation is also provided. This quality indicator is based on the consistency of the multiple location information (post address, coordinates and EGID). The more consistent they are, the better the localization is considered. In case of a potential bad localization, the domain expert is invited to check the entry of the database to correct the position. In parallel, a simple Excel file is set and filled by the domain expert along the procedure. It allows setting the corrected positions, when required, and to indicate if the prediction is correct and correctly linked to the database entry. This process allows setting a win-win strategy where incorrectly located installation are treated on the side of the database and the prediction is assessed for the correct localization. The procedure for the domain expert consists then only to parse a sequence of images on which all the information are shown and to fill columns in the assessment Excel sheet. This allows to assess quickly and efficiently the prediction while correcting the inconsistency in the database. Results \u00b6 Thanks to the assessment procedure, part of the predictions are certified by the domain expert. This allows to compute scores on the capacity of the initial deep learning model to compute inventory of thermal panel installations. Unfortunately, this assessment procedure does not allow the computation of the formal scores, as the false negative are not considered. This is the main drawback coming from the fact that we work in parallel with the domain expert database. On the 354 predictions linked to the database, 316 corresponds to correctly localized entries of the database. On the 316 correct entries of the database, the domain expert reported 255 visible installation. This shows that many installations, present in the database through an entry, are not visible in the reality. With these numbers, one can deduce that 61 installations are reported in the database through paper work but cannot be found in the real world. The explanation is probably complex, but this shows how difficult it is to keep a database of installation up to date with the reality. Without a formal historical analysis, it is not possible to determine what happened to these missing installation. For some of them, one needs to consider the natural cycle of life of such installations. Indeed, thermal panel have a determined lifetime and need to be replaced or decommissioned. It is also possible that for some of them, the construction permit was asked but without leading to the actual construction of a thermal panel installation. This case is expected to be less usual. Back to the score of the initial deep learning model, on the 255 visible installation, the domain expert determined that 204 are correctly detected by the model. This lead to an inventory capacity of 0.8 which remains in the initial model scores. It is interesting to observe that the initial model scores seem to hold in the case of Neuch\u00e2tel but not in the previous case of Geneva . Indeed, on Geneva , the inventory capacity drop to 0.6 . Improvement of the Deep Learning Network \u00b6 With the assessment made by the domain expert, despite false negatives are not considered, it was possible to increase the ground truth with new annotation on the test area of Neuch\u00e2tel . The procedure starts by isolating all prediction that are marked as correct (true positive) by the domain expert. A tiling system is then set to cover the entire test area with size fitting the initial choices. The certified true positive are then manually processed to create a proper annotation, as the prediction are not reliable enough. The certifications made by the domain expert are sufficiently clear for a data scientist to do this task autonomously. The last stage consist in validating the tiles containing a new annotation. This part is the most complex one, as the data scientist has to work autonomously. The tiles containing a new annotation can only be validated, and enter the ground-truth, if and only if no other ambiguous element appear in the validated tiles. If any ambiguities arise for a tile, it needs to be dropped and not considered for the ground truth. In the case of Neuch\u00e2tel a few tiles are then removed for this reason. With this procedure, 272 new annotation are added to the ground truth on 254 tiles. These annotations, as for Geneva , are certified by a domain expert, providing a reliable ground truth. With this new set of annotation, and considering the new annotation made in the case of Geneva , it is possible to conduct a new training of the deep learning model. For this last training, the full ground truth is considered, with the FHNW annotations and those coming from the domain experts of Geneva and Neuch\u00e2tel . The following plot gives an overall simple representation of the obtained results : Score obtained using all the available ground truth, including FHNW, Geneva and Neuch\u00e2tel - Simple representation On the test set, an F1-score of 0.82 is obtained, which is slightly worse that for the initial training ( 0.85 ). On the overall, one can also sees that the inventory capacity is decreased while the amount of false positive is reduced. Again, one can here sees the instabilities of the results, showing that the used data is not sufficient or not enough well suited for such task. One can see on this following plots, the simple representation of the score reduced only the Geneva and Neuch\u00e2tel areas : Score obtained restricted to the Geneva (test set) - Simple representation Score obtained restricted to the Neuch\u00e2tel (test set) - Simple representation One has to take into account that restricting the score to such area leads to very few prediction, leading to poor statistics. It is nevertheless clear that the results on the Neuch\u00e2tel restriction demonstrate the instabilities observed all along the project. On Neuch\u00e2tel , choosing a different threshold could lead to a better inventory capacity, but the fact that the threshold needs to be adapted according to the situation shows that the model was not able to generalise. It is most likely that the nature of the objects, its similarity with other objects and the resolution of the images play a central role in the lack of generalisation. As a conclusion, detecting thermal panels needs higher resolution in order for the model to be able to extract more reliable features from the object instead of relying only on the situation of the object. Conclusion \u00b6 In the case of Neuch\u00e2tel , the procedure is more complex, as the database is considered. The work on the database is time-consuming and the linkage of the predictions with the entries of the database is not straightforward, mainly due to the inconsistencies on thermal panel installation localization. In addition, considering the database lead it to be the main point of view from which the prediction are analyzed, assessed and understood. It offers a very interesting point of view as it allows assessing the synchronization between the database and the current state of the thermal panel installations deployment. Nevertheless, such point of view also introduce drawback, as it does not allow to directly assess the false negative and only part of the false positive. This lead to intermediate scores, that are more focused on the database-reality synchronization than the performances of the deep learning model. It is then clearly demonstrated that a deep learning model can be interfaced with an existing database to ensure processes continuity with the introduction of new technologies in the territory management. It shows that new methods can be introduced without requiring to abandon the previous processes, which is always complicated and undesired. On the initial deep learning model assessment, with an inventory capacity of around 0.85 (recall), one can observe a difference between Neuch\u00e2tel and Geneva . Indeed, in Geneva , the recall dropped to around 0.6 while it was more around 0.8 in the Neuch\u00e2tel case. A possible explanation is the similarity between the Aargau (used as to train the initial deep learning model) and Neuch\u00e2tel in terms of geography. The case of Geneva is more urban than these two others. This confirms the instabilities already observed and seems to indicate that thermal panels remains a complex object to detect at this stage considering the available data. Conclusion and Perspectives \u00b6 As a main conclusion, this project, performed in two stage with Geneva and Neuch\u00e2tel states, is a complex task. The nature of the object of interest is the main source of difficulty. The current available aerial images made the detection of such object possible, but the resolution of the images (GSD) makes the task very difficult. Indeed, as mentioned, the thermal panel installations visible on the image are at the limit of resolution. This forces the deep learning model to learn more with the context than with the object features themselves. To add complexity, thermal panels appear very alike electrical panels on images, leading to a major source of confusion. The fact that the deep learning model is relying more on context than on object features lead the electrical panel to be reported as a thermal one, reducing the efficiency of inventory, leading to large amount of false positive. Despite that, interesting results are obtained and cannot lead to the conclusion that inventory such object is currently impossible. It remains very challenging, but data science can already bring help in the tracking and surveillance of the thermal panel installations. The collaboration with the domain experts is here a necessity. Indeed, such installations, especially with the image resolution, are extremely complex to confirm as such (mainly due to the confusion with electrical panels and other roof elements ). Even for the domain expert, determining if a prediction is a true positive or not is challenging and time-consuming. Without the help of domain experts, data scientists are not able to tackle such problem. Another positive outcome is the demonstration that data science can be interfaced smoothly with existing processes. This is shown with the Neuch\u00e2tel case, where the predictions can instantly be linked to the entries of the pre-existing domain expert database. This eases the domain expert assessment procedure and can also participate to assess the synchronization between the database and the reality. As a final word, the obtained deep learning model is not formally able to enter the management of the territory. It is demonstrated that the nature of the object and the available data makes the model unstable from a situation to another. This shows that the current data available is not formally enough to lead to the production of a fully working prototype able to satisfy the specifications of the domain experts. Nevertheless, such model can already perform pre-processes to ease the work of domain expert in the complex task of tracking the deployment of thermal energy generators on the Swiss territory.","title":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT"},{"location":"PROJ-TPNL/#detection-of-thermal-panels-on-canton-territory-to-follow-renewable-energy-deployment","text":"Nils Hamel (UNIGE) - Huriel Reichel (FHNW) Supervision : Roxane Pott (swisstopo) Project in collaboration with Geneva and Neuch\u00e2tel States - TASK-TPNL July 2021 to February 2022 - Published on February 22, 2022 Abstract : Deployment of renewable energy becomes a major stake in front of our societies challenges. This imposes authorities and domain expert to promote and to demonstrate the deployment of such energetic solutions. In case of thermal panels, politics ask domain expert to certify, along the year, of the amount of deployed surface. In front of such challenge, this project aims to determine to which extent data science can ease the survey of thermal panel installations deployment and how the work of domain expert can be eased.","title":"DETECTION OF THERMAL PANELS ON CANTON TERRITORY TO FOLLOW RENEWABLE ENERGY DEPLOYMENT"},{"location":"PROJ-TPNL/#introduction","text":"For authorities, being able to track the deployment of renewable energy is becoming a major challenge in front of stakes of our societies. In addition, following the deployment of installations on territory is difficult, as construction permits are not sufficient evidences. Indeed, the construction permits materialize a will, but the actual deployment and its specifications can differ from paperwork to reality. In case of thermal panels, domain experts are then put in front of a major challenge, as they have to certify of the surface of solar thermal energy that is deployed and active on their territory on a regular basis. This reporting is made for politics that aim to deploy a certain amount of renewable energy, part of territories energetic politic. Mainly based on paperwork, the current survey of thermal panels deployment are affected by drawbacks. Indeed, it is currently complicated to determine whether a construction permit lead to the deployment of a thermal panel installation and if this installation is still in activity. The goal of this project is to determine if data science is able to provide new solutions for the survey of thermal energy production in order to report more accurate surface values to the politics.","title":"Introduction"},{"location":"PROJ-TPNL/#research-project-specification","text":"In this project, the goal is to determine whether it is possible to track down thermal panels installation on territory by using aerial images and deep learning methods. The main axis are : Train a deep learning model on aerial images to detect thermal panels Assess the performances of the deep learning model Determine to which extent it is possible to link the predictions to existing domain expert database","title":"Research Project Specification"},{"location":"PROJ-TPNL/#research-project-strategy-and-collaboration","text":"This research project was made in collaboration with the States of Neuch\u00e2tel and Geneva . Both domain experts are facing similar challenges and their needs are nearly identical, despite their current processes differs. For each collaboration, the goals are similar, but the methodology is different. With Neuch\u00e2tel , the domain expert database is considered while with Geneva , the database is not considered. Considering the database in the collaboration with Neuch\u00e2tel lead to a much larger amount of work, as the database need to be pre-processed before to put it into perspective of the deep learning network results. It is nevertheless important to be able to assess the possibility to insert our demonstrator in the existing procedures, that are used by domain expert to track thermal panels installations.","title":"Research Project Strategy and Collaboration"},{"location":"PROJ-TPNL/#research-data-selected-areas","text":"As mentioned, the best (and probably the only) solution to track down thermal panels is to use aerial images. Indeed, due to their nature, thermal panels are always visible on aerial images. Exceptions to this rule are unusual. In addition, aerial images are acquired regularly and a full set of orthomosaic can be easily obtained each five years (at least in Switzerland). For Geneva and Neuch\u00e2tel , it is not impossible to obtain a set of images each two years. Nevertheless, using aerial images come with drawbacks. The main one is of course resolution ( GSD ). Aerial image sets used to compose orthomosaics are acquired to cover the whole territory. It follows that the resolution is limited. For a large amount of applications, the available resolution is sufficient. But for thermal panels, the resolution starts to become challenging. Illustration of the resolution at which thermal panels can be viewed on aerial images - Data : swisstopo, SITG (GSD ~ 10 cm/pixel) Despite the resolution, aerial images are selected to train a deep learning network. Mainly SWISSIMAGE from swisstopo are considered for this research project. At the time, the 2020 version of the orthomosaic is considered for both Neuch\u00e2tel and Geneva . For both cases, a test area is defined. On the side of Neuch\u00e2tel , a large test area is chosen in order to cover a large portion of the territory that mixes constructed zones and more rural ones. On the side of Geneva , the test area is defined by the domain expert and consists of a rectangular zone. Illustration of the test areas defined on Neuch\u00e2tel (left) and Geneva (right) - Data : swisstopo The research project is then only focusing on portion of territory to keep the scale realistic for such demonstrator according to the available time.","title":"Research Data &amp; Selected Areas"},{"location":"PROJ-TPNL/#deep-learning-model-initial-training","text":"In this project, it is not possible to extract a ground truth, that is annotations on aerial images, from the domain expert databases. Thankfully, the FHNW , partner of the STDL , conducted some year ago annotations for thermal panels on the States of Aargau . The set consists of thousands of annotated tiles of 80x80m in size made on the SWISSIMAGE images set ( 2020 ). The annotation work was made by students of the FHNW and supervised by the D. Jordan scientists team. Such data-set is exactly the required bootstrap data to train an initial deep learning model. The only constraint is coming from the fact that the ground truth is defined by the 80x80m wide tiles on which annotations are made. Illustration of the FHNW ground truth - Labels in white, tiles in red - Data : swisstopo, FHNW Several training sessions are conducted in order to determine which sub-tiling system lead to the best performances scores. Due to the predefined ground truth, only sub-tiles of the 80x80m original tiles are possible. As a result, 80x80m , 40x40m and 26x26m tiles are considered for the network training. In all training sessions, the results are quite stable around a F1-score of 0.8-0.85 , with always a non-negligible proportion of false positives. The best results are obtained for the smaller tiles : 26x26m . It is unfortunate as small tiles comes with drawbacks. Indeed, using small tiles impose important tiling strategy to cover a large area. In addition, using small tiles also induce larger amount of cuts that have to be merged afterwards to create a usable geographical layer. Despite these drawbacks, as a demonstrator is desired, the performances are favored. The following plot shows the precision, recall and F1-score obtained for the initial training using the data of the FHNW . These values are computed over the test set, that consists of 15% of the total data-set. Scores obtained with the FHNW ground truth - Precision, Recall and F1-score On the previous plot, the scores are all computed entity-wise and not pixel-wised. This choice is made to fit the main necessity of domain experts, which is to inventory thermal panel installations more than estimating their surfaces, which is a secondary goal. One can see that encouraging results are obtained, but one can also see that the F1-score plateau is not significantly marked, a sign that the model is not yet optimal, despite the large amount of data. As we are working with domain experts, presenting F1-score according to threshold can be challenging and difficult to understand. During other research projects, it has been clear that efforts have to be put on our side to present the performances of our tools in a way that is informative and understandable by the domain exerts, in order to ensure a working collaboration and dialog, without which, such research projects can be difficult to conduct. It is the reason why an alternate representation of the performances are introduced. It shows the performances of the neural network in a more compact and readable way, focusing on elements that are interesting for the domain experts and their real-world necessities. The proposed plot is as follows : Simplified representation used with domain experts of the obtained scores - The green area is the true positives, the yellow one is false negatives and the red on is the false positive. The upper percentage give the inventory capacity, the lower one adding the false positive to the percentage. The bar is containing three proportions : the true positives, the false negatives and the false positives. The two first proportions are grouped into one in order to represent the capacity of the network to create a reliable inventory. It shows the amount of thermal panels detected over their total amount (recall). The overall bar adds the proportion of false positive, that are seen by domain experts as pollution of the obtained inventory. Showing this proportions indicates to the domain experts, in a simple way, how usable the inventory is.","title":"Deep Learning Model Initial Training"},{"location":"PROJ-TPNL/#assessment-and-improvement-of-the-model","text":"This section is split into two separated parts, one for the Geneva case and the other for the Neuch\u00e2tel one, as the chosen strategy is different. The case of Geneva , with a more direct approach (not considering the domain expert pre-existing database), is presented first.","title":"Assessment and Improvement of the Model"},{"location":"PROJ-TPNL/#case-of-geneva","text":"In the case of Geneva , the choice is made to not consider existing databases and to proceed on detecting thermal panel installations directly on images to create an inventory that can then be assessed by the domain expert to extract reliable performance scores.","title":"Case of Geneva"},{"location":"PROJ-TPNL/#case-of-neuchatel","text":"The case of Neuch\u00e2tel is clearly more complex than the case of Geneva . In this case, the database of the domain expert is considered in order to try to link the predictions with the entries of the existing database. This choice is made to demonstrate the ability to integrate data science technology in existing pipeline, in order to avoid creating disruptive effect.","title":"Case of Neuch\u00e2tel"},{"location":"PROJ-TPNL/#conclusion-and-perspectives","text":"As a main conclusion, this project, performed in two stage with Geneva and Neuch\u00e2tel states, is a complex task. The nature of the object of interest is the main source of difficulty. The current available aerial images made the detection of such object possible, but the resolution of the images (GSD) makes the task very difficult. Indeed, as mentioned, the thermal panel installations visible on the image are at the limit of resolution. This forces the deep learning model to learn more with the context than with the object features themselves. To add complexity, thermal panels appear very alike electrical panels on images, leading to a major source of confusion. The fact that the deep learning model is relying more on context than on object features lead the electrical panel to be reported as a thermal one, reducing the efficiency of inventory, leading to large amount of false positive. Despite that, interesting results are obtained and cannot lead to the conclusion that inventory such object is currently impossible. It remains very challenging, but data science can already bring help in the tracking and surveillance of the thermal panel installations. The collaboration with the domain experts is here a necessity. Indeed, such installations, especially with the image resolution, are extremely complex to confirm as such (mainly due to the confusion with electrical panels and other roof elements ). Even for the domain expert, determining if a prediction is a true positive or not is challenging and time-consuming. Without the help of domain experts, data scientists are not able to tackle such problem. Another positive outcome is the demonstration that data science can be interfaced smoothly with existing processes. This is shown with the Neuch\u00e2tel case, where the predictions can instantly be linked to the entries of the pre-existing domain expert database. This eases the domain expert assessment procedure and can also participate to assess the synchronization between the database and the reality. As a final word, the obtained deep learning model is not formally able to enter the management of the territory. It is demonstrated that the nature of the object and the available data makes the model unstable from a situation to another. This shows that the current data available is not formally enough to lead to the production of a fully working prototype able to satisfy the specifications of the domain experts. Nevertheless, such model can already perform pre-processes to ease the work of domain expert in the complex task of tracking the deployment of thermal energy generators on the Swiss territory.","title":"Conclusion and Perspectives"},{"location":"PROJ-TREEDET/","text":"Tree Detection from Point Clouds over the Canton of Geneva \u00b6 Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET May 2021 to March 2022 - Published on April 22, 2022 Abstract : Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement. 1. Introduction \u00b6 1.1 Context \u00b6 Human societies benefits from the presence of trees in cities and their surroundings. More specifically, as far as urban contexts are concerned, trees deliver many ecosystem services such as: the reduction of heat islands, by shading and cooling their direct environment; the mitigation of flood risks, by intercepting precipitation through their foliage and increasing soil infiltration; the reduction of atmospheric pollution; the reduction of noise pollution; a positive contribution to the physical, mental and social health of the population. Moreover, they play an important role of support of the biodiversity by offering resources and shelter to numerous animal, plant and fungus species. The quality and quantity of such benefits depend on various parameters, such as the height, the age, the leaf area, the species diversity within a given population of trees. Therefore, the preservation and the development of a healthy and functional tree population is one of the key elements of those public policies which aim at increasing resilience against climate change. For these reasons, the Canton of Geneva has set the ambitious goal of increasing its canopy cover (= ratio between the area covered by foliage and the total area) from 21% (as estimated in 2019) to 30% by 2050. In order to reach this goal, the concerned authorities ( i.e. the Office cantonal de l\u2019agriculture et de la nature ) need detailed data and tools to keep track of the cantonal tree population and drive its development. The Inventaire Cantonal des Arbres Isol\u00e9s (ICA) is the most extensive and detailed source of data on isolated trees (= trees that do not grow in forests) within the Canton of Geneva. Such dataset is maintained by a joint effort of several public administrations (green spaces departments of various municipalities, the Office cantonal de l\u2019agriculture et de la nature , the Geneva Conservatory and Botanical Garden, etc.). For each tree, several attributes are provided: geographical coordinates, species, height, plantation date, trunk diameter, crown diameter, etc. To date, the ICA includes data about more than 237 000 trees. However, it comes with a host of known limitations: only the public domain is covered (no records about trees which are found within private properties); moreover, the coverage of the public domain is partial (business experts estimate that half of the actual trees are missing). The freshness of data is not consistent among the various records, as it relies on sporadic ground surveys and manual updates. Trees tagged as \"historical\" lack precision in terms of geolocation and taxonomical information. In light of Geneva's ambitions in terms of the canopy growth, the latter observations call for the need of a more efficient methodology to improve the exhaustivity and veracity of the ICA. Over the last few years, several joint projects of the Canton, the City and the University of Geneva explored the potential of using LiDAR point clouds and tailored software to characterize trees in a semi-automatic way, following practices that are already established in forestry. Yet, forest and urban settings are quite different from each other: forests exhibit higher tree density, which can hinder tree detection; forests exhibit lower heterogeneity in terms of species and morphology, which can facilitate tree detection. Hence, the task of automatic detection is likely to be harder in urban contexts than in forests. The study reported in this page, proposed by the Office cantonal de l\u2019agriculture et de la nature (OCAN) and carried out by the STDL, represents a further yet modest step ahead towards the semi-automatic digitalisation of urban trees. 1.2 Objectives \u00b6 The objectives of this project was fixed by the OCAN domain experts and, in one sentence, amount to designing a robust and reproducible semi-automatic methodology allowing one to \"know everything\" about each and every isolated tree of the Canton of Geneva, which means: detecting all the trees (exhaustivity); geolocating the trunk and the top of every tree; measuring all the properties of every tree: height, trunk and crown diameter, canopy area and volume; identify species. Regarding quality, the following requirements were fixed: Property Expected precision Trunk geolocation 1 m Top geolocation 1 m Height 2 m Trunk diameter at 1m height 10 cm Crown diameter 1 m Canopy area 1 m\u00b2 Canopy volume 1 m\u00b3 In spite of such thorough and ambitious objectives, the time span of this project was not long enough to address them all. As a matter of fact, the STDL team only managed to tackle the tree detection and trunk geolocation. 1.3 Methodology \u00b6 As shown in Figure 1.1 here below, algorithms and software exist, which can detect individual trees from point clouds. Figure 1.1: The two panels represent a sample of a point cloud before (top panel) and after (bottom) tree detection. Not only such tools take point cloud as input data, but also the values of a bunch of parameters have to be chosen by users. The quality of results depend both on input data and on input parameters. The application of some pre-processing to the input point cloud have an impact, too. Therefore, it becomes clear that in order to find the optimal configuration for a given context, one should be able to measure the quality of results as a function of the chosen parameters as well as of the pre-processing operations. To this end, the STDL team called for the acquisition of ground truth data. Further details about input data (point cloud and ground truth), software and methodology will be provided shortly. 1.4 Input data \u00b6 1.4.1 LiDAR data \u00b6 A high-density point cloud dataset was produced by the Flotron Ingenieure company, through Airborne Laser Scanning (ALS, also commonly known by the acronym LiDAR - Light Detection And Ranging). Thanks to a lateral overlap of flight lines of ~80%, more than 200 pts/m\u00b2 were collected, quite a high density when compared to more conventional acquisitions (30 \u2013 40 pts/m\u00b2). Flotron Ingenieure took care of the point cloud classification, too. The following table summarizes the main features of the dataset: LIDAR 2021 - OCAN, Flotron Ingenieure Coverage Municipalities of Ch\u00eane-Bourg and Th\u00f4nex (GE) Date of acquisition March 10, 2021 Density > 200 pts/m\u00b2 Planimetric precision 20 mm Altimetric precision 50 mm Tiles 200 tiles of 200 m x 200 m Format LAS 1.2 Classes 0 - Unclassified 2 - Ground 4 - Medium vegetation (0.5 - 3m) 5 - High vegetation (> 3m) 6 - Building 7 - Low points 10 - Error points 13 - Bridges 16 - Noise / Vegetation < 0.5m Figs. 1.2 and 1.3 represent the coverage of the dataset and a sample, respectively. Figure 1.2: Coverage and tiling of the 2021 high-density point cloud dataset. Figure 1.3: A sample of the 2021 high-density point cloud. Colors correspond to different classes: green = vegetation (classes 4 and 5), orange = buildings (class 6), grey = ground or unclassified points (class 2 and 0, respectively). 1.4.2 Test sectors and ground truth data \u00b6 In order to be able to assess the exhaustivity and quality of our results, we needed reference (or \"ground truth\") data to compare with. Following the advice of domain experts, it was decided to acquire ground truth data regarding trees within three test sectors, which represent three different types of contexts: [1] alignment of trees, [2] park, [3] a mix of [1] and [2]. Of course, these types can also be found elsewhere within the Canton of Geneva. Ground truth data was acquired through surveys conducted by geometers, who recorded the (x, y) coordinates of the trunk at 1 m above the ground; the trunk diameter at 1 m above the ground, for every tree having a trunk diameter larger than 10 cm. Details about the three test sectors are provided in the following, where statistics on species, height, age and crown diameter stem from the ICA. Avenue de Bel-Air (Ch\u00eane-Bourg, GE) \u00b6 Property Value Type Alignment of trees Trees 135 individuals Species monospecific ( Tilia tomentosa ) Height range 6 - 15 m Age range 17 - 28 yo Crown diameters 3 - 10 m Comments Well separated trees, heights and morphologies are relatively homogenous, no underlying vegetation (bushes) around the trunks. Figure 1.4: \"Avenue de Bel-Air\" test sector in Ch\u00eane-Bourg (GE). Orange dots represents ground truth trees as recorded by geometers. Parc Floraire (Ch\u00eane-Bourg, GE) \u00b6 Property Value Type Park with ornemental trees Trees 95 individuals Species 65 species Height range 1.5 - 28 m Age range Unknown Crown diameters 1 - 23 m Comments Many ornemental species of all sizes and shapes, most of them not well separated. Very heterogenous vegetation structure. Figure 1.5: \"Parc Floraire\" test sector in Ch\u00eane-Bourg (GE). Orange dots represents ground truth trees as recorded by geometers. Adrien-Jeandin (Th\u00f4nex, GE) \u00b6 Property Value Type Mixed (park, alignment of tree, tree hedges, etc.) Trees 362 individuals Species 43 species Height range 1 - 34 m Age range Unknown Crown diameters 1 - 21 m Comments Mix of different vegetation structures, such as homogenous tree alignments, dense tree hedges and park with a lot of underlying vegetation under big trees. Figure 1.6: \"Adrien-Jeandin\" test sector in Th\u00f4nex (GE). Orange dots represents ground truth trees as recorded by the geometers. 1.5 Off-the-shelf software \u00b6 Two off-the-shelf software products were used to detect trees from LiDAR data, namely TerraScan and the Digital Forestry Toolbox (DFT). The following table summarizes the main similarities and differences between the two: Feature Terrascan DFT Licence Proprietary (*) Open Source (GPL-3.0) Price See here Free Standalone No: requires MicroStation or Spatix No: requires Octave or MATLAB Graphical User Interface Yes No In-app point cloud visualization Yes (via MicroStation or Spatix ) No (**) Scriptable Partly (via macros ) Yes Hackable No Yes (*) Unfortunately, we must acknowledge that using network licenses turned out to be quite problematic. Weeks of unexpected downtime were experienced, due to puzzling issues related to the interplay between the self-hosted license server, firewalls, VPN and end-devices. (**) We used the excellent Potree Free and Open Source software for visualization. The following sections are devoted to brief descriptions of these two tools; further details will be provided in Section 4 and Section 5 . 1.5.1 Terrascan \u00b6 Terrascan is a proprietary software, developed and commercialized by Terrasolid , a MicroStation and Spatix plugin which is capable of performing several tasks on point clouds, including visualisation, classification. As far as tree detection is concerned, Terrascan offers multiple options to manually, semi- or fully-automatically detect and segment trees in point clouds; estimate the value of a host of properties (height, trunk diameter, etc.). Two methods are provided to group (one may also say \"to segment\") points into individual trees: the so-called \"highest point\" (aka \"watershed\") method, suitable for airborne point clouds. the so-called \"trunk\" method, which requires a high amount of points from trunks and hence is suitable for very high-density airborne point clouds, for mobile data and point clouds from static scanners. For further details on these two methods, we refer the reader to the official documentation . 1.5.2 Digital Forestry Toolbox (DFT) \u00b6 The Digital Forestry Toolbox (DFT) is a collection of tools and tutorials for Matlab/Octave designed to help process and analyze remote sensing data related to forests (source: official website ) developed and maintained by Matthew Parkan, released under an Open Source license (GPL-3.0). The DFT implements algorithms allowing one to perform tree top detection, via a marker-controlled watershed segmentation (cf. this tutorial ); stem detection (cf. this other tutorial ). We refer the reader to the official documentation for further information. 2. Method \u00b6 As already stated, in spite of the thorough and ambitious objectives of this project (cf. here ), only the tree detection and trunk geolocation sub-tasks could be tackled given the resources (time, humans) which were allocated to the STDL. The method we followed goes through several steps, pre-processing, running Terrascan or DFT, post-processing, which are documented here-below. 2.1 Pre-processing: point cloud reclassification and cleaning \u00b6 [1] In some cases, points corresponding to trunks may be misclassified and lay in class 0 \u2013 Unclassified instead of class 4 \u2013 Medium vegetation . As the segmentation process only takes vegetation classes (namely classes 4 and 5) into account, the lack of trunk points can make some trees \"invisibles\". [2] We suspected that the standard classification of vegetation in LiDAR point clouds could be too basic for the task at hand. Indeed, vegetation points found at less (more) than 3 m above the ground are classified as 4 \u2013 Medium Vegetation ( 5 \u2013 High Vegetation ). This may cause one potential issue: all the points of a given tree that are located at up to 3 meters above the ground (think about the trunk!) belong to a class (namely class no. 4) which can also be populated by bushes and hedges. The \"contamination\" by bushes and hedges may spoil the segmentation process, especially in situations where dense low vegetation exists around higher trees. Indeed, it was acknowledged that in such situations the segmentation algorithm fails to properly identify trunk locations and distinguish one tree from another. Issues [1] and [2] can be solved or at least mitigated by reclassifying and cleaning the input point cloud, respectively. Figures 2.1 and 2.2 show how tree grouping (or \"segmentation\") yields better results if pre-processed pointclouds are used. Figure 2.1: Tree grouping (or \"segmentation\") applied to the original (top panel) vs pre-processed (bottom) point cloud. Without pre-processing, two trees connected by a hedge are segmented as one single individual. Therefore, only one detection is made (green circle slightly above the ground). With pre-processing, we get rid of the hedge and recover the lowest trunk points belonging to the tree on the left. Eventually, both trees are properly segmented and we end up having two detections (green circles). Figure 2.2: Tree grouping (or \"segmentation\") applied to the original (left panel) vs reclassified (right) point cloud. Without pre-processing, segmentation yields a spurious detection (= false positive, red circle slightly above the ground), resulting from the combination of a pole and a hedge. With pre-processing, we get rid of most of the points belonging to the hedge and the pole; no false positive shows up. 2.1.1 Reclassification with Terrascan and FME Desktop \u00b6 The reclassification step aims at recovering trunk points which might be misclassified and hence found in some class other than class 4 \u2013 Medium Vegetation ( e.g. class 0 - Unclassified ). It was carried out with Terrascan using the Classify by normal vectors tool, which identifies linear features generated by groups of class 0 and 4 points; moves the concerned points to an empty class (here: class 10). Finally, during the cleaning process with FME Desktop (cf. Chapter 2.1.2 here below), these points are reclassified in class 4. The outcome of this reclassification step is shown in Figure 2.3. Figure 2.3: Outcome of reclassification. In the upper picture, the trunk of the tree on the left is partially misclassified, while the trunk of the tree in the middle is completely misclassified. After reclassification, almost all the points belonging to trunks are back in class 4. Let us note that the reclassification process may also recover some unwanted objects enjoying linear features similar to trees (poles, power lines, etc.). However, such spurious objects can at least partly filtered out by cleaning step described here below. 2.1.2 Cleaning point clouds with FME Desktop \u00b6 The cleaning step aims to filter as many \"non-trunk\" points as possible out of class 4 \u2013 Medium Vegetation , in order to isolate trees from other types of vegetation. Vegetation is considered as part of a tree if higher than 3 m. Cleaning consists in two steps: Every point of class 4 which is NOT vertically covered by any class 5 point ( i.e. any class 4 point which is not under a tree) is moved to another class. This filters out an important part of bushes and hedges. Only those bushes and hedges which are actually under a tree remain in class 4. Every point of class 4 which is located above a wall is moved to another class. Actually, it was noticed that many hedges were located on or against walls. This filters out some additional \"hedge points\", which may escape the first cleaning step if found straight under a tree. Note that in case the point cloud is reclassified in order to recover missing trunks, the cleaning step also allow to get rid of unwanted linear objects (poles, electric lines, etc) that have been recovered during the reclassification. The class containing reclassified points (class 10) will simply be process together with class 4 and receive the same treatment. Eventually, reclassified points that are kept (discarded) by the cleaning process will be integrated in class 4 (3). Figure 2.4: Outcome of the cleaning process. Red points correspond to the \"cleaned\" points that were moved to class 3. Figure 2.5: Outcome of the cleaning process. Red points correspond to the \"cleaned\" points that were moved to class 3. Hedges under trees escape the cleaning. 2.1.3 FME files and documentation of pre-processing steps \u00b6 More detailed information about the reclassification and cleaning of the point cloud can be found here . FME files can be downloaded by following these links: FME Workbench File (requires a Canopy Cover Layer) Alternative FME Workbench File (does not require a Canopy Cover Layer Further information on the generation of a Canopy Cover Layer can be found here . 2.2 Running Terrascan \u00b6 Terrascan offers multiple ways to detect trees from point clouds. In this project, we focused on the fully automatic segmentation, which is available through the \"Assign Groups\" command. As already said (cf. here ), two methods are available: highest point (aka \"watershed\") method and trunk method. In what follows, we introduce the reader to the various parameters that are involved in such methods. 2.2.1 Watershed method parameters \u00b6 Group planar surfaces \u00b6 Quoting the official documentation , If on, points that fit to planes are grouped. Points fitting to the same plane get the same group number. Min height \u00b6 This parameter defines a minimum threshold on the distance from the ground that the highest of a group of points must have, in order for the group to be considered as a tree. The default value is 4 meters. The Inventaire Cantonal des Arbres Isol\u00e9s includes trees which are at least 3 m high. This parameter ranged from 2 to 6 m in our tests. Figure 2.6: Cross-section view of two detected trees. The left tree would not be detected if the parameter \"Min height\" were larger than 3.5 m. Require \u00b6 This parameter defines the minimum number of points which are required to form a group ( i.e. a tree). The default value is 20 points, which is very low in light of the high density of the dataset we used. Probably, the default value is meant to be used with point clouds having a one order of magnitude smaller density. In our analysis, we tested the following values: 20 (default), 50, 200, 1000, 2000, 4000, 6000. 2.2.2 Trunk method parameters \u00b6 Group planar surfaces \u00b6 See here . Min Height \u00b6 Same role as in the watershed method, see here . Max diameter \u00b6 This parameter defines the maximum diameter (in meters) which a group of points identified as trunk can reach. Default value is 0.6 meters. Knowing that very few trees of the ICA exceed this value; yet, older trees can exhibit larger diameters, we used the following values: 0.20, 0.30, 0.40, 0.60 (default), 0.80, 1.00, 1.50 meters. Min trunk \u00b6 This parameter defines a minimum threshold on the length of tree trunks. Default value is 2 m. We tested the following values: 0.50, 1.00, 1.50, 2.00 (default), 2.50, 3.00, 4.00, 5.00 meters. Group by density \u00b6 Quoting the official documentation , If on, points are grouped based on their distance to each other. Close-by points get the same group number. Gap \u00b6 Quoting the official documentation , Distance between consecutive groups: Automatic: the software decides what points belong to one group or to another. This is recommended for objects with variable gaps, such as moving objects on a road. User fixed: the user can define a fixed distance value in the text field. This is suited for fixed objects with large distances in between, such as powerline towers. We did not attempt the optimization of this parameter but kept the default value (Auto). 2.2.3 Visualizing results \u00b6 Terrascan allows the user to visualize the outcome of the tree segmentation straight from within the Graphical User Interface. Points belonging to the same group ( i.e. to the same tree) are assigned the same random color, which allows the user to perform intuitive, quick, qualitative in-app assessments. An example is provided in Figure 2.7. Figure 2.7: Three examples of tree segmentations. From a qualitative point of view, we can acknowledge that the leftmost (rightmost) example is affected by undersegmentation (oversegmentation). The example in the middle seems to be a good compromise. 2.2.4 Exporting results \u00b6 As already said, Terrascan takes point clouds as input data and can run algorithms which form group out of these points, each group corresponding to an individual tree. A host of \"features\" (or \"measurements\"/ \"attributes\"/...) are generated for each group, which the user can export to text files using the \"Write group info\" command. The set of exported features can be customized through a dedicated configuration panel which can be found within the software settings (\"File formats / User group formats\"). The list and documentation of all the exportable features can be found here . Let us note that depending on the segmentation method, not all the features can be populated; multiple geolocation information can exist. The following table summarizes the features which the watershed and trunk methods can export: Feature Watershed Method Trunk Method Group ID Yes Yes Point Count Yes Yes Average XY Coordinates Yes Yes Ground Z at Avg. XY Yes Yes Trunk XY No Yes Ground Z at Trunk XY No Yes Trunk Diameter See here below See here below Canopy Width Yes Yes Biggest Distance above Ground (Max. Height) Yes Yes Smallest Distance above Ground Yes Yes Length Yes Yes Width Yes Yes Height Yes Yes 2.2.5 Trunk Diameters \u00b6 Terrascan integrates a functionality allowing users to measure trunk diameters (see Figure 2.8). Figure 2.8: Screenshots of the trunk diameter measurement function. Let us note that the measurement of trunk diameters can be feasible or not, depending on the number of points which sample a given trunk. We performed some rapid experiments, which showed that some diameters could actually be estimated, given the high density of the point cloud we used (cf. here ). Still, we did not analyzed the reliability of such estimations against reference/ground truth data. 2.3 Running DFT \u00b6 As already said, DFT consists of a collection of functions which can be run either with Octave or MATLAB . The former software was used in the frame of this context. A few custom Octave scripts were written to automatize the exploration of the parameter space. Our preliminary, warm-up tests showed that we could not obtain satisfactory results by using the \"tree top detection method\" (cf. here ). Indeed, upon using this method the F1-score topped at around 40%. Therefore, we devoted our efforts to exploring the parameter space of the other available method, namely the \"tree stem detection method\" (cf. this tutorial ). In the following, we provide a brief description of the various parameters involved in such a detection method. 2.3.2 Parameters concerned by the tree stem detection method \u00b6 Quoting the official tutorial , The stem detection algorithm uses the planimetric coordinates and height of the points above ground as an input. To compute the height, DFT provides a function called elevationModels , which takes the classified 3D point cloud as input, as well as some parameters. Regarding these parameters, we stuck to the values suggested by the official tutorial, except for the cellSize parameter (= size of the raster cells) which was set to 0.8 (meters); the searchRadius parameter which was set to 10 (meters). Once that each point is assigned an height above the ground, the actual tree stem detection algorithm can be invoked ( treeStems DFT function, cf. DFT Tree Stem Detection Tutorial / Step 4 - Detect the stems ), which takes a host of parameters. While referring the reader to the official tutorial for the definition of these parameters, we provide the list of values we used (unit = meters): Parameter Value cellSize 0.9 bandWidth 0.7 verticalStep 0.15 searchRadius from 1 to 6, step = 0.5 minLength from 1 to 6, step = 0.5 searchRadius ( minLength ) was fixed to 4 (meters) when minLength ( searchRadius ) was let vary between 1 and 6 meters. 2.3.3 Visualizing results \u00b6 DFT does not include any specific Graphical User Interface. Still, users can rely on Octave/MATLAB to generate plots, something useful and clever especially when performing analysis in an interactive way. In our case, DFT was used in a non-interactive way and visualisation was delayed until the assessment step, which we describe in Section 2.4 . 2.3.4 Exporting results \u00b6 Thanks to the vast Octave/MATLAB ecosystem, DFT results can be output to disk in several ways and using data formats. More specifically, we used the ESRI Shapefile file format to export the average (x, y) coordinates of the detected stems/peaks. 2.3.5 Trunk diameters \u00b6 This feature is missing in DFT. 2.4 Post-processing: assessment algorithm and metrics computation \u00b6 As already said, the STDL used a couple of third-party tools, namely TerraScan and the Digital Forestry Toolbox (DFT) , in order to detect trees from point clouds. Both tools can output a segmented point cloud, in which points associated to the same tree are assigned the same identifier; one (X, Y, Z) triplet per detected tree, where the X, Y and Z (optional) coordinates are computed either as the centroid of all the points which get associated to a given tree, or - under some conditions - as the centroid of the trunk only; expressed in the same reference system as the input point cloud. As the ground truth data the STDL was provided with take the form of one (X', Y') pair per tree, with Z' implicitly equal to 1 meter above the ground, the comparison between detections and ground truth trees could only be performed on the common ground of 2D space. In other words, we could not assess the 3D point clouds segmentations obtained by either TerraScan or DFT against reference/ground truth segmentations in the 3D space. The problem which needed to be solved amounts to finding matching and unmatching items between two sets of 2D points: a 1st set including the (X', Y') coordinates of ground truth trees; a 2nd set including the (X, Y) coordinates of detected trees. In order to fulfill the requirement of a 1 meter accuracy which was set by the beneficiaries of this project, the following matching rule was adopted: a detection (D) matches a ground truth tree (GT) (and vice versa) if and only if the Cartesian distance between D and GT is less or equal to 1 meter Figure 2.9 shows how such a rule would allow one to tag detections as either True Positives (TPs) or False Positives (FPs) ground truth trees as either True Positives (TPs) or False Negatives (FNs) in the most trivial case. Figure 2.9: Tagging as True Positive (TP), False Positive (FP), False Negative (FN) ground truth and detected trees in the most trivial case. Actually, far less trivial cases can arise, such as the one illustrated in Figure 2.10. Figure 2.10: Only one detection can exist for two candidate ground truth trees, or else two detections can exist for only one candidate ground truth tree. The STDL designed and implemented an algorithm, which would produce relevant TP, FP, FN tags and counts even in such more complex cases. For instance, in a setting like the one in the image here above, one would expect the algorithm to count 2 TPs, 1 FP, 1 FN. Details are provided here below. 2.4.1 The tagging and counting algorithm \u00b6 1st step: geohash detections and ground truth trees \u00b6 In order to keep track of the various detections and ground truth trees all along the execution of the assessment algorithm, each item is given a unique identifier, computed as the geohash of its coordinates, using the pygeohash Python module. Such identifier is not only unique (as far as a sufficiently high precision is used), but also stable across subsequent executions. The latter property allows analysts to \"synchronise\" the concerned objects between the output of the (Python) code and the views generated with GIS tools such as QGIS , which turns out to be quite useful especially at development and debugging time. 2nd step: convert point detections to circles \u00b6 As a 2nd step, each detection is converted to a circle, centered on the (X, Y) coordinates of the detection; having a 1 m radius. This operation can be accomplished by generating a 1 m buffer around each detection. For the sake of precision, this method was used, which generates a polygonal surface approximating the intended circle. 3rd step: perform left and right outer spatial joins \u00b6 As a 3rd step, the following two spatial joins are computed: left outer join between the circles generated at the previous step and ground truth trees; right outer join between the same two operands. In both cases, the \"intersects\" operation is used (cf. this page for more technical details). 4th step: tag trivial False Positives and False Negatives \u00b6 All those detections output by the left outer join for which no right attribute exists (in particular, we focus on the right geohash) can trivially be tagged as FPs. As a matter of fact, this means that the 1 m circular buffer surrounding the detection does not intersect any ground truth tree; in other words, that no ground truth tree can be found within 1 m from the detection. The same reasoning leads to trivially tagging as FNs all those ground truth trees output by the right outer join for which no left attribute exists. These cases correspond to the two rightmost items in Fig. 6.1. For reasons which will be clarified here below, the algorithm does not actually tag items as either FPs or FNs; instead, TP and FP \"charges\" are assigned to detected trees; TP and FN charges are assigned to ground truth trees. Here's how: for FP detected trees: TP charge FP charge 0 1 for FN ground truth trees: TP charge FN charge 0 1 5th step: tag non-trivial False Positives and False Negatives \u00b6 The left outer spatial join performed at step 3 establishes relations between each detection and those ground truth trees which are located no further than 1 meter, as shown in Figure 2.11. Figure 2.11: The spatial join between buffered detections and ground truth trees establishes relations between groups of items of these two populations. In the sample setting depicted in this picture, two unrelated groups can be found. The example here above shows 4 relations, D1 - GT1, D1 - GT2, D2 - GT3, D3 - GT3 which can be split (see the red dashed line) into two unrelated, independent groups: {D1 - GT1, D1 - GT2} {D2 - GT3, D3 - GT3} In order to generate this kind of groups in a programmatic way, the algorithm first builds a graph out of the relations established by the left outer spatial join, then it extracts the connected components of such a graph (cf. this page ). The tagging and counting of TPs, FPs, FNs is performed on a per-group basis, according to the following strategy: if a group contains more ground truth than detected trees, then the group is assigned an excess \"FN charge\", equal to the difference between the number of ground truth trees and detected trees. This excess charge is then divided by the number of ground truth trees and the result assigned to each of them. For instance, the {D1 - GT1, D1 - GT2} group in the image here above would be assigned an FN charge equal to 1; then, each ground truth tree would be assigned an FN charge equal to 1/2. Similarly, if a group contains more detected trees than ground truth trees, then the group is assigned an excess FP charge, equal to the difference between the number of detected trees and ground truth trees. This excess charge is then divided by the number of detections and the result assigned to each of them. For instance, the {D2 - GT3, D3 - GT3} group in the image here above would be assigned an excess FN charge equal to 1; then, each detection would be assigned an FP charge equal to 1/2. In case the number of ground truth trees be the same as the number of detections, no excess FN/FP charge is assigned to the group. Concerning the assignment of TP charges, the per-group budget is established as the minimum between the number of ground truth and detected trees, then equally split between the items of these two populations. In the example above, both groups would be assigned TP charge = 1. Wrapping things up, here are the charges which the algorithm would assign to the various items of the example here above: item TP charge FP charge Total charge D1 1 0 1 D2 1/2 1/2 1 D3 1/2 1/2 1 Sum 2 1 3 item TP charge FN charge Total charge GT1 1/2 1/2 1 GT2 1/2 1/2 1 GT3 1 0 1 Sum 2 1 3 Let us note that: the count of TPs yields the same result, whether we consider detections or ground truth trees, which makes sense; the \"Total charge\" column allows one to check the consistency of the algorithm; as expected, we obtain 2 FPs, 1 FP, 1 FN; the algorithm does not even attempt to establish 1:1 relations, \"optimal\" in a given sense, between ground truth and detected trees. As a matter of fact, the algorithm is designed to produce meaningful counts and tags only; of course, the algorithm also works in far more complex settings than the one depicted in Figs. 6.2 and 6.3. 2.4.2 From counts to metrics \u00b6 TP, FP, FN counts are extensive properties, out of which we can compute some standard metrics such as precision recall F1-score which are intensive, instead. While referring the reader to this paragraph for the definition of these metrics, let us state the interpretation which holds in the present use case: precision is optimal (= 1.0) if and only if (iff) all the detections are matched by ground truth trees (no FPs); recall is optimal (= 1.0) iff all the ground truth trees are detected (no FNs). Typically, one cannot optimize both precision and recall for the same values of a set of parameters. Instead, they can exhibit opposite trends as a function of a given parameter ( e.g. precision increases while recall decreases). In such cases, the F1-score would exhibit convexity and could be optimized. 3. Results and discussion \u00b6 Figure 3.1 shows some of the tree detection trials we performed, using Terrascan and DFT. Each trial corresponds to a different set of parameters and is represented either by gray dots or colored diamonds in a precision-recall plot (see the image caption for further details). Figure 3.1: Precision vs. Recall of a subset of the tree detections we attempted, using different parameters in Terrascan and DFT. Colored diamonds represent the starting point (red) as well as our \"last stops\" in the parameter space, with (yellow, green) and without (orange) pre-processing. All the three test sectors are here combined. Let us note that: the DFT parameter space can be conveniently explored by scripting the batch execution of various runs; on the contrary, the exploration of the Terrascan parameter space is more laborious, has to be performed manually, trying out one specific set of parameters after another, with repeated manual export of features (including geographical coordinates) in between. Indeed, although Terrascan let users define macros, unfortunately the \"Write Group Info\" command cannot be used in macros; in both cases, the parameter space was explored in quite an heuristic and partial way; we aimed at optimizing the F1-score all sectors combined. More detailed comments follow, concerning the best trials made with Terrascan and DFT. 3.1 The best trial made with Terrascan \u00b6 Among the trials we ran with Terrascan, the one which yielded the best F1-score was obtained using the following parameters: Parameter Value Method / Algorithm Trunk Classes 4+5, cleaned and reclassified Group planar surfaces Off Min height 3.00 m Max diameter 0.40 m Min trunk 3.00 m Group by density On Gap Auto Require 1500 pts This trial corresponds to the green diamond shown in Figure 3.1. Figure 3.2: Test sectors as segmented by the best trial made with Terrascan. Figure 3.2 provides a view of the outcome on the three test sectors. Metrics read as follows: Sector TP FP FN Detectable (TP+FN) Precision Recall F1-Score Global 323 137 234 557 70.2% 58.0% 63.5% Adrien-Jeandin 177 69 160 337 72.0% 52.5% 60.7% Bel-Air 114 15 11 125 88.4% 91.2% 89.8% Floraire 32 53 63 89 37.6% 33.7% 35.6% Figure 3.3 provides a graphical representation of the same findings, with the addition of the metrics we computed before cleaning and reclassifying the LiDAR point cloud. Figure 3.3: Cleaning and reclassifying the point cloud has a positive influence on precision and recall, although modest. Our results confirm that the tree detection task is more or less hard depending on the sector at hand. Without any surprise, we acknowledge that: the \"Avenue de Bel-Air\" test sector (BEL), enjoying an alley of well-separated trees, is easily tackled by Terrascan. Quite decent precision and recall are obtained. In contrast, the \"Parc Floraire\" test sector (FLO) turns out to be the hardest one, given the vegetation density and heterogeneity. The \"Adrien-Jeandin\" (ADR) is actually a mix of dense and sparse contexts and turns out to be a good proxy for the global performance. Cleaning and Reclassification have a benificial impact on Precision and Recall for all sectors as well as the global context (TOT). While for BEL mainly Recall profited from preprocessing, ADR and FLO showed a stronger increase in Precision. For the global context both, Precision and Recall, could be increased slighty. Figure 3.4: The F1-score attained by our best Terrascan trial. Figure 3.4 shows how our best Terrascan trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that pre-processing slightly improves the F1-score for the global context as well as for the individual sectors. The largest impact was observed for the Bel-Air sector, especially for preprocessing including Reclassification. 3.2 The best trial made with DFT \u00b6 The DFT trial yielding the highest global F1-score was obtained using the stem detection method and the following parameters: Parameter Value Method / Algorithm Stem detection Classes 4+5, cleaned and reclassified Search radius 4.00 Minimum length 4.00 Here's a summary of the resulting metrics: Sector Precision Recall F1-score Adrien-Jeandin 75.4% 36.5% 49.2% Bel-Air 88.0% 82.4% 85.1% Floraire 47.9% 36.8% 41.7% Global 74.0% 46.6% 57.2% Similar comments to those formulated here apply: the \"Avenue de Bel-Air\" sector remains the easiest to process; \"Parc Floraire\" the hardest. However, here we acknowledge a bigger gap between the global F1-score and the F1-score related to the \"Adrien-Jeandin\" test sector. Figure 3.5 shows how our best DFT trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that the impact of point cloud reclassification can be slightly positive or negative depending on the test sector. Figure 3.5: The F1-score attained by our best DFT trial. 3.3 Comparison: Terrascan vs. DFT \u00b6 Figure 3.6: Comparison of Terrascan and DFT in terms of F1-score. The comparison of the best Terrascan trial vs. the best DFT trial in terms of F1-score shows that there is no clear winner (see Figure 3.6). Still, we can notice that: DFT reaches the best F1-score ever in the \"Parc Floraire\" (\"Avenue de Bel-Air\") sector, without (with) pre-processing. Terrascan performs slightly better on global scores and substantially better on the mixed context of the Adrien-Jeandin sector,especially after pre-processing. 3.4 Trials with standard-density datasets \u00b6 In addition to applying our method to the 2021 high-density (HD) LiDAR dataset, we also tried using two other datasets exhibiting a by far more standard point density (20-30 pt/m\u00b2): Nuage de points LiDAR 2017 Nuage de points LiDAR 2019 The goal was twofold: finding evidence for the added value of high-density (HD) datasets, despite their higher cost; checking whether the parameters which turned out to yield optimal scores with HD LiDAR data could also yield acceptable results if used with standard-density (SD) datasets. Concerning the 1st point, lower point densities make the \"trunk method\" unreliable (if not completely unusable). In Figure 3.7, we report results obtained with the watershed method, along with results related to the best performing trials obtained with the 2021 HD dataset. The scores we obtained with the SD dataset are far below the best we obtained with the HD dataset, confirming the interest of high-density acquisitions. Figure 3.7: Comparison of F1-scores of the best performing trials. Parameters were optimized for each model individually. Concerning the 2nd point, without any surprise we confirmed that parameters must be re-optimized for SD datasets. The usage of the set of parameters which were optimized on the basis of the HD dataset yielded poor results, as shown in Figure 3.8. Figure 3.8: Using the parameters which were optimized for the high-density dataset leads to poor results (strong under-segmentation) on SD datasets. In accordance with the TS documentation we can see that the trunk method is unusable for lower and medium density datasets. The watershed algorithm produces a more realistic segmentation pattern on the SD dataset but still cannot reach the performance levels of the trunk or the watershed method on the HD dataset. After optimizing parameters, we could obtain quite decent results though (see Figure 3.9). Figure 3.9: After a dataset-specific parameter optimization, convincing results can be achieved on the medium-density 2019 dataset (Terrascan's watershed method was used). 3.5 Tree detection over the full 2021 high-density LiDAR dataset \u00b6 Clearly, from a computational point of view processing large point cloud dataset is not the same as processing small datasets. Given the extremely high density of the 2021 LiDAR datasets, we wanted to check whether and how Terrascan could handle such a resource-intensive task. Thanks to Terrascan's macro actions, one can split the task into a set of smaller sub-tasks, each sub-task dealing with a \"tile\" of the full dataset. Additionally, Terrascan integrates quite a smart feature, which automatically merges groups of points ( i.e. trees) spanning multiple tiles. Figure 3.10 provides a static view of the results we obtained, using the parameters which globally performed the best on the three sectors. We refer the reader to this Potree viewer (kindly hosted by the G\u00e9oportail du SITN ) for an interactive view. Figure 3.10: Result of the application of the best performing Terrascan parameters to the full dataset. 4. Conclusion and outlook \u00b6 Despite all the efforts documented here above, the results we obtained are not as satisfactory as expected. Indeed, the metrics we managed to attain all sectors combined indicate that tree detections are neither reliable (low precision) nor exhaustive (low recall). Still, we think that results may be improved by further developing some ideas, which we sketch in the following. 4.1 Further the DFT parameter space exploration \u00b6 We devoted much more time to exploring Terrascan's parameter space than DFT's. Indeed, as already stated here , we only explored the two parameters searchRadius and minLenght . Other parameters such as cellSize , bandwidth and verticalStep were not explored at all (we kept default values). We think it is definitely worth exploring these other parameters, too. Moreover, we did not try feeding all the LiDAR returns to the stem detection method, we only used the last returns. It is surely worth checking whether the usage of the other returns could be beneficial. Upon using the peak detection method, we did not manage to reach a better F1-score than ~40%, as opposed to the 57% obtained with the stem detection method. However, the peak detection method is particularly interesting because it can also delimit canopies. Hence, it may be worth trying to improve the F1-score, for instance by tuning the parameters of the power law equation relating the crown radius to the tree height (cf. here ). 4.2 Exploit contextual information \u00b6 We showed that the algorithms implemented by TerraScan and DFT yield much better results in sparse contexts (ex.: the \"Avenue de Bel-Air\" test sector) than in dense ones (ex.: the \"Parc Floraire\" test sector). This means that precision may be improved (at the expense of recall, though) if one could restrain the tree detection to sparse contexts only, either as a pre- or post-processing step. We can think of at least a couple of methods which would allow one to (semi-)automatically tell sparse from dense contexts: intrinsic method: after segmenting the point cloud into individual trees, one could analyze how close (far) each individual is to (from) the nearest neighbor and estimate the density of trees on some 2D or 3D grid; extrinsic method: territorial data exist (see for instance the dataset \"Carte de couverture du sol selon classification OTEMO\" distributed by the SITG ), providing information about urban planning and land use ( e.g . roads, parks, sidewalks, etc.). These data may be analyzed in order to extract hints on how likely it is for a tree to be in close proximity with another, according to its position. 4.3 Combine detections stemming from two or more independent trials \u00b6 Detections coming from two or more independent trials (obtained with different software or else with the same software but different parameters) could be combined in order to improve either precision or recall: recall would be improved (i.e. the number of false negatives would be reduced) if detections coming from multiple trials were merged. In order to prevent double counting, two or more detections coming from two or more sources could be counted as just one if they were found within a given distance from each other. The algorithm would follow along similar lines as the ones which led us to the \"tagging and counting algorithm\" presented here above ; precision would be improved (i.e. the number of false positives would be reduced) if we considered only those detections for which a consensus could be established among two or more trials, and discarded the rest. A distance-based criterion could be used to establish such consensus, along similar lines as those leading to our \"tagging and counting algorithm\" . 4.4 Use generic point cloud segmentation algorithms \u00b6 Generic ( i.e. not tailored for tree detection) clustering algorithms exist, such as DBSCAN (\"Density-Based Spatial Clustering of Applications with Noise\", see e.g. here ), which could be used to segment a LiDAR point cloud into individual trees. We think it would be worth giving these algorithms a try! 4.5 Use Machine Learning \u00b6 The segmentation algorithms we used in this project do not rely on Machine Learning. Yet, alternative/complementary approaches might me investigated, in which a point cloud segmentation model would be first trained on reference data, then used to infer tree segmentations within a given area of interest. For instance, it would be tempting to test this Deep Learning model published by ESRI and usable with their ArcGIS Pro software. It would be also worth deep diving into this research paper and try replicating the proposed methodology. Regarding training data, we could generate a ground truth dataset by using our best TerraScan/DFT model to segment the 3D point cloud; using 2D ground truth data to filter out wrong segmentations. 5. Other resources \u00b6 The work documented here was the object of a Forum SITG which took place online on March 29, 2022. Videos and presentation materials can be found here . 6. Acknowledgements \u00b6 This project was made possible thanks to a tight collaboration between the STDL team and some experts of the Canton of Neuch\u00e2tel (NE), the Canton of Geneva (GE), the Conservatoire et Jardin botaniques de la Ville de Gen\u00e8ve (CJBG) and the University of Geneva (UNIGE). The STDL team acknowledges key contributions from Marc Riedo (SITN, NE), Bertrand Favre (OCAN, GE), Nicolas Wyler (CJBG) and Gregory Giuliani (UNIGE). We also wish to warmly thank Matthew Parkan for developing, maintaining and advising us on the Digital Forestry Toolbox .","title":"<span style=\"text-transform:uppercase;\"> Tree Detection from Point Clouds over the Canton of Geneva </span>"},{"location":"PROJ-TREEDET/#tree-detection-from-point-clouds-over-the-canton-of-geneva","text":"Alessandro Cerioni (Canton of Geneva) - Flann Chambers (University of Geneva) - Gilles Gay des Combes (CJBG - City of Geneva and University of Geneva) - Adrian Meyer (FHNW) - Roxane Pott (swisstopo) Proposed by the Canton of Geneva - PROJ-TREEDET May 2021 to March 2022 - Published on April 22, 2022 Abstract : Trees are essential assets, in urban context among others. Since several years, the Canton of Geneva maintains a digital inventory of isolated (or \"urban\") trees. This project aimed at designing a methodology to automatically update Geneva's tree inventory, using high-density LiDAR data and off-the-shelf software. Eventually, only the sub-task of detecting and geolocating trees was explored. Comparisons against ground truth data show that the task can be more or less tricky depending on how sparse or dense trees are. In mixed contexts, we managed to reach an accuracy of around 60%, which unfortunately is not high enough to foresee a fully unsupervised process. Still, as discussed in the concluding section there may be room for improvement.","title":" Tree Detection from Point Clouds over the Canton of Geneva "},{"location":"PROJ-TREEDET/#1-introduction","text":"","title":"1. Introduction"},{"location":"PROJ-TREEDET/#11-context","text":"Human societies benefits from the presence of trees in cities and their surroundings. More specifically, as far as urban contexts are concerned, trees deliver many ecosystem services such as: the reduction of heat islands, by shading and cooling their direct environment; the mitigation of flood risks, by intercepting precipitation through their foliage and increasing soil infiltration; the reduction of atmospheric pollution; the reduction of noise pollution; a positive contribution to the physical, mental and social health of the population. Moreover, they play an important role of support of the biodiversity by offering resources and shelter to numerous animal, plant and fungus species. The quality and quantity of such benefits depend on various parameters, such as the height, the age, the leaf area, the species diversity within a given population of trees. Therefore, the preservation and the development of a healthy and functional tree population is one of the key elements of those public policies which aim at increasing resilience against climate change. For these reasons, the Canton of Geneva has set the ambitious goal of increasing its canopy cover (= ratio between the area covered by foliage and the total area) from 21% (as estimated in 2019) to 30% by 2050. In order to reach this goal, the concerned authorities ( i.e. the Office cantonal de l\u2019agriculture et de la nature ) need detailed data and tools to keep track of the cantonal tree population and drive its development. The Inventaire Cantonal des Arbres Isol\u00e9s (ICA) is the most extensive and detailed source of data on isolated trees (= trees that do not grow in forests) within the Canton of Geneva. Such dataset is maintained by a joint effort of several public administrations (green spaces departments of various municipalities, the Office cantonal de l\u2019agriculture et de la nature , the Geneva Conservatory and Botanical Garden, etc.). For each tree, several attributes are provided: geographical coordinates, species, height, plantation date, trunk diameter, crown diameter, etc. To date, the ICA includes data about more than 237 000 trees. However, it comes with a host of known limitations: only the public domain is covered (no records about trees which are found within private properties); moreover, the coverage of the public domain is partial (business experts estimate that half of the actual trees are missing). The freshness of data is not consistent among the various records, as it relies on sporadic ground surveys and manual updates. Trees tagged as \"historical\" lack precision in terms of geolocation and taxonomical information. In light of Geneva's ambitions in terms of the canopy growth, the latter observations call for the need of a more efficient methodology to improve the exhaustivity and veracity of the ICA. Over the last few years, several joint projects of the Canton, the City and the University of Geneva explored the potential of using LiDAR point clouds and tailored software to characterize trees in a semi-automatic way, following practices that are already established in forestry. Yet, forest and urban settings are quite different from each other: forests exhibit higher tree density, which can hinder tree detection; forests exhibit lower heterogeneity in terms of species and morphology, which can facilitate tree detection. Hence, the task of automatic detection is likely to be harder in urban contexts than in forests. The study reported in this page, proposed by the Office cantonal de l\u2019agriculture et de la nature (OCAN) and carried out by the STDL, represents a further yet modest step ahead towards the semi-automatic digitalisation of urban trees.","title":"1.1 Context"},{"location":"PROJ-TREEDET/#12-objectives","text":"The objectives of this project was fixed by the OCAN domain experts and, in one sentence, amount to designing a robust and reproducible semi-automatic methodology allowing one to \"know everything\" about each and every isolated tree of the Canton of Geneva, which means: detecting all the trees (exhaustivity); geolocating the trunk and the top of every tree; measuring all the properties of every tree: height, trunk and crown diameter, canopy area and volume; identify species. Regarding quality, the following requirements were fixed: Property Expected precision Trunk geolocation 1 m Top geolocation 1 m Height 2 m Trunk diameter at 1m height 10 cm Crown diameter 1 m Canopy area 1 m\u00b2 Canopy volume 1 m\u00b3 In spite of such thorough and ambitious objectives, the time span of this project was not long enough to address them all. As a matter of fact, the STDL team only managed to tackle the tree detection and trunk geolocation.","title":"1.2 Objectives"},{"location":"PROJ-TREEDET/#13-methodology","text":"As shown in Figure 1.1 here below, algorithms and software exist, which can detect individual trees from point clouds. Figure 1.1: The two panels represent a sample of a point cloud before (top panel) and after (bottom) tree detection. Not only such tools take point cloud as input data, but also the values of a bunch of parameters have to be chosen by users. The quality of results depend both on input data and on input parameters. The application of some pre-processing to the input point cloud have an impact, too. Therefore, it becomes clear that in order to find the optimal configuration for a given context, one should be able to measure the quality of results as a function of the chosen parameters as well as of the pre-processing operations. To this end, the STDL team called for the acquisition of ground truth data. Further details about input data (point cloud and ground truth), software and methodology will be provided shortly.","title":"1.3 Methodology"},{"location":"PROJ-TREEDET/#14-input-data","text":"","title":"1.4 Input data"},{"location":"PROJ-TREEDET/#15-off-the-shelf-software","text":"Two off-the-shelf software products were used to detect trees from LiDAR data, namely TerraScan and the Digital Forestry Toolbox (DFT). The following table summarizes the main similarities and differences between the two: Feature Terrascan DFT Licence Proprietary (*) Open Source (GPL-3.0) Price See here Free Standalone No: requires MicroStation or Spatix No: requires Octave or MATLAB Graphical User Interface Yes No In-app point cloud visualization Yes (via MicroStation or Spatix ) No (**) Scriptable Partly (via macros ) Yes Hackable No Yes (*) Unfortunately, we must acknowledge that using network licenses turned out to be quite problematic. Weeks of unexpected downtime were experienced, due to puzzling issues related to the interplay between the self-hosted license server, firewalls, VPN and end-devices. (**) We used the excellent Potree Free and Open Source software for visualization. The following sections are devoted to brief descriptions of these two tools; further details will be provided in Section 4 and Section 5 .","title":"1.5 Off-the-shelf software"},{"location":"PROJ-TREEDET/#2-method","text":"As already stated, in spite of the thorough and ambitious objectives of this project (cf. here ), only the tree detection and trunk geolocation sub-tasks could be tackled given the resources (time, humans) which were allocated to the STDL. The method we followed goes through several steps, pre-processing, running Terrascan or DFT, post-processing, which are documented here-below.","title":"2. Method"},{"location":"PROJ-TREEDET/#21-pre-processing-point-cloud-reclassification-and-cleaning","text":"[1] In some cases, points corresponding to trunks may be misclassified and lay in class 0 \u2013 Unclassified instead of class 4 \u2013 Medium vegetation . As the segmentation process only takes vegetation classes (namely classes 4 and 5) into account, the lack of trunk points can make some trees \"invisibles\". [2] We suspected that the standard classification of vegetation in LiDAR point clouds could be too basic for the task at hand. Indeed, vegetation points found at less (more) than 3 m above the ground are classified as 4 \u2013 Medium Vegetation ( 5 \u2013 High Vegetation ). This may cause one potential issue: all the points of a given tree that are located at up to 3 meters above the ground (think about the trunk!) belong to a class (namely class no. 4) which can also be populated by bushes and hedges. The \"contamination\" by bushes and hedges may spoil the segmentation process, especially in situations where dense low vegetation exists around higher trees. Indeed, it was acknowledged that in such situations the segmentation algorithm fails to properly identify trunk locations and distinguish one tree from another. Issues [1] and [2] can be solved or at least mitigated by reclassifying and cleaning the input point cloud, respectively. Figures 2.1 and 2.2 show how tree grouping (or \"segmentation\") yields better results if pre-processed pointclouds are used. Figure 2.1: Tree grouping (or \"segmentation\") applied to the original (top panel) vs pre-processed (bottom) point cloud. Without pre-processing, two trees connected by a hedge are segmented as one single individual. Therefore, only one detection is made (green circle slightly above the ground). With pre-processing, we get rid of the hedge and recover the lowest trunk points belonging to the tree on the left. Eventually, both trees are properly segmented and we end up having two detections (green circles). Figure 2.2: Tree grouping (or \"segmentation\") applied to the original (left panel) vs reclassified (right) point cloud. Without pre-processing, segmentation yields a spurious detection (= false positive, red circle slightly above the ground), resulting from the combination of a pole and a hedge. With pre-processing, we get rid of most of the points belonging to the hedge and the pole; no false positive shows up.","title":"2.1 Pre-processing: point cloud reclassification and cleaning"},{"location":"PROJ-TREEDET/#22-running-terrascan","text":"Terrascan offers multiple ways to detect trees from point clouds. In this project, we focused on the fully automatic segmentation, which is available through the \"Assign Groups\" command. As already said (cf. here ), two methods are available: highest point (aka \"watershed\") method and trunk method. In what follows, we introduce the reader to the various parameters that are involved in such methods.","title":"2.2 Running Terrascan"},{"location":"PROJ-TREEDET/#23-running-dft","text":"As already said, DFT consists of a collection of functions which can be run either with Octave or MATLAB . The former software was used in the frame of this context. A few custom Octave scripts were written to automatize the exploration of the parameter space. Our preliminary, warm-up tests showed that we could not obtain satisfactory results by using the \"tree top detection method\" (cf. here ). Indeed, upon using this method the F1-score topped at around 40%. Therefore, we devoted our efforts to exploring the parameter space of the other available method, namely the \"tree stem detection method\" (cf. this tutorial ). In the following, we provide a brief description of the various parameters involved in such a detection method.","title":"2.3 Running DFT"},{"location":"PROJ-TREEDET/#24-post-processing-assessment-algorithm-and-metrics-computation","text":"As already said, the STDL used a couple of third-party tools, namely TerraScan and the Digital Forestry Toolbox (DFT) , in order to detect trees from point clouds. Both tools can output a segmented point cloud, in which points associated to the same tree are assigned the same identifier; one (X, Y, Z) triplet per detected tree, where the X, Y and Z (optional) coordinates are computed either as the centroid of all the points which get associated to a given tree, or - under some conditions - as the centroid of the trunk only; expressed in the same reference system as the input point cloud. As the ground truth data the STDL was provided with take the form of one (X', Y') pair per tree, with Z' implicitly equal to 1 meter above the ground, the comparison between detections and ground truth trees could only be performed on the common ground of 2D space. In other words, we could not assess the 3D point clouds segmentations obtained by either TerraScan or DFT against reference/ground truth segmentations in the 3D space. The problem which needed to be solved amounts to finding matching and unmatching items between two sets of 2D points: a 1st set including the (X', Y') coordinates of ground truth trees; a 2nd set including the (X, Y) coordinates of detected trees. In order to fulfill the requirement of a 1 meter accuracy which was set by the beneficiaries of this project, the following matching rule was adopted: a detection (D) matches a ground truth tree (GT) (and vice versa) if and only if the Cartesian distance between D and GT is less or equal to 1 meter Figure 2.9 shows how such a rule would allow one to tag detections as either True Positives (TPs) or False Positives (FPs) ground truth trees as either True Positives (TPs) or False Negatives (FNs) in the most trivial case. Figure 2.9: Tagging as True Positive (TP), False Positive (FP), False Negative (FN) ground truth and detected trees in the most trivial case. Actually, far less trivial cases can arise, such as the one illustrated in Figure 2.10. Figure 2.10: Only one detection can exist for two candidate ground truth trees, or else two detections can exist for only one candidate ground truth tree. The STDL designed and implemented an algorithm, which would produce relevant TP, FP, FN tags and counts even in such more complex cases. For instance, in a setting like the one in the image here above, one would expect the algorithm to count 2 TPs, 1 FP, 1 FN. Details are provided here below.","title":"2.4 Post-processing: assessment algorithm and metrics computation"},{"location":"PROJ-TREEDET/#3-results-and-discussion","text":"Figure 3.1 shows some of the tree detection trials we performed, using Terrascan and DFT. Each trial corresponds to a different set of parameters and is represented either by gray dots or colored diamonds in a precision-recall plot (see the image caption for further details). Figure 3.1: Precision vs. Recall of a subset of the tree detections we attempted, using different parameters in Terrascan and DFT. Colored diamonds represent the starting point (red) as well as our \"last stops\" in the parameter space, with (yellow, green) and without (orange) pre-processing. All the three test sectors are here combined. Let us note that: the DFT parameter space can be conveniently explored by scripting the batch execution of various runs; on the contrary, the exploration of the Terrascan parameter space is more laborious, has to be performed manually, trying out one specific set of parameters after another, with repeated manual export of features (including geographical coordinates) in between. Indeed, although Terrascan let users define macros, unfortunately the \"Write Group Info\" command cannot be used in macros; in both cases, the parameter space was explored in quite an heuristic and partial way; we aimed at optimizing the F1-score all sectors combined. More detailed comments follow, concerning the best trials made with Terrascan and DFT.","title":"3. Results and discussion"},{"location":"PROJ-TREEDET/#31-the-best-trial-made-with-terrascan","text":"Among the trials we ran with Terrascan, the one which yielded the best F1-score was obtained using the following parameters: Parameter Value Method / Algorithm Trunk Classes 4+5, cleaned and reclassified Group planar surfaces Off Min height 3.00 m Max diameter 0.40 m Min trunk 3.00 m Group by density On Gap Auto Require 1500 pts This trial corresponds to the green diamond shown in Figure 3.1. Figure 3.2: Test sectors as segmented by the best trial made with Terrascan. Figure 3.2 provides a view of the outcome on the three test sectors. Metrics read as follows: Sector TP FP FN Detectable (TP+FN) Precision Recall F1-Score Global 323 137 234 557 70.2% 58.0% 63.5% Adrien-Jeandin 177 69 160 337 72.0% 52.5% 60.7% Bel-Air 114 15 11 125 88.4% 91.2% 89.8% Floraire 32 53 63 89 37.6% 33.7% 35.6% Figure 3.3 provides a graphical representation of the same findings, with the addition of the metrics we computed before cleaning and reclassifying the LiDAR point cloud. Figure 3.3: Cleaning and reclassifying the point cloud has a positive influence on precision and recall, although modest. Our results confirm that the tree detection task is more or less hard depending on the sector at hand. Without any surprise, we acknowledge that: the \"Avenue de Bel-Air\" test sector (BEL), enjoying an alley of well-separated trees, is easily tackled by Terrascan. Quite decent precision and recall are obtained. In contrast, the \"Parc Floraire\" test sector (FLO) turns out to be the hardest one, given the vegetation density and heterogeneity. The \"Adrien-Jeandin\" (ADR) is actually a mix of dense and sparse contexts and turns out to be a good proxy for the global performance. Cleaning and Reclassification have a benificial impact on Precision and Recall for all sectors as well as the global context (TOT). While for BEL mainly Recall profited from preprocessing, ADR and FLO showed a stronger increase in Precision. For the global context both, Precision and Recall, could be increased slighty. Figure 3.4: The F1-score attained by our best Terrascan trial. Figure 3.4 shows how our best Terrascan trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that pre-processing slightly improves the F1-score for the global context as well as for the individual sectors. The largest impact was observed for the Bel-Air sector, especially for preprocessing including Reclassification.","title":"3.1 The best trial made with Terrascan"},{"location":"PROJ-TREEDET/#32-the-best-trial-made-with-dft","text":"The DFT trial yielding the highest global F1-score was obtained using the stem detection method and the following parameters: Parameter Value Method / Algorithm Stem detection Classes 4+5, cleaned and reclassified Search radius 4.00 Minimum length 4.00 Here's a summary of the resulting metrics: Sector Precision Recall F1-score Adrien-Jeandin 75.4% 36.5% 49.2% Bel-Air 88.0% 82.4% 85.1% Floraire 47.9% 36.8% 41.7% Global 74.0% 46.6% 57.2% Similar comments to those formulated here apply: the \"Avenue de Bel-Air\" sector remains the easiest to process; \"Parc Floraire\" the hardest. However, here we acknowledge a bigger gap between the global F1-score and the F1-score related to the \"Adrien-Jeandin\" test sector. Figure 3.5 shows how our best DFT trial performed in terms of F1-score: globally, on a per-sector basis; with and without pre-processing. We can notice that the impact of point cloud reclassification can be slightly positive or negative depending on the test sector. Figure 3.5: The F1-score attained by our best DFT trial.","title":"3.2 The best trial made with DFT"},{"location":"PROJ-TREEDET/#33-comparison-terrascan-vs-dft","text":"Figure 3.6: Comparison of Terrascan and DFT in terms of F1-score. The comparison of the best Terrascan trial vs. the best DFT trial in terms of F1-score shows that there is no clear winner (see Figure 3.6). Still, we can notice that: DFT reaches the best F1-score ever in the \"Parc Floraire\" (\"Avenue de Bel-Air\") sector, without (with) pre-processing. Terrascan performs slightly better on global scores and substantially better on the mixed context of the Adrien-Jeandin sector,especially after pre-processing.","title":"3.3 Comparison: Terrascan vs. DFT"},{"location":"PROJ-TREEDET/#34-trials-with-standard-density-datasets","text":"In addition to applying our method to the 2021 high-density (HD) LiDAR dataset, we also tried using two other datasets exhibiting a by far more standard point density (20-30 pt/m\u00b2): Nuage de points LiDAR 2017 Nuage de points LiDAR 2019 The goal was twofold: finding evidence for the added value of high-density (HD) datasets, despite their higher cost; checking whether the parameters which turned out to yield optimal scores with HD LiDAR data could also yield acceptable results if used with standard-density (SD) datasets. Concerning the 1st point, lower point densities make the \"trunk method\" unreliable (if not completely unusable). In Figure 3.7, we report results obtained with the watershed method, along with results related to the best performing trials obtained with the 2021 HD dataset. The scores we obtained with the SD dataset are far below the best we obtained with the HD dataset, confirming the interest of high-density acquisitions. Figure 3.7: Comparison of F1-scores of the best performing trials. Parameters were optimized for each model individually. Concerning the 2nd point, without any surprise we confirmed that parameters must be re-optimized for SD datasets. The usage of the set of parameters which were optimized on the basis of the HD dataset yielded poor results, as shown in Figure 3.8. Figure 3.8: Using the parameters which were optimized for the high-density dataset leads to poor results (strong under-segmentation) on SD datasets. In accordance with the TS documentation we can see that the trunk method is unusable for lower and medium density datasets. The watershed algorithm produces a more realistic segmentation pattern on the SD dataset but still cannot reach the performance levels of the trunk or the watershed method on the HD dataset. After optimizing parameters, we could obtain quite decent results though (see Figure 3.9). Figure 3.9: After a dataset-specific parameter optimization, convincing results can be achieved on the medium-density 2019 dataset (Terrascan's watershed method was used).","title":"3.4 Trials with standard-density datasets"},{"location":"PROJ-TREEDET/#35-tree-detection-over-the-full-2021-high-density-lidar-dataset","text":"Clearly, from a computational point of view processing large point cloud dataset is not the same as processing small datasets. Given the extremely high density of the 2021 LiDAR datasets, we wanted to check whether and how Terrascan could handle such a resource-intensive task. Thanks to Terrascan's macro actions, one can split the task into a set of smaller sub-tasks, each sub-task dealing with a \"tile\" of the full dataset. Additionally, Terrascan integrates quite a smart feature, which automatically merges groups of points ( i.e. trees) spanning multiple tiles. Figure 3.10 provides a static view of the results we obtained, using the parameters which globally performed the best on the three sectors. We refer the reader to this Potree viewer (kindly hosted by the G\u00e9oportail du SITN ) for an interactive view. Figure 3.10: Result of the application of the best performing Terrascan parameters to the full dataset.","title":"3.5 Tree detection over the full 2021 high-density LiDAR dataset"},{"location":"PROJ-TREEDET/#4-conclusion-and-outlook","text":"Despite all the efforts documented here above, the results we obtained are not as satisfactory as expected. Indeed, the metrics we managed to attain all sectors combined indicate that tree detections are neither reliable (low precision) nor exhaustive (low recall). Still, we think that results may be improved by further developing some ideas, which we sketch in the following.","title":"4. Conclusion and outlook"},{"location":"PROJ-TREEDET/#41-further-the-dft-parameter-space-exploration","text":"We devoted much more time to exploring Terrascan's parameter space than DFT's. Indeed, as already stated here , we only explored the two parameters searchRadius and minLenght . Other parameters such as cellSize , bandwidth and verticalStep were not explored at all (we kept default values). We think it is definitely worth exploring these other parameters, too. Moreover, we did not try feeding all the LiDAR returns to the stem detection method, we only used the last returns. It is surely worth checking whether the usage of the other returns could be beneficial. Upon using the peak detection method, we did not manage to reach a better F1-score than ~40%, as opposed to the 57% obtained with the stem detection method. However, the peak detection method is particularly interesting because it can also delimit canopies. Hence, it may be worth trying to improve the F1-score, for instance by tuning the parameters of the power law equation relating the crown radius to the tree height (cf. here ).","title":"4.1 Further the DFT parameter space exploration"},{"location":"PROJ-TREEDET/#42-exploit-contextual-information","text":"We showed that the algorithms implemented by TerraScan and DFT yield much better results in sparse contexts (ex.: the \"Avenue de Bel-Air\" test sector) than in dense ones (ex.: the \"Parc Floraire\" test sector). This means that precision may be improved (at the expense of recall, though) if one could restrain the tree detection to sparse contexts only, either as a pre- or post-processing step. We can think of at least a couple of methods which would allow one to (semi-)automatically tell sparse from dense contexts: intrinsic method: after segmenting the point cloud into individual trees, one could analyze how close (far) each individual is to (from) the nearest neighbor and estimate the density of trees on some 2D or 3D grid; extrinsic method: territorial data exist (see for instance the dataset \"Carte de couverture du sol selon classification OTEMO\" distributed by the SITG ), providing information about urban planning and land use ( e.g . roads, parks, sidewalks, etc.). These data may be analyzed in order to extract hints on how likely it is for a tree to be in close proximity with another, according to its position.","title":"4.2 Exploit contextual information"},{"location":"PROJ-TREEDET/#43-combine-detections-stemming-from-two-or-more-independent-trials","text":"Detections coming from two or more independent trials (obtained with different software or else with the same software but different parameters) could be combined in order to improve either precision or recall: recall would be improved (i.e. the number of false negatives would be reduced) if detections coming from multiple trials were merged. In order to prevent double counting, two or more detections coming from two or more sources could be counted as just one if they were found within a given distance from each other. The algorithm would follow along similar lines as the ones which led us to the \"tagging and counting algorithm\" presented here above ; precision would be improved (i.e. the number of false positives would be reduced) if we considered only those detections for which a consensus could be established among two or more trials, and discarded the rest. A distance-based criterion could be used to establish such consensus, along similar lines as those leading to our \"tagging and counting algorithm\" .","title":"4.3 Combine detections stemming from two or more independent trials"},{"location":"PROJ-TREEDET/#44-use-generic-point-cloud-segmentation-algorithms","text":"Generic ( i.e. not tailored for tree detection) clustering algorithms exist, such as DBSCAN (\"Density-Based Spatial Clustering of Applications with Noise\", see e.g. here ), which could be used to segment a LiDAR point cloud into individual trees. We think it would be worth giving these algorithms a try!","title":"4.4 Use generic point cloud segmentation algorithms"},{"location":"PROJ-TREEDET/#45-use-machine-learning","text":"The segmentation algorithms we used in this project do not rely on Machine Learning. Yet, alternative/complementary approaches might me investigated, in which a point cloud segmentation model would be first trained on reference data, then used to infer tree segmentations within a given area of interest. For instance, it would be tempting to test this Deep Learning model published by ESRI and usable with their ArcGIS Pro software. It would be also worth deep diving into this research paper and try replicating the proposed methodology. Regarding training data, we could generate a ground truth dataset by using our best TerraScan/DFT model to segment the 3D point cloud; using 2D ground truth data to filter out wrong segmentations.","title":"4.5 Use Machine Learning"},{"location":"PROJ-TREEDET/#5-other-resources","text":"The work documented here was the object of a Forum SITG which took place online on March 29, 2022. Videos and presentation materials can be found here .","title":"5. Other resources"},{"location":"PROJ-TREEDET/#6-acknowledgements","text":"This project was made possible thanks to a tight collaboration between the STDL team and some experts of the Canton of Neuch\u00e2tel (NE), the Canton of Geneva (GE), the Conservatoire et Jardin botaniques de la Ville de Gen\u00e8ve (CJBG) and the University of Geneva (UNIGE). The STDL team acknowledges key contributions from Marc Riedo (SITN, NE), Bertrand Favre (OCAN, GE), Nicolas Wyler (CJBG) and Gregory Giuliani (UNIGE). We also wish to warmly thank Matthew Parkan for developing, maintaining and advising us on the Digital Forestry Toolbox .","title":"6. Acknowledgements"},{"location":"TASK-4RAS/","text":"TASK-4RAS - HR, NH \u00b6 Schedule : September 2020 to February 2021 (initially planned from August 2021 February 2022) This document describe the state of an ongoing task (DIFF) and is subject to daily revision and evolution Context \u00b6 The 4D platform developed at EPFL with the collaboration of Cadastre Suisse is able to ingest both large scale point-based and vector-based models. During the previous development, the possibility to have this different type of data in a single framework lead to interesting results, showing the interest to have the possibility to put this different type of data into perspectives. Illustrations of mixed models in the 4D platform : INTERLIS, Mesh and LIDAR - Data : SITN Taking into account point-based and vector-based model allows to almost cover all type of data that are traditionally considered for land registering. The only type of data that is currently missing is the two-dimensional rasters. Indeed, due to their nature, image are more complicated to put in perspective of other three-dimensional data. The goal of this task is then to address the management of the raster by the platform in order to be able to ingest, store and broadcast any type of data with the 4D platform. Specifications \u00b6 In order to address this task, a step-by-step approach is defined. In the first place, a set of data has to be gathered from the STDL partners : Gathering a dataset of geo-referenced ortho-photography of a chosen place of reasonable size The dataset has to provide ortho-photography for at least two different times The format of the dataset has to be analyzed in order to be able to extract the image pixels with their position (CH1903+) As the platform indexation formalism is not straightforward, the images are treated as point-based model, each pixel being one colored point of the model. This will allow to provide a way of starting to analyze and understand the indexation formalism while having first results on image integration : Transform images into simple point-based models (each pixel being one point) Injection of the point-based model in an experimental instance of the platform Understanding the indexation formalism for point-based models and, subsequently, its adaptation for the vector-based models As the indexation formalism is understood for point-based models, the following adaptation will be performed : removing the third dimension from the point-based indexation specifically for the image (flat indexation) At this point, a first reporting is required : Is there an advantage to add raster to such a platform in perspective of the other types of model (points, vectors, meshes) ? How the adaptation of the point-based indexation performs for images ? How taking advantage of color accumulation enrich the image integration ? What is the cost of rendering the image with the adaptation of the point-based indexation ? Based on the formulated answer, the following strategical choice has to be discussed : Would it be more efficient to integrate image keeping them as raster (deviation from the current indexation) ? Depending on the answer, a new set of specification will be decided (if this direction is favored). Depending on the remaining time and on the obtained results, the question of the time management in the platform will be addressed. Currently, the time is treated linearly in the platform and a multi-scale approach, as for the spatial dimensions, could be interesting. The specifications will be decided as the previous points will be fulfilled. Resources \u00b6 List of the resources initially linked to the task : liberatosthene - Platform and indexation back-end eratosthene-suite - Platform front-end Other resources will be provided according to requirements.","title":"**TASK-4RAS** - HR, NH"},{"location":"TASK-4RAS/#task-4ras-hr-nh","text":"Schedule : September 2020 to February 2021 (initially planned from August 2021 February 2022) This document describe the state of an ongoing task (DIFF) and is subject to daily revision and evolution","title":"TASK-4RAS - HR, NH"},{"location":"TASK-4RAS/#context","text":"The 4D platform developed at EPFL with the collaboration of Cadastre Suisse is able to ingest both large scale point-based and vector-based models. During the previous development, the possibility to have this different type of data in a single framework lead to interesting results, showing the interest to have the possibility to put this different type of data into perspectives. Illustrations of mixed models in the 4D platform : INTERLIS, Mesh and LIDAR - Data : SITN Taking into account point-based and vector-based model allows to almost cover all type of data that are traditionally considered for land registering. The only type of data that is currently missing is the two-dimensional rasters. Indeed, due to their nature, image are more complicated to put in perspective of other three-dimensional data. The goal of this task is then to address the management of the raster by the platform in order to be able to ingest, store and broadcast any type of data with the 4D platform.","title":"Context"},{"location":"TASK-4RAS/#specifications","text":"In order to address this task, a step-by-step approach is defined. In the first place, a set of data has to be gathered from the STDL partners : Gathering a dataset of geo-referenced ortho-photography of a chosen place of reasonable size The dataset has to provide ortho-photography for at least two different times The format of the dataset has to be analyzed in order to be able to extract the image pixels with their position (CH1903+) As the platform indexation formalism is not straightforward, the images are treated as point-based model, each pixel being one colored point of the model. This will allow to provide a way of starting to analyze and understand the indexation formalism while having first results on image integration : Transform images into simple point-based models (each pixel being one point) Injection of the point-based model in an experimental instance of the platform Understanding the indexation formalism for point-based models and, subsequently, its adaptation for the vector-based models As the indexation formalism is understood for point-based models, the following adaptation will be performed : removing the third dimension from the point-based indexation specifically for the image (flat indexation) At this point, a first reporting is required : Is there an advantage to add raster to such a platform in perspective of the other types of model (points, vectors, meshes) ? How the adaptation of the point-based indexation performs for images ? How taking advantage of color accumulation enrich the image integration ? What is the cost of rendering the image with the adaptation of the point-based indexation ? Based on the formulated answer, the following strategical choice has to be discussed : Would it be more efficient to integrate image keeping them as raster (deviation from the current indexation) ? Depending on the answer, a new set of specification will be decided (if this direction is favored). Depending on the remaining time and on the obtained results, the question of the time management in the platform will be addressed. Currently, the time is treated linearly in the platform and a multi-scale approach, as for the spatial dimensions, could be interesting. The specifications will be decided as the previous points will be fulfilled.","title":"Specifications"},{"location":"TASK-4RAS/#resources","text":"List of the resources initially linked to the task : liberatosthene - Platform and indexation back-end eratosthene-suite - Platform front-end Other resources will be provided according to requirements.","title":"Resources"},{"location":"TASK-DIFF/","text":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT \u00b6 Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF September 2020 to November 2020 - Published on December 7, 2020 Abstract : Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds. Task Context : Difference Detection \u00b6 As the implemented indexation formalism is based on equivalences classes defined on space and time, a natural discretization along all the four dimensions is obtained. In the field of difference detection, it allowed implementing simple logical operators on the four-dimensional space. The OR , AND and XOR operators were then implemented allowing the platform to compute, in real time , convolutions to compare models with each others across the time. The implementation of these operators was simple due to the natural spatio-temporal discretization obtained from the indexation formalism. Nevertheless, two major drawbacks appeared : the first one is that such operators only works for point-based models. Having the opportunity to compute and render differences and similarities between any type of data is not possible with such formal operators. The second drawback comes from the nature of the point-based capturing devices. Indeed, taking the example of a building, even without any change to its structure, two digitization campaigns can lead to disparities only due to measures sampling. The XOR operator is the natural choice to detect and render differences, but this operator is very sensitive to sampling disparities. Computing the XOR convolution between two point-based models leads the rendering to be dominated by sampling variations rather than the desired structural differences. This drawback was partially solved by considering the AND operator. Indeed, the AND operator allows to only shows constant structural elements from two different positions in time and is insensitive to sampling disparities. As shown on the following images, the AND operator shows differences as black spots (missing parts) : AND convolution between two LIDAR models : Geneva 2005 and 2009 - Data : SITG As one can see, AND convolutions allow detecting, through the black spots, large area of structural changes between the two times and also, with more care, allow guessing smaller differences. Nevertheless, reading and interpreting such representation remains complex for users. The goal of this task is then to tackle these two drawbacks, allowing the platform to detect changes not only for point-based models but also for vector-based models and to implement a variation of the XOR operator for point-based models allowing to efficiently highlight the structural evolution. The task consists then in the implementation, testing and validation of a difference detection algorithm suitable for any type of model and to conduct a formal analysis on the best rendering techniques. Methodology \u00b6 A step by step methodology is defined to address the problem of difference detection in the platform. In a first phase, the algorithm will be developed and validated on vector-based models as follows : Obtaining a large scale vector-based model on which synthetic variation are introduced Development of the algorithm using the synthetic variations model Testing and validation of the algorithm (using the known synthetic variations) First conclusion In a second phase, true land register data will be used to formally detect real evolutions of the territory : Obtaining true land register vector-based models (INTERLIS) at different times Analysis of the difference detection algorithm on true land register vector-based models Second conclusion In a third phase, the algorithm will be validated and adapted to work on point-based models : Obtaining true land register point-based models (LAS) at different position in time Verifying the performances of the vector-based detection algorithm on point-based data Adaptation of the algorithm for point-based models Analysis of the difference detection algorithm on true land register point-based models Comparison of the detected differences on point-based models and on their corresponding land register vector-based models (INTERLIS) Third conclusion In addition, the development of difference detection algorithm has to be conducted keeping in mind the possible future evolutions of the platform such as addition of layers (separation of data), implementation of a multi-scale approach of the time dimension and addition of raster data in the platform. First Phase : Synthetic Variations \u00b6 In order to implements the vector-based difference detection algorithm, sets of data are considered as base on which synthetic differences are applied to simulate the evolution of the territory. This approach allows focusing on well controlled data to formally benchmark the results of the implemented algorithm. Experiments are conducted using these data to formally evaluate the performance of the developed algorithm. Selected Resources and Models \u00b6 Vector Models : Line-based \u00b6 In this first phase, line-based data are gathered from openstreetmap in order to create simple models used during the implementation and validation of the detection algorithm. A first set of vector-based models are considered made only of lines. Three sets are created each with a different scale, from city to the whole Switzerland. The line-based sets of data are extracted from openstreetmap shapefiles and the elevations are restored using the SRTM geotiff data. The EGM96-5 geoid model is then used to convert the elevation from MSL to ellipsoid heights. The following images give an illustration of these sets of data : Line-based data-sets : Switzerland - Data : OSM The following table gives a summary of the models sizes and primitives count : Model Size (UV3) Primitive Count Frauenfeld 5.0 Mio 93.3 K-Lines Neuch\u00e2tel 33.1 Mio 620.2 K-Lines Switzerland 1.3 Gio 25.0 M-Lines In order to simulate evolution of the territory in time, synthetic variations are added to these models. A script is developed and used to insert controlled variations on selected primitives. The script works by randomly selecting a user-defined amount of primitives of a model and by adding a variation on one of its vertex position using a user-specified amplitude. The variation is applied on the three dimensions of space. Vector Models : Triangle-based \u00b6 A second set of triangle-based models is also considered for implementing and validating the difference detection algorithm. The selected model is a mesh model of the Swiss buildings provided by swisstopo . It comes aligned in the CH1903+ frame with elevations. It is simply converted into the WGS84 frame using again the EGM96-5 geoid model : Triangle-based data-sets : Switzerland - Data : swisstopo The following table gives a summary of the models sizes and primitives count : Model Size (UV3) Primitive Count Frauenfeld 116.9 Mio 1.4 M-Triangles Neuch\u00e2tel 842.2 Mio 10.5 M-Triangles Switzerland 30.5 Gio 390.6 M-Triangles These models are very interesting for difference detection as the ratio between primitive size and model amplitude is very low. It means that all the primitives are small according to the model coverage, especially for the Switzerland one. The developed script for line-based models is also used here to add synthetic variations to the models primitives in order to simulate an evolution of the territory. Models : Statistical Analysis \u00b6 Before using the models in the following developments, a statistical analysis is performed on the two Switzerland models, line and triangle-based. Each primitive of these two models are considered and their edges size are computed to deduce their distribution : Statistical analysis : Models primitive edge size distribution, in meters, for the Switzerland models : line-based (left) and triangle-based (right) One can see that the line-based model comes with a much more broad distribution of the primitives size . Most of the model is made from lines between zero and twenty meters. In the case of the triangle-based models, the primitives are much smaller. As most of them are less than ten meters, a significant fraction of primitives is below one meter. Implementation of the Algorithm \u00b6 In order to compare two models at two different positions in time to detect differences, the solution is of course to search for each primitive of the primary time if it has a corresponding one in the secondary time. In such case, the primitives can be concluded as static in time and only the primitives that have no correspondence will be highlighted as differences. A first approach was initially tested : a vertex-based comparison. As every primitive (points, lines and triangles) is supported by vertexes, it can be seen as a common denominator on which comparison can take place. Unfortunately, it is not a relevant approach as it leads to an asymmetric detection algorithm. To illustrate the issue, the following image shows the situation of a group of line-based primitives at two different times with an evolution on one of the primitive vertex : Asymmetric approach : The variation is detected only when comparing backward in time When the comparison occurs between the second time and the first one, the modified vertex correspondence is not found, and the vertex can be highlighted as a difference. The asymmetry appears as the first time is compared to the second one. In this case, despite the primitive vertex changed, the vertex-based approach is able to find another vertex, part of another primitive, and interprets it as a vertex identity, leading the modified primitive to be considered as static. In order to obtain a fully symmetric algorithm, that does not depend on the way models are compared in times, a primitive-attached approach is considered. The implemented algorithm then treats the correspondence problem from the whole primitive point of view, by checking that the whole primitive can be found in the other model to which it is compared to. This allows to highlight any primitive showing a modification, regardless of the way models are compared and the nature of the modification. In addition to highlighting the primitives that changed through time, the implemented algorithm also renders the primitives that have not changed. The primitives are then shown by modulating their color to emphasize the modifications by keeping their original color for the modified one, while the static primitives are shown in dark gray. This allows to not only show the modifications but also to keep the context of the modifications, helping the user to fully understand the nature of the territory evolution. In addition to color modulation, a variation of difference rendering is analyzed. In addition to color modulation, a visual and artificial marker is added to ease their search. The visual marker is a simple line emanating from the primitive and goes straight up with a size of 512 meters. Such markers are introduced to ease the detection of small primitives that can be difficult to spot according to large point of views. Additional developments were required for triangle-based models : indeed, such models need to be subjected to a light source during rendering for the user to understand the model (face shading). The previously implemented lighting model is then modified to take into account color modulation in order to correctly render the triangle that are highlighted. Moreover, the lighting model was modified to light both face of the triangles in order to light them regardless of the point of view. In addition, as mesh models are made of triangles, primitives can hide themselves. It can then be difficult for the user to spot the highlighted primitives as they can be hidden by others. An option was added to the rendering client allowing the user to ask the rendering of triangles as line-loops or points in order to make them transparent. Finally, an option allowing the user to enable or disable the render face culling was added for him to be able to see the primitive from backward. Results and Experiments \u00b6 With the implemented algorithm, a series of experiments are conducted in order to validate its results and to analyze the efficiency of the difference detection and rendering from a user point of view. In addition, experiments are also conducted to quantify the efficiency of the difference detection for automated processes. Difference Detection : Overview \u00b6 Considering the selected data-sets, each original model is injected at a given time and synthetic variations are added to a copy of it to create a second model injected at another time. The synthetic variations are randomly added to a small amount of primitives of the original model and are of the order of one meter. On the following examples, the detection is operated considering the original model as primary and the modified one as secondary. The following images show examples of how the detection algorithm allows to highlight the detected differences while keeping the rest of the model using a darker color in case of line-based models : Example of difference detection on line-based Frauenfeld (left) and Neuch\u00e2tel (right) models - Data : OSM One can see how the modified primitives are highlighted while keeping the context of the modifications. The highlighted primitive is the one belonging to the primary time. Comparing the models in the other way around would lead the secondary model primitives to be highlighted. Considering the Frauenfeld example, the following images show the situation in the primary time (original model) and the secondary time (model with synthetic variations) : Primary model (left) and secondary one (right) showing the formal situations - The modified primitive is circled in read - Data : OSM As a result, the user can choose between the differences highlighting with the choice of model as primary and can also switch back and worth between the models themselves though the platform interface. Of course, the readability of the difference detection models depends on the size of the modified primitive and the scale at which the model is looked at by the user. If the user adopts a large scale point of view, the differences, even highlighted, can become difficult to spot. This issue can be worsened as triangle-based models are considered. In addition to primitive size, triangles also bring occlusions. The visual markers added to the highlighted primitives can considerably improve ease of differences search by the user. The following images give an example of difference detection without and with the visual markers added by the algorithm : Example of highlighted primitives without (left) and with (right) visual markers - Data : OSM Considering the triangle-based models, difference detection is made more complicated by at least three aspects : the first one is that 3D vector models are more complex than 2D ones in the way primitives (triangles) are more densely packed in the same regions of space in order to correctly model the buildings. The second one is that triangles are solid primitives that bring occlusions in the rendering, hiding other primitives. The last aspect is that such a model can contain very small primitives in order to model the details of the buildings. In such a case, the primitives can be difficult to see, even when highlighted. The following images show an example of highlighted triangles on the Frauenfeld model : Example of highlighted primitive on the Frauenfeld building model - Data : swisstopo On the right image above, the highlighted triangle is underneath the roof of the house, forcing the user to adopt an unconventional point of view (from above the house) to see it. In addition, some primitives can be defined fully inside a volume close by triangles, making them impossible to see without going inside the volume or playing with triangle rendering mode. In such a context, the usage of the visual markers become very important for such models coming with large amount of occlusion and small primitives : Example of highlighted primitives without (left) and with (right) visual markers - Data : swisstopo In case of triangle-based models, the usage of markers appears to be mandatory in order for the user to be able to locate the position of the detected differences in a reasonable amount of time. Difference Detection : User-Based Experiments \u00b6 In any case, for both line and triangle-based models, the difference detection algorithm is only able to highlight visible primitives. Depending on the point of view of the user, part of the primitives are not provided by the platform because of their small size. Indeed, the whole point of the platform is to allow the user to browse through arbitrary large models, which implies to provided only the relevant primitives according to its point of view. As a result, the detection algorithm will not be able to highlight the variations as the involved primitives are not considered as a query answer by the platform. The user has then to reduce is point of view in order to zoom on the small primitives to make them appear, and so, allowing the algorithm to highlight them. In order to show this limitation, an experiment is performed. For each model, a copy is made on which eight synthetic differences are randomly introduced. The variations are of the order of one meter. The models and their modulated copy are injected in the platform. The rule is the following : the user uses the detection algorithm on each model and its modulated copy and has five minutes to detect the eight differences. Each time a difference is seen by the user, the detection time is kept. The user is allowed to use the platform in the way he wants. In each case, the experiment is repeated five times to get a mean detection rate. As one could ask, these measures are made by the user and are difficult to understand without a reference. In order to provide such reference, the following additional experiment is conducted : each model and its modulated copy are submitted to a naive automated detection process. This process parses each primitive of the original model to search in its modulated copy if the primitive appear. If the primitive is not found, the process trigger a difference detection. This process is called naive as it simply implements two nested loops, which is the simplest searching algorithm implementation. The process is written in C with full code optimization and executed by a single thread. Starting with the line-based models, the following figures shows the difference detection rates according to time. For each of the three models, the left plots show the rate without visual markers, the middle ones with visual markers and the right ones the naive process detection rate : Frauenfeld : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Canton of Neuch\u00e2tel : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Switzerland : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process As expected, the larger the model is, the more difficult it is for the user to find the highlighted differences, with or without visual markers. Considering a city, the differences, even of the order of one meter, are easy to spot quickly. As the model gets larger, the more time it takes for the user to find the differences. On a model covering a whole canton (Neuch\u00e2tel), one can see that most of the differences are detected in a reasonable amount of time despite their small size according to the overall model. On the Swiss model, things get more complicated, as simply looking at each part of the country is already complicated in only five minutes, leading the detection rate to be lower, even using the visual markers. These results are consistent with the statistical analysis made on the line-based Switzerland model. Detection on a city or even a whole canton lead the user to adopt a point of view sufficiently close to make most of the primitives appearing. For the Switzerland model, the user is forced to adopt a larger point of view, leading to a significant proportion of primitives to stay hidden. These results also show that adding visual markers to the highlighted primitives increases the user detection rate, meaning that the markers lead to a more suitable rendering from the user experience point of view. Considering the user results and the naive detection process, one can see that the user obtains at least similar results but most of the time outperforms the automated process. This allows to demonstrate how the implementation and data broadcasting strategy of the platform is able to provide an efficient way to access models and composite models, here in the context of difference detection. The following figures show the experiments results for the triangle-based models, which were not performed on the whole Switzerland model due to limited rendering capabilities : Frauenfeld : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Canton of Neuch\u00e2tel : The black curve shows the mean detection rate while the blue (left, middle) and red (right) area gives the worst and best rates Left : without visual markers - Middle : with visual markers - Right : automated process Similar conclusions apply for the triangle-based models : the larger the model is, the more difficult the difference detection is. These results also confirm that adding visual markers in addition to primitives highlighting significantly helps the user, particularly in case of triangle-based models. The obtained results on triangle-based models are lower than for line-based models. A first explanation is the greater amount of primitive that lead the user to spend more time at each successive point of view. The occlusion problem also seems to play a role, but to a lesser extent as the visual markers seems to largely solve it. The differences between detection on line and triangle-based models have to be searched in the statistical analysis of the triangle-based models. Indeed, for these models, a large proportion of the primitives are very small (less than a meter), leading them to be rendered only as the user adopts a close point of view, making the detection much more complicated in such a small amount of time. The triangle-based models being larger than the line-based one, the results of the naive process are very poor. As for the line-based models experiments, the user outperforms this automated process, in a much more significant way. Difference Detection : Process-Based Experiments \u00b6 In the previous experiments, the user ability to find the differences on the data-sets, using synthetic variations, was benchmark in perspective of the results provided by a naive automated process. The user performs quite well using the platform, but start to struggle as the data-sets get bigger according to the sizes of their primitives. In this second set of experiments, the platform is used through an automated process instead of a user. The process has the same task as the user, that is, finding the eight synthetic differences introduced in the models copy. The process starts with a list of index (the discretization cells of the platform) in order to query the corresponding data to the platform before to search for differences in each cell. The process implements, then, a systematic difference detection covering the whole model. In order for the process to work, it requires an input index list. To create it, the primitive injection condition of the platform is used to determine the maximal depth of these index. The following formula gives the poly-vertex (lines and triangles) primitives injection condition according to the platform scale. In other words, the formula gives the shallowest scale at which the primitive is considered through queries according to its size : where s gives the shallowest scale, R being the WGS84 major semi-axis and e is the largest distance, in meters, between the primitive first vertex and its other ones. For example, choosing s = 26 allows the index to reach any primitive that is greater than ~30 cm over the whole model covered by the index. The scale 26 is then chosen as the deepest search scale in the following experiments. This value can be adapted according to the primitives size and to the nature of the detection process. The larger it is, the more data are broadcast by the platform increasing the processing time. In order to compare the user-based experiments, the naive automated approach and this process-based exhaustive search, the same protocol is considered. The process addresses queries to the platform, based on the index list, and save the detection time of each difference. The detection rate is plot in the same way as for the previous experiments. Again, eight synthetic differences are randomly introduced and the experiment is repeated five times for the line-based model and only two times for the triangle-based model. As the scale 26 is chosen as the deepest search scale, the index list can be built in different ways. Indeed, as a query is made of one spatial index, that points at the desired cell, and an additional depth ( span ), to specify the density of data, the only constraint to maintain the deepest search scale at 26 is the following : where the two left hand side terms are the spatial index size and span value. In these experiments, a first list of index is built using a span of 9 and a second with a span of 10 . As the deepest scale is maintained constant, increasing the span reduces the index list size, but the queried cells contain more data to analyze. The following figures show the mean detection rate for the Switzerland lined-based model with the deepest scale at 26 and span at 9 and 10 . The plots are scaled in the same way as for the user-based experiments : Switzerland : The black curve shows the mean detection rate while the blue area gives the worst and best rates - Span at 9 (left) and 10 (right) One can see that the detection rate on such a model is much better than the user-based or naive approach ones. In a manner of five minutes, for the span set to 10 , the eight differences can be detected and reported. The full detection process took ~5 minutes with span set to 10 and ~8 minutes with the span set to 9 . This shows how the platform can be used by automated processes as an efficient data provider. In addition, as the data are queried by the automated process, the detected primitive geometry is directly available, allowing all sorts of subsequent processes to take place. As the deepest scale was set to 26 , in one of the five measures session, one of the eight differences was not detected (at all). It means that the primitive on which a synthetic variation was introduced is smaller than 30cm and was then not reached by any index. This shows the importance of defining the spatial index and spans according to the processes needs. For example, increasing the deepest scale to 27 would allow reaching primitive down to ~15 cm over the whole Switzerland, and so on. The following figures show the mean detection rate for the Switzerland triangle-based model. In this case, only two measure sessions were made to limit the time spent on this analysis : Switzerland : The black curve shows the mean detection rate while the blue area gives the worst and best rates - Span at 9 (left) and 10 (right) The conclusion remain, but the rate is slower in this case as the model contains much more primitives than the line-based one. In this case, the full detection process took ~15 minutes with span set to 10 and ~20 minutes with the span set to 9 . Again, in one of the two measure session, one difference was not detected due to the size of the primitive. Nevertheless, these results shows how the platform, seen as a process data provider, allows outperforming user-based and classic detection algorithms. Such process-based strategy can be performed in many ways depending on the needs. For example, the index list can be limited to a specific area or set to focus on spread and defined locations (for example at the intersection of the Swiss hectometric grid). The following image gives a simple example of how the detected differences can be leveraged. As the geometry of the differences is known by the process, a summary of the differences can be provided through a simple map : Example of a differences map based on the results of the detection process - Data : SRTM The eight synthetic differences are easily presented allowing a user to analyze them more in detail in the platform interface for example. This map was created detecting the eight differences on the line-based Switzerland model in about 5 minutes with a span set to 10 . Conclusion : First Phase \u00b6 During this first phase, the difference detection algorithm was developed and validated on both line-based and triangle-based data. An efficient algorithm is then implemented in the platform allowing emphasizing differences between models at different temporal positions. The algorithm is able to perform the detection on the fly with good performances allowing the users to dynamically browse the data to detect and analyze the territory evolutions. The performances of the detection algorithm allow the platform to be suitable for automated detection processes, as a data provider, answering large amounts of queries in an efficient and remote manner. Two variations of the difference detection algorithm are implemented. The first version consists in highlighting the primitives that are subject to modifications over a time. This variation is suitable for automated processes that can rely on simple search methods to list the differences. For the users, this first variation can lead to more difficult visual detection of the differences, especially in case the highlighted primitives are small or hidden by others. For this reason, visual markers were added on top of the highlighted primitives in order to be seen from far away, regardless of the primitives size. The measures sessions made during the user-based experiments showed a clear improvement of the detection rate when using the visual markers. This was especially true for triangle-based models, where the primitives bring occlusions. The user-based experiments showed that using the platform interface, a human can significantly outperform the result of a naive automated process operating on the models themselves. The experiments showed that the user is able to efficiently search and find through space and time the evolutions of the territory appearing in the data. Of course, as the model size and complexity increases, the user-driven interface starts to show its limits. In such a case, the process-based experiments showed that automated processes can take over these more complicated searches through methods allowing performing exhaustive detection over wide models in a matter of several minutes. At this point, the developments and validations of the algorithm, and its variations, were conducted on synthetic modifications introduced in models using controlled procedures. The next phase focuses on formal data extracted from land registers. Second Phase : True Variations \u00b6 In this second phase, also dedicated to vector-based models, the focus is set on applying the developed difference detection algorithm on true land register models. Two sets of data are considered in order to address short-term and long-term difference detection. Selected Resources and Models \u00b6 In both cases, short-term and long-term, INTERLIS data are considered. A selection of tables in different topics is performed to extract the most interesting geometries of the land registering. For all models, the following colors are used to distinguish the extracted layers : INTERLIS selected topics and tables colors - Official French and German designations The layers are chosen according to their geometric content. The color assignation is arbitrary and does not correspond to any official colorization standard. Short-Term Difference Detection : Thurgau \u00b6 For the short-term application of the difference detection algorithm, the case of the Thurgau canton is considered. Two set of INTERLIS data are considered that are very close in time, of the order of days. The selected layers are extracted from the source files before to be converted to the WGS84 frame using the EGM95-6 geoid model. The heights are restored using the SRTM topographic model. The following images give an illustration of the considered data : Canton of Thurgau (left) and close view of Frauenfeld (right) - Data : Kanton Thurgau Two INTERLIS models are considered with times 2020-10-13 and 2020-10-17, corresponding to the models gathering time. The following table gives the models size and primitives count : Model Size (UV3) Primitive Count Thurgau 2020-10-13 203.7 Mio 3.8 M-Lines Thurgau 2020-10-17 203.8 Mio 3.8 M-Lines As the two models are very close in time, they are very similar in size and content as the corrections count made during the considered time range is small. Long-Term Difference Detection : Geneva \u00b6 For the long-term difference detection analysis, the Geneva case is selected as the canton of Geneva keeps a copy of each land register model for each month from at least 2009 . This allows to compare INTERLIS models that are further away from each other from a temporal point of view. The selected layers are extracted and converted to the WGS84 coordinates system using the EGM96-6 geoid model. Again, the SRTM model is used to restore the heights. The following images give an illustration of the selected models : Canton of Geneva in 2019-04 (left) and close view of Geneva in 2013-04 (right) - Data : SITG The selected models are not chosen randomly along the time dimension. Models that corresponds to the Geneva LIDAR campaigns are selected as they are used in the next phase. In addition, as the LIDAR campaigns are well spread along the time dimension, the selected models are far away from each other in time, of the order of at least two years. The following table summarize the models size and primitives count : Model Size (UV3) Primitive Count Geneva 2009-10 (MN03) 550.2 Mio 10.3 M-Lines Geneva 2013-04 407.0 Mio 7.6 M-Lines Geneva 2017-04 599.6 Mio 11.2 M-Lines Geneva 2019-04 532.6 Mio 9.9 M-Lines As the temporal gaps between the models are much larger than for the Thurgau models, the size and primitive count show larger variations across the time, indicating that numerous differences should be detected on these data. Models : Statistical Analysis \u00b6 As in the first phase, a statistical analysis of the Thurgau and Geneva models is conducted. The following figures show the line length distribution of the two Thurgau models : Statistical analysis : Primitive size distribution, in meters, for the Thurgau 2020-10-13 (left) and 2020-10-17 (right) As expected, as the models are very similar, the distribution between both models is almost identical. In both cases, the distribution is centered around two meters and is mostly contained within the [0,5] range. The following figures show the same statistical analysis for the Geneva models, more spread along the time dimension : Statistical analysis : Primitive size distribution, in meters, for the Geneva 2009-10 (top-left), 2013-04 (top-right), 2017-04 (bottom-left) and 2019-04 (bottom-right) One can see that the distribution varies more from a time to another. In addition, in comparison with the Thurgau models, the Geneva models tend to have smaller primitive, mostly distributed in the [0,1] range with a narrower distribution. Results and Analysis \u00b6 Short-Term : Thurgau \u00b6 In the case of Thurgau data, the models are only separated in time by a few days. It follows that only a small amount of differences is expected. As an introduction, the following images show the overall situation of the difference detection between the two models. The differences are highlighted by keeping the primitive original color while identities are shown in dark gray to allow context conservation : Overall view of difference detection : Thurgau (right) and Amriswil (left) As expected, as the two models are very close in time, only a limited amount of differences is detected. Such situation allows to have a clear view and understanding of each difference. In order to analyze the results of the difference detection algorithm on real cases , selected differences, using the algorithm itself, are studied more in detail to emphasize the ability of the algorithm to detect and make the difference understandable for the user. As a first example, the case of the Bielackerstrasse in Amriswil is considered and illustrated by the following images : Example of difference detection : Bielackerstrasse in Amriswil - 2020-10-17 (right) and 2020-10-13 (left) as primary time In this case, new buildings are added to the official land register. As the 2020-10-17 is selected as primary, the highlighted elements correspond the footprint of the added buildings. When the 2020-10-13 time is set as primary, as it does not contain the building footprints, the highlighted elements only corresponds to the re-measured elements for land register correction. This illustrates the asymmetry of the difference detection algorithm that only highlight primitives of the primary time. In addition, by keeping the color of the highlighted primitives, the difference detection algorithm allows to immediately see that three layers of the land register have been affected by the modification (German : Einzelobjekte, Flaechenelement Geometrie; Bodenbedeckung, BoFlaeche Geometrie; Einzelobjekte, Linienelement). The following images show the respective situation of the 2020-10-13 and 2020-10_17 models : Situation of Bielackerstrasse in Amriswil - 2020-10-17 (right) and 2020-10-13 (left) This confirms the analysis deduced from the difference detection algorithm that a group of new buildings are added to the land register. In this example, if the inner road was not re-measured, at least on some portion, the difference detection with 2020-10-13 as primary time would have shown noting. To illustrate the asymmetry of the algorithm more clearly, the example of Mammern is considered. On the following image, the result of the difference detection is illustrated with both time chosen successively as primary : Example of difference detection : Mammern - 2020-10-17 (right) and 2020-10-13 (left) as primary time On this specific example, one can see that choosing the 2020-10-17 time as primary, which is the most recent time, nothing is highlighted by the detection algorithm. But when the 2020-10-13 time is set as primary, a specific element appears as highlighted, showing an evolution of the land register. This example illustrates the deletion of a sequence of primitive of the property (German : Liegenschaften, ProjLiegenschaft Geometrie) layer of the land register, which then only appear as the oldest time is set as primary. The following images show both time situation : Situation of Mammern - 2020-10-17 (right) and 2020-10-13 (left) This example shows the opposite situation of the previous one, where elements were deleted from the land register instead of added. As a last example, an in-between situation is selected. The case of the Trungerstrasse in M\u00fcnchwilen is considered and illustrated by the following images showing both time as primary : Example of difference detection : Trungerstrasse in M\u00fcnchwilen - 2020-10-17 (right) and 2020-10-13 (left) as primary time This situation is in-between the two previous one as nothing really appeared and nothing really disappeared from the land register. A modification was made on the situation of this specific property and so, appear no matter which of the two times is selected as primary. The following images show the formal situation of the land register for the two times : Situation of Trungerstrasse in M\u00fcnchwilen - 2020-10-17 (right) and 2020-10-13 (left) One can see that the correction made are around the pointed house, as the access road of the rear delimitation. For this type of situation, the algorithm recover some kind of symmetry, as the selected time as primary does is not relevant to detect the difference. To conclude this short-term difference detection analysis, the efficiency of visual markers is illustrated on the region of Romanshorn and Amriswil on the following images. Both images show the difference detection rendering without and with the visual markers : Illustration of difference detection without (right) and with (left) visual markers - 2020-10-17 as primary time for both images One can see that, for small highlighted primitive, the usage of visual markers eases the differences view for the user. Of course, as the highlighted primitive are big enough, or if the point of view is very close to the model, the efficiency of the visual markers decreases. Long-Term : Geneva \u00b6 Considering the Geneva land register, the compared model are much more spread along the time dimension, leading to a much richer difference model. Starting with the 2019-04 and 2017-04 models, the following images gives an overview of the detected differences on the whole canton : Overall view of difference detection between Geneva 2019-04 and 2017-04 models with 2019-04 as primary On this example, one can see that a much larger amount of differences is detected as the model are separated by two years. As the first observation, one can see that large portions of the model seems to have entirely moved between the two dates. Three of these zones are clearly visible on the images above as all their content is highlighted by the difference detection algorithm : the superior half of the Geneva commune , the Carouge commune and the left half of the Plan-les-Ouates commune , but more can be seen, looking more closely. These zones have been subjected to correction during the time interval separating the two models. These corrections mainly comes from the FINELTRA [1] adjustment used to ensure conversion between the old Swiss coordinates system MN03 and the MN95 current standard. As these corrections operate on each coordinate, the whole area is then modified of the order of a few centimeters. In these condition, the whole area is then highlighted by the difference detection algorithm as illustrated by the following image on the Carouge commune : Closer view of the Carouge 2019-04 and 2017-04 differences with 2019-04 as primary On this closer view, one can see that almost all the primitive of this specific commune have been corrected. Some exceptions remain. It is the case of the train tracks for example, that appear as static between the two models. Looking more closely, one can also observe that some primitive were not affected by the correction. Looking at the areas that have not been corrected through the FINELTRA triangular model, one can see that a lot of modification appear. For example, the following two images gives the differences of the Geneva historical part and the Verbois dam : Closer view of the Historical city (left) and Verbois dam (right) 2019-04 and 2017-04 differences with 2019-04 as primary One can see that, despite very few elements truly changed, a lot of primitives are highlighted as differences. This can be explained by a constant work of correction based on in-situ measurement. Some other factors can also explain these large amount of differences such as scripts used to correct the data to bring them in the expected Swiss standards. In such context, detected real changes of the territory is made much more complicated, as large amounts of detected differences are due to corrections of the model itself, without underlying true modification on the territory. Nevertheless, differences that corresponds to a true territory modification can be found. The following images show an example on the Chemin du Signal in Bernex : Differences on Chemin du Signal in Bernex with 2019-04 (left) and 2017-04 (right) as primary These differences can be detected by the user on the difference model as they appear more clearly due to an accumulation of highlighted primitives. Indeed, in case of simple correction, the highlighted primitive appear more isolated. The following images give the formal situation for the two times : Situation of Chemin du Signal in Bernex in 2019-04 (left) and 2017-04 (right) On this example, one can see that, with both time as primary, the territory evolution can be seen by the user as the highlighted primitives are more consistent. Nevertheless, territory changes are more difficult to list in such a case than in the previous short-term analysis. The following images give two example of visible territory changes in the difference model : La Gradelle (left) and Puplinge (right) 2019-04 and 2017-04 differences with 2019-04 as primary On the previous left image, a clear block of buildings can be seen as more highlighted than the rest of the difference model and correspond to new building. On the right of this block, a smaller one can also be seen that also corresponds to new buildings. On the right images, a clear block of new buildings is also visible, as more highlighted. In such a case, the user has more effort to perform in order to detect the differences that correspond to true changes in the territory, the differences model showing the land register modification in the first place rather than of the proper territory evolution. Considering the 2013-04 model, similar observations apply with stronger effect due to the larger temporal gap. The difference models are dominated by correction made to the model rather than proper territory changes. Comparing the 2017-04 and 2013-04 lead to even more difficult detection of these true modification, as the correction are widely dominating the difference models. The case of the 2009-10 model is made even worse by its coordinates system, as it is expressed in the old MN03 coordinates system. This model is made very difficult to compare with the three others, expressed in the MN95 frame, as all its primitives are highlighted in difference models due to the conversion performed between the MN03 and MN95 frames. Comparing the 2009-10 model with the 2013-04 lead to no primitive detected as identity, leaving only differences. Conclusion : Second Phase \u00b6 Two cases have been addressed in this phase showing each specific interesting application of the difference detection applied on land register data through the INTERLIS format. Indeed, short and long term differences emphasize two different points of view according to the analysis of the land register and its evolution in time. In the first place, the short term application clearly showed how difference detection and their representation opens a new point of view on the evolution of the land register as it allows focusing on clear and well identified modifications. As the compared models are close in time, one is able to produced differences models allowing to clearly see, modification by modification, what happened between the two compare situations, allowing focusing on each evolution to fully understand the modification. It follows that this short-term difference detection can provide a useful approach for the user of the land register that are more interested in the evolution of the model rather than in the model itself. The difference models can provide users a clear a simple view on what to search and to analyze to understand the evolution of such complex models. In some way, the differences on land register models can be seen as an additional layer proposed to the user to allow him to reach information that are not easy to extract from the models themselves. The case of Geneva , illustrating the long-term difference detection case, showed another interesting point of view. In the first place, one has to understand that land register models are complex and living models, not only affected by the transcription of the real-world situation across the time. Indeed, on the Geneva models, a large amount of differences is detected even on a relative short period of time (two years). In addition to the regular updates, following the territory evolution, a large amount of corrections is made to keep the model in the correct reference frame. The Swiss federal system can also add complexity, as all Cantons have to align themselves on a common set of expectations. In such a case, the difference detection turned out to be an interesting tool to understand and follows the corrections made to the model in addition to the regular updates. On the Geneva case, we illustrated that, by detecting it in the difference model, the correction on the coordinates frame on large pieces of the territory. This shows how the difference detection can be seen as a service that can help to keep track of the life of the model by detecting and checking these type of modifications. As a result, difference detection can be a tool for the user of the land register but can also be a tool for the land register authorities themselves. The difference models can be used to check and audit the evolution of the models, helping the required follow-up on the applied correction and updates. Third Phase : Point-Based Models \u00b6 In this third and last phase, the developed algorithm for difference detection on vector models is tested on point-based ones. As mentioned in the introduction, the platform was already implementing logical operators allowing comparing point-based models across time. As illustrated in the introduction, only the AND operator allowed emphasizing differences, but rendering them as missing part of the composite models. It was then difficult for the user to determine and analyze those differences. The goal of this last phase is to determine in which extend the developed algorithm is able to improve the initial results of point-based logical operators and how it can be adapted to provide better detection of differences. Selected Resources and Models \u00b6 Point-Based Models : LIDAR \u00b6 Smaller data-sets are considered as point-based models are usually much larger. The city of Geneva is chosen as an example. Four identical chunks of LIDAR data are considered covering the railway station and its surroundings. The four models correspond to the digitization campaigns of 2005, 2009, 2013 and 2017. The data are converted from LAS to UV3 and brought to WGS84 using the EGM96-5 geoid model. The following images give an overview of the selected models : Point-based data-sets : Geneva LIDAR of 2005 (left) and 2009 (right) - Data : SITG The following table gives a summary of the models sizes and primitive count : Model Size (UV3) Primitive Count Geneva 2005 663.2 Mio 24.8 M-Points Geneva 2009 1.2 Gio 46.7 M-Points Geneva 2013 3.9 Gio 4.2 G-Points Geneva 2017 7.0 Gio 7.5 G-Points The color of the models corresponds to the point classification. In addition, the models have a density that considerably increases with time, from 1 points/m^2 (2005) to 25 points/m^2 (2017). This disparity of density is considered as part of the sampling disparity, leading to a set of data very interesting to analyze and benchmark the difference detection algorithm. Models : Statistical Analysis \u00b6 As for line and triangle-based models, a statistical analysis of the point-based models is performed. The analysis consists in computing an approximation of the nearest neighbor distance distribution of points. The following figure shows the distribution of the 2005 and 2009 models : Statistical analysis : Nearest neighbor distribution approximation of the 2005 (left) and 2009 (right) models and the following figure shows the results for the 2013 and 2017 models : Statistical analysis : Nearest neighbor distribution approximation of the 2013 (left) and 2017 (right) models The nearest neighbor distribution tends to go toward zeros with the year of acquisition, showing that modern models are significantly denser that the older ones, making these models interesting for the difference detection algorithm analysis. Differences Detection Algorithm : Direct Application on Point-Based Models \u00b6 In order to determine the performances of the difference detection algorithm on the selected point-based models, the algorithm is simply applied without any adaptation on the data-sets and the results are analyzed. The following images give an overview of the obtained results comparing the 2005 and 2009 models : Application of the difference detection algorithm on point-based models : Geneva model of 2005 and 2009 with 2005 as primary (left) and inversely (right) - Data SITG One can see that the obtained results are very similar to the results obtained with the previously implemented XOR logical operator. The only differences is that the identical points are shown (in dark gray) along with the highlighted points (showing the differences). The same conclusion applies : the obtained composite model is difficult to read as it is dominated by sampling disparities. One can, by carefully looking at the model, ending up detecting large modifications by searching for highlighted points accumulation. In addition, taking one model or the other as primary for the algorithm does not really help as shown on the images above. The same conclusion applies even when the two compared models comes with a similar point density as the 2013 and 2017 models : Application of the difference detection algorithm on point-based models : Geneva model of 2013 and 2017 with 2013 as primary (left) and inversely (right) - Data SITG One can nevertheless observe that choosing the less dense model as primary leads to results a bit more clear for difference detection, but remaining very hard to interpret for a user, and much more for automated processes. In addition, the performances of the algorithm are very poor as point-based models are much denser in terms of primitives than line or triangle-based models. These reasons lead to the conclusion that the algorithm can not be directly used for point-based models and need a more specific approach. Differences Detection Algorithm : Adaptation for Point-Based Models \u00b6 In order to adapt the difference detection algorithm for point-based models, two aspects have to be addressed : the efficiency of the detection and the reduction of the sampling disparities over-representation, which are both server-side operations. The problem of efficiency can be solved quite easily if the adaptation of the difference detection algorithm goes in the direction of logical operators, for which an efficient methodology is already implemented. Solving the sampling disparity over-representation is more complicated. The adopted solution is inspired from a simple observation : the less deep (density of cells) the queries are, the clearer the obtained representation is. This can be illustrated by the following images showing the 2005 model compared with the 2009 one with depth equal to 7, 6 and 5, from left to right : Example of decreasing query depth on the comparison of 2005 and 2009 models - Data SITG This is expected, as the sampling disparities can only appear at scales corresponding to the nearest neighbor distribution. Nevertheless, as the depth is decreased, the models become less and less dense. The increase of difference readability is then compensated by the lack of density, making the structures more difficult to identify, and then, their subsequent modifications. The goal of the algorithm adaptation is to keep both readability and density. To achieve this goal, the implementation of the previous XOR operator is considered as a base, mostly for its efficiency. As the XOR simply detects if a cell of the space-time discretization at a given time is in a different state as its counterpart at another time, it can be modulated to introduce a scale delay mechanism that only applies detection on low-valued scales, broadcasting their results to their daughter cells. This allows to preserve the density and to perform the detection only on sufficiently shallow scales to avoid sampling disparities to become dominant. The question is how to operate the scale delay according to the scale itself. Indeed, with large points of view, the delay is not necessary as the model is viewed from far away. The necessity of the scale delay appears as the point of view is reduced, and, the more it is reduced, the larger the scale delay needs to be. A scale-attached delay is then defined to associate a specific value for each depth. Results and Experiments \u00b6 The adaptation of the difference detection algorithm for point-based models is analyzed using the selected data-sets. An overview of its result is presented before a more formal analysis is made using difference detection made on line-based official land register data to be compared with the differences on point-based models. Differences Detection : Overview \u00b6 Considering the two first models, from 2005 and 2009 campaigns, the following images shows the results of the initial version of the difference detection algorithm (similar to XOR operator) and its adapted version implementing the scale delay : Differences detection on 2005 and 2009 models with 2005 as primary - Left : without scale delay - Right : with scale delay - Data SITG One can see how scale delay is able to drastically reduce the effect of sampling disparities while comparing two point-based models. The effect is more obvious as the 2009 model is set as primary for difference detection : Differences detection on 2005 and 2009 models with 2009 as primary - Left : without scale delay - Right : with scale delay - Data SITG This improvement gets more clear as the point of view is reduced. The following image shows the initial algorithm and the scale delay algorithm on a specific area of the city with 2005 as primary model : Differences detection on 2005 and 2009 models with 2005 as primary - Left : without scale delay - Right : with scale delay - Data SITG By inverting the model roles and making the 2009 model primary for difference detection lead to similar results : Differences detection on 2005 and 2009 models with 2009 as primary - Left : without scale delay - Right : with scale delay - Data SITG Considering the denser models of 2013 and 2017 campaigns, the results of the scale delay introduction also lead to a better understanding of the differences as shown on the following images : Differences detection on 2013 and 2017 models with scale delay - Left : 2013 as primary - Right : 2017 as primary - Data SITG Nevertheless, one can see that scale delay is not able to get rid entirely of sampling disparities. The right image above, comparing the 2017 model to the 2013 one, shows sampling disparities being highlighted as differences on the wall of the building in the background. This does not affect too much the user readability, but still make the model a bit more complicated to understand. In addition, the models play an important role in the way differences can be detected through classic approach. For example, focusing on a specific building, the obtained highlighted differences : Differences detection on 2013 and 2017 models with scale delay with 2013 (left) and 2017 (right) as primary - Data SITG could lead the user to consider the building wall as a difference. Looking at the formal situation in both 2013 and 2017 models : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can see that the detected difference comes from the missing wall on the 2013, and not from a formal evolution of the building. This example illustrates that sampling disparity is not the only factor that could reduce the readability of the model for the user. Differences Detection : Comparison with Land Register Differences \u00b6 As the algorithm is already tested for land register models, one can use its results on these data in order to put them into perspective of the detected differences on point cloud. As the methodology is not the same for vector-based and point-based models, it is interesting to see the coherence and deviations of both approaches. One important thing to underline, is that difference detection in land register model does not detect changes in the environment directly, but detects the revision of the land register itself, as discussed in the previous phase. Of course, land register models evolve with environment, but come also with a large amount of modifications that only represent corrections of the model and not formal changes in the environment. This reason reinforces the interest to but point-based model difference detection with the land register models ones. In the previous phase, the land register models of Geneva were selected to be the closest to the LIDAR campaigns. It follows, that these models can be directly used here, as each corresponding to the compared point-based model of this phase. As a first example, the following case is studied : Rue de Bourgogne and Rue de Lyon . In this case, looking at the following images giving the situation in 2013-04 and 2017-04 through the LIDAR models, that an industrial building was partially demolished. Structural situation in 2013 (left) and 2017 (right) - Data SITG The following images show the differences computed on both point-based and line-based models : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG One can clearly see that the difference detection on the LIDAR models correctly emphasized a true structural difference between the two times. The situation is much less clear on the land register model. Indeed, as the time separating the two models is quite high, four years in such a case, a large mount of corrections dominates the difference model, leading to a difficult interpretation of the building situation change. The following images give the situation of the land register model in 2013 and 2017 that lead to the difference model above : Land register situation in 2013 (left) and 2017 (right) - Data SITG Looking at the land register models, one can also see that such large scale modification of the building situation does not appear clearly. Indeed, it takes some effort to detect minor changes on the two models, without leading to a clear indication of the modification. This shows how the LIDAR and its differences can help to detect and analyze differences in complement to the land register itself. Considering the second example, Avenue de France and Avenue Blanc , the following images give the structural situation of the two times as capture by the LIDAR campaigns : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can clearly see the destruction of the two 2013 buildings replaced by a parking lot in 2017 . The detected differences on the LIDAR and land register models are presented on the following images : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG Again, despite the differences are clearly and correctly highlighted on the LIDAR differences model, the situation remains unclear on the differences model of the land register. Again, one can observe that the land register was highly corrected between the two dates, leading to difficulties to understand the modification and its nature. Looking at the land register respective models : Land register situation in 2013 (left) and 2017 (right) - Data SITG the modification appears a bit more clearly. One can clearly see the disappearance of the two 2013 buildings in the land register replaced by a big empty area. Again, the difference detection on LIDAR seems clearly more relevant to detect and analyze structural differences than the land register itself. An interesting example is provided by the situation just east of the Basilique Notre-Dame . The two situations as captured by the LIDAR campaigns are presented on the following images : Structural situation in 2013 (left) and 2017 (right) - Data SITG One can observe two structure mounted on top of two buildings roof in the 2013 situation. These structures are used to ease the work that has to be performed on the roofs. These structures are no more present in the 2017 situation. The following images give the difference detection models for the LIDAR and land register : Difference models between 2013 and 2017 of LIDAR (left) and INTERLIS (right), with 2013 as primary - Data SITG In such a case, as the structural modification between 2013 and 2017 occurs on top of the buildings, their footprints is not affected and the differences have no chance to appear in the land register models, even looking at them individually as in the following images : Land register situation in 2013 (left) and 2017 (right) - Data SITG This is another example where the LIDAR difference detection lead to more and clearer information on the structural modification that appear on Geneva between the two times. Conclusion : Third Phase \u00b6 The main element of this third phase conclusion is that difference detection on point-based models is less straightforward than for other models. Indeed, applied naively, the algorithm is dominated by the sampling disparities of the compared models. This illustrate that point-based models, being a close mirror of the true territory state, have a large information density that is more difficult to reach, especially from their evolution point of view. Nevertheless, we showed that the algorithm can be adapted, with relatively simple adjustments, to perform well on point-based models difference detection problem. The implemented algorithm is able to track and represent the differences appearing between the models in a useful and comprehensive way for users. The proposed example showed that the differences models are able to guide the user toward interesting structural changes in the territory, with a clear view of the third dimension. Of course, the highlighted differences in point-based models are more complex and required a trained user that is able to interpret correctly the detail of the highlighted part of the model. The trees are a good example. As the tree re-grow each year, they will always appear as a differences in the compared models. A user only interested in building changes has to be aware of that and be able to separate the relevant differences from the others. Following the comparison between LIDAR and land register ( INTERLIS ) differences models, a very surprising conclusion appear. In the first place, one could stand that land register is the proper way of detected changes that can be then analyzed more in detail in point-based differences models. In turns out that to opposite is true. Several reason explain this surprising situation. In the first place, LIDAR are available only with large temporal gaps between them, at least two/three years. This allows the land register models to be filled with large amount of updates and correction, leading the differences model on this temporal gap to be filled with much more than structural modification. In addition, the LIDAR models come with the third dimension where the land register models are flat. The third dimension comes with large amount of differences that can not be seen in the land register. To some extend, the land register, and its evolution, is the reflect of the way the territory is surveyed, not the reflect of the formal territory evolution. In the opposite, as LIDAR models are a structural snapshot of a territory situation, the analyze of their differences across the time lead to a better tracking of the formal modification of the real world . Conclusion \u00b6 First Phase \u00b6 In the first phase, the difference detection algorithm was implemented for vector models and tested using synthetic differences on selected models. The results showed the interest of the obtained differences models to emphasize evolution of models from both user and process points of view. It was demonstrated that the information between models exists and can be extracted and represented in a relevant way for both users and processes. Second Phase \u00b6 In the second phase, the difference detection algorithm was tested on the Swiss land register models on which the results obtained during the first phase were confirmed. The differences models are able to provide both user and process a clear and understandable view of the modification brought to the models. In addition, through the short and long-term perspectives, it was possible to demonstrate how the difference detection algorithm is able to provide different points of view on the model evolution. From a short-term perspective, the differences models are able to provide a clear and individual view of the modification while the long-term perspective allows to see the large scale evolution and transformation of the models. It follows that the difference models can be used as a tool for various actors using or working with the land register models. Third Phase \u00b6 In the third phase, the difference detection algorithm, developed on vector models, was applied on point-based models, showing that a direct application on these models lead to the same issue as the logical operators : the differences models are dominated by sampling disparities, making them complicated to read. The solution of scale delay brought to the algorithm allowed to produce much clearer differences models for point-based data, allowing to generalize the difference detection on any models. In addition to these results, the comparison of difference models on land register and on their corresponding LIDAR point-based models showed an interesting result : for structural changes, the point-based models lead to much more interesting results through the highlighted differences. Indeed, as land register models, considered long term perspective, are dominated by a large amount of corrections and adjustments in addition to territory evolution updates, making the structural changes not easy to detect and understand. The differences models are more clear with point-based models form this point of view. In addition, as point-based models, such as LIDAR , come with the third dimension, a large amount of structural differences can only be seen through such data as many structural changes are made along the third dimension. It then follows that difference detection applied to point-based models offers a very interesting point of view for the survey of territory structural changes. Synthesis \u00b6 As a synthesis, it is clear that models are carrying a large amount of richness themselves, that is already a challenge to exploit, but it is also clear that a large amount of information can be found between the versions of the models. The difference detection algorithm brings a first tool that demonstrate the ability to reach and start to exploit these informations. More than the content of the models itself, the understanding of the evolution of this content is a major topic especially in the field of geodata as they represent, transcript, the evolution of the surveyed territory. It then appears clear that being able to reach and exploit the information contained in-between the models is a major advantage as it allows understanding what are these models, that is four dimensional objects. Perspectives \u00b6 Many perspectives are opened following the implementation and analysis of the difference detection. Several perspectives, mostly technical, are presented here as a final section. In the first place, as raster are entering the set of data that can be injected in the platform, evolution of the difference detection could be applied to the platform, taking advantage of the evolution of machine learning. The possibility of detected differences in images could lead to very interesting perspective through the data communication features of the platform. Another perspective could be to allow the platform to separate the data into formal layers, the separation being only currently ensure by type and times. Splitting data into layers would allow applying difference detection in a much more controlled manner, leading to difference models focused on very specific elements of the model temporal evolution. The addition of layer could also be the starting point to the notion of data convolution micro language . Currently, data communication and difference detection only apply through the specification of two different and parallel navigation time. The users, or processes, have to specify each of the two time position in order to obtain the mixed of differences models they need. An interesting evolution would be to replace these two navigation time by a small and simple micro language allowing the user to compare more than two times in a more complex manner. This could also benefit from data separation through layer. Such micro language could allow to compare two, three or more models, or layers, and would also open the access the mixed models of differences models such as comparing the difference detection between point-based and vector-based models, which would then be a comparison of a comparison. Reproduction Resources \u00b6 To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Only part of the considered datasets are publicly available. For the OpenStreetMap datasets, you can download them from the following source : Shapefile layers, OpenStreetMap For the Swiss 3D buildings model, you can contact swisstopo : Shapefile 3D buildings, swisstopo For the land register datasets of Geneva and Thurgau , you can contact the SITG and the Thurgau Kanton : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) The point-based models of Geneva can be downloaded from the SITG online extractor : LAS MNS, SITG (Geneva) To extract and convert the data from planimetric shapefiles , the following code is used : Shapefile CSV export to UV3 (csv-wkt-to-uv3), STDL where the README gives all the information needed. In case of shapefile containing 3D models, please ask the STDL for advice and tools. To extract and convert the data from INTERLIS and LAS , the following codes are used : INTERLIS to UV3 (dalai-suite), STDL/EPFL LAS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results. Auxiliary Developments & Corrections \u00b6 In addition to the main developments made, some additional scripts and other corrections have been made to solve auxiliary problems or to improve the code according to the developed features during this task. The auxiliary developments are summarized here : Correction of socket read function to improve server-client connectivity. Creation of scripts that allows to insert synthetic modifications (random displacements on the vertex coordinates) on UV3 models. Creation of a script to convert CSV export from shapefile to UV3 format. The script code is available here . Adding temporary addresses (space-time index) exportation in platform 3D interface. Correction of the cell enumeration process in platform 3D interface (wrong depth limit implementation). Creation of a script allowing segmenting UV3 model according to geographical bounding box. Creation of C codes to perform statistical analysis of the point, line and triangle-based models : computation of edge size and nearest neighbor distributions. Creation of a C code allowing enumerating non-empty cell index over the Switzerland models injected in the platform. Creation of a C code allowing to automate the difference detection based on an index list and by searching in the data queried from the platform. Developments of various scripts for plots and figures creations. References \u00b6 [1] REFRAME, SwissTopo, https://www.swisstopo.admin.ch/de/karten-daten-online/calculation-services.html","title":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT"},{"location":"TASK-DIFF/#automatic-detection-of-changes-in-the-environment","text":"Nils Hamel (UNIGE) Project scheduled in the STDL research roadmap - TASK-DIFF September 2020 to November 2020 - Published on December 7, 2020 Abstract : Developed at EPFL with the collaboration of Cadastre Suisse to handle large scale geographical models of different nature, the STDL 4D platform offers a robust and efficient indexation methodology allowing to manage storage and access to large-scale models. In addition to spatial indexation, the platform also includes time as part of the indexation, allowing any area to be described by models in both spatial and temporal dimensions. In this development project, the notion of model temporal derivative is explored and proof-of-concepts are implemented in the platform. The goal is to demonstrate that, in addition to their formal content, models coming with different temporal versions can be derived along the time dimension to compute difference models. Such proof-of-concept is developed for both point cloud and vectorial models, demonstrating that the indexation formalism of the platform is able to ease considerably the computation of difference models. This research project demonstrates that the time dimension can be fully exploited in order to access the data it holds.","title":"AUTOMATIC DETECTION OF CHANGES IN THE ENVIRONMENT"},{"location":"TASK-DIFF/#task-context-difference-detection","text":"As the implemented indexation formalism is based on equivalences classes defined on space and time, a natural discretization along all the four dimensions is obtained. In the field of difference detection, it allowed implementing simple logical operators on the four-dimensional space. The OR , AND and XOR operators were then implemented allowing the platform to compute, in real time , convolutions to compare models with each others across the time. The implementation of these operators was simple due to the natural spatio-temporal discretization obtained from the indexation formalism. Nevertheless, two major drawbacks appeared : the first one is that such operators only works for point-based models. Having the opportunity to compute and render differences and similarities between any type of data is not possible with such formal operators. The second drawback comes from the nature of the point-based capturing devices. Indeed, taking the example of a building, even without any change to its structure, two digitization campaigns can lead to disparities only due to measures sampling. The XOR operator is the natural choice to detect and render differences, but this operator is very sensitive to sampling disparities. Computing the XOR convolution between two point-based models leads the rendering to be dominated by sampling variations rather than the desired structural differences. This drawback was partially solved by considering the AND operator. Indeed, the AND operator allows to only shows constant structural elements from two different positions in time and is insensitive to sampling disparities. As shown on the following images, the AND operator shows differences as black spots (missing parts) : AND convolution between two LIDAR models : Geneva 2005 and 2009 - Data : SITG As one can see, AND convolutions allow detecting, through the black spots, large area of structural changes between the two times and also, with more care, allow guessing smaller differences. Nevertheless, reading and interpreting such representation remains complex for users. The goal of this task is then to tackle these two drawbacks, allowing the platform to detect changes not only for point-based models but also for vector-based models and to implement a variation of the XOR operator for point-based models allowing to efficiently highlight the structural evolution. The task consists then in the implementation, testing and validation of a difference detection algorithm suitable for any type of model and to conduct a formal analysis on the best rendering techniques.","title":"Task Context : Difference Detection"},{"location":"TASK-DIFF/#methodology","text":"A step by step methodology is defined to address the problem of difference detection in the platform. In a first phase, the algorithm will be developed and validated on vector-based models as follows : Obtaining a large scale vector-based model on which synthetic variation are introduced Development of the algorithm using the synthetic variations model Testing and validation of the algorithm (using the known synthetic variations) First conclusion In a second phase, true land register data will be used to formally detect real evolutions of the territory : Obtaining true land register vector-based models (INTERLIS) at different times Analysis of the difference detection algorithm on true land register vector-based models Second conclusion In a third phase, the algorithm will be validated and adapted to work on point-based models : Obtaining true land register point-based models (LAS) at different position in time Verifying the performances of the vector-based detection algorithm on point-based data Adaptation of the algorithm for point-based models Analysis of the difference detection algorithm on true land register point-based models Comparison of the detected differences on point-based models and on their corresponding land register vector-based models (INTERLIS) Third conclusion In addition, the development of difference detection algorithm has to be conducted keeping in mind the possible future evolutions of the platform such as addition of layers (separation of data), implementation of a multi-scale approach of the time dimension and addition of raster data in the platform.","title":"Methodology"},{"location":"TASK-DIFF/#first-phase-synthetic-variations","text":"In order to implements the vector-based difference detection algorithm, sets of data are considered as base on which synthetic differences are applied to simulate the evolution of the territory. This approach allows focusing on well controlled data to formally benchmark the results of the implemented algorithm. Experiments are conducted using these data to formally evaluate the performance of the developed algorithm.","title":"First Phase : Synthetic Variations"},{"location":"TASK-DIFF/#selected-resources-and-models","text":"","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#implementation-of-the-algorithm","text":"In order to compare two models at two different positions in time to detect differences, the solution is of course to search for each primitive of the primary time if it has a corresponding one in the secondary time. In such case, the primitives can be concluded as static in time and only the primitives that have no correspondence will be highlighted as differences. A first approach was initially tested : a vertex-based comparison. As every primitive (points, lines and triangles) is supported by vertexes, it can be seen as a common denominator on which comparison can take place. Unfortunately, it is not a relevant approach as it leads to an asymmetric detection algorithm. To illustrate the issue, the following image shows the situation of a group of line-based primitives at two different times with an evolution on one of the primitive vertex : Asymmetric approach : The variation is detected only when comparing backward in time When the comparison occurs between the second time and the first one, the modified vertex correspondence is not found, and the vertex can be highlighted as a difference. The asymmetry appears as the first time is compared to the second one. In this case, despite the primitive vertex changed, the vertex-based approach is able to find another vertex, part of another primitive, and interprets it as a vertex identity, leading the modified primitive to be considered as static. In order to obtain a fully symmetric algorithm, that does not depend on the way models are compared in times, a primitive-attached approach is considered. The implemented algorithm then treats the correspondence problem from the whole primitive point of view, by checking that the whole primitive can be found in the other model to which it is compared to. This allows to highlight any primitive showing a modification, regardless of the way models are compared and the nature of the modification. In addition to highlighting the primitives that changed through time, the implemented algorithm also renders the primitives that have not changed. The primitives are then shown by modulating their color to emphasize the modifications by keeping their original color for the modified one, while the static primitives are shown in dark gray. This allows to not only show the modifications but also to keep the context of the modifications, helping the user to fully understand the nature of the territory evolution. In addition to color modulation, a variation of difference rendering is analyzed. In addition to color modulation, a visual and artificial marker is added to ease their search. The visual marker is a simple line emanating from the primitive and goes straight up with a size of 512 meters. Such markers are introduced to ease the detection of small primitives that can be difficult to spot according to large point of views. Additional developments were required for triangle-based models : indeed, such models need to be subjected to a light source during rendering for the user to understand the model (face shading). The previously implemented lighting model is then modified to take into account color modulation in order to correctly render the triangle that are highlighted. Moreover, the lighting model was modified to light both face of the triangles in order to light them regardless of the point of view. In addition, as mesh models are made of triangles, primitives can hide themselves. It can then be difficult for the user to spot the highlighted primitives as they can be hidden by others. An option was added to the rendering client allowing the user to ask the rendering of triangles as line-loops or points in order to make them transparent. Finally, an option allowing the user to enable or disable the render face culling was added for him to be able to see the primitive from backward.","title":"Implementation of the Algorithm"},{"location":"TASK-DIFF/#results-and-experiments","text":"With the implemented algorithm, a series of experiments are conducted in order to validate its results and to analyze the efficiency of the difference detection and rendering from a user point of view. In addition, experiments are also conducted to quantify the efficiency of the difference detection for automated processes.","title":"Results and Experiments"},{"location":"TASK-DIFF/#conclusion-first-phase","text":"During this first phase, the difference detection algorithm was developed and validated on both line-based and triangle-based data. An efficient algorithm is then implemented in the platform allowing emphasizing differences between models at different temporal positions. The algorithm is able to perform the detection on the fly with good performances allowing the users to dynamically browse the data to detect and analyze the territory evolutions. The performances of the detection algorithm allow the platform to be suitable for automated detection processes, as a data provider, answering large amounts of queries in an efficient and remote manner. Two variations of the difference detection algorithm are implemented. The first version consists in highlighting the primitives that are subject to modifications over a time. This variation is suitable for automated processes that can rely on simple search methods to list the differences. For the users, this first variation can lead to more difficult visual detection of the differences, especially in case the highlighted primitives are small or hidden by others. For this reason, visual markers were added on top of the highlighted primitives in order to be seen from far away, regardless of the primitives size. The measures sessions made during the user-based experiments showed a clear improvement of the detection rate when using the visual markers. This was especially true for triangle-based models, where the primitives bring occlusions. The user-based experiments showed that using the platform interface, a human can significantly outperform the result of a naive automated process operating on the models themselves. The experiments showed that the user is able to efficiently search and find through space and time the evolutions of the territory appearing in the data. Of course, as the model size and complexity increases, the user-driven interface starts to show its limits. In such a case, the process-based experiments showed that automated processes can take over these more complicated searches through methods allowing performing exhaustive detection over wide models in a matter of several minutes. At this point, the developments and validations of the algorithm, and its variations, were conducted on synthetic modifications introduced in models using controlled procedures. The next phase focuses on formal data extracted from land registers.","title":"Conclusion : First Phase"},{"location":"TASK-DIFF/#second-phase-true-variations","text":"In this second phase, also dedicated to vector-based models, the focus is set on applying the developed difference detection algorithm on true land register models. Two sets of data are considered in order to address short-term and long-term difference detection.","title":"Second Phase : True Variations"},{"location":"TASK-DIFF/#selected-resources-and-models_1","text":"In both cases, short-term and long-term, INTERLIS data are considered. A selection of tables in different topics is performed to extract the most interesting geometries of the land registering. For all models, the following colors are used to distinguish the extracted layers : INTERLIS selected topics and tables colors - Official French and German designations The layers are chosen according to their geometric content. The color assignation is arbitrary and does not correspond to any official colorization standard.","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#results-and-analysis","text":"","title":"Results and Analysis"},{"location":"TASK-DIFF/#conclusion-second-phase","text":"Two cases have been addressed in this phase showing each specific interesting application of the difference detection applied on land register data through the INTERLIS format. Indeed, short and long term differences emphasize two different points of view according to the analysis of the land register and its evolution in time. In the first place, the short term application clearly showed how difference detection and their representation opens a new point of view on the evolution of the land register as it allows focusing on clear and well identified modifications. As the compared models are close in time, one is able to produced differences models allowing to clearly see, modification by modification, what happened between the two compare situations, allowing focusing on each evolution to fully understand the modification. It follows that this short-term difference detection can provide a useful approach for the user of the land register that are more interested in the evolution of the model rather than in the model itself. The difference models can provide users a clear a simple view on what to search and to analyze to understand the evolution of such complex models. In some way, the differences on land register models can be seen as an additional layer proposed to the user to allow him to reach information that are not easy to extract from the models themselves. The case of Geneva , illustrating the long-term difference detection case, showed another interesting point of view. In the first place, one has to understand that land register models are complex and living models, not only affected by the transcription of the real-world situation across the time. Indeed, on the Geneva models, a large amount of differences is detected even on a relative short period of time (two years). In addition to the regular updates, following the territory evolution, a large amount of corrections is made to keep the model in the correct reference frame. The Swiss federal system can also add complexity, as all Cantons have to align themselves on a common set of expectations. In such a case, the difference detection turned out to be an interesting tool to understand and follows the corrections made to the model in addition to the regular updates. On the Geneva case, we illustrated that, by detecting it in the difference model, the correction on the coordinates frame on large pieces of the territory. This shows how the difference detection can be seen as a service that can help to keep track of the life of the model by detecting and checking these type of modifications. As a result, difference detection can be a tool for the user of the land register but can also be a tool for the land register authorities themselves. The difference models can be used to check and audit the evolution of the models, helping the required follow-up on the applied correction and updates.","title":"Conclusion : Second Phase"},{"location":"TASK-DIFF/#third-phase-point-based-models","text":"In this third and last phase, the developed algorithm for difference detection on vector models is tested on point-based ones. As mentioned in the introduction, the platform was already implementing logical operators allowing comparing point-based models across time. As illustrated in the introduction, only the AND operator allowed emphasizing differences, but rendering them as missing part of the composite models. It was then difficult for the user to determine and analyze those differences. The goal of this last phase is to determine in which extend the developed algorithm is able to improve the initial results of point-based logical operators and how it can be adapted to provide better detection of differences.","title":"Third Phase : Point-Based Models"},{"location":"TASK-DIFF/#selected-resources-and-models_2","text":"","title":"Selected Resources and Models"},{"location":"TASK-DIFF/#differences-detection-algorithm-direct-application-on-point-based-models","text":"In order to determine the performances of the difference detection algorithm on the selected point-based models, the algorithm is simply applied without any adaptation on the data-sets and the results are analyzed. The following images give an overview of the obtained results comparing the 2005 and 2009 models : Application of the difference detection algorithm on point-based models : Geneva model of 2005 and 2009 with 2005 as primary (left) and inversely (right) - Data SITG One can see that the obtained results are very similar to the results obtained with the previously implemented XOR logical operator. The only differences is that the identical points are shown (in dark gray) along with the highlighted points (showing the differences). The same conclusion applies : the obtained composite model is difficult to read as it is dominated by sampling disparities. One can, by carefully looking at the model, ending up detecting large modifications by searching for highlighted points accumulation. In addition, taking one model or the other as primary for the algorithm does not really help as shown on the images above. The same conclusion applies even when the two compared models comes with a similar point density as the 2013 and 2017 models : Application of the difference detection algorithm on point-based models : Geneva model of 2013 and 2017 with 2013 as primary (left) and inversely (right) - Data SITG One can nevertheless observe that choosing the less dense model as primary leads to results a bit more clear for difference detection, but remaining very hard to interpret for a user, and much more for automated processes. In addition, the performances of the algorithm are very poor as point-based models are much denser in terms of primitives than line or triangle-based models. These reasons lead to the conclusion that the algorithm can not be directly used for point-based models and need a more specific approach.","title":"Differences Detection Algorithm : Direct Application on Point-Based Models"},{"location":"TASK-DIFF/#differences-detection-algorithm-adaptation-for-point-based-models","text":"In order to adapt the difference detection algorithm for point-based models, two aspects have to be addressed : the efficiency of the detection and the reduction of the sampling disparities over-representation, which are both server-side operations. The problem of efficiency can be solved quite easily if the adaptation of the difference detection algorithm goes in the direction of logical operators, for which an efficient methodology is already implemented. Solving the sampling disparity over-representation is more complicated. The adopted solution is inspired from a simple observation : the less deep (density of cells) the queries are, the clearer the obtained representation is. This can be illustrated by the following images showing the 2005 model compared with the 2009 one with depth equal to 7, 6 and 5, from left to right : Example of decreasing query depth on the comparison of 2005 and 2009 models - Data SITG This is expected, as the sampling disparities can only appear at scales corresponding to the nearest neighbor distribution. Nevertheless, as the depth is decreased, the models become less and less dense. The increase of difference readability is then compensated by the lack of density, making the structures more difficult to identify, and then, their subsequent modifications. The goal of the algorithm adaptation is to keep both readability and density. To achieve this goal, the implementation of the previous XOR operator is considered as a base, mostly for its efficiency. As the XOR simply detects if a cell of the space-time discretization at a given time is in a different state as its counterpart at another time, it can be modulated to introduce a scale delay mechanism that only applies detection on low-valued scales, broadcasting their results to their daughter cells. This allows to preserve the density and to perform the detection only on sufficiently shallow scales to avoid sampling disparities to become dominant. The question is how to operate the scale delay according to the scale itself. Indeed, with large points of view, the delay is not necessary as the model is viewed from far away. The necessity of the scale delay appears as the point of view is reduced, and, the more it is reduced, the larger the scale delay needs to be. A scale-attached delay is then defined to associate a specific value for each depth.","title":"Differences Detection Algorithm : Adaptation for Point-Based Models"},{"location":"TASK-DIFF/#results-and-experiments_1","text":"The adaptation of the difference detection algorithm for point-based models is analyzed using the selected data-sets. An overview of its result is presented before a more formal analysis is made using difference detection made on line-based official land register data to be compared with the differences on point-based models.","title":"Results and Experiments"},{"location":"TASK-DIFF/#conclusion-third-phase","text":"The main element of this third phase conclusion is that difference detection on point-based models is less straightforward than for other models. Indeed, applied naively, the algorithm is dominated by the sampling disparities of the compared models. This illustrate that point-based models, being a close mirror of the true territory state, have a large information density that is more difficult to reach, especially from their evolution point of view. Nevertheless, we showed that the algorithm can be adapted, with relatively simple adjustments, to perform well on point-based models difference detection problem. The implemented algorithm is able to track and represent the differences appearing between the models in a useful and comprehensive way for users. The proposed example showed that the differences models are able to guide the user toward interesting structural changes in the territory, with a clear view of the third dimension. Of course, the highlighted differences in point-based models are more complex and required a trained user that is able to interpret correctly the detail of the highlighted part of the model. The trees are a good example. As the tree re-grow each year, they will always appear as a differences in the compared models. A user only interested in building changes has to be aware of that and be able to separate the relevant differences from the others. Following the comparison between LIDAR and land register ( INTERLIS ) differences models, a very surprising conclusion appear. In the first place, one could stand that land register is the proper way of detected changes that can be then analyzed more in detail in point-based differences models. In turns out that to opposite is true. Several reason explain this surprising situation. In the first place, LIDAR are available only with large temporal gaps between them, at least two/three years. This allows the land register models to be filled with large amount of updates and correction, leading the differences model on this temporal gap to be filled with much more than structural modification. In addition, the LIDAR models come with the third dimension where the land register models are flat. The third dimension comes with large amount of differences that can not be seen in the land register. To some extend, the land register, and its evolution, is the reflect of the way the territory is surveyed, not the reflect of the formal territory evolution. In the opposite, as LIDAR models are a structural snapshot of a territory situation, the analyze of their differences across the time lead to a better tracking of the formal modification of the real world .","title":"Conclusion : Third Phase"},{"location":"TASK-DIFF/#conclusion","text":"","title":"Conclusion"},{"location":"TASK-DIFF/#first-phase","text":"In the first phase, the difference detection algorithm was implemented for vector models and tested using synthetic differences on selected models. The results showed the interest of the obtained differences models to emphasize evolution of models from both user and process points of view. It was demonstrated that the information between models exists and can be extracted and represented in a relevant way for both users and processes.","title":"First Phase"},{"location":"TASK-DIFF/#second-phase","text":"In the second phase, the difference detection algorithm was tested on the Swiss land register models on which the results obtained during the first phase were confirmed. The differences models are able to provide both user and process a clear and understandable view of the modification brought to the models. In addition, through the short and long-term perspectives, it was possible to demonstrate how the difference detection algorithm is able to provide different points of view on the model evolution. From a short-term perspective, the differences models are able to provide a clear and individual view of the modification while the long-term perspective allows to see the large scale evolution and transformation of the models. It follows that the difference models can be used as a tool for various actors using or working with the land register models.","title":"Second Phase"},{"location":"TASK-DIFF/#third-phase","text":"In the third phase, the difference detection algorithm, developed on vector models, was applied on point-based models, showing that a direct application on these models lead to the same issue as the logical operators : the differences models are dominated by sampling disparities, making them complicated to read. The solution of scale delay brought to the algorithm allowed to produce much clearer differences models for point-based data, allowing to generalize the difference detection on any models. In addition to these results, the comparison of difference models on land register and on their corresponding LIDAR point-based models showed an interesting result : for structural changes, the point-based models lead to much more interesting results through the highlighted differences. Indeed, as land register models, considered long term perspective, are dominated by a large amount of corrections and adjustments in addition to territory evolution updates, making the structural changes not easy to detect and understand. The differences models are more clear with point-based models form this point of view. In addition, as point-based models, such as LIDAR , come with the third dimension, a large amount of structural differences can only be seen through such data as many structural changes are made along the third dimension. It then follows that difference detection applied to point-based models offers a very interesting point of view for the survey of territory structural changes.","title":"Third Phase"},{"location":"TASK-DIFF/#synthesis","text":"As a synthesis, it is clear that models are carrying a large amount of richness themselves, that is already a challenge to exploit, but it is also clear that a large amount of information can be found between the versions of the models. The difference detection algorithm brings a first tool that demonstrate the ability to reach and start to exploit these informations. More than the content of the models itself, the understanding of the evolution of this content is a major topic especially in the field of geodata as they represent, transcript, the evolution of the surveyed territory. It then appears clear that being able to reach and exploit the information contained in-between the models is a major advantage as it allows understanding what are these models, that is four dimensional objects.","title":"Synthesis"},{"location":"TASK-DIFF/#perspectives","text":"Many perspectives are opened following the implementation and analysis of the difference detection. Several perspectives, mostly technical, are presented here as a final section. In the first place, as raster are entering the set of data that can be injected in the platform, evolution of the difference detection could be applied to the platform, taking advantage of the evolution of machine learning. The possibility of detected differences in images could lead to very interesting perspective through the data communication features of the platform. Another perspective could be to allow the platform to separate the data into formal layers, the separation being only currently ensure by type and times. Splitting data into layers would allow applying difference detection in a much more controlled manner, leading to difference models focused on very specific elements of the model temporal evolution. The addition of layer could also be the starting point to the notion of data convolution micro language . Currently, data communication and difference detection only apply through the specification of two different and parallel navigation time. The users, or processes, have to specify each of the two time position in order to obtain the mixed of differences models they need. An interesting evolution would be to replace these two navigation time by a small and simple micro language allowing the user to compare more than two times in a more complex manner. This could also benefit from data separation through layer. Such micro language could allow to compare two, three or more models, or layers, and would also open the access the mixed models of differences models such as comparing the difference detection between point-based and vector-based models, which would then be a comparison of a comparison.","title":"Perspectives"},{"location":"TASK-DIFF/#reproduction-resources","text":"To reproduce the presented experiments, the STDL 4D framework has to be used and can be found here : STDL 4D framework (eratosthene-suite), STDL You can follow the instructions on the README to both compile and use the framework. Only part of the considered datasets are publicly available. For the OpenStreetMap datasets, you can download them from the following source : Shapefile layers, OpenStreetMap For the Swiss 3D buildings model, you can contact swisstopo : Shapefile 3D buildings, swisstopo For the land register datasets of Geneva and Thurgau , you can contact the SITG and the Thurgau Kanton : INTERLIS land register, Thurgau Kanton INTERLIS land register, SITG (Geneva) The point-based models of Geneva can be downloaded from the SITG online extractor : LAS MNS, SITG (Geneva) To extract and convert the data from planimetric shapefiles , the following code is used : Shapefile CSV export to UV3 (csv-wkt-to-uv3), STDL where the README gives all the information needed. In case of shapefile containing 3D models, please ask the STDL for advice and tools. To extract and convert the data from INTERLIS and LAS , the following codes are used : INTERLIS to UV3 (dalai-suite), STDL/EPFL LAS to UV3 (dalai-suite), STDL/EPFL where the README gives all the information needed. For the 3D geographical coordinates conversion and heights restoration, we used two STDL internal tools. You can contact the STDL to obtain the tools and support in this direction : ptolemee-suite : 3D coordinate conversion tool (EPSG:2056 to WGS84) height-from-geotiff : Restoring geographical heights using topographic GeoTIFF ( SRTM ) You can contact STDL for any question regarding the reproduction of the presented results.","title":"Reproduction Resources"},{"location":"TASK-DIFF/#auxiliary-developments-corrections","text":"In addition to the main developments made, some additional scripts and other corrections have been made to solve auxiliary problems or to improve the code according to the developed features during this task. The auxiliary developments are summarized here : Correction of socket read function to improve server-client connectivity. Creation of scripts that allows to insert synthetic modifications (random displacements on the vertex coordinates) on UV3 models. Creation of a script to convert CSV export from shapefile to UV3 format. The script code is available here . Adding temporary addresses (space-time index) exportation in platform 3D interface. Correction of the cell enumeration process in platform 3D interface (wrong depth limit implementation). Creation of a script allowing segmenting UV3 model according to geographical bounding box. Creation of C codes to perform statistical analysis of the point, line and triangle-based models : computation of edge size and nearest neighbor distributions. Creation of a C code allowing enumerating non-empty cell index over the Switzerland models injected in the platform. Creation of a C code allowing to automate the difference detection based on an index list and by searching in the data queried from the platform. Developments of various scripts for plots and figures creations.","title":"Auxiliary Developments &amp; Corrections"},{"location":"TASK-DIFF/#references","text":"[1] REFRAME, SwissTopo, https://www.swisstopo.admin.ch/de/karten-daten-online/calculation-services.html","title":"References"},{"location":"TASK-IDET/","text":"Object Detection Framework \u00b6 Alessandro Cerioni, Etat de Geneve - Cl\u00e9mence Herny, Exolabs - Adrian F. Meyer, FHNW - Gwena\u00eblle Salamin, Exolabs Published on November 22, 2021 Updated on December 12, 2023 Abstract : The STDL develops a framework allowing users to train and use deep learning models to detect objects in aerial images. While relying on a generic-purpose third-party open-source library, the STDL's framework implements a somewhat opinionated workflow, targeting georeferenced aerial images and labels. After a brief introduction to object detection, this article provides detailed information on the STDL's object detection framework and the opinions it implements. References to successful applications are provided along with concluding remarks. Introduction \u00b6 Object detection is a computer vision task which aims at detecting instances of objects of some target classes ( e.g. buildings, swimming pools, solar panels, ...) in digital images and videos. According to the commonly adopted terminology, a distinction is made between the following tasks: object detection , in which the goal is to determine the rectangular \"bounding box\" surrounding each detected object; instance segmentation , in which one aims at finding the pixels belonging to each detected object. This distinction is well illustrated by the bottom half of the following image: Object Detection vs Instance Segmentation. Image credit: Waleed Abdulla . Significant progress has been made over the past decades in the domain of object detection and instance segmentation (cf. e.g. this review paper ). Applications of object detection methods are today popular also in real-world products: for instance, some cars are already capable of detecting and reading speed limit signs; social media applications integrate photo and video effects based on face and pose detection. All these applications usually rely on deep learning methods, which are the subset of machine learning methods leveraging deep neural networks. While referring the reader to other sources for further information on machine and deep learning methods (cf. e.g. these lecture notes ), we wish to highlight a key point in all these approaches based on learning: no rigid, static, human-engineered rule is given to the machine to accomplish the task. Instead, the machine is provided with a collection of input-output pairs, where the output represents the outcome of a properly solved task. As far as object detection is concerned, we provide deep learning algorithms with a set of images accompanied by reference annotations (\"ground truth labels\"), which the machine is expected to reproduce. Clearly, things become interesting when the machine learns how to generate acceptable detections/segmentation on previously unseen images; such a crucial ability is referred to as \"generalization\". A generic framework was developed within the STDL, allowing the usage of state-of-the-art machine learning methods to detect objects in aerial images. Such framework allows one to leverage aerial images e.g. to provide valuable hints towards the update of cadastral information. At least as far as Switzerland is concerned, high-resolution (< 30 cm Ground Sample Distance) are acquired at the cantonal and federal scales on a regular basis. An inventory of the STDL's applications will be provided at the end of this article. The STDL's object detection framework is powered at its core by Detectron2 , a Python library developed by the Facebook Artificial Intelligence Research group and released under the Apache 2.0 open-source license . Detectron2 includes methods to train models performing various tasks, object detection and instance segmentation to name a few. Specific pieces of code were written by the STDL to pre-process data to be input to Detectron2, as well as to post-process outputs and turn them into meaningful information for the projects being developed. More precisely, our developments enable the usage of Detectron2 with georeferenced images and labels. Our workflow goes through the steps described here-below. Workflow \u00b6 1. Tileset generation \u00b6 Typically, aerial coverages are made accessible through Web Services, publicly or privately. While making opaque to the user the server-side tiling and file-based structure, these Web Services can efficiently generate raster images on-demand depending on the parameters sent by the requesting client. These parameters include: the bounding box of the requested area; the image width and height (in pixels); the reference system of both the bounding box (input) and the requested image (output). GIS tools such as QGIS and ArcGIS Pro as well as Web Applications powered by Web Mapping clients such as Leaflet , OpenLayers , MapLibre GL , etc. actually rely on this mechanism to let end-users navigating through tons of bits in quite a seamless, fluent, reactive way. As a matter of fact, zooming in and out in such 2D scenes amounts to fetching and visualizing different images depending on the zoom level, instead of \"simply\" increasing/decreasing the size of the various image pixels as displayed on screen. Through this 1st step of our workflow, several requests are issued against a Web Service in order to generate a consistent set of tiled images (\"tileset\") covering the so-called \" area of interest \" (AoI), namely the area over which the user intend to train a detection model and/or to perform the actual object detection. Connectors for the following two Web Services have been developed so far: OGC's Web Mapping Service (WMS) ; ESRI's Map Image Layer . XYZ link Except when using the XYZ connector that requires the EPSG:3857, our framework is agnostic with respect to the tiling scheme. The user has to provide as a input file compliant with some requirements. We refer the user to the code documentation for detailed information about these requirements. Concerning the AoI and its extension, the following scenarios are supported: training-only scenarios, i.e. the user intends to train a model to be used for detection at a later stage. In this case, the AoI would only cover the area for which reference, ground truth data exist. Detection-only (or \"inference-only\") scenarios, in which the user wishes to carry out object detection leveraging a previously trained model. In this case, the AoI would cover areas for which no reference data is available. Training AND detection scenarios, namely the composition of tasks 1 and 2. In the case of scenarios no. 1 and 3, ground truth labels are necessary. Provided by the user as polygons in some geographic coordinate system, the spatial coordinates of the vertices of these polygons must be mapped onto each image coordinate system - the latter ranging from (0, 0) to (<image width in pixels> - 1, <image height in pixels> - 1) - in order to generate reference, ground truth instance segmentations. Technically, such a mapping can be achieved through an affine transformation . Labels can optionally be provided in the case of inference-only scenarios as well, should the user be willing to check non-ground truth labels against detections and vice-versa. At least two somewhat \"standard\" data formats exist, which allow one to formalize the link between images and instance segmentations (cf. e.g. this article for further information): Pascal VOC, COCO . Since Detectron2 natively supports the latter but not the former, we made the obvious choice to opt for the COCO format. As mentioned above, machine learning models are valuable as far as they do not \"overfit\" to the training data; in other words, as far as they generalize well to new, unseen data. One of the techniques which are commonly used in order to prevent machine learning algorithms from overfitting is the \"train, validation, test split\". While referring the interested reader to this Wikipedia page for further details, let us note that a 70%-15%-15% split is currently hard-coded in our framework. Various independent COCO tilesets are generated, depending on the scenario: in training-only scenarios, three COCO tilesets are generated: training tileset, abbreviated as trn ; validation tileset ( val ); test tileset ( tst ). For now, training, validation and test tiles are chosen exclusively among the tiles of the AoI including one or more ground truth labels. Having realized that some of our models tend to produce false detections, we will shortly improve our framework in order to allow for unlabeled tiles within the training, validation, test tilesets. In inference-only scenarios, a single COCO tileset labeled as \"other\" is generated ( oth is the abbreviation we use). In training + inference scenarios, the full collection of tilesets is generated: trn , val , tst , oth . 2. Model training \u00b6 The 1st step provides a collection of consistent ( i.e. same size and resolution) tiled images and corresponding COCO files ( trn + val + tst and/or oth depending on the scenario). The 2nd step consists in training a prediction model by iterating over the training dataset, as customarily done in machine and deep learning. As already mentioned, we delegate this crucial part of the process to the Detectron2 library; support for other libraries may be implemented in the future, if suitable. Detectron2 comes with a large collection of pre-trained models tailored for various tasks. In particular, as far as instance segmentation is concerned, pre-trained models can be selected from this list . In our workflow, we setup Detectron2 in such a way that inference is made on the validation dataset every N training iterations, being N a user-defined parameter. By doing this, we can monitor both the training and validation losses all along the iterative learning and decide when to stop. Typically, learning is stopped when the validation loss reaches a minimum (cf. e.g. this article for further information on early stopping). As training and validation loss curves are somewhat noisy, typically an on-the-fly smoothing is applied in order to reveal steady trends. Other metrics may be tracked and used to decide when to stop. For now, within our framework (early) stopping can be done manually and is left to the user; it will be made automatic in the future, following some suitable criterion. Training and validation losses in a sample object detection task. In this case, one could stop the training after the first ~1400 iterations. Note that, in this example, the validation loss is evaluated every 200 iterations. Let us note that the learning process is regulated by several parameters, which are usually called \"hyper-parameters\" in order to distinguish them from the learned \"parameters\", the latter being - in our deep learning context - the coefficients of the many neurons populating the various layers of the deep neural network. In successful scenarios, the iterative learning process does actually lower the validation loss until a minimum value is reached. Yet, such a minimum is likely to be a \"local\" one ( i.e. relative to a given set of hyper-parameters); indeed, the global minimum may be found along a different trajectory, corresponding to a different set of hyper-parameters. Actually, even finding the global minimum of the validation loss could be not as relevant as checking how different models resulting from different choices of the hyper-parameters compare with each other on the common ground of more meaningful \"business metrics\". Even though currently our code does not implement any automatic hyper-parameter tuning, neither in terms of expert metrics nor in terms of business ones, we have already setup everything that is needed to produce business metrics, as explained here-below. 3. Detection \u00b6 The model trained at the preceding step can be used to perform the actual object detection or instance segmentation over the various tilesets concerned by a given study: in training-only scenarios, detections can be made on the training, validation and test sets, for model assessment purposes (cf. next section); in inference-only scenarios, detections can be made over the tileset which we call \"other\", for now. Depending on the configuration, Detectron2 is capable to perform either object detection AND instance segmentation at once, or object detection only. In both cases, every detection is accompanied by the following information: the class the detected object belongs to; a confidence score, ranging from 0 to 1. In the case of object detection only, a bounding box is output as a list of vertices relative to the image coordinate system. In case instance segmentation is demanded, detections are also output under the form of binary (\"monochromatic\") masks, one per input tile/image, in which pixels belonging to target objects are encoded with ones whereas background pixels are encoded with zeros. Detectron2 output is then converted into a georeferenced vector. Polygon geometry can be simplified using the Ramer-Douglas-Peucker algorithm (RDP) by tuning the epsilon parameter. 4. Assessment \u00b6 The results are evaluated by matching the detections and the ground truth labels, i.e. by finding detections overlapping with ground truth labels. To be considered a match, the intersection over union (IoU) between the detection polygon and label polygon must be greater than a threshold set by the user, with a default value = 0.25. In addition, if there are intersections between several detections and ground truth labels, only the pair with the largest IoU is considered to be a valid match. Intersection over union between a label and a detection is defined as: \\(\\mbox{IoU} = \\frac{A_{label \\cap detection}}{A_{label \\cup detection}}\\) The spatial intersection between the vectorized detections and the ground truth labels is computed to tag detections according to the following classification: true positive (TP): detections matching correctly a ground truth object; false positive (FP): detections not matching any ground truth object; false negative (FN): missing detections, namely objects of the ground truth which are not detected; wrong class: detections matching a ground truth object of another class. The reader may wonder why there are no true negatives (TN) in the list. Actually, all the image pixels which are rightly not associated with the target class can be considered as \"true negatives\". Yet, as far as object detection and instance segmentation are concerned, we do not need to group leftover pixels into some sort of \"dummy objects\". Should the user need to model such a scenario, one idea might consist in introducing a dummy class ( e.g. \"background\" or \"other\"), to which all the (ir)relevant pixels would be associated. The metrics are calculated per-class to take into account possible imbalances between classes. The detections in the wrong class will be classified as FN, i.e. missed object, or false positive (FP), i.e. detections not matching any object, depending on the target class we are calculating for. Precision and recall by class are used here: \\(\\mbox{precision}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FP}_{class}}\\) \\(\\mbox{recall}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FN}_{class}}\\) While referring the reader to this page for further information on these metrics, let us note that: Precision is optimal when it equals one, i.e. when the count of FPs is equal to zero. This metric measures how good the model is in detecting only objects with the class of interest; Recall is optimal when it equals one, i.e. when the count of FNs is equal to zero. This metric measures how good the model is in detecting all objects of the class of interest without missing any. Each metric can be aggregated to keep only one value per dataset, rather than one per class. \\(\\mbox{precision} = \\frac{\\sum_{class}\\mbox{precision}_{class}}{\\mbox{nbr of classes}}\\) \\(\\mbox{recall} = \\frac{\\sum_{class}\\mbox{recall}_{class}}{\\mbox{nbr of classes}}\\) As already mentioned, each detection is assigned a confidence score, ranging from 0 to 1. By filtering out all the detections exhibiting a score smaller than some cut-off/threshold value, one would end up having more or less detections to compare against ground truth data; the higher the threshold, the smaller the number of detections, the better their quality in terms of the confidence score. Sampling the threshold from a minimal user-defined value to a maximum value ( e.g. 0.95) and counting TPs, FPs, FNs at each sampling step, meaningful curves can be obtained representing counts and/or metrics like precision and recall as a function of the threshold. Typically, precision (recall) is monotonically increasing (decreasing) as a function of the threshold. As such, neither the precision nor the recall can be used to determine the optimal value of the threshold, which is why precision and recall are customarily aggregated in order to form a third metric which can be convex if computed as a function of the threshold or, at least, it can exhibit local minima. This metric is named \" \\(F_1\\) score\" and is defined as follows: \\(F_1 = 2\\times \\frac{\\mbox{precision}\\;\\times\\;\\mbox{recall}}{\\mbox{precision}\\; +\\; \\mbox{recall}}\\) Different models can then be compared with each other in terms of \\(F_1\\) scores; the best model can be selected as the one exhibiting the maximum \\(F_1\\) over the validation dataset. At last, the test dataset can be used to assess the selected model and provide the end-user with an objective figures concerning its reliability. Other approaches exist, allowing one to summarize metrics and eventually come up with threshold-independent scores. One of these approaches consist in computing the \"Area Under the ROC curve\" (AUC, cf. this page ) and will be soon implemented by the STDL. 5. Iterate until results are satisfactory \u00b6 Several training sessions can be executed, using different values of the various hyper-parameters involved in the process. As a matter of fact, reviewing and improving ground truth data is also part of the hyper-parameter tuning (cf. \" From Model-centric to Data-centric Artificial Intelligence ''). Keeping track of the above-mentioned metrics across multiple realizations, eventually an optimal model should be found (at least, a local optimum). The exploration of the hyper-parameter space is a tedious task, which consumes time as well as human and computing resources. It can be performed in a more or less systematic/heuristic way, depending on the experience of the operator as well as on the features offered by the code. Typically, a partial exploration is enough to obtain acceptable results. Within the STDL team, it is customary to first perform some iterations until \"decent scores\" are obtained, then to involve beneficiaries and domain experts in the continuous evaluation and improvement of results, until satisfactory results are obtained. These exchanges between data scientists and domain experts are also key to raise both communities' awareness of the virtues and flaws of machine learning approaches. Use cases \u00b6 Here is a list of the successful applications of the object detection framework described in this article: Automatic detection of quarries Swimming Pool Detection for the Canton of Geneva Swimming Pool Detection for the Canton of Thurgau Classification of road surfaces Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau Concluding remarks \u00b6 The STDL's object detection framework is still under development and receives updates as new use cases are tackled.","title":"<span style=\"text-transform:uppercase;\"> Object Detection Framework </span>"},{"location":"TASK-IDET/#object-detection-framework","text":"Alessandro Cerioni, Etat de Geneve - Cl\u00e9mence Herny, Exolabs - Adrian F. Meyer, FHNW - Gwena\u00eblle Salamin, Exolabs Published on November 22, 2021 Updated on December 12, 2023 Abstract : The STDL develops a framework allowing users to train and use deep learning models to detect objects in aerial images. While relying on a generic-purpose third-party open-source library, the STDL's framework implements a somewhat opinionated workflow, targeting georeferenced aerial images and labels. After a brief introduction to object detection, this article provides detailed information on the STDL's object detection framework and the opinions it implements. References to successful applications are provided along with concluding remarks.","title":" Object Detection Framework "},{"location":"TASK-IDET/#introduction","text":"Object detection is a computer vision task which aims at detecting instances of objects of some target classes ( e.g. buildings, swimming pools, solar panels, ...) in digital images and videos. According to the commonly adopted terminology, a distinction is made between the following tasks: object detection , in which the goal is to determine the rectangular \"bounding box\" surrounding each detected object; instance segmentation , in which one aims at finding the pixels belonging to each detected object. This distinction is well illustrated by the bottom half of the following image: Object Detection vs Instance Segmentation. Image credit: Waleed Abdulla . Significant progress has been made over the past decades in the domain of object detection and instance segmentation (cf. e.g. this review paper ). Applications of object detection methods are today popular also in real-world products: for instance, some cars are already capable of detecting and reading speed limit signs; social media applications integrate photo and video effects based on face and pose detection. All these applications usually rely on deep learning methods, which are the subset of machine learning methods leveraging deep neural networks. While referring the reader to other sources for further information on machine and deep learning methods (cf. e.g. these lecture notes ), we wish to highlight a key point in all these approaches based on learning: no rigid, static, human-engineered rule is given to the machine to accomplish the task. Instead, the machine is provided with a collection of input-output pairs, where the output represents the outcome of a properly solved task. As far as object detection is concerned, we provide deep learning algorithms with a set of images accompanied by reference annotations (\"ground truth labels\"), which the machine is expected to reproduce. Clearly, things become interesting when the machine learns how to generate acceptable detections/segmentation on previously unseen images; such a crucial ability is referred to as \"generalization\". A generic framework was developed within the STDL, allowing the usage of state-of-the-art machine learning methods to detect objects in aerial images. Such framework allows one to leverage aerial images e.g. to provide valuable hints towards the update of cadastral information. At least as far as Switzerland is concerned, high-resolution (< 30 cm Ground Sample Distance) are acquired at the cantonal and federal scales on a regular basis. An inventory of the STDL's applications will be provided at the end of this article. The STDL's object detection framework is powered at its core by Detectron2 , a Python library developed by the Facebook Artificial Intelligence Research group and released under the Apache 2.0 open-source license . Detectron2 includes methods to train models performing various tasks, object detection and instance segmentation to name a few. Specific pieces of code were written by the STDL to pre-process data to be input to Detectron2, as well as to post-process outputs and turn them into meaningful information for the projects being developed. More precisely, our developments enable the usage of Detectron2 with georeferenced images and labels. Our workflow goes through the steps described here-below.","title":"Introduction"},{"location":"TASK-IDET/#workflow","text":"","title":"Workflow"},{"location":"TASK-IDET/#1-tileset-generation","text":"Typically, aerial coverages are made accessible through Web Services, publicly or privately. While making opaque to the user the server-side tiling and file-based structure, these Web Services can efficiently generate raster images on-demand depending on the parameters sent by the requesting client. These parameters include: the bounding box of the requested area; the image width and height (in pixels); the reference system of both the bounding box (input) and the requested image (output). GIS tools such as QGIS and ArcGIS Pro as well as Web Applications powered by Web Mapping clients such as Leaflet , OpenLayers , MapLibre GL , etc. actually rely on this mechanism to let end-users navigating through tons of bits in quite a seamless, fluent, reactive way. As a matter of fact, zooming in and out in such 2D scenes amounts to fetching and visualizing different images depending on the zoom level, instead of \"simply\" increasing/decreasing the size of the various image pixels as displayed on screen. Through this 1st step of our workflow, several requests are issued against a Web Service in order to generate a consistent set of tiled images (\"tileset\") covering the so-called \" area of interest \" (AoI), namely the area over which the user intend to train a detection model and/or to perform the actual object detection. Connectors for the following two Web Services have been developed so far: OGC's Web Mapping Service (WMS) ; ESRI's Map Image Layer . XYZ link Except when using the XYZ connector that requires the EPSG:3857, our framework is agnostic with respect to the tiling scheme. The user has to provide as a input file compliant with some requirements. We refer the user to the code documentation for detailed information about these requirements. Concerning the AoI and its extension, the following scenarios are supported: training-only scenarios, i.e. the user intends to train a model to be used for detection at a later stage. In this case, the AoI would only cover the area for which reference, ground truth data exist. Detection-only (or \"inference-only\") scenarios, in which the user wishes to carry out object detection leveraging a previously trained model. In this case, the AoI would cover areas for which no reference data is available. Training AND detection scenarios, namely the composition of tasks 1 and 2. In the case of scenarios no. 1 and 3, ground truth labels are necessary. Provided by the user as polygons in some geographic coordinate system, the spatial coordinates of the vertices of these polygons must be mapped onto each image coordinate system - the latter ranging from (0, 0) to (<image width in pixels> - 1, <image height in pixels> - 1) - in order to generate reference, ground truth instance segmentations. Technically, such a mapping can be achieved through an affine transformation . Labels can optionally be provided in the case of inference-only scenarios as well, should the user be willing to check non-ground truth labels against detections and vice-versa. At least two somewhat \"standard\" data formats exist, which allow one to formalize the link between images and instance segmentations (cf. e.g. this article for further information): Pascal VOC, COCO . Since Detectron2 natively supports the latter but not the former, we made the obvious choice to opt for the COCO format. As mentioned above, machine learning models are valuable as far as they do not \"overfit\" to the training data; in other words, as far as they generalize well to new, unseen data. One of the techniques which are commonly used in order to prevent machine learning algorithms from overfitting is the \"train, validation, test split\". While referring the interested reader to this Wikipedia page for further details, let us note that a 70%-15%-15% split is currently hard-coded in our framework. Various independent COCO tilesets are generated, depending on the scenario: in training-only scenarios, three COCO tilesets are generated: training tileset, abbreviated as trn ; validation tileset ( val ); test tileset ( tst ). For now, training, validation and test tiles are chosen exclusively among the tiles of the AoI including one or more ground truth labels. Having realized that some of our models tend to produce false detections, we will shortly improve our framework in order to allow for unlabeled tiles within the training, validation, test tilesets. In inference-only scenarios, a single COCO tileset labeled as \"other\" is generated ( oth is the abbreviation we use). In training + inference scenarios, the full collection of tilesets is generated: trn , val , tst , oth .","title":"1. Tileset generation"},{"location":"TASK-IDET/#2-model-training","text":"The 1st step provides a collection of consistent ( i.e. same size and resolution) tiled images and corresponding COCO files ( trn + val + tst and/or oth depending on the scenario). The 2nd step consists in training a prediction model by iterating over the training dataset, as customarily done in machine and deep learning. As already mentioned, we delegate this crucial part of the process to the Detectron2 library; support for other libraries may be implemented in the future, if suitable. Detectron2 comes with a large collection of pre-trained models tailored for various tasks. In particular, as far as instance segmentation is concerned, pre-trained models can be selected from this list . In our workflow, we setup Detectron2 in such a way that inference is made on the validation dataset every N training iterations, being N a user-defined parameter. By doing this, we can monitor both the training and validation losses all along the iterative learning and decide when to stop. Typically, learning is stopped when the validation loss reaches a minimum (cf. e.g. this article for further information on early stopping). As training and validation loss curves are somewhat noisy, typically an on-the-fly smoothing is applied in order to reveal steady trends. Other metrics may be tracked and used to decide when to stop. For now, within our framework (early) stopping can be done manually and is left to the user; it will be made automatic in the future, following some suitable criterion. Training and validation losses in a sample object detection task. In this case, one could stop the training after the first ~1400 iterations. Note that, in this example, the validation loss is evaluated every 200 iterations. Let us note that the learning process is regulated by several parameters, which are usually called \"hyper-parameters\" in order to distinguish them from the learned \"parameters\", the latter being - in our deep learning context - the coefficients of the many neurons populating the various layers of the deep neural network. In successful scenarios, the iterative learning process does actually lower the validation loss until a minimum value is reached. Yet, such a minimum is likely to be a \"local\" one ( i.e. relative to a given set of hyper-parameters); indeed, the global minimum may be found along a different trajectory, corresponding to a different set of hyper-parameters. Actually, even finding the global minimum of the validation loss could be not as relevant as checking how different models resulting from different choices of the hyper-parameters compare with each other on the common ground of more meaningful \"business metrics\". Even though currently our code does not implement any automatic hyper-parameter tuning, neither in terms of expert metrics nor in terms of business ones, we have already setup everything that is needed to produce business metrics, as explained here-below.","title":"2. Model training"},{"location":"TASK-IDET/#3-detection","text":"The model trained at the preceding step can be used to perform the actual object detection or instance segmentation over the various tilesets concerned by a given study: in training-only scenarios, detections can be made on the training, validation and test sets, for model assessment purposes (cf. next section); in inference-only scenarios, detections can be made over the tileset which we call \"other\", for now. Depending on the configuration, Detectron2 is capable to perform either object detection AND instance segmentation at once, or object detection only. In both cases, every detection is accompanied by the following information: the class the detected object belongs to; a confidence score, ranging from 0 to 1. In the case of object detection only, a bounding box is output as a list of vertices relative to the image coordinate system. In case instance segmentation is demanded, detections are also output under the form of binary (\"monochromatic\") masks, one per input tile/image, in which pixels belonging to target objects are encoded with ones whereas background pixels are encoded with zeros. Detectron2 output is then converted into a georeferenced vector. Polygon geometry can be simplified using the Ramer-Douglas-Peucker algorithm (RDP) by tuning the epsilon parameter.","title":"3. Detection"},{"location":"TASK-IDET/#4-assessment","text":"The results are evaluated by matching the detections and the ground truth labels, i.e. by finding detections overlapping with ground truth labels. To be considered a match, the intersection over union (IoU) between the detection polygon and label polygon must be greater than a threshold set by the user, with a default value = 0.25. In addition, if there are intersections between several detections and ground truth labels, only the pair with the largest IoU is considered to be a valid match. Intersection over union between a label and a detection is defined as: \\(\\mbox{IoU} = \\frac{A_{label \\cap detection}}{A_{label \\cup detection}}\\) The spatial intersection between the vectorized detections and the ground truth labels is computed to tag detections according to the following classification: true positive (TP): detections matching correctly a ground truth object; false positive (FP): detections not matching any ground truth object; false negative (FN): missing detections, namely objects of the ground truth which are not detected; wrong class: detections matching a ground truth object of another class. The reader may wonder why there are no true negatives (TN) in the list. Actually, all the image pixels which are rightly not associated with the target class can be considered as \"true negatives\". Yet, as far as object detection and instance segmentation are concerned, we do not need to group leftover pixels into some sort of \"dummy objects\". Should the user need to model such a scenario, one idea might consist in introducing a dummy class ( e.g. \"background\" or \"other\"), to which all the (ir)relevant pixels would be associated. The metrics are calculated per-class to take into account possible imbalances between classes. The detections in the wrong class will be classified as FN, i.e. missed object, or false positive (FP), i.e. detections not matching any object, depending on the target class we are calculating for. Precision and recall by class are used here: \\(\\mbox{precision}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FP}_{class}}\\) \\(\\mbox{recall}_{class} = \\frac{\\mbox{TP}_{class}}{\\mbox{TP}_{class} + \\mbox{FN}_{class}}\\) While referring the reader to this page for further information on these metrics, let us note that: Precision is optimal when it equals one, i.e. when the count of FPs is equal to zero. This metric measures how good the model is in detecting only objects with the class of interest; Recall is optimal when it equals one, i.e. when the count of FNs is equal to zero. This metric measures how good the model is in detecting all objects of the class of interest without missing any. Each metric can be aggregated to keep only one value per dataset, rather than one per class. \\(\\mbox{precision} = \\frac{\\sum_{class}\\mbox{precision}_{class}}{\\mbox{nbr of classes}}\\) \\(\\mbox{recall} = \\frac{\\sum_{class}\\mbox{recall}_{class}}{\\mbox{nbr of classes}}\\) As already mentioned, each detection is assigned a confidence score, ranging from 0 to 1. By filtering out all the detections exhibiting a score smaller than some cut-off/threshold value, one would end up having more or less detections to compare against ground truth data; the higher the threshold, the smaller the number of detections, the better their quality in terms of the confidence score. Sampling the threshold from a minimal user-defined value to a maximum value ( e.g. 0.95) and counting TPs, FPs, FNs at each sampling step, meaningful curves can be obtained representing counts and/or metrics like precision and recall as a function of the threshold. Typically, precision (recall) is monotonically increasing (decreasing) as a function of the threshold. As such, neither the precision nor the recall can be used to determine the optimal value of the threshold, which is why precision and recall are customarily aggregated in order to form a third metric which can be convex if computed as a function of the threshold or, at least, it can exhibit local minima. This metric is named \" \\(F_1\\) score\" and is defined as follows: \\(F_1 = 2\\times \\frac{\\mbox{precision}\\;\\times\\;\\mbox{recall}}{\\mbox{precision}\\; +\\; \\mbox{recall}}\\) Different models can then be compared with each other in terms of \\(F_1\\) scores; the best model can be selected as the one exhibiting the maximum \\(F_1\\) over the validation dataset. At last, the test dataset can be used to assess the selected model and provide the end-user with an objective figures concerning its reliability. Other approaches exist, allowing one to summarize metrics and eventually come up with threshold-independent scores. One of these approaches consist in computing the \"Area Under the ROC curve\" (AUC, cf. this page ) and will be soon implemented by the STDL.","title":"4. Assessment"},{"location":"TASK-IDET/#5-iterate-until-results-are-satisfactory","text":"Several training sessions can be executed, using different values of the various hyper-parameters involved in the process. As a matter of fact, reviewing and improving ground truth data is also part of the hyper-parameter tuning (cf. \" From Model-centric to Data-centric Artificial Intelligence ''). Keeping track of the above-mentioned metrics across multiple realizations, eventually an optimal model should be found (at least, a local optimum). The exploration of the hyper-parameter space is a tedious task, which consumes time as well as human and computing resources. It can be performed in a more or less systematic/heuristic way, depending on the experience of the operator as well as on the features offered by the code. Typically, a partial exploration is enough to obtain acceptable results. Within the STDL team, it is customary to first perform some iterations until \"decent scores\" are obtained, then to involve beneficiaries and domain experts in the continuous evaluation and improvement of results, until satisfactory results are obtained. These exchanges between data scientists and domain experts are also key to raise both communities' awareness of the virtues and flaws of machine learning approaches.","title":"5. Iterate until results are satisfactory"},{"location":"TASK-IDET/#use-cases","text":"Here is a list of the successful applications of the object detection framework described in this article: Automatic detection of quarries Swimming Pool Detection for the Canton of Geneva Swimming Pool Detection for the Canton of Thurgau Classification of road surfaces Updating the \u00abCultivable Area\u00bb Layer of the Agricultural Office, Canton of Thurgau","title":"Use cases"},{"location":"TASK-IDET/#concluding-remarks","text":"The STDL's object detection framework is still under development and receives updates as new use cases are tackled.","title":"Concluding remarks"}]}
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
index 22e882a..c79e2dc 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,82 +2,82 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
     <url>
          <loc>None</loc>
-         <lastmod>2024-02-02</lastmod>
+         <lastmod>2024-02-26</lastmod>
          <changefreq>daily</changefreq>
     </url>
 </urlset>
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 93817c8..31d8dd2 100644
Binary files a/sitemap.xml.gz and b/sitemap.xml.gz differ