Methods, apparatus, and computer programs for managing map data

Abstract

This invention provides a method, apparatus, and computer program method for managing map data of digital maps. [Solution] The method involves receiving one or more map data modification requests from at least one device 101, storing one or more modifications of the modification requests 102, transmitting one or more modifications of the modification requests to a second device 103, storing one or more states of the map data, receiving a request from a third device to obtain at least a portion of a specific state of the map data 104, if the specific state of the map data is stored in the second device 105, obtaining at least a portion of the specific state of the map data from the second device 106A, transmitting it to the third device 107A, if it is not stored in the second device, applying one or more modifications stored in the second device 107B, and transmitting at least a generated portion of the specific state of the map data to the third device 108B.

Description

Technical Field

[0001] Examples of the present disclosure relate to a method, an apparatus, and a computer program for managing map data of a digital map.

Background Art

[0002] A spatial database (which may also be known as a geospatial database) is a type of database designed to store, query, and manage data representing objects within a geometric space. Such a database may be referred to as a digital map, and the data stored therein representing map objects / features may sometimes be referred to as map data. An example of a spatial database is the "TomTom Orbis Map" of TomTom International B.V.

[0003] A digital map, also known as an electronic map, may include map data representing map features, particularly navigable elements of a network of navigable elements within a geographic area. In the following description of examples of the present disclosure, the navigable elements are simply referred to as roads, and the network of navigable elements is simply referred to as a road network. However, it will be understood that in other examples, the navigable elements may be, for example, walking paths, hiking trails, bicycle paths, canals, towpaths, rivers, railway lines, etc.

[0004] [[ID=第十九]] A digital map may be used for navigation, route calculation, and / or route guidance, for example, by a portable navigation device (PND), which is a portable computing device (particularly such a smartphone) that includes GNSS signal reception and processing functionality for positioning / determining the location of the device. In this regard, such a device may have the ability to determine one or more "fixes", "raw" GNSS fixes, or "enhanced" fixes, each of which is a time-stamped geo-location. Such PNDs / devices are well known and widely adopted as in-vehicle or other vehicle navigation systems.

[0005] A digital map may contain map data representing multiple map layers. The primary / base layer of a digital map may represent primary-level elements of the digital map. Such primary-level elements are elements of the digital map that can be directly referenced, for example, through higher-level elements. Primary-level elements may represent the physical geometry and topology of a network of navigable elements, such as a network of road segments (i.e., a single road between two road junctions). A network of roads may be represented through a graph of nodes and arcs. In this regard, a road segment may be represented / defined in the primary layer by two nodes and the arc between them.

[0006] A primary layer can serve as a base / reference layer for other / higher map layers. A primary layer can serve as a reference layer that can be used by (downstream) producers of map content / higher layer map data (e.g., producers of VAD data for digital map value addition data (VAD) layers). Higher layers may include attributes and associations of attributes with specific map features (such map features themselves are defined / represented in the reference / base layer). For example, a higher map layer may represent a secondary-level element, i.e., an element of a digital map that is only referenced in the context of the related primary element (e.g., attributes of a road segment, particularly speed limits for road segments).

[0007] The state of map data for a digital map can be considered to include all primary-level elements and all secondary / higher-level elements related to the specific spatial scope of the state (e.g., the geographical extent / area represented by the map data state). The state of map data can also be considered to correspond to all elements of a particular layer.

[0008] Digital maps can be dynamically and frequently modified / updated to reflect changes / updates in their map data (e.g., map data representing geographical features, infrastructure, map feature attributes, and other relevant information). Each change or update may result in a new / updated state of the digital map. A change may be considered information about the difference between two states (X and Y) of the digital map, and it describes the modifications to the map data necessary to update state X to state Y. A change may include modifications made to primary and / or secondary level elements. A change may only include information about modifications to secondary level elements and / or modifications to map feature attributes.

[0009] A digital map may also be in the form of a versioned database, which is a type of database that maintains multiple versions or states of its data and schema over time (for example, a schema relating to the structure of the database, including tables, fields, relationships, and constraints). A digital map may also contain a continuous sequence of map data states, where a sequence of changes to the map data states is applied (sequentially) to form a continuous sequence of map data states. This allows users to track changes to the digital map, manage updates, and access (or revert to) previous states as needed. An example of a versioned database is TomTom International BV's "TomTom Orbis Map".

[0010] Each layer of a layered digital map, i.e., each individual layer, may depend on one or more users to generate updates to the map data (throughout this description, “user” does not necessarily refer to a human being, but may be interpreted as referring to a service or automated component). In this regard, a series of messages describing a set of changes to be applied to the state of the map data may be received. Traditionally, each layer may need to expose an application programming interface (API) that allows publication / access to a consistent state of the map data (so that all received changes are applied sequentially / in order), while also allowing access to a range of past versions of the state of the map data for other users to read.

[0011] Changes, i.e., received change messages, must be “squashed” / “merged” into the map data to change the map data from one state to another, i.e., applied (for example, in a sequential order corresponding to the order in which the changes were received). The set of changes may form an ordered, uninterrupted set of changes, with each change built upon a previous change. Traditionally, this may be done via either of the following methods: a. "Squash-on-Read" or "Merge-on-Read". All change messages are stored in the map database, and all changes represented by the stored change messages are applied when the map data is read. In this regard, each received change message is stored in the map database (this mere storage of received change messages is compared and contrasted with actually applying the changes of each received change message to the map data stored in the map database, so as to change the state of the map data and store the new state of the map data in the map database). In "Squash-on-Read", during a read operation, all changes from all stored change messages up to the change message leading to a specific state of the map data (for example, in response to a request for a specific state of the map data, e.g., the state of the map associated with a specific identifier and / or the most recent state of the map data) are applied sequentially to the initial / original state of the map data to produce the requested state of the map data, i.e., all changes from all change request messages up to the change message leading to the specific requested state are applied. b. "Squash-on-Write" or "Merge-on-Write". Each change is applied to the previous state at the time of writing, and each brings about a new state of map data stored in the map database. In this regard, upon receipt of each change message, the changes indicated therein are applied to the most recent state of map data stored in the map database, and the state of the map data is changed to the most recent state of map data stored in the map database. When a request is made to retrieve a specific state of map data, the corresponding state can be easily retrieved.

[0012] Traditional "squash-on-read" / "merge-on-read" databases (including certain geospatial databases) can offer smaller databases and faster write times compared to "squash-on-write" / "merge-on-write" databases. This is because, in "squash-on-read," each change must be applied sequentially to the state of the map data to form a continuous set of states of the map data (as in the case of "squash-on-write"), and instead of storing all the continuous states of the map data, only information about each change must be written and stored in the map database. However, traditional "squash-on-read" geospatial databases can offer slower read times compared to "squash-on-write" geospatial databases. This is because, instead of simply being able to read the desired / current / latest stored state as in the case of "squash-on-write," all stored changes must be applied sequentially to the base state to form the desired / current / latest state. Traditional squash-on-write geospatial databases may offer faster read performance but require larger data sets and may have slower write performance than squash-on-read geospatial databases.

[0013] Traditional methods of managing map data are not always optimal. In some situations, it may be desirable to improve the management of map data. In some cases, it may be desirable to provide improved methods for updating map data (e.g., applying changes to map data / writing map data). In some cases, it may be desirable to provide improved methods for retrieving map data (e.g., searching for map data / reading map data). In some cases, it may be desirable to provide improved methods for retrieving map data that requires changes but has not yet been applied.

[0014] Any enumeration or discussion of prior art or background in this specification should not be construed as an acknowledgment that the art or background is part of the current art or common general knowledge. One or more aspects / examples of this disclosure may or may not address one or more of the background issues. [Overview of the project]

[0015] While not necessarily exhaustive, various examples provided in this disclosure include those asserted in the appended claims. Any examples and features described in this specification that are not included in the scope of the independent claims should be interpreted as useful examples for understanding various embodiments of the invention.

