EA013011B1 - Method for updating and using geographical data bases and spatially-distributed hybrid navigation system for realising thereof - Google Patents

Abstract

A method of updating and using geographical data bases in a spatially-distributed hybrid navigation system is characterized in that there provided a reference version of the spatially-distributed the main geographical data base 100 for the coverage zone 101, in which geographical objects are divided to separate content elements and unite into disjoint regional geographical data bases, permanently update reference version of the main geographical data base 100 by independently from each other updating diversity versions of regional geographical data bases 102, informing end users of updating data bases in the interested regions 103, updating the geographical data bases in navigation systems of end users and jointly use one or several regional geographical data bases 100, at least in one application software, implementing navigation functions in end user's navigation systems.

Description

Currently, there are three main types of ground-based navigation systems that have the English names accepted in the industry: oi-bouagb navigation systems, ou-bouagb navigation systems and hybrid navigation systems that integrate the functions of both oi-bougb and gb-bouagb systems (1Shr: //rogy1/tbekh.r1f? X | b = ai152151) 5b11b11b1111315) 2315) 1).

In the navigation system, navigation software applications and maps are stored directly on the user's device, which requires large amounts of memory and high processor performance. For example, the volume of maps for navigation in Europe can take up to 5 GB, and with the growing detail of maps and points of interest, the volume of cartographic information only increases. There are a large number of commercial devices for nav-nav navigation (see, for example, 1Wr: //towo51ggi/beu1se5/ag1/3735.111t1). which, with the help of the receiver’s OP8 receiver, allow the user to determine the current location, enter the end point of the route (address or object of interest - PO1 - Po1p (-0G-1p (ege81)) in the system menu, calculate the route of movement and provide visual and voice directions while driving according to the calculated The navigation maps are updated by purchasing a new release.The quality of the service in this case depends on the capabilities of the software, the user interface, as well as the accuracy and completeness of the contents of the navigation translational card.

OGG-BOAGB navigation is fundamentally different from OG-BOAGB. All the necessary cartographic information is on a single operator geoserver. The user does not need to download large amounts of information directly to the device, all the required information (calculated route, taking into account traffic jams and voice guidance codes, a map of the area within the calculated transport corridor, PO1, etc.) is sent from the server to the device using high-speed data transmission (ORV8, ΕΌΟΕ, SFML, 30) at the request of the user from his mobile terminal, which can be used mobile phones with preinstalled software, performing They have an interactive connection with the geoserver and visual and voice guidance while driving along the route received from the server (see yyr: //^ ете ете. ош...... / / / й 8 8 8 8 8 8 8)). This fundamentally solves the problem of updating maps, since the geographic database is available for editing offline by the navigation services operator, who, through his own cartographic service, can quickly make changes, update the geographic databases and provide exclusively up-to-date information without disturbing the functioning of the routing process generally. The user of OGG-LOOAGB services, unlike oi-LOOAGB, does not need to independently monitor the release of updated versions of navigation maps (releases) and periodically download them to the mobile terminal. The user does not need to purchase an additional, quite expensive navigation device. However, the user of the OGG-LOGB system incurs additional costs for CPP8 traffic.

Hybrid navigation systems that combine operating modes in a single device oi-boagb and oi-boagb have all the advantages of both systems and eliminate some of the disadvantages of each of them. The user chooses for himself the most convenient mode of operation for the given situation: “OPLOAGB” - for comfortable navigation and local computing or “OGG-LOAGB” - for receiving traffic information and taking it into account when moving in real time or for traveling around the territory for which there are no cards in the mobile terminal (see 1Bp: // \\ l \ l \ '.1b5t5sch1i.ot /? | b = 1082).

An important element of any navigation system is the navigation map. A navigation map is a set of geographic data, the structure and content of which allows you to get the best routes for moving vehicles according to various criteria. The main characteristics of the navigation map are:

Content - volume, quality and variety of navigation-relevant data;

structure - data model and storage organization - data storage formats.

The data contained in the navigation map can be divided into the following types:

road network data (road network graph);

data on traffic conditions (priorities, restrictions, traffic bans, maneuvers at intersections);

data on landmarks or reference (PO1, address information);

additional data (hydrography, topography, administrative boundaries, etc.),

The basis and the main distinguishing feature of the navigation map is the presence in it of data on the road network, presented in the form of a graph with the obligatory presence of basic elements (nodes and connections). Connections are linear objects of the road network, nodes are the intersection points of linear objects of the road network. Without a logically consistent and topologically related graph, the road

- 1 013011 networks, automation of routing tasks is impossible.

Other types of data are associated with the graph of the road network based on the object-relational model. Data on traffic conditions are used in calculating the route and provide routing in accordance with traffic rules. Landmark data is also used in calculating the route and provides a search for road elements associated with a given address or ΡΟΙ. Additional data is not used in calculating routes and is used for display in order to increase awareness and orientation. The exception is data on administrative districts, when it is necessary to obtain a route between different cities or regions.

Each company that provides navigation services for vehicles, without exception, uses the above concept of organizing the storage of geographic data. The difference used in map systems is the data model (storage structure of the road network graph and other navigational information) and the storage format (shapefiles, Ogas1e, MZ ZOB Zegueg, Mu ZOB, etc.). The generally accepted industry standard for the digital representation of geographic data for navigation systems is the CIR exchange format Ι3Ο-14825-2004 (1 Шр: // \ у \ у \ у.е1ЫЬ.Г / тбех.р111т1? Епу раде = те1йобо1оду / те (аaba1а / тб ге \ ze \\ 7tb bespr deo.yt1), which determines the structure and content of the navigation database of the geographical data of the road network. Using a universal exchange format like CIR (not limited to it) allows the provider of navigation maps to convert geographical navigation data into any application form m used in one or another system op-bog or gb-bog navigation.

A navigation map in the format of a specific applied navigation application, as a derivative of a geographic database in the SIR format, requires constant updating caused by changes in the terrain: changes in traffic, construction and reconstruction of roads and road junctions, development of roadside infrastructure, etc. . The process of updating the navigation map includes the following basic operations: 1) entering new objects, 2) deleting “old” objects, and 3) changing or editing objects existing in the geographic database. The main technological technique for partial updating of geographic databases is a variety of incremental transaction methods. An incremental update model (transaction) is understood as a description of changes relative to the previous release (version) of the geographic database and corresponding maps in a particular format of the applied navigation application. After the formation and execution of the incremental transaction operation for the geographic database, a new release (version) of the geographic database is obtained, after which a series of incremental transactions are performed to obtain navigation maps in the corresponding formats of the applied navigation applications.

US Pat. No. 5,893,113 A (C06P 17/40) describes the component structure of an update transaction by which an incremental update method of a geographic database is implemented. The method and apparatus includes organizing updates to geographic database sets in a series of transactions. Each transaction contains a transaction identifier that uniquely describes the transaction, control data that includes the Dependency field, and n steps that must be performed with a set of geographic databases to complete the transaction. Each transaction step describes a change operation for a single database object. All steps of the transaction must be successfully completed to complete the transaction, otherwise the transaction will not be fully completed. At the same time, some transactions can be performed only after performing other transactions that are indicated in the Dependency field, which in the general case does not allow independent editing of various elements of the content of the geographic database. The disadvantages of this method are the sequential object-by-order and sequence-dependent nature of the execution of individual transactions in a series of transactions, as well as the significant size of the data in the transaction itself, which makes it difficult to use this method at the stage of converting data to formats of applied navigation applications, especially for op-nav systems.

US Pat. No. 7,082,443 B1 (C06P 17/30) describes a system and method for updating geographic databases using incremental transactions, in which an original version of the geographic data base is generated in which the data is organized into separate sections — parcels (NHS). The updated version of the geographic database (DG) is organized in separate sections so that each section of the updated version of the geographic database represents the same objects that were presented in the corresponding section of the original version of the GDB. An incremental update transaction is performed, which shows the differences between the sections of the updated database relative to the sections of the original version. An incremental update transaction is transmitted to devices that perform navigation functions, where they are used, to form updated sections that are used in places corresponding to sections of the original version. In this method, it is not possible to store update transactions and transaction history. In this regard, this method cannot be used if, for one reason or another, the user “skips” the execution of one or more consecutive update transactions. In this case, the user will have to buy and reinstall the latest version of the DGD in its entirety.

- 2 013011

US patent 7403851 (06/22/2008, C06P 19/00), which was selected as a prototype, describes a method for using a navigation system in which a message is issued stating that the oi-BOOGB system uses updated and non-updated parts of the GDB. The method consists in the fact that the applied navigation software application uses both the updated part of the GDB and not the updated one. The updated part of the GDB has a corresponding date or version that differs from the date or version of the non-updated part of the GD D. The method includes generating a report on the possible fact of incompatibility of the used versions of geographic databases, as well as determining the type of incompatibility for the updated and not updated sections of the GDB. This method provides for periodic (for example, once a quarter, half a year, a year, etc.) release of a new version (release) of the GDB simultaneously for all regions of the system coverage area. The method does not have the ability to permanently and simultaneously update the DGD of individual regions included in the system coverage area. Therefore, if there are any changes in the traffic conditions in a particular region, the system will not take these changes into account and will produce non-optimal or even incorrect results, at least until the release of a new release of the GDB for all regions. Notification of the presence of incompatibility of versions for different sections of the GDB is performed in the passive mode only after the route calculation program cannot correctly route the route due to incompatibility of geographical data at the border of adjacent sections. As the practice of operating navigation programs shows, in the case of a high density of the road network, the program may also lay a non-optimal route along nearby roads, ignoring the incompatibility of the data at the place of the changes. In this case, the user will not be notified of the incompatibility of the GDB data and will move along non-optimal routes, which will reduce the efficiency of using the navigation system.

SUMMARY OF THE INVENTION

The present invention allows for the permanent and independent updating of multivariate versions of the DGD of certain regions of the navigation system coverage area, actively notifying users of updated versions of the DGD of the regions of interest to them, interactively updating the regional versions of the DGD installed on the user's mobile terminals and / or laying out routes through the territories to which there are no geographical data in the mobile terminals of users, which will lead to an increase in the efficiency of using navigation tional systems.

This is achieved due to the fact that in the method of updating and using geographical databases in systems that perform navigation functions, they create the initial version of the spatially distributed main geographical database for the entire system coverage area, in which geographical objects are divided into separate content elements and combined into non-overlapping regional geographic databases permanently update the original version of the main geographic database by independently updating each other The current versions of regional geographic databases inform the end users about updating the regional geographic databases of interest to them, update the geographic databases in the navigation systems of the end users and share at least one regional geographic database and data from the main geographic database in at least one application software application that performs navigation functions in end-user navigation systems.

For permanent and independent updating of regional DGDs, each regional geographic database has an additional content element such as a regional boundary point, at least including an identifier for a boundary point, coordinates of a boundary point, an identifier for a geographical object, a name for the content element, a serial number for a point for areal objects, and an identifier adjacent region and the accuracy category of positioning of the boundary point, which is determined by the accuracy of measuring the position of the point on the local STI

When updating the initial version of the main geographic database and versions of regional geographic databases of different times, they simultaneously or sequentially temporarily unpin at least one piece of geographic data within the borders of the current region; make the required changes to each detached area; Recognize and resolve data conflicts between different content elements within the updated region and at least attach at least one updated section of geographic data to the current regional geographic database; perform a summary of geographic features along common borders with at least one adjacent region in the regional geographic database of the current region; form an update transaction for the current region; transmit the update transaction of the current region to the main geographic database; updating a copy of the regional geographic database in the main geographic database by processing an incoming update transaction from the current region; identifying an updated version of the geographic data for the current region in the main geographic database; determine the regions adjacent to the current region in which you want to update the positioning of the boundary points; form the update transaction of the coordinates of the boundary points for each adjacent region; perform update operations on the coordinates of boundary points for copies of regional geographic databases of adjacent regions in the main geographic database

- 3 013011 data; identify updated versions for each contiguous region; replace in the main geographic database previous versions of regional geographic databases for adjacent regions; save update transactions for each updated region; transmit to the current region the identifiers of the new version for the regional geographic database; transmit to each adjacent region identifiers of new versions for regional geographic databases with the corresponding update transaction of the coordinates of the boundary points; register identifiers received from the main database for the new version of the regional geographic database in the current region; process the updates of the boundary point updates received from the main database in each adjacent region; Assign the obtained identifiers for updated versions of regional geographic databases and save the update transaction for the current region and the update transaction of the coordinates of the boundary points for adjacent regions.

After that, the end users are notified about updating the regional geographic databases of interest to them using text (8M8, e-mail) or audio-visual multimedia messages (MM8) transmitted via wireless channels (6РК.8, ΕΌ6Ε, 3Ό) or via 1п1сгпс1 channels .

At the request of users, they update geographic databases in navigation systems of end users. When updating the geographic databases in the navigation systems of end users, the identifiers of the current version of the regional geographic database installed in the user's navigation system are transferred to the geographic database of the corresponding region; select all intermediate update transactions that are recorded between the date of the current version of the user and the date of the latest version of the regional geographic database; copy all selected transactions; sequentially restore the version of the regional geographic database on the date of the current version and form an update transaction relative to the latest regional version; compile the update transaction in the desired format of the user's navigation system; transmitting the update transaction to the navigation system of the end user; and performing the update transaction on the navigation system of the end user.

By updating the geographic data on mobile op-based devices, users share one or more regional geographic databases in the navigation applications installed in the navigation op-systems and / or on the regional navigational server serving one or more regions, or use the data of the main geographic database in the applied navigation programs installed on the central navigation server OGG-LOG server serving all regions of the coverage area that system.

To implement the method, a hybrid navigation system is used comprising a central subsystem associated with at least one regional subsystem, which is associated with at least one end user subsystem.

The central subsystem includes a module for updating and storing the main geographic database, containing the main geographic database and the associated transaction processing unit; a module for compiling and controlling versions of a geographic database, containing a transaction archive of a service area associated with a unit for restoring versions of a geographic database and a compilation unit; application navigation software module; a control module containing a unit for interacting with regional subsystems: a unit for interacting with OGG-LOGO systems and a control unit for inter-regional exchange of optional maps: and a communication module associated with at least one regional subsystem, with the main geographical database being linked to the compilation unit and the version recovery unit, the transaction processing unit is connected with the transaction archive of the service area and with the interaction unit with regional subsystems, which is connected with the communication module, Associated with the control unit for inter-regional exchange of optional maps, the module of applied navigation programs is connected with the compilation unit and the unit of interaction with the OGG-LOGO systems, which is connected with the communication module.

The regional subsystem includes a module for updating and storing a regional geographic database containing a regional geographic database associated with a transaction generation and processing unit and at least one geographic data editing unit; a module for compiling and version control of a geographic database containing a region’s transaction archive associated with a version recovery and user transaction generation unit that is associated with a compilation unit and a regional geographic database; application navigation software module, a control module comprising an interaction unit with a central subsystem, a control module for inter-regional exchange of opt-in maps associated with a control and user interaction unit, and a communication module, wherein a regional geographic database is connected to a compilation unit, a formation unit and transaction processing is connected with the region’s transaction archive, the interaction block with the central subsystem and the control and user interaction block, the module dnyh navigation programs associated with the compilation unit and a user management and communication unit, which is linked to Campiglio unit

- 4 013011 units and a unit for recovering versions and generating user transactions, and a communication unit is connected to a unit for interacting with a central subsystem, a unit for controlling inter-regional exchange of op-cards, a unit for managing and interacting with users with at least one user subsystem, at least with one regional subsystem and with a central subsystem.

The user subsystem includes an application navigation program module comprising an op-bogb application navigation program unit and a bog-bcb application navigation program unit, which are associated with a routing mode switching module, a user geographic database storage module associated with an op-bcb application navigation unit the program and the update transaction processing module, the module for positioning and tracking along the route, connected by the block op-logb of the applied navigation program we block Ogg-oagb application navigation software module and a multimedia user interaction, which is associated with the module switching mode routing and control and communications module that is associated with the update transaction processing module, a unit Ogg-oagb application navigation software with regional subsystem.

List of drawings

In FIG. Figure 1 shows the scope of the main GDB system and the area of responsibility of the regional GDB.

In FIG. 2 is a structural diagram of the formation of the BGD in the area of the system coverage.

In FIG. 3 shows a preferred arrangement for organizing the main GDB.

FIG. 4 illustrates the principle of generating a version of a temporary DGD when updating geographic data within a region.

In FIG. Figure 5 shows the option of defining a data region in which data conflicts are possible in multi-user editing mode.

FIG. 6 illustrates an example of multi-user editing of various content elements when updating a regional GDB.

In FIG. 7 is a structural diagram of an upgrade transaction package.

In FIG. 8 is a diagram of updating the main GDB.

FIG. 9 illustrates possible options for relationships between objects of one content element located in adjacent regions.

In FIG. 10 illustrates an example of a Boundary Points content element.

In FIG. 11 shows a diagram of the transition between the states of the local BHD.

In FIG. 12 is a structural diagram of an update transaction package for user DGDs.

In FIG. 13 is a schematic block diagram of a spatially distributed hybrid navigation system.

In FIG. 14 is a block diagram of a central subsystem.

In FIG. 15 is a block diagram of a regional subsystem.

In FIG. 16 is a block diagram of a user subsystem.

DETAILED DESCRIPTION OF THE INVENTION

I. Formation of the main DGD from the regional DGD.

In FIG. 1 shows the coverage area 101 of the main geographic database (GDB) 100. The main GDG contains data that represents geographic features in the scope. The scope may correspond to the whole country such as the Russian Federation. Alternatively, the scope may correspond to several countries such as the Russian Federation, Kazakhstan, the Republic of Belarus or China and India, etc.

The coverage area 101 of the main DGD 100 is divided into separate regions 103, which serve the regional DGD 102. The combination of the main DGD and regional DGD forms a distributed system for the formation of the DGD in the coverage area (Fig. 2). The main DGD is stored on the central server of the system 200. The central server 200 manages the regional servers 201, on which the regional DGDs are stored, through 1p1sgps1. Each regional server 201 has a multi-user network for editing geographic data 206, which ensures the formation and maintenance of the relevance of the regional GDB to the corresponding region (1-, 2-, ..., p-th). The data sources for updating the regional DGD are various local geographic databases 205 (regional, municipal, etc.) and mobile field teams for collecting and verifying geographical data 204. Data sources for updating the main DGD 200 are data from regional DGD 201.

The DGD formation scheme provides for the rapid collection and updating of data on terrain objects belonging to the system 101 coverage area. The update is carried out on the basis of synchronization of different-time data from the regional DGS 201 and the main DGD 200. Each regional DGD 201 has a multi-user editing network 206, which updates geographic data on relevant region.

- 5 013011

The multi-user geographic data editing network 206 allows multiple editors to simultaneously edit the same spatially related objects. Each editor works with his own version of the DGD at workplace 203, independently of other editors. Management and storage of versions is carried out by the catalog of versions of the region 202. As a result, after all corrections have been made, corrections are made with the edits of other editors, identification of possible conflicts and their elimination.

In multi-user editing mode, a database fragment is temporarily detached from a common regional GDB to a specific area, transferred to the editor's computer 203, and the geographic data inside the area is updated in an offline editing session, which can take from several minutes to several weeks. Or the editor can unpin part of a large geographic database to the laptop 204, take it with him and carry out verification and correction of data directly in the field. Then, all adjustments are placed back into the regional geographic database 201. This is done by applying detachment and attachment transactions. At the same time, several users are engaged in the creation and processing of a shared database and exchange only new or updated data through a local area network based on a specific scheme. The version catalog of region 202 captures the categories of data for the editor’s area of responsibility, which are subject to updating, and tracks conflicts between editors.

II. Organization of geographic data in the GDB.

The organization of geographic data in the main GDG 200 is carried out spatially, by content elements and by packages. At the same time, standard object-relational spatial database management systems are used for data storage (for example, MB BOB Betuet, Ogas1e and 1VM ΌΒ2).

a. The spatial organization of geographic data.

In FIG. 3, the main BHD 300 combines the geographical data from the regional BHD 302 (1, ..., p). Regional DGD 302 contains data that represents geographic features in a specific region 305 that is part of the scope of the system 301. The region is determined by the degree of spatial detail of the main DGD 300. For example, it can be a division into federal districts, or into regions, or republics . A more detailed division is possible, but division into regions such as Moscow Region, the Republic of Tatarstan, etc. is preferable.

The territorial areas of responsibility of 305 regional DGDs 302 cannot overlap and include each other. Objects included in the area of responsibility 305 of the regional DGD 302 can be recorded in only one DGD. For example, the regional DGD of the Moscow region cannot include objects that are within the boundaries of the coverage of the regional DGD of the Tver region. In a situation where one region is spatially located within the borders of another (for example, Moscow and the Moscow region), the above rule is also observed.

In the main GDD 300, a regional section 302 is organized for each region, in the form of a copy of the regional GDG 302 of the corresponding region 305. The boundaries of the region are initially fixed at the time of the creation of the distributed data collection system and are recorded in the data storage model of the main GDD 300.

Organization of a copy of the regional DGD 302 in the main DGD 300 is carried out logically. Each object of the main BGD 300 has a double key. The first key uniquely identifies the object's belonging to the region 305 (regional DGD 302). The second key identifies the uniqueness of the object within the region (regional DGD). Also in the main DGD 300, elements are fixed that establish logical connections between objects separated by the boundaries of the region.

b. Organization of geographic data by content elements.

The main BDG 300 preferably includes the following generalized data categories, each of which is divided into content elements 303:

transport networks, presented in the form of a graph structure, for each element of which a list of attributive data is determined (including road, rail and water);

vehicle traffic conditions, including maneuvers at intersections, directions, restrictions, traffic restrictions, etc .;

landmarks, including points of interest, information road signs, names, etc .; additional information for orientation and organization of movement, including information on hydrography, administrative units, land management, etc .;

reference information, including any social, political, demographic, cultural, etc. information about objects of the area that are not included in the above categories (for example, schedules, list of services, duration of service and availability of services).

- 6 013011

from. Batch organization of geographic data.

Each content element 303 belonging to a particular region is divided into packages 304, in which the number of records about the objects of the content element is fixed. All entries are sorted by key. The number of entries in a packet can be arbitrary, but it is preferable (for software purposes) to use a number encoded with 1 byte (0-255) or 2 bytes (0-65535). The number of records in packages belonging to one content element is necessarily the same. If the last packet is incomplete, then the remainder is filled with zeros.

The position of each record about the object of the content element inside the package is fixed. The record size is unchanged and is equal to the sum of the sizes of the data types of the attributes included in the record. Accordingly, the size of the entire package is also unchanged. Knowing the packet size and record size, you can uniquely identify the record in the packet by assigning a shift from the beginning of the packet.

Content elements 303 of each region 305 are organized into packages 304 and are interconnected based on an object-relational model. The sequence of packets of the content element is fixed, i.e., the position of the packet relative to other packets of the content element is unchanged.

III. Updating the regional BG D.

but. Defining the boundaries of geographic updates for temporary detachment sites.

When updating a regional DGD, first set the boundaries of the update site within the boundaries of the region. There are several preferred options for setting the boundaries of update sites (areas of responsibility of editors in multi-user mode).

One preferred option for defining the boundaries of the update site is the option of defining boundaries based on the administrative division of the region, FIG. 4. The boundaries of the site are determined by analyzing the territorial affiliation of the changes proposed for input to the administrative region. For example, data entry on a new road is supposed. Geographically, the road belongs to a certain administrative unit 402 (district, city, microdistrict, etc.), which is part of the region 403, or to several administrative units. In this case, the boundaries of the area to be updated will be the generalized boundaries of the administrative units to which the road belongs. The boundaries are determined in a similar way for any other objects to be entered or modified. This preferred option assumes the presence of metric data on the boundaries of administrative units in the regional GDD 400.

Another preferred option for defining the boundaries of the update site is the option of defining boundaries based on the nomenclature layout of sheets of topographic or other types of maps. Borders are determined by analyzing the territorial affiliation of the changes proposed for input, to the nomenclature sheet (cell or parcel of a given shape and size) 404. For example, it is supposed to enter data on a new road. Geographically, a road belongs to a specific stock list, for example, a topographic map or a group of stock lists. In this case, the boundaries of the site of the terrain to be updated will be the generalized boundaries of the nomenclature sheets to which the road belongs. The boundaries are defined in a similar way for any other objects that are subject to input or change. This preferred option assumes the optional availability of metric data on the borders of the nomenclature sheets in the regional GDB 400. The nomenclature markup can be obtained programmatically.

Another preferred option for defining the boundaries of the update site is the option of defining the boundaries of arbitrary shape. Borders are determined by analyzing the territorial affiliation of the changes proposed for input to the editorial needs of the operator. For example, it is supposed to enter data on a new road. An operator in any form can draw a border so that the road belongs to the received section. In this case, the boundaries of the area to be updated will be those drawn by the editor. The boundaries are defined in a similar way for any other objects that are subject to input or change.

Another preferred option for setting the boundaries of the update site is the option of automatically setting boundaries according to certain criteria. Borders are determined by analyzing the territorial affiliation of the changes proposed for input, the requirements for certain editorial criteria. For example, it is supposed to enter data on a new road. The operator determines the criteria by which the boundary of the section will be determined (by the accessory of objects crossed by the new road, by the width of the new road coverage band, etc.). The boundaries are determined programmatically, taking into account the criteria set by the editor. In this case, the boundaries of the area to be updated will be the boundaries received by the program. The boundaries are defined in a similar way for any other objects that are subject to input or change.

- 7 013011

b. Formation of temporary DGD on the updated site.

After setting the boundaries of the update site, a temporary GDG 401 is formed by unpinning geographic data from the regional GDG 400. The corresponding data from the regional GDG 400 are unfastened to the workplace of the editor 203, and the following information is recorded in the version catalog of the region 202:

version identifier, which is a unique key that identifies the version of the temporary GDB 401 among the many versions at the time of editorial work;

the boundaries of the plot 402, determining the spatial localization of the temporary BGD 401;

content elements with a copy of records of objects including a list of content elements to be updated with a list of objects entering and crossing the boundaries of the area to be updated. Also records are recorded about objects of content elements that are associated with content elements to be updated, logically according to the data model;

identifiers of boundary objects (crossing the boundaries of a site), fixed in order to resolve conflicts during an attachment transaction.

The content elements to be updated are determined by the editor depending on the tasks for updating and the data model of the regional GDG 400. For example, when updating the geometry of the road network, the following content elements are taken: "road network elements" and all table elements associated with this category (subordinate) according to the data model. The model of the temporary BGD 401 corresponds to the model of the regional BGD 400.

c. Entering changes to the temporary DGD.

When editing a temporary BGD 401, the editor performs three basic operations: adding objects (records about objects);

deleting objects (records about objects);

editing objects (changing the geometry and / or attribute values of records about objects).

After editing the temporary BGD 401, an updated version is recorded in the version catalog of the region 202. Based on a comparison of the original and updated versions, an update protocol is generated.

6. Updating the current version of the regional BG D.

Regional GDG 201 (Fig. 2) stores the current version of the GDG in the region. The current version of the regional GDG is synchronized with the data of the main GDG 200 and is updated only upon receipt of a response transaction (on the receipt of an update transaction from the corresponding region) from the main GDG. In the version catalog of region 202, in addition to temporary editors, a copy of the current version of the regional GDB is stored, which is constantly updated by editors through a distributed editing network 206.

When updating the current version of the regional DGD, conflict situations may arise that violate the consistency protocol (1Wr: // \ y \ y \ u.tTsTs.Gi / 6erag1teSH / 6a1aBa5e / o1ar / 8 /). when changes made by one editor conflict with changes made by other editors. In FIG. Figure 5 shows the situation when the first editor updated the temporary DGD to the site of the area corresponding to the update site of the type of map sheet 500, and the second editor updated the DGD to the site of the area corresponding to administrative unit 501. The boundaries of the sites can be of any shape.

To resolve conflicts in the version catalog of the region 202, 503 changes (update protocols) of two editors are compared to a common work area 502. Compare all added, deleted and editable records of objects belonging to or intersecting a common work area or records of other elements connected according to the logical data model content. The comparison is carried out by evaluating the identifiers and geometry of the objects of the corresponding content elements. If conflicts arise, they are resolved by software. In cases where the contradiction cannot be resolved, the editor is proposed to be resolved with a higher priority.

Example 1

In FIG. Figure 6 shows the situation in which two editors updated the data on the same area 601, i.e. at the time of the “start of work” they had the same version of the regional DGS 600. The first editor updated the road network 602, the second editor collected data on points of interest 604. After the work was completed, a conflict arose due to the uncertainty of the binding of the point of interest 603 (GO = 00_31, “emergency telephone number”) to the road element (GO = 00_3). After updating the data, the first editor of the road element with (GO = 00_3) was gone. Instead, two new road elements appeared (GO = 00_21, GO = 00_22). Based on the data of the version catalog recorded during the comparison of versions 503 and the location of the point of interest, this conflict can be resolved by “linking” the point of interest (GO = 00_31) to the road element (GO = 00_22) 605, and then attach the corresponding versions 500 and 501 to the regional DGD 600.

- 8 013011

IV. Updating the main GDB.

After updating the current version of the regional GDG, a transaction is generated to update the corresponding data of the main GDG. The update transaction represents a structured data set and is formed by comparing the state of the initial data of the regional GDB (current version of the GDG) and the data state of the updated regional GDG (new version of the GDG).

For each content item individually, all deleted objects are selected. Each entry of any content item has a delete bit. If the status of the delete bit is 1, this means that this record was deleted during the update of the GDB. Then, objects whose geometry and / or attribute values have changed (editable objects) are selected. The packages that include editable and deleted objects (updated packages) are determined and comparison masks for the updated package are calculated. The mask is determined by bitwise comparison of the source and updated packages according to the rules given in table. one.

Table 1

Separately, all new objects are highlighted.

a. Formation of an update transaction package.

After all the above steps are completed for each content element, a common update transaction package 700 is formed, FIG. 7. The package includes a header 701, a shift table 702, and a data table 703.

The package is formed by sequentially forming a data table, a table of shifts, a header and compression of all data. In the data table 703, for each content element 710, comparative masks for the corresponding packages 708 are written sequentially, a list of records of new objects 709. Based on the data table 703, a shift table 702 is formed. The shift table 702 determines the data structure of the data table 703. It records the shifts from the beginning a file of content elements 704, packages 705, added 706 objects. Based on the shifts, it is possible to uniquely identify the transaction elements necessary for updating the main GDB.

Header 701 determines from which region a given transaction is generated, as well as the date the transaction was generated, i.e., the main transaction identifier among the many transactions coming from this region. After the formation of the header, the packet is compressed and sent through the channels 1p1sgps1 to the main GDB.

b. Processing regional update transactions.

In FIG. Figure 8 shows the update scheme of the main DGD 800. Transaction updates 802 are received from many regional DGD 801. The software of the main DGD 800 receives transaction packets and unpacks them. The header determines which region the transaction came from. Based on the contents of the shift table, the corresponding content items 803 are unfastened from the main GDB 800. The corresponding packages are selected from the content items. As mentioned above, records about objects in content elements are sorted by identifier and synchronized between the regional and the main DGD. Bitmap comparison masks are applied to packets. At the end of the list of entries for content elements, add entries about new objects (keeping order by the identifier of the civil defense).

When replacing data, an analysis of the spatial and logical integrity of the main GDB is carried out. Spatial integrity consists in observing the topological rules of spatially related objects of the content element of adjacent regions. Logical integrity consists in observing logical relationships according to the data model between spatially related objects of the content element of adjacent regions. FIG. 9 illustrates possible options for relationships between objects of the same content element located in adjacent regions.

Example 2

Border 902 separates two adjacent regions, respectively, GO1 = 00_ * 1 (the right region from the border) and GO1 = 00_ * 2 (the left region from the border). From the regional DGD responsible for generating data to the “right region”, an update transaction with two new content elements came to the main DGD: Forests (GO2 = 00_ * 3) 906 and Road Communications (GO2 = 00_ * 3, GO2 = 00_ * 5) 907. Analo

- On 9 013011, a transaction came from the regional GDB responsible for the “left region”: “Forests” (GO2 = 00_ * 4) 903 and “Road communications” (ΙΌ2 = 00_ * 3, GO2 = 00_ * 4) 901.

In FIG. 9 spatially connected objects are: 903, 906 - for the element of content "Forests"; 900, 905 - for the content element “Road connections”. After the transactions are completed, geometric inconsistencies of type 908 may arise, which may affect the correctness of the construction of the graph of the road (railway, river) network. To maintain topological integrity in the main GDB, a summary of the boundary points of spatially related objects (00_ * 3, 00_ * 4) 908 is made. To maintain logical integrity in the main GDB, data are bound by the identifier of the object.

In a preferred embodiment, this problem is eliminated by adding an additional content element to the regional DGD, in which boundary points for linear and areal objects are fixed. The boundaries of the regions are strictly fixed for the main and regional DGDs; therefore, for areal objects, it is enough to fix two points: the beginning of adjacency to the border and the end of adjacency (determine the beginning and end according to the clockwise rule). In FIG. 10 illustrates a preferred embodiment of the Boundary Point content element, including the following attribute data:

ΙΌ points - uniquely identifies the record in the content element;

coordinates of the boundary point, coinciding with the coordinates of the point of the boundary object and belonging to the border between adjacent regions;

ΙΌ object - the foreign key of the boundary object to which the boundary point belongs; content element - content element to which the boundary object belongs; serial number of a point for polygonal areal objects;

ΙΌ adjacent region - the foreign key of the adjacent region with which the object is associated;

accuracy category - code of the metric interval of accuracy of positioning of terrain objects.

The accuracy category is determined by the number series: 1, 2, 3, .... For example, category 1, as the category of highest accuracy, includes road network objects obtained using geodetic measurements using inertial systems. Category 2 includes objects of the road network, positioning on the terrain of which was obtained by less accurate geodetic methods without the use of inertial systems. Category 3 includes objects that have been digitized according to topographic plans on a scale of 1: 500-1: 2000. Category 4 includes objects digitized by maps or aerospace images at a scale of 1: 10000-1: 25000, etc.

The content element “Boundary Points” is included in the update transaction, if it changes during the update of the regional GDB. Based on the analysis of the records of this element of the content of the regional DGS of adjacent regions, topologically related objects belonging to different adjacent regions can be uniquely identified. For this, during the update transaction of the Boundary Points content element, the main server software processes the received data. The adjacent region and the coordinates of the nearest boundary point of the corresponding content element are determined. Next, the accuracy of the corresponding boundary points is compared. If the accuracy of the new point is greater, then the point of the adjacent region is forcibly attracted to the new point. Otherwise, vice versa. If the accuracy is equal, then calculate the new location for both boundary points by averaging. Based on the obtained averaged coordinates, topological binding of the corresponding objects is carried out. Then (if this is required by the data model of the main DGD), topologically connected objects of different regions are connected logically by defining the corresponding foreign keys.

from. Synchronization of the main and regional DGD.

At the final stage of updating the main GDB, the updated content elements for the corresponding region replace obsolete data. After this, a message is generated by the regional DGD about receiving data to synchronize the state of the databases. If during the transaction the main DGD was brought into compliance with the rules of topological and logical integrity, then in this case response transactions are generated for those adjacent regions whose objects were connected. The structure of the response transaction is similar to the transaction shown in FIG. 7. Upon receipt of an update transaction in a regional GDB, changes are made in the initial update transaction in order to bring it into line with the changes made in the regional and main GDG. This ensures full synchronization of the main and regional DGD.

Data on the objects of the regional DGD are always synchronized in content with the corresponding data of the main DGD. The order of recording about the object in the content element of the regional DGD corresponds to the order of recording in the detachment on the corresponding region of the data of the same content element of the main DGD. Restrictions on synchronization allow you to apply an approach to the formation of an update transaction based on one mask for comparing the source data packet of the content element with the updated packet. The comparison mask captures only bitwise changes. As a result, the resulting set of bits is compressed with a high degree of compression. In this case, the larger the packet size, the greater the compression ratio. This increases the efficiency when transferring a transaction through channels 1p1sgps1.

Packet data splitting also reduces the amount of update transaction data. The splitting of the content element into packages occurs after the exclusion of records about objects that were deleted during editing. For packages in which no changes have occurred (changes associated with editing attributes), a comparison mask is not generated and data about it is not received in the update transaction. The update transaction includes masks of only those packages in which the changes occurred. New entries about content element objects added to the regional DGD during updating are not taken into account when dividing the content element into packages. Records of new objects are sorted by identifier and combined into a separate package. This package is written to the data table of the update transaction, at the end of the section of the corresponding content element. This approach to structuring the update transaction is caused by the fact that there is no need to create a comparison mask for new records. The mask for the new entry will correspond to the entry itself.

V. Maintaining an update transaction archive.

To track the history of changes in the regional DGD, an update archive is created, which represents a database for storing update transactions. Each transaction after updating the main DGD and synchronizing the regional and main DGD is recorded in the update archive of the regional DGD. The transaction identifier is the date of synchronization of the regional and the main BG D.

The update archive of the regional DGD allows you to track the history of its changes and obtain, if necessary, the status of the regional DGD on a given date. Do this by obtaining reverse transactions based on direct transactions (update transactions). In FIG. 11 shows a diagram of the transition between the states of the regional BHD. The difference between the states is laid down in the update transaction. For example, transaction 2 uniquely identifies all the differences between the 2nd and 3rd states of the regional GDB. Regional DGD is always in its current state, i.e. at the time of the last update. If it is necessary to obtain any previous state, then it is necessary to apply reverse transactions sequentially in the reverse order until the required state of the regional GDB is obtained.

The reverse transaction is formed on the basis of the update transaction (see Fig. 7). New objects are transferred to the category of deleted objects. And bit masks with the inverse comparison law are applied to the corresponding packets according to the rules given in table. 2.

table 2

Current state Previous state Comparison mask one 0 one 0 one one one one 0 0 0 0

To track the update history at the level of the main DGD, an update archive is created in the form of a database for storing update transactions received from regional DGDs. The archive of updates to the scope and the principle of its operation is similar to the regional archive with the exception that the transaction identifier is not only the date of synchronization of the regional and main DGDs, but also the identifier of the region from which the transaction came.

VI. Updating user-defined versions of regional GDB.

Data on the objects of the user DGD installed on the mobile terminal at the time of its acquisition is always synchronized in content with the corresponding data of the regional DGD (according to the data format of the user DGD). Over time, the state of the regional BHD changes. The history of changes is recorded in the regional DGD update archive.

The regional subsystem records information about the user (client database). Each client of the system is assigned an identification number, and information on the format and release of the user DGD is attached to it (see Section VII “Spatially Distributed Hybrid Navigation System”).

When a user requests an updated version, a transaction for updating the user GDB is formed.

The user update transaction is a structured data set and is formed based on a comparison of the initial state of the regional GDB data and the state of the GDB data of the user. Based on the data of the update archive, the state of the regional GDB is obtained at the time the user acquires the data. Then, two versions of the DGD (the original and the received) are compiled into the format of the user DGD. Based on the received versions, an update transaction is generated.

A user update transaction is formed similarly to the update transaction of the main GDB with some exceptions. For each element of the content separately carry out the determination

- 11 013011 division of all remote objects; the formation of new packages based on the updated version of the regional DGD; identification of objects that have changed attribute values (updated objects); definition of packages that include editable objects (updated packages); calculation of the comparison mask for each editable package (the mask is determined by bitwise comparison of the original package and updated in accordance with Table 3) and the identification of new objects.

Table 3

In FIG. 12 illustrates the structure of a transaction package for updating a user-wide DGD. After the above steps are performed for each content element, a common update transaction package 1200 is generated. The package includes a header 1201, a shift table 1202, and a data table 1203.

The formation of the package is carried out by forming a data table; formation of a table of shifts; header formation and compression of all data.

First, a list of deleted object identifiers 1208, comparative masks for corresponding packets 1209, a list of records of new objects 1210 are sequentially written to the data table 1203 for each content element 1211. A shift table 1202 is generated based on the data table 1203.

The shift table 1202 defines the data structure of the data table 1203. Shifts are fixed in it relative to the beginning of the file of content elements 1204, packets 1205, added 1206, and deleted objects. Based on the shifts, the transaction elements necessary for updating the user-wide DGD are uniquely identified. For example, knowing the offset relative to the beginning for * 1 content element 1204, the offset relative to the beginning * 1 of packet 1205 and the data type of the record identifier of the content element 1208, a list of identifiers of deleted objects can be distinguished.

Header 1201 determines from which region this transaction is generated, as well as the date of formation (the main transaction identifier among the many transactions coming from this region).

After the formation of the header, the packet is compressed and sent either via wireless communication channels (ORKB, ΕΌΟΕ, 3Ό), or via 1p1sgps1 channels to the user GDB.

User GDB software accepts transaction packages and unpacks them. Based on the contents of the shift table, the corresponding content elements are unfastened from the user DGD.

Entries corresponding to the identifiers of the deleted objects in the update transaction are deleted from each content element. After that, entries in the content elements are shifted and new packages are formed (as mentioned above, records about objects in the content elements are ordered by identifier). Appropriate bitwise comparison masks apply to new packages. At the end of the list of entries for content elements, entries are added for new objects (keeping ordering according to GO). After that, the updated content elements replace the outdated data in the user GDB.

To implement the method, a spatially distributed hybrid navigation system is used.

VII. Spatially distributed hybrid navigation system.

In FIG. 13 is a schematic block diagram of a spatially distributed hybrid navigation system. It consists of a central subsystem A, connected via channels 1n1egpe1 with a set (1, ..., n) of regional subsystems B, each of which interacts with the high-speed data transmission tools (ΟΡΚ.8, ΕΌΟΕ, 0ΌΜΑ, 3Ο) or different number (1, ..., t) of user subsystems B registered in the corresponding region.

The central subsystem of FIG. 14 includes an update and storage module for a main geographic database 1430, comprising a main geographic database 1431 and an associated transaction processing unit 1432; a module for compiling and version control of a geographic database 1440, comprising a transaction archive of the coverage area 1441 associated with a unit for recovering versions of a geographic database 1443 and a compilation unit 1442; 1410 applied navigation software module; a control module 1420, comprising a unit for interacting with regional subsystems 1421, a unit for interacting with OGG-LOOBG systems 1422, and a control unit for inter-regional exchange of op-LOBATB

- 12 013011 with cards 1423, and a communication module 1450 associated with at least one regional subsystem B, while the main geographic database 1431 is associated with the compilation unit 1442 and the recovery unit versions 1443, the transaction processing unit 1432 is associated with the transaction archive of the service area 1441 and with a unit for interacting with regional subsystems 1421, which is connected to a communication module 1450, associated with a control unit for inter-regional exchange of op-cards, 1423, a module of applied navigation programs 1410 is connected with a compiler unit 1442 and a unit for interacting with the OGG-Boagb systems 1422, which is connected to the communication module 1450.

Each regional subsystem B ₁ (1 = 1, ..., p) shown in FIG. 15, includes a module for updating and storing a regional geographic database 1530, containing a regional geographic database 1532 associated with a transaction generation and processing unit 1531 and with the number of geographic data editing blocks 1533 necessary for a given region; a module for compiling and version control of a geographic database 1540, containing a region archive of transactions 1541, associated with a block for version recovery and generation of user transactions 1543, which is associated with a compilation block 1542 and a regional BGD 1532; a module for applied navigation programs 1510, a control module 1520, comprising a unit for interacting with a central subsystem 1521, a control unit for inter-regional exchange of op-cards 1522, connected with a control unit and for interacting with users 1523; and communication module 1550, while the regional geographic database 1532 is connected to the compilation unit 1542, the transaction generation and processing unit 1531 is connected to the region’s transaction archive 1541, the interaction block with the central subsystem 1521 and the control and user interaction unit 1523, the application navigation program module 1510 is connected with the compilation unit 1542 and with the control and user interaction unit 1523, which is associated with the compilation unit 1542 and the version recovery and user t 1543, and the communication module 1550 is connected with the interaction unit with the central subsystem 1521, the control unit for inter-regional exchange of op-cards 1522, the control unit and interaction with users 1523, with many user subsystems B registered in this region, with other regional subsystems B_ ) included in the service area, and with a central subsystem. Communication of regional subsystems with the central subsystem and among themselves is carried out through channels 1p1sgps1.

In each region, a different number of user subsystems B can be registered, the number of which can be proportional, for example, to the number of inhabitants or the number of vehicles in a given region. The user subsystem shown in FIG. 16 should include at least a navigation application program module 1610, comprising an op navigation module 1611 and an application navigation module 1612, which are associated with a routing mode switching module 1640, a user geodatabase 1620 storage module associated with the op-batch block of the applied navigation program 1611 and the update transaction processing module 1670, the positioning and tracking module for route 1650 associated with the b-block of the applied navigation application program 1611, the open navigation application block 1612 and the multimedia user interaction module 1660, which is connected to the routing mode switching module 1640, and the communication and control module 1630, which is connected to the update transaction processing module 1670, and the open navigation application navigation block programs 1612 and with the regional subsystem B.

All functional modules and blocks of the central, regional and user subsystems can be implemented on modern hardware and software.

In the central and regional subsystems, the modules of applied navigation programs (1410 and 1510) are executed in the form of software applications implemented on the basis of standard GIS functions and additional special user functions that provide the solution of optimization problems of calculating movement routes (see, for example, yyr: // уеЬта8ка .sot / Rgobis18 /). The compilation and version control module for the DGD (1440 and 1540) includes a transaction archive block (1441 and 1541), which is implemented on the basis of standard DBMS functions such as Mktokoi 8OB 8et; a compilation unit (1442 and 1542), which is implemented as a software application that converts data from one format to another based on attribute information matching schemes, and a version recovery and user transaction generation unit (1443 and 1543), which is implemented as a software application, implemented based on the technology described above.

The control modules (1420 and 1520) are implemented in the form of software applications based on XMB technologies (see, for example, 1Bp: // \ y \ y \ y.tPes11. \ YeBe8uyu18.yi / Ts / t1egpe1 / x1n1 / ag3.1it1) .

Modules for updating and storing the main and regional DGDs are software applications implemented on the basis of DBMSs of the type Ogas1e or Mktokoy 8OB 8et and GIS of the type LTSS18 (see yyr: //ba1ar1i8.gi/8oy/E8K1/tbekh.yt). The communications module (1450 and 1550) is implemented in the form of a software and hardware complex based on network equipment providing the physical, channel, network and session level, according to the O81 standard (see 1 Шр: // \ у \ у \ у.шйо8У81ет .gi / 81apbag1 / 81apbag (octct!).

- 13 013011

In user subsystem B, the module of applied navigation programs 1610 consists of two blocks: the optional navigation application 1611 and the general navigation application 1612, which are executed as software applications implemented on the basis of standard functions of navigation applications (see, for example, yyr: //^^^.р1uad.sot/tyeh.yyr? 1y = 492), which provide the solution to the problems of constructing a route for the block oi-boobb and interpreting the route for the block oi-boobb. The storage module of the user DGD 1620 provides the solution of the problems of storing and retrieving data in the device memory and is implemented on the basis of the standard functions of the DGD (see, for example, 1Bp: // \ y \ y \ y. .1it1). The 1630 control and communication module performs the functions of connecting to the regional subsystem, receiving routes from it and checking access possibilities, as well as updating the user-wide DGD, if necessary, and is implemented on the basis of the technologies UeB-5GG1Ce5 and XMB technologies (see, for example, 1i1p: / (bb5eptg.y/\5/\\'5.1it1).

The routing mode switching module 1640 performs the task of selecting the navigation mode oGG-ioagb or oi-ioatt. The module for positioning and tracking along route 1650 is responsible for positioning with any available positioning tools, such as CP8, GLONASS, LV8, etc., as well as for tracking along the route and recalculating the route when deviating from a given route. The multimedia user interaction module 1660 contains all the necessary functionality for interacting with the user, including visualization of the interface and receiving control commands from the user. These modules are implemented in the form of a software and hardware complex made using standard functions of the platform AP1 devices implemented in programming languages such as 1aua, C ++ (see, for example, yyr: //t8bp.t1sgo5oy.ot/ep-e8/11 / t8840702.a8rh, 1Shr: //raua.y1p.ot/) auate / gegegeps / ar15.) 5r.

yyr: //yyue1oreg.arr1.e.ot/1ryyope/ or yyr: //yyue1oreg.apygo1y.yot/t11/gi/ge1geepse/rakeK.e8.yt1), and technical means, such as displays, control keys and positioning devices. The update transaction processing module 1670 performs the functions of updating the user DGD and is implemented as a software application based on technologies for accessing the built-in DB (see, for example, 1Bp: // \ y \ y \ y.ogas1.e.sot / ba1aaa5e / bgke1eu-b / xt1 / tex.1it1) and XMB technology (see yyr: // \ y \ y \ y. | bt.sot / geee1oreg \ wogk5 / gi / xm1 /).

Viii. The use of BHD in a spatially distributed hybrid navigation system.

The described method for updating and using geographical databases, as well as the operation of a spatially distributed hybrid navigation system, is illustrated by the example of the implementation of a number of basic technological processes performed during the operation of such systems.

a. Updating the regional and main DGD.

In the regional subsystem B1, the updating of the regional geographic data base 1532 is carried out by editing the geographic data in the geodata editing blocks 1533 (see section III). Then, in block 1531, an update transaction is formed (see section IV, etc.), which is transmitted through block 1521 and communication module 1550 to central subsystem A. In the central subsystem, through the communication module 1450 and the unit for interacting with regional subsystems 1421, the transaction goes to processing unit 1432. After the transaction is processed, the regional data sections in the main GDB 1431 are updated, after which, through block 1421 and module 1450, a message is received on the regional subsystem B1 to synchronize the state of the databases data, and in the regional subsystems adjacent to,, if necessary, send response transactions to synchronize the positioning of boundary points. Next, the final transaction is sent to the archive of the central subsystem 1441, and the new version of the DGS of the coverage area of the central subsystem after compilation in block 1442 is transferred to the application navigation module 1410, which supports OGG-Nav navigation throughout the system coverage area.

After receiving a message from the central subsystem in the regional subsystem B1, the last transaction is placed in the regional archive 1541, the current version of the regional GDB 1532 is updated, and after compilation in block 1542, it is transferred to the module for applied navigation programs 1510, which provides support for UGG navigation in the territory of the nth region.

After that, the control and user interaction unit 1523 through the communication module 1550 notifies the users of the maps about the update of the map of the региона-th region. In this case, shown in FIG. 15 communications also allow notifying users in other regions as they wish.

b. Providing an optional card to a new user.

To receive an opt-in card of his (home) region, a new user from the multimedia interaction module 1660 through the control and communication module 1630 of user subsystem B makes a request to receive the latest version of the opt-in card of the required format in the regional subsystem B1. The received request through the communication module 1550 of the regional subsystem is sent to the control and user interaction unit 1523. Block 1523 registers the incoming request and generates a control request to the transaction generation unit 1531, which transmits the corresponding instruction to transmit the latest version of the regional GDG 1532 for compilation

- 14 013011 in the required format to block 1542. After compilation, the regional GDB in the required format is sent by the module 1523 through the module 1550 to the user subsystem B, where it is transmitted through the control and communication module 1630 and the transaction processing module of the update 1670 to the storage module of the user GDB 1620. After this user subsystem becomes ready for the implementation of op-navigation navigation in the "home" region.

from. Providing op-cards with another region.

If the user requires an op-geo-map for one or several adjacent regions, the user from the multimedia interaction module 1660 through the control and communication module 1630 of subsystem B submits a request for the latest version of the op-geo-card for the desired region in the required format in his regional subsystem B1. The received request through the communication module 1550 of the regional subsystem is sent to the control and user interaction unit 1523. Block 1523 registers the incoming request and forwards it to the central subsystem A to the interregional exchange control unit of op-cards 1423. After the request is registered in block 1423, the request from the central subsystem is sent to the corresponding regional subsystem B_), which stores the desired geographic database. In the regional subsystem B_), through the module 1550 and the control unit for inter-regional exchange of op-cards, the request 1522 is received and registered in the control and user interaction unit 1523. After registration, the block 1523 generates a control request to the transaction generation unit 1531, which transmits the corresponding transfer instruction the latest version of the regional GDG 1532 for compilation in the required format to block 1542. After compilation, the regional GDG in the required format is sent by module 1523 through module 1550 to the regional sub theme B1, from which entered the original user query. The fact of receipt by the block 1522 of the op-bougb card of the region of the region is registered in the block 1523 of the bth region, after which this block issues a control command to send the op-bouagb map of the region of the region to the user subsystem with which the request came. In the user subsystem op-geoagb, the map of the geographic region of the region, through the control and communication module 1630 and the transaction processing module of the update 1670, enters the storage module of the user geodatabase 1620. After that, the user subsystem becomes ready for the implementation of op-navig in the region.

b. Updating op-map maps on the user subsystem.

After receiving a notification about updating the map of his region, the user from the multimedia interaction module 1660 through the control and communication module 1630 of the subsystem of user B makes a request to receive an update of the version of the op-map card in the required format to the regional subsystem B1. The request arrives at the control and user interaction unit 1523, which stores accounting information for each registered user. Block 1523 transfers data about the current version of the op-bog user card to the recovery unit of versions and generating user transactions 1543. Block 1543 queries the transaction archive 1541 for all transactions that came into it after the date corresponding to the version date of the b-vb user card, performs sequential restoring the GDB version to the version date of the op-bogb user card and generates an update transaction relative to the current version of the regional GDG 1532. Next, the update transaction is compiled in block 1542 to my format op-oagb card user and through the block 1523 and the module 1550 is transmitted to the user subsystem B. The control unit and the communications subsystem 1630 in the user sends the data in the update transaction processing module 1670, in which the update custom geodatabase on the region. After that, the updated custom BGD 1620 becomes ready for the implementation of op-navigation in the "home" region.

If a user of the ί-th region receives a request to update the op-bog map to the ry region, the regional subsystem B ₁ sends this request to the central subsystem A, which, in turn, forwards it to the regional subsystem B ,. In the regional subsystem B, all the steps described above are performed to form the transaction for updating the map of the map to the region, and the generated transaction is sent to the regional subsystem B ₁ , which transfers it to the user subsystem B with which the request was received. The control and communication module 1630 of the user subsystem B sends the received data to the update transaction processing module 1670, in which the user DGD is updated to the ry region. After that, the updated user BGD 1620 becomes ready for the implementation of op-navigation in the region.

e. Description of the process of op-navigation navigation.

The user from the multimedia interaction module 1660 sets the route parameters (start and end points, car, pedestrian, etc.). The control and communication module 1630, associated with the transaction processing module of update 1670 and receiving update messages from the regional subsystem B1, checks the relevance of the user DGD 1620 to the route territory. If the user op-bouagb BGD 1620 corresponds to the latest version of the regional BDB, then the module 1640 activates the op-bouagb navigation program 1611, which performs route calculation taking into account the given parameters and transfers data to the positioning module

- 15 013011 navigation and tracking along route 1650, which constantly monitors the current location of the user and issues relevant audiovisual directions for movement through the multimedia interaction module with user 1660.

D. A description of the process of navigating navigation within the “home” region.

If, during the process of checking the relevance of a user op-cards, it is found out that it is out of date, then on the display of the multimedia interaction module 1660 the user may be offered the choice of several alternatives: updating the op-cards of a card (see section VIII, или) or navigation in the OGG Bog. Each alternative will be accompanied by a proposal for the cost and estimated time required for its implementation. If the user selects the OGG-L0AGB navigation mode, the routing mode switching module 1640 activates the OGG-L0AGB navigation program 1612 of the application navigation module 1610. Block 1612 transmits the route parameters through the 1630 module to the regional subsystem B1, in which the request through the 1550 module is sent to the control unit and interaction with users 1523. After registering the route request, block 1523 transmits the route parameters to the module of applied navigation programs 1510, which calculates the route and generates pa a data ket that is returned to block 1523 and sent through the module 1550 to the user subsystem. The control and communication module 1630 of the user subsystem transmits the received data packet to the OGG-LOGB block of the applied navigation program 1612, which after processing transmits data to the positioning and tracking module along route 1650, which constantly monitors the user's current location and issues appropriate audio-visual instructions for movement through the module multimedia user interaction 1660.

e. Description of the process of interregional regional navigation.

If the route requested by the user covers several regions, then on the display of the multimedia interaction module 1660 the user may be offered the choice of several alternatives: receiving new op-cards for missing regions (see section VII, c), updating op-cards for existing regions (see Section VIII, ά), navigation in the ой-аг аг аг б или mode or other combinations of the-Ь аг аг б и and Г Г-аг аг og modes. Each alternative will be accompanied by a proposal for the cost and estimated time required for its implementation. If the user selects the OGG-OoGy navigation mode, the routing mode switching module 1640 activates the OGG-OOGY navigation program 1612 of the application navigation module 1610. Block 1612 transmits the route parameters through the 1630 module to the regional subsystem B1, in which the request through the 1550 module is sent to the control unit and interactions with users 1523. After registering the route request, block 1523 transmits the route parameters to the central subsystem A, in which the request through the communication module 1450 enters the block interacting ones with regional oh-systems oagb 1422. After the route request registration unit 1422 transmits the route options in the application navigation software module 1410 that calculates an inter-regional route and generates a data package which returns to block 1422 and 1450 through the module is sent to the regional subsystem. The response of the central subsystem through the module 1550 goes to block 1523. After registering the response of the central subsystem, block 1523 sends the data packet of the inter-regional route to the user subsystem through module 1550. The control and communication module 1630 of the user subsystem transmits the received data packet to the--о аг б блок block of the navigation application 1612, which after processing transmits data to the positioning and tracking module along route 1650, which constantly monitors the user's current location and issues the corresponding audio-visual instructions for movement through the module multimedia user interaction 1660.

IX. The advantages of the method and system.

In the proposed method, the data on the objects of the regional DGD are always synchronized in content with the corresponding data of the main DGD. The order of recording about the object in the content element of the regional DGD corresponds to the order of recording in the detachment on the corresponding region of the data of the same content element of the main DGD. Restrictions on synchronization allow you to apply an approach to the formation of an update transaction based on one mask for comparing the source data packet of the content element with the updated packet. The comparison mask captures only bitwise changes. As a result, the resulting set of bits is compressed with a high degree of compression. In this case, the larger the packet size, the greater the compression ratio. This increases the efficiency of the transaction transfer through the channels

Packet data splitting also reduces the amount of update transaction data. The splitting of the content element into packages occurs after the exclusion of records about objects that were deleted during editing. For packages in which no changes have occurred (changes associated with editing attributes), a comparison mask is not generated and data about it is not received in the update transaction. The update transaction includes masks of only those packages in which the changes occurred. New entries about content element objects added to the regional DGD during updating are not taken into account when dividing the content element into packages. New Property Records

- 16 013011 max are sorted by identifier and combined into a separate package. This package is written to the data table of the update transaction, at the end of the section of the corresponding content element. This approach to structuring the update transaction is caused by the fact that there is no need to create a comparison mask for new records. The mask for the new entry will correspond to the entry itself.

The present invention allows for the permanent and independent updating of multi-time versions of the DGD of certain regions of the navigation system coverage area, actively notifying users of updated versions of the DGD of the regions of interest to them, interactively updating the regional versions of the DGD installed on the user’s mobile terminals, and / or laying out routes through the territories which do not have geographic data in the mobile terminals of users, which will lead to an increase in the efficiency of using navigation tion systems.

Claims (15)

CLAIM 1. The method of updating and using geographic data bases in systems that perform navigation functions, which consists in creating the original version of a spatially distributed main geographic data base for the entire system coverage area, in which geographic objects are divided into separate content elements and combined into non-intersecting regional bases data; permanently update the original version of the main geographic data base by updating the multi-temporal versions of the regional geographic data bases independent of each other; notify end-users about updating regional geographic databases of interest; update geographic databases in end-user navigation systems and share at least one regional geographic database and main geographic database data in at least one application software that performs navigation functions in end-user navigation systems. 2. The method according to claim 1, in which each regional geographic database has an additional content element such as a region boundary point, at least including the boundary point identifier, the coordinates of the boundary point, the geographical object identifier, the name of the content element, the sequence number of the point for areal objects, the identifier of the adjacent region and the accuracy category of the positioning of the boundary point, which is determined by the accuracy of measuring the position of the point on the ground. 3. The method according to claim 1, in which a permanent update of the original version of the main geographic database and multi-temporal versions of regional geographic databases consists in the simultaneous or sequential temporary detachment of at least one geographic data site within the boundaries of the current region, making the required changes to each detached area; recognize and eliminate data conflicts between different content elements within the updated region and back attach at least one updated geographic data segment to the current regional geographic database; perform a summary of geographical features on common borders with at least one adjacent region in the regional geographical data base of the current region; form an update transaction for the current region; transmit the update transaction of the current region to the main geographic database; update a copy of the regional geographic database in the main geographic database by processing the inbound update transaction from the current region; identify an updated version of geographic data for the current region in the main geographic database; determine the regions adjacent to the current region in which you want to update the positioning of the boundary points; form the transaction of updating the coordinates of the boundary points for each adjacent region; perform update transactions of the coordinates of the boundary points for copies of regional databases of geographic data of adjacent regions in the main geographic data base; identify updated versions for each adjacent region; replace in the main geographic database previous versions of regional geographic databases for adjacent regions; save update transactions for each updated region; transmit to the current region the identifiers of the new version for the regional geographic database; transmit to each adjacent region identifiers of new versions for regional databases of geographical data with the corresponding transaction of updating the coordinates of boundary points; register identifiers obtained from the main database for a new version of the regional geographic database in the current region; process the boundary point updates received from the main transaction database in each adjacent region, assign the obtained identifiers for the updated versions of regional geographic databases, and save the update transaction for the current region and the boundary point coordinate update for the adjacent regions. 4. The method according to claim 3, in which portions of geographic data temporarily detached to update within the region’s boundaries contain additional data including at least the identifier of the time version, the coordinates of the boundaries of the temporal portion, the contents with - 17 013011 letters about objects and identifiers of boundary objects. 5. The method according to claim 3, which performs a summary of the geographical objects of the updated region along common borders with at least one adjacent region, taking into account the category of accuracy of positioning of the corresponding boundary points from the updated and adjacent region. 6. The method according to claim 3, wherein during the formation of an update transaction for the current region, all deleted objects are installed, all partially modified objects and all new objects form data packets that include remote and partially changed objects, and packages that include new objects, calculate one data mask for the updated package for all objects by comparing the updated package and the original one by one, form a common update transaction package, including at least a data table, a shift table and Header, and compress all the data package. 7. The method according to claim 1, in which the end-users are informed about the update of the regional geographic data bases of interest by means of text or audiovisual multimedia messages transmitted via wireless communication channels or via 1n1sgps1 channels. 8. The method according to claim 1, wherein, when updating the geographical databases in the end-user navigation systems, transfer the identifiers of the current version of the regional geographical database installed in the user's navigation system to the geographical database of the corresponding region; select all intermediate update transactions that are registered between the date of the current version of the user and the date of the latest version of the regional geographic database; copy all selected transactions; consistently restore the version of the regional geographic database on the date of the current version and form an update transaction relative to the latest regional version; compile the update transaction into the required format of the user's navigation system; transmitting the update transaction to the end user’s navigation system and performing the update transaction on the end user’s navigation system. 9. The method according to claim 8, in which the identifiers of the current version of the regional geographic database include at least the date of registration of the version and the format of the application navigation program. 10. The method according to claim 1, in which share at least one regional geographic database in application navigation software installed in the end-user navigation systems and on a regional navigation server serving at least one region. 11. The method according to claim 1, in which the data of the main geographic data base is used in the application navigation software installed on the central navigation server serving all regions of the system coverage area. 12. A spatially distributed hybrid navigation system containing a central subsystem associated with at least two regional subsystems that are interconnected and each of which is associated with at least one hybrid end-user subsystem. 13. The system of claim 12, wherein the central subsystem includes a module for updating and storing a main geographic database comprising a main geographic data base and an associated transaction processing unit; a module for compiling and controlling versions of a geographical database containing a transaction archive of a service area associated with a unit for restoring versions of a geographical database and a compiling unit; application navigation module; a control module containing a block of interaction with regional subsystems, a block of interaction with oGG-laptop systems and a control block for the inter-regional exchange of op-laptop cards; and a communication module associated with at least one regional subsystem, while the main geographic database is associated with the compilation unit and the version recovery unit, the transaction processing unit is associated with the service transaction archive and the interaction unit with regional subsystems that is associated with the communication module associated with the control unit for the interregional exchange of op-laptop maps, the application navigation module is associated with the compilation unit and the interaction unit with the oGG-coagb system and that is associated with communication module. 14. The system of claim 12, wherein the regional subsystem includes a module for updating and storing a regional geographic database comprising a regional geographic database associated with a transaction generation and processing unit and with at least one geographic data editing unit; a module for compiling and controlling versions of a geographical database containing a region's transaction archive, associated with a unit for restoring versions and generating user transactions, which is associated with a compilation unit and a regional geographic database; application navigation module; a control module containing a unit for interacting with the central subsystem, a unit for controlling the inter-regional exchange of op-carrier cards associated with the control unit and user interaction; and communications module, with the regional geographic database associated with the compilation unit, the formation unit and - 18 013011 transaction processing is associated with the archive of the region’s transactions, the interaction block with the central subsystem and the control and user interaction block, the application navigation module is associated with the compilation block and the control and user interaction block, which is associated with the compilation block and version recovery block and formation of user transactions, and the communication module is associated with the block of interaction with the central subsystem, the block of control of the interregional exchange op-lagd to mouths with user management and communication unit, with at least one user subsystem, at least one regional center subsystem and a subsystem. 15. The system of claim 12, wherein the user subsystem includes an application navigation program module comprising an op-code block of an application navigation program and an o1T-line block! an application navigation program that is associated with a routing mode switch module; the storage module of the user geographic data base associated with the operand block of the application navigation program and the update transaction processing module; the module of positioning and tracking along the route, connected with the block op-boot of the application navigation program, with the block o1T-gogs! an application navigation program and a multimedia user interaction module, which is associated with a routing mode switching module and a control and communications module, which is associated with an update transaction processing module, with an o1T-Loags unit! application navigation software and with the regional subsystem.