JP2012133132A - Map data generation system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To create data for drawing road signs with a light load.SOLUTION: A road network database and a drawing database (polygon data) are prepared. Further, a road-sign rule database for ruling the shape and location when a road sign is drawn is prepared. The system groups various links and nodes to be processed collectively on the basis of the road network data, sets an intersection area, etc. and then generates a cross-walk and a road white line with reference to the rule of the road-sign rule database. In this generation process, no photograph of a road sign is required. Thus, road sign data can be generated with a light load without a need to conduct a field survey such as photographing, by generating data concerning a road white line, etc. with reference to the road-sign rule database which stores the same rules as those to be used in actually drawing a road sign.

Description

  The present invention generates data for drawing road markings such as a vehicle traffic zone boundary line (hereinafter also referred to as “road white line”) and a pedestrian crossing drawn on a map based on drawing data such as road polygons. Regarding technology.

  In recent years, it is not sufficient to simply represent the topography on a map, and there is a tendency to reproduce a more realistic state. As an example, it may be required to reproduce various road markings drawn on an actual road such as a white road, a pedestrian crossing, and a stop line on a map. If a state close to reality is reproduced in this way, the user of the map can easily target the map and the site, and the convenience of the map can be improved. Such a demand is higher for an electronic map displayed on a display such as a computer or a navigation device than for a map as a printed matter. Further, there is a strong demand for a three-dimensional map in which features and the like are three-dimensionally displayed rather than a two-dimensional map.

As technologies related to road marking, there are technologies described in Patent Documents 1 to 3.
Patent Document 1 discloses a technique for determining whether a road exists on a map by detecting a road white line by image processing from an image taken by a camera mounted on a traveling vehicle and comparing it with a map. To do. Patent Document 2 discloses a technique for detecting a road white line by image processing from an image taken by an in-vehicle camera and utilizing it for vehicle control so that the vehicle travels in a lane. Patent Document 3 discloses a technique for generating image data of a road white line by performing ortho-transform on an image photographed by an in-vehicle camera.
As described above, the conventional technology obtains road white line data from an image taken by an in-vehicle camera. In addition to vehicles, a technique for obtaining road white line data from aerial photographs is also conceivable.

JP 2003-121161 A JP 2003-168198 A JP 2010-175756 A

However, in the prior art, field surveys were indispensable in order to generate road white line data, whether in-vehicle cameras or aerial photographs. Therefore, if an attempt was made to draw a road white line everywhere in the country, the burden of investigation was great. The same applies to other road sign data such as pedestrian crossings and stop lines as well as white road lines.
In consideration of such a problem, an object of the present invention is to enable generation of data for drawing a road sign with a light load.

The present invention relates to a map data generation system for generating map data for drawing a map.
A road network database for storing road network data representing roads by nodes and links;
A drawing database that stores polygon data for drawing roads;
A road marking regulation database that stores road marking regulation data that defines the shape and position of the road white line to be drawn on the road to distinguish vehicle lanes;
An intersection area setting unit for setting an intersection area around a node in road network data based on polygon data;
A road white line generation unit that generates road marking data for drawing a road white line in a shape defined in the road marking regulation data at a position determined by the road marking regulation data based on the boundary between the road and the intersection area It was.

According to the present invention, road marking data for drawing road markings can be generated using an existing drawing database and road network data, so that the burden of field surveys can be greatly reduced.
However, in the method of the present invention, the position and shape of road markings such as road white lines and pedestrian crossings may not completely match the local conditions. However, even when the position and shape of the road marking are slightly different from the local state, the effect that the user who viewed the map can easily collate with the local state is easily obtained.
In the present invention, by using road marking regulation data in addition to the drawing database and the road network data, the accuracy of the road marking data is improved, and the drawing of the road marking in accordance with the above-described purpose is realized.

In the present invention, the road marking data can be configured in various formats such as polygon data and raster data. The road marking data may be configured as a part of the drawing database or polygon data, or may be configured as data different from these.
The road marking regulation data is preferably prepared based on laws and regulations such as a road structure ordinance. By doing so, the road marking data is generated using the same rules as the actual road marking, so that the accuracy can be improved. However, the road marking regulation data can include not only the contents stipulated in the regulations but also other regulations.

The intersection area can be set by various methods. For example, when polygon data is prepared for each road, a portion where polygon data of roads overlap may be used as an intersection area. Alternatively, a point corresponding to the corner of the intersection may be obtained based on the distance from the road network data node to the road boundary, and the intersection region may be set by connecting the points.
By setting the intersection area in this way, it is possible to accurately set the position and shape of road markings drawn around the intersection, such as stop wars and pedestrian crossings. In addition, since the road white line is not drawn in the intersection and the end point is often determined by a stop war or a pedestrian crossing, drawing a stop war with high accuracy contributes to improving the accuracy of the road white line.

In the map data generation system of the present invention,
If the link is defined by a polyline according to the road shape,
Road white line generator
Create a straight link that stretches the link in a straight line without changing its length,
Generate straight road marking data, which is road marking data for straight links,
Divide the straight road marking data at the point corresponding to the broken line of the link line,
By arranging the divided straight road marking data along the link, the road marking data for the broken line link may be generated.

By doing so, road markings can be generated with high accuracy even for broken line links.
When the straight road marking data generated for the straight link is divided and arranged on the broken line link, a portion where the road marking data overlaps or a gap is generated. For these, road marking data may be generated by a method such as smoothly interpolating portions other than the overlapping portion and the gap portion.

In the map data generation system of the present invention,
Furthermore, a road network grouping processing unit that refers to road network data and defines links and nodes that satisfy a predetermined group condition as a group,
The intersection area setting unit may set an intersection area by excluding nodes existing between links in the same group.