[0016] According to at least some examples of this disclosure, a computer-implemented method for managing map data is provided, and the method is Receiving one or more map data modification requests from at least one device, each of which indicates a request for a change to be applied to the state of the map data in order to generate another state of the map data, To store the one or more changes of the one or more map data change requests, Transmitting one or more changes to the one or more map data change requests to a second device, wherein the second device stores one or more states of the map data. The third device receives a request to obtain at least a portion of a specific state of the map data, Determining whether the aforementioned specific state of the map data is stored in the second device, In response to determining that the aforementioned specific state of the map data is stored in the second device, From the aforementioned second device, to obtain at least a portion of the map data in the aforementioned specific state, Transmitting at least a portion of the acquired map data in the aforementioned specific state to the third device, In response to determining that the aforementioned specific state of the map data is not stored in the second device, From the two equipped devices, obtain at least a portion of the map data status, To generate at least a portion of the aforementioned specific state of the map data, apply one or more of the stored changes to the aforementioned acquired portion of the aforementioned state of the map data; The process includes transmitting at least a portion of the generated map data in the specific state to the third device.

[0017] Apparatus for carrying out the methods described above is provided, but not necessarily in all cases, according to various examples of this disclosure.

[0018] Various examples of this disclosure, though not necessarily all, provide at least one module, circuit, processing circuit, chipset, data processing device, computer, device and / or system, which includes means configured to perform the methods described above.

[0019] Through various examples of this disclosure, though not necessarily all, computer programs are provided that, when executed by the device, include instructions causing the device to perform the methods described above.

[0020] While not all examples are given, various examples in this disclosure indicate that At least one processor, The provided device includes, when executed by the at least one processor, at least one memory for storing instructions that cause the device to perform at least the method described above.

[0021] Through various examples of this disclosure, though not necessarily all, a non-temporary computer-readable medium is provided which, when executed by at least one processor, causes to perform at least the method described above.

[0022] The following parts of this "Summary" section describe various features that may be characteristics of any of the examples described in the foregoing part of the "Summary" section, with the necessary modifications. The description of a function should also be considered as further disclosing any means suitable for performing the function, or any instructions stored in at least one memory that cause the apparatus to perform the function when executed by at least one processor.

[0023] In some but not all examples, the method further comprises performing at least one verification procedure on the received one or more map data change requests.

[0024] In some but not all examples, the at least one verification procedure includes at least one of checking that the one or more map data change requests are in a predetermined format and performing a verification procedure on the one or more map data change requests to check whether they are independent of other map data change requests and / or the map data.

[0025] In some but not all examples, the method further comprises accepting the one or more map data change requests, and accepting the one or more map data change requests is at least partially based on the at least one verification procedure.

