Virtual space generating system and virtual space generating method

The virtual space generation system addresses the challenge of generating railway-related virtual spaces by using a processing statement generation unit and node data acquisition to create and control virtual spaces, enabling automated railway data reproduction and maintenance support.

JP2025172537APending Publication Date: 2025-11-26HITACHI LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024078094
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-05-13
Publication Date
2025-11-26

AI Technical Summary

Technical Problem

Existing technologies do not allow for the generation of virtual spaces relating to railways, which is a challenge due to the manual nature of maintenance work and the impact of population decline on skill availability.

Method used

A virtual space generation system and method that includes a processing statement generation unit, node data acquisition unit, and virtual space control unit to create a virtual space based on user input, using a language model to generate API processing statements and store node data in a database to draw a virtual space.

Benefits of technology

Enables the generation of virtual spaces related to railways, allowing for the reproduction of real railway lines and supporting maintenance through automated data acquisition and control, with features like viewpoint and line of sight changes, and editing capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025172537000001_ABST
    Figure 2025172537000001_ABST
Patent Text Reader

Abstract

To generate a virtual space related to an arbitrary railroad.SOLUTION: A virtual space generating system includes a process sentence generating unit that inputs, into a language model, a user input that is language information related to a railroad and is input by a user, to generate an API processing sentence, a node data acquisition unit that inputs the API processing sentence generated by the process sentence generating unit into an API processing unit and acquires data of nodes related to the railroad, a placement unit that stores the node data in a virtual space database, and a virtual space control unit that renders a virtual space based on the data stored in the virtual space database.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a virtual space generation system and a virtual space generation method. [Background technology]

[0002] As operational technology becomes increasingly digitalized, there is a growing trend toward digitizing operational assets such as railways and station environments. However, maintenance work remains largely manual. Furthermore, social factors such as population decline pose challenges to the availability and preservation of skills necessary for modern maintenance practices. Patent Document 1 discloses a map information creation device that creates three-dimensional road network information based on two-dimensional road network information represented using links and nodes. The map information creation device includes: a map information storage unit that stores two-dimensional road network information including at least link and node position information and their attribute information; an elevation information addition unit that generates elevation information using a portion of the attribute information and adds the generated elevation information to the road network information as new attribute information; and a revised map information storage unit that stores the road network information with the elevation information added. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-305953 Summary of the Invention [Problem to be solved by the invention]

[0004] The invention described in Patent Document 1 does not allow for the generation of a virtual space relating to any railway. [Means for solving the problem]

[0005] A virtual space generation system according to a first aspect of the present invention comprises a processing statement generation unit that inputs user input, which is linguistic information related to railways entered by a user, into a language model to generate an API processing statement, a node data acquisition unit that inputs the API processing statement generated by the processing statement generation unit into an API processing unit and acquires node data related to railways, a placement unit that stores the node data in a virtual space database, and a virtual space control unit that draws a virtual space based on the data stored in the virtual space database. A virtual space generation method according to a second aspect of the present invention is a virtual space generation method executed by one or more computers, and includes inputting user input, which is linguistic information related to railways entered by a user, into a language model to generate an API processing statement, inputting the generated API processing statement into an API processing unit to obtain node data related to railways, storing the node data in a virtual space database, and drawing a virtual space based on the data stored in the virtual space database. [Effects of the Invention]

[0006] According to the present invention, a virtual space relating to any railway can be generated. [Brief explanation of the drawings]

[0007] [Figure 1] Functional configuration diagram of the virtual space generation system [Figure 2] Hardware configuration diagram of the virtual space generation system [Figure 3] An example of a station node table [Figure 4] An example of a rail track table [Figure 5] A diagram showing an example of a traffic light schedule [Figure 6] An example of a turnout table [Figure 7] An example of a platform table [Figure 8] Schematic diagram showing the processing of the virtual space generation system [Figure 9] A diagram showing an example of a screen display by the virtual space control unit. [Figure 10] FIG. 10 is a diagram showing a method for generating a language model in Modification 1. [Figure 11] Configuration diagram of a virtual space generation system in Modification 2 [Figure 12] Configuration diagram of a virtual space generation system in Modification 3 DETAILED DESCRIPTION OF THE INVENTION

