WO2021176677A1 - 管理装置、管理方法及び管理プログラム - Google Patents

管理装置、管理方法及び管理プログラム Download PDF

Info

Publication number
WO2021176677A1
WO2021176677A1 PCT/JP2020/009540 JP2020009540W WO2021176677A1 WO 2021176677 A1 WO2021176677 A1 WO 2021176677A1 JP 2020009540 W JP2020009540 W JP 2020009540W WO 2021176677 A1 WO2021176677 A1 WO 2021176677A1
Authority
WO
WIPO (PCT)
Prior art keywords
road
lane
polygon
data
mesh
Prior art date
Application number
PCT/JP2020/009540
Other languages
English (en)
French (fr)
Inventor
淳 磯村
和大 宮原
一兵衛 内藤
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2022504905A priority Critical patent/JP7355216B2/ja
Priority to US17/908,534 priority patent/US20230160719A1/en
Priority to PCT/JP2020/009540 priority patent/WO2021176677A1/ja
Publication of WO2021176677A1 publication Critical patent/WO2021176677A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3863—Structures of map data
    • G01C21/3867—Geometry of map features, e.g. shape points, polygons or for simplified maps
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/28—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network with correlation of data from several navigational instruments
    • G01C21/30—Map- or contour-matching
    • G01C21/32—Structuring or formatting of map data
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804—Creation or updating of map data
    • G01C21/3807—Creation or updating of map data characterised by the type of data
    • G01C21/3815—Road data
    • G01C21/3819—Road shape data, e.g. outline of a route