[0026] In some but not all examples, the at least one verification procedure [[ID= checks the one or more changes of the one or more map data change requests to comply with one or more criteria and performs a verification procedure on the one or more changes of the one or more map data change requests that depends on other map data change requests and / or the map data. with respect to the one or more changes of the one or more map data change requests and / or the map data. <O000107> the one or more changes of the one or more map data change requests This includes checking for any conflicts between at least one change in at least one other map data change request and at least one change in at least one other map data change request.

[0027] In some, but not all, examples, the storage and / or transmission of one or more of the changes is at least partially based on the at least one verification procedure.

[0028] In some, but not all, examples, the method described above, Accepting one or more of the aforementioned map data modification requests, The storage of the one or more changes of the one or more map data change requests, The transmission of the one or more map data change requests and the one or more changes made to the one or more map data change requests, The method further comprises transmitting a response to the at least one device, following at least one of the verification procedures described above.

[0029] In some, but not all, map data modification requests are received synchronously.

[0030] In some, but not all, examples, the method further comprises associating and / or assigning the one or more changes of the one or more map data change requests to one or more version identifiers.

[0031] In some, but not all, examples, the method described above, Receiving multiple map data modification requests, each of which indicates a modification; The means of storing the changes of the multiple map data change requests received (the storage of each change may depend at least in part on a verification procedure performed on the individual change), The system further comprises assigning a continuous and uninterrupted version identifier to the aforementioned stored changes.

[0032] In some, but not all, examples, the method further comprises enqueuing the one or more changes for transmission to the second device.

[0033] In some, but not all, examples, the method further comprises coordinating the order of the one or more changes in order to enqueue them for transmission to the second device.

[0034] In some, but not all, examples of submitting one or more of the above changes are: The above one or more changes are periodically transmitted to the above second device, This includes at least one of the following: transmitting the newly stored changes to the second device.

[0035] In some, but not all, examples, one or more of the changes are transmitted asynchronously to the second device.

[0036] In some, but not all, examples, the second device stores multiple different versions of map data, each of which is associated with and / or includes map data in a different state.

[0037] In some, but not all, examples, the method described above, Requesting information about the best state stored in the second device from the second device, The system further includes receiving information about the best state stored in the second device from the second device, Determining whether the specific state of the map data is stored in the second device is based on the information relating to the best state stored in the second device.

[0038] In some but not all instances, in response to determining that the particular state of the map data is not stored in the second device, at least a portion of the states of the map data obtained from the second device is at least a portion of the best states of the map data stored in the second device.

[0039] In some but not all instances, the method further comprises deleting one or more of the stored changes, the deletion being at least in part based on the received information relating to the best state stored in the second device.

[0040] In some but not all examples, the method further comprises deleting one or more of the stored changes, the deletion being at least in part based on determining whether the number of stored changes exceeds a threshold number.

[0041] In some but not all examples, the second device includes a database for storing the map data. The aforementioned database is a geospatial database, The aforementioned database is a versioned map database, The aforementioned map data is map data for a map layer of a digital map.

[0042] While the above examples and optional features of this disclosure are described separately, it should be understood that their provision in all possible combinations and substitutions is included within this disclosure. It should be understood that the various examples of this disclosure may include any or all of the features described with respect to other examples of this disclosure, and vice versa. Furthermore, it should be understood that any one or more or all of the features may be implemented / executable by apparatus, methods and / or computer program instructions, in any combination, as desired and as necessary. [Brief explanation of the drawing]

[0043] Several examples are described below with reference to the attached drawings. [Figure 1] This section provides a brief overview of the methods described in this book, using examples of the subject matter. [Figure 2] This section provides a brief overview of examples of requesting (one or more) map data changes based on the subject matter described in this book. [Figure 3] This section provides a brief overview of an example of requesting map data based on the subject matter described in this book. [Figure 4A] , [Figure 4B] This section provides a brief overview of an example of providing map data based on the subject matter described in this book. [Figure 5] This section provides a brief overview of how to apply changes to map data using examples from the subjects described in this book. [Figure 6] Further examples of requesting changes to map data, based on the subject matter described in this book, are outlined below. [Figure 7] Further examples of requests for map data, based on the subject matter described in this book, are outlined below. [Figure 8] Further examples of applying changes to map data based on the subject matter described in this book are outlined below. [Figure 9] This section provides a general overview of the apparatus used as an example in the subject matter described in this book. [Figure 10] This section provides a general overview of computer programs using examples from the subjects covered in this book.

[0044] Drawings are not necessarily to scale. Certain features and views in drawings may be shown schematically or at scale exaggerated for clarity and conciseness. For example, the dimensions of some elements in a drawing may be exaggerated relative to other elements to aid in explanation. Similar reference numerals are used in drawings to indicate similar functions. For clarity, not all reference numerals are necessarily shown in all drawings.

[0045] In descriptions and drawings, unsubscripted reference numbers (e.g., 123) may be used as a general reference to a feature or class / set of features. Subscripted reference numbers (e.g., 123_1) may be used as unique references, for example, to distinguish different instances of a feature or class / set of features. Numeric subscript indices (e.g., 123_1) may be used to indicate a member of a particular instance / set of a class, while non-unique instances of a class (members of a set) may be referenced using reference numbers with variable subscript indices (e.g., 123_i). [Modes for carrying out the invention]

[0046] Figure 1 schematically illustrates an example of Method 100, which provides a computer-implemented method for managing one or more portions of map data of a digital map (also known as an electronic map).

[0047] One or more of the features discussed in relation to Figure 1 may be found in one or more of the other figures (in particular, Figures 2 to 4B). Therefore, during the discussion of Figure 1, references will be made to Figures 2 to 4B and the features and reference numerals shown therein. In particular, the functionality of blocks 101 to 103 of Method 100 in Figure 1 is shown in Figure 2. The functionality of block 104 of Method 100 is shown in Figure 3. The functionality of blocks 106A and 107A of Method 100 is shown in Figure 4A. Finally, the functionality of blocks 106B to 107B of Method 100 is shown in Figure 4B.

[0048] Figure 1 can be considered to describe multiple ways in which it can be considered to describe one or more actions performed by / in multiple actors / entities. Therefore, Figure 1 can be considered to describe multiple individual ways in which it is performed by each individual actor / entity of multiple actors / entities.

[0049] The constituent blocks in Figure 1 are functional, and the functions described can be performed by each individual actor / entity, each of which can be implemented as a device or module (such as device 10 as shown with reference to Figure 9). The functions described can also be implemented via a computer program (such as computer program 14 as shown with reference to Figure 10).

[0050] Multiple actors / entities may include, for example, the following: i. A first device / entity 201 that sends a request to change the state of map data (for example, a first user who may be a producer of map data content / changes / updates, such as with respect to a particular layer, for which the user may be considered the “owner” / responsible for that particular map data layer). ii. Entity 1 (which may also be referred to in this document as the "concurrent write module," "interface module," or simply "module") receives a request to change the state of map data. iii. An entity 205 that stores map data (sometimes called a “map state database,” map data state, or digital map repository). iv. Entity 301 (e.g., a user of map data) sends a request for at least a portion of the map data. In some examples, entity / user 301 may be the same as the first user / entity 201. In other examples, these entities are different.

[0051] In block 101, entity / module 1 receives a map data change request 202 from a first device 201 (for example, a map data change / update producer, such as a map content or VAD producer for a digital map).

[0052] Each map data change request indicates a request for a map data change 202Δ to be applied to a state of map data in order to generate a different state of map data (for example, the change being applied to the state of map data of a digital map stored / hosted in a second device 205). Map data may be map layer data, i.e., map data for a particular map layer of a digital map. In this regard, each map data change request may be a message requesting that an update be made to the map data for a layer of the digital map. In some examples, a map layer data producer may "own" a particular layer of the digital map (i.e., may be responsible for its generation / management / update), and the map change request message may describe the changes the map layer data producer has made to that particular layer. The map layer data producer may send such a map change request message to a repository that stores at least the particular layer to which the change relates, requesting that the changes the map layer data producer has made to that particular layer data be applied to the individual layers of the digital map stored in the repository.

[0053] Entity / Module 1 may perform validation procedures for each map data modification request received. In some examples, preliminary checks may be performed to verify that the map data modification request is in a predetermined format. In addition or alternatively, in some examples, validation procedures may be performed on the map data modification request to verify that it is independent of and / or matches other map data modification requests, and / or independent of and / or matches map data (for example, a specific state of map data, such as the state of map data associated with a particular identifier).

[0054] The verification procedure is, Checking for changes to one or more map data change requests in order to comply with one or more criteria, For (one or more) map data change requests, Other map data modification requests, and / or Performing verification procedures that depend on map data, One or more changes to one or more map data change requests, This may include checking for any conflicts between at least one other map data modification request and at least one modification of at least one other map data modification request.

[0055] After the verification procedure is successfully completed, the map data modification request may be accepted. Subsequently, an acceptance response may be sent to the second device (as described below in block 103).

[0056] Map data change requests may be received synchronously from the first device within the entity / module. Verification procedures and acceptance responses may be part of the synchronous reception process.

[0057] In block 102, one or more changes in the map data change request 202 are stored in entity / module 1 and therefore, for example, in the first database 111. The storage of the changes may be at least partially based on a verification procedure, i.e., the changes are stored only if the verification procedure is successful and the changes are properly verified. Subsequently, a storage response may be sent to the first device to confirm / acknowledge the storage of each change in the map data.

[0058] The changes in one or more map data modification requests may be associated with and / or assigned to one or more version identifiers. In some examples, multiple map data modification requests are received, the multiple changes they represent are stored, and then a continuous and uninterrupted set of version identifiers is assigned to the stored changes in the multiple map data modification requests.

[0059] One or more changes may be enqueued for transmission to the second device 205. The order of the enqueued changes may be coordinated by entity / module 1, for example, based on the assigned version identifier.

[0060] The second device includes a second database 222 for storing map data, that is, for storing map data in at least one state, preferably multiple states. The second database may be a geospatial database, a versioned map database, and the map data may be map data of a map layer of a digital map. Such a map database may be called a state database or a versioned state database.

[0061] The second device 205 stores one or more states 204 of the map data 203. The second device may store multiple different versions of the map data, each version of the map data being associated with and / or containing map data in different states. Such states may also be considered to correspond to the most recent change that brought the map data into that state.

[0062] In block 103, entity / module 1 sends a map data change 202Δ of the map data change request 202 to the second device 205 so that the second device can apply ("squash" / "merge") the map data change to the map data stored in the second device (i.e., to obtain a new / updated / current state from the old state of the map data stored in the second device).

[0063] As used in this book, the terms “squash” or “merge” may also mean, in the context of squashing or merging changes, applying a series of one or more changes to the state of map data (for example, applying all the modifications identified in the series of changes to the state of map data) to generate new state map data.

[0064] The storage and transmission of (one or more) changes may be at least partially based on a verification procedure, i.e., (one or more) changes are transmitted only if the verification procedure is successful / (one or more) changes are properly verified. Following the verification and / or storage and / or transmission of the map data changes to the second device, a response may be sent to the first device to confirm / acknowledge the verification and / or transmission of the map data changes.

[0065] Map data changes 202Δ may be transmitted asynchronously, i.e., without waiting for confirmation, from entity / module 1 to the second device 205. This is possible thanks to entity / module 1 acting as an intermediary, ensuring the acceptance of queued changes while providing a synchronous interface to the first device.

[0066] Map data change 202Δ may be periodically transmitted to a second device. In some examples, only newly stored changes are transmitted to the second device (i.e., only changes that have not been transmitted previously).

[0067] In block 104, entity / module 1 receives a request 302 from the third device 301 for at least a portion of a specific state 204_x of map data 203_x. The specific state may be, for example, the current / latest state or a previous / past state, and may be associated with a specific identifier represented here by "x". The specific state may be, for example, a state that has not yet been "squashed" / "merged" in the second device 205, or a state that has not yet been stored in the second device 205 in order to incorporate changes that have not yet been sent to the second device 205. The portion may be, for example, a specific area of ​​the map data, and / or information about a specific type of entity contained in the map data, and / or information about a specific entity.

[0068] The third device 301 may be a requester of map layer data, such as a map layer data user. The third device may also be the same as the first device 201 (i.e., a map layer data producer requests, for example, a portion of the latest / current state of the map data to decide on new changes / updates to the map data).

[0069] In block 105, entity / module 1 determines whether a requested specific state of map data 203_x, for example, the state of map data associated with a specific identifier, is stored in the second device 205.

[0070] Entity / module 1 may communicate with the second device 205 to query whether a specific requested state of map data 203_x is stored in the second device. In this regard, Entity / module 1 Requesting information about the best state stored in the second device from the second device, The second device may also receive information about the best state stored in the second device.

[0071] For example, each state stored in the second device (205) may be provided with an identifier, which is unique and ordered. Preferably, a set of unique and ordered identifiers is selected such that it is possible to determine from a group of identifiers which of them corresponds to the highest state.

[0072] Determining whether a particular state of map data is stored in the second device may be based on information about the best state stored in the second device 205, for example, an identifier associated with the most recently stored state by the second device 205. In some examples, entity / module 1 may periodically send such requests and store the best state (of its country) stored in the second device in its own memory.

[0073] In response to determining that a specific state of the map data is stored in the second device, Entity / Module 1 performs the following (Branch A in Figure 1):

[0074] In block 106A, entity / module 1 obtains at least a portion of a specific state of map data from the second device. In this regard, entity / module 1 may request at least a portion of a specific state of map data from the second device 205 and receive it from the second device 205.

[0075] In block 106A, entity / module 1 transmits at least a portion of the acquired data representing a specific state of the map data to the third device 301.

[0076] Alternatively, in response to determining that a specific state of the map data is not stored in the second device 205, entity / module 1 performs the following (branch B in Figure 1):

[0077] In block 106B, entity / module 1 obtains at least a portion of the map data state from the second device. The obtained portion of the state may be the state of at least a portion of the map data stored in the second device 205, whose state is the closest available state to the specific state of the map data requested in block 104. In some examples, the obtained portion of the map data state is at least a portion of the highest state of the map data stored in the second device 205.

[0078] In block 107B, entity / module 1 applies one or more of its stored changes to at least a portion of the captured state of the map data in order to generate the requested at least portion of the state of the map data. In this regard, entity / module 1 may apply any number of its stored changes to the captured portion of the map data in order to change the captured portion of the map data to a state corresponding to the requested specific state or a state associated with the requested identifier.

[0079] In block 108B, entity / module 1 transmits at least a portion of the generated map data of a specific state to a third device.

[0080] In some examples, entity / module 1 may delete one or more of its stored changes based on determining the highest state stored in the second device 205 (for example, by receiving information indicating this from the second device). In this regard, if the module determines that the second device 205 has map data states up to state n stored in its versioned database, entity / module 1 may delete its stored changes corresponding to changes that result in states prior to state n. Since entity / module 1 can obtain map data of state n from the second device 205, entity / module 1 does not need to store changes applied by entity / module 1 to previous states of map data in order to generate map data of state n. Thus, entity / module 1 can delete such redundant changes. However, it is not ruled out that these changes may be retained over a longer period of time, as they may be used to perform consistency checks. Alternatively, or in addition, to prevent too many changes from being stored in entity / module 1, entity / module 1 may perform a delete operation, which is at least in part based on determining whether the number of changes to be stored exceeds a threshold number.

[0081] To aid in explaining Method 100 in Figure 1, an exemplary scenario is discussed below, referring to the various elements in Figures 2 through 4B.

[0082] In this exemplary scenario, entity / module 1 receives a request 202_x from the first device 201 for a map data change 202Δ_x. This request is to change map data 203_w (in state w) to map data 203_x in state x (e.g., a new / current / latest map data state). Entity / module 1 stores a copy of the map data change 202Δ_x in its own database 111. Entity / module 1 also sends a copy of the map data change 202Δ_x to the second device 205 (where the map data 203_w in state w is stored in the second database 222 of the second device 205), and as a result, the second device 205 applies the map data change 202Δ_x to its stored map data 203_w to generate map data 203_x in state x, and then also stores the newly generated map data 203_x having state x.

[0083] In an exemplary scenario, entity / module 1 subsequently receives a request 302 from a third device 301 (which may be different from or the same as the first device 201 that requested the change to the map data) requesting a portion of map data 203_x (for example, a portion of map data 204_x that is state x for a particular geographic area). Entity / module 1 determines whether the map data 203_x is available and stored in the database 222 of the second device. For example, it may contact, or has contacted, the second device 205 to request information about an identifier corresponding to the most recently stored state of the map in the database 222 of the second device. This may be done independently of receiving request 302, for example, periodically. The second device 205 may also send information about the most recent state to entity / module 1, for example, periodically, when a new state is stored, or every n states.

[0084] In this scenario, it becomes known that the second device has not yet executed or completed the process of applying the map data change 202Δ_x to the map data state 203_w, and therefore the map data 203_x has not yet been generated and is not stored in the second device's database 222. Therefore, the map data 203_x is not (yet) available from the second device / database 222. When entity / module 1 determines that the second device does not have the map data 203_x available / stored there, it requests the second device 205 to provide a copy of a portion of the map data 203_w (the portion corresponding to the portion requested by the third device in its request 302 [e.g., a specific geographical area]) that corresponds to the latest state of map data available / stored in the second device 205, or at least to the latest state known to entity / module 1. When entity / module 1 receives a portion of map data 203_w from the second device, it applies the map data modification 202Δ_x (which is stored in the entity / module's database 111) to the received portion of map data 203_w to generate a portion of map data 203_x in state x. Entity / module 1 then transmits the portion of map data 203_x to the third device.

[0085] It should be noted that there are also scenarios with different sequences or steps. For example, request 302 may be received by entity / module 1 after map change request 202 has been received by entity / module 1, but before the map data change 202Δ_x is sent to the second device 205. In such scenarios as well, the same procedure for responding to request 302 may be favorably performed.

[0086] An example of Method 100 may allow requesting / retrieving the most up-to-date map data (i.e., having the most recent changes applied to it) regardless of whether the most up-to-date map data is stored in the second device 205. For example, in order to generate and store the most up-to-date map data stored in the second device, if the map data stored in the second device 205 has not yet been modified by the second device 205 to make the map data the most up-to-date, the entity / module 1 itself may apply the most recent changes stored in entity / module 1 to the map data retrieved from the second device 205 in order to generate the most up-to-date map data and send it to the requesting device.

[0087] Advantageously, the provision of entities / modules (which have their first database for storing changes to map data) is, Map layer data producer (i.e., owner of the map layer / map layer content creator), It effectively acts as an intermediary / bridge between the second device (and its second database, i.e., the main map data storage), The map layer data producer requests map data changes through synchronous writing in entities / modules (this helps reduce read latency, even at the expense of slower writes), This offers the advantage of effectively enabling asynchronous writing of map layer data changes from entities / modules to a second device (which helps improve write performance, even at the expense of read latency).

[0088] In practice, in the examples of the present invention, it can be considered that "squash-on-write" / "merge-on-write" is used for the main storage of map data / map layer data, i.e., the second database of the second device. On the other hand, "squash-on-read" is used for storing map data change / map layer change data, i.e., in the first database of entities / modules. Furthermore, in practice, the examples of the present invention can be considered to provide synchronous writes for writing to the first database of entities / modules and asynchronous writes for writing to the second database of the second device.

[0089] Advantageously, Method 100 may provide improved write and read performance. For example, Method 100 may provide improved / optimized overall write and read performance compared to any of the following: Traditional "squash-on-read" based on map databases (which has good write performance for write requests that seek changes to map data, but suffers from poor read performance because all changes must be applied to the initial / first state of the map data during each read process in order to read the current / most up-to-date map data). The traditional "squash-on-write" method based on map databases (which has good read performance for retrieving stored map data, but suffers from poor write performance because each change must be applied to the map data during the write process). Furthermore, it would be impossible to retrieve the most up-to-date map data during the process of applying recent changes to generate the most up-to-date map data, and before the generation and storage of the most up-to-date map data.

[0090] Here, referring to Figures 5 to 7, we will discuss an example of the subject matter of this disclosure, namely the implementation of Entity / Module 1, using the same reference numerals as those used in Figures 1 to 4B to aid understanding.

[0091] In some examples, entity / module 1 is a module used in conjunction with a versioned map state database. This versioned map state database is a spatial database / repository of map layer data for at least one map layer. This database can be considered a digital map. However, multiple such databases together can also be considered a digital map. In general, it will be apparent to those skilled in the art that the proposed method is advantageous for versioned geospatial databases, achieving low latency in the sense of fast reads as well as fast writes, and optionally allowing changes to be validated and / or checked before being applied to maps stored in the database.

[0092] Each map layer depends on updates generated by the user (the owner of the map layer / service), such as map data changes 202Δ. These can take the form of a series of messages (e.g., change request messages 202) that describe the map data changes 202Δ that need to be made to the map data (i.e., changes to the map data state stored in the versioned map state repository in its state database 222).

[0093] Each map layer needs to expose an application programming interface (API) that allows for the publication of a consistent state of map data, while also allowing other users to access a range of previous states of the map data for reading. By using entities / modules and exposing read APIs through these entities / modules, both read and write latency can be reduced simultaneously.

[0094] For the main memory of the layer data (i.e., the versioned map state database), squash-on-write is applied, which provides faster reads than squash-on-read, but at the cost of slower writes. The slower writes resulting from the database's use of squash-on-write are handled via Module 1, which is discussed below in both worlds, i.e., From the perspective of a content producer / map data change request producer, synchronous writing of changes at high throughput (i.e., high throughput for writing map data status) and The aim is to provide the best of the following: efficient readout with no latency or low latency.

[0095] Module 1 effectively enables the use of both squash on lead and squash on light. That is, i) Squash-on-read database 111 of module 1 for storing map data changes 202Δ, and ii) A squash-on-light database 222 of a second device / repository 205 for storing map data status.

