dataesr/scientific-paragraphs-categorization huggingface dataset:
Sentinel-2 images The Theia Land data center 2 provides Sentinel-2 images in surface reflectance. The products are computed using MACCS (Multi-sensor Atmospheric Correction and Cloud Screening), a level 2A processor which detects the clouds and their shadows, and estimates aerosol optical thickness, water vapour and corrects for the atmospheric effects  (Hagolle et al. , 2015). While level 1C processing level could have been used in this study, we chose level 2A products because they include cloud masks that are useful meta-data. Indeed these information suffice to derive a cloud coverage percentage over patches. Figure  2  shows the cloud coverage computed for each location from the number of cloudy pixels among available ones in the temporal dimension. The average cloud coverage over the area is 39.
Patches indexation Figure  8  gives an overview of the dataset creation step. In order to perform the query of samples, i. e. the search of groups of patches that match the properties defined in the acquisitions layout, we use an indexation structure. An R-Tree indexes all available patches. The space partitioning data structure describes the following dimensions: • Cloud coverage (ranging from 0% to 100%) • Time from the reference image of the acquisitions layout • Duration to the closest valid SAR patch • Number of pixels different from the no-data value A Kd-Tree is used to ease the computation of the duration to the closest valid SAR patch. The R-Tree is built for each patches of Sentinel tiles using the acquisition dates provided in the Sentinel images metadata, and the following statistics collected on the Sentinel images patches: • For Sentinel-1 images: the number of valid pixels, • For Sentinel-2 images: the number of valid pixels, and the number of pixels impacted by clouds.
To compute this last, we use the cloud quality mask provided in the Theia product. We note that cloud masks are only used as a single value for each patch, representing the proportion of cloud coverage. We have computed the R-Trees from non-overlapping, 256 × 256 sized patches in all Sentinel tiles. This indexation structure is computed once. After that, any acquisitions layout can be used to query all samples matching the defined properties of the remote sensing acquisitions. One generated sample includes data arrays containing pixels and ancillary data, e. g. acquisition date, for each items of the acquisitions layout. Finally, the samples are restricted in the provided region of interest, to allow the generation of mutually exclusive samples in the geographical domain, i. e. in training, validation and test datasets.
Generation of samples For each network, samples are first extracted in the images from the specific acquisitions layout. We split the samples in three groups: training, validation, and test. We ensure that these three groups are mutually exclusive by randomly selecting their location in the geographical domain, without overlapping patches of distinct groups. We have randomly selected 5% and 15% of the area to form the region of interest for the validation and test datasets, and the other 80% has been used to form training datasets. Since the swath of Sentinel-1 and 2 does overlap in some areas, the samples density is heterogeneous in spatial domain. For this reason, we have limited the number of samples per spatial location in the training and validation datasets, to guarantee that models are trained with the same number of patches at each location.
Protocol We train all networks with their respective datasets presented in section 2. The SSOP and MSOP models are trained over the training dataset detailed in section 4. 3. 1, and evaluated over the test datasets detailed in sections 4. 3. 2 and 4. 4. The MSOP models are trained over the dataset detailed in section 4. 3. 2, and evaluated on the test datasets detailed in sections 4. 3. 2 and 4. 4. We use the ADAM algorithm  (Kingma and Ba, 2014)  to train all networks to minimize the l1 loss. For M SOPunet and SSOPunet, we use a learning rate of lr = 0. 00012, β0 = 0. 9 and β1 = 0. 999, with a batch of size 128 distributed across 4 GPUs. We train the SSOPmer network using the same setup as described by the authors. All experiments are realized on NVIDIA V100 GPUs with 32Gb RAM. We kept the trained models that reach the smallest l1 loss on the validation split.
To assess the performance of each approach, we compute the following metrics between the reconstructed output optical images S2t and the reference cloud-free optical image S2 t over the test datasets: • Peak Signal to Noise Ratio (PSNR): P SN R = 10 × log10( d 2 M SE ) ( 2 ) Where MSE is the Mean Squared Error computed over n patches: M SE = 1 n n S2t -S2 t 2 (3) The higher is the PSNR, the closer are the values of the estimated image to the target image. • Spectral angle (SAM)  (Kruse et al. , 1993) , representing the mean spectral angle between the estimated image and the target image, ranging in [0, π] • The Structural Similarity Index (SSIM)  (Wang et al. , 2004) , measures the similarity in terms of structure, between the estimated image and the target image. The range is [0, 1], and values close to 1 correspond to the best structural similarity between the images.
Comparison of SSOP networks The comparison between SSOP networks is carried out on the test dataset presented in section 4. 3. 1. We first report the metrics obtained with SSOP networks in table 7. It can be noticed that the metrics from the modified network (SSOPunet) are close to the original SSOPmer. SSIM and SAM are slightly better for SSOPmer and MSE and PSNR a bit better for SSOPunet. While this result is not groundbreaking in terms of evaluation metrics, we highlight the huge difference of required overall processing time: to train both networks over the same dataset with the same setup, SSOPunet needs ≈ 30 hours and SSOPmer ≈ 35 days. For this particular reason, we have chosen to perform all other benchmarks only on SSOPunet, since the metrics are quite similar to SSOPmer, but the processing budget far lower and we could ran more experiment at lower cost.
It can be noticed that the SSOPunet+DEM model has the best PSNR, MSE and SAM, but the SSOPmer still has a slightly better SSIM. One explanation could be that in the SSOPmer model, all convolutions are performed in the original resolution, and no downsampling is performed, which might preserve the structural similarity, hence a better SSIM. The lowest metrics are obtained with the SSOP unet,w/oSAR model, which does not use DEM and SAR inputs, showing the benefits of these modalities for the reconstruction. Figure  9  shows images from the test dataset, processed with the different U-Net based SSOP networks. We can visually appreciate the contributions of the input SAR and DEM. It can be noticed the limits of the method with thick clouds in the optical image, especially for the SSOP unet,w/oSAR network that only use the input optical image.
Comparison of SSOP and MSOP networks The comparison of approaches that input one or more cloudy images to reconstruct the optical image at t, is carried out. We compare networks that consume different kind of inputs, i. e. one single (S1, S2) pair for SSOP networks versus three pairs of images for MSOP networks. We recall that, unlike the MSOP networks, t -1 and t + 1 images are not used by the SSOP networks. We compare the networks on the test dataset detailed in section 4. 3. 2, since its acquisitions layout fulfills both MSOP and SSOP models validity domains, in particular the maximum SAR-optical temporal gap at t. Evaluation metrics are reported in table 8. While it can be observed the same outcome in the comparison between SSOP networks, these quality metrics differ a bit from the ones presented in table7, since the evaluated samples are just a subset of this last dataset.
Comparison of deep-learning based approaches and gap-filling In this setup, optical images acquired at t -1 and t + 1 are completely cloud-free, which enables the use of the gap-filling. Also, the optical image acquired at t is completely covered by clouds or clouds shadows, according to the cloud masks, helping toward a fair comparison between the approach that consume the optical image at t (M SOPunet) and the gapfilling. We perform the comparison of MSOP, SSOP models and the gap-filling using the MSOP cld test dataset detailed in table 6, which matches the validity range of all approaches. Table  9  reports the metrics obtained. We can observe that all the metrics are in favor of the MSOP models. Also, in this particular use-case, the gap-filling leads to superior results to the SSOP models.
We can notice that all metrics are largely in favor of the M SOPunet+DEM model, showing the benefit of the multitemporality, the SAR and the DEM modalities. shows reconstructed images from the test dataset. We can notice that the gap-filling fails to retrieve various details in the reconstructed images, like sudden crops changes. Also, the input images cloud masks are not always exact, and the gap-filling might interpolates polluted images, unlike the MSOP models which are capable of removing those clouds. Figure 12.
However, we only have trained all single date based networks using the only the , output reconstructed optical images S2t from M SOPunet+DEM (4), the Gap-filling (  5 ), and the reference image S2 t (6). In violet are circled details in the reconstructed images that the gap-filling fails to retrieve, or artifacts caused by wrong could masks in input images. l1 loss, and future works could investigate other objective formulations. We have carried out the comparison of single date networks and the multitemporal networks over the MSOP test dataset, which represents the nominal operational context of both networks, e. g. using every available input images, cloudy or not. Our results shown that the multitemporal networks lead to superior image reconstruction. We believe that more available input images improves the retrieval of the missing contents of the cloudy optical image at t.
The comparison between the deep learning based networks and the gap-filling is performed over the MSOP cld test dataset, which contains samples where the t optical image patches are covered by clouds at 100%. The gap-filling performs better than the single date network with a significant margin in this particular setup. However, even though the multitemporal network is not primarily designed for this task, it has outperformed the gap-filling. Finally our ablation study shows that the SAR and the SAR+DEM contribute in the optical image reconstruction process in both single date based networks, and multitemporal based networks. For future works, we believe that a further investigation of the SAR signal contribution should be carried out. For instance, it could be interesting to study if feeding geometrical information (e.
SUMMARY AND CONCLUSION In this paper, we sought to provide a comparison of single date based and multitemporal convolutional networks with the traditional deterministic temporal interpolation between two images. We have introduced a framework to generate various datasets to train and evaluate various methods for cloudy optical image reconstruction. Our simple yet convenient method relies on space partitioning data structures indexing the crucial parameters of the remote sensing acquisitions, i. e. how SAR and optical remote sensing images must be acquired in the datasets, in term of cloud coverage, SAR/optical maximum gap, number and type of acquisition, and relative acquisition time. We have built several datasets to train single date based networks and multitemporal networks, and to evaluate the different selected approaches, representing various operational contexts.
We have analyzed the contribution of the different kind of inputs, namely optical, SAR and DEM with an ablation study, showing how the reconstructed image benefits from these modalities. Also, we have shown that, even if the primary design of the multitemporal convolutional network is not focused on image interpolation in temporal domain, it leads to similar even better results than the gap-filling. However, we should interpret our results carefully regarding the ancillary data available for cloud coverage characterization, since our cloud coverage information per patch depends from it, and the bias it can introduce. Finally, we lead our study over a small area that do not represents the various atmospheric conditions all over the earth. With the continuous stream of synchronized SAR and optical acquisitions thanks to the Sentinel constellation, it is expected that future data driven multitemporal models will help to deliver more exploitable data.
We use the Unsplash API  3  for the pictures, allowing keyword-based searches over an image dataset. We use the Pick-A-Mood toolkit (a character-based pictorial scale for reporting and expressing moods) to select the mood, which is a simple yet expressive tool validated in previous studies  [6]. Also, users can browse all visions created by others, as shown in Figure  2. Guessing Game. In this last step, shown in Figure  1 (c), users play games where they guess the mood of a vision created by another user. This step allows people to empathize with each other since users need to try to understand each other visions. It also engages users through game-play.
Implementation The platform's implementation is available on GitHub under the MIT license  4. In the documentation of the README file, we explain the techniques and packages that we used to build the platform, which is separated into two parts: the front-end web client and the back-end server. The front-end is implemented using HTML/CSS/Ja-vaScript and the jQuery library  5. The back-end is implemented using Python (with the Flask 6  web framework and the PostgreSQL database 7  ) and deployed using uWSGI  8  with an Apache Web server  9.
This paper describes the new GNSS data and product services that have been developed within the context of the EPOS (European Plate Observing System) European Research Infrastructure Consortium (ERIC), which is part of the European Strategy Forum on Research Infrastructures. These services, optimized for Solid Earth research applications, endeavour to harmonise, and standardise Global Navigation Satellite System (GNSS) data collection and processing. They have been implemented by the members of the GNSS Data & Products (EPOS-GNSS), one of the Thematic Core Services (TCS) of EPOS with the active support of national and pan-European infrastructures (in particular the Regional Reference Frame Sub-Commission for Europe (EUREF) of the International Association of Geodesy). The optimized use of data from dozens of diverse European GNSS networks, installed not specifically for geodynamic studies, created additional requirements from an organizational and technical point of view, the solutions for which we describe in this article.
During the H2020 EPOS Implementation Phase project that ended in 2019, approximately 5000 GNSS stations with the potential to be included in the EPOS network have been identified (cf. Figure  1 ). However, most of these GNSS stations have been installed for geo-referencing applications (mainly surveying) and only about 350 of them were providing open access to their data in a coordinated way through the EUREF Permanent GNSS network. Until EPOS, there had yet been no effort in Europe to coordinate the provision of data and products for Solid Earth applications of all available European CORS. This differs from other regions of the globe, like Japan  [Sagiya, 2004]  and Western USA  [Herring et al. , 2016] , where dedicated GNSS networks were implemented using centralized and consistent projects with the main objective of producing information to study and monitor natural phenomena.
Governance The above-mentioned EPOS-GNSS objectives are being implemented formally by eleven institutions from ten different countries, who signed a Consortium Agreement in 2020 to operate the pan-European EPOS-GNSS services necessary to achieve these goals. The EPOS-GNSS Service Providers consists of a multidisciplinary team with experience in the management (quality control and dissemination) of data and metadata from GNSS networks and analysis of the derived products specifically for Solid Earth studies. In addition, it is supported by a strong group of IT experts. However, these EPOS-GNSS collaborations are not limited to the EPOS-GNSS Service Providers, but also involve GNSS Data Providers, researchers, and other stakeholders. The Consortium Agreement also defines the EPOS-GNSS governance framework (cf.
Workflow to disseminate validated GNSS data and metadata The EPOS GNSS data and metadata dissemination system integrates several independent nodes as well as a GNSS station metadata collection service (M 3 G, maintained at ROB, Belgium, see section 2. 2. 3), through a central gateway, the EPOS-GNSS Data Gateway (maintained at CNRS-OCA, France, cf. Figure  4 ). As mentioned in the introduction, the EPOS-GNSS Data Gateway makes the data and metadata from the numerous GNSS data suppliers discoverable. Currently EPOS-GNSS focuses on the distribution of daily RINEX data at a 30-second rate. To provide open and free access to their daily RINEX data, the station operators must i) sign the EPOS-GNSS data supplier letter; ii) provide station metadata (equipment information, data license, data ownership, etc.
) to M 3 G (see section 2. 2. 3); and iii) make their data available at a data repository linked to an EPOS-GNSS data node. Each of the EPOS-GNSS data nodes uses GLASS (Geodetic Linkage Advanced Software System) (see section 2. 4), as a virtualization level on top of the data repository itself. GLASS also indexes the GNSS data files, validates GNSS data with respect to station metadata synchronized from the central metadata database located at the Data Gateway, computes data quality metrics, and stores all information in the local node database. GLASS then ensures the synchronization of this local database with the EPOS-GNSS Data Gateway. In this perspective, the GNSS quality control process, performed at each EPOS-GNSS data node with the G-Nut/Anubis software  [Václavovic and Douša, 2016] , is crucial in order to control which data can be made discoverable and if a status warning must be associated to the data.
Data with critical inconsistencies between the RINEX header and the M 3 G information related to the instrumentation (antenna, receiver and radome types, eccentricity), or the file name, or the file format (e. g. , RINEX 2 or RINEX 3) will not be discoverable at the Data Gateway (it remains however discoverable at the local nodes). Data with minor inconsistencies on the instrumentation (e. g. , antenna or receiver number, coordinate deviations) or on the receiver tracking parameters (e. g. , frequency acquisition, elevation cut-off) will be available on the Data Gateway with a specific warning status in the associated file metadata. Finally, some data quality criteria are checked (e. g. , number of cycle slips, number of epochs, and expected number of observables) and if out of range, a warning status is issued in the file metadata.
Access to GNSS data and metadata The EPOS-GNSS Data Gateway offers three ways to access to data and metadata: a web client, a command line client and a RESTfull API. The web client (https://gnssdata-epos. oca. eu, cf. Figure  5 ), which is maintained at CNRS-OCA (France), is a convenient and attractive way to visually explore available data and metadata. Its main interface allows an easy and quick visualization, selection and filtering of stations using geographical, temporal, organization (agencies, networks) or name criteria. An advanced search interface offers selection criteria among all the station, file and quality control metadata (e. g. , instrumentation, percentage of data availability, minimum years of data). With criteria set up, a detailed view of all the station or file metadata is shown.
Station metadata can be downloaded in 3 different formats (JSON, GeodesyML and IGS Site Log), and file metadata (e. g. , url, size, md5) in one format (JSON). The RINEX files that meet the selection criteria can also be downloaded directly. The command line client, available for download at the GNSS Data Gateway, provides the same functionalities. The user can automatically retrieve station and file metadata as well as RINEX files. This client is therefore particularly suitable for massive, regular, or automatic data download. Finally, the RESTfull API allows to interface the GNSS Data Gateway with any existing software or programming language to get metadata.
Collection, validation and distribution of GNSS station metadata The GNSS station metadata that are used in the EPOS-GNSS framework to verify the correctness of the RINEX headers originate from M 3 G (Metadata management and distribution system for multiple GNSS networks, https://www. gnss-metadata. eu). GNSS station managers use M 3 G to submit, validate and distribute the metadata of their GNSS stations including information on station ownership, the equipment installed at the station, its monu mentation and environment, and eventually co-located instruments. From M 3 G the station metadata of EPOS stations automatically flow to the EPOS-GNSS Data Gateway from where it then gets distributed throughout the EPOS-GNSS delivery framework, as shown in Figure  4. GNSS station metadata can be submitted and retrieved using the M3G GUI as well as API.
Current Status Up to now, more than 65 agencies have signed the EPOS-GNSS data supplier letter, inserted their GNSS station metadata in M 3 G (total of 1300+ stations) and offered to provide daily RINEX data to EPOS (Figure  6 ). Ten EPOS-GNSS nodes (cf. Figure  7 ), in addition to the Data Gateway and the Product Portal, are presently operating or in the process of being set up. Apart from node providing access to the data from a specific country or network, the node network includes two pan-European nodes accepting station data from all over Europe: the EUREF node (providing access to EUREF data) and the pan-European EPOS-GNSS node. As these nodes are operating on a pre-operational basis, several of them are still in the process of gathering historical data or setting up the daily population of their databases for the automatic ingestion of new incoming data.
In addition, power spectral density plots using the residuals (i. e. , signal minus fitted model) for the East, North and Up components are also presented for the user to have an additional important measure of the quality of the estimated solutions. Figure  16  presents an example of the visualization of these different products in the EPOS-GNSS Product Portal that can be downloaded in a multitude of formats to be further processed by the user. As explained before (cf. section 2. 3. 2), the different products are updated regularly. The Analysis Centers upload the solutions using the sftp protocol in a reserved area of the Products Portal server in order that the new solutions can be parsed and added to the related tables of the common EPOS-GNSS database that is shared by all the different nodes (see next section for more details).
EPOS GNSS Data and Products goal was to implement an integrated package to be installed at all levels of a single/multi-level GNSS infrastructure. This package is constituted by several components: -A common database scheme (including metadata, data & products); -Web Services for queries and data mining on the data and metadata; -Quality Control tools; -Submission and Validation of metadata; -Tools to guarantee synchronization and consistency of the databases; -Tools to guarantee redundancy and uniqueness of data and metadata. GLASS follows a standard three-tier in which the functional logic, data access, data storage, and user interfaces are developed and maintained as independent modules on the same or separate platforms. Conceptually, all GLASS components can be installed in a single server, or, as it is the case of EPOS, in a distributed environment where there are several nodes (cf.