[0008] -First embodiment- A first embodiment of a virtual space generation system and a virtual space generation method will be described below with reference to FIGS. 1 to 9. In this embodiment, the real three-dimensional space on Earth is referred to as "real space," and the virtual three-dimensional space created on a computer is referred to as "virtual space." Real space can also be called the "real world" or "real." Virtual space can also be called "virtual" or "metaverse." A position in real space can be specified by a combination of latitude, longitude, and altitude. Altitude can also be called "height" or "above sea level." In this embodiment, a position in virtual space is specified by a combination of X, Y, and Z coordinate values. Hereinafter, individual objects placed in virtual space will be referred to as "objects." However, objects may be grouped or subdivided.

[0009] FIG. 1 is a functional configuration diagram of a virtual space generation system 1. The virtual space generation system 1 includes, as its functions, a user interface 111, an API processing unit 112, a processing statement generation unit 113, a node data acquisition unit 114, a placement unit 120, and a virtual space control unit 150. The virtual space generation system 1 stores a map node database (hereinafter referred to as "DB") 160, a language model 117, a 3D model DB 170, and a virtual space DB 151. The map node DB 160 includes a station node table 160-1, a rail track table 160-2, a traffic light table 160-3, a switch table 160-4, and a platform table 160-5. Before describing each functional configuration, the hardware configuration will be described.

[0010] FIG. 2 is a hardware configuration diagram of the virtual space generation system 1. The arithmetic device 40 includes a CPU 41, which is a central processing unit; a ROM 42, which is a read-only storage device; a RAM 43, which is a read / write storage device; an input / output device 44, which implements a user interface 111; and a communication device 45. The CPU 41 loads a program stored in the ROM 42 into the RAM 43 and executes it to perform the various calculations described above. The arithmetic device 40 may be realized by a field programmable gate array (FPGA), which is a rewritable logic circuit, or an application specific integrated circuit (ASIC), which is an application specific integrated circuit, instead of the combination of the CPU 41, ROM 42, and RAM 43. Furthermore, the arithmetic device 40 may be realized by a combination of different configurations, for example, a combination of the CPU 41, ROM 42, RAM 43, and an FPGA, instead of the combination of the CPU 41, ROM 42, and RAM 43.

[0011] The input / output device 44 is a microphone, keyboard, mouse, LCD display, speaker, etc. The communication device 45 enables communication with other devices via the virtual space generation system 1. The communication device 45 is a wireless LAN adapter or a network interface card. Note that instead of the virtual space generation system 1 being provided with the input / output device 44, the communication device 45 may be used to realize dialogue with a user using another device. For example, the virtual space generation system 1 communicates with a mobile phone or computer (not shown) and receives voice input to the mobile phone as audio data from the mobile phone, whereby the communication device 45 replaces the operation of the microphone that is the input / output device 44. Furthermore, the communication device 45 transmits image data or audio data to another device based on an operation command from the CPU 41, and displays the image data or plays the audio data on that device, whereby the communication device 45 replaces the operation of the LCD display or speaker that is the input / output device 44.

[0012] Although FIG. 2 illustrates the virtual space generation system 1 as a single hardware device, the virtual space generation system 1 may be composed of multiple pieces of hardware. That is, the virtual space generation system 1 may be realized by multiple hardware devices operating cooperatively. In this case, the multiple hardware devices may be located in one location or connected via a network. In other words, the locations where the multiple hardware devices constituting the virtual space generation system 1 are installed and the distance between the devices are not important. The map node DB 160, language model 117, 3D model DB 170, and virtual space DB 151 may be stored in RAM 43 or in a non-volatile storage device (not shown). Returning to FIG. 1, the explanation will continue.

[0013] The user interface 111 receives requests from the user and presents information to the user. For example, the user interface 111 receives character input using a keyboard, selection input using a mouse, and voice input using a microphone. When the user performs voice input, the user interface 111 acquires the user's speech as a string of characters using a built-in voice recognition mechanism (not shown). However, the user interface 111 may also realize voice recognition of recorded user speech using a service provided outside the virtual space generation system 1 or a device outside the virtual space generation system 1. Hereinafter, the linguistic information about railways input by the user will be referred to as "user input."