[0096] As schematically illustrated in Figure 5 (and Figures 6 and 7), Module 1 includes or can access a relational database management system (RDBMS) for map data changes 202Δ (for example, referred to as the "change database" 111 in this document), which has logic to query another database 222 (referred to as the "state database" 222 in this document) that stores the underlying state 204 of map data 203, and combine the map state retrieved from the state database 222 with changes (from the change database 111) that have not yet been applied to the map data state. In this way, Module 1 performs only limited squash-on-read while taking advantage of all the benefits of squash-on-write.

[0097] Module 1 may contain a limited number of changes stored within it (the number of changes depends on usage / purpose / local configuration).

[0098] As schematically illustrated in Figure 6, in addition to storing the map data changes 202Δ in the database 111, module 1 transmits the map data changes 202Δ (e.g., changes 13, 12, 11, ... as shown in Figure 6) to a second device 205, which can then be applied to the map data in a given state to change the map data to a new state and store the new state in the second device 205, i.e., the state database 222. Subsequently, each map data change can be applied to the previous map state when writing to the database 222, so that a consistent state for each version is stored in the database 222.

[0099] As schematically illustrated in Figure 7, Module 1 also receives requests from a user 301 or producer 201 of the map data 201 for map data in a certain state, for example, the most recent / most recent state, such as a request for a map state having a version identifier 14 as shown in Figure 7. Module 1 can retrieve map data in a certain state from database 222 if available, otherwise it can retrieve map data in a different state (e.g., a previous state) from database 222, and can apply the necessary map data changes 202Δ from change database 111 to the retrieved map data in the other state in order to change the retrieved map data to the requested state (i.e., to perform a "squash-on-read" procedure). In this regard, Module 1 can apply the map data changes 202Δ from database 111 to each other (sequentially) when reading map data states from state database 222. In practice, Module 1 can perform squash-on-read when reading map data states from squash-on-write database 222.

