update docu

docs/cr2l2.md

@@ -30,7 +30,7 @@ This code of this conversion take some points into account:
 
 To get a better understanding of the conversion process, a flowchart of the function that transforms the lanelet
 (CommonRoad format) to the WayRelation (Lanelet2/OSM format) is given below:
-![l2flowchart](assets/lanelet2/Lanelet_to_way_rel_FLOWCHART.png)
+![](assets/lanelet2/Lanelet_to_way_rel_FLOWCHART.png)
 
 The function takes a lanelet as an input and creates nodes based on those lanelet's vertices.
 As the nodes form right and left ways, the function checks if those ways already exist.

docs/l22cr.md

@@ -34,12 +34,22 @@ A few comments on the conversion:
 dictionaries are used which save the node-lanelet relation, e.g.,
 "Node is first left node of which lanelet" (first_left_nodes[node_id] = lanelet_id).
 - Same for lanelet predecessor relationship.
-- If lanelets in OSM share a common way, they are adjacent to each other. As a way can have only one direction, and if it is shared by lanelets having opposite driving directions, the vertices of one boundary of one of the two lanelet have to be reversed after conversion. This boundary is by default the left boundary considering the right-driving system in most of the world. You can set it to right by using the argument "left_driving_system=True" when calling the Converter.
-- Lanelets can be adjacent without sharing a common way, because two ways can describe the same trajectory, but with a different number of nodes. This converter can still compare two vertices which resulted from converting two possible adjacent ways to the CommonRoad lanelet format and determine if the corresponding lanelets are adjacent. However, this is computationally quite intensive and is thus disabled by default (enable it with "--adjacencies" in the command line tool or setting "detect_adjacencies=True" when calling the converter.)
+- If lanelets in OSM share a common way, they are adjacent to each other.
+As a way can have only one direction, and if it is shared by lanelets having opposite driving directions,
+the vertices of one boundary of one of the two lanelet have to be reversed after conversion.
+This boundary is by default the left boundary considering the right-driving system in most of the world.
+You can set it to right by using the argument "left_driving_system=True" when calling the Converter.
+- Lanelets can be adjacent without sharing a common way, because two ways can describe the same trajectory,
+but with a different number of nodes.
+This converter can still compare two vertices which resulted from converting two possible adjacent ways
+to the CommonRoad lanelet format and determine if the corresponding lanelets are adjacent.
+However, this is computationally quite intensive and is thus disabled by
+default (enable it with "--adjacencies" in the command line tool or setting "detect_adjacencies=True"
+when calling the converter.)
 
 To get a better understanding of the conversion process, a flowchart of the function that
 transforms the WayRelation (Lanelet2/OSM format) to the Lanelet (CommonRoad format) is given below:
-![l2flowchart](assets/lanelet2/Way_rel_to_lanelet_FLOWCHART.png)
+![](assets/lanelet2/Way_rel_to_lanelet_FLOWCHART.png)
 
 Both left and right ways of the WayRelation object have to be of the same size.
 If not, the function tries to fix the issue by resizing one of the ways, raising an error in case of a failure.

docs/odr2cr.md

@@ -30,9 +30,25 @@ conversion from parametric lanes to lanelets is explained.
 
 The three main types of formats are:
 
-- `OpenDRIVE format`: In OpenDRIVE, roads are specified based on a reference path. Individual lanes are created by specifying a lateral distance from a reference path. Lanes with a negative lane number (ID) have the same direction as the reference path and positive IDs indicate that the direction is opposite.
-- `Lanelet format`: Lanelets are atomic, interconnected, and drivable road segments. A lanelet is defined by its left and right bound, where each bound is represented by an array of points.Two lanelets are called longitudinally adjacent, if the left and right start points of one lanelet are identical with the corresponding final points of the next lanelet in driving direction. The longitudinal, left, right, and empty adjacencies form a road network that can be modeled as a directed graph.
-- `Parametric lanes`: In OpenDRIVE, lanes are merged by gradually reducing their width to zero or split by gradually increasing the width from zero. In a lanelet network, the end points have to coincide with starting points of another lanelet so that splitting and merging is realized. To conveniently perform the conversion of merging and splitting, the concept of parametric lanes is used. These eliminate the dependency of each lane on its inner neighbor by specifying the borders with respect to the reference path. The following parameters are required for parametric lanes: 1 ) offset specifying distance from the beginning of the reference path of the considered section, 2) path length of the parametric lane, 3) inner and outer borders specified as distances to the reference path varying along the reference path.
+- `OpenDRIVE format`: In OpenDRIVE, roads are specified based on a reference path.
+Individual lanes are created by specifying a lateral distance from a reference path.
+Lanes with a negative lane number (ID) have the same direction as the reference path and positive IDs
+indicate that the direction is opposite.
+- `Lanelet format`: Lanelets are atomic, interconnected, and drivable road segments.
+A lanelet is defined by its left and right bound, where each bound is represented by an array of points.
+Two lanelets are called longitudinally adjacent, if the left and right start points of one lanelet are identical
+with the corresponding final points of the next lanelet in driving direction.
+The longitudinal, left, right, and empty adjacencies form a road network that can be modeled as a directed graph.
+- `Parametric lanes`: In OpenDRIVE, lanes are merged by gradually reducing their width to zero or
+split by gradually increasing the width from zero.
+In a lanelet network, the end points have to coincide with starting points of another
+lanelet so that splitting and merging is realized.
+To conveniently perform the conversion of merging and splitting, the concept of parametric lanes is used.
+These eliminate the dependency of each lane on its inner neighbor by specifying the borders with respect
+to the reference path. The following parameters are required for parametric lanes:
+  1) offset specifying distance from the beginning of the reference path of the considered section,
+  2) path length of the parametric lane,
+  3) inner and outer borders specified as distances to the reference path varying along the reference path.
 
 ### Code Structure
 Subsequently, we provide a simplified overview about the code structure (the presented code
@@ -52,16 +68,25 @@ structure is not complete)::
         └── conversion_lanelet_network.py
 
 - `/opendriveparser`: All files to parse the open drive xodr files.