[0014] The user interface 111 outputs text and images using, for example, a liquid crystal display. The API processing unit 112 receives an API processing statement created in a predetermined format and executes the processing described in the API processing statement. This processing is to obtain necessary data from the map node DB 160. The API processing unit 112 can also be called an API processing program.

[0015] The processing statement generation unit 113 generates API processing statements based on the above-mentioned user input using a language model 117. In order to use an API (Application Programming Interface), it is necessary to prepare command statements that follow a predetermined syntax, which is not easy for humans to handle. Therefore, the processing statement generation unit 113 generates command statements intended by the user using the language model 117. The processing statement generation unit 113 outputs the generated API processing statements to the node data acquisition unit 114.

[0016] The node data acquisition unit 114 inputs the API processing statement generated by the processing statement generation unit 113 to the API processing unit 112. Then, the node data acquisition unit 114 outputs the node data output by the API processing unit 112 to the arrangement unit 115. In other words, the node data acquisition unit 114 does not actually perform processing, but rather passes the data to an appropriate processing target, acting as a data intermediary, so to speak. The arrangement unit 115 stores the node data output by the node data acquisition unit 114 in the virtual space DB 151. The arrangement unit 115 includes a coordinate conversion unit 123, a 3D model processing unit 124, and a simple model generation unit 125. The arrangement unit 115 will be described in detail later.

[0017] The language model 117 is a language model, such as a large-scale language model, that has been trained in advance for generating API processing statements. The language model 117 receives the above-mentioned user input in natural language and outputs API processing statements. The user input is related to railways, such as "rail tracks from station A to station B," "a 1-km radius around station C," or "stations and tracks of regional railway company D." The API processing statements are commands written in accordance with predetermined API rules to acquire data corresponding to the user input. The output of the language model 117 is required to be free of errors in API grammar and proper nouns such as station, line, and railway company names. Therefore, data related to API grammar and functions, as well as data related to railways such as station names, are used in the process of creating the language model 117. A specific method for creating the language model 117 will be described in a modified example.

[0018] The 3D model DB 170 stores at least 3D model data related to railways. For example, the 3D model DB 170 includes 3D models of trains, station buildings, platforms, tracks, railroad crossing alarms, traffic lights, and the like. Note that while the database is described here for convenience, the data for each 3D model does not need to be compiled in one place. The 3D model includes at least three-dimensional shape and texture data. The texture data may be image data, a combination of color data and patterns, or color data alone. The 3D model may also include animation data.

[0019] Virtual space DB 151 stores data related to the virtual space controlled by virtual space control unit 150. For example, virtual space DB 151 stores data such as the position, orientation, state quantity, three-dimensional shape, and texture of each object placed in the virtual space. The position of an object is the position of the object in the virtual space. The scale of the virtual space may be the same as or different from that of the real space. For example, the origin of the virtual space is set to a predetermined latitude, longitude, and altitude. In the initial state, no data is stored in virtual space DB 151, and data is stored by placement unit 115 and virtual space control unit 150. The data stored in virtual space DB 151 is updated by virtual space control unit 150 based on user operations. In other words, objects in the virtual space are added, deleted, and moved based on user operations.

[0020] The virtual space control unit 150 controls the virtual space using data stored in the virtual space DB 151. The virtual space control unit 150 has at least a function for displaying the virtual space. The display function is, for example, a function for displaying the virtual space by freely changing the viewpoint and line of sight. The virtual space control unit 150 allows the user to view the virtual space via the input / output device 44 or the communication device 45 and reflects the user's operations in the virtual space. The term "user" here refers to a human being, and may refer to two or more people. In other words, the virtual space control unit 150 can simultaneously provide an image of the same virtual space to multiple users. The virtual space display may be a still image or a video. The virtual space control unit 150 may display dynamic movement, i.e., animation, by moving or transforming objects placed in the virtual space.