[0100] The following is a discussion of an example of the writing process for Module 1.

[0101] Writing process As schematically illustrated in Figure 6, each request 202 for a map data change 202Δ received from customer 201 (e.g., map data producer) via the synchronous interface is accepted (optionally undergoing and passing an initial preliminary check / verification process - after which a version identifier is assigned to the map data change) and stored by module 1 (where the storage of the map data change occurs via synchronous writing, i.e., including sending a response message to customer 201 only after a successful write, the response message may include the assigned version identifier). Following the acceptance and storage of the map data change 202Δ in the module's change database 111, a response 602 (i.e., a response from the synchronous interface / synchronous write process indicating the unblocking of the operation) is sent to the customer. This enables fast synchronous writing to the change database without the sacrifice of applying the map data change 202Δ to the state of the map data stored in the state database 222. In this regard, simply writing a change is faster than applying a change and write to a new state of map data, because the change itself is simply written (compared to the change being applied to the map data state in order to generate a new state of map data that will be written to afterward).

[0102] In some examples, before the map data change 202Δ is accepted and stored in the module change database 111, and before the response 602 is sent, the map data change 202Δ may undergo a (further) check / verification process (i.e., a more substantial check / verification than the initial preliminary check / verification process, if performed), which may include conflict checks, as will be discussed in more detail below. The map data change is then stored in the module change database 111 and enqueued for transmission to the second device 205 so that the map data change can be applied to and written / stored in the status database 222 (for example, periodic checks may be performed periodically to ensure that there are any newly received map data changes that have not yet been transmitted). Figure 6 shows that the (previously enqueued) map data changes 13, 12, 11… are sent to the second device 2 for application to and writing in the status database 222.

[0103] The application and writing of map data changes to the state database may be performed asynchronously. However, as described above, states that have not yet been written to the state database (e.g., state 14) can still be provided to the requester by applying the necessary changes from the change database to previous states retrieved from the second device 205 in order to generate the desired state for transmission to the requester.

[0104] Module 1 may run a background scheduled process that sends newly stored map data changes to the second device 205 for asynchronous application of map data changes to the map data state in the state database and writing the new map data state to the state database. Due to this asynchronous process, the most recent / best available state / version in the second device may be somewhat behind the best state achievable through the most recent map data changes received and stored in the module's change database (i.e., such recent map data changes have not yet been applied to and written to the state database).

[0105] The following is a discussion of an example of the read process for module 1.

[0106] Read process As schematically illustrated in Figure 7, the read request 302 is received by module 1. The read request may include various parameters used to define the extent and scope of the requested map data, in particular, which subparts of the map data are requested (e.g., only for a specific geographic area), and which state or version of the map data is requested (in the example in Figure 7, version identifier "version 14" is requested). Such parameters can effectively be considered equivalent to searching for a query term.

[0107] When used in this book, for example, in the context of digital map versions, “version” may refer to an identifier for a particular state of a digital map, i.e., a particular iteration or update.

[0108] A read request may include a specific version identifier or simply request the "current / recent" version. A request for the current version may be translated by the module to a specific / identified version, e.g., version X, which may or may not be available from the second device. However, even if the requested version is not available on the second device, the module can resolve this issue.

[0109] The request is redirected to the second device 205, which executes the read request with the same parameters using the highest available version not higher than the requested version. In the example in Figure 7, the highest version available from the second device is version 10 (because changes 13, 12, and 11 are still in the process of being sent to, applied, and written to the second device, and change 14 is currently enqueued in the module and has not yet been sent to the second device).

[0110] In the example in Figure 7, it is assumed that the requested version (version 14) is not yet available from the second device. Therefore, the module instead requests and uses the most current available version (version 10). The second device returns this version to the module in response to the module's read request.

