## 3 Materials and Methods
### Identification of a Rail Vehicle Position in Rail Network  
As the above-indicated research demonstrates, a number of localization systems exist in the world based on the GNSS. However, these systems are often complemented by further elements which participate in the resultant localization. This is why a mere GNSS-based localization may not be considered original; we have to take into view the overall localization system concept using the GNSS as a general supplier of information about a rail vehicle position and its consequent connection with the designed railway network model. This is one of the reasons why this article puts stress on the algorithms and methodology of building a railway network model, as well as on the proper description of localization and its use in the detection of nonstandard situations for the additional support of rail transport control by dispatchers. It was possible to build a three-layer railway network model from the above-indicated algorithms with different abstraction levels. The final model was then saved in the Oracle database with a Network Data Model (Oracle Spatial and Graph) superstructure, which enabled the building of a graph representation directly on the database level. For the correct functioning, the database structure must be complemented by binding tables to maintain individual layer hierarchies. The vertices and edges of the graph were saved in predefined database tables and complemented by the appropriate geometric properties (point, right line), which were saved in a special object-relation data type, SDO_GEOMETRY. The vertices were represented by multidimensional points with GPS coordinates. The edges were carried out as line segments between the relevant vertices. For effective work with this object-relation data type, Oracle offers several functions and operators, such as a calculation of distance between two objects, a search for the object closest to the given object (e.g., a point), or finding an intersection of two geometric objects. The design of the actual access of a rail vehicle localization access on the track was based on the correct match of GPS information about the vehicle position (obtained fromthe communication terminals installed on a rail vehicle) with the nearest vertex and edge of the graph. The found vertex (hectometer post) then disposes of a multidimensional key in the form of a GPS coordinate and is linked to other railway-infrastructure-relating information by means of definition section of TUDU. To carry out the actual rail vehicle localization access, we used an SDO_NN (_nearest neighbour_) operator [30], which looked for a geometrical object closest to the given object (e.g., a point). In other words, the nearest vertex or model edge could be found in the current rail vehicle position (Figure 12). The actual detection of the current rail vehicle position was divided into the following steps:  
1. Search for the nearest graph vertex and edge--from the current rail vehicle position regarding the three-layer railway infrastructure model. 2. Evaluation of the relevant incoming GPS information from the communication terminal--verification as to whether the current position was loaded by an excessive error. The verification included the following assessments: 1. The distance of a rail vehicle from the nearest vertex or edge and its admissibility within the determined tolerance. 2. Was the current position related to the same _supra-edge_ as in the previous positions on the condition that it was expected to occur on it? 3. Was the azimuth of a rail vehicle motion's direction within the admissible tolerance? In the event that the current position failed to meet some of the above indicated criteria, the position was considered invalid. 3. Calculation of the accurate rail vehicle position on a model edge--by means of perpendicular point projection (the current vehicle position) on a right line (an axis of the found edge or rail).