Definitions

  • the present invention relates to a management device, a management method, and a management program.
  • the inside / outside determination technology for determining whether a specific coordinate is included inside a specific polygon has been applied to determine whether the coordinates of a geographical vehicle or the like are included in the polygon representing the road area. There is.
  • the present invention has been made in view of the above, and an object of the present invention is to provide a management device, a management method, and a management program for managing polygon data that enables high-speed search.
  • the management device of the present invention refers to the reception unit that accepts the input of the road map data and the road map data, and sets the first polygon indicating the area of the lane.
  • the management method of the present invention is a management method executed by the management device, in which a step of accepting input of road map data and a first polygon indicating a lane area are generated by referring to the road map data.
  • a process a process of generating a second polygon expressing a spatial index for each spatial mesh divided by a predetermined size, and a determination of which spatial mesh the first polygon exists in are determined, and the determination result is obtained.
  • it is characterized by including a step of associating the data of the first polygon with the data of the second polygon and storing the data in the road coordinate database.
  • the management program of the present invention includes a step of accepting input of road map data, a step of referring to the road map data, and a step of generating a first polygon indicating a lane area. For each spatial mesh divided by a predetermined size, a step of generating a second polygon expressing a spatial index and a determination as to which spatial mesh the first polygon exists in are determined, and depending on the determination result, A computer is made to perform a step of associating the data of the first polygon with the data of the second polygon and storing the data in the road coordinate database.
  • FIG. 1 is a block diagram showing an example of the configuration of the communication system according to the first embodiment.
  • FIG. 2 is a diagram illustrating an example of the configuration of the road coordinate management system according to the first embodiment.
  • FIG. 3 is a diagram illustrating an outline of processing of each component of the road coordinate conversion device shown in FIG.
  • FIG. 4 is a diagram illustrating a definition of a non-road area.
  • FIG. 5 is a diagram illustrating a definition of a road.
  • FIG. 6 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 7 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 8 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. FIG.
  • FIG. 9 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 10 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 11 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 12 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 13 is a diagram showing an example of mesh information.
  • FIG. 14 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 15 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 16 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. FIG.
  • FIG. 17 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 18 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG.
  • FIG. 19 is a flowchart showing a processing procedure of the road coordinate conversion process according to the first embodiment.
  • FIG. 20 is a diagram showing an example of polygons for each lane that can be generated by the road coordinate conversion device.
  • FIG. 21 is a diagram illustrating an example of the configuration of the road coordinate management system according to the second embodiment.
  • FIG. 22 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 23 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 24 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 25 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 26 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 27 is a diagram illustrating a processing flow of the road coordinate conversion device shown in FIG. 21.
  • FIG. 28 is a flowchart showing a processing procedure of the road coordinate conversion process according to the second embodiment.
  • FIG. 29 is a diagram showing an example of polygons for each lane that can be generated by the road coordinate conversion device.
  • FIG. 30 is a diagram showing an example of polygons for each lane that can be generated by the road coordinate conversion device.
  • FIG. 31 is a diagram showing an example of a computer in which a road coordinate conversion device is realized by executing a program.
  • the management device refers to the road map data, generates lane-specific polygons (first polygons) indicating the lane area, and generates a spatial index for each spatial mesh divided by a predetermined size.
  • a mesh-specific polygon (second polygon) for expressing the spatial index to be expressed is generated, it is determined in which spatial mesh the lane-specific polygon exists, and according to the determination result, the data of the first polygon is used. It is stored in the road coordinate database in association with the data of polygons for each mesh.
  • FIG. 1 is a diagram showing an example of a configuration of a communication system according to the first embodiment.
  • the communication system 100 according to the first embodiment is mounted on a terminal device (not shown), and is used in a spatiotemporal analysis application 10 such as lane congestion detection and GeoFencing.
  • the PIP processing result D3 for determining the position of the vehicle in the lane is provided.
  • the road coordinate database (DB) 30 (OSS: Open Source Software) in the road coordinate management system 20 determines the polygons for each lane representing the lane area in response to the spatial index search by the spatiotemporal analysis application 10.
  • the road coordinate search result D1 including is output.
  • the spatio-temporal DB 60 which stores information on vehicle data, outputs a vehicle search result D2 including vehicle coordinates to the spatio-temporal analysis application 10.
  • the PIP processing module 70 performs PIP processing for determining in which lane of the road the vehicle is located, and the PIP processing result D3. Is output.
  • the spatiotemporal analysis application 10 executes lane congestion detection, GeoFence, etc. based on the PIP processing result D3.
  • FIG. 2 is a diagram illustrating an example of the configuration of the road coordinate management system 20 shown in FIG.
  • the road coordinate management system 20 includes a road coordinate conversion device 50 and a road coordinate DB 30.
  • the road coordinate conversion device 50 includes lane-specific polygons indicating the area of the lane generated using the road map data 40 including the longitude-latitude information of the shoulder line and the longitude-latitude information of the lane marking, and each mesh for expressing the spatial index. It is stored in the road coordinate DB 30 in association with the polygon (second polygon).
  • the lane-specific polygon is data indicating the coordinates of each vertex of the polygon indicating the area of the lane.
  • the mesh-specific polygon is data indicating the coordinates of each vertex of the spatial index of the polygon shape divided according to a predetermined accuracy.
  • the road coordinate DB 30 stores the polygons for each mesh and the polygons for each lane in association with each other.
  • the road coordinate DB 30 has a spatial index search function, searches for polygons by lane using the spatial index as a search key, and outputs the road coordinate search result D1.
  • the road map data 40 stores data including road ID, lane ID, number of lanes, latitude and longitude at the center of the road, latitude and longitude at the center of the lane, and latitude and longitude of lane markings (white lines and dotted lines at the road edge). Will be done.
  • longitude / latitude data is stored with attributes such as lane information, roadway information, lane markings, shoulder lines, intersection areas, and road markings.
  • the road coordinate conversion device 50 generates polygons by using the longitude / latitude data of the lane information, the lane information, the lane markings, and the shoulder line among the data contained in the road map data 40.
  • the road coordinate conversion device 50 for example, a predetermined program is read into a computer or the like including a ROM (Read Only Memory), a RAM (Random Access Memory), a CPU (Central Processing Unit), etc., and the CPU executes the predetermined program. It is realized by doing. Further, the road coordinate conversion device 50 has a communication interface for transmitting and receiving various information to and from other devices connected via a network or the like. For example, the road coordinate conversion device 50 has a NIC (Network Interface Card) or the like, and communicates with other devices via a telecommunication line such as a LAN (Local Area Network) or the Internet.
  • NIC Network Interface Card
  • the road coordinate conversion device 50 includes a reception unit 51, a lane-specific polygon generation unit 52 (first generation unit), a mesh-specific polygon generation unit 53 (second generation unit), and a storage unit.
  • FIG. 3 is a diagram illustrating an outline of processing of each component of the road coordinate conversion device 50 shown in FIG.
  • the reception unit 51 accepts the input of the road map data 40.
  • the road map data 40 includes latitude / longitude data 40-1 such as a shoulder line and a lane marking line, for example.
  • the reception unit 51 accepts input of the longitude / latitude data of the road shoulder line and the longitude / latitude data of the lane marking line as the road map data.
  • the lane-specific polygon generation unit 52 refers to the road map data 40 and generates a lane-specific polygon (for example, see 50-1 in FIG. 3) indicating a lane area.
  • the lane-specific polygon generation unit 52 refers to the road map data, sets the area surrounded by the shoulder line as the non-road area, and positions the area between the two adjacent non-road areas and the two non-road areas. Generate polygons for each lane based on the data of the lane markings.
  • the mesh-specific polygon generation unit 53 generates mesh-specific polygons expressing a spatial index for each spatial mesh divided by a predetermined size.
  • the storage unit 54 determines in which space mesh the lane-specific polygons exist, and stores the lane-specific polygon data and the mesh-specific polygon data in the road coordinate DB 30 in association with each other according to the determination result. Specifically, the storage unit 54 is data in which the data of the polygons for each mesh (spatial index) and the data of the polygons for each lane corresponding to the polygons for each mesh are associated with each other (see, for example, 30-3 in FIG. 3). Is stored in the road coordinate DB 30.
  • the storage unit 54 searches for each lane-specific polygon included in each space mesh for each space mesh, and corresponds the searched lane-specific polygon with the mesh-specific polygon corresponding to the space mesh including the lane-specific polygon. Attached and stored in the road coordinate DB 30.
  • the road coordinate conversion device 50 realizes polygon generation by generating polygons for each lane using white lines such as shoulder lines and lane markings, and then filtering by spatial index.
  • the road coordinate conversion device 50 manages polygons by storing road polygons for each range delimited by the spatial mesh (geohash). That is, the road coordinate conversion device 50 determines whether or not the polygon exists in the mesh separated by the space mesh, and then stores the polygon in the road coordinate DB 30 in association with the space mesh. As a result, the road coordinate conversion device 50 can perform a high-speed search without many determinations by calculating the spatial mesh to be searched in advance.
  • FIG. 4 is a diagram illustrating a definition of a non-road area.
  • FIG. 5 is a diagram illustrating a definition of a road.
  • the area surrounded by the shoulder line is not a "road”, that is, a "non-road area” (see, for example, Ra in FIG. 4).
  • the distance between the road shoulder line and the road shoulder line adjacent to the road shoulder line is 3 m or more
  • the distance between the road shoulder line and the road shoulder line adjacent to the road shoulder line is a “road”.
  • the distance between the road shoulder line A and the road shoulder line B is 3 m or more
  • the distance between the road shoulder line A and the road shoulder line B is a “road” (see (1) in FIG. 5).
  • the distance between the lane marking line and the lane marking line adjacent to the lane marking line is 3 m or more, there is a "lane” between the lane marking line and the adjacent lane marking line. Specifically, if the distance between the lane marking A and the lane marking B is 3 m or more, there is a "lane” between the lane marking A and the lane marking B (see (2) in FIG. 5).
  • the road coordinate conversion device 50 sets the area surrounded by the shoulder line as a non-road area (see, for example, Ra in FIG. 4) in order to generate polygons for each lane. Then, the road coordinate conversion device 50 generates lane-specific polygons based on the data of the lane markings located between the two adjacent non-road areas and the two non-road areas.
  • FIG. 6 is a two-dimensional display of each road shoulder line and each lane marking line based on the longitude / latitude data of the road shoulder line and the longitude / latitude data of the lane marking line of the road map data 40 used in the processing.
  • the shoulder line and the lane marking line are often cut off in the middle. Therefore, when the distance between the end points of the two adjacent road shoulder lines is L or less, the polygon generation unit 52 for each lane connects the end points of the two road shoulder lines (see (1) in FIG. 7). Generates one shoulder line. Then, the lane-specific polygon generation unit 52 assigns a label to the generated road shoulder line (see (2) in FIG. 7). For example, the lane-specific polygon generation unit 52 assigns the label “r1” to the road shoulder line “1” which is formed by connecting the end points at three places.
  • the lane-specific polygon generation unit 52 joins the end points of the two division lines and assigns a label to the division line.
  • L is set to, for example, 3 m (mean width of lanes). It should be noted that the distance between the end points of the two adjacent road shoulder lines and the distance between the end points of the two adjacent lane marking lines described above may be set differently depending on the average width of the road or lane. good.
  • the lane-specific polygon generation unit 52 sets the area surrounded by the shoulder line as a non-road area (see (1) in FIG. 8) and converts it into polygons. Then, the polygon generation unit 52 for each lane assigns a unique label to each non-road area that has been converted into polygons (see (2) in FIG. 8). For example, the lane-specific polygon generation unit 52 assigns the label “h1” to the non-road area “1”.
  • the lane-specific polygon generation unit 52 draws a perpendicular bisector with respect to the line between the point n constituting the side of each non-road area and the point n + 1 adjacent to the point n in the outward direction of the non-road area.
  • the points n and the points n + 1 are set at predetermined intervals, for example, on the sides of the non-road area.
  • the lane-specific polygon generation unit 52 draws a perpendicular bisector v1 outward of the non-road region h1 with respect to the line between the points n and n + 1 for the non-road region h1 ((1) in FIG. 9). )reference).
  • the lane-specific polygon generation unit 52 includes the first non-road area A where the vertical bisectors intersect, and all the lane markings (including the shoulder line) that intersect the vertical bisector until the first non-road area A is reached.
  • the lane-specific polygon generation unit 52 sets A as the first non-road region h2 at which the vertical bisectors v1 intersect, and the vertical of all the lane markings B that intersect until the first non-road region h2 is reached.
  • the point c6 is an intersection of the vertical bisector v1 and the side of the non-road region h2.
  • the lane-specific polygon generation unit 52 is the distance between the start point of the vertical bisector and the point of the lane marking line B adjacent to the start point, and the first non-road region A where the vertical bisector v1 intersects. The distance between the intersection and the point of the adjacent lane line B and the distance between each point of the adjacent lane line B are calculated. Then, if the calculated distance is L (for example, 3 m, which is the average width of the lane) or more, the polygon generation unit 52 for each lane stores the calculated distance and assigns a label to the point.
  • L for example, 3 m, which is the average width of the lane
  • the first half of the label shows the non-road area that is the starting point of the vertical bisector and the first non-road area A where the vertical bisector intersects, and the second half of the label is the vertical bisector.
  • the crossing order "n (1 ⁇ n ⁇ N (maximum value)" is shown.
  • the lane-specific polygon generation unit 52 calculates the distance between the start point c0 of the vertical bisector v1 and the point c1 of the adjacent lane marking B. In this case, since the calculated distance is less than L, the lane-specific polygon generation unit 52 does not add a label. Subsequently, the lane-specific polygon generation unit 52 calculates the distance between the point c1 at which the vertical bisector v1 intersects first and the point c2 at which the vertical bisector v1 intersects second.
  • the lane-specific polygon generation unit 52 assigns the label "h1 ⁇ h2, 1st” to the point c1 and labels "h1 ⁇ h2, 2nd” to the point c2.
  • the polygon generation unit 52 for each lane has labels "h1 ⁇ h2, 3rd”, labels “h1 ⁇ h2, 4th”, and labels "h1 ⁇ h2" at points c3 to c5, respectively. , 5th "is given.
  • the lane-specific polygon generation unit 52 moves the start point of the vertical bisector in the non-road region h1 by a predetermined distance, and repeats the processes of FIGS. 9 to 11. As a result, points with labels are set for each predetermined distance on the division line.
  • the polygon generation unit 52 for each lane refers to the label of each point, and among the points to which the label having the same first half is given, the crossing order of the second half of the label is "n" and "n + 1".
  • the given points are combined clockwise to generate a polygon for each lane.
  • the lane-specific polygon generation unit 52 is among the points of the division line between the non-road area h1 and the non-road area h2 in which "h1 ⁇ h2" is assigned to the first half of the label.
  • Each point whose second half of the label is "first” and each point whose second half of the label is “second” are combined clockwise.
  • the lane-specific polygon generation unit 52 generates the lane-specific polygon 1.
  • the polygon generation unit 52 for each lane among the points of the division line in which "h1 ⁇ h2" is assigned to the first half of the label, each point where the second half of the label is "second” and "third".
  • the polygon 2 for each lane is generated by combining each point of the above in a clockwise direction.
  • the lane-specific polygon generation unit 52 generates a plurality of lane-specific polygons from the longitude-latitude data of the shoulder line and the lane marking of the road map data.
  • the mesh-specific polygon generation unit 53 is input when the accuracy (number of digits) of the spatial index (geohash) is input and the mesh information including the longitude and latitude values that are the polygon search range is taken from the external file prepared in advance. Depending on the accuracy, the size of the mesh delimiter is determined and a spatial index equivalent to the entire range of meshes to be searched is generated.
  • the mesh information may be in any data format, but is represented by longitude (decimal notation) and latitude value (decimal notation), for example, as illustrated in FIG.
  • the mesh-specific polygon generation unit 53 when the accuracy of the latitude of 15 digits and the longitude of 14 digits is input, the mesh-specific polygon generation unit 53 has a size of 1.25 km ⁇ 1.25 km. Determine the mesh break. Further, as shown in FIG. 14B, when the accuracy of the latitude of 18 digits and the longitude of 17 digits is input, the mesh-specific polygon generation unit 53 determines the mesh division having a size of 150 m ⁇ 150 m.
  • the mesh-specific polygon generation unit 53 generates mesh-specific polygons for expressing all geohashes according to the determined mesh division. Specifically, as shown in FIG. 15, when the latitude is 15 digits and the longitude is 14 digits, the mesh-specific polygon generation unit 53 determines a polygon having a size of 1.25 km ⁇ 1.25 km. Of the plurality of polygons, for example, the polygon 10 is set by the coordinates (x1, y1), (x2, y1), (x2, y2), (x1, y2) of each vertex of the polygon.
  • the mesh-specific polygon generation unit 53 stores the lane-specific polygons that have an “Intersect” relationship with each mesh-specific polygon.
  • Intersect an Intersect function such as JIS is assumed.
  • the mesh-specific polygon generation unit 53 stores the lane-specific polygons of lanes 3 to 10.
  • the mesh-specific polygon generation unit 53 searches for lane-specific polygons included in the mesh in mesh units, and assigns a spatial index to the lane-specific polygons that hit the search. Further, the mesh-specific polygon generation unit 53 may assign a serial number value that does not overlap in the mesh as a lane ID to the lane-specific polygon that hits the search. For example, as illustrated in FIG. 17, the mesh-specific polygon generation unit 53 searches for lane-specific polygons included in the mesh in order from mesh 1 to mesh 9, and assigns a spatial index to the lane-specific polygons that hit the search. do. In the example of FIG. 17, the mesh-specific polygon generation unit 53 assigns a spatial index to lanes 1, 2, and 3 because, for example, lanes 1, 2, and 3 included in the mesh 5 are extracted by a search.
  • the storage unit 54 stores each spatial index and lane-specific polygons corresponding to each spatial index in the road coordinate DB 30. For example, as shown in FIG. 18, with respect to the polygon 10, the storage unit 54 associates the spatial index of the polygon 10 with the lane-specific polygons of the lanes 3 to 10 having an Intersect relationship with the polygon 10-. 3 is stored in the road coordinate DB 30.
  • FIG. 19 is a flowchart showing a processing procedure of the road coordinate conversion process according to the present embodiment.
  • the road coordinate conversion device 50 accepts the input of the road map data 40 and performs a process of generating polygons for each lane.
  • the lane-specific polygon generation unit 52 refers to the road map data 40, and when the distance between the end points of two adjacent road shoulder lines and the distance between the end points of two adjacent division lines is L or less. Performs a process of joining the end points of the two lane markings or the end points of the two lane markings and assigning a label to the shoulder line or the lane marking line (step S1).
  • the lane-specific polygon generation unit 52 sets the area surrounded by the shoulder line as a non-road area, and after polygonizing, performs a process of assigning a label to the polygonized non-road area (step S2).
  • the lane-specific polygon generation unit 52 draws a perpendicular bisector with respect to the line between the points n and the points n + 1 forming the sides of each non-road region in the outward direction of the non-road region (step S3).
  • the lane-specific polygon generation unit 52 stores the first non-road area A where the vertical bisectors intersect, and all the lane markings B that intersect the vertical bisector until the first non-road area A is reached (step). S4).
  • the lane-specific polygon generation unit 52 determines the distance between the start point of the vertical bisector and the point of the lane marking line B adjacent to the start point, and the intersection of the first non-road region A where the vertical bisector intersects. And the distance between the intersection and the point of the adjacent bisector B, and the distance between each point of the adjacent bisector B are calculated, and if the calculated distance is L or more, it is memorized and a label is attached to the point. Grant (step S5).
  • the lane-specific polygon generation unit 52 moves the start point of the vertical bisector in the non-road region h1 by a predetermined distance, and repeats the processes of steps S3 to S5.
  • the polygon generation unit 52 for each lane refers to the label of each point, and among the points to which the labels having the same first half are given, the crossing order of the latter half of the label is given as "n" and "n + 1".
  • the generated points are combined clockwise to generate polygons for each lane (step S6).
  • the polygon generation unit 53 for each mesh determines the size of the mesh delimiter according to the input accuracy (step S7).
  • the mesh-specific polygon generation unit 53 generates mesh-specific polygons for expressing all geohashes according to the determined mesh division (step S8).
  • the mesh-specific polygon generation unit 53 stores lane-specific polygons that have an “Intersect” relationship with each mesh-specific polygon (step S9).
  • the storage unit 54 stores each spatial index and lane-specific polygons corresponding to each spatial index in the road coordinate DB 30 (step S10), and the road coordinate conversion device 50 ends the road coordinate conversion process.
  • the road coordinate conversion device 50 receives the input of the road map data, refers to the road map data, and generates a lane-specific polygon indicating the lane area. Then, the road coordinate conversion device 50 generates mesh-specific polygons expressing the spatial index for each spatial mesh divided by a predetermined size, determines in which spatial mesh the lane-specific polygons exist, and determines the determination result.
  • the data of the polygons for each lane and the data of the polygons for each mesh are associated with each other and stored in the road coordinate DB 30.
  • the road coordinate conversion device 50 manages polygons by storing road polygons for each range delimited by a spatial mesh (geohash). That is, the road coordinate conversion device 50 determines whether or not the polygon exists in the mesh separated by the space mesh, and then stores the polygon in the road coordinate DB 30 in association with the space mesh. As a result, the road coordinate conversion device 50 enables high-speed search without many determinations by, for example, calculating the spatial mesh to be searched in advance at the time of search processing.
  • the road map data including the longitude / latitude data of the road shoulder line and the longitude / latitude data of the lane marking is referred to, and the area surrounded by the road shoulder line is a non-road area. Is set, and a lane-specific polygon indicating the lane area is generated based on the data of the lane markings located between the two adjacent non-road areas and the two non-road areas.
  • a lane-specific polygon indicating the lane area is used as compared with the conventional method using the center line of the lane. It can be generated accurately.
  • FIG. 20 is a diagram showing an example of polygons for each lane that can be generated by the road coordinate conversion device 50.
  • the area surrounded by the shoulder line is set as a non-road area, and by generating polygons for each lane based on this non-road area, the part between the non-road areas surrounded by a circle is generated. It is possible to accurately generate polygons for each lane. As a result, in the communication system 100, the accuracy of lane congestion detection and the like can be improved by using the lane-specific polygons accurately generated by the road coordinate conversion device 50.
  • the road coordinate conversion device 50 generates mesh-specific polygons expressing the spatial index, associates the mesh-specific polygon data with the lane-specific polygon data corresponding to the mesh-specific polygons, and converts the mesh-specific polygons into the road coordinate DB 30.
  • the road coordinate DB 30 can output the road coordinate search result D1 including the lane-specific polygons that accurately represent the lane area to the spatiotemporal analysis application 10.
  • the road coordinate conversion device 50 determines that the distance between the two road shoulder lines is a road when the distance between the two adjacent road shoulder lines is equal to or greater than a predetermined distance, and determines that the road is between the two lane markings. When the distance is greater than or equal to a predetermined distance If the distance is greater than or equal to a predetermined distance, it is determined that there is a lane between the two lane markings. In this way, the road coordinate conversion device 50 can appropriately generate lane-specific polygons in order to appropriately determine the road and the lane.
  • the road coordinate conversion device 50 combines the end points of the two road shoulder lines when the distance between the end points of the two adjacent road shoulder lines is L or less, and the distance between the end points of the two adjacent road shoulder lines is If it is L or less, the end points of the two marking lines are joined.
  • the road coordinate conversion device 50 can appropriately set the non-road area and the lane marking by combining the shoulder line and the lane marking that are interrupted in the road map data 40 and correcting the shoulder line or the lane marking line. The polygon generation accuracy can be improved.
  • the road map data is referred to, the area surrounded by the shoulder line is set as the non-road area, and the lane marking line located between the two adjacent non-road areas and the two non-road areas.
  • the case of generating polygons for each lane based on the data of the above has been described, but the present invention is not limited to this.
  • the road map data may be referred to, and a lane-specific polygon may be generated based on the intersection of the lane marking line or the road shoulder line that intersects the perpendicular line from the lane information.
  • the lane-specific polygon generation unit 52 refers to the road map data and determines the lane area based on the intersection of the lane marking line or the road shoulder line intersecting the perpendicular line from the lane information.
  • the case of generating the first polygon shown will be described. The same configuration and processing as in the first embodiment will be omitted as appropriate.
  • FIG. 21 is a diagram illustrating an example of the configuration of the road coordinate management system 20A according to the second embodiment.
  • the road coordinate management system 20A has a road coordinate conversion device 50A and a road coordinate DB 30.
  • the road coordinate conversion device 50A includes a reception unit 51, a lane-specific polygon generation unit 52 (first generation unit), a mesh-specific polygon generation unit 53 (second generation unit), and a storage unit 54.
  • the reception unit 51 receives input of road map data 40 including longitude / latitude data of lane information indicating the center line of the lane, longitude / latitude data of the road shoulder line, and longitude / latitude data of the lane marking.
  • the road map data 40 includes latitude / longitude data 40-1 such as a shoulder line and a lane marking line, for example.
  • the lane-specific polygon generation unit 52 refers to the road map data 40, and based on the intersection of the division line or the shoulder line that intersects the vertical line from the lane information, the lane-specific polygon (for example, FIG. 3) shows the area of the lane. 50-1) is generated. Specifically, the lane-specific polygon generation unit 52 generates lane-specific polygons by connecting the intersections of the lane markings or road shoulder lines that intersect the perpendiculars from the lane information.
  • the mesh-specific polygon generation unit 53 generates a mesh-specific polygon that expresses a spatial index.
  • the storage unit 54 determines in which space mesh the lane-specific polygons exist, and stores the lane-specific polygon data and the mesh-specific polygon data in the road coordinate DB 30 in association with each other according to the determination result.
  • the road coordinate conversion device 50A realizes polygon generation by generating polygons for each lane using white lines such as shoulder lines and lane markings, and then filtering by spatial index.
  • 22 to 27 are views for explaining the processing flow of the road coordinate conversion device 50A shown in FIG. 21.
  • FIG. 22 is a two-dimensional display of each road shoulder line and each lane marking line based on the longitude / latitude data of the road shoulder line and the longitude / latitude data of the lane marking line of the road map data 40 used in the processing.
  • the polygon generation unit 52 for each lane connects the end points of the two road shoulder lines (see (1) in FIG. 23). Generates one shoulder line. Then, the lane-specific polygon generation unit 52 assigns a label to the generated road shoulder line (see (2) in FIG. 23). For example, the lane-specific polygon generation unit 52 assigns the label “r1” to the road shoulder line “1” which is formed by connecting the end points at three places.
  • the lane-specific polygon generation unit 52 joins the end points of the two division lines and assigns a label to the division line.
  • L is set to, for example, 3 m (mean width of lanes).
  • the polygon generation unit 52 for each lane is combined and labeled if the distance between the end points of the lane information is 0.
  • start point-> start point and "end point-> end point” are not combined.
  • end points are lined up in the traveling direction of the vehicle.
  • start point-> start point and "end point-> end point” are not combined.
  • end point-> end point are not combined.
  • the condition for combining is not limited to the distance 0.
  • the polygon generation unit 52 for each lane does not combine any of them.
  • the lane-specific polygon generation unit 52 draws a vertical bisector with respect to the point n constituting each combined lane information and the point n + 1 adjacent to the point n in both directions.
  • the lane-specific polygon generation unit 52 draws a vertical bisector with a length of about 2 m, as illustrated in FIG.
  • the length of the vertical bisector is not limited, and the setting can be changed as appropriate.
  • the lane-specific polygon generation unit 52 stores and labels the intersections A and B with the first division line or road shoulder line where the vertical bisectors intersect, respectively.
  • the lane-specific polygon generation unit 52 does not store the intersection when the first intersection is another lane information.
  • the lane-specific polygon generation unit 52 moves the start point of the vertical bisector by a predetermined distance, and repeats the processes of FIGS. 25 and 26. As a result, points with labels are set for each predetermined distance on the division line.
  • the lane-specific polygon generation unit 52 combines the points with the same label and the same label + 1 to generate a lane-specific polygon. For example, as illustrated in FIG. 27, the lane-specific polygon generation unit 52 connects the intersections A to create the side a (see (1) in FIG. 27), and connects the intersections B to each other to create the side b. (See (2) in FIG. 27), and the end points of the sides a and b are connected to each other to create a polygon for each lane (see (3) in FIG. 27).
  • the lane-specific polygon generation unit 52 generates a plurality of lane-specific polygons from the longitude-latitude data of the lane information of the road map data, the longitude-latitude data of the shoulder line, and the lane marking.
  • FIG. 28 is a flowchart showing a processing procedure of the road coordinate conversion process according to the present embodiment.
  • the road coordinate conversion device 50A accepts the input of the road map data 40 and performs a process of generating polygons for each lane.
  • the lane-specific polygon generation unit 52 refers to the road map data 40, and when the distance between the end points of two adjacent road shoulder lines and the distance between the end points of two adjacent division lines is L or less. Performs a process of joining the end points of the two lane markings or the end points of the two lane markings and assigning a label to the shoulder line or the lane marking line (step S11).
  • the lane-specific polygon generation unit 52 joins and assigns a label if the distance between the end points of the lane information is 0 (step S12). Then, the lane-specific polygon generation unit 52 draws a perpendicular bisector with respect to a point n constituting each combined lane information and a point n + 1 adjacent to the point n in both directions. (Step S13).
  • the lane-specific polygon generation unit 52 stores the intersections A and B with the first lane marking or road shoulder line where the vertical bisectors intersect, and assigns a label (step S14). Then, the lane-specific polygon generation unit 52 combines the points to which the same label and the same label + 1 are given to generate a lane-specific polygon (step S15).
  • the polygon generation unit 53 for each mesh determines the size of the mesh delimiter according to the input accuracy (step S16).
  • the mesh-specific polygon generation unit 53 generates mesh-specific polygons for expressing all geohashes according to the determined mesh division (step S17).
  • the mesh-specific polygon generation unit 53 stores lane-specific polygons that have an “Intersect” relationship with each mesh-specific polygon (step S18).
  • the storage unit 54 stores each spatial index and lane-specific polygons corresponding to each spatial index in the road coordinate DB 30 (step S19), and the road coordinate conversion device 50A ends the road coordinate conversion process.
  • the road coordinate conversion device 50A enables high-speed search. Further, the road coordinate conversion device 50A refers to the road map data including the longitude / latitude data of the lane information indicating the center line of the lane, the longitude / latitude data of the shoulder line, and the longitude / latitude data of the lane marking, and the vertical line from the lane information. Generate lane-specific polygons indicating the area of lanes based on the intersections of intersecting lane markings or shoulder lines. Therefore, it is possible to generate polygons for each polygon lane in which road width information is accurately defined.
  • 29 and 30 are diagrams showing an example of lane-specific polygons that can be generated by the road coordinate conversion device 50A.
  • the road coordinate conversion device 50A does not generate lane-specific polygons because there is no lane information in the road shoulder or zebra zone, and the road coordinate conversion device 50A does not generate polygons for each lane. Only generate polygons by lane.
  • the road coordinate conversion device 50A can generate lane-specific polygons for lanes without being affected by the interrupted lane markings even when the lane markings are interrupted.
  • the road coordinate conversion device 50A is a combination target for three or more lane information
  • none of them is a combination target. Therefore, even if the number of lanes changes, "lanes". It is possible to generate polygons for each lane of "increased lanes", “main lanes after increasing lanes”, and “increased lanes”. That is, if three or more lane information are to be combined, polygons for each lane of "main lane” and "increased lane” are generated as illustrated in (1) of FIG. 30, or FIG. 30 As illustrated in (2), either "main lane before lane increase + increased lane” or "main lane after lane increase” polygons for each lane are generated.
  • the ideal processing result is (1) in FIG.
  • the road coordinate conversion device 50A does not combine none of them. Therefore, as illustrated in FIG. 30 (3), the number of lanes Even when is changed, it is possible to generate polygons for each lane of "main lane with increased lanes", “main lane after increased lanes”, and "increased lanes".
  • the road coordinate conversion device 50A generates mesh-specific polygons expressing the spatial index, associates the mesh-specific polygon data with the lane-specific polygon data corresponding to the mesh-specific polygons, and converts the mesh-specific polygons into the road coordinate DB 30.
  • the road coordinate DB 30 can output the road coordinate search result D1 including the lane-specific polygons that accurately represent the lane area to the spatiotemporal analysis application 10.
  • the road coordinate conversion device 50A combines the end points of the two road shoulder lines when the distance between the end points of the two adjacent road shoulder lines is L or less, and the distance between the end points of the two adjacent road shoulder lines is If it is L or less, the end points of the two marking lines are joined.
  • the road coordinate conversion device 50 can appropriately set the non-road area and the lane marking by combining the shoulder line and the lane marking that are interrupted in the road map data 40 and correcting the shoulder line or the lane marking line. The polygon generation accuracy can be improved.
  • Each component of the road coordinate conversion devices 50 and 50A is a functional concept and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of the distribution and integration of the functions of the road coordinate conversion device 50 is not limited to the one shown in the figure, and all or a part thereof may be functionally or physically in an arbitrary unit according to various loads and usage conditions. It can be configured in a distributed or integrated manner.
  • each process performed by the road coordinate conversion devices 50 and 50A may be realized by a CPU and a program in which an arbitrary part is analyzed and executed by the CPU. Further, each process performed by the road coordinate conversion devices 50 and 50A may be realized as hardware by wired logic.
  • FIG. 31 is a diagram showing an example of a computer in which the road coordinate conversion devices 50 and 50A are realized by executing the program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.
  • Memory 1010 includes ROM 1011 and RAM 1012.
  • the ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120.
  • the video adapter 1060 is connected to, for example, the display 1130.
  • the hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process of the road coordinate conversion devices 50 and 50A is implemented as a program module 1093 in which a code that can be executed by the computer 1000 is described.
  • the program module 1093 is stored in, for example, the hard disk drive 1090.
  • the program module 1093 for executing the same processing as the functional configuration in the road coordinate conversion devices 50 and 50A is stored in the hard disk drive 1090.
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, a memory 1010 or a hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 into the RAM 1012 as needed, and executes the program.
  • the program module 1093 and the program data 1094 are not limited to those stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from another computer via the network interface 1070.
  • LAN Local Area Network
  • WAN Wide Area Network
  • Communication system 10 Spatio-temporal analysis application 20, 20A Road coordinate management system 30 Road coordinate database (DB) 40 Road map data 50, 50A Road coordinate conversion device 51 Reception unit 52 Polygon generation unit for each lane 53 Polygon generation unit for each mesh 54 Storage unit 60 Space-time DB 70 PIP processing module