By doing so, it is possible to perform flexible processing at an intersection that is different from normal.
For example, in a place where a narrow street intersects with a main road, there may be a case where a road white line is consistently drawn on the main road even if strictly within the intersection. If each of these areas is handled as an intersection, the road white line of the spectator road may be finely divided, resulting in a state different from the actual situation. In such a case, if a series of links constituting a main road is defined as a group according to the above aspect, the main roads in the same group can be handled as a series of roads, and narrow streets intersect. Since it is possible to recognize that the location is different from the normal intersection, it is possible to generate a consistent white road on the main road. Thus, according to the above-described aspect, depending on circumstances such as the arrangement and type of roads constituting the intersection, it is possible to switch whether or not to treat as an intersection area through a group and to draw a road white line without a sense of incongruity. It becomes possible.
In this embodiment, the group can be set in various ways. For example, in the road network data, the same group name or the like may be given to links to be grouped in advance, and grouping may be performed according to the group condition that the group names are the same. Even when there is no such data, those having the same attributes such as the road name, road type, lane width, and road intersection angle may be grouped.

In the map data generation system of the present invention,
Furthermore, a reference line that intersects the target link is set at an intersection angle determined according to the angle between the target link to be processed for drawing a pedestrian crossing and the intersection link that intersects the target link, and the reference line is defined as one side. You may provide the pedestrian crossing process part which produces the pedestrian crossing data for drawing a pedestrian crossing in the area | region of a quadrilateral.

The pedestrian crossing is not necessarily drawn to be orthogonal to the road. At intersections where roads intersect diagonally, there are places where pedestrian crossings intersect with roads diagonally according to the angle of intersection. According to the above aspect, by using the crossing angle according to the crossing state of the target link and the crossing link, it is possible to draw a crossing that crosses diagonally, and it is possible to reproduce a crossing in a state close to reality. Become.
The intersection angle can be set by various methods such as an angle between the target link and any one of the intersection links, and an average value of angles between the plurality of intersection links.

In the map data generation system of the present invention,
If the road network data link has lane increase data representing the increase in the number of lanes in the link,
Road white line generator
For links with an increasing number of lanes, based on the road marking regulation database, the required stay length that is the length of the stay section that should be drawn with increasing lanes, and the length of the rubbed section for shifting to the stay section Seeking rubbed length,
By shortening the required residence length over the rubbing length, the necessary residence length and the rubbing length are adjusted so that the sum of the required residence length and the rubbing length is smaller than the link length.
Based on the adjusted rub length and the required stay length, road marking data for drawing the stay section and the rub section may be generated.

There are lanes increasing near the intersection for right or left turn, and there are places where a staying section and a rubbing section are provided. According to the above-described aspect, it is possible to generate data for drawing these staying sections and rubbing sections.
In the above-mentioned aspect, both lengths can be adjusted so that the sum of the staying section and the rubbing section is smaller than the length of the link, that is, the length between the intersections. Since this adjustment is performed by preferentially shortening the staying section, the length of the rubbed section for changing the lane during traveling is ensured. Since an actual staying section and a rubbing section are usually configured in this way, a state close to reality can be realized by adjusting with this method.

When drawing a rubbed section,
Road white line generator
In a link in which a rubbed section and a stay section are set, road marking data for drawing a current carrying zone in a shape based on the road marking regulation data may be generated in a gap generated between the rubbed sections of the upper and lower lines.

  By doing so, it becomes possible to draw a current-carrying zone (hereinafter sometimes referred to as “zebra zone”). Since the zebra zone is a portion that is easy to visually recognize when the user looks at the road, there is an advantage that the map can be easily compared with the actual state by drawing the zebra zone. As described above, the zebra zone may be drawn by providing not only the gap in the rubbing section but also various regulations.

  In addition, the present invention may be configured as a map data generation method for generating map data by a computer, or may be configured as a computer program for causing a computer to generate map data. Moreover, you may comprise as a computer-readable recording medium which recorded such a computer program. The recording medium may be a medium separate from the computer such as a CD-ROM or a server, or may be an internal storage device such as a RAM, ROM, or hard disk built in the computer.

It is explanatory drawing which shows the outline | summary of road marking data generation. It is explanatory drawing which shows the structure of a map data generation system. It is explanatory drawing which shows the example of the content of a road marking regulation database. It is a flowchart of a map data generation process. It is explanatory drawing which shows the outline | summary of grouping. It is a flowchart of a road network grouping process. It is a flowchart of an intersection area | region setting process. It is explanatory drawing which shows the determination method of the candidate value of the intersection angle of a pedestrian crossing. It is a flowchart (1) of a pedestrian crossing angle determination process. It is a flowchart (2) of a pedestrian crossing angle determination process. It is a flowchart (1) of a road white line production | generation process. It is a flowchart (2) of a road white line production | generation process. It is a flowchart (3) of a road white line production | generation process. It is a flowchart (4) of a road white line production | generation process. It is a flowchart of a pedestrian crossing drawing process. It is explanatory drawing which shows the example of a production | generation of road marking data.

<< Overview of map data generation >>
The map data generation system of an Example produces | generates the road marking data for drawing the road marking shown on a road using drawing data, road network data, etc. FIG. In the present embodiment, the map data includes the above-mentioned drawing data and road network data, and the road marking data constitutes a part of the drawing data. The road marking data can be used for an electronic map displayed on a display or the like, or can be used as data for printing a map as a printed matter.

