1. Field of Invention
This invention relates generally to traffic intersections and more particularly to generating a geometric layout of an intersection.
2. Description of Related Art
Traffic intersection design commonly involves two generally distinct activities. Firstly, a capacity analysis of the intersection may be performed to determine vehicle flow through the intersection. The capacity analysis may be based on a traffic count of vehicular flow along existing roadway and may include a prediction of expected changes to the flows over time. Capacity analysis generally results in a specification of a number of lanes, permitted movements along the lanes and minimum lane widths for accommodating the expected traffic flows. The capacity analysis may further provide for channelization of traffic flows, lane flaring, medians between lanes etc. While the capacity data prescribes many aspects of the intersection, the capacity data at best only provides sufficient information for producing a schematic representation of the intersection.
Accordingly, the data produced by a capacity analysis system generally forms the input to a subsequent geometric design process, in which the physical geometry of the roadways and transitions between roadways is generated. The geometric design process conforms the schematic intersection that is generated in accordance with the capacity data to the real world and enables preparation of a set of plans for the construction of a physical intersection. During the geometric design process constraints may be encountered that necessitate changes to the intersection that require revision of the capacity analysis and generation of new capacity data. Since the two processes are often performed by different people with different sets of skills, there may be a need for several design iterations to reach a satisfactory geometric layout of an intersection, resulting in a process that may become tedious and time consuming.
There remains a need for improved methods for producing geometric representations of traffic intersections.
In accordance with one aspect of the invention there is provided a method for generating a geometric layout of a traffic intersection. The method involves receiving intersection capacity data, where receiving includes receiving an identification of a number of intersection legs associated with the traffic intersection, receiving a lane designation designating a plurality of lanes for accommodating permitted vehicle movements between the intersection legs, each lane having at least one associated permitted vehicle movement, and receiving lane width dimensions for accommodating an expected vehicular traffic volume associated with permitted vehicle movements on each of the plurality of lanes. The method also involves generating a geometric layout of the traffic intersection by receiving orientation data defining respective orientations of each of the intersection legs. The method further involves receiving intersection design criteria for designing the traffic intersection, for each intersection leg, combining the lane width dimensions and the intersection design criteria to determine extents of a roadway segment corresponding to the intersection leg, applying the intersection design criteria to generate corner geometry connecting between the roadway segments, and generating display signals for causing the geometric layout of the intersection to be displayed on a computer display.
The method may involve generating the intersection capacity data using an intersection capacity analysis system.
Receiving the intersection capacity data may involve receiving intersection capacity data at an interface of an intersection design system.
Receiving the intersection capacity data may involve receiving a data file having fields encoded with values defining the intersection leg identification, lane designation, and lane width dimensions.
Receiving the data file may involve receiving an extensible markup language (XML) data file.
Receiving the lane designation may involve receiving data defining at least one of an approach lane and an exit lane for each of the at least two roadways.
Receiving the lane designation may involve receiving at least one turn designation associated with each of the approach lanes and the exit lanes, the turn designation defining the permitted vehicle movements along each of the lanes.
Receiving the intersection capacity data may further involve receiving speed data associated with each of the permitted vehicle movements, and applying the intersection design criteria to generate the corner geometry may involve using a defined turning path criteria of the design criteria to generate a corner geometry for safely accommodating the vehicle speed along the lane.
The method may involve generating an updated geometric layout in response to receiving operator input defining a change to the intersection, generating updated intersection capacity data including revised data corresponding to the change, and causing the interface to transmit the updated intersection capacity data back to the capacity analysis system.
Receiving the intersection design criteria may involve receiving an operator selection of an industry standard intersection design guideline for designing the traffic intersection.
Receiving the intersection design criteria may involve receiving a designation of a design vehicle for designing the traffic intersection and applying the intersection design criteria to generate corner geometry may involve identifying at least one permitted vehicle movement that defines the corner geometry connecting between the roadway segments, generating a turning path of the design vehicle along the identified permitted vehicle movement, generating first vehicle extent locations associated with passage of the design vehicle along the at least one turning path, and generating an outer edge of the intersection area, the outer edge being generally aligned with selected ones of the first vehicle extent locations.
Receiving the orientation data may involve receiving at least two reference lines defining respective orientations of the intersection legs.
Receiving the at least two reference lines may involve receiving a reference line extending in a direction aligned with an intended direction of traffic movement along a corresponding intersection leg and combining the lane width dimensions and the intersection design criteria may involve offsetting the lane width dimensions from the reference line to determine the extents of the a roadway segment corresponding to the intersection leg.
The method may involve offsetting the lane width dimensions to accommodate at least one of a median between lanes, a clearance allowance between lanes, a clearance allowance between an edge of the roadway section and a curb defining a physical extent of the roadway, or a storage bay associated with a lane designated to permit turning of a vehicle.
Applying the intersection design criteria to generate the corner geometry may involve generating a swept path of a design vehicle between the roadway segments, using the swept path to generate the corner geometry.
Using the swept path to generate the corner geometry may involve generating a curve that generally conforms to the swept path.
The curve may involve one of a simple curve, a 2-centered compound curve, and a 3-centered compound curve.
In accordance with another aspect of the invention there is provided an apparatus for displaying a geometric layout of a traffic intersection. The apparatus includes a processor circuit operably configured to receive intersection capacity data including an identification of a number of intersection legs associated with the traffic intersection, a lane designation designating a plurality of lanes for accommodating permitted vehicle movements between the intersection legs, each lane having at least one associated permitted vehicle movement, and lane width dimensions for accommodating an expected vehicular traffic volume associated with permitted vehicle movements on each of the plurality of lanes. The processor circuit is also operably configured to generate a geometric layout of the traffic intersection by receiving orientation data defining respective orientations of each of the intersection legs. The processor circuit is also operably configured to receive intersection design criteria for designing the traffic intersection The processor circuit is further operably configured to, for each intersection leg, combine the lane width dimensions and the intersection design criteria to determine extents of a roadway segment corresponding to the intersection leg, apply the intersection design criteria to generate corner geometry connecting between the roadway segments, and to generate display signals for causing the geometric layout of the intersection to be displayed on a computer display.
The processor circuit may be operably configured to generate the intersection capacity data using an intersection capacity analysis system.
The processor circuit may be operably configured to generate the intersection capacity data for each permitted movement by receiving a designation of an expected proportion of different vehicles classified in accordance with vehicle size, receiving an expected flow of vehicles of each classification as a function of time, and generating a lane width dimensions sufficient to accommodate the flow of vehicles.
The apparatus may include an intersection design system having an interface operably configured to receive the intersection capacity data.
The processor circuit may be operably configured to receive the intersection capacity data by receiving a data file having fields encoded with values defining the intersection leg identification, lane designation, and lane width dimensions.
The data file may include receiving an extensible markup language (XML) data file.
The lane designation may include data defining at least one of an approach lane and an exit lane for each of the at least two roadways.
The lane designation may include at least one turn designation associated with each of the approach lanes and the exit lanes, the turn designation defining the permitted vehicle movements along each of the lanes.
The intersection capacity data may include speed data associated with each of the permitted vehicle movements, and the processor circuit may be operably configured to apply the intersection design criteria to generate the corner geometry by using a defined turning path criteria of the design criteria to generate a corner geometry for safely accommodating the vehicle speed along the lane.
The processor circuit may be operably configured to generate the intersection capacity data using an intersection capacity analysis system, generate an updated geometric layout in response to receiving operator input defining a change to the intersection, generate updated intersection capacity data including revised data corresponding to the change, and cause the interface to transmit the updated intersection capacity data back to the capacity analysis system.
The processor circuit may be operably configured to receive the intersection design criteria by receiving an operator selection of a traffic intersection template for designing the traffic intersection.
The processor circuit may be operably configured to receive the intersection design criteria by receiving an operator selection of an industry standard intersection design guideline for designing the traffic intersection.
The processor circuit may be operably configured to receive the intersection design criteria by receiving data defining line-of-sight criteria for the traffic intersection.
The processor circuit may be operably configured to receive the intersection design criteria by receiving a designation of a design vehicle for designing the traffic intersection and to apply the intersection design criteria to generate corner geometry by identifying at least one permitted vehicle movement that defines the corner geometry connecting between the roadway segments, generating a turning path of the design vehicle along the identified permitted vehicle movement, generating first vehicle extent locations associated with passage of the design vehicle along the at least one turning path, and generating an outer edge of the intersection area, the outer edge being generally aligned with selected ones of the first vehicle extent locations.
The processor circuit may be operably configured to receive the orientation data by receiving at least two reference lines defining respective orientations of the intersection legs.
The processor circuit may be operably configured to receive the at least two reference lines by receiving a reference line extending in a direction aligned with an intended direction of traffic movement along a corresponding intersection leg and to combine the lane width dimensions and the intersection design criteria by offsetting the lane width dimensions from the reference line to determine the extents of the a roadway segment corresponding to the intersection leg.
The processor circuit may be operably configured to offset the lane width dimensions to accommodate at least one of a median between lanes, a clearance allowance between lanes, a clearance allowance between an edge of the roadway section and a curb defining a physical extent of the roadway, and or a storage bay associated with a lane designated to permit turning of a vehicle.
The processor circuit may be operably configured to apply the intersection design criteria to generate the corner geometry by generating a swept path of a design between the roadway segments, and using the swept path to generate the corner geometry.
The processor circuit may be operably configured to use the swept path to generate the corner geometry by generating a curve that generally conforms to the swept path.
The curve may include one of a simple curve, a 2-centered compound curve, and a 3-centered compound curve.
In accordance with another aspect of the invention there is provided a computer readable medium encoded with codes for directing a processor circuit to display a geometric layout of a traffic intersection. The codes direct the processor circuit to receive intersection capacity data including an identification of a number of intersection legs associated with the traffic intersection, and a lane designation designating a plurality of lanes for accommodating permitted vehicle movements between the intersection legs, each lane having at least one associated permitted vehicle movement. The codes also direct the processor circuit to receive intersection capacity data including lane width dimensions for accommodating an expected vehicular traffic volume associated with permitted vehicle movements on each of the plurality of lanes. The codes further direct the processor circuit to generate a geometric layout of the traffic intersection by receiving orientation data defining respective orientations of each of the intersection legs, receiving intersection design criteria for designing the traffic intersection, and for each intersection leg, combining the lane width dimensions and the intersection design criteria to determine extents of a roadway segment corresponding to the intersection leg. The codes also direct the processor circuit to apply the intersection design criteria to generate corner geometry connecting between the roadway segments, and to generate display signals for causing the geometric layout of the intersection to be displayed on a computer display.
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
In drawings which illustrate embodiments of the invention,
Referring to
Referring to
Referring to
Referring to
The intersection capacity data 170 shown in Table 2 may be generated using an intersection capacity analysis system such as the Highway Capacity Software product (HCS+™) produced by the University of Florida McTrans Center (McTrans). Several other commercially available software products for generating intersection capacity data are also available, and many of these products are capable of providing intersection capacity data in the form of an export data file for receipt at the input 106 of the interface 104. The capacity data 170 in Table 2 may thus be received as a computer readable data file, in which case the interface 104 would be implemented as a file interface. Alternatively, the capacity data 170 may be received as a computer readable signal and the interface 104 may be implemented as a network interface, such as an Ethernet network interface, for example.
A schematic intersection layout in accordance with the capacity data 170 in Table 2 is shown generally at 200 in
Referring back to
Referring back to
Referring to
The intersection design criteria 260 also include a design speed 264 for the design vehicle 262. The design speed 264 may be prescribed by a standards body or may be related to an intended posted speed limit on roadways that are to connect to the intersection. In this embodiment, the design criteria 260 further includes a minimum turning radius 266 for the design vehicle 262 traveling at the design speed 264. The minimum turning radius R may be read from a table of values prescribed by a standards body or may be calculated for the selected or prescribed design vehicle 262 on the basis of the design speed 264. In one embodiment the apparatus 102 may include a database of design vehicles and associated parameters, and the selection of the design vehicle 262 and design speed 264 may be received from an operator at the input 108 of the intersection design apparatus 102 (shown in
In other embodiments, the intersection design criteria may additionally provide specific criteria for corner geometry connecting between roadway segments, such as radii guidelines for a circular arc or a 3-centered compound curve defining the corner geometry.
Referring back to
Referring to
Similarly, an eastbound roadway segment 298 has an extent defined between the second reference line 244 and a line segment 300, which defines roadway portions 302 and 304 that correspond to both the approach lane 216 and the exit lane 222 shown schematically in
In some embodiments a further offset allowance may be added to the widths 176 of the lanes 288 and 290 to provide additional clearance for vehicles using the intersection. Offset allowances, if implemented, may be included in the intersection design criteria received at block 136 or may be received as operator input at the input 108 of the intersection design apparatus 102 (shown in
In the embodiment shown in
Referring back to
Referring to
Referring back to
Advantageously, the process 130 when implemented on the system 100 is able to transform the schematic layout 200 shown in
Referring to
The processor circuit 350 includes a microprocessor 352, a program memory 354, a variable memory 356, a media reader 360, and an input output port (I/O) 362, all of which are in communication with the microprocessor 352.
Program codes for directing the microprocessor 352 to carry out various functions are stored in the program memory 354, which may be implemented as a random access memory (RAM) and/or a hard disk drive (HDD) or other non-volatile storage such as flash memory, or a combination thereof. The program memory 354 includes a first block of program codes 364 for directing the microprocessor 352 to perform operating system functions and a second block of program codes 366 for directing the microprocessor 352 to perform CAD system functions. The program memory 354 also includes a third block of program codes 368 for interacting with the CAD system functions to implement the geometric design apparatus 102 shown in
The CAD system may be provided by causing a computer to execute CAD system software such as the AutoCAD® software application available from Autodesk Inc. of San Rafael, Calif., USA. AutoCAD provides drawing elements such as lines, polylines, circles, arcs, and other complex elements. Customization of AutoCAD is provided through ObjectARX (AutoCAD Runtime Extension), which is an application programming interface (API) that permits access to a class-based model of AutoCAD drawing elements. Customization code may be written in a programming language such as C++, which may be compiled to provide the codes 368 for implementing the intersection geometric design functions. Other CAD systems, such as MicroStation sold by Bentley Systems Inc. of Exton, Pa., USA, provide similar CAD functionality and interfaces for customization. Advantageously, using existing CAD software applications to provide standard CAD functionality allows operators to produce drawing files representing the traffic intersection using a familiar software application.
The program memory 354 also includes a fourth block of program codes 370 for directing the microprocessor 352 to perform capacity analysis functions. In one embodiment the capacity analysis functions may be provided by the HCS+ capacity analysis product.
The media reader 360 facilitates loading program codes into the program memory 354 from a computer readable medium 380, such as a CD ROM disk 382, or a computer readable signal 384, such as may be received over a network such as the internet, for example.
The I/O 362 includes the input 108 for receiving operator input signals from the keyboard 110 and the pointing device 112. The pointing device may be a computer mouse, trackball, or digitizing tablet, or other device operable o produce pointer movement signals. The I/O 362 further includes the output 114 for generating display signals for driving the display 116 and the output 118 for producing printer control signals for driving the printer 120.
The variable memory 356 includes a plurality of storage locations including a capacity data file store 400 for storing an XML file, stores 402-408 for storing LEG data, a store 410 for storing coordinates of orientation lines, a store 412 for storing design criteria, a store 414 for storing geometric layout data, and a store 416 for storing a design vehicle database for storing design vehicle parameters. The variable memory 356 may be implemented as a random access memory (RAM) and/or a hard disk drive (HDD) or other non-volatile storage such as flash memory, or a combination thereof.
Capacity Data File
Block 132 of the process 130 shown in
Referring to
The process begins at 502, which directs the microprocessor 352 to invoke the capacity analysis program codes 370. In this embodiment the capacity analysis system is run on the same processor circuit 350 as the intersection geometric design system, but in other embodiments the capacity analysis system may be run on another processor circuit which is in communication with the processor circuit 350 using a network connection or other data transfer medium such as a memory card, CD ROM, or magnetic disk, for example.
The process 500 then continues at block 504, which directs the capacity analysis system to perform capacity analysis. The capacity analysis may be performed using HCS+, or any other capacity analysis product. In general such products receive input of traffic data and various other operator inputs, and in response generate capacity analysis data for an intersection. The traffic data may include data from a traffic count in the vicinity of an existing or planned intersection.
Block 506 then directs the microprocessor 352 to generate an export data file including the intersection capacity analysis data. Such capacity analysis data generally includes at least the types of data fields listed in Table 1 (
A portion of an exemplary XML capacity data file produced by HCS+ is shown in
The XML file 550 includes data related to a single intersection between a start tag 558 and an end tag 560 (shown in
Referring back to
Block 516 then directs the microprocessor 352 to display an operator interface for displaying intersection capacity data to the operator and receiving operator input. An exemplary operator interface is shown in
The data table 604 also includes a section 620 defining exit lanes for the eastbound leg 606. The XML file 550 does not include a field defining the exit lane, and thus the codes in block 514 direct the microprocessor 352 to include a single exit lane 622 on the eastbound leg 606 that corresponds to the single entry lane 618. This is based on an assumption that since the movement 578 in section 568 defines a “Thru” lane on the westbound leg 608, that there will also be a corresponding exit lane 622 on the eastbound leg 606. Accordingly an exit field 624 in the table 604 is set to “1”.
The data table 604 also includes a section 626 defining lane adjustments. The lane adjustments 626 include a number of fields populated from the XML file 550. For example a “right turn channelized” field 628 is populated from a field 580 in
The data table 604 also includes a section 638 defining entry lane widths. In this case the width of the “Through-left-right” lane 618 is taken from a lane width field 590 in
The data table 604 also includes a section 644 defining exit lane widths. As noted above, the XML file 550 does not include a field defining the exit lane, and thus the codes 514 direct the microprocessor 352 to set an exit lane width field 648 to the same value as the entry lane width in the field 646.
In the embodiment shown, the operator interface 600 further provides an opportunity for the operator to edit values in the table 604 and to add additional values where desired. Such edits will be reflected in the preview 602.
The sections 562, 564, and 568 of the XML file 550 may be similarly processed to populate and store values for the northbound leg 610, the westbound leg 608, and the southbound leg 612 in respective memory blocks 404-408 of the variable memory 356.
The operator interface 600 also includes an “OK” button 642. Block 518 directs the microprocessor 352 to determine whether the OK button 642 has been actuated, in which case block 518 directs the microprocessor 352 to block 520. Block 520 directs the microprocessor 352 to store the values in the data table 604 in the respective blocks 402-408 of the variable memory 356. The process 500 then ends at 522. If at block 518 the “OK” button 642 is not actuated, then block 518 directs the microprocessor 352 to continue receiving operator input at block 516.
In one embodiment the intersection geometric design system is implemented on the AutoCAD platform as described earlier herein. Referring to
Referring back to
Referring to
As disclosed above in connection with
The interface 730 further includes a design vehicle selection control 736 that facilitates operator selection of a design vehicle for the movement. In some cases, the selection of a particular design vehicle for a particular movement such as a right turn is prescribed by design guidelines. In this case the selected design vehicle is a 50 ft semitrailer vehicle (WB-50). Other design vehicles may be selected from a list (not shown) displayed by clicking on a design vehicle button 738.
Referring to
The design vehicles 820 and 822 are defined by a plurality of design vehicle parameters stored in the design vehicle database 416 (shown in
The parameter listing 840 also includes parameters associated with a front axle group, including the number of wheels per axle 854 and a track dimension 852. In this embodiment, the track dimension 852 is the distance between outer edges of the tire tread measured across the axle. Conventionally, track dimensions generally refer to a distance between respective centers of the outer wheel tire tread, but for intersection design the outside of the tire tread is relevant for defining intersection features. Accordingly, when populating the design vehicle database 416, conventional track dimensions are adjusted to correspond to the distance between the outer edges of the tire tread measured across the axle.
The parameter listing 840 also includes parameters associated with a rear axle group, including the number of wheels per axle 858 and a track dimension 856. The parameter listing 840 further includes a number of parts parameter 860, which when set to “1” indicates that the vehicle is an unarticulated vehicle, and for values of “2” or higher indicates that the vehicle articulated. The vehicle 822 is articulated and includes a tractor portion 826 and a trailer portion 828 connected to the tractor portion at a pivot location 830. The parameter listing also includes a pivot location dimension 862, which is referenced to the center of the rear axle group of the tractor 826.
The parameter listing 840 also includes trailer parameters, such as a trailer length parameter 864 and an articulating angle parameter 866. The articulating angle parameter 866 represents is a maximum angle that may exist between a longitudinal centerline of a tractor portion 826 and a longitudinal centerline of a trailer portion 828 when turning the vehicle.
In general, the design vehicle database 416 would stores sets of parameters 840 for a plurality of design vehicles, such as the vehicles 820 and 822. Libraries of various standard design vehicles are implemented in the AutoTURN® software product available from Transoft Solutions Inc. of British Columbia, Canada. The libraries include commonly used design vehicles for different countries and also provide for custom definition of vehicles not available in the standard libraries. Other design vehicles such as a passenger vehicle (P) are commonly used for other aspects of intersection design. For example, a passenger vehicle may be used for the evaluation of site-lines through the intersection.
Referring to
In this embodiment, when generating corner geometry using the swept path of the design vehicle, a bicycle model is used to represent the design vehicle. The use of a bicycle model simplifies computation of coordinate locations along the turning path, thereby providing improved computational efficiency.
Referring to
For any arbitrary location of the bicycle model 900, the design vehicle parameters stored in the design vehicle database 416 may be used to determine corresponding locations of the wheels of the design vehicle. For example, the front left hand wheel 909 of the design vehicle 820 is spaced apart from the front wheel 902 of the bicycle model by half of the track width dimension 852 in a direction perpendicular to the wheelbase 906. Locations of other vehicle extents, such as the right hand rear wheel 908, may be similarly computed using the design vehicle parameters.
For more complex design vehicles such as the design vehicle 822 shown in
A flowchart depicting blocks of code for directing the processor circuit 350 to implement a process for generating the corner geometry from the design vehicle swept path is shown at 950 in
Referring to
Referring back to
Block 954 then directs the microprocessor 352 to compute a minimum turn radius Rmin. In this embodiment the minimum turn radius is computed in accordance with the formula:
where:
The radius Rmin is computed using the values stored in the store 412 of the variable memory 356 and the computed Rmin value is stored in the store 414. Note that for units other than meters and kilometers, the values of the numerical constants in Eqn 1 would have to be modified accordingly.
Block 956 then directs the microprocessor 352 to determine whether the turn radius R0 input by the operator is less then the minimum turn radius Rmin, in which case block 958 directs the microprocessor 352 to write the value of Rmin into the store 414 as the turning radius R0. In other embodiments block 958 may direct the microprocessor 352 to generate a warning signal for displaying a warning to inform the operator that the selected turn radius is not a feasible turn radius. For example, the warning signal may cause an audible tone to be generated and/or causing an operator interface to be displayed to alert the operator. If at block 956 the turn radius R0 input by the operator is not less than the minimum turn radius Rmin the process continues at block 960.
The right turn movement between the westbound roadway portion 310 and the northbound roadway portion 288 in
Block 960 then directs the microprocessor 352 to locate a bicycle model 1008 of the selected design vehicle on the approach portion 1001 of the path 1000 and then to move the bicycle model along the approach path by successive increments of ΔD until a front wheel 1010 of the bicycle model is at a start 1012 of the first transition portion 1002. In this embodiment, the approach portion 1001 is spaced inwardly from the second reference line 244 by a distance corresponding to half of the front axle track the design vehicle, and the further offset Di (712 in
Block 960 also directs the microprocessor 352 to compute vehicle extent locations at each location along the approach portion 1001. Referring back to
Referring back to
The first transition portion 1002 of the turning path 1001 represents a portion of the turn during which a driver of the design vehicle would be turning the steering to cause the vehicle to begin steering through the turn. In this embodiment, the first transition portion 1002 has a generally spiral shape having reducing radius as the bicycle model 1008 moves along the first transition portion.
Block 962 then directs the microprocessor 352 to compute a steering increment Δφ. In this embodiment the steering increment is computed in accordance with the following formulae:
where:
The value of tL may be measured for each design vehicle under driving conditions, or a default value (such as 6 seconds) may be assumed for the design vehicle. The steering increment is then computed from:
where:
In one embodiment the distance increment ΔD is set to 4 inches. The value of the steering increment Δφ is then written to the store 414 of the variable memory 356.
Block 964 then directs the microprocessor 352 to read the value of Δφ from the store 414 and to turn the front wheel of the bicycle model by an angle corresponding to Δφ.
The first transition portion 1002 of the turning path 1001 is shown in greater detail in
Block 966 then directs the microprocessor 352 to compute a value of an instantaneous turn radius Rn (where n=1, 2, 3 . . . ). Computing the first radius R1 involves determining an intersection between lines 1032 and 1034, which each extend perpendicularly outward from the respective front and rear wheels 1010 and 1014, in accordance with the formula:
where n=1 for calculating the radius R1 at the first location 1030, and WB is the wheelbase of the design vehicle, which for the design vehicle 820 is the value 850 of 25.85 ft from the parameter listing 840 in
The Radius R1 defines a center of rotation 1036 for a first movement of the bicycle model 1008 along the first transition portion 1002 from the first location 1030. Block 968 then directs the microprocessor 352 to read the value of ΔD from the store 414 of the variable memory 356 and to move the bicycle model through an arc about the center of rotation 1036 to a second location 1038, such that the front wheel 1010 is displaced by a distance ΔD from the first location.
Block 970 then directs the microprocessor 352 to use the locations of the front and rear wheels 1010 and 1014 of the bicycle model to compute corresponding vehicle extent locations for the design vehicle using the values of design vehicle parameters for the design vehicle read from the design vehicle database 416. The vehicle extent locations are shown at 1016 and 1018 in
The process then continues at block 972, which directs the microprocessor 352 to read the value of R0 (the operator defined turn radius) and to determine whether Rn is less than or equal to R0. If Rn is still greater than R0, block 972 directs the microprocessor 352 to block 974, where n is incremented. Block 974 then directs the microprocessor 352 back to block 964 and the blocks 964 to 972 of the process 950 are repeated. At the repeat of block 964, the front wheel 1010 is turned through a further angle Δφ, and the radius R2 is computed using Eqn 4 with n=2. The radius R2 defines a new center of rotation 1040 for moving the bicycle model 1008 from the second location 1038 to a third location 1042.
It should be noted that in
If at block 972, the radius Rn matches the radius R0 specified by the operator (as is the case for R3), the first transition portion 1002 of the turning path 1001 is completed and the circular arc turning portion commences at a point 1020.
Once the circular arc portion 1004 is reached, the steering angle of the front wheel 1010 is held constant. Referring to
Block 983 then directs the microprocessor 352 to generate a mirrored shape of the first transition portion 1002 for generating a second transition portion 1005. Mirror functions for shapes are generally provided in many CAD systems, and may be applied to produce a target shape that is a mirror image of an input shape. The mirrored shape is then positioned so that a first end of the mirrored curve (corresponding to the point 1020 on the first transition portion) is located tangent to the front wheel 1010.
The process then continues at block 984, which directs the microprocessor 352 to determine whether a second end of the shape of the second transition portion 1005 is parallel to the reference line 242. If the second end is not parallel to the reference line 242 then block 984 directs the microprocessor 352 back to block 980, and blocks 980 to 984 are repeated.
If at block 984, the second end of the second transition portion is parallel to the reference line 242 then the circular arc portion 1004 of the turning path 1001 is completed at a point 1021, and the mirrored shape is correctly positioned and forms the second transition curve 1005. The second transition curve 1005 extends between the points 1021 and 1022, and represents a portion of the turn during which a driver of the design vehicle is turning the steering to cause the vehicle to begin steering out of the turn. In this embodiment, the second transition portion 1005 has a generally spiral shape having increasing radius as the bicycle model 1008 moves along the second transition portion.
Block 986 then directs the microprocessor 352 to move the bicycle model along the second transition portion 1005 and the departure portion 1006 by successive increments of ΔD and to compute vehicle extent locations at each location along the turning path 1000. At each successive increment the steering angle φ is decremented by Δφ, where Δφ is an angle between the current steering angle of the front wheel of the bicycle model 1010 and a line drawn tangent to the turning path 1000 at each successive location. The front wheel of the bicycle model 1008 is then moved to the next successive location located ΔD along the turning path 1000. At each successive location, bock 986 also directs the microprocessor 352 to use the locations of the front and rear wheels 1010 and 1014 of the bicycle model to compute corresponding vehicle extent locations for the design vehicle. Block 986 further directs the microprocessor 352 to write coordinate values of locations of the front and rear wheels 1010 and 1014 along the second transition portion 1005 and the departure portion 1006 and coordinate values of the corresponding vehicle extents of the design vehicle to the store 414 of the variable memory 356. The process 950 then ends at 988.
In other embodiments, the first and/or second transition portions (1002, 1005) of the turning path 1001 may be omitted, thus representing the turning path using only the approach portion 1001, the circular arc turning portion 1004 specified by the operator input radius R0, and the departure portion 1006.
A flowchart depicting blocks of code for directing the processor circuit 350 to implement a process for generating the corner geometry of the intersection in accordance with one embodiment of the invention is shown at 1080 in
Block 1086 then directs the microprocessor 352 to offset the vehicle extent location to generate an offset vehicle extent location 1025, which may be used to define the corner geometry of the roadway portion. In one embodiment, offsetting the vehicle extent locations involves constructing a line joining locations of a previous vehicle extent location and a next vehicle extent location to define a tangent line to the current vehicle extent location. The offset Di is then applied to the current vehicle extent location in a direction perpendicular to the tangent line.
Block 1088 then directs the microprocessor 352 to determine whether the current vehicle extent location is the last vehicle extent location, in which case the process ends at 1092. If at block 1088 the current vehicle extent location is not the last vehicle extent location, then the process continues at block 1090, which directs the microprocessor 352 to read coordinates of the next vehicle extent location from the store 414 of the variable memory 356.
In an alternative embodiment, the offset Di may not be a fixed offset distance but may vary along the vehicle extent locations such that some vehicle extent locations are offset by a greater distance than other vehicle extent locations to generate the outer edges of the intersection. In another alternative embodiment of the process 1080, CAD system functions may provide an offset function for offsetting a curve by a fixed distance, and such a function may be invoked to offset the vehicle extent locations to generate the outer edges of the intersection.
In this embodiment, the process 1080 generates the offset vehicle extent location 1025 including a plurality of locations for defining the corner geometry. Referring back to
In this embodiment where a “triarc” is selected at 702, three radii are available to conform the triarc geometry to the offset design vehicle extents 1025. In other embodiments where a biarc or simple arc is used, there may be a greater deviation between the offset vehicle extents 1025 and the corner geometry defined by the biarc or simple arc. An updated screenshot of the user interface 680 is shown in
Referring back to
Referring to
Referring again to
When one of the endpoints 1024 or 1026 is moved to another location, blocks 140 and 142 of the process 130 of
Advantageously, the intersection geometric design system 100 facilitates generation of a physical geometric layout of an intersection from data provided in a capacity analysis of the intersection. Since capacity analysis, which is concerned primarily with traffic flows trough a schematically represented intersection and geometric design have previously been considered as separate design functions often performed by different people, the system 100 also provide an opportunity for better integration between these two aspects of intersection design.
While specific embodiments of the invention have been described and illustrated, such embodiments should be considered illustrative of the invention only and not as limiting the invention.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/CA2011/000753 | 6/22/2011 | WO | 00 | 12/19/2012 |
Number | Date | Country | |
---|---|---|---|
61357192 | Jun 2010 | US | |
61421685 | Dec 2010 | US |