Abstract

道路座標変換装置（５０）は、道路地図データの入力を受け付ける受付部（５１）と、道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成するレーン別ポリゴン生成部（５２）と、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成するメッシュ別ポリゴン生成部（５３）と、第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、第１のポリゴンのデータと第２のポリゴンのデータとを対応付けて、道路座標ＤＢ（３０）に格納する格納部（５４）と、を有する。

Description

管理装置、管理方法及び管理プログラム
　本発明は、管理装置、管理方法及び管理プログラムに関する。
　従来、特定の座標が特定のポリゴンの内部に含まれるかを判定する内外判定技術が、地理上の車両等の座標が、道路領域を表現したポリゴンに含まれるかを判定する場合に適用されている。
　従来、道路の中央線を中央とし、この中央線から所定の幅を持たせたポリゴンを、道路領域を表現するポリゴンとして生成する方法が提案されている。このように生成されたポリゴンを管理する方法として、全てのポリゴンを同じテーブルに格納する方式がある。
"Mysql　spatial　and　postgis-implementations　of　spatial　data　standards"，［令和２年２月２０日検索］，インターネット＜ＵＲＬ：https://www.researchgate.net/profile/Adam_Piorkowski/publication/267627231_Mysql_spatial_and_postgis-implementations_of_spatial_data_standards/links/54547f7c0cf2bccc490b344d.pdf＞ "Introduction　to　PostGIS"，［令和２年２月２０日検索］，インターネット＜ＵＲＬ：http://postgis.net/workshops/postgis-intro/geometries.html＞
　上述した従来の技術では、全てのポリゴンを同じテーブルに格納するので、全てのポリゴンの中から、該当領域に存在するポリゴンかどうか判定するため、検索に時間がかかるという課題があった。
　本発明は、上記に鑑みてなされたものであって、高速な検索を可能とするポリゴンのデータ管理を行う管理装置、管理方法及び管理プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の管理装置は、道路地図データの入力を受け付ける受付部と、前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成する第１の生成部と、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成する第２の生成部と、前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納する格納部と、を有することを特徴とする。
　また、本発明の管理方法は、管理装置が実行する管理方法であって、道路地図データの入力を受け付ける工程と、前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成する工程と、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成する工程と、前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納する工程と、を含んだことを特徴とする。
　また、本発明の管理プログラムは、道路地図データの入力を受け付けるステップと、前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成するステップと、
　所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成するステップと、前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納するステップと、をコンピュータに実行させる。
　本発明によれば、高速な検索を可能とするポリゴンのデータ管理を行うことができる。
図１は、第１の実施の形態に係る通信システムの構成の一例を示すブロック図である。 図２は、第１の実施の形態に係る道路座標管理システムの構成の一例を説明する図である。 図３は、図２に示す道路座標変換装置の各構成要素の処理の概略を説明する図である。 図４は、非道路領域の定義を説明する図である。 図５は、道路の定義を説明する図である。 図６は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図７は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図８は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図９は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１０は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１１は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１２は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１３は、メッシュ情報の一例を示す図である。 図１４は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１５は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１６は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１７は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１８は、図２に示す道路座標変換装置の処理の流れを説明する図である。 図１９は、第１の実施の形態に係る道路座標変換処理の処理手順を示すフローチャートである。 図２０は、道路座標変換装置が生成可能なレーン別ポリゴンの一例を示す図である。 図２１は、第２の実施の形態に係る道路座標管理システムの構成の一例を説明する図である。 図２２は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２３は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２４は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２５は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２６は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２７は、図２１に示す道路座標変換装置の処理の流れを説明する図である。 図２８は、第２の実施の形態に係る道路座標変換処理の処理手順を示すフローチャートである。 図２９は、道路座標変換装置が生成可能なレーン別ポリゴンの一例を示す図である。 図３０は、道路座標変換装置が生成可能なレーン別ポリゴンの一例を示す図である。 図３１は、プログラムが実行されることにより、道路座標変換装置が実現されるコンピュータの一例を示す図である。
　以下に、本願に係る管理装置、管理方法及び管理プログラムの実施の形態を図面に基づいて詳細に説明する。また、本発明は、以下に説明する実施の形態により限定されるものではない。
［第１の実施の形態］
　まず、第１の実施の形態について説明する。本実施の形態に係る管理装置は、道路地図データを参照し、レーンの領域を示すレーン別ポリゴン（第１のポリゴン）を生成し、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する空間インデックスを表現するためのメッシュ別ポリゴン（第２のポリゴン）を生成し、レーン別ポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、第１のポリゴンのデータとメッシュ別ポリゴンのデータとを対応付けて、道路座標データベースに格納する。
［通信システムの構成］
　図１は、第１の実施の形態に係る通信システムの構成の一例を示図である。例えば、図１に示すように、第１の実施の形態における通信システム１００は、端末装置（不図示）に搭載された、レーン渋滞検知、ＧｅｏＦｅｎｃｉｎｇ等の時空間分析アプリケーション１０に、どの道路の各レーンにおける車両の位置を判定したＰＩＰ処理結果Ｄ３を提供する。
　通信システム１００では、時空間分析アプリケーション１０による空間インデックス検索に応じて、道路座標管理システム２０内の道路座標データベース（ＤＢ）３０（ＯＳＳ：Open　Source　Software）が、レーン領域を表現するレーン別ポリゴンを含む道路座標検索結果Ｄ１を出力する。車両データに関する情報を蓄積する時空間ＤＢ６０が、時空間分析アプリケーション１０に、車両の座標を含む車両検索結果Ｄ２を出力する。
　そして、時空間分析アプリケーション１０から道路座標検索結果Ｄ１及び車両検索結果Ｄ２を受信すると、ＰＩＰ処理モジュール７０が、道路のどのレーンに車両が位置するかを判定するＰＩＰ処理を行い、ＰＩＰ処理結果Ｄ３を出力する。時空間分析アプリケーション１０は、このＰＩＰ処理結果Ｄ３を基にレーン渋滞検知、ＧｅｏＦｅｎｃｉｎｇ等を実行する。
［道路座標管理システム］
　次に、道路座標管理システム２０について説明する。図２は、図１に示す道路座標管理システム２０の構成の一例を説明する図である。図２に示すように、道路座標管理システム２０は、道路座標変換装置５０と、道路座標ＤＢ３０とを有する。
　道路座標変換装置５０は、路肩線の経度緯度情報及び区画線の経度緯度情報を含む道路地図データ４０を用いて生成したレーンの領域を示すレーン別ポリゴンと、空間インデックスを表現するためのメッシュ別ポリゴン（第２のポリゴン）とを対応付けて、道路座標ＤＢ３０に格納する。レーン別ポリゴンは、レーンの領域を示すポリゴンの各頂点の座標を示すデータである。メッシュ別ポリゴンは、所定精度にしたがって区切られたポリゴン形状の空間インデックスの各頂点の座標を示すデータである。
　道路座標ＤＢ３０は、メッシュ別ポリゴンとレーン別ポリゴンとを対応付けて記憶する。道路座標ＤＢ３０は、空間インデックス検索機能を有し、空間インデックスを検索キーとして、レーン別ポリゴンを検索し、道路座標検索結果Ｄ１として出力する。
［道路地図データ］
　続いて、道路地図データ４０について説明する。道路地図データ４０は、道路ＩＤ、レーンＩＤ、車線数、道路中央の緯度及び経度、レーン中央の緯度及び経度、区画線（道路端白線及び点線）の緯度及び経度のデータを含む各データが格納される。
　道路地図データ４０では、車線情報、車道情報、区画線、路肩線、交差点領域、道路標示等の属性で経度緯度データが格納される。道路座標変換装置５０は、道路地図データ４０が有するデータのうち、車線情報、車道情報、区画線及び路肩線の経度緯度データを用いて、ポリゴンの生成を行う。
［道路座標変換装置］
　次に、図２に戻り、道路座標変換装置５０の構成について説明する。道路座標変換装置５０は、例えば、ＲＯＭ（Read　Only　Memory）、ＲＡＭ（Random　Access　Memory）、ＣＰＵ（Central　Processing　Unit）等を含むコンピュータ等に所定のプログラムが読み込まれて、ＣＰＵが所定のプログラムを実行することで実現される。また、道路座標変換装置５０は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースを有する。例えば、道路座標変換装置５０は、ＮＩＣ（Network　Interface　Card）等を有し、ＬＡＮ（Local　Area　Network）やインターネットなどの電気通信回線を介した他の装置との間の通信を行う。
　図２に示すように、道路座標変換装置５０は、受付部５１、レーン別ポリゴン生成部５２（第１の生成部）、メッシュ別ポリゴン生成部５３（第２の生成部）、及び、格納部５４を有する。図３は、図２に示す道路座標変換装置５０の各構成要素の処理の概略を説明する図である。
　受付部５１は、道路地図データ４０の入力を受け付ける。道路地図データ４０は、例えば、図３に示すように、路肩線、区画線等の緯度経度データ４０－１を含む。例えば、受付部５１は、道路地図データとして、路肩線の経度緯度データ及び区画線の経度緯度データの入力を受け付ける。
　レーン別ポリゴン生成部５２は、道路地図データ４０を参照し、レーンの領域を示すレーン別ポリゴン（例えば、図３の５０－１参照）を生成する。例えば、レーン別ポリゴン生成部５２は、道路地図データを参照し、路肩線で囲まれた領域を非道路領域と設定し、隣接する２つの前記非道路領域と２つの非道路領域の間に位置する区画線のデータとを基に、レーン別ポリゴンを生成する。
　メッシュ別ポリゴン生成部５３は、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現するメッシュ別ポリゴンを生成する。
　格納部５４は、レーン別ポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、レーン別ポリゴンのデータとメッシュ別ポリゴンのデータとを対応付けて、道路座標ＤＢ３０に格納する。具体的には、格納部５４は、メッシュ別ポリゴンのデータ（空間インデックス）と、該メッシュ別ポリゴンと対応するレーン別ポリゴンのデータとを対応付けたデータ（例えば、図３の３０－３参照）を、道路座標ＤＢ３０に格納する。例えば、格納部５４は、各空間メッシュについて、各空間メッシュに含まれるレーン別ポリゴンをそれぞれ検索し、検索されたレーン別ポリゴンと該レーン別ポリゴンを含む空間メッシュに対応するメッシュ別ポリゴンとを対応付けて、道路座標ＤＢ３０に格納する。
　このように、道路座標変換装置５０は、路肩線や区画線等の白線を用いて、レーン別ポリゴン生成した後に、空間インデックスによるフィルタリングを行うことで、ポリゴン生成を実現する。
　そして、道路座標変換装置５０は、空間メッシュ（geohash）で区切られた範囲ごとに道路ポリゴンを格納することで、ポリゴンを管理する。つまり、道路座標変換装置５０では、空間メッシュで区切られたメッシュ内に存在するポリゴンかどうかを判定し、そのあとに道路座標ＤＢ３０に空間メッシュと紐づけて格納する。これにより、道路座標変換装置５０は、あらかじめ検索対象となる空間メッシュを計算で求めることにより、多くの判定を省略した高速な検索が可能になる。
　そして、本実施の形態では、以下のように「道路」を定義し、レーン別ポリゴン生成部５２は定義にしたがって道路及びレーンの判定を行う。図４は、非道路領域の定義を説明する図である。図５は、道路の定義を説明する図である。
　まず、路肩線で囲まれた領域は、「道路」ではない、すなわち、「非道路領域」（例えば、図４のＲａ参照）である。そして、路肩線と該路肩線と隣り合う路肩線との間の距離が３ｍ以上の場合、路肩線と該路肩線と隣り合う路肩線との間は「道路」である。具体的には、路肩線Ａと路肩線Ｂとの間が３ｍ以上であれば、路肩線Ａと路肩線Ｂとの間は「道路」である（図５の（１）参照）。また、区画線と該区画線と隣り合う区画線との間の距離が３ｍ以上の場合、区画線と隣り合う区画線との間は「レーン」である。具体的には、区画線Ａと区画線Ｂとの間が３ｍ以上であれば、区画線Ａと区画線Ｂとの間は「レーン」である（図５の（２）参照）。
　道路座標変換装置５０は、レーン別ポリゴン生成のため、路肩線で囲まれた領域を非道路領域（例えば、図４のＲａ参照）と設定する。そして、道路座標変換装置５０は、隣り合う２つの非道路領域と２つの非道路領域の間に位置する区画線のデータとを基に、レーン別ポリゴンを生成する。
［道路座標変換装置の処理の流れ］
　そこで、道路座標変換装置５０の処理の流れを具体的に説明する。図６～図１８は、図２に示す道路座標変換装置５０の処理の流れを説明する図である。
　まず、図６～図１２を参照して、レーン別ポリゴンの生成について説明する。図６は、処理において用いる道路地図データ４０の路肩線の経度緯度データと区画線の経度緯度データとを基に、各路肩線及び各区画線を２次元表示した図である。
　図６に示すように、道路地図データ４０では、路肩線及び区画線が途中で切れていることが多い。このため、レーン別ポリゴン生成部５２は、隣接する２つの路肩線の端点の間の距離がＬ以下である場合には２つの路肩線の端点を結合する（図７の（１）参照）ことで１本の路肩線を生成する。そして、レーン別ポリゴン生成部５２は、生成した路肩線にラベルを付与する（図７の（２）参照）。例えば、レーン別ポリゴン生成部５２は、端点同士を３か所で結合し１本となった路肩線「１」に、ラベル「ｒ１」を付与する。
　レーン別ポリゴン生成部５２は、隣接する２つの区画線の端点の間の距離がＬ以下である場合には２つの区画線の端点を結合し、区画線にラベルを付与する。Ｌは、例えば、３ｍ（レーンの平均幅）に設定される。なお、上述した、隣接する２つの路肩線の端点の間の距離及び隣接する２つの区画線の端点の間の距離は、道路またはレーンの平均幅に応じて、それぞれ異なる距離が設定されてもよい。
　レーン別ポリゴン生成部５２は、路肩線で囲まれた領域を非道路領域と設定し（図８の（１）参照）、ポリゴン化する。そして、レーン別ポリゴン生成部５２は、ポリゴン化した非道路領域に、それぞれの非道路領域に対して固有のラベルを付与する（図８の（２）参照）。例えば、レーン別ポリゴン生成部５２は、非道路領域「１」に、ラベル「ｈ１」を付与する。
　レーン別ポリゴン生成部５２は、各非道路領域の辺を構成する点ｎと、点ｎに隣り合う点ｎ＋１との間の線に対する垂直二等分線を非道路領域の外方向に引く。点ｎと、点ｎ＋１とは、例えば、非道路領域の辺上に、所定の間隔で設定される。例えば、レーン別ポリゴン生成部５２は、非道路領域ｈ１について、点ｎと点ｎ＋１の間の線に対し、垂直二等分線ｖ１を非道路領域ｈ１の外方向に引く（図９の（１）参照）。
　レーン別ポリゴン生成部５２は、垂直二等分線が交差した最初の非道路領域Ａ、最初の非道路領域Ａに達するまで垂直二等分線と交差した全ての区画線（路肩線も含む）Ｂを記憶する。具体的には、レーン別ポリゴン生成部５２は、垂直二等分線ｖ１が交差した最初の非道路領域ｈ２をＡとし、最初の非道路領域ｈ２に達するまで交差した全ての区画線Ｂの垂直二等分線ｖ１上の点ｃ１～ｃ５を記憶する（図１０参照）。なお、点ｃ６は、垂直二等分線ｖ１と非道路領域ｈ２の辺との交差点である。
　レーン別ポリゴン生成部５２は、垂直二等分線の開始点と該開始点と隣り合う区画線Ｂの点との間の距離、垂直二等分線ｖ１が交差した最初の非道路領域Ａの交差点と該交差点と隣り合う区画線Ｂの点との間の距離、及び、隣り合う区画線Ｂの各点間の距離を計算する。そして、レーン別ポリゴン生成部５２は、計算した距離がＬ（例えば、レーンの平均幅である３ｍ）以上であれば記憶し、点にラベルを付与する。ラベルの前半部は、垂直二等分線の開始点となる非道路領域と垂直二等分線が交差した最初の非道路領域Ａとを示し、ラベルの後半部は、垂直二等分線の交差順序「ｎ（１≦ｎ≦Ｎ（最大値）」を示す。
　まず、図１１に示すように、レーン別ポリゴン生成部５２は、垂直二等分線ｖ１の開始点ｃ０と、隣り合う区画線Ｂの点ｃ１との間の距離を計算する。この場合、計算した距離はＬ未満であるため、レーン別ポリゴン生成部５２は、ラベルの付与は行わない。続いて、レーン別ポリゴン生成部５２は、垂直二等分線ｖ１が１番目に交差した点ｃ１と、２番目に交差した点ｃ２との間の距離を計算する。この場合、計算した距離はＬ以上であるため、レーン別ポリゴン生成部５２は、点ｃ１にラベル「ｈ１→ｈ２，１番目」を付与し、点ｃ２にラベル「ｈ１→ｈ２，２番目」を付与する。同様の処理を行うことで、レーン別ポリゴン生成部５２は、点ｃ３～点ｃ５に、それぞれ、ラベル「ｈ１→ｈ２，３番目」、ラベル「ｈ１→ｈ２，４番目」、ラベル「ｈ１→ｈ２，５番目」を付与する。
　そして、レーン別ポリゴン生成部５２は、非道路領域ｈ１における垂直二等分線の開始点を所定距離ずつ移動させ、図９～図１１の処理を繰り返し行う。この結果、区画線上には、それぞれラベルが付された点が、所定距離ごとに設定される。
　続いて、レーン別ポリゴン生成部５２は、各点のラベルを参照し、同一の前半部を有するラベルが付与された点のうち、ラベルの後半部の交差順序が「ｎ」及び「ｎ＋１」を付与された点を右回りに結合し、レーン別ポリゴンを生成する。
　図１２に示すように、レーン別ポリゴン生成部５２は、「ｈ１→ｈ２」がラベルの前半部に付与された非道路領域ｈ１と非道路領域ｈ２との間の区画線の各点のうち、ラベルの後半部が「１番目」である各点と、ラベルの後半部が「２番目」である各点とを、右回りに結合する。これによって、レーン別ポリゴン生成部５２は、レーン別ポリゴン１を生成する。また、レーン別ポリゴン生成部５２は、「ｈ１→ｈ２」がラベルの前半部に付与された区画線の各点のうち、ラベルの後半部が「２番目」である各点と「３番目」である各点とを右回りに結合することで、レーン別ポリゴン２を生成する。
　このように、レーン別ポリゴン生成部５２は、道路地図データの路肩線、区画線の経度緯度データから、複数のレーン別ポリゴンを生成する。
　続いて、図１３～図１６を参照して、メッシュ別ポリゴン生成部５３によるメッシュ別ポリゴンの生成について説明する。メッシュ別ポリゴン生成部５３は、空間インデックス（geohash）の精度（桁数）が入力され、事前に用意した外部ファイルからポリゴン検索範囲となる経度と緯度の値を含むメッシュ情報を取り込むと、入力された精度に応じて、メッシュ区切りのサイズを決定し、検索する全範囲のメッシュと等価な空間インデックスを生成する。メッシュ情報は、どのようなデータ形式であってもよいが、例えば、図１３に例示するように、経度（１０進数表記）緯度値（１０進数表記）で表現されるものとする。
　また、例えば、図１４の（ａ）に示すように、緯度が１５桁、経度が１４桁の精度が入力された場合、メッシュ別ポリゴン生成部５３は、１．２５ｋｍ×１．２５ｋｍのサイズのメッシュ区切りを決定する。また、図１４の（ｂ）に示すように、緯度が１８桁、経度が１７桁の精度が入力された場合、メッシュ別ポリゴン生成部５３は、１５０ｍ×１５０ｍのサイズのメッシュ区切りを決定する。
　そして、メッシュ別ポリゴン生成部５３は、決定したメッシュ区切りにしたがって、全てのgeohashを表現するためのメッシュ別ポリゴンを生成する。具体的には、図１５に示すように、緯度が１５桁、経度が１４桁の精度の場合、メッシュ別ポリゴン生成部５３は、１．２５ｋｍ×１．２５ｋｍのサイズのポリゴンを決定する。複数のポリゴンのうち、例えば、ポリゴン１０は、ポリゴンの各頂点の座標（ｘ１，ｙ１），（ｘ２，ｙ１），（ｘ２，ｙ２），（ｘ１，ｙ２）によって設定される。
　そして、メッシュ別ポリゴン生成部５３は、各メッシュ別ポリゴンと“Intersect”の関係にあるレーン別ポリゴンを記憶する。Intersectとして、ＪＩＳ等のIntersect関数を想定する。図１６に示すように、メッシュ別ポリゴン生成部５３は、レーン３～１０のレーン別ポリゴンを記憶する。
　例えば、メッシュ別ポリゴン生成部５３は、メッシュ単位で、メッシュに含まれるレーン別ポリゴンを検索し、検索にヒットしたレーン別ポリゴンに、空間インデックスを付与する。また、メッシュ別ポリゴン生成部５３は、検索にヒットしたレーン別ポリゴンに、メッシュ内で重複しない通番の値をレーンＩＤとして付与するようにしてもよい。例えば、メッシュ別ポリゴン生成部５３は、図１７に例示するように、メッシュ１からメッシュ９まで順に、メッシュに含まれるレーン別ポリゴンを検索し、検索にヒットしたレーン別ポリゴンに、空間インデックスを付与する。図１７の例では、メッシュ別ポリゴン生成部５３は、例えば、メッシュ５に含まれるレーン１、２、３が検索で抽出されるので、レーン１、２、３に空間インデックスを付与する。
　格納部５４は、道路座標ＤＢ３０に、各空間インデックスと、各空間インデックスに対応するレーン別ポリゴンを格納する。例えば、図１８に示すように、格納部５４は、ポリゴン１０に関しては、ポリゴン１０の空間インデックスと、ポリゴン１０にIntersectの関係にあるレーン３～１０のレーン別ポリゴンとを対応付けたデータ３０－３を、道路座標ＤＢ３０に格納する。
［道路座標変換処理の処理手順］
　図１９は、本実施の形態に係る道路座標変換処理の処理手順を示すフローチャートである。
　図１９に示すように、道路座標変換装置５０は、道路地図データ４０の入力を受け付け、レーン別ポリゴンを生成する処理を行う。まず、レーン別ポリゴン生成部５２は、道路地図データ４０を参照し、隣接する２つの路肩線の端点の間の距離、隣接する２つの区画線の端点の間の距離がＬ以下である場合には、２つの区画線の端点、または、２つの区画線の端点を結合し、路肩線または区画線にラベルを付与する処理を行う（ステップＳ１）。
　レーン別ポリゴン生成部５２は、路肩線で囲まれた領域を非道路領域とし、ポリゴン化後、ポリゴン化した非道路領域にラベルを付与する処理を行う（ステップＳ２）。レーン別ポリゴン生成部５２は、各非道路領域の辺を構成する点ｎと点ｎ＋１との間の線に対する垂直二等分線を非道路領域の外方向に引く（ステップＳ３）。
　レーン別ポリゴン生成部５２は、垂直二等分線が交差した最初の非道路領域Ａ、最初の非道路領域Ａに達するまで垂直二等分線と交差した全ての区画線Ｂを記憶する（ステップＳ４）。レーン別ポリゴン生成部５２は、垂直二等分線の開始点と該開始点と隣り合う区画線Ｂの点との間の距離、垂直二等分線が交差した最初の非道路領域Ａの交差点と該交差点と隣り合う区画線Ｂの点との間の距離、及び、隣り合う区画線Ｂの各点間の距離を計算し、計算した距離がＬ以上であれば記憶し、点にラベルを付与する（ステップＳ５）。レーン別ポリゴン生成部５２は、非道路領域ｈ１における垂直二等分線の開始点を所定距離ずつ移動させ、ステップＳ３～ステップＳ５の処理を繰り返し行う。
　そして、レーン別ポリゴン生成部５２は、各点のラベルを参照し、同一の前半部を有するラベルが付与された点のうち、ラベルの後半部の交差順序が「ｎ」及び「ｎ＋１」を付与された点を右回りに結合し、レーン別ポリゴンを生成する（ステップＳ６）。
　続いて、空間インデックス（geohash）の精度（桁数）が入力されると、メッシュ別ポリゴン生成部５３は、入力された精度に応じて、メッシュ区切りのサイズを決定する（ステップＳ７）。メッシュ別ポリゴン生成部５３は、決定したメッシュ区切りにしたがって、全てのgeohashを表現するためのメッシュ別ポリゴンを生成する（ステップＳ８）。メッシュ別ポリゴン生成部５３は、各メッシュ別ポリゴンと“Intersect”の関係にあるレーン別ポリゴンを記憶する（ステップＳ９）。
　そして、格納部５４は、道路座標ＤＢ３０に、各空間インデックスと、各空間インデックスに対応するレーン別ポリゴンを格納し（ステップＳ１０）、道路座標変換装置５０は、道路座標変換処理を終了する。
［第１の実施の形態の効果］
　このように、第１の実施の形態に係る道路座標変換装置５０では、道路地図データの入力を受け付け、道路地図データを参照し、レーンの領域を示すレーン別ポリゴンを生成する。そして、道路座標変換装置５０では、所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現するメッシュ別ポリゴンを生成し、レーン別ポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、レーン別ポリゴンのデータとメッシュ別ポリゴンのデータとを対応付けて、道路座標ＤＢ３０に格納する。
　道路座標変換装置５０は、空間メッシュ（geohash）で区切られた範囲ごとに道路ポリゴンを格納することで、ポリゴンを管理する。つまり、道路座標変換装置５０では、空間メッシュで区切られたメッシュ内に存在するポリゴンかどうかを判定し、そのあとに道路座標ＤＢ３０に空間メッシュと紐づけて格納する。これにより、道路座標変換装置５０は、例えば、検索処理時において、あらかじめ検索対象となる空間メッシュを計算で求めることにより、多くの判定を省略した高速な検索が可能になる。
　また、第１の実施の形態に係る道路座標変換装置５０では、路肩線の経度緯度データ及び区画線の経度緯度データを含む道路地図データを参照し、路肩線で囲まれた領域を非道路領域と設定し、隣接する２つの非道路領域と２つの非道路領域の間に位置する区画線のデータとを基に、レーンの領域を示すレーン別ポリゴンを生成する。
　本実施の形態では、車載されたＬＩＤＡＲ等のセンサデバイスによって検出可能な白線の路肩線や区画線を用いるため、レーンの中央線を用いる従来の方法よりも、レーンの領域を示すレーン別ポリゴンを正確に生成することができる。
　図２０は、道路座標変換装置５０が生成可能なレーン別ポリゴンの一例を示す図である。図２０に示すように、路肩線で囲まれた領域を非道路領域として設定し、この非道路領域を基にレーン別ポリゴンを生成することによって、丸で囲まれた、非道路領域間の部分のレーン別ポリゴンを正確に生成することができる。この結果、通信システム１００では、道路座標変換装置５０によって正確に生成されたレーン別ポリゴンを用いることによって、レーン渋滞検知等の精度の向上を図ることができる。
　また、道路座標変換装置５０は、空間インデックスを表現するメッシュ別ポリゴンを生成し、メッシュ別ポリゴンのデータと、該メッシュ別ポリゴンと対応するレーン別ポリゴンのデータとを対応付けて、道路座標ＤＢ３０に格納する。このため、道路座標ＤＢ３０は、時空間分析アプリケーション１０に、レーン領域を正確に表現するレーン別ポリゴンを含む道路座標検索結果Ｄ１を出力することができる。
　そして、道路座標変換装置５０は、隣接する２つの路肩線の間の距離が所定の距離以上である場合には２つの路肩線の間は道路であると判定し、２つの区画線の間の距離が所定の距離以上である場合離れている場合には２つの区画線の間はレーンであると判定する。このように、道路座標変換装置５０は、道路及びレーンを適切に判定するため、レーン別ポリゴンを適切に生成することができる。
　道路座標変換装置５０は、隣接する２つの路肩線の端点の間の距離がＬ以下である場合には２つの路肩線の端点を結合し、隣接する２つの区画線の端点の間の距離がＬ以下である場合には２つの区画線の端点を結合する。道路座標変換装置５０は、道路地図データ４０において途切れている路肩線及び区画線を結合して、路肩線または区画線を修正することで、非道路領域及び区画線を適切に設定でき、レーン別ポリゴンの生成精度を上げることができる。
［第２の実施の形態］
　次に、第２の実施の形態について説明する。第１の実施の形態では、道路地図データを参照し、路肩線で囲まれた領域を非道路領域と設定し、隣接する２つの非道路領域と２つの非道路領域の間に位置する区画線のデータとを基に、レーン別ポリゴンを生成する場合を説明したが、これに限定されるものではない。例えば、道路地図データを参照し、車線情報からの垂線と交差する区画線または路肩線の交点を基に、レーン別ポリゴンを生成するようにしてもよい。
　そこで、以下の第２の実施の形態では、レーン別ポリゴン生成部５２が、道路地図データを参照し、車線情報からの垂線と交差する区画線または路肩線の交点を基に、レーンの領域を示す第１のポリゴンを生成する場合について説明する。なお、第１の実施の形態と同様の構成・処理については適宜説明を省略する。
［道路座標管理システム］
　第２の実施の形態に係る道路座標管理システム２０Ａについて説明する。図２１は、第２の実施の形態に係る道路座標管理システム２０Ａの構成の一例を説明する図である。図２１に示すように、道路座標管理システム２０Ａは、道路座標変換装置５０Ａと、道路座標ＤＢ３０とを有する。
［道路座標変換装置］
　第２の実施の形態に係る道路座標変換装置５０Ａの構成について説明する。道路座標変換装置５０Ａは、受付部５１、レーン別ポリゴン生成部５２（第１の生成部）、メッシュ別ポリゴン生成部５３（第２の生成部）、及び、格納部５４を有する。
　受付部５１は、車線の中心線を示す車線情報の経度緯度データ、路肩線の経度緯度データ及び区画線の経度緯度データを含む道路地図データ４０の入力を受け付ける。道路地図データ４０は、例えば、図３に示すように、路肩線、区画線等の緯度経度データ４０－１を含む。
　レーン別ポリゴン生成部５２は、道路地図データ４０を参照し、車線情報からの垂線と交差する前記区画線または路肩線の交点を基に、レーンの領域を示すレーン別ポリゴン（例えば、図３の５０－１参照）を生成する。具体的には、レーン別ポリゴン生成部５２は、車線情報からの垂線と交差する区画線または路肩線の交点同士を結合してレーン別ポリゴンを生成する。
　メッシュ別ポリゴン生成部５３は、空間インデックスを表現するメッシュ別ポリゴンを生成する。
　格納部５４は、レーン別ポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、レーン別ポリゴンのデータとメッシュ別ポリゴンのデータとを対応付けて、道路座標ＤＢ３０に格納する。
　このように、道路座標変換装置５０Ａは、路肩線や区画線等の白線を用いて、レーン別ポリゴン生成した後に、空間インデックスによるフィルタリングを行うことで、ポリゴン生成を実現する。
［道路座標変換装置の処理の流れ］
　そこで、道路座標変換装置５０Ａの処理の流れを具体的に説明する。図２２～図２７は、図２１に示す道路座標変換装置５０Ａの処理の流れを説明する図である。
　まず、図２２～図２７を参照して、レーン別ポリゴンの生成について説明する。図２２は、処理において用いる道路地図データ４０の路肩線の経度緯度データと区画線の経度緯度データとを基に、各路肩線及び各区画線を２次元表示した図である。
　図２２に示すように、道路地図データ４０では、路肩線及び区画線が途中で切れていることが多い。このため、レーン別ポリゴン生成部５２は、隣接する２つの路肩線の端点の間の距離がＬ以下である場合には２つの路肩線の端点を結合する（図２３の（１）参照）ことで１本の路肩線を生成する。そして、レーン別ポリゴン生成部５２は、生成した路肩線にラベルを付与する（図２３の（２）参照）。例えば、レーン別ポリゴン生成部５２は、端点同士を３か所で結合し１本となった路肩線「１」に、ラベル「ｒ１」を付与する。
　レーン別ポリゴン生成部５２は、隣接する２つの区画線の端点の間の距離がＬ以下である場合には２つの区画線の端点を結合し、区画線にラベルを付与する。Ｌは、例えば、３ｍ（レーンの平均幅）に設定される。
　また、レーン別ポリゴン生成部５２は、図２４に例示するように、車線情報の端点の距離が０であれば結合し、ラベルを付与する。ここで車線情報は、車両の進行方向に向かって端点が並んでいるため、「始点→始点」、「終点→終点」の結合は行わない。また、例えば、距離０のもののみを結合するものとする。なお、結合するための条件として、距離０に限定されるものではない。また、レーン別ポリゴン生成部５２は、結合可能な車線情報が複数存在する場合には、どれも結合しないものとする。
　そして、レーン別ポリゴン生成部５２は、各結合済み車線情報を構成する点ｎと、点ｎに隣り合う点ｎ＋１との間に対する垂直二等分線を両方向に引く。例えば、レーン別ポリゴン生成部５２は、図２５に例示するように、長さ２ｍ程度の垂直二等分線を引く。なお、垂直二等分線の長さは限定されるものではなく、適宜設定変更できるものとする。
　続いて、レーン別ポリゴン生成部５２は、図２６に例示するように、垂直二等分線がそれぞれ交差した最初の区画線または路肩線との交点Ａ、Ｂを記憶し、ラベルを付与する。なお、レーン別ポリゴン生成部５２は、最初に交差したのが別の車線情報だった場合には交点を記憶しない。
　そして、レーン別ポリゴン生成部５２は、垂直二等分線の開始点を所定距離ずつ移動させ、図２５、図２６の処理を繰り返し行う。この結果、区画線上には、それぞれラベルが付された点が、所定距離ごとに設定される。
　その後、レーン別ポリゴン生成部５２は、同一ラベル、同一ラベル＋１を付与された点を結合し、レーン別ポリゴンを生成する。例えば、レーン別ポリゴン生成部５２は、図２７に例示するように、交点Ａ同士をつないで辺ａを作成し（図２７の（１）参照）、交点同士Ｂ同士をつないで辺ｂを作成し（図２７の（２）参照）、辺ａと辺ｂの端点同士をつないでレーン別ポリゴンを作成する（図２７の（３）参照）。
　このように、レーン別ポリゴン生成部５２は、道路地図データの車線情報の経度緯度データ、路肩線、区画線の経度緯度データから、複数のレーン別ポリゴンを生成する。
［道路座標変換処理の処理手順］
　図２８は、本実施の形態に係る道路座標変換処理の処理手順を示すフローチャートである。
　図２８に示すように、道路座標変換装置５０Ａは、道路地図データ４０の入力を受け付け、レーン別ポリゴンを生成する処理を行う。まず、レーン別ポリゴン生成部５２は、道路地図データ４０を参照し、隣接する２つの路肩線の端点の間の距離、隣接する２つの区画線の端点の間の距離がＬ以下である場合には、２つの区画線の端点、または、２つの区画線の端点を結合し、路肩線または区画線にラベルを付与する処理を行う（ステップＳ１１）。
　続いて、レーン別ポリゴン生成部５２は、車線情報の端点の距離が０であれば結合し、ラベルを付与する（ステップＳ１２）。そして、レーン別ポリゴン生成部５２は、レーン別ポリゴン生成部５２は、各結合済み車線情報を構成する点ｎと、点ｎに隣り合う点ｎ＋１との間に対する垂直二等分線を両方向に引く（ステップＳ１３）。
　続いて、レーン別ポリゴン生成部５２は、垂直二等分線がそれぞれ交差した最初の区画線または路肩線との交点Ａ、Ｂを記憶し、ラベルを付与する（ステップＳ１４）。そして、レーン別ポリゴン生成部５２は、同一ラベル、同一ラベル＋１を付与された点を結合し、レーン別ポリゴンを生成する（ステップＳ１５）。
　続いて、空間インデックス（geohash）の精度（桁数）が入力されると、メッシュ別ポリゴン生成部５３は、入力された精度に応じて、メッシュ区切りのサイズを決定する（ステップＳ１６）。メッシュ別ポリゴン生成部５３は、決定したメッシュ区切りにしたがって、全てのgeohashを表現するためのメッシュ別ポリゴンを生成する（ステップＳ１７）。メッシュ別ポリゴン生成部５３は、各メッシュ別ポリゴンと“Intersect”の関係にあるレーン別ポリゴンを記憶する（ステップＳ１８）。
　そして、格納部５４は、道路座標ＤＢ３０に、各空間インデックスと、各空間インデックスに対応するレーン別ポリゴンを格納し（ステップＳ１９）、道路座標変換装置５０Ａは、道路座標変換処理を終了する。
［第２の実施の形態の効果］
　第２の実施の形態に係る道路座標変換装置５０Ａでも同様に、高速な検索を可能とする。また、道路座標変換装置５０Ａは、車線の中心線を示す車線情報の経度緯度データ、路肩線の経度緯度データ及び区画線の経度緯度データを含む道路地図データを参照し、車線情報からの垂線と交差する区画線または路肩線の交点を基に、レーンの領域を示すレーン別ポリゴンを生成する。このため、道路の幅情報が正確に定義されたポリゴンレーン別ポリゴンを生成することが可能である。
　図２９および図３０は、道路座標変換装置５０Ａが生成可能なレーン別ポリゴンの一例を示す図である。図２９に示すように、道路座標変換装置５０Ａは、路肩やゼブラゾーンが存在する場合であっても、路肩やゼブラゾーンには車線情報がないためレーン別ポリゴンは生成せず、車線に対してのみレーン別ポリゴンを生成する。また、図２９に示すように、道路座標変換装置５０Ａは、区画線が途切れる場合であっても、途切れた区画線の影響を受けず、車線に対してレーン別ポリゴンを生成することができる。
　また、例えば、道路座標変換装置５０Ａは、３本以上の車線情報が結合対象となる場合には、どれも結合しないを結合対象としないので、車線数が変化する場合であっても、「車線増数の本線」、「車線増後の本線」、「増えた車線」のレーン別ポリゴンを生成することが可能である。つまり、仮に、３本以上の車線情報を結合対象とした場合に、図３０の（１）に例示するように、「本線」と「増えた車線」のレーン別ポリゴンを生成するか、図３０の（２）に例示するように、「車線増前の本線＋増えた車線」と「車線増後の本線」のレーン別ポリゴンを生成するかのどちらかとなる。図３０の（１）となるのが理想的な処理結果であるが、そのための判断材料がない。このため、道路座標変換装置５０Ａは、３本以上の車線情報が結合対象となる場合には、どれも結合しないを結合対象としないので、図３０の（３）に例示するように、車線数が変化する場合であっても、「車線増数の本線」、「車線増後の本線」、「増えた車線」のレーン別ポリゴンを生成することが可能である。
　また、道路座標変換装置５０Ａは、空間インデックスを表現するメッシュ別ポリゴンを生成し、メッシュ別ポリゴンのデータと、該メッシュ別ポリゴンと対応するレーン別ポリゴンのデータとを対応付けて、道路座標ＤＢ３０に格納する。このため、道路座標ＤＢ３０は、時空間分析アプリケーション１０に、レーン領域を正確に表現するレーン別ポリゴンを含む道路座標検索結果Ｄ１を出力することができる。
　道路座標変換装置５０Ａは、隣接する２つの路肩線の端点の間の距離がＬ以下である場合には２つの路肩線の端点を結合し、隣接する２つの区画線の端点の間の距離がＬ以下である場合には２つの区画線の端点を結合する。道路座標変換装置５０は、道路地図データ４０において途切れている路肩線及び区画線を結合して、路肩線または区画線を修正することで、非道路領域及び区画線を適切に設定でき、レーン別ポリゴンの生成精度を上げることができる。
［実施形態のシステム構成について］
　道路座標変換装置５０、５０Ａの各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち道路座標変換装置５０の機能の分散および統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。
　また、道路座標変換装置５０、５０Ａにおいておこなわれる各処理は、全部または任意の一部が、ＣＰＵおよびＣＰＵにより解析実行されるプログラムにて実現されてもよい。また、道路座標変換装置５０、５０Ａにおいておこなわれる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。
　また、実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的に行うこともできる。もしくは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述および図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。
［プログラム］
　図３１は、プログラムが実行されることにより、道路座標変換装置５０、５０Ａ実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating　System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、道路座標変換装置５０、５０Ａの各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、道路座標変換装置５０、５０Ａにおける機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３およびプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３およびプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例および運用技術等はすべて本発明の範疇に含まれる。
　１００　通信システム
　１０　時空間分析アプリケーション
　２０、２０Ａ　道路座標管理システム
　３０　道路座標データベース（ＤＢ）
　４０　道路地図データ
　５０、５０Ａ　道路座標変換装置
　５１　受付部
　５２　レーン別ポリゴン生成部
　５３　メッシュ別ポリゴン生成部
　５４　格納部
　６０　時空間ＤＢ
　７０　ＰＩＰ処理モジュール