[0021] The virtual space control unit 150 may further have an editing function and a simulation function. The editing function is to edit data related to the virtual space based on user operations, and specifically, to add, change, and delete data stored in the virtual space DB 151. For example, based on user operations, objects already placed in the virtual space may be moved or deleted. Objects may also be added to the virtual space based on user operations. Furthermore, parameters of objects placed in the virtual space may be changed based on user operations.

[0022] The map node DB 160 stores at least node data related to railways. However, the map node DB 160 may also store node data unrelated to railways. Node data related to railways are nodes that indicate at least stations and tracks. Each node includes a combination of location data in real space, a station name, and a line name. Each node may also include a direction of travel, in other words, either up or down, or, in the case of a circular line, either an inner loop or an outer loop. A station may be composed of a single node or multiple nodes. If a station is composed of a single node, it is desirable to provide auxiliary data indicating the shape of the station separately. If a station is composed of multiple nodes, it is desirable to set the shape of the platform where trains depart and arrive, especially the edge of the platform, as one of the nodes. The location data in real space is, for example, a combination of latitude and longitude.

[0023] The map node DB 160 may also include data on other railroad components, such as signals, switches, crossing gates, and crossing alarms. For nodes indicating these, data such as latitude and longitude, identifiers or names of the two nearest stations, and identifiers or names of the line that the node is involved in is included in the map node DB 160. For nodes indicating railroad tracks, data such as the node identifier, latitude and longitude of the node, identifiers of the two adjacent nodes, identifiers or names of the two nearest stations, and identifiers or names of the line that the node is part of is included in the map node DB 160.

[0024] The map node DB 160 may be configured with one table, or may be configured with multiple tables or multiple databases. The map node DB 160 may store data in a format other than a table, for example, a NoSQL format. An example in which the map node DB 160 is configured with multiple tables will be described below with reference to Figures 3 to 7.

[0025] 3 is a diagram showing an example of a station node table 160-1 that constitutes the map node DB 160. The station node table 160-1 stores data related to railway stations. The station node table 160-1 is made up of multiple records, and each record has fields for a node ID 16011, a station name 16012, a line name 16013, a platform 16014, an external shape 16015, an associated rail 16016, and a 3D model ID 16017, with one record corresponding to one station.

[0026] The node ID 16011 is the identifier of the station. The station name 16012 is the name of the station. The line name 16013 is the name of the line of the train that stops at that station. The platform 16014 is the identifier of the platform that the station has. The outer shape 16015 indicates the outer shape of the station, that is, the latitude and longitude of the four corners. The associated rail 16016 is the identifier of the track on which the train that stops at that station runs. The 3D model ID 16017 is the identifier of the three-dimensional model of the station.

[0027] 4 is a diagram showing an example of a rail track table 160-2 constituting the map node DB 160. The rail track table 160-2 stores data related to the rail tracks on which trains run. The rail track table 160-2 is made up of multiple records, each of which has fields for a track ID 16021, a passing station 16022, a passing platform 16023, a signal ID 16024, a switch ID 16025, and track coordinates 16026, with one record corresponding to one rail track. Note that here, a set of physically connected rails is called a rail track, and the ends of the rail track are switches, bumpers, etc.

[0028] The track ID 16021 is an identifier for that rail track. The passing station 16022 is the name or identifier of a station at which a train running on that rail track stops or passes. The name or identifier entered in the passing station 16022 corresponds to the entry in the station node table 160-1. The passing platform 16023 is the identifier of a platform at which a train running on that rail track stops or passes. If the rail track passes through a station but does not stop and runs at a position that does not face a platform, no information is entered in the passing platform 16023. Also, if one rail track is sandwiched between two platforms at a terminal station, for example, multiple passing platforms 16023 are entered for one passing station.

[0029] The signal ID 16024 is the identifier of a signal that the driver of a train traveling on that rail track should check. The turnout ID 16025 is the identifier of a turnout related to the branching or merging of that rail track. The track coordinates 16026 are a collection of coordinates required to reproduce that rail track. For example, the coordinates of an inflection point on that rail track, i.e., a combination of latitude and longitude, are stored in the track coordinates 16026. The order of the coordinates written is arranged so that they are the same as or the reverse of the order in which a train would pass if it were traveling on that rail track.