[0111] The module then queries its database of changes to read the response from the second device (i.e., the map data in state 10) and the changes 11, 12, 13, and 14 that are combined with / applied to it, thereby generating a response 702 to the original read request 302 (i.e., the desired portion of the map data for version 14) and returning a response 702 containing the combined data (i.e., the map data generated from applying the changes in the module's database to the latest version of the map data from the second device) to the requester 301. This may enable fast reads (as only a limited amount of squashing, i.e., changes 11-14, is required, as opposed to squashing all previously made changes 1-14) without / with reduced latency (i.e., without having to wait for version 14 of the map data available in the second device).

[0112] The discussion then continues with examples of additional capabilities of the system architecture, schematically represented in Figures 6 and 7.

[0113] Additional abilities The system architectures described above in Figures 6 and 7 (in particular, those that actually have a module that acts as a portal / gateway to the digital map of the underlying second device and works to receive write and read requests to the same) pave the way for providing additional capabilities due to the ability to perform synchronous write application programming interface APIs (i.e., synchronous writing of map data changes received by the module in map data change requests to the module change database 111) without sacrificing overall performance.

[0114] Previously, the asynchronous writing interface provided by the second device (and without the currently proposed module 1) made it impossible to effectively perform data validation (e.g., checking requests for changes to the map data state and checking them against other change requests, i.e., determining whether there are conflicts with the map data state and / or other change requests), assign version numbers, and order changes using those numbers. As a result, without such a module, the user / map data producer would be responsible for the following: Versioning, and • Checking / verifying (i.e., checking the correctness of the changes).

[0115] The currently proposed module can support both user / map data producers who have both of these responsibilities, thereby significantly reducing the amount of overhead effort occupied by the user / map data producer's process.

[0116] Figure 8 schematically illustrates the checking of requests for map data changes, versioning requests for map data changes (i.e., the assignment of version identifiers / version numbers to the changes in map data change requests, in which case the assigned version number / identifier effectively serves as a specifier for the change number and specifies its order among other changes), and the checking of map data changes performed by a module such as the proposed one.

[0117] The Orbis map system / platform requires that each map layer generate its changes using an assigned, incrementing, continuous numerical version (i.e., a gapless, continuous numerical version). Messages requesting map data changes must be enqueued sequentially for each layer according to those versions.

[0118] It is typical for a user / map data producer to run multiple parallel processes that generate map data based on different sources. Meeting the requirements for Orbis versioning necessitates synchronizing all such processes in one place in order to assign continuous and seamless versions.

[0119] The proposed module may expose a REST (Representational State Transfer) API to accept change requests. This means that no version has been assigned at this point. In this way, the module can receive multiple requests in parallel, assign versions, and arrange them in order. Versions may be generated by a PostgreSQL database sequence, which may allow changes to be arranged in order. If a change needs to be rejected after a version has been assigned (for example, due to a failure in the check / validation process), an empty change may be generated instead.

[0120] The module may include a table of versions awaiting acceptance and a table of changes enqueued for transmission to a second device / awaiting transmission. This allows the module to: • Perform preliminary validity checks in parallel, • Assigning a version, • Stateful checking, that is, sequential critical checking of the (resulting) state (this step switches from parallel processing to sequential processing because all previous changes must be checked and accepted for publication), • Enables the asynchronous transmission of changes to a second device (i.e., without waiting for a response, and, if necessary, filling gaps caused by changes that fail state checks with empty changes).

[0121] Figure 8 shows the two phases: checking the change request and the change itself. • Preliminary checks - This includes checking compliance with the request message for changes to the speed camera model and its requirements (e.g., that the correct format / formatting is used). These checks can be performed in parallel, as each request is checked separately / independently. • Stateful checks / conflict checks - These check for problems in the change data itself, including potential issues / disputes related to dependent or duplicate changes. For this reason, these checks must be performed sequentially.

[0122] The preliminary check is a simple, independent set of validators. The stateful check / conflict check, at its core, performs conflict detection between the changes in each received change request. Note that change request 202 becomes change 202Δ only after it has been accepted by the stateful check / conflict check.

[0123] The following is a discussion of conflict detection methods that may be adopted by the proposed module.

[0124] Conflict detection When a process is generating a change request, another process running in parallel may have changed the state of the same data with a different change request. Apart from the second device which provides fast access to the state, the module also has access to a set of recent changes (i.e., changes that have not yet been sent to the second device and / or have not yet been applied to the state stored in the second device), so the proposed module is in a unique position to check for such conflicts.

[0125] The number of changes maintained in a proposed module can be configured for different purposes. To achieve fast readouts, the module may only need to maintain changes that have not yet been written to the state, i.e., those that have not yet been sent to a second device. To provide conflict detection, the module may be configured to maintain more changes. The number of changes maintained within a module may affect the minimum base version (described later) that can be used to create the changes.

[0126] The data producer may be required to provide certain necessary information to enable conflict detection / identification. To identify conflicts, the proposed module may require additional change context information without which conflict detection will not be performed.

[0127] Such additional change context information may include information indicating the base version of the map on which the change is based, a context consisting of a list of map element identifiers, and a spatial context. The following is an example of additional change context information that may be required by a module to perform conflict checking. ChangeRequest{ Change{...} ChangeContext{ baseVersion contextIds spatial context } }

[0128] Base Version - This field contains the version on which the changes are based. Conflicts may occur if changes are recorded to the same element after this version. The module checks each element included in the change request (and potentially the context, see below) and compares them to all associated IDs related to changes made to the layer since the base version. A conflict occurs if any of the elements have been changed.

[0129] Context ID - By default, modules can only detect conflicts between elements within a change. In more advanced cases, it may be important that elements used to construct the change but which themselves have not been changed should not be updated by another process. In such cases, the data producer can provide the IDs of those elements in the Context ID field.

[0130] Spatial Context - In more advanced cases, if the changes are based on a spatial context (a specific bounding box), this spatial context may be provided for conflict detection. The module checks whether any changes have occurred within the indicated spatial extent / geometry since the base version.

[0131] To create conflict-free changes and ensure proper conflict detection, all read calls used to create and later validate change requests must use the same version. The version used for reads must be provided as the base version within the change context.

[0132] Using change requests allows the change context to be transmitted / passed along with the change itself.

[0133] To enable conflict detection, a module may accept change requests instead of “pure changes.” A change request 202 is simply a request for the change to be applied. Therefore, the module has the ability to reject the request (for example, if a preliminary check or stateful / conflict check fails), while a “pure change” is a change that must pass preliminary and stateful / conflict checks and be applied.

[0134] A brief discussion of the conflict detection process that may be adopted by the proposed module follows below. 1. If a base version is not provided, conflict detection will not be performed. 2. Conflicts are detected regarding changes (or context) published after the base version. 3. A conflict is detected and a 409 (conflict) status code is returned in the following cases: a. Change conflict detection: i. Any element from the checked changes is modified by another change in a version higher than the base version. ii. Any element from the checked change existed in the context of another change in a version higher than the base version. b. Context ID conflict detection: i. Any element from the context ID has been modified by another change since the base version. c. Context vs. Context Conflict Detection: i. Any element from the context ID provided in the context of another change since the base version. d. Spatial context conflict detection: i. Any element present on the map within the bounding box of the base version is modified by another change made after the base version. ii. A new element has appeared within the bounding box of a base version or later (i.e., created or moved by another change). 4. A conflict has been detected, and the following precautions apply: a. All IDs present in the change are used, including not only the IDs of elements directly affected by the change, but also the IDs of referenced elements, such as the IDs of elements that the newly created element connects to (through the concept of relationships or references). b. Spatial context conflict detection is performed on all elements that have geometry; that is, conflicts are detected even if tags are added to elements that have geometry within a bounding box. c. Spatial context conflict detection is not performed on elements that do not have geometry (conflicts cannot be detected). d. Spatial context vs. spatial context conflict detection: Context vs. spatial context conflict detection is not performed for spatial contexts. e. Spatial context vs. context conflict detection: Context (ID) vs. spatial context conflict detection is not performed for spatial contexts. 5. Before conflict detection begins, the module waits for all previous versions to be processed. a. There is a timeout (e.g., 10 seconds by default) that waits for all previous versions. b. In case of a timeout, a status code of 429 (Too Many Requests) is returned (this is an indicator that the service is overloaded due to too many parallel requests). c. If a timeout has elapsed and some previous versions have not yet been processed, the module may preemptively accept these changes, prevent them from being remembered, and continue checking and publishing the current changes within the scope of another (longer) timeout.

[0135] It will be understood that each block described in Figure 1, and in particular the further functionalities described above with respect to Figures 2 to 8, can be implemented by various means such as hardware, firmware, and / or software including one or more computer program instructions. For example, one or more of the functionalities described above can be implemented by a properly configured device (such as device 10 described with reference to Figure 9, which includes means configured to perform the functionalities described below). One or more of the functionalities can be implemented by a properly configured computer program (such as computer program 14, which includes computer program instructions that embody the functionalities described below, are stored in a memory storage device, and can be executed by a processor, as described with reference to Figure 10).

[0136] The blocks and functionalities described in Figures 1 to 8 may represent actions in a method, functionalities performed by the apparatus 10, and / or sections of instructions / code in the computer program 14.

[0137] Instructions / code within a computer program can be loaded onto a computer or other programmable device (i.e., hardware) to generate a machine, such that the instructions create means configured to implement the functions / features identified within a block when the instructions are executed on the programmable device. These computer program instructions can also be stored in computer-readable media that can instruct a programmable device to function in a particular way, such that the instructions stored in computer-readable memory produce a product containing instruction means that implement the functions identified within a block. Computer program instructions can also be loaded onto a programmable device so that a set of operational actions are executed on the programmable device to generate a computer-executed process, such that the instructions executed on the programmable device provide actions configured to implement the functions / features identified within a block.

[0138] Many of the examples in this disclosure, though not all, may take the form of methods, apparatus, or computer programs. Therefore, many of the examples, though not all, may be implemented in hardware, software, or a combination of hardware and software.

[0139] While not all, various examples in this disclosure are described using flowcharts and schematic block diagrams. It will be understood that each block (and combination of blocks) can be implemented by computer program instructions of a computer program. These program instructions can be provided to one or more processors, processing circuits, or controllers to create means for instructions executed by them to perform functions identified within one or more blocks, i.e., so that a method can be computer-implemented. Computer program instructions can be executed by (one or more) processors to generate a computer-implemented process, such that a set of operational blocks / steps / actions are executed by (one or more) processors to provide blocks / steps configured so that instructions executed by (one or more) processors implement functions identified within one or more blocks.

[0140] Therefore, a block supports a combination of means configured to perform a specified function, a combination of actions configured to perform a specified function, and computer program instructions / algorithms configured to perform a specified function. It will also be understood that each block, and combinations of blocks, may be implemented by a dedicated hardware-based system, or a combination of dedicated hardware and computer program instructions, to perform the specified function or action.

[0141] While not necessarily all, various examples of the present disclosure provide a method and / or a corresponding apparatus including various modules, means, or circuits that provide functionality for performing / applying the actions of such method. These modules, means, or circuits may be implemented as hardware or as software or firmware executed by a computer processor. In the case of firmware or software, examples of the present disclosure may be provided as a computer program product including a computer-readable storage structure that implements computer program instructions (i.e., software or firmware) for execution by a computer processor.

[0142] Figure 9 schematically illustrates a block diagram of apparatus 10 configured to perform the methods, processes, and functionalities described herein and relating to Figures 1 to 8. In this regard, in some examples, the apparatus may be embodied as a server. The component blocks in Figures 1 to 8 are functional, and the functions described may be performed by a single physical entity. The apparatus may be embodied, in particular, by computing devices as described above. However, in some examples, the apparatus may be embodied as a chip, chipset, circuit, or module, i.e., for use in any of the aforementioned.

[0143] The controller 11 may be embodied in computing devices, particularly those described above. In some, though not all, examples, the device may be embodied as a chip, chipset, circuit, or module, i.e., for use in any of the aforementioned ways. As used in this text, “module” refers to a unit or device excluding certain parts / components that may be added by the end manufacturer or user.

[0144] The controller 11 may be implemented as a controller circuit. The controller 11 may be implemented as hardware alone, may have certain aspects in software including firmware, or may be a combination of hardware and software (including firmware).

[0145] The controller 11 can be implemented by using instructions that enable hardware functionality, for example, by using executable instructions for a computer program 14 in a general-purpose or dedicated processor 12 that is stored in a computer-readable storage medium 13, such as memory or a disk, and can be executed by such a processor 12.

[0146] The processor 12 is configured to read from and write to the memory 13. The processor 12 may also include an output interface to which data and / or commands are output by the processor 12, and an input interface to which data and / or commands are input to the processor 12. The device may be coupled to or include one or more other components 15 (in particular, for example, a wireless transceiver, a sensor, an input / output user interface element, and / or other modules / devices / components for inputting and outputting data / commands).

[0147] Memory 13 stores instructions such as a computer program 14, which, when loaded into the processor 12, controls the operation of the device 10. The instructions of the computer program 14 provide logic and routines that enable the device to perform the methods, processes, and procedures described in this disclosure and illustrated in Figures 1 to 8. The processor 12 can load and execute the computer program 14 by reading from memory 13.

[0148] Instructions may include computer programs, non-temporary computer-readable media, computer program products, and machine-readable media. As used in this text, the term “non-temporary” refers to the limitations of the medium itself (i.e., tangible rather than signal-based), as opposed to the limitations of data storage persistence (e.g., RAM vs. ROM). In some, though not all, computer program instructions may be distributed across two or more computer programs.

[0149] Although memory 13 is described as a single component / circuit, it can be implemented as one or more separate components / circuits, some or all of which can be integrated / removed, and / or can provide persistent / semi-persistent / dynamic / cached storage.

[0150] Although processor 12 is described as a single component / circuit, it can be implemented as one or more separate components / circuits, some or all of which can be integrated / removed. Processor 12 can be a single-core or multi-core processor.

[0151] The apparatus may include one or more components configured to perform the methods, processes, and procedures described in this disclosure and illustrated in Figures 1 to 8. The functions of these components are intended to be performed by one or more components combined or by other components having equivalent functionality. Descriptions of functions should be additionally deemed to disclose any suitable means for performing such functions.

[0152] Where a structural feature is described, it may be replaced by means configured to perform one or more of the functions of the structural feature, whether one or more of those functions are explicitly or implicitly described.

[0153] While examples of devices have been described above in relation to the inclusion of various components, it should be understood that components can be embodied as one or more processing elements of the device or as corresponding controllers or circuits such as processors, or can be controlled in other ways. In this regard, each of the components described above may be one or more of any devices, means, or circuits embodied in hardware, software, or a combination of hardware and software, configured to perform the corresponding function of the individual components described above.

[0154] In some cases, the device, At least one processor 12, When executed by at least one processor 12, the device, Receiving one or more map data modification requests from at least one device, each of which indicates a request for a change to be applied to the state of the map data in order to generate a different state of the map data, To store one or more changes to one or more map data change requests, The process involves transmitting one or more changes to one or more map data modification requests to a second device, the second device storing one or more states of the map data, and The third device receives a request to obtain at least a portion of a specific state of the map data, To determine whether a specific state of the map data is stored in the second device, In response to determining that a specific state of the map data is stored in the second device, From the second device, obtain at least a portion of a specific state of the map data, The process involves transmitting at least a portion of the acquired data representing a specific state of the map data to a third device, In response to determining that a specific state of the map data is not stored in the second device, From the second device, obtain at least a portion of the map data state, To generate at least a portion of a specific state of the map data, apply one or more of the stored changes to at least a portion of the acquired state of the map data, The system includes transmitting at least a portion of the generated map data in a specific state to a third device, and at least one memory 13 that stores instructions for performing at least this operation.

[0155] Figure 10 illustrates a computer program 14 that may be transported via a delivery mechanism 20. The delivery mechanism 20 may be any suitable delivery mechanism, such as a machine-readable medium, a computer-readable medium, a non-temporary computer-readable storage medium, a computer program product, a memory device, a solid-state memory, a recording medium such as a compact disk read-only memory (CD-ROM) or a digital versatile disk (DVD), or a manufactured product comprising or tangibly embodying the computer program 14. The delivery mechanism may be a signal configured to reliably transfer the computer program. The device may receive, propagate, or transmit the computer program as a computer data signal.

[0156] In the specific examples of this disclosure, when performed by the device, The device receives one or more map data modification requests from at least one first device, each of which indicates a request for a change to be applied to the state of the map data in order to generate a different state of the map data. The device stores one or more changes to one or more map data change requests, The process involves transmitting one or more changes to one or more map data modification requests from one device to a second device, the second device storing one or more states of the map data, and The device receives a request from a third device to obtain at least a portion of a specific state of the map data, In the device, it is determined whether a specific state of the map data is stored in the second device, In response to determining that a specific state of the map data is stored in the second device, The device obtains at least a portion of a specific state of map data from the second device, The process involves transmitting at least a portion of the acquired data of a specific state of the map data from the device to a third device, In response to determining that a specific state of the map data is not stored in the second device, The device obtains at least a portion of the map data status from the second device, The device applies one or more of the stored changes to at least a portion of the acquired state of the map data in order to generate at least a portion of a specific state of the map data. A computer program is provided which includes, or is configured to, instructions to cause the device to perform at least the following: transmit at least a portion of the generated map data in a specific state from the device to a third device; and perform at least the following.

[0157] References to "computer programs," "computer-readable storage media," "computer program products," "tangible computer programs," or "controllers," "computers," and "processors" should be understood to include not only computers with different architectures such as single / multiprocessor architectures and sequential (von Neumann) / parallel architectures, but also specialized circuits such as field-programmable gate arrays (FPGAs), application-specific circuits (ASICs), signal processing devices, and other devices. References to computer programs, instructions, and code should be understood to include software for programmable processors or firmware, such as instructions for processors, or programmable content for hardware devices such as configuration settings for fixed-function devices, gate arrays, or programmable logic devices.

[0158] While certain terms are used in this book, they are used in a general and descriptive sense, not as a limiting definition.

[0159] The characteristics described above may be used in combinations other than those explicitly stated.

[0160] While functions have been described by referring to specific features, those functions may be executable by other features, regardless of whether they are described or not.

[0161] While features have been described by referring to specific examples, those features may also be demonstrable by other examples, whether described or not. Therefore, features described in relation to one example / aspect of this disclosure may include, to the extent that they do not contradict each other, any or all of the features described in relation to another example / aspect of this disclosure, and vice versa.

[0162] While various examples of this disclosure have been described in the preceding paragraphs, it should be understood that modifications can be made to these examples without departing from the scope of the invention as described in the claims.

[0163] The term “comprise” is used in this document in an inclusive, not exclusive, sense. That is, any reference to X containing Y indicates whether X can contain only one Y or two or more Ys. If “comprise” is intended to be used in an exclusive sense, it will be clarified in the context by referring to it as “containing only one…” or by using “consisting of.”

[0164] When used in this book, "decide / decide" (and its grammatical variations) may include, among other things, evaluating, calculating, operating, processing, deriving, measuring, investigating, identifying, looking up (e.g., looking up a table, database, or other data structure), and confirming. Also, "decide" may include receiving (e.g., receiving information), searching / accessing (e.g., searching / accessing data in memory), and obtaining. Furthermore, "decide / decide" may include resolving, selecting, choosing, establishing, and reasoning.

[0165] When used in this book, a description of an action should also be deemed to disclose that it enables, and / or causes, and / or controls, such action. For example, a description of receiving information should also be deemed to disclose that it enables, and / or causes, and / or controls, the receiving of information. Similarly, for example, a description of an information receiving device should also be deemed to disclose at least one means or controller of a device that enables, and / or causes, and / or controls, the receiving of information.

[0166] As used in this description and in the claims, the term “means” may refer to one or more individual elements configured to perform one or more corresponding described functionalities, or to several elements that perform one or more such functionalities. Furthermore, some of the functionalities described in the claims may be performed by the same individual means or the same combination of means. For example, the performance of one or more such functionalities may be caused in the device by a processor that executes instructions stored in the device’s memory.

[0167] References to parameters (e.g., tile freshness parameters) or parameter values ​​should be understood to refer to "data indicating," "data defining," or "data representing" the relevant parameter / parameter value, unless explicitly stated otherwise (unless the context requires otherwise). The data may be any method indicating the relevant parameter / parameter value, and may indicate it directly or indirectly.

[0168] This document has referenced various examples. Descriptions of features or functions related to an example indicate that those features or functions are present in that example. The use of the terms “example,” “for example,” “can,” or “may,” whether explicitly stated or not, in this document indicates that such features or functions are present in at least the example given, regardless of whether they are given as an example, and that they may be present in some or all other examples, but not necessarily. Thus, “example,” “for example,” “can,” or “may,” refers to a specific instance in the example class. Properties of an instance can be properties of that instance only, properties of the class, or properties of a subclass of the class that includes some, but not all, instances within the class.

[0169] In this text, references to “a / an / the” [features, elements, components, means…] are used in a non-exclusive, inclusive sense and should be interpreted as “at least one” [features, elements, components, means…] unless explicitly indicated otherwise. That is, any reference to X containing Y indicates that X may contain only one Y or two or more Ys, unless the context clearly indicates the opposite. If “a” or “the” is intended to be used in an exclusive sense, it will be made clear in the context. In some situations, the use of “at least one” or “one or more” may be used to emphasize an inclusive meaning, and the absence of these terms should not be interpreted as inferring any exclusive meaning. When used in this text, “at least one of the following, i.e., <list of two or more elements>” and “at least one of <list of two or more elements>” and similar phrasing mean at least one of the elements, at least two or more of the elements, or at least all of the elements, regardless of whether the list of two or more elements is joined by “and” or “or.”

[0170] The presence of a feature (or combination of features) in a claim is a reference to the feature (or combination of features) itself, and also a reference to features that achieve substantially the same technical effect (equivalent features). Equivalent features include, for example, variations of features that achieve substantially the same result in substantially the same way. Equivalent features include, for example, features that perform substantially the same function in substantially the same way to achieve substantially the same result.

[0171] In this description, references have been made to various examples in which adjectives or adjective phrases are used to describe the characteristics of the examples. Such descriptions of characteristics related to the examples indicate that the characteristics exist exactly as described in some examples, and substantially as described in others.

[0172] In the foregoing, the described devices may, alternatively or additionally, include, in some other examples, devices that include a distributed system of devices, e.g., a client / server device system. In examples where the provided devices form a distributed system (or the method is implemented as a distributed system), each device that forms a component and / or part of the system provides (or implements) one or more features that collectively implement the examples of the disclosure. In some examples, the devices are reconfigured by an entity other than the original manufacturer to implement the examples of the disclosure by providing additional software that, when executed, causes the devices to implement the examples of the disclosure, for example, by a user downloading such software (such implementation may be entirely by the devices or as part of the system of the devices described above).

[0173] While the above descriptions illustrate some examples of the present disclosure, those skilled in the art will notice alternative structural and method features that provide equivalent functionality to the specific examples of such structures and features described herein and have been omitted for brevity and clarity. Nevertheless, the above descriptions should be read as implicitly including references to such alternative structural or method features that provide equivalent functionality, unless such alternative structural or method features are explicitly excluded in the above descriptions of the examples of the present disclosure.

[0174] While efforts have been made in the foregoing specification to draw attention to the examples of features of this disclosure that are considered particularly important, it should be understood that the applicant may claim protection for any patentable features or combinations of features described herein and / or shown in the drawings, whether or not specific emphasis is made.

[0175] The examples and accompanying claims of this disclosure may be appropriately combined in any manner that is apparent to those skilled in the art. Separate references to “examples,” “in some examples,” and / or similar terms within this description do not necessarily refer to the same examples and are not mutually exclusive except as is readily apparent to those skilled in the art unless otherwise stated. For example, a feature, structure, process, block, step, action, or similar described in one example may, but may not, be included in another example.

[0176] Each and all claims are incorporated herein as further disclosures, and the claims are embodiments of the present disclosure. Furthermore, although the claims herein are provided as including certain dependencies, any claim may be dependent on any other claim, and any such alternative embodiments and their equivalents are also within the scope of the present disclosure to the extent that any alternative embodiments may arise from combining, integrating, and / or omitting features of various claims and / or altering the dependencies of the claims.

Claims

1. A computer-implemented method for managing map data, wherein the method is Receiving one or more map data modification requests from at least one device, each of which indicates a request for a change to be applied to the state of the map data in order to generate another state of the map data, To store the one or more changes in the one or more map data change requests, Transmitting one or more changes to one or more map data change requests to a second device, wherein the second device stores one or more states of the map data. The third device receives a request to obtain at least a portion of a specific state of the map data, Determining whether the aforementioned specific state of the map data is stored in the second device, In response to determining that the aforementioned specific state of the map data is stored in the second device, From the aforementioned second device, to obtain at least a portion of the map data in the specific state, Transmitting at least a portion of the acquired map data in the specific state to the third device, In response to determining that the aforementioned specific state of the map data is not stored in the second device, From the aforementioned second device, obtain at least a portion of the map data status, To generate at least a portion of the aforementioned specific state of the map data, one or more of the stored changes are applied to the acquired portion of the aforementioned state of the map data. A method comprising: transmitting at least a portion of the generated map data in the specific state to the third device.

2. A method according to claim 1, further comprising performing at least one verification procedure for one or more received map data modification requests.

3. The method according to claim 2, The aforementioned at least one verification procedure is The process involves checking that one or more map data modification requests are in a predetermined format, The procedure includes, at least one of the following: performing a verification procedure for one or more map data modification requests in order to check whether they are independent of other map data modification requests and / or map data; And / or optionally, The method further comprises accepting one or more map data modification requests, and the acceptance of one or more map data modification requests is at least partially based on the at least one verification procedure. And / or optionally, The aforementioned at least one verification procedure is To comply with one or more criteria, check the one or more changes in the one or more map data change requests, For the one or more changes to the one or more map data change requests, Other map data modification requests, and / or Performing verification procedures that depend on the aforementioned map data, The one or more changes to the one or more map data change requests, A method comprising checking for any conflicts between at least one change of at least one other map data change request and at least one other change request.

4. A method according to claim 2 or 3, wherein the storage and / or transmission of the one or more changes is at least partially based on the at least one verification procedure.

5. A method according to any one of claims 2 to 4, Accepting one or more of the aforementioned requests to modify map data, The storage of the one or more changes of the one or more map data change requests, The transmission of the one or more map data change requests and the one or more changes made to the one or more map data change requests, A method further comprising transmitting a response to the at least one device, following at least one of the verification procedures.

6. A method according to any one of claims 1 to 5, wherein the one or more map data change requests are received synchronously.

7. A method according to any one of claims 1 to 6, Associating and / or assigning the one or more changes of the one or more map data change requests to one or more version identifiers, And / or optionally, Receiving multiple map data modification requests, each of which indicates a modification; The process involves storing each of the changes in the multiple map data change requests received, Assigning a continuous and uninterrupted version identifier to the aforementioned stored changes, And / or optionally, A method further comprising enqueuing one or more changes for transmission to the second device.

8. A method according to any one of claims 1 to 7, wherein transmitting one or more of the changes is: The one or more changes described above are periodically transmitted to the second device, A method comprising at least one of the following: transmitting newly stored changes to the second device.

9. A method according to any one of claims 1 to 8, wherein the one or more modifications are transmitted asynchronously to the second device.

10. A method according to any one of claims 1 to 9, wherein the second device stores a plurality of different versions of map data, the different versions of map data each being associated with and / or comprising map data in a different state.

11. A method according to any one of claims 1 to 10, Requesting the second device to retrieve information about the best state stored in the second device, The second device further includes receiving information about the best state stored in the second device, A method for determining whether the specific state of the map data is stored in the second device is based on the information relating to the best state stored in the second device.

12. The method according to claim 11, In response to determining that the aforementioned specific state of the map data is not stored in the second device, at least a portion of the aforementioned state of the map data obtained from the second device is at least a portion of the best state of the map data stored in the second device. And / or optionally, The method further comprises deleting one or more of the stored changes, wherein the deletion is at least in part based on the received information relating to the best state stored in the second device.

13. A method according to any one of claims 1 to 12, wherein the second device includes a database for storing the map data, The aforementioned database is a geospatial database, The aforementioned database is a versioned map database, The map data is map data for a map layer of a digital map, according to the method.

14. An apparatus comprising means for performing the method described in any one of claims 1 to 13.

15. A computer program including instructions, wherein, when the program is executed by a computer, the instructions cause the computer to perform the method according to any one of claims 1 to 13.

Images