Claims (6)

  1. 　道路地図データの入力を受け付ける受付部と、
    　前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成する第１の生成部と、
    　所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成する第２の生成部と、
    　前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納する格納部と、
    　を有することを特徴とする管理装置。
  2. 　前記受付部は、前記道路地図データとして、路肩線の経度緯度データ及び区画線の経度緯度データの入力を受け付け、
    　前記第１の生成部は、前記道路地図データを参照し、前記路肩線で囲まれた領域を非道路領域と設定し、隣接する２つの前記非道路領域と前記２つの非道路領域の間に位置する区画線のデータとを基に、前記第１のポリゴンを生成することを特徴とする請求項１に記載の管理装置。
  3. 　前記受付部は、前記道路地図データとして、車線の中心線を示す車線情報の経度緯度データ、路肩線の経度緯度データ及び区画線の経度緯度データの入力を受け付け、
    　前記第１の生成部は、前記道路地図データを参照し、前記車線情報からの垂線と交差する前記区画線または前記路肩線の交点を基に、前記第１のポリゴンを生成することを特徴とする請求項１に記載の管理装置。
  4. 　前記格納部は、各空間メッシュについて、各空間メッシュに含まれる第１のポリゴンをそれぞれ検索し、検索された第１のポリゴンと該第１のポリゴンを含む空間メッシュに対応する第２のポリゴンとを対応付けて、前記道路座標データベースに格納することを特徴とする請求項１に記載の管理装置。
  5. 　管理装置が実行する管理方法であって、
    　道路地図データの入力を受け付ける工程と、
    　前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成する工程と、
    　所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成する工程と、
    　前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納する工程と、
    　を含んだことを特徴とする管理方法。
  6. 　道路地図データの入力を受け付けるステップと、
    　前記道路地図データを参照し、レーンの領域を示す第１のポリゴンを生成するステップと、
    　所定のサイズで区切られた空間メッシュごとに、空間インデックスを表現する第２のポリゴンを生成するステップと、
    　前記第１のポリゴンがいずれの空間メッシュに存在するか判定し、判定結果に応じて、前記第１のポリゴンのデータと前記第２のポリゴンのデータとを対応付けて、道路座標データベースに格納するステップと、
    　をコンピュータに実行させるための管理プログラム。