First, an outline of a method for generating road marking data in the present embodiment will be described. FIG. 1 is an explanatory diagram showing an outline of road marking data generation. FIG. 1 (a) shows a road drawn using the road marking data generated by this embodiment, and FIG. 1 (b) shows an aerial photograph of a location corresponding to FIG. 1 (a). . In this embodiment, the road marking data for drawing FIG. 1A is not generated using the aerial photograph of FIG. 1B. The map data generation system according to the embodiment generates road marking data (FIG. 1A) with reference to road drawing data, road network data, etc. regardless of the aerial photograph (FIG. 1B). It is.
The road markings in the present embodiment include a road lane outermost line LL11, a road lane border LL12, a stop line LL13, a pedestrian crossing PT11, a diversion zone or a zebra zone PT12, and the like. The road lane outermost line LL11 and the road lane border LL12 may be collectively referred to as “road white line”.
As the simplest processing example for generating road marking data, for example, a road white line may be arranged so that two lanes are formed with a constant lane width on a two-lane road. However, the pedestrian crossing PT11, the stop line LL13, the zebra zone PT12, etc. cannot be generated only by this processing. In the present embodiment, a region where the lane increases for a right turn (region A11 in FIG. 1A) is also reproduced. The map data generation system generates road marking data corresponding to these road markings from drawing data or the like based on preset rules.
In FIG. 1A, it can be seen that the road markings are drawn with high accuracy to the extent that it can be recognized as a map of the area corresponding to the aerial photograph of FIG. Hereinafter, a system configuration and processing for generating such road marking data will be described.

<< System configuration >>
FIG. 2 is an explanatory diagram showing the configuration of the map data generation system. The map data generation system is configured by installing software for realizing map data generation processing in a computer including a CPU, a RAM, and a ROM. In this embodiment, an example of a configuration as a system that operates in a stand-alone manner is shown, but each element shown in the figure may be realized by distributed processing using a plurality of computers connected by a network or the like.

The map data generation system includes a map database 10 and a road marking definition database 20 as databases used for processing.
The map database 10 has a road network database 11 and a drawing database 12. The road network database 11 stores road network data represented by nodes and links for route search. In the road network data, attribute data indicating a road type, a road name, the number of lanes, and the like are also set for each link and node. The drawing database 12 stores polygon data for drawing a map. The polygon data includes, for example, data for drawing roads, buildings, lakes, and the like. Further, when road marking data is generated by the processing described in the embodiment, the road marking data is also stored as part of the polygon data.
The road marking regulation database 20 stores road marking regulation data that defines the shape and position of road markings. In this embodiment, road marking regulation data is set based on the regulation contents of the road structure ordinance. The data structure and contents will be described later.
The map database 10 and the road marking definition database 20 may be stored in a hard disk or the like in the map data generation system, or may be provided from a server connected via a network. Moreover, you may provide with storage media, such as DVD.

  The road marking data storage unit 40 is a storage unit that stores data of a process of generating road marking data and a generated result. Various rewritable memories such as a memory area such as a RAM, a hard disk, and a flash memory can be used as the road marking data storage unit 40.

  As other components of the map data generation system, functional blocks for generating road marking data are shown in the figure. These functional blocks may be configured by software by installing a computer program, or may be configured by hardware by an electronic circuit. Hereinafter, the functional outline of each functional block will be described. However, a specific processing method in each functional block will be described later together with a flowchart.

  The road network grouping processing unit 30 groups links and nodes on which road white lines should be drawn as a series of roads as a main road as preprocessing for generating road marking data. In the road network data, since all nodes are set at the intersections of the links, a series of links constituting the main road are also divided at each node, but such divided links are grouped together. In this way, in the generation of road marking data, it becomes possible to handle a main road or the like as a series of roads.

  The intersection area setting unit 32 sets an intersection area with reference to the polygon data and the road network data. Many road markings, such as pedestrian crossings and stop wars, are located on the basis of the boundary of the intersection area, so the intersection area set here has significance as a reference for determining the position of the road marking. Yes. A method for setting the intersection area will be described later.

  The pedestrian crossing processing unit 34 sets the shape of the pedestrian crossing and generates data for drawing the pedestrian crossing. The pedestrian crossing is not necessarily drawn to be orthogonal to the road, and depending on the intersection, it may be drawn to cross the road diagonally. In consideration of the shape of the intersection, the pedestrian crossing processing unit 34 can draw a pedestrian crossing that intersects obliquely in this way.

  The road white line generation unit 36 generates data for drawing a road white line, a stop game, and a zebra zone. When the number of lanes increases for a right turn, the road white line generation unit 35 also generates data for drawing a staying section where the increased lane is drawn and a rubbing section for smoothly connecting to the staying section.

  The database update unit 38 reads the road marking data generated from the road marking data storage unit 40 and updates the drawing database 12. In this embodiment, the road marking data constitutes a part of the drawing database 12, but the road marking data may be stored in the map database 10 as a database different from the drawing database 12.

FIG. 3 is an explanatory diagram showing an example of the contents of the road marking definition database 20.
The road marking definition database 20 defines the shape and position of the road marking based on the contents of the road structure ordinance. FIG. 3A illustrates the sign, content, and numerical value of each parameter that configures the road marking definition database 20. FIG. 3B shows the significance of each parameter in association with the marking on the road. The contents of the parameters exemplified here will be described below.
The lane width WLN is the width of the lane in which the vehicle travels, and can be set to 3.0 m, for example.
The vehicle lane outermost line width and the vehicle lane boundary line width WLL are the width (thickness) of the road white line, and can be, for example, 0.15 m.
The vehicle lane boundary line length (broken line) LL is the length of the road white line drawn with a broken line, and can be set to, for example, 5.0 m.
The white line width (zebra) ZW in the current-carrying zone is the width of the white line constituting the zebra zone, and can be set to 0.45 m, for example.
The distance between white lines (Zebra) ZS in the current-carrying zone is an interval between white lines constituting the zebra zone, and can be set to, for example, 1.0 m.
The stop line width WSL is the width of the stop line, and can be set to 0.45 m, for example.
The distance DS between the pedestrian crossing and the stop line is an interval between the pedestrian crossing and the stop line, and can be set to 2.0 m, for example.
The lane change prohibition line DPC in front of the stop line is the length of the section in which the road white line should be drawn with a solid line instead of a broken line until the stop line is prohibited, for example, 30.0 m Can do.
The pedestrian crossing line width WCW and the line interval SCW are the widths and intervals of the white lines constituting the pedestrian crossing, and can be both 0.45 m, for example.
In this embodiment, these numerical values are set based on regulations such as a road structure ordinance. In addition to this, various parameters for determining the position and shape of the road marking can be set in the road marking definition database 20. Further, not all parameters need to be set based on the road structure ordinance, and parameters that are not defined in the road structure ordinance may be defined in order to accurately reproduce the actual state.