[0030] 5 is a diagram showing an example of a traffic light table 160-3 that constitutes the map node DB 160. The traffic light table 160-3 stores data related to traffic lights used for train operation management. The traffic light table 160-3 is made up of multiple records, and each record has fields for a traffic light ID 16031, a target track 16032, a target station 16033, coordinates 16034, an attitude 16035, and a 3D shape 16036, with one record corresponding to one traffic light.

[0031] The signal ID 16031 is the identifier of the signal. The target track 16032 is the identifier of the line on which the train that should reference the signal runs. The target station 16033 is the name or identifier of the station where the signal is installed, or the two nearest stations to which the signal is installed. The coordinates 16034 are the coordinates of the signal, which are latitude and longitude. However, the coordinates 16034 may also include altitude information, i.e., altitude. The attitude 16035 is the attitude of the signal, and is, for example, a combination of yaw angle, roll angle, and pitch angle that indicate the deviation from the standard state. The standard state is, for example, a state in which the front defined in the 3D model faces north and is horizontally positioned. The 3D shape 16036 is the identifier of the 3D model that indicates the configuration of the signal.

[0032] FIG. 6 is a diagram showing an example of a switch table 160-4 constituting the map node DB 160. The switch table 160-4 stores data related to switches that control train track changes. The switch table 160-4 is composed of multiple records, and each record has fields for a switch ID 16041, a target track 16042, a target station 16043, coordinates 16044, a posture 16045, and a 3D shape 16046. The switch ID 16041 is an identifier for the switch. The target track 16042 is an identifier for the target track controlled by the switch. The target station 16043 is the name or identifier of the station where the switch is installed or the two stations nearest to the switch. The coordinates 16044, posture 16045, and 3D shape 16046 are the same as those in FIG. 5, so their explanations are omitted.

[0033] FIG. 7 is a diagram showing an example of a platform table 160-5 constituting the map node DB 160. The platform table 160-5 stores data related to the platforms of each station. The platform table 160-5 is made up of multiple records, and each record has fields for a platform ID 16051, a target track 16052, a target station 16053, and shape coordinates 16054. The platform ID 16051 is an identifier for the platform. The target track 16052 is an identifier for the rail track facing the platform. The target station 16053 is the station to which the platform belongs.

[0034] The shape coordinates 16054 are coordinates that indicate the shape of the platform and include the coordinates of at least the four corners of the platform. However, if the platform has a triangular shape, there may be three coordinates, or for a more accurate representation, there may be five or more coordinates. These coordinates are, for example, a combination of latitude, longitude, and altitude. However, if the altitude of the platform is approximately constant, the coordinates may include only latitude and longitude, and the altitude may be recorded separately. Also, the height from the tracks may be recorded instead of the altitude.

[0035] The coordinate conversion unit 123, 3D model processing unit 124, and simple model generation unit 125 included in the placement unit 115 will be described. The coordinate conversion unit 123 converts the position of a node listed in the map node DB 160 into a position in virtual space. Specifically, the coordinate conversion unit 123 calculates the X coordinate value, Y coordinate value, and Z coordinate value of the virtual space for each of the node's latitude, longitude, and altitude by multiplying the difference from a predetermined origin position by a scale variable Sx, which is a coefficient for scaling. The 3D model processing unit 124 acquires data of the corresponding 3D model from the 3D model DB 170, multiplies each dimension of the three-dimensional shape by the aforementioned scale variable Sx, and then places the 3D model at the coordinates calculated by the coordinate conversion unit 123.

[0036] The simple model generation unit 125 generates 3D models for objects for which no 3D model is specified in the map node DB 160 or for which no 3D model is registered in the 3D model DB 170. This is because nodes are points, and if they remain points, it would be inconvenient to visually represent them in three-dimensional space. For example, the simple model generation unit 125 creates a 3D model for an object for which no 3D model is specified, such as the platform shown in Figure 7.