PCT/JP2020/009540 2020-03-05 2020-03-05 管理装置、管理方法及び管理プログラム WO2021176677A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022504905A JP7355216B2 (ja) 2020-03-05 2020-03-05 管理装置、管理方法及び管理プログラム
US17/908,534 US20230160719A1 (en) 2020-03-05 2020-03-05 Management device, management method, and management program
PCT/JP2020/009540 WO2021176677A1 (ja) 2020-03-05 2020-03-05 管理装置、管理方法及び管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/009540 WO2021176677A1 (ja) 2020-03-05 2020-03-05 管理装置、管理方法及び管理プログラム

Publications (1)

Publication Number Publication Date
WO2021176677A1 true WO2021176677A1 (ja) 2021-09-10

Family

ID=77613312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/009540 WO2021176677A1 (ja) 2020-03-05 2020-03-05 管理装置、管理方法及び管理プログラム

Country Status (3)

Country Link
US (1) US20230160719A1 (ja)
JP (1) JP7355216B2 (ja)
WO (1) WO2021176677A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009300889A (ja) * 2008-06-16 2009-12-24 Yahoo Japan Corp 地図階層通知方法、地図階層通知プログラム、及び地図階層通知システム
JP2015001575A (ja) * 2013-06-14 2015-01-05 株式会社ジオ技術研究所 地図データ生成システム、地図出力システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009300889A (ja) * 2008-06-16 2009-12-24 Yahoo Japan Corp 地図階層通知方法、地図階層通知プログラム、及び地図階層通知システム
JP2015001575A (ja) * 2013-06-14 2015-01-05 株式会社ジオ技術研究所 地図データ生成システム、地図出力システム