<< Overall process flow >>
Next, processing for generating road marking data will be described. First, an overview of the entire process is shown, and then the specific processing contents are described in detail.
FIG. 4 is a flowchart of the map data generation process. The “map data generation process” is called because a new map database 10 including road marking data is generated by storing the road marking data generated by this process in the map database 10. It is.

The map data generation process is a process executed by the CPU of the map data generation system in terms of hardware, and is executed by each functional block shown in FIG. 1 in terms of software.
As a pre-processing, the CPU performs a process of grouping nodes and links that should be treated as a series of roads when road marking data is generated by a road network grouping process (step S100). I do. This is a process corresponding to the function of the road network grouping processing unit 30 described above.
Next, the CPU performs a process of setting an intersection area by referring to polygon data and road network data by an intersection area setting process (step S200). This is a process corresponding to the function of the intersection area setting unit 32 described above.
Next, the CPU performs a process of determining how many angles the pedestrian crossing is drawn on the road by the pedestrian crossing angle determination process (step S300). This is a process corresponding to the function of the pedestrian crossing processing unit 34 described above.
Next, the CPU generates useless data for drawing a stop line, a road white line, and a zebra zone by a road white line generation process (step S400). This is a process corresponding to the function of the road white line generation unit 36 described above. In this embodiment, each road is divided into upper and lower lines at a position corresponding to the center line, and data for drawing a stop line, a road white line, and a zebra zone is generated, and then the data of the upper and lower lines are combined to create a road. The procedure is to generate data that draws the entire stop line, road white line, and zebra zone.
Next, the CPU generates data for drawing the pedestrian crossing by the drawing process of the crossing security (step S500). This is a process corresponding to the function of the pedestrian crossing processing unit 34 described above.
The data generated in steps S400 and S500 is road marking data.
Finally, the CPU performs a process of updating the drawing database 20 with the generated road marking data (step S600).
The above processing may be performed in an appropriate order or collectively. Hereinafter, each processing content is explained in full detail.

<< Road network grouping >>
The road network grouping is processing content corresponding to the functions of step S100 and the road network grouping processing unit 30 in FIG. Below, after showing the meaning and outline | summary of a process first, a flowchart is shown.

FIG. 5 is an explanatory diagram showing an outline of grouping.
FIG. 5A shows a road where a link L53 of a narrow street intersects with links L51 and L52 constituting the main road at a node N50. In road network data, a node is always set at the intersection of links regardless of the road type. Accordingly, the links L51 and L52 constituting the main road are also stored on the road network data in a state of being divided into a plurality of links, and the node N50 is recognized as an intersection. An intersection area A50 (hatched portion) is set around the node N50 by a processing method described later. Since the road white line is usually drawn avoiding the intersection area, as a result of setting the intersection area A50, the road white line divided as the road white lines LL51 and LL52 is drawn for the main road. Become.
However, in general, at a portion where a narrow street intersects with a main road, a white road on the main road is usually drawn continuously without being divided as shown in FIG.
Therefore, in the network grouping process, links and nodes that should not generate intersection areas, such as intersection area A50, are defined as groups. In the example of FIG. 5A, in the process of generating road marking data in the direction D51, the link L51, the node N50, and the link L52 are defined as a group. In this way, when the road marking data is generated for the links L51 and L52, it is recognized that these links and nodes should be handled as a series, and the setting of the intersection area A50 is avoided. The road white lines LL51 and LL52 can be generated in a continuous state.
Conversely, no grouping is performed in the process of generating road marking data in the direction D52. By doing so, since the intersection area A50 is set, the road outermost lines LL53 and LL54 can be generated in a state of being divided by the intersection area A50.
Consider a case where road marking data of link L53 is generated for this intersection. The link L53 is not defined as a group in any of the links L51 and L52. In this way, at the time of processing the link L53, the intersection area A50 around the node N50 can be set, and a stop line and a crosswalk can be drawn on the straight line of the intersection.

FIG. 5B shows another example in which grouping should be performed. In the example shown in the figure, links L58 and L59 that run in parallel across a relatively narrow separation band M51 intersect with links L54 to L57 at nodes N51 and N52. Such a situation can occur in places such as urban areas where the vertical lines are separated by the separation band M51.
When processing is performed without grouping in such a place, the node N51 is recognized as an intersection, and the intersection area A51 is set. This is because the position of the node N52 and the link L59 is not considered when processing the node N51. When the intersection area A51 is set, a pedestrian crossing is set based on the intersection area A51. Therefore, the pedestrian crossing CW51 is set so as to cross the separation zone M51.
Therefore, in the network grouping process, when the process is performed in the D53 direction, the link L55, the node N51, and the link L54 are defined as a group. By doing this, it is possible to exclude the node N51 and set an intersection area only around the node N52, so that it is possible to generate the pedestrian crossing CW52 instead of the unnatural pedestrian crossing CW51.
When processing in the D54 direction, the link L55, the node N52, and the link L56 are defined as a group. By doing so, it is possible to exclude the node N52 and set an intersection area only around the node N51, so that a pedestrian crossing CW53 can be generated.
For the other links L57, L58, and L59, if a process is performed without defining a group, it is possible to generate a pedestrian crossing at an appropriate position.
As described above, as shown in FIGS. 5 (a) and 5 (b), by performing grouping, it is possible to switch whether or not to set an intersection area, and to reflect the situation of each intersection A sign can be generated. Next, specific processing for grouping will be described.

