dataesr/scientific-paragraphs-categorization huggingface dataset:
After assembly and finishing, the genome size was 5. 6 Mb. Open reading frames (ORFs) were predicted using the Prodigal tool (http://prodigal. ornl. gov) with defaults parameters. The prediction of protein function was performed by searching against the GenBank database using BLASTP algorithm  27. Functional classification of gene families (COG ID and Letters) was obtained using COGnitor against the COG database 28. tRNAs and rRNAs were detected using tRNAscan-SE v. 1. 21  29 and RNAmmer v. 1. 2  30 , respectively. The presence or absence of plasmids was verified both by searching the gene annotation for any plasmid-related gene and by mapping all contigs against previously published Raoultella sp. plasmid sequences. We compared the genome sequence of R. ornithinolytica strain Marseille-P1025 to those of other strains of this species found in public databases.
As of August 30 th , 2016 13 R. ornithinolytica genomes were available in public databases. Of these, we used 12 genomes for comparative analysis and excluded that of strain S12 due to its insufficient quality. The twelve comparator genomes were those from strains 10-5246 (AGDM00000000), NBRC 105727 (BCYR00000000), B6 (CP004142), A14 (CP008886), CMUL058 (CVRH00000000), TNT (JHQH00000000), 2-156-04_S1_C1 (JNPC00000000), 2-156-04_S1_C2 (JNPD00000000), 811_RORN (JURX00000000), BAL286 (JXXF00000000), CB1 (LFBW00000000) and Yangling I2 (CP013338). All genomes were re-annotated using the Prokka software, version 1. 11  31. Comparisons between all selected genomes were done using Roary, a tool that rapidly builds large-scale pangenomes  32  , with a blast identity cut-off of 97% for the comparison between R.
ornithinolytica species. In addition, Roary identified the specific and missing genes from strain Marseille-P1025. Specific genes were checked by BLASTP and TBLASTN against the other studied genomes. Missing genes were checked by TBLASTN against the genome of strain Marseille-P1025, using a coverage and identity of 60% and 80% as thresholds, respectively, as described by Kuenne et al. 33, 34. Easyfig. 35 was used to visualise the coding regions and colour the specific genes of strain Marseille-P1025. Recombination and Phylogenetic analysis. The genome of strain Marseille-P1025 was used as a reference for whole-genome alignment 36 using Mugsy  37. Then, a phylogenetic tree based on whole genome sequence alignment was done using the FastTree software  38  and the maximum likelihood method (Fig.
1 ). ClonalFrameML was used to search recombination hotspots in R. ornithinolytica genomes by analyzing both the whole genome alignment and the phylogenetic tree  39. Unique sequences were detected by a BLASTN search for homologous sequences and multiple sequence alignment using the Mafft software algorithm  40. Phylogenetic analysis of these unique sequences was performed using MEGA version 7  41  and the maximum likelihood (ML) algorithm, with 1,000 bootstrap replicates. Electron microscopy. Electron microscopy was performed with detection Formvar coated grids. Forty 40 μL of bacterial suspension were deposited on a grid and incubated at 37 °C for 30 min, followed by a 10 sec incubation on ammonium molybdate 1%. Grids were then observed using a Morgagni 268D transmission electron microscope (Philips) at an operating voltage of 60 kV.
An approximation to the ROI pixel mean uncertainty using the S2-RUTv1 Case study locations The study is performed over three different sites that correspond to different methodologies of TOA radiometric validation: the RadCalNet site at Gobabeb, the Boussole buoy site and DCCs. These sites have a different balance of uncertainty contributions and were chosen to determine how this changes the level of pixel correlation for each case. Here there is no discussion of the uncertainty associated to the validation methods themselves, simply the S2 MSI uncertainty estimates. RadCalNet (www. radcalnet. org), once it becomes fully operational, will provide users with an operational (routine) service for nadir-view TOA reflectance factor data from several instrumented ground sites in the spectral region 400 nm to 1000 nm or 2500 nm, depending on available instrumentation.
RadCalNet Gobabeb site case study For the RadCalNet Gobabeb site we selected a product with minimum cloud image percentage. The product corresponds to an overpass on 9 June 2017 and UTM tile T33KWP. The ROI pixels were selected with centre at lat/lon -23. 6°, 15. 119°with a size ranging from one pixel up to 500 m. This ROI was also checked for any potential pixels masked as cloud, cirrus, no data or defective. The results in Figure  4  show the evolution of the ROI mean uncertainty as a function of the ROI size as calculated using the MCM. The first point on the left side of the figure corresponds to the per-pixel uncertainty directly obtained from the S2-RUTv1. The decrease of the uncertainty is in the range of 0. 2-0. 8%, depending on spectral band and the different correlation levels of different bands.
Acknowledgements This work was supported by the  European Space Agency (Scientific Exploitation of Operational Missions (SEOM)   S2-4Sci  Land and Water Radiometric Validation Contract No. SEOM. 1426. ACR-NPL. i1r0 ),the  National Measurement System of the UK government's Department for Business, Energy and Industrial Strategy , and the  European Metrology Research Programme (EMRP). The EMRP is jointly funded by the EMRP participating countries within EURAMET and the  European Union.
The study's contribution is twofold, including specific identification of the issues pertaining to a single or a combination of data sets (AFC, AVL, and GTFS), and the development of a methodology for addressing these issues and generating spatiotemporal load profiles of transit vehicles. The methodology consists of four steps through which raw data are processed and integrated to generate the passenger load profiles over space and time. These profiles allow service providers to analyze vehicle trajectories and demand patterns, and further investigate service utilization and the propagation of delays and crowding. The data collected from the urban transit network in The Hague, The Netherlands are utilized for demonstrating the methodology. A series of inference and matching steps are employed.
This analysis results in profiles of vehicle trajectories and passenger loads which are further visualized through space-time occupancy graphs. Analogously to how space-time graphs of speed and flow enable traffic engineers to study spatiotemporal congestion patterns along routes in car traffic, these space-time occupancy graphs enable transit operators to study and inspect spatiotemporal on-board crowding patterns along transit service lines. The remainder of this study is organized as follows. The next section describes the transit data sets available in the Dutch context, including AFC, AVL, and GTFS data, along with the related issues. Following this the methodology is described, with an overview and descriptions of all the steps as well as implementation. The results are then presented, followed by the conclusions and discussion of future research directions.
Data Description and Issue Identification In this study three different transit data sets are used, all of which were collected from the urban transit system in The Hague, The Netherlands. These comprise AFC, AVL, and GTFS data. All three data sets cover the period of March 2015, which includes 22 normal working days and 9 weekend days. In this period, the system consisted of 12 tram lines and 8 bus lines, and the incumbent transit operator was HTM.
AFC Data The Dutch smart card system (OV-chipkaart in Dutch) is a nationwide fare-collection system (21, 22). An important feature of the Dutch smart card system is that passengers are required to check in and check out for every single ride of a journey for fare calculation, except when transferring within the national railway system and metro systems. Missing the check-out will result in a much higher fare, therefore making passengers have a strong incentive to finish a ride by correctly checking out. Consequently, information of travelers' origin and destination is fairly complete and accurate without the need to infer passenger alighting stops. However, individual rides still need to be combined to obtain an OD matrix, which is an important input for a variety of offline applications. The smart card data set from The Hague for the whole month of March 2015 contains close to 8 million validated records.
AVL Data The AVL data of transit vehicles in The Netherlands are well stored and managed at a national level (23). The one-month data set used in this study contains over 22 million records in an event-based format. Individual trips are distinguished by a unique trip ID within an operating day. Besides information of line ID, stop ID, and vehicle ID, each row of data is specified as an event and its corresponding timestamp(s), such as the start of a trip, onroute, arrival, dwell, departure, and end of a trip. In addition, deviation from the scheduled time is indicated in the data under ''punctuality. '' The entire fleet of HTM is equipped with the AVL system.
GTFS Data GTFS, as one of the most prevailing formats for transit schedules and associated geographic information, has been widely adopted in the past decade by transit agencies and operators to share information with the public (4). In The Netherlands, GTFS data that cover most transit services nationwide can be accessed via a website called OVapi (24). These feeds are created from the open data files published by local transit operators under an open license. The website is well maintained with frequent updates of GTFS and GTFS-Realtime data. The GTFS data used in this study contain all trips scheduled by HTM for March 2015 in The Hague. The GTFS data can be matched with the AVL data set using the trip ID.
Data Issues Several issues pertaining to a single or a combination of data sets can be identified and need to be resolved for the current application, that is, constructing the spatiotemporal load profiles of transit vehicles. These issues are summarized and presented in Figure  1  in relation to their sources. Basically, issues specific to each individual data set are illustrated in the respective oval, whereas issues that arise when two or more data sources are combined are positioned at their intersections. The following issues have been identified: (1) Indirect availability of line information about stops Information in GTFS data is stored in a trip-based manner, meaning that what can be directly obtained from it are only individual vehicle trips that consist of all the stops per trip.
Complete stop sets of service lines, which are crucial for subsequent analytics, are not directly available from the GTFS data. (2) Erroneous AFC check-in/out records AFC data contain different types of errors, including unrealistic alighting times or alighting locations, as well as missing and unrealistic trip numbers. The issues are the result of improper passenger behaviors and system malfunctions. (3) Multiple timestamps for one arrival/departure event Multiple timestamps can be occasionally found for one arrival or departure event in the raw AVL data set. It is unclear why this happens, but it jeopardizes the global consistency of vehicle trajectories. (4) Timestamps missing for one arrival/departure event Arrival and/or departure timestamps at a stop can be missing. The size of missing timestamps ranges from one event (arrival/departure) at a stop to an entire trip.
5) Inconsistency in trip ID The vehicle trip ID indices in AVL and GTFS data do not always match. This inconsistency causes problems in matching trip and trajectory when combining GTFS (scheduled trajectories) and AVL (recorded trajectories). (6) Lack of information for matching rides to scheduled vehicle trips Since the AFC data set used in this study does not contain vehicle trip ID, it is impossible to directly match individual rides to scheduled vehicle trips that are extracted from the GTFS data. (7) Lack of information for matching rides to recorded vehicle trips The same issue as #6 holds for this situation too. There is no direct way to match rides to the recorded vehicle trips from AVL data.
(8) Uncertainty in trip cancelation/execution The GTFS data contain all scheduled trips of a day. However, this does not provide conclusive evidence that all these trips are indeed executed. In many cases, the number of trips found in the AVL data set is smaller than the scheduled number of trips. It is uncertain whether this is a result of trip cancelation or AVL system malfunction without any additional information. AFC data may be used here to settle the discrepancy. These issues are illustrated for a given day and line in Figure  2 , which visualizes the recorded trajectories from AVL data; scheduled trajectories from GTFS data; and check-in/out records. Figure  2a  first displays all the recorded trajectories from the AVL data. There are many gaps in this plot, which indicates that there is either a missing timestamp or multiple timestamps for the arrival or departure event at that stop.
Overview The methodology consists of four steps as shown in Figure  3. Raw data from three independent sources are used throughout the four steps. All three individual data sets are initially stored in separate databases. In step 1, the raw data are first obtained from the databases with all the information restructured at a daily level. By doing so, the subsequent workflow is made more computationally efficient. Issues #1 and #2 (described earlier) are addressed at the first step, resulting in data files respectively containing passenger rides; recorded vehicle  Consequently, all trajectories have complete trajectory and load information and are globally consistent. Issues #3 and #4 are thus solved in this final step. This sequential method decomposes the process into small sub-tasks with each step solving one or several of the identified issues.
Step 1: Data Pre-Processing All three types of data are preprocessed in the first step at a daily level. For AFC data, single transaction records are first linked to generate individual passenger rides with both check-in and check-out information (stops and times). Erroneous rides with unrealistic travel time and origin or alighting stops are identified and removed in this process. In this case, the travel time threshold was set to 90 min, which exceeds the maximal travel time between any pair of stops in the case study network. In addition, the indices of stops were also transformed to be consistent with those of the AVL and GTFS data. Every single scheduled trajectory-characterized by the arrival and departure time at every stop along a line-is extracted from the GTFS data. This process is not straightforward because the GTFS standard does not contain direct information about regular stop sequences of individual transit routes.
Designed originally for the purpose of route planning, the GTFS data make it quite handy to obtain arrival and departure times at each stop of individual trips by storing information based on trips. A trip is recorded in the trip. txt file and further detailed in the stop_times. txt file with its sequence of stops. All trips, including sub-lines and partial trips with some stops skipped, are thus easily stored in the data. However, this becomes an obstacle when information about the most regular and fullest stop sequence of transit lines is required. To overcome this problem, a brute-force approach is adopted. All trips of a transit route from a normal working day are scanned in order to acquire the complete set and right sequence of stops on this line and this direction. This is a straightforward yet effective solution to this problem.
AVL data, however, do not need to be much processed since the information is already organized based on stop sequences of trips. If there is a missing record, a ''Not A Number'' label is added. Step 2: Matching Trips in GTFS and AVL This step is dedicated to matching all the trips recorded in the AVL data set to all the scheduled trips contained in the GTFS data. Ideally, the two data sources should share the same trip ID indexing scheme so that the matching is very straightforward. However, inconsistencies do exist, as illustrated in the previous section. To address this issue, the recorded arrival time as well as the delay at stops from the AVL data are used to compute the probable scheduled arrival times as follows: ps n, k = p r n, k À d r n, k ð1Þ where ps n, k , and p r n, k , respectively, denote the probable scheduled and recorded arrival times of trip n at stop k.
d r n, k denotes the recorded delay of trip n at stop k from the AVL data. The scheduled trip that has the closest arrival time at a stop to this ''estimated'' scheduled arrival time ps n, k is then found, and its trip ID from the GTFS data is temporarily labeled to this stop visit. After applying this process to all the stops of this trip, the GTFS trip ID that has been most frequently labeled is adopted and assigned to the entire trip. The matching of the recorded trips (AVL) to scheduled trips (GTFS) is performed so that those trips that cannot be found in the AVL data will be later checked to assess whether they were really executed by taking the AFC data into consideration. In addition, headways based on AVL and GTFS are also computed and added to the trajectory profiles at the end of this step.
Step 3: Matching Passenger Rides to Vehicle Trajectories The objective of this step is to match all individual passenger rides to the vehicle trips that these passengers traveled with. However, since the trip ID information is missing in the current AFC data set, a trip ID inference algorithm for all the rides is first developed, as shown in Figure  4. Let t in i, k denote the check-in time of passenger i at stop k. Let p r n, k and p s n, k , respectively, denote the recorded and scheduled arrival times of trip n at stop k. Essentially, the algorithm attempts to find the trip ID for a single ride by the ith passenger so that his or her check-in time at the stop k, t in i, k , is closest to the vehicle arrival time p r n, k and p s n, k at the very same stop k along the trip n. Recorded arrival times p r are used as the major benchmark because delays can introduce a significant bias when performing such inference.
Step 4: Improving Vehicle Trajectories The last step is dedicated to the correction of vehicle trajectory profiles based on the results from step 3. It attempts to resolve the issues identified in the AVL data (#3, #4, and #8). The central idea is that the integrated information from three different data sources at the same detail level, including the recorded (AVL) and scheduled (GTFS) arrival/departure times, as well as check-in/out times at stops (AFC), will allow (1) whether a vehicle trip was indeed executed to be inferred, and (2) actual vehicle trajectories to be restored to the maximal extent. In the current study, practical solutions consisting of several rules were developed and applied. To infer whether a trip is executed or canceled in reality, a series of rules are proposed based on the practical investigation.
Results For simplicity and tractability, only the results of tram line 1 for the entire month of March 2015 are described in this section. Line 1 connects Delft, a mid-size old university city, to The Hague, the main city in its urban agglomeration, serving 41 stops per direction, including three major train stations. The service is frequent, with 208 trips on a normal weekday and up to 8 trams per hour in the peak on each direction. More than 670,000 passenger rides are recorded for line 1 in the AFC database over the case study period. After applying the pre-processing to these rides, around 0. 03% (around 200) rides were discarded because of the issues described earlier. Figure  5a  shows the result of vehicle trip ID inference for passenger rides. For most of the days, over 90% of the rides' trip ID can be successfully inferred based on the recorded trajectories owning to the relatively high quality of AVL data on these days.
Two particular days, that is, the 6th and 18th of March, are noticeable because of their low AVL-based inference percentage. This is arguably caused as a result of the significant loss of AVL data on those two days, which implies that many inferences rely instead on just the scheduled trajectories. The percentages of recorded trips in the AVL data and the executed trips that are eventually validated compared with the total number of scheduled trips are calculated and displayed in Figure  5b. Both directions are considered at the same time. It can be seen that on many days, not all scheduled trips were executed. A significant plunge appears on the 6th of March, where fewer than 80% of scheduled trips are recorded in the AVL data, whereas over 90% trips could be validated when also using information from check-in/out activities on that day.
Conclusions and Future Research Obtaining on-board load profiles of transit vehicles has remained as a difficult task for operators in recent years as a result of technical and financial constraints. In this paper, a new methodology for constructing such profiles with multiple transit data sources is presented, including AFC, AVL, and GTFS. Difficulties of utilizing these data are discussed with the issues arising from a single or a combination of data sets specifically identified. The methodology consists of four steps through which the raw information from individual data sources is processed and corrected. The output profiles can convey integrated information regarding both vehicle trajectories and passenger demand on a large spatiotemporal scale. The methodology is demonstrated with data collected from the urban transit system in The Hague, The Netherlands.
A key output is so-called space-time seat occupancy graphs, which provides operators with a compact and powerful reference to intuitively examine the on-board crowding patterns over time and space, thus helping to improve their services, such as timetable optimization, network and fleet scheduling, designing subservices running over partial lines, and so forth. The contribution of this study is twofold. First, the study aimed to integrate different transit data sources for obtaining state estimations for passenger loads. In this process, the issues related to each and the combination of different data sets, namely AFC, AVL, and GTFS, are specifically identified. Although based on data available in the Dutch context, most of their properties are universal, and this way of presenting all the issues can be beneficial for researchers and practitioners with different data formats but similar difficulties.
Acknowledgments The authors thank HTM and  Stichting OpenGeo  for providing the AFC and AVL data sets, respectively. We also acknowledge Transportation Research Part C: Emerging Technologies, Vol. 19, No. 4, 2011, pp. 557-568. 3. Utsunomiya, M. ,  J. Attanucci , and  N. Wilson. Potential Uses of Transit Smart Card Registration and Transaction Data to Improve Transit Planning. Transportation Research Record: Journal of the  Transportation Research Board , 2006. 1971:  119-126. 4. Google. GTFS Static Overview. https://developers. google. com/transit/gtfs/. 5. Wong,  J. Leveraging  the  General Transit Feed Specification  for Efficient Transit Analysis. Transportation Research Record: Journal of the  Transportation Research Board , 2013. 2338:  11-19. 6. Alfred Chu, K. , and  R. Chapleau. Enriching Archived Smart Card Transaction Data for Transit Demand Modeling.