[0037] In this case, the simple model generation unit 125 can generate a 3D model using the following procedure. That is, the simple model generation unit 125 first forms the upper surface by connecting points indicated by the shape coordinates with straight lines. Next, the simple model generation unit 125 forms the lower surface by projecting this upper surface perpendicularly onto the ground. The simple model generation unit 125 then forms a hollow, closed space by connecting the outer edges of the upper surface and the lower surface along the entire circumference, and defines this as a 3D model. For example, if the shape coordinates 1654 of the platform are composed of four coordinates, the shape of the platform will be a rectangular parallelepiped because the upper surface is rectangular. Note that the procedure shown here is an example, and the method by which the simple model generation unit 125 generates a 3D model is not limited to this.

[0038] 8 is a schematic diagram showing the processing of the virtual space generation system 1. First, the user 9 inputs "Display the railway from station A to station B" into the user interface 111 using a character string or voice. When the input is voice, the user interface 111 records the user's speech using a microphone and converts it into an input character string 801, which is a character string, using a voice recognition mechanism (not shown), and outputs it to the processing statement generation unit 113. When the input is a character string using a keyboard or the like, the user interface 111 outputs the character string as is as input character string 801 to the processing statement generation unit 113.

[0039] The processing statement generation unit 113 inputs an input character string 801 into the language model 117 to obtain an API processing statement 802. The processing statement generation unit 113 then inputs this API processing statement 802 to the node data acquisition unit 114. The node data acquisition unit 114 inputs the input API processing statement 802 as is to the API processing unit 112. The API processing unit 112 processes the input API processing statement 802 and acquires necessary data (hereinafter referred to as "acquired data" 803) from the map node DB 160. The acquired data 803 is, for example, data on the node of station A, the node of station B, the rail track connecting stations A and B, traffic signals installed near the rail track, switches, and platforms along the rail track connecting stations A and B. In the examples shown in Figures 3 to 7, the records with node IDs N1 and N2 in Figure 3, the record with track ID R1 in Figure 4, the record with signal IDs S1 and S2 in Figure 5, the record with switch ID W1 in Figure 6, and the record with platform IDs P11 and P21 in Figure 7 are extracted.

[0040] The API processing unit 112 outputs the acquired data 803 extracted from the map node DB 160 to the node data acquisition unit 114. The node data acquisition unit 114 outputs the acquired data 803 input from the API processing unit 112 to the arrangement unit 115. The arrangement unit 115 processes the acquired data 803 and inputs it to the virtual space DB 151. Specifically, the coordinate conversion unit 123 performs coordinate conversion, the 3D model processing unit 124 acquires and converts a 3D model from the 3D model DB 170, and the simple model generation unit 125 creates a 3D model.

[0041] FIG. 9 is a diagram showing an example of a screen display by the virtual space control unit 150. As described above, the virtual space control unit 150 has a display function for displaying the virtual space represented by the data stored in the virtual space DB 151 as an image. The viewpoint and line of sight can be freely set and may be changed arbitrarily by the user, or multiple options may be set in advance. FIG. 9(a) shows a viewpoint overlooking Stations A and B on the ground from above, while FIG. 9(b) shows a viewpoint overlooking Station B from near Station A on the ground. In FIG. 9(a), the entire rail track connecting Stations A and B can be seen, but the rail track cannot be seen in detail because it is far away. In FIG. 9(b), the entire rail track connecting Stations A and B cannot be seen, but the rail track near the viewpoint can be observed in detail.

[0042] According to the above-described first embodiment, the following advantageous effects can be obtained. (1) The virtual space generation system 1 includes a processing statement generation unit 113 that inputs user input, which is linguistic information related to railways entered by a user, into a language model 117 to generate an API processing statement, a node data acquisition unit 114 that inputs the API processing statement generated by the processing statement generation unit 113 into an API processing unit 112 and acquires node data related to railways, a placement unit 120 that stores the node data in a virtual space database 151, and a virtual space control unit 150 that renders a virtual space based on the data stored in the virtual space database 151. Therefore, it is possible to generate a virtual space related to any railway.

[0043] (2) The API processing unit 112 is connected to a map node database 160. Data relating to real railway lines is stored as nodes in the map node database 160. This makes it possible to reproduce real railway lines in a virtual space.