FIG. 6 is a flowchart of the road network grouping process.
The CPU reads the road network data (step S102) and selects a node to be grouped (step S104). Then, a link connected to this node is extracted (step S106).
Next, the CPU determines a road condition for the extracted link (step S108). The road condition is a condition for judging whether or not a plurality of links divided by nodes should be treated as a series of roads in the generation of road marking data, and is a basis for judgment for grouping. It is a condition. In this embodiment, it is assumed that whether or not the road is a road is set individually in the vertical direction of each link as an attribute in the road network data.
A three-way road composed of links L1 to L3 shown in the figure is illustrated. Among these, the direction P12 from the link L1 to the link L2 and the direction P21 from the link L2 to the link L1 are set to be “roadways”, and the other directions (link L1 → L3, etc.) are It is assumed that “Road” is not set. Based on this attribute, the CPU extracts the result of whether or not each link is a road as shown in the figure.
Whether it is a road or not may be determined analytically based on the road type, road name, lane width, shape, etc., in addition to being set as an attribute. For example, it is determined that links with the same road name and road type are determined to be roads, or that the links are determined to be roads if the angle between the links is within a predetermined range from 180 degrees. Can do.

When the determination of the road condition is completed, the CPU performs grouping based on the determination result (step S110). In this embodiment, a group is set when any one of cases 1 and 2 shown in the figure is satisfied. A case where the link La is a processing target will be described as an example with respect to the three-way road including the links La, Lb, and Lc shown in the drawing.
Case 1 is a case where, in step S108, it is determined that both the direction Pab of the link La → Lb and the direction Pba of the link Lb → La are the way.
Case 2 is a case where, in step S108, it is determined that only the direction Pab of the link La → Lb is a road, and it is determined that the link Lc and the links La and Lb are not a road.
Cases 1 and 2 are set as a result of investigating a portion that is not handled as an intersection on an actual road. If grouping is performed according to this condition, road white lines can be appropriately generated in the cases shown in FIGS. 5 (a) and 5 (b). However, various conditions can be set for the grouping, and conditions other than those shown in step S110 can also be used.
If the link La in the above condition is replaced with the link Lb or the link Lc, the grouping condition for these links can be set. In step S110, the CPU determines grouping for all links connected to the processing target node.
The CPU repeatedly executes the above processing until all the nodes are completed (step S112).

<< Intersection area setting >>
The intersection area setting is processing contents corresponding to the functions of step S200 and the intersection area setting unit 32 in FIG.
FIG. 7 is a flowchart of the intersection area setting process. The CPU selects a processing target node (step S202). At this time, the nodes on the grouped links are excluded from the processing targets by the above-described road network grouping processing (FIG. 6).
The CPU reads polygon data around the processing target node from the drawing database, and acquires a road area (step S204). The state of the process is illustrated on the right side in the figure. When the node N70 is a processing target node, the road area (white portion in the figure) corresponding to the links L71 to L74 connected thereto is specified. It is not always necessary to acquire polygon data of the road itself, and polygon data of a background portion other than the road (hatched portion in the figure) may be acquired.
As shown on the right side, the periphery of the processing target node N70 is divided into four areas I to IV by links L71 to L74. For each of the areas I to IV, the CPU acquires an intersection, that is, the nearest point from the processing target node N70 (step S206). As shown in the figure, point P1 for region I, point P2 for region II, point P3 for region III, and point P4 for region IV are the nearest points.
When the nearest neighbor is found, the CPU connects these and sets an intersection area (step S208). In the figure, a portion surrounded by a thick line connecting points P1, P2, P3, and P4 is an intersection region.
The CPU repeatedly executes the above processing until all the nodes are completed (step S210).
The intersection area set in this way is used as a reference for the position when the white road line is drawn.

<< Generation of crosswalk >>
The generation of the pedestrian crossing is a processing content corresponding to the functions of step S300 and the pedestrian crossing processing unit 34 in FIG. In the case of drawing a pedestrian crossing, after describing a method of setting candidate values for the intersection angle between the pedestrian crossing and the road, the processing content will be described.

FIG. 8 is an explanatory diagram showing a method for determining candidate values for the intersection angle of a pedestrian crossing. The example of setting the four candidate values of FIGS. 8A to 8D is shown by taking the case where the link L81 is a processing target at the intersection where the links L81 to L84 intersect.
FIG. 8A shows an example in which a pedestrian crossing WC81 orthogonal to the link L81 is set. As shown in the figure, at the intersection where the roads intersect diagonally, if it is drawn like a pedestrian crossing WC81, the space to the intersection is opened on the right side of the link L81 (link L84 side), and it becomes an unnatural state. . In such a case, it is preferable to draw the pedestrian crossing obliquely in a state of rising to the right in the drawing.
FIGS. 8B to 8D are examples in which a pedestrian crossing WC82 is set obliquely with respect to the link L81. The pedestrian crossing WC82 in FIG. 8B is drawn by a parallelogram having sides parallel to the link L83 intersecting the left side of the link L81. The pedestrian crossing WC83 in FIG. 8C is drawn by a parallelogram having sides parallel to the link L84 intersecting the right side of the link L81. The pedestrian crossing WC84 in FIG. 8D has points P83 and P84 that are equidistant from the node N on the links L83 and L84, and has a parallelogram having sides parallel to the line segment connecting these points P83 and P84. be painted. It can also be said to be a parallelogram having a side whose normal is the bisector of the corner between the links L83 and L84.
In this embodiment, one of the three candidate angles shown in FIGS. 8B to 8D is selected according to the intersection, and the intersection angle of the pedestrian crossing is determined. The determination method will be described according to the following flowchart.

