dataesr/scientific-paragraphs-categorization huggingface dataset:
AlexNet showed that a large, deep convolutional neural network is capable of achieving record-breaking results on a highly challenging dataset using purely supervised training. Nowadays, deep learning is becoming a powerful approach in several domains to solve many big data problems such as computer vision, speech recognition, and natural language processing. In agriculture, CNNs have been used for different problems such as weed detection, plant classification, plant disease detection but not for crop row detection  [12] -  [17]. In this paper we propose a new method that combines CNN and the Hough transform to extract crop rows in images taken by an unmanned aerial vehicle (UAV). The aim is to design a robust method able to detect and highlight the crop rows. The paper is divided into four parts.
IV. RESULTS AND DISCUSSION The images used come from a public dataset provided by  [50]. These images were acquired in a beet field by the Parrot RedEdge-M multispectral sensor 10m from the ground. This public dataset contains 5 subsets of images numbered from 000 to 004. Each subset corresponds to part of the field. For the training, only images in the 003 subset were used and the evaluation was performed on the 000-002 image subsets. The images in subset 004 were not used because of the blurring that was present in some parts of the images. In order to test the robustness of the proposed method, it was applied to images acquired in another field with a different flight altitude and spatial resolution. These new images were acquired in a corn field with Sony camera 100m above the ground with a spatial resolution of 2.
A. TRAINING Manual image annotation is very time consuming because it requires not only the ability to draw a continuous line per crop row, but also to repeat the same process for each image. To simplify the annotation process, we proceeded in a semi-supervised manner. The orthomosaic image 003 was divided into patches of 250 × 250 pixels. This size was chosen to obtain images showing crop rows with different layouts (discontinuity, non-regular contours, inter-row weeds, etc. ) and also to facilitate the CNN learning. Then we applied CR-Hough-SLIC  [27]  to detect crop rows in all the image patches. Patches where all crop rows were correctly detected were selected to build the training dataset. The number of learning samples collected was 134. With data augmentation we increased the size of the dataset seven times (Rotation 0 • , 45 • , 90 • and 135 • and 3 contrast changes).
Fig. 8  presents the dataset used for the training. SegNet was trained with all the training data, while the HoughCNet network was trained only with the original images and data augmented by rotation since samples with contrast change have the same orientation as the original ones. The ground truth shows that classes are imbalanced: the majority of pixels are in the background and this can affect the learning process. Classes with more trained elements may become more sensitive to identification in relation to classes with fewer trained elements. This class imbalance problem is solved by reweighting the loss by inverse class frequency. Thus the weighting of each class corresponds to the inverse of its frequency in the images. This process has the advantage of increasing the weight of under-represented classes and thus influencing the loss function by assigning a relatively higher weight to the minor classes (Table  1 ).
B. TEST Assessment was carried out on 154 images (480 × 360 pixels) from datasets number 000, 001 and 002 of the public dataset  [50]. In order to take into account crop row irregularities and to avoid the impact of weed pressure in the test data, the ground truth was built manually with the Matlab labeling tool (Image labeler). The labeling consisted in creating a mask around each row. The weed infestation rate (WIR) in these images varies from low to high. The WIR is the proportion of vegetation pixels considered as weeds in an image. According to the WIR classification, we have 45 images without weeds (WIR < 5%), 21 images with a low rate of infestation ([5% -15%[), 50 images with a moderate infestation rate ([15% -35%[) and 38 heavily infested (WIR > 35%). These infestation rates were computed from the ground truth of the images available in the public dataset.
Data streams from sensors have various qualities, and the assessment of this data quality with respect to the nature of the sensor is necessary in order to construct analysis frames that take into consideration all available information so that falsification issues and attack issues can be clearly discriminated. Since falsifications and attacks address different issues originating from different sources, it is particularly important to be able to differentiate them as soon as possible so that the relevant methods can be applied for data analysis. In general, machine learning techniques are widely used for data analysis  (Kotsiantis et al. , 2006). Those techniques include regression, classification, clustering, deep learning, image processing or natural language processing. Since the topic of maritime cybersecurity issues has few available and usable data for the construction of a model for the training of an algorithm, this field of study is prone to the use of alternative methods that do not require such training dataset.
This research has been applied to an AIS dataset constituted of messages received by our antenna and parsed with an in-house parser. In the following of this paper, Section 2 introduces the added-value of mechanism of anomaly detection in the decision-support system, addressing the issues of trust in information, data quality dimensions and methods for the detection of anomalous events. Section 3 presents the AIS (Automatic Identification System), which is the most important source of information on vessels at sea. As our study is based upon this system, its issues in relation with data quality are presented. Section 4 presents the proposed methodology for the design of an information system which assesses data, extracts relevant pieces of informa-tion and presents them to an operator as a decision support tool, taking into consideration the specificities of the system studied, going from the assessment of data fields to the evaluation of some selected scenarios.
Dynamic data are the pieces of information contained in the data fields which are expected to change over time, displaying a physical motion, such as the latitude, longitude, course over ground or speed over ground. Voyage-related data are pieces of information that are expected to change often, at each new voyage, such as the draught, the destination, the estimated time of arrival or 1 e. g. marinetraffic. com, aishub. net, amongst others the hazardous nature of the cargo.
, 2014a) , the resulting trajectory of which is presented in Figure  1. In Figure  1 , the result was received and displayed on the website marinetraffic. com, as a station of this network received the signal. Other kinds of attacks or tests have occurred to appear on this platform, where fake data (e. g. ships) Availability disruption threats are three of a kind: slot starvation, frequency hopping and timing attacks. Slot starvation consists in impersonating the maritime authority to reserve all the slots, thus all stations within coverage have no slot available for reservation and emission. Frequency hopping is the fact to instruct the AIS transceivers to change their transmission frequency, as it is possible by protocol specification for given areas in the World. In timing attacks, the malicious user instructs transceivers to delay their transmission, by doing it repetitively, it prevents the system from functioning normally; and on the contrary, the attacker can command transceivers to send updates at a very high rate, thus overloading the channel.
The perception of some elements that can be hazardous is however limited (cargo, identities of passengers, identities of mariners for instance) which implies a limit of the detection of anomalies, because an hypothetically perfect analysis would require a perfect knowledge of the various components serving as information sources on a perfectly known interpretative framework. In this perspective, the determination of quality dimensions as defined in Section 2. 2 is necessary, so as to ensure a proper assessment of AIS data. The data quality dimensions of accuracy, currentness, completeness, precision, consistency  (Huh et al. , 1990) , integrity  (Fox et al. , 1994)  and reliability  (Brodie, 1980)  have been highlighted as particularly important in the analysis of AIS issues by  Iphar et al.
A methodology for integrity assessment of maritime data As shown in Section 3. 2, AIS messages present vulnerabilities in their structure and data, such as falsification, and those vulnerabilities can increase or lead to the creation of maritime risks. In this section, a method for assessing integrity of AIS messages is presented. In this method, a thorough examination of AIS messages leads to the identification of 935 integrity items, which are elements in which AIS data may disagree. In the complex AIS structure, it would be an indicator of an integrity issue. A system of flags, based on the one hand on integrity items and on the other hand on non-AIS data (contextual data such as fleet registers), has been developed, the goal of which being to highlight humanly understandable anomalies about the AIS, in the frame of some specified scenarios.
A logic-based formalism for integrity assessment After the determination of the item list, each item must be rigorously assessed in order to check the conformity or the coherence of the fields within. A Boolean value is associated with the item to the message assessed, taking the value True or False, considering the assignment of this value as an answer to the question: Is the statement expressed in the item demonstrating an AIS-data integrity violation? Therefore, of the application of the item to a message demonstrates an integrity issue, then the value True is allocated to this item for this message, else it is False. The essence of the item will not be assessed in some cases, for several reasons. Should it happen, as the integrity of the system has not been violated, the value associated to this item is False.
The list of integrity items for each flag is fixed, and the selection of flags which directly use integrity items results is fixed for each scenario. As a consequence, the list of integrity items needed for each scenario can be easily deduced by gathering all items of every single flag of the given scenario. For example, in the case of the remoteness flag (excessive communication distance), there are 17 different items corresponding to this flag in the case of message type number 1. If only one of those items display a True value, then the remoteness flag will be set to True. Scenario-specific flags. Those flags are totally dependent on the available external datasets, and each flag will be tied to the content of the database itself. Therefore it is impossible to set a fixed list of those scenario-specific flags, as their number and nature vary according to the available databases.
The fact to use such contextual information is particularly important in order to be aware of the environment of the system, and the assessments provided are as various as data coming from the system enable it. Each flag is associated with one particular assessment type involving both AIS data and contextual information (i. e. it is necessary to query both system and non-system data before assessing the item), then the computation of the result is performed by a specially designed algorithm. As a consequence, it is not possible to write a general assessment program but it is needed to adjust the program to the data structure and type of the contextual dataset. An example of such scenario-specific flags is presented in the following of this section, with the involvment of a fleet register.
Example: f fr consistency This exemple assesses the conformity of AIS data with a given fleet register, in our case the European Union Fishing Vessel Fleet Register 3  , which is publicly available and contains the list of EU fishing vessels. In this database, the fields in common with AIS are the call sign (which will serve as foreign key, usable for a join), the vessel name and the vessel dimensions (which will be the values to be compared). Let B be the EU fishing vessel database, b be an element of B, be a Boolean standing for the fact for B to be exhaustive ( = exhaustive), Dist α be a semantic distance (here an Edit distance), Dist β be a Minkowski distance (here a Manhattan distance), Ξ and Υ be the respective expert-defined thresholds for semantic and Minkowski distance for data compliance.
Data The dataset contains three categories of data: AIS data, vessel-oriented data and geographic data (mainly linked to navigation) and provides ship messages issued from the Celtic sea, the north Atlantic ocean, the English Channel and Bay of Biscay (France). The dataset consists of circa 24 million messages, 94% of them being geolocalised messages and 5% being static information messages, as shown in Table  5 , which also display the number and percentage of messages per type of emitting station and families of messages. Message number 1 is by far the most used, representing 62% of all messages, before messages number 3 (13%), number 4 (12%), number 18 (4%) and number 5 (4%), which are the only messages to have a frequency greater than 3%. In our dataset, 71% of the messages number 1 are within 10 km of the reception antenna.
Falsified AIS data. Genuine AIS messages of the dataset natively contain errors and misconfigurations. They also contain several falsifications (cf. Section 6). However, some behaviours involve rare or never received messages, other require a condition on data which is rare (for instance a weird-looking trajectory involving AIS location on shore such as the one presented in Figure  1 ). In order to test, evaluate and validate algorithms and specific scenario cases under reference data, controlled degradation of data has been also performed  (Iphar et al. , 2019). Our approach relies on two degradations: first, original AIS data has been manually or automatically modified. Second, some AIS frames or sequences AIS frames were created intentionally and injected in the dataset as described in Figure  6.
Architectural principles Based on the methodology presented in section 4, an information system has been developed for the detection of AIS falsifications. The system is designed to handle both real-time asynchronous and offline analysis of messages and works 900 with both streamed and historical data. While in the experiments, only one receiver has been used, the information system has been designed to cope with multiple AIS receivers and one central database. Figure  6  shows the different components of the system.
Data integration Most AIS messages come without any timing information because the AIS has been initially designed as an anti-collision system to be used in real-time. First, a receiving station timestamps the messages in UTC format immediately upon reception. In a second step, the parser reads AIS frames, extracts parameters of the message and stores parsed information in the central database. Additionally, the parser exports the timestamped messages, in the raw and unparsed format received to the central server which also stores all the messages (i. e. , all the 27 different message types described in the ITU-R. M 1371-4 or NMEA 4. 0 specification) in text files (one file per day). This parser, written in Java, extends and adapts the CC-BY-NC-SA 3. 0 parser aismessages 4. The additional functionalities developed include: the connection to the database, ingestion, and outputting of UDP (User Datagram Protocol) streams and files (used by the AIS), automatic folder import, data logger for unparsed messages, data export translated to the standardised TAG Block format, data analytics about the receiving flow of messages.
Data management For data storage and manipulation, a database management system was used, because of the ability of such systems to find, write, sort, modify or transform data in complex databases, while ensuring the user a level of robustness of the analysis by avoiding partial assessment or information loss. The choice of the widespread and open source relational database management system Post-greSQL was made, using the SQL querying language, with the adjunction of the PostGIS extension, for the treatment of spatial features. The main contents of the database are presented in Figure  7. The database gathers several main elements organised per database schemas: The AIS messages schema contains 27 tables corresponding to each message type and a table for all unparsed messages (error table ).
Asynchronous batch data processing Message analysis and falsification detection constitutes the core component of the information system. The Python programming language was chosen for its development. Beyond the availability of several libraries (e. g. maths libraries for statistical computations) that favour our data analysis, Python is easy to handle and it enables database querying with embedded SQL. The program works using an incremental and a sliding temporal window in which items and scenarios are assessed. The processing follow the four-order assessment model described in Figure  3  and is organised in two steps further detailed in this section. In a first step, the program queries the database to fetch all the needed information and messages in a given time window. In a second step, it executes a batch processing of data to assess integrity issues and detect falsification cases by computing flags.
Those two steps constitute a processing loop, as the process is triggered again after a waiting time, and a new computational first step occurs. The corresponding data analysis workflow is described in Section 5. 2. 4. AIS messages are collected continuously (average velocity of our receiver is about 77 messages per minute), parsed and stored in a database together with analytic values of the flow. While it would be possible to stream and analyse every single message on-the-fly, it has been chosen to perform an asynchronous batch processing within temporal windows working on the database. This choice is adapted to a centralised database architecture where duplicates can occur in the cases where the same message is received by different stations. It also enables the creation of temporal series of messages from the emitter, easing series-based analyses compared to historical data.
The need for this approach is also directly drawn from the data treatment process, where a group of messages with timestamps between given bounds (for each of the 27 message types) are consecutively assessed for the items, the scenarios and for the flags. In such batch processing, newly arriving messages are collected into a group of AIS messages. The whole group is then processed at a future time. The time when each group is processed can be determined in different ways. For instance, it can be based on a fixed time interval (e. g. every minute) or on some triggered conditions (e. g. process the group according to the frequency of received messages, i. e. once a given amount of messages has arrived). Each processing loop is characterised by three timestamps, defining two temporal windows: the incremental and the sliding temporal windows.
Data Analysis Workflow Message analysis and falsification detection component loops on several steps: first it updates temporal windows, then it computes item assessment and flag assessment which are detailed in this section. Item assessment. Amongst formalised integrity items (935 in total), a total number of 666 have been successfully implemented into our system. These items are spread amongst the different levels of the four-order assessment model. Several elements of the database are involved in this assessment process, namely the AIS messages, the configuration tables (e. g. temporal window parameters) and results tables. Each assessment starts reading a configuration file in which a set of items to be computed are listed (up to 666 valid ones). The reading of each item triggers one of the four following cases depending on the item level: 1.
The read item is either of order 1 and 2, so the querying to the database will involve only one message; 2. The read item is either of order 3 and 4 so several messages, possibly of different types will be queried; 3. The read item has a bad format (non-existent item). The algorithm, in this case, returns the information that this item has not been treated; 4. The read item has no value. This ends the loop (the program stops or another loop is going to start with the next temporal window). In both (1) and (2) cases, a table of results for the item is created in the database. Then the relevant AIS message database is queried for the data fields of interest for this item and for the temporal span defined by the working window. Once the values are returned, a loop occurs on it, treating all the messages within the working temporal window one-by-one.
From this point on, the processing varies with the order of the algorithm. In the (1) case, the values are directly assessed by the corresponding algorithm, and the result is filled in the item result table once all messages have been treated. In the (2) case, another query to AIS messages tables is necessary in order to get all the necessary pieces of information from other messages, which can come either from the same message type (in the case of order 3 item) or from another message type (in the case of order 4 item). Once the result of the query stored, all necessary data are present and the assessment can occur, followed by the filling in of the table gathering all results in the database, once all the messages have been treated. Flag assessment. A flag assessment is based on the analysis of AIS messages (item assessment as described above) together with contextual data sources (geographic, navigation-related data.
). This assessment is driven by temporal windows and by the configuration file describing the list of algorithms to run for each scenario. It also specifies the data sources to involve in computations (AIS messages, external information, various results of the item algorithms). The flag assessment results are stored in dedicated database tables. First, the temporal extent of the working window is obtained so that the messages to be assessed are known. A assessment is then performed on all falsification scenarios selected by the user. For each of the scenarios, a flag table (in the database) corresponding to the scenario in question is created, and the relevant item results are queried and stored in the program, enabling further flag studies. Then, for each of the messages in the working window, and for each of the various assessments that lead to the determination of a flag, the same process is repeated.
Selected flags As it is not possible to display the results of all the flags, a subset of flags has been selected, in order to cover the diversity of scenarios put in place. In total, 23 flags have been implemented and 8 have been chosen for testing and validation of results. Table  6  summarises the characteristics of those chosen flags. In addition to those flags, the flags linked to the vessel type have also been computed. In Table  6 , the scenario column displays the number of the scenario described in Table  4. Required AIS and contextual data are also extracted from the dataset presented in section 5. 1.