[0044] (3) The language model corrects any errors in proper nouns contained in the user's input, and the API processing statement is output with the corrected proper noun errors in the user's input and utterances.

[0045] (4) The node data relating to railways includes at least one of rail tracks, platforms, and signals.

[0046] (5) The virtual space control unit 150 has a viewpoint change function and a line of sight change function.

[0047] (6) The virtual space control unit 150 edits the data stored in the virtual space database based on the user's instructions, thereby realizing at least one of adding, deleting, and moving an object in the virtual space.

[0048] (Variation 1) 10 is a diagram showing a method for generating the language model 117. The language model 117 is generated by an additional learning unit 223 using a general-purpose language model 221 generated in advance, railway map data 222A, and a railway API specification 222B. Although the additional learning unit 223 is not shown in the configuration of FIG. 1, the additional learning unit 223 may be included in the virtual space generation system 1. Alternatively, the additional learning unit 223 may generate the language model 117 outside the virtual space generation system 1, and the language model 117 may be imported into the virtual space generation system 1.

[0049] The railway map data 222A includes railway line names, station names on each line, the order of stations on each line, and the connections between the lines. The railway API specification 222B is an API specification that can be interpreted by the API processing unit 112. The railway API specification 222B includes data on function names related to the API and arguments for each function. The additional learning unit 223 performs transfer learning and fine tuning.

[0050] According to this first modification, in addition to the effects of the first embodiment, the following effects are achieved. (7) The virtual space generation system 1 includes an additional learning unit 223 that creates a language model by fine-tuning or transfer learning a pre-created general-purpose language model using railroad map data and API-related data. Therefore, the language model 117 required for the virtual space generation system 1 can be generated using a general-purpose language model.

[0051] (Variation 2) FIG. 11 is a configuration diagram of a virtual space generation system 1B in Modification 2. In this modification, the virtual space generation system 1 does not include the API processing unit 112, language model 117, map node DB 160, and 3D model DB 170. The API processing unit 112, language model 117, map node DB 160, and 3D model DB 170 may each be implemented individually by hardware different from that of the virtual space generation system 1, or all three may be implemented by the same hardware. The API processing unit 112, map node DB 160, and 3D model DB 170 may each be connected to the virtual space generation system 1 via a communication device 45, or may be connected via a data transmission interface different from that of the communication device 45, such as a Universal Serial Bus. The API processing unit 112 may use an API processing server publicly available on the Internet.

[0052] (Variation 3) FIG. 12 is a configuration diagram of a virtual space generation system 1C in Modification 3. In addition to the configuration of the first embodiment, the virtual space generation system 1C further includes a virtual space storage unit 152, a storage area 153, and a virtual space restoration unit 154. The virtual space storage unit 152 stores, i.e., backs up, the virtual space DB 151. The virtual space storage unit 152 stores the data stored in the virtual space DB 151 in the storage area 153. The storage area 153 can store multiple pieces of data for the virtual space DB 151. The virtual space restoration unit 154 restores the virtual space DB 151 based on past backups stored in the storage area 153. The virtual space storage unit 152 may back up the virtual space DB 151 automatically at a predetermined time interval, for example, every 24 hours, or may perform a backup based on an operator's instructions.

[0053] According to the third modification, in addition to the effects of the first embodiment, the following effects are achieved. (8) The system includes a virtual space storage unit 152 that backs up the virtual space database, and a virtual space restoration unit 154 that restores the virtual space database based on past backups of the virtual space storage unit. This allows the virtual space DB 151 at any time to be saved and reproduced.

[0054] (Variation 4) The virtual space control unit 150 may place an object corresponding to each user in the virtual space and reflect it in the rendering of the virtual space. This object may be a humanoid avatar or a body part, particularly a face or hand. The virtual space control unit 150 may also display a name or nickname as an identifier to identify the user.

[0055] (Variation 5) The placement unit 120 may take in real-time data at short time intervals, for example, every second, and update the virtual space DB 151. In this modification, for example, the position of trains, congestion at stations and roads, and the like in the real world can be reflected in the virtual space.