9 and 10 are flowcharts of the pedestrian crossing angle determination process.
The CPU first selects a processing target link, and acquires an intersection link that intersects the processing target link (step S302). Although it is possible to acquire all the links that intersect the processing target link, in this embodiment, the acquisition is limited to those satisfying the following conditions 1 and 2. Here, “A9 *” is an angle between the link L9 * (* = 1, 2,...) Intersecting the processing target link and the processing target link.
Condition 1: | A9 * -90 ° | is minimized on both sides of the processing target link;
Condition 2: 90 ° −TH ≦ A9 * ≦ 90 ° + TH;
Condition 1 is a condition for selecting a link that intersects the processing target link at an angle closest to 90 ° one by one on both sides of the processing target link. Condition 2 is a condition that the angle between the selected link and the processing target link is within a predetermined range from a right angle. Under these conditions, a link that intersects at an angle close to a right angle is obtained on both sides of the processing target link.

The above conditions 1 and 2 are illustrated in the figure. Assume that at the node Nob at the end of the processing target link Lob, the links L91 and L93 intersect on the left side and the link L92 intersects on the right side. The angles between the processing target link Lob and the links L91 to L93 are represented by A91 to A93, respectively. The hatched portion in the figure represents a range that satisfies the condition 2. That is, the boundary line BL1 is a line whose angle with the processing target link Lob is “90 ° −TH”, and the boundary line BL2 is a line whose angle is “90 ° + TH”. In the state shown in the figure, since the links L91 to L93 are all within the hatched area, the condition 2 is satisfied.
Only the link L92 exists on the right side of the processing target link Lob. Therefore, in the condition 1 that | A9 * −90 ° | is the minimum, the link L92 is selected without comparing with other conditions.
Links L91 and L93 exist on the left side of the processing target link Lob. Of these, the link L91 intersects the processing target link Lob at an angle close to a right angle. Therefore, on the left side, the link L91 is selected according to the condition 1. If expressed in a form corresponding to condition 1, | A91−90 ° | <| A93−90 ° |.

When the intersection link is acquired in this way, the CPU calculates the left and right intersection angles (step S304). The definition of the left / right crossing angle is shown in the figure. In order to avoid complication of the figure, the left and right parts are shown separately. The left figure shows the left intersection angle, and the right figure shows the right intersection angle. The left intersection angle is defined by an angle AN91 between the normal line NL91 of the link L91 intersecting the left side and the processing target link Lob. The right intersection angle is defined by an angle AN92 between the normal line NL92 of the link L92 that intersects the right side and the processing target link Lob. Since the evaluation of the left crossing angle and the right crossing angle is performed using absolute values, it is not necessary to consider the sign of positive or negative depending on whether the angles AN91 and AN92 appear on the left or right of the processing target link.
When the crossing report is drawn using the left intersection angle, the state is as shown in FIG. 8B, and when the pedestrian crossing is drawn using the right intersection angle, the state is as shown in FIG. 8C.
Next, the CPU calculates an average intersection angle (step S306). As shown in the figure, the average intersection angle is an angle AN93 between the bisector NL93 of the left and right intersection links L91 and L92 and the processing target link Lob. When a pedestrian crossing is drawn using this angle, the state shown in FIG.

The CPU sets the minimum value of the left and right intersection angles and the average intersection angle obtained above as the pedestrian crossing angle (step S308). The angle was evaluated as an absolute value. Drawing of a pedestrian crossing at a set pedestrian crossing angle is performed by a pedestrian crossing drawing process described later.
The CPU repeats the above processing until it is finished for all links (step S310).

<< Generation of white road lines >>
The generation of the road white line is a processing content corresponding to the functions of step S400 and the road white line generation unit 36 in FIG.
11 to 14 are flowcharts of the road white line generation process.
The CPU acquires a link group to be processed (step S402). Then, the link group is linearized (step S404). The linearization method is shown in the figure. As shown in the upper side of the figure, a link group including links L111 and L112 and nodes N111 to N113 is considered. It is assumed that this link group is defined by a broken line that is bent along the road shape.
In the linearization process, as shown on the lower side of the figure, the nodes N111 to N113 are mapped onto one-dimensional coordinates while maintaining the lengths of the links L111 and L112. The mapped results are referred to as linearization links L111s and L112s and linearization nodes N111s to N113s.

The CPU determines the positions of the vehicle lane outermost line and the center line (step S406). These determination methods are shown in the figure. The determination method is as follows.
The road network data includes road width Wrd and the number of lanes as road attributes. Further, the road marking regulation data (see FIG. 3) has the lane width as a parameter. Accordingly, by calculating the lane width × the number of lanes using these data, the width D used for the lane among the road width Wrd is determined. By arranging the width D evenly within the road width Wrd, the positions of the vehicle lane belt outermost lines BL1 and BL2 can be determined. Moreover, the position of the center line CL can be determined by dividing the width D by the number of lanes on the upper and lower lines. Since the number of lanes of the upper and lower lines is not necessarily the same, the center line CL does not necessarily come to the center of the width D. For example, on a road with two lanes going up and one lane going down, the center line is set at a position where the width D is internally divided by 2: 1.

When the center line is set in this way, the CPU divides the road vertically by the center line, and generates road marking data for each. Specifically, an intersection area, a pedestrian crossing area, and a stop line are set, and the outermost line length and the center line length of the vehicle lane are corrected based on the results (step S408).
An example of processing is shown in the figure. Consider a case where processing is performed in the direction D12. The CPU arranges the intersection area CS set in the intersection area setting process (FIG. 7). Then, based on the pedestrian crossing angle determined in the pedestrian crossing angle determination process (FIG. 9), the reference line LCS0 is drawn from the end point of the intersection area. An angle ACS between the reference line LCCS0 and the processing target link L11s corresponds to a pedestrian crossing angle.
Next, a pedestrian crossing area CW is set as a parallelogram having a predetermined width LCW at a position shifted by a predetermined distance OST from the reference line LCS0 in a direction away from the intersection area. These distance OST and width LCW may be set in the road marking regulation data.
The CPU cuts the vehicle lane belt outermost line BL2 and the center line CL at the boundary line of the pedestrian crossing area CW. Further, the stop line SL is set at a position shifted from the intersection of the center line CL and the pedestrian crossing area CW by the distance DS between the pedestrian crossing and the stop line. In addition, a vehicle lane boundary line is set in parallel to the vehicle lane outermost line BL2 and the center line CL according to the number of lanes.
A road marking can be drawn on the down line in the same manner. The procedure described here is only an example, and may be generated by another method / procedure.

