dataesr/scientific-paragraphs-categorization huggingface dataset:
PixBox S2 reference dataset Not all algorithms processed all 29 products of the PixBox S2 dataset; the reasons for this were limitations of allowed geometries (ATCOR, processed) or too sparse time-series around the acquisition (MAJA, processed). In order to account for the difference of available products for validation, two different comparisons were made: one using all available products for each algorithm and a second using only the products that all algorithms have been applied to (14 out of 29 reference scenes). We call the second dataset the least common denominator (LCD) subset, while the first is referred to as the "complete dataset". The whole comparison could have been made only on the LCD subset, but this reduces the complete dataset by half, which reduces its utility. Therefore, the complete dataset also was used for comparison.
In this comparison using the complete dataset, results for MAJA must be assessed with caution, as they are only based on 14 out of 29 products. Algorithm performance for the complete PixBox dataset is provided in Table  9  and Fig. 12. For all types of clouds, BOA varied from 67. 5% to 85. 9% (average 80. 0 ± 5. 3%). The top two algorithms (S2cloudless and MAJA) showed a similar performance in terms of BOA; however, the tradeoff between PA and UA varied substantially for those algorithms: S2cloudless yielded PA = 80. 2% and UA = 89. 5% (more cloud omissions than commissions) and MAJA yielded PA = 88. 6% and UA = 80. 2% (less cloud omissions and more commissions, in part due to the dilation). When thin/semi-transparent clouds were not considered, all algorithms showed a better performance with an average gain in BOA of +5.
Also, algorithms performance  In bold are the numbers with the highest value for the particular metric (column-wise). improved when thin clouds and snow were excluded from the analysis. Fig. 13  shows an example of cloud detection over the Sentinel-2 scene from the PixBox dataset. The scene features opaque clouds as well as semi-transparent clouds over the water. All algorithms were successful in identifying opaque clouds, while majority struggled to identify semi-transparent over the water. Fig. 14  shows performance of algorithms on clear pixels depending on the major land cover classes (proportion > 4%) from the PixBox S2 data. LaSRC, IdePix and FORCE showed the worst performance for the clear snow pixels, which was expected given limitations of these algorithms. Excluding snow, overall performance of algorithms was uniform throughout the land clover classes.
L8Biome reference dataset Table  12  provides a summary of performance metrics for the L8Biome dataset. Results in this table should not be used directly for intercomparing algorithms for the following reasons: (i) ATCOR processed only 86 images out of 96 images, since images in polar regions were removed due to Sun elevation lower than 20 • ; (ii) LaSRC processed 80 images, since snow/ice scenes were not considered; (iii) all algorithms, except ATCOR, had on average 2. 4% pixels not classified-those pixels are on the boundary of the Landsat 8 scene, and do not have valid values for all spectral bands. In addition, since CD-FCNN was trained on the L8Biome and the L8SPARCS datasets (80% and 20%, respectively), the CD-FCNN results on this dataset are omitted in order to avoid overoptimistic (overfitted) detection results.
Fmask partially used L8Biome data to find optimal thresholds for some of the rules, namely weight of cirrus cloud probability, spectral-contextual snow index, and morphology-based post-processing  (Qiu et al. , 2019; personal communication, Zhe Zhu and Shi Qiu, University of Connecticut, November 2021). Since the foundation of the Fmask algorithm was developed well before the L8Biome dataset release, we still included Fmask 4. 0 for the inter-comparison, though with caveats. Table  13  provides a correct intercomparison between algorithms since the amount of reference scenes and pixels used was the same. The average BOA was 90. 0 ± 1. 4% and 91. 5 ± 1. 8% for all types of clouds and without thin clouds, respectively. Removing thin clouds from the reference increases BOA and Cloud-PA accuracies by +1.
PixBox L8 reference dataset Table  14  shows the algorithm performance for the PixBox dataset. Fmask and ATCOR yielded the best performance in terms of BOA (87. 9% and 86. 3%, respectively), however PA/UA values exhibited a different behavior: for Fmask, PA and UA were mostly balanced (82. 5% and 81. 8%), while for ATCOR omission error (26. 7%) was much higher than commission error (2. 8%). Overall, performance over the PixBox dataset was lower than for L8Biome and GSFC, as the case with PixBox S2. Performance metrics substantially improved when semi-transparent clouds were removed from the analysis. For all algorithms cloud PA increased on average by 28. 1 ± 13. 9% reaching 95. 9 ± 3. 6%. While there was an overall agreement between algorithms on detecting opaque clouds from the PixBox L8 dataset (with average PA 95.
Four algorithms (ATCOR, CD-FCNN, InterSSIM and Sen2Cor) yielded performance with cloud UA > 90% (cloud conservative), meaning these algorithms committed less clouds over clear regions, however at the expense of missing clouds. LaSRC yielded the cloud PA > 90% performance (non-cloud conservative), detecting most of the clouds, however, at the expense of masking out also valid non-cloudy observations, and with a large standard deviation in UA across the datasets (potentially, owing to various rules defining the cloud and the use of conservative threshold for the cirrus band). Since only three datasets were used for Landsat 8, we did not perform the averaging (Fig. 18 ). Three distinct clusters corresponding to the three reference datasets were evident with varying performance. The highest performance was for the GSFC dataset with only six Landsat 8 scenes over the same area, which probably is not fully representative of the performance of the algorithms.
Dependence of the performance on the reference datasets Performance of cloud masking algorithms for Sentinel-2 varied depending on the reference dataset (Fig. 19 ): average BOA was 80. 0 ± 5. 3% (PixBox) to 89. 4 ± 2. 4%  (Hollstein). Performance of algorithms was the worst for the PixBox dataset compared to datasets. This can be explained by the following. PixBox dataset was sampled in such a way, so non-challenging (e. g. , opaque thick clouds) and challenging (e. g. , semi-transparent clouds, cloud boundaries) cases are equally present in the dataset. At the same time, other datasets were aimed at labelling the full images (L8Biome, CESBIO) or provide homogeneous polygons  (Hollstein, GSFC) , where the weight of challenging cases would be lower than for PixBox. In this regard, the question is about whether to weight samples according to the area or not.
Both characteristics (based on equal allocation and area proportions) can be valuable to describe separability of classes by a given algorithm (model accuracy) and to estimate probability of a pixel being mapped correctly (map accuracy)  (Blickensdörfer et al. , 2022; Congalton, 1991). Across the four reference datasets algorithms showed better performance in terms of cloud UA, which was consistently higher than cloud PA. Removing thin/semi-transparent clouds from the reference datasets improves performance of algorithms (Fig. 20 ), though at the expense of cloud UA. This happens because thin clouds have higher uncertainties and therefore are more challenging to the algorithms in contrast to thick clouds. When thin clouds removed from reference datasets the proportion of correctly detected classes increases and therefore cloud PA increases.
At the same time, cloud UA can experience both increase or decrease depending on the proportion of thin clouds and algorithm's performance on thin clouds. The issue of thin/semi-transparent cloud detection has a significant impact on the subsequent shadow detection. Fig. 21  shows an example of a cloud with different levels of transparency depending on wavelength used and its shadow. While the cloud is semi-transparent in the false color composite (SWIR-NIR-red), its shadow is clearly visible and impacts the reflectance. Fig. 22  shows averaged BOA values across multiple Landsat 8 algorithms. As with Sentinel-2, the performance varied across datasets yielding BOA of 97. 6 ± 0. 8%, 90. 0 ± 1. 3% and 79. 8 ± 7. 1% for GSFC, L8Biome and PixBox, respectively. As with Sentinel-2, cloud PA was higher than cloud UA for GSFC and PixBox datasets, but not for L8Biome.
In terms of various land cover classes, it is difficult to draw conclusions since only generic "static" information on land cover was available for some of the datasets. We did not observe any substantial differences in algorithm's performance over various land cover classes, except for urban areas in the PixBox S2 data, which is expected. Sentinel-2 does not have a thermal band and, therefore, detection of clouds over bright targets in urban areas remains a challenging task. The use of multispectral parallax  (Gascon et al. , 2017; Skakun et al. , 2017)  only partially addresses this problem  (Frantz et al. , 2018).
Sen2Cor The parameters used to run Sen2Cor version 2. 8 for CMIX were the default parameters used in Sentinel-2 operational ground segment and available in L2A_CAL_SC_GIPP. xml. No cloud mask dilation is applied and cloud boundaries can be omitted. - The first area for improvement should aim at initially providing an agreed upon definition of "cloud"  (Mejia et al. , 2016; Stubenrauch et al. , 2013)  that is passed beforehand to intercomparison participants and validation dataset originators. Ideally this would be an objective (quantitative) definition of clouds, which would include a numerical metric. As results from CMIX-I showed, existing validation datasets varied in how a cloud was defined through mostly photointerpretation, and it influenced the performance of the algorithms. For example, one potential metric to define the cloud would be the cloud optical thickness.
Based on the cloud definition, the second area for improvement would include generation of new reference/validation datasets. The strengths and weaknesses of existing cloud reference datasets were thoroughly analyzed and discussed within this study, and new datasets should substantially address those weaknesses. A special attention should be paid to ensure a balanced statistical distribution of surface and cloud types, as well as the need to cover a wide range of environmental conditions, in order to thoroughly test the performance of the algorithms at global scale. Some of the recommendations include: • Consistently implementing the cloud definition, and adding cloud shadows to the analysis. Recommended practices for labelling clouds should be developed and implemented for new datasets, whether through visual interpretation or ground measurements or ancillary data (e.
g. geostationary satellites). Cloud shadows should be also part of the analysis, since an inaccurate cloud shadow mask can lead to substantial artifacts in the downstream products. • Defining a proper dilation of cloud masks to be applied, taking into account the effect of parallax between spectral bands, smooth variation of clouds at their borders, and adjacency effects. The dilation could then be applied to the reference datasets and to the algorithm results. • Increasing the number of sites collecting ground-based imagery of the sky and use them in coordination with Aeronet measurements. Some limitations of the use of ground-based sky imagery include radiance contrast which could yield better detection of thin clouds; furthermore, the geometrical matching between sky-camera and satellite pixel may introduce some errors, which are related to the cloud height.
• Acquire multiple datasets (time-series) over the same area to analyze consistent errors in cloud detection. This would enable temporal metrics to be exploited when assessing the efficiency of cloud masks. The third set of activities should focus on expanding the analysis framework, which would include: • A sample-based approach versus an area-based approach, when comparing reference cloud mask with a predicted one. The problem with an area-based approach is that more weight would be given to large clouds (which cover the larger area), whereas smaller clouds might have a small impact on the performance metrics. At the same time, sampled-based approaches can also miss some specific land cover features (unless a stratification scheme can be constructed with strata describing those features), and often do not address the boundaries of the clouds or more broadly segmentation aspects.
Area-based approaches are likewise necessary to study the effects of cloud dilation. Therefore, both approaches should be considered. • Temporal analysis of cloud masks over the same area. Originally planned for CMIX-I, the idea of using temporal metrics was abandoned, since no reference data (except GSFC, which were assisted with sky imagery and Aeronet measurements) was available for these purposes. As undetected clouds add noise on time-series, it is possible to evaluate the noise on time-series and compute the contribution of different cloud masks to this noise. • Application-based approach to cloud validation. One way to analyze efficiency of the cloud/shadow masks is to "validate" them indirectly within the downstream products. An example could include a generic land cover mapping workflow, when the same set of satellite data will be processed by various cloud detection algorithms and used as input to the classification algorithm.
The derived land cover maps will be validated using the same validation data and intercompared. And finally, CMIX-I was limited to Landsat 8 and Sentinel-2 data. Future activities could include adding hyper-spectral data (such as PRISMA or DESIS), coarse resolution data (such as MODIS, VIIRS, Sentinel-3), and commercial very high spatial resolution satellites, such as Planet or hyperspectral sensors.
Conclusion The Cloud Mask Intercomparison eXercise (CMIX) was a communitywide effort to intercompare the state-of-the-art and commonly-used cloud masking algorithms, with a focus on moderate spatial resolution data acquired by Landsat 8 and Sentinel-2 missions. Ten algorithms developed by nine teams from fourteen organizations representing universities, industry and space agencies were evaluated within CMIX using existing cloud reference data. Overall, the performance of algorithms varied depending on the reference dataset, which can be attributed to differences in which reference datasets were generated. Average overall accuracy (across algorithms) varied 80. 0 ± 5. 3% to 89. 4 ± 2. 4% for Sentinel-2, and 79. 8 ± 7. 1% to 97. 6 ± 0. 8% for Landsat 8, depending on the reference dataset. An overall accuracy of 90% yields twice less errors than an overall accuracy of 80%.
The study highlighted algorithms that provided a balance between commission and omission errors, as well as algorithms which are cloud conservative (high UA) and non-cloud (clear) conservative (high PA). With repetitive observations like those of Sentinel-2, it seems reasonable to favor cloud conservative approaches, with maybe the exception of very cloudy regions where every cloud free observation is critical. When thin/semi-transparent clouds were not considered in the reference datasets algorithms' performance generally improved: overall accuracy values increased from +1. 5% to 7. 4%. It should be noted though that these clouds are commonly occurring and are often present in optical imagery. We concluded the paper with recommendations for further activities, which include provision of a quantitative definition for clouds (targeting moderate spatial resolution imagery by Landsat 8 and Sentinel-2), generation of new reference datasets, and expansion of the analysis framework (for example, multi-temporal analysis and applicationdriven validation).
regardless of the sensor, are homogenized and resampled to 30 m overlapping patches of 32 × 32 pixels, which are used for training the networks in a 64-batch size configuration. Models are trained to minimize a pixel-wise binary cross-entropy cost function, between ground truth and predictions, using the Adam stochastic gradient descent optimization algorithm. An initial learning rate of 10 -5 , a weight decay of 5 × 10 -4 and 120 epochs were used to train the final network. The TensorFlow framework was used to implement and train the models on a GPU (average of 800 s/epoch in all configurations). Training and testing details can be found in López-Puigdollers et al. (2021); in addition, the pre-trained model and a Python-implementation of the proposed cloud detection algorithm for Landsat-8 and Sentinel-2 is provided in a public repository (https://github.
Acknowledgment We would like to thank to  Chris Justice  ( University of Maryland ) for helpful comments on an earlier draft of paper and  Gasmine Myers  ( University of Maryland ) for proof-reading the paper. L. G. C. , D. L. P. and G. M. G. ( University of Valencia ) were supported for this work by the  Spanish Ministry of Science and Innovation  (project  PID2019-109026RB-I00 , ERDF) and the  European Social Fund. S. S. , J. C. R. ( University of Maryland ) and E. V. (NASA GSFC) were supported by  NASA  grants  80NSSC19K1592 ,  80NSSC19M0222  and  80NSSC21M0080.
gfz-potsdam. polygons an expert validation 20 m) de/EnMAP/sentinel2_manual _classification_clouds L8Biome Fully classified Manually classified by an expert Training and 4 classes L8 30 m L8: 96 https://doi. org/10. 5066 Landsat 8 scenes validation /F7251GDH PixBox Sample pixels Manually selected and classified by Validation 10 classes S2, L8 S2: 10 m S2: 29 https://zenodo. org/recor an expert L8: 30 m L8: 11 d/5036991 https://zenodo. org/recor d/5040271.
a b s t r a c t Collecting GPS data using mobile devices is essential to understanding human mobility. However, getting this type of data is tricky because of some specific features of mobile operating systems, the high-power consumption of mobile devices, and users' privacy concerns. Therefore, data of this kind are rarely publicly available for scientific purposes, while private companies that own the data are often reluctant to share it. Here we present a large anonymous longitudinal dataset of Activity Point Location (APL) generated from mobile devices' GPS tracking. The GPS data were collected by using the Google Location History (GLH), accessible in the Google Maps application. Our dataset, named AnLo-COV hereafter, includes anonymised data from 338 persons with corresponding socio-demographics over approximately ten years (2012-2022), thus covering pre-and post-COVID periods, and calculates over 2 million weekly-classified APL extracted from approximately 16 million GPS tracking points in Ecuador.
Data format Raw, Filtered, Anonymised Description of data collection We organised an information session to inform details of the project and to explain participants on how we would use it and the treatment we would give to the data. Participants were recruited on a voluntary basis and only adults (age 18 + ) participated in the study. To ensure the privacy of the participants, all data was anonymised, and the original data was destroyed after transformation and processing. Data source location • Institution: Central University of Ecuador The spatial analysis of Activity Point Locations and Human Activity Spaces clarifies the relationships between the built environment/the transport system and travel behaviour in cities. • AnLoCOV is publicly available at Mendeley Data  [1]. We provide algorithms entirely based on open-source frameworks and make them publicly available on GitHub  [2].
The anonymisation technique must enable data access while maintaining people's privacy and keeping the data structure to analyse it efficiently within the original research purpose  [ 22 , 23 ]  despite the undeniable semantic information loss  [24]. Empirical APL data collected on a longitudinal basis are rarely publicly available, mainly because of the costs and difficulty of acquiring data over a long period of time  [25]. AnLoCOV is an open, anonymised, and longitudinal dataset with spatial APLs computed on a weekly basis. This dataset stores information collected using GLH, which, once activated, accumulates GPS data from the mobile device and can be used as a mobility data acquisition tool  [26]. In addition, AnLoCOV considers different restriction levels imposed by the government of Ecuador due to COVID-19 from March 2020, when practically all cities in the world were in lockdowns to reduce mobility and prevent the spread of the disease.
The Ecuadorian emergency operations committee (EOC) periodically analysed the country's health conditions. The lowest level (0) implies no restrictions, i. e. , before COVID-19. The highest level (3) implies total lockdown; only priority public services such as health, food and transport are provided. The intermediate levels (1 and 2) imply vehicular prohibition during certain days of the week, curfew during the nights and capacity control in enclosed or crowded places. These restriction levels are depicted in Fig. 1. and encoded in the datasets (see Data Description section). AnLoCOV encompasses four anonymised datasets distributed in CSV format:  All datasets are publicly available and licensed with the Creative Commons BY 4. 0 license, which allows their use for any purpose (including commercial use) if appropriate credit for the dataset is declared.
First stage: data collection Data is an essential component in the research process. We use the GLH component of the Google Maps platform, an innovative and widely used application, to get location data worldwide. Through GLH, Google Maps collects the device's locations via GPS, Wi-Fi, or mobile Fig. 2. Schematic overview of the data preparation process. The data is first collected in JSON files. Then, it is transformed into a proper format before being processed and anonymised network connections if the GPS is active. The location data coordinates are defined in accordance with the WGS84 coordinate reference system. The device's hardware, operating system version, or use in indoor locations (e. g. tunnels, buildings) can result in location data loss accuracy. However, Macarulla Rodriguez, in his paper  [27]  , demonstrates that this loss of accuracy is not significant, so we can assume that the device was close to a specific location.
Also, a continuous Internet connection, GPS enabled, and frequent use of the Google Maps application to search for routes or move from one place to another improve the location data accuracy. The drawback is that continued use of the device's GPS may result in battery performance problems. Once the GLH is activated in the Google account, Google tracks, when possible, the GPSbased mobility data from the mobile device. Each person can manage their location history status (pause, disable, edit, or delete) in Google Timeline. By default, GLH is disabled in all Google accounts. The last step in this stage is to request the GLH JSON data from Google via the Google Takeout application. This activity was carried out by each participant of the study. Fig. 3  shows an extract of a JSON data file provided by Google.
Second stage: data transformation A JSON file transformation is required to manipulate data computationally. In this paper, we assume the most straightforward possible representation of location data: each observation consists of a timestamp and a location point. We will use three fields of the GLH JSON file to represent data: (1) timestamp (recorded UTC date and time), (2) latitudeE7, and (3) longitudeE7 (recorded WGS84 GPS location coordinates). An algorithm in Python  [28]  will transform the original GLH JSON file into a comma-separated value (CSV) file with three columns (datetime, latitude and longitude). This file is then the input for the AnLoCOV processing stage.