[0056] In each of the above-described embodiments and modifications, the functional block configurations are merely examples. Some functional configurations shown as separate functional blocks may be configured as an integrated unit, or a configuration shown in a single functional block diagram may be divided into two or more functions. Furthermore, some of the functions of each functional block may be provided by other functional blocks.

[0057] (Variation 6) In the embodiment described above, the map node DB 160 includes the station node table 160-1, the rail track table 160-2, the signal table 160-3, the switch table 160-4, and the platform table 160-5. However, the map node DB 160 only needs to include at least the station node table 160-1 and the rail track table 160-2, and need not include the others.

[0058] In the above-described embodiments and modifications, the program is stored in a ROM (not shown), but the program may be stored in a non-volatile memory (not shown). Furthermore, the virtual space generation system 1 may be provided with an input / output interface (not shown), and the program may be loaded from another device as needed via the input / output interface and a medium available to the virtual space generation system 1. Here, the medium refers to, for example, a storage medium detachable from the input / output interface, or a communication medium, i.e., a wired, wireless, or optical network, or a carrier wave or digital signal propagating through the network. Furthermore, some or all of the functions realized by the program may be realized by a hardware circuit or FPGA.

[0059] The above-described embodiments and modifications may be combined with each other. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments conceivable within the scope of the technical concept of the present invention are also included within the scope of the present invention. [Explanation of symbols]

[0060] 1, 1B, 1C: Virtual space generation system 111: User Interface 112: API processing section 113: Processing statement generation unit 114: Node data acquisition unit 115: Placement section 117: Language Model 120: Placement section 123: Coordinate conversion section 124: 3D model processing section 125: Simple model generation unit 150: Virtual space control section 151: Virtual Space Database 152: Virtual Space Storage Department 154: Virtual space restoration unit 160: Map node database 160-1: Station node table 160-2: Rail track table 221: General-purpose language model 222A: Railway map data 222B: Railway API Specification 223: Additional Learning Section 151: Virtual Space Database 160: Map node database 170: 3D model database

Claims

1. a processing statement generation unit that inputs user input, which is linguistic information related to railways input by a user, into a language model and generates API processing statements; a node data acquisition unit that inputs the API processing statement generated by the processing statement generation unit into an API processing unit and acquires node data related to railways; an arrangement unit that stores data of the nodes in a virtual space database; a virtual space control unit that renders a virtual space based on the data stored in the virtual space database.

2. 2. The virtual space generation system according to claim 1, A map node database is connected to the API processing unit, In the virtual space generation system, data relating to real railway lines is stored as nodes in the map node database.

3. 2. The virtual space generation system according to claim 1, A virtual space generation system, wherein the API processing statement has an error in a proper noun contained in the user input corrected by the language model.

4. 2. The virtual space generation system according to claim 1, The virtual space generation system further comprises an additional learning unit that creates a pre-created general-purpose language model by performing fine tuning or transfer learning using railway-related map data and data related to the API.

5. 2. The virtual space generation system according to claim 1, A virtual space generation system, wherein the node data relating to the railway includes at least one of a rail track, a platform, and a signal.

6. 2. The virtual space generation system according to claim 1, a virtual space storage unit that backs up the virtual space database; The virtual space generation system further comprises a virtual space restoration unit that restores the virtual space database based on a past backup of the virtual space storage unit.

7. 2. The virtual space generation system according to claim 1, The virtual space control unit is a virtual space generation system having a viewpoint change function and a line of sight change function.

8. 2. The virtual space generation system according to claim 1, The virtual space control unit edits data stored in the virtual space database based on user instructions, thereby realizing at least one of adding, deleting, and moving objects in the virtual space.

9. A virtual space generation method executed by one or more computers, comprising: inputting user input, which is linguistic information related to railways input by a user, into a language model to generate an API processing statement; inputting the generated API processing statement into an API processing unit to acquire node data related to railways; storing data of the nodes in a virtual space database; and drawing a virtual space based on the data stored in the virtual space database.

Citation Information

Patent Citations

  • Map information producing device and map information display device using the same

    JP2001305953A