The CPU calculates a slag length Lt and a required stagnation length Ls in order to generate a stay section and a rub section for the lane increase portion (step S410). These lengths can be calculated as follows based on laws such as the road structure ordinance.
Required residence length Ls = 1.5 × N × S;
Rubbing length Lt = V × WLN / 6;
N: Average number of stays per cycle;
S: Average vehicle head distance (distance between the heads of the front and rear vehicles);
V: Design speed;
WLN: Lane width;
Of the above parameters, the lane width may be stored in the road marking definition data as a value common to all roads. Since the parameters N and V are values specific to the road, it is preferable to set them as attributes in the road network data. These default values may be set in the road marking regulation data. For example, the design speed V can be set according to the number of lanes, such as 30 km / h for a one-lane road, 40 km / h for a two- to three-lane road, and 50 km / h for four or more lanes.
The parameter S may be set as an attribute of road network data, considering a value unique to the road, or may be set in the road marking definition data as a value common to all roads.
Furthermore, these default values may be set for the case where the above-mentioned parameters are insufficient and the necessary staying length Ls and rubbing length Lt cannot be calculated. For example, the required staying length Ls can use the same value as the distance DPC (see FIG. 3) of the lane change prohibition line before the stop line.

The CPU adjusts the calculated rubbing length Lt and the necessary staying length Ls so that the staying section and the rubbing section are within the road length (step S412). For the road length, the outermost vehicle lane and the minimum value min of the center line are used as the reference value Lrd. The reason why the minimum value min is used is that, as depicted in step S408 of FIG. 12, the pedestrian crossing area is set obliquely, and the length of the center line may differ from the outermost side of the vehicle lane. is there.
As shown in the upper side of the figure, consider a case where “necessary staying length LS0 + rubbing length Lt0” is larger than the reference value Lrd. In such a case, as shown in the figure, the staying section and the rubbing section are protruded from the road.
In this embodiment, in such a case, the necessary retention length is shortened while ensuring the rub length, so that the sum of both is adjusted to be equal to or less than the reference value Lrd. The adjustment results are shown in the lower part of the figure. In this example, the rubbing length Lt1 is the same as the initial length Lt0, and the required length Ls1 is made shorter than the initial length Ls0, so that the entire length falls within the reference value Lrd. In this aspect, even if the required staying length Ls is reduced to a preset limit such as the length of one vehicle, if the total length exceeds the reference value Lrd, the rubbing length Lt is reduced. It will be. However, various adjustment methods can be used for the necessary residence length and the rub length, and a method of shortening both at a fixed ratio can also be used.

The CPU polygonizes each white line set by the above processing (step S414). A white line here means a stop line, a center line, and a road white line (a vehicle traffic zone outermost line, a vehicle traffic zone boundary line). The pedestrian crossing is not yet drawn at this point.
The CPU combines the road marking data of the upper and lower lines with the center line, and then sets the gap between the upper and lower line rubbing sections as a guiding fluid (zebra zone) (step S416). The zebra zone ZZ set in the gap between the upper and lower rubbing sections LSA and LSB is illustrated in the figure. The width and interval of the white lines that make up the zebra zone are defined in the road marking definition data (see FIG. 3).
Through the above processing, the road marking data for the up and down lines is generated.

The processing so far has been performed after straightening the broken line link (see step S404 in FIG. 11), but what is required is data for drawing road markings on the broken line road. It is. In order to obtain such road marking data, the CPU divides the generated road marking data along the polygonal line shape and maps it along the link (step S418).
An example of processing is shown in the figure. First, as shown in the upper side of the figure, for the straight links L111s and L112s and the straight nodes N111s to N113s, the obtained road marking data is represented by normal BRL passing through the node N112s and left and right polygons POL1 and POL2. Divide into The divided left and right polygons POL1 and POL2 are arranged on the original links L111 and L112 having a polygonal line shape as shown in the lower side of the figure. As a result of the mapping, a region DA where the polygons POL1 and POL2 overlap and a gap RA between the two are generated. These areas DA and RA may be generated by smoothly interpolating polygons in other areas (outlined portions in the figure) according to the shapes of the links L111 and L112.
An example of mapping is shown at the bottom of the figure. The road marking shown in step S416 in FIG. 13 is divided and mapped at the node N112. Due to the mapping, the shape of the zebra zone ZZ changes in this way.
The CPU repeatedly executes the above processing until all groups are finished. With these processes, generation of road markings excluding pedestrian crossings is completed.

Next, in order to draw a pedestrian crossing, the CPU executes a pedestrian crossing drawing process. This is processing content corresponding to the functions of step S500 and the crosswalk processing unit 34 in FIG.
FIG. 15 is a flowchart of the pedestrian crossing drawing process. The CPU reads the pedestrian crossing area set in step S408 of FIG. 12 (step S502).
Then, crosswalk polygon data is generated in this area (step S504). Parameters set in the road marking definition data are used for the width WCW and the interval SCW of the white lines PCW1 to PCW3 constituting the pedestrian crossing. When the pedestrian crossing area CW is a parallelogram, the shape of each of the white lines PCW1 to PCW3 is also a parallelogram composed of sides parallel to the side of the pedestrian crossing area CW.
The CPU repeatedly executes the above processing until it ends for all pedestrian crossing areas (step S506).

  The pedestrian crossing can also be drawn when the pedestrian crossing area is set in step S408 in FIG. However, if the pedestrian crossing is drawn at this time, it is necessary to map each polygon constituting the pedestrian crossing in the subsequent mapping (step S418 in FIG. 14), and the processing load increases. In this embodiment, in order to reduce this processing load, the pedestrian crossing is drawn after the mapping is completed.

  Through the above processing, road marking data is generated. In the processing of the present embodiment, the arrangement of arrows and the like on the road was not shown. However, if the position and shape where the arrow and the like should be drawn are defined in the road marking definition data, the road marking is referred to by referring to this. It is possible to generate data.