-- `/elements`: This directory contains various tools and files that are used throughout all stages of parsing and initiation of various commonroad objects.
+- `/elements`: This directory contains various tools and files that are used throughout all stages of parsing
+and initiation of various commonroad objects.
 - `parser.py`: Parses XML tree, returns OpenDRIVE object, parse road type, profiles and signals and append to road object.
 - `/opendriveconversion`: All files to convert the parsed open drive objects to a CommonRoad scenario.
-- `/plane_elements`: This directory contains various tools and files used to define CommonRoad objects such as border, geo reference, parametric lanes, and traffic signals.
-- `converter.py`: Module for the logic behind converting OpenDRIVE to ParametricLanes which includes converting from lane_sections to parametric_lanes, determine_neighbours of lanes and creating outer lane border.
-- `network.py`: Module to contain network which can load an opendrive object and then export to lanelets. Internally, the road network is represented by ParametricLanes with a LinkIndex which stores the neighbor relations between the parametric lanes which are essentially index of all links in the file and saves everything as successors and predecessors.
-- `conversion_lanelet.py`: Module to enhance lanelet class with helper functions for access/manipulation of various objects especially lanelet_ids, borders, width of lanes (s_pos), concatenate lanes, and adjacent lanes so it can be used for conversion from the opendrive format.
-- `conversion_lanelet_network.py`: Module to enhance LaneletNetwork class so it can be used for conversion from the OpenDRIVE format and further enable it to modify its lanelets.
-
-![l2flowchart](assets/opendrive/opendrive_flow_chart.png)
+- `/plane_elements`: This directory contains various tools and files used to define CommonRoad objects such as border,
+geo reference, parametric lanes, and traffic signals.
+- `converter.py`: Module for the logic behind converting OpenDRIVE to ParametricLanes which includes converting
+from lane_sections to parametric_lanes, determine_neighbours of lanes and creating outer lane border.
+- `network.py`: Module to contain network which can load an opendrive object and then export to lanelets.
+Internally, the road network is represented by ParametricLanes with a LinkIndex which stores the neighbor
+relations between the parametric lanes which are essentially index of all links in the file and saves everything
+as successors and predecessors.
+- `conversion_lanelet.py`: Module to enhance lanelet class with helper functions for access/manipulation
+of various objects especially lanelet_ids, borders, width of lanes (s_pos), concatenate lanes,
+and adjacent lanes so it can be used for conversion from the opendrive format.
+- `conversion_lanelet_network.py`: Module to enhance LaneletNetwork class so it can be used for conversion
+from the OpenDRIVE format and further enable it to modify its lanelets.
+
+![](assets/opendrive/opendrive_flow_chart.png)
 
 ### Parsing OpenDRIVE
 Parsing the OpenDRIVE xodr file is straightforward. We mirror the OpenDRIVE document
@@ -78,8 +103,11 @@ starts, as a Border can be used by multiple ParametricLanes.
 Calculating Cartesian coordinates at a position on a border works as follows:
 
 - The border has a reference border which calculates its coordinates.
-- The border has one or more tuples of width coefficients. With the width coefficients which apply at the position (determined by a width coefficients offset), it calculates the width of its reference border.
-- The width is added to the coordinates of the reference border in orthogonal direction, which results in coordinates of the border at a specific position.
+- The border has one or more tuples of width coefficients.
+With the width coefficients which apply at the position (determined by a width coefficients offset),
+it calculates the width of its reference border.
+- The width is added to the coordinates of the reference border in orthogonal direction,
+which results in coordinates of the border at a specific position.
 
 The position on a border is always specified in a curve parameter ds which follows the path of the border.
 Each reference border is a border again, until the last reference border, which in turn is a reference path,