dataesr/scientific-paragraphs-categorization huggingface dataset:
The resulting segmented volume is then displayed, either qualitatively through a rendered 3D model of LA showing the spatial extent of LGE or quantitatively as a percentage of LA volume. However, high-resolution LGE CMR of atrial fibrosis remains technically challenging and the post-processing is fairly timeconsuming (up to 1 h per patient). In the multicentre prospective DECAAF study, 123 17% of LGE datasets were excluded due to poor quality images related to CMR technologist error or patients arrhythmia during acquisition. An alternative approach based on the quantification of LA extracellular volume fraction by T1 mapping technique was recently proposed. 124 T1 relaxation times measured in LA posterior wall were shorter in patients with AF than in controls, thereby suggesting that T1 value might be a surrogate for diffuse interstitial LA fibrosis burden.
Integration of CT anatomy and electro-anatomical mapping The introduction of 3D electro-anatomical mapping systems has led to a new era in catheter ablation procedures. Data acquired from electrical mapping of the left atrium are used to render a 3D geometrical map of the left atrium. However, these maps are operatordependent and are subject to anatomical inaccuracies. 163 Technological advances has allowed for fusion of pre-procedural CT images either direct into fluoroscopy or into electro-anatomical mapping systems providing 3D depiction of individual patient anatomy. 163 he static nature of the CT images as well as the time lag between CT acquisition and the ablation procedure with subsequent change in volume status and potentially rhythm status are acknowledged limitations for such fusion modalities.
72, 175, 176 2 Aortic valve disease In guidelines, atrial arrhythmias are not proposed as significant events that might impact the treatment strategy. The prevalence of AF is lower in aortic valve disease than in MV diseases. In Rennes surgical database, according to more than 4000 patients assessed for aortic valve replacement, about 10% are in arrhythmia before surgery and about 15% will have atrial arrhythmia episode in the early post-operative period. These have more co-morbidities, an history of renal failure, stroke, etc. ; thus, they have an higher Euro-SCORE. In PARTNER A (40%) and in FRANCE-2 (25. 5%) the prevalence of arrhythmia is higher than in surgical cohorts. 177 -179  AF is more prevalent in low-flow, low-gradient, preserved LVEF patients. That is in part related to the co-morbidities but it is important to keep in mind that this arrhythmia complicates the assessment of the severity of the aortic stenosis (AS) as it would complicate the assessment of the degree of aortic regurgitation.
Overall, it is the transformation of the World Wide Web and the current availability of a vast range of consumer-grade hardware devices and software solutions capable of collecting, managing and distributing geographic data and information which have had the greatest impact on the popularity of VGI  [5]. Crowdsourcing of geographic information through popular VGI projects such as OpenStreetMap (OSM) has also been a major factor in the rise of VGI  [6]. The literature has shown VGI quality to be comparable to data from National Mapping Agencies (NMAs) and Commercial Surveying Companies (CSC), at least in selected geographic areas (see, e. g. ,  [7] [8] [9] [10] ). Initial fears about using VGI as an alternative or complement to authoritative data have subsided. There are many examples of where VGI is being used in real world contexts, some of which will be presented later in the paper.
Protocols in Geomatics and Citizen Science Protocols usually specify how data should be collected and various other elements such as the area of scope, preferred methodology, best practises, and common pitfalls. Protocols must define a formal design or action plan for data collection that will allow observations made by multiple participants in many locations to be comparable and to be combined for analysis. In this section, we provide a brief discussion of protocols that already exist in geomatics and citizen science domains. This amplifies the need for protocols in VGI. Other areas of geomatics rely heavily upon the use of protocols for the collection, management and production of geographic data. Within NMAs and CSC, there are protocols for how reference and survey data are modelled, collected, collated, managed and inserted into spatial databases.
Some of them are available to public  [22] [23] [24] [25]  and others are used strictly for internal purposes. For example, the specifications proposed by IGN France, specify how features are organised, referenced, captured, maintained and how the quality is assessed. For each theme, precise information such as the definition, the geometry type (point, line, polygon), list of attributes (e. g. , name, nature, and number of lanes), selection rules, and geometric capture are described. A similar example exists in the Italian national vector cartography, named Database Topografico (Topographic Database (DbT)). This has subsequently been transposed by each Italian Region by means of customized specifications. As an example, Lombardy Region (in Northern Italy) provides a rich set of technical specifications for DbT production and updating through photogrammetric surveys, representation, content and physical schemes.
All these specifications are separately accessible  [24]. Some rigorous protocols, not available to public, were proposed by the Multinational Geospatial Co-production Program (MGCP) to produce high resolution vector data. The protocol provides guidance for every phase of the data gathering and management by providing documentation on: Feature and Attribute Catalogue, Semantic Information Model, Extraction Guide, Metadata Specification, Edge-matching Process, QA Cookbook-Quality Assurance Guidance, Validation and Internal Supervisors' Direction  [26]. Few NMAs in Europe have experience with VGI  [27]  and there only now we are witnessing the first efforts to develop guidelines, best practices and protocols within NMAs or CSC for dealing with VGI  [28]. However several authors such as  [8, [29] [30] [31]  have considered ways in which VGI and data from NMAs and CSC can be compared, fused or integrated in order to develop more comprehensive, up-to-date and complete datasets.
The Lack of Protocol from the Perspective of the Layman Contributor At minimum, a novice, potential contributor is equipped only with interest to participate in a collaborative project. It cannot be assumed that these contributors have any knowledge about editing environments, differences between raster and vector encodings, preferred feature geometries or topologic rules. Even if some explanations are given in web pages of a VGI project, concrete understanding of the basic principles of GIS is not acquired immediately when a contributor engages with a VGI project. If there is only sporadic contribution, concepts such as formats, data types, domains, attributes, database integrity, etc. are hard to understand and implement. In this context, one can recognize a number of issues that could be avoided if a best-practice protocol for VGI data collection is to be followed.
The Lack of Protocol from the Perspective of Experts In many VGI projects the loose and unstructured way of data contribution from numerous volunteers has created more problems than those it was trying to solve. Researchers have recognized this issue (see, e. g. ,  [47] ) and they have highlighted the need for a moderation in data creation or integration from multiple sources. In this section we present a number of examples where the VGI contribution process and particularly the lack of data contribution protocols were obstacles as they affected many geographic data quality elements. One major example arises from examining the effort to integrate Corine Land Cover data  [48]  with OSM for France  [49]. First, it was realised that the Level of Detail (LoD) of the two datasets differed considerably and this created numerous geometric inconsistencies with OSM  [50].
Regarding attribution consistency it has been shown that the loose, grass-roots mechanisms of data contribution lead to noise into the datasets that deteriorate overall data quality  [5]. VGI is also a social phenomenon and consequently there must be consideration of how social factors can affect contributors and how their contributions are accepted by society itself. For the former, it has been shown that uncontrolled contributions lead to biased participation patterns  [52] , while for the latter, Haklay et al. [49]  describe how a crowdsourced gazetteer project encountered obstacles by the local communities in respect with the dialect used. All these, affect the VGI data quality and create numerous errors in the VGI data collected. This is not to say that VGI communities do not recognize the importance of error-detecting and avoid trying to correct them.
In the case of the OSM project there are a number of tools that try to detect errors such as Keep Right (http://keepright. at), Osmose (http://wiki. openstreetmap. org/wiki/Osmose), MapRoulette (http://maproulette. org), JOSM Validator (http: //wiki. openstreetmap. org/wiki/JOSM/Validator) and others that deal with specific layers such as addresses (http://gulp21. bplaced. net/osm/housenumbervalidator), roads (CheckAutopista http: //k1wiosm. github. io/checkautopista2), etc. These tools check the OSM data for potential data errors in geometry, topology, accuracy, completeness, and attributes. Notwithstanding the usefulness of such tools, they have an a posteriori functionality and thus form the quality control strategy of OSM. This work aims to create proper conditions at the other end of the quality spectrum of VGI projects: quality assurance.
• The protocol should be structured and managed efficiently, so that an objective review, control and integrity check both from the managers of the project and external subjects are possible at any time. It should also be easily changed and adapted to changes or advances in geospatial technology or in the mission and vision of the applied VGI project, while at the same time allow compatibility with datasets already created. The protocol should be based on both existing standards related to the collection, analysis, visualization and documentation of vector data (e. g. , from ISO and OGC) but also on successful practices already used in VGI projects. From a data point of view the protocol should: • Outline how to collect accurate VGI vector data.
Initialisation 1. Familiarize with the project by exploring its goals, aims and needs. Understand existing best practices and project specifications, which will facilitate to understand the tasks expected by the project's contributors and the outcome sought. 2. Decide on/pick a proper device for the task. This can range from a simple web browser for onscreen digitizing to more specialised sensors for on-field collection. The device you choose might not be the best possible one, but it should produce data of a suitable quality for the specific purpose of the VGI project you are contributing to. 3. Familiarise with the device. This helps novice or inexperienced contributors to avoid creating errors that will propagate to the final datasets. Furthermore, some sensors might need to be correctly parameterized.
Discussion In this paper, we have described a plan for the design and implementation of a protocol for the collection of vector data in VGI projects. This protocol is intended to be generic rather than linked to any specific VGI project and works to balance the needs for rigorous data collection strategies and the motivation for VGI project participants to follow the protocol. VGI is now well established and its quality can be in many cases comparable, if not even better, than the quality of corresponding authoritative spatial data  [8, 9]. In contrast with mainstream and authoritative GI that is usually documented in terms of quality, VGI comes without any straightforward information about its quality and thus, much of the on-going research on the field is devoted into revealing intrinsic data characteristics that can be used as quality indicators.
However, and despite the fact that many projects or initiatives seek to maximize the quality of the data collected by contributors, a comprehensive protocol acting as a reference for VGI projects and covering a wide spectrum of quality-related elements is still missing. This paper has addressed this situation by outlining a protocol for the collection of VGI vector data from three distinct processes: manual vectorisation from maps and imagery, field survey, and bulk data import. We believe that the protocol is the first of this kind and intends to provide a first set of general but detailed specifications, which can be potentially applicable to any (existing or new) VGI project focused on vector data collection. We are careful not to relate to any specific VGI initiative (like OpenStreetMap for example) so as to ensure the protocol has potential for further customizations or improvements for specific VGI projects.
For all of these reasons it is difficult to provide an evaluation of the actual usability or effectiveness of the proposed protocol. This will hopefully emerge as VGI projects and related academic research decide to use, or at least to make reference to, the protocol as described in this paper. The protocol has potential to play a very valuable role in VGI projects. This is exemplified in Figure  3 , which shows the four actors involved in the use and creation of a protocol for data collection in the framework of a VGI project:.
• Users/Contributors: Collect VGI data following the protocol and provide feedback about the process and the protocol itself. In this context, the most suitable position available for researchers is the one for spatial data experts. This group can include also project specific experts who bring the substance knowledge to the protocol. As the actors in charge of defining the protocol spatial data experts play a preliminary and crucial role in the whole process. Nevertheless, the success or failure in the adoption of the protocol depends also on all the other actors involved. In an ideal workflow, there should be interaction between all of them. This process should be dynamic and in principle it should never come to an end because as long as the VGI project is active the protocol should be a living reference that constantly evolves with the actors' feedbacks and mutual decisions.
Every protocol for VGI vector data collection should follow the above-mentioned sequence of five main stages. These stages have been considered by the authors and verified by the case studies analysed in Appendices A-C. However, the evaluation of a VGI project specific protocol is considered an open process that is conducted as the VGI project develops. The content of the protocol is project-specific, continuously enriches based on the user experiences and adjusts to any new condition, e. g. , new technologies in data collection. Initially, the protocol can be evaluated, in order to assess how well it provides with the knowledge and skills needed to collect data, by the spatial data experts or by conducting specific tests. As the VGI project matures, possible problems, omissions or insufficient documentation in the protocol become apparent eventually in the data collected and can be fixed by any of the above mentioned actors such as spatial data experts, IT experts, project community or users.
Careless application and rejection of the protocol by the users are also possible and become apparent by problems in the data. When errors are detected, a more careful application of the protocol is advised or enhancement of the protocol with more precise or user-friendly directions to support a better implementation (see Appendices A-C). Every protocol for VGI vector data collection should follow the above-mentioned sequence of five main stages. These stages have been considered by the authors and verified by the case studies analysed in Appendices A, B and C. However, the evaluation of a VGI project specific protocol is considered an open process that is conducted as the VGI project develops. The content of the protocol is project-specific, continuously enriches based on the user experiences and adjusts to any new condition, e.
g. new technologies in data collection. Initially, the protocol can be evaluated, in order to assess how well it provides with the knowledge and skills needed to collect data, by the spatial data experts or by conducting specific tests. As the VGI project matures, possible problems, omissions or insufficient documentation in the protocol become apparent eventually in the data collected and can be fixed by any of the above mentioned actors such as spatial data experts, IT experts, project community or users. Careless application and rejection of the protocol by the users are also possible and become apparent by problems in the data. When errors are detected, a more careful application of the protocol is advised or enhancement of the protocol with more precise or user-friendly directions to support a better implementation (see Appendix).
Future Work and Future Directions As outlined above, to our knowledge, this is a first attempt at developing a formal protocol for VGI vector data collection. The protocol addresses the collection of vector data from: manual vectorisation of image-based sources of geographic data; collection of field-survey data using devices such as GPS; and the importing or fusion of existing geographic data which is available as open geographic data. This protocol does not claim to address every issue in vector data collection for VGI. We have only touched the tip of the iceberg. There are other issues. Palen et al  [56]  indicates in their.
Future Work and Future Directions As outlined above, to our knowledge, this is a first attempt at developing a formal protocol for VGI vector data collection. The protocol addresses the collection of vector data from: manual vectorisation of image-based sources of geographic data; collection of field-survey data using devices such as GPS; and the importing or fusion of existing geographic data which is available as open geographic data. This protocol does not claim to address every issue in vector data collection for VGI. We have only touched the tip of the iceberg. There are other issues. Palen et al. [56]  indicates in their work that OSM, as the largest VGI project, has had to make itself more accessible to a new array of users both mappers and data consumers. This new accessibility has been brought about by a focus both on the usability of OSM tools, legal questions around data usage, the distribution of the data and the working to attract and retain contributors.
However, this is a new contribution to the knowledge in this area. We are not aware of any similar approaches for VGI at the present time. With appropriate protocols, training, and oversight, volunteers can collect data of quality equal to those collected by experts  [57]. Development and outline of this first protocol is an important step. As authors such as Kremen et al. [58]  suggest, protocols, once developed, can be continually monitored and refined resulting in improved data quality. There are many opportunities for future work and continued research. As technology continues to develop on ubiquitous Internet, smart phones and smart devices, the Internet of Things, wearables, and so forth, there will be more and more opportunities and novel ways to collect, create and manage VGI. It will be necessary to treat the protocol as a living document because, as  Vogt and Fischer (2014)   [59]  recommend, protocols should be monitored and updated as necessary ensuring the types of data quality checking and quality assurances in place are still valid.
This work has proposed, described and explained the protocol, however as it has not yet been adopted by any VGI project thus a formal evaluation is still missing. Retrospectively, future work could study which is the degree of implementation of the protocol within one or more existing VGI projects and analyse the correlation between the adherence to the protocol and the overall VGI data quality or impact of quality issues. From an opposite perspective, in the future the protocol could be customized for specific case studies in VGI projects. This customisation could include writing separate and more detailed protocols for manual vectorisation, field surveys and bulk import. Additionally, this could include the extension of the protocol to including editing and updating of existing data in the project.
Implementation of the protocol in dedicated data capturing software would facilitate more widespread adoption and realisation of its merits. The majority of the most popular contribution software in VGI has been developed by software developers and not necessarily influenced by other experts in the field. In this case, we can have a protocol developed by experts which is then implemented by software developers as this serves as a better collaborative utilisation of skills and resources. since map data are in UTM projection as stated in the marginalia. GeoZ connects to VGI4all home page and opens the best practices page based on the protocol referring to "Import bulk data". He refreshes information about VGI4all CRS and realizes that WGS84 is used which is different from UTM. The process becomes too complicated and overpasses his abilities, so he decides to ask help from an experienced VGI4all user.
After posting in the forum, he finds a more experienced contributor living in MyTown willing to help him. Before data import, preprocessing must take place which has three stages: changing projection from UTM to WGS84; adding an attribute named "type" and updating its value to "mountaineering path"; and finally saving data in a format that can be uploaded to VGI4all such as ESRI shapefile. After the appropriate processing, MyTown mountain paths are imported. Self-Assessment/Quality Control: At a first look, the data seem of suitable quality and according to the project specifications. There are no impacts on existing data, as no other mountain paths existed in the VGI4all map. Data diffusion: When all the checks according to the protocol have been completed, data are submitted to the VGI4all project server.
In general, the precipitation extremes from the weather station are more intense than those from the SAFRAN analysis. Figure  2  also zooms on one period to better illustrate the comparison between the data sets and shows a fairly good ability of the SAFRAN analysis to reproduce subdaily precipitation, i. e. , the diurnal cycle of the precipitation. Some of the weather surface stations, GPS data as well as the SAFRAN analysis have been uploaded to the HyMeX database in the frame of the long observation period (see  Drobinski et al. [2014]  for details on the observation strategy). Figure  2. Time series of 3-hourly precipitation data from the in situ weather station having the longest record (blue), from the WRF simulation (green), and SAFRAN analysis (red) at the nearest grid point, as well as the daily precipitation data from SAFRAN analysis (cyan).
, 2013]. Other studies using this simulation  [Lebeaupin-Brossier et al. , 2013; Stéfanon et al. , 2014; Chiriaco et al. , 2014]  or ocean/atmosphere coupled simulations using WRF with such configuration  [Drobinski et al. , 2012; Lebeaupin-Brossier et al. , 2013 , 2015; Berthou et al. , 2014 Berthou et al. , , 2015 Berthou et al. , , 2016;; Flaounas et al. , 2015]  have already been published, and data can be found on the HyMex/MED-CORDEX database.