<< Example of road marking data >>
FIG. 16 is an explanatory diagram illustrating an example of generation of road marking data. FIG. 16A shows a generation example according to the present embodiment, and FIG. 16B shows an aerial photograph of a corresponding region.
At first glance, such as the pedestrian crossing CW16, it can be seen that the actual state can be accurately reproduced to the extent that it can be recognized that FIG. 16 (a) and FIG. 16 (b) correspond to each other. The zebra zone ZZ16 has a different shape from the actual state, but the zebra zone ZZ16 is drawn at this position, so the correspondence between FIG. 16 (a) and FIG. 16 (b) is compared. Can be easily recognized.
As described above, according to the present embodiment, even if the actual state is not accurately reproduced with high accuracy, it sufficiently contributes to the purpose of intuitively recognizing the correspondence between each actual point and the map. It is possible to reproduce road markings with accuracy. According to the present embodiment, there is an advantage that road marking data for drawing such a road marking can be generated with a light processing load.

  Although the embodiments of the present invention have been described above, the various processes described in the above-described embodiments are not necessarily all provided, and some of them may be omitted or replaced with other processes. I do not care. In the above-described example, the process executed in software may be executed in hardware and vice versa.

  The present invention can be used to generate road marking data for drawing road markings.

DESCRIPTION OF SYMBOLS 10 ... Map database 11 ... Road network database 12 ... Drawing database 20 ... Road marking regulation database 40 ... Road marking data storage part 30 ... Road network grouping process part 32 ... Intersection area setting part 34 ... Crosswalk processing part 36 ... Road white line Generation unit 38 ... database update unit

Claims (8)

A map data generation system for generating map data for drawing a map,
A road network database for storing road network data representing roads by nodes and links;
A drawing database that stores polygon data for drawing roads;
A road marking regulation database that stores road marking regulation data that defines the shape and position of the road white line to be drawn on the road to distinguish vehicle lanes;
An intersection area setting unit for setting an intersection area around a node in the road network data based on the polygon data;
A road white line generation unit that generates road marking data for drawing the road white line in a shape defined by the road marking definition data at a position determined by the road marking definition data based on a boundary between the road and the intersection area A map data generation system comprising: The map data generation system according to claim 1,
The link is defined by a polygonal line according to the road shape,
The road white line generation unit
Generate a straight link that extends the link in a straight line without changing its length,
Generating straight road marking data which is the road marking data for the straight link;
Dividing the straight road marking data at a location corresponding to the bending point of the broken line of the link,
A map data generation system for generating road marking data for a broken line-like link by arranging the divided straight road marking data along the link. The map data generation system according to claim 1 or 2,
Furthermore, a road network grouping processing unit that refers to the road network data and defines a link and a node that satisfy a predetermined group condition as a group,
The said intersection area | region setting part excludes the node which exists between the links of the same group, The map data generation system which sets the said intersection area | region. The map data generation system according to any one of claims 1 to 3,
Further, a reference line that intersects the target link is set at an intersection angle determined according to an angle between the target link that is a processing target for drawing a pedestrian crossing and an intersection link that intersects the target link. A map data generation system including a pedestrian crossing processing unit that generates pedestrian crossing data for drawing a pedestrian crossing in a parallelogram area. A map data generation system according to any one of claims 1 to 4,
In the link of the road network data, lane increase data representing an increase in the number of lanes in the link is set,
The road white line generation unit
For the link where the number of lanes increases, based on the road marking regulation database, the required stay length that is the length of the stay section to be drawn by increasing the lane, and the rubbing section for shifting to the stay section Seeking the rubbed length, which is the length,
By shortening the rubbing length in preference to the necessary residence length, the necessary residence length and the rubbing length are adjusted so that the sum of the necessary residence length and the rubbing length is smaller than the length of the link,
A map data generation system for generating road marking data for drawing the staying section and the rubbing section based on the adjusted rubbing length and the required staying length. The map data generation system according to claim 5,
The road white line generation unit
Map data for generating road marking data for drawing a diversion zone in a shape based on the road marking regulation data in a gap formed between vertical rubbing sections in a link in which the rubbing section and the stay section are set Generation system. A map data generation method for generating map data for drawing a map by a computer,
The computer
A road network database for storing road network data representing roads by nodes and links;
A drawing database that stores polygon data for drawing roads;
A road marking regulation database that stores road marking regulation data that defines the shape and position of a road white line to be drawn on the road to distinguish vehicle lanes;
The computer setting an intersection area around a node in the road network data based on the polygon data;
The computer generates road marking data for drawing the road white line in a shape defined in the road marking definition data at a position determined by the road marking definition data based on a boundary between the road and the intersection area. A map data generation method comprising the steps. A computer program for generating map data for drawing a map by a computer,
The computer
A road network database for storing road network data representing roads by nodes and links;
A drawing database that stores polygon data for drawing roads;
A road marking regulation database that stores road marking regulation data that defines the shape and position of the road white line to be drawn on the road to distinguish vehicle lanes,
A function of setting an intersection area around a node in the road network data based on the polygon data;
A function of generating road marking data for drawing the road white line in a shape defined in the road marking definition data at a position determined by the road marking definition data based on a boundary between the road and the intersection area; A computer program to be realized by a computer.