Also Published As

Publication number Publication date
JP7355216B2 (ja) 2023-10-03
US20230160719A1 (en) 2023-05-25
JPWO2021176677A1 (ja) 2021-09-10

Similar Documents

Publication Publication Date Title
KR102160990B1 (ko) 객체 기반의 3d 도시 모델링 방법 및 이를 구현하는 서버, 그리고 이를 이용하는 시스템
CN112784002B (zh) 一种虚拟场景生成方法、装置、设备和存储介质
EP4098975A2 (en) Vehicle travel control method and apparatus
US20170211941A1 (en) Generalising Topographical Map Data
CN112348317A (zh) 一种智慧城市的项目规划条件生成方法和系统
JP2023022185A (ja) 地図データ処理方法及び装置、電子機器、記憶媒体、並びにコンピュータプログラム
WO2021176676A1 (ja) 生成装置、生成方法及び生成プログラム
CN112765127B (zh) 一种交通数据仓库的构建方法、装置、存储介质及终端
Goldin et al. Georouting and delta-gathering: Efficient data propagation techniques for geosensor networks
WO2021176677A1 (ja) 管理装置、管理方法及び管理プログラム
CN103167032B (zh) 地图辅助的室内定位后台服务系统
CN110544159B (zh) 一种地图信息处理方法、装置、可读存储介质和电子设备
WO2021176678A1 (ja) 生成装置、生成方法及び生成プログラム
WO2022142889A1 (zh) 高精度地图更新方法及装置
CN113435403B (zh) 路网缺失道路检测方法、装置、电子设备和存储介质
CN113872798A (zh) 空间网络拓扑图的构建方法、装置、存储介质及电子设备
CN114419883A (zh) 识别路口缺失交通限制信息的方法、装置和电子设备
JP2021009027A (ja) 経路出力装置、方法、及びプログラム
CN113656425B (zh) 电子地图的更新方法、装置、电子设备、存储介质及产品
CN115845381B (zh) 一种基于包围盒的快速寻路方法、装置、设备及介质
CN112885129B (zh) 道路限速的确定方法、装置、设备及计算机可读存储介质
JP2004126757A (ja) データ予測装置、データ予測方法およびデータ予測プログラム
WO2023231459A1 (zh) 一种生成路口面的方法以及相关装置
CN112329119B (zh) 虚拟场景仿真处理方法、装置、电子设备及存储介质
CN115830255B (zh) 一种仿真场景生成方法、装置、电子设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20922651

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022504905

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20922651

Country of ref document: EP

Kind code of ref document: A1