More spelling fixes

Signed-off-by: ClemensLinnhoff <clemens.linnhoff@partner.bmw.de>

Author: ClemensLinnhoff

.github/spelling_custom_words_en_US.txt

@@ -28,13 +28,13 @@ befahrbar
 befahren
 Begriffe
 bei
-Beleuchtung
+beleuchtung
 Benrath
 Bereich
 berholt
 Besondere
 Bewohner
-bgbl
+BGBl
 bggr
 Biblio
 bicyclesback
@@ -68,6 +68,7 @@ courtneystrong
 Crabb
 css
 customizable
+dataset
 daytimes
 dBm
 de
@@ -97,6 +98,7 @@ Einheiten
 Elektrotechnik
 ellpadding
 Elsevier
+Encyclopaedia
 endcode
 Ende
 Endeninch
@@ -173,6 +175,7 @@ incrementing
 Industriegebiet
 innerhalb
 Institut
+interoperable
 Intl
 io
 IRI
@@ -234,13 +237,16 @@ ONEWAY
 onlinepubs
 ONRAMP
 opengroup
+opendrive
+openscenario
 optischen
 Ordnung
 osi
 osmp
 Ouml
 ouml
 parametrization
+parametrize
 Parkausweis
 Parken
 Parkfl
@@ -264,6 +270,7 @@ publikationen
 pubrec
 px
 QLTkit
+radiocommunication
 Rauch
 rbd
 rcs
@@ -309,12 +316,15 @@ Strassenfahrzeuge
 Strassenverkehrs
 strassenverkehrsordnung
 StVO
+stvo
 StVZO
 subtype
 subtypes
+superelevation
 svg
 szlig
 Tait
+TBD
 td
 tf
 tf

osi_common.proto

@@ -204,7 +204,7 @@ message Orientation3d
 //
 message Identifier
 {
-    // The identifier's value.
+    // The value of the identifier.
     //
     // \rules
     // is_greater_than_or_equal_to: 0

osi_environment.proto

@@ -40,7 +40,7 @@ message EnvironmentalConditions
     // sorted by languages](https://www.epochconverter.com/#code).
     //
     // \par References:
-    // [1] ITU Radiocommunication Assembly. (2002). <em>Recommondation  ITU-R  TF.460-6 Standard-frequency and time-signal emissions</em>. (Rec.  ITU-R  TF.460-6). Retrieved January 25, 2020, from http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf \n
+    // [1] ITU Radiocommunication Assembly. (2002). <em>Recommendation  ITU-R  TF.460-6 Standard-frequency and time-signal emissions</em>. (Rec.  ITU-R  TF.460-6). Retrieved January 25, 2020, from http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf \n
     // [2] The Open Group. (2018). <em>POSIX.1-2017</em> The Open Group Base Specifications Issue 7, 2018 edition. IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008). Retrieved January 25, 2020, from https://pubs.opengroup.org/onlinepubs/9699919799/xrat/contents.html
     //
     optional int64 unix_timestamp = 8;
@@ -176,7 +176,7 @@ message EnvironmentalConditions
     // \par References:
     // [1] Shepard, F. D. (1996). <em>Reduced visibility due to fog on the highway.</em> Transportation Research Board, National Research Council (Ed.). National Academy Press. Washington, D.C., USA. ISBN 0-309-06006-0. \n
     // [2] Strassenverkehrs-Ordnung (StVO) as of dated  March 06, 2013 (BGBl. I S. 367), lastly changed by article 4a of the order from June 06, 2019 (BGBl. I S. 756). \n
-    // [3] stvo.de. (2013, April 01). <em>StVO Par. 17 Beleuchtung</em>. Retrieved January 25, 2020, from https://www.stvo.de/strassenverkehrsordnung/101-17-beleuchtung \n
+    // [3] StVO.de. (2013, April 01). <em>StVO Par. 17 Beleuchtung</em>. Retrieved January 25, 2020, from https://www.StVO.de/strassenverkehrsordnung/101-17-beleuchtung \n
     // [4] Meteorological Office UK. (2020). <em>Homepage of the Meteorological Office - How we measure visibility</em>. Retrieved January 25, 2020, from http://www.metoffice.gov.uk/guide/weather/observations-guide/how-we-measure-visibility
     //
     enum Fog
@@ -358,7 +358,7 @@ message EnvironmentalConditions
         // 8 oktas means that the sky is completely covered with clouds and no sky blue can be recognized.
         //
         // \par References:
-        // [1] CIE engl. International Commission on Illumination. (2020). <em>CIE S017:2020 ILV: Intl. Lighitng Vocabulary, 2nd edn.</em>. Retrieved March 8, 2022, from https://cie.co.at/eilvterm/17-29-116 \n
+        // [1] CIE engl. International Commission on Illumination. (2020). <em>CIE S017:2020 ILV: Intl. Lighting Vocabulary, 2nd edn.</em>. Retrieved March 8, 2022, from https://cie.co.at/eilvterm/17-29-116 \n
         // [2] UBC The University of British Columbia. (2018). <em>ATSC 113 Weather for Sailing, Flying & Snow Sports</em>. Retrieved March 8, 2022, from https://www.eoas.ubc.ca/courses/atsc113/flying/met_concepts/01-met_concepts/01c-cloud_coverage/index.html
         //
         enum FractionalCloudCover

osi_featuredata.proto

@@ -222,7 +222,7 @@ message SensorDetectionHeader
         //
         EXTENDED_QUALIFIER_INPUT_NOT_AVAILABLE = 9;
 
-        // Internal reason (e.g. an internal HW or SW error has occurred).
+        // Internal reason (e.g. an internal hardware or software error has occurred).
         //
         EXTENDED_QUALIFIER_INTERNAL_REASON = 10;
 
@@ -459,7 +459,7 @@ message LidarDetection
     // \endrules
     //
     // \par Reference:
-    // [1] Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. (2020). <em>Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving</em> Automot. Engine Technol. 5, Fig 7, Fig 8. Retrieved May 10, 2021, from https://doi.org/10.1007/s41104-020-00066-x
+    // [1] Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. (2020). <em>Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving</em> Automotive Engine Technology 5, Fig 7, Fig 8. Retrieved May 10, 2021, from https://doi.org/10.1007/s41104-020-00066-x
     //
     optional double echo_pulse_width = 11;
 
@@ -509,7 +509,7 @@ message UltrasonicDetectionSpecificHeader
 //
 // \image html OSI_USSensor.svg
 //
-// \note Direct detections lie on circles with the sending sensor as centre.
+// \note Direct detections lie on circles with the sending sensor as center.
 //
 message UltrasonicDetectionData
 {
@@ -544,7 +544,7 @@ message UltrasonicDetectionData
 //
 // \image html OSI_USSensor_direct.svg
 //
-// \note Direct detections lie on circles with the sensor as centre.
+// \note Direct detections lie on circles with the sensor as center.
 //
 message UltrasonicDetection
 {

osi_hostvehicledata.proto

@@ -568,7 +568,7 @@ message HostVehicleData
             //
             STATE_OTHER = 1;
 
-            // The function has errored in some way that renders it ineffective.
+            // The function has thrown an error in some way that renders it ineffective.
             //
             STATE_ERRORED = 2;
 

osi_lane.proto

@@ -189,7 +189,7 @@ message Lane
 
         // Indicates that the host vehicle travels on this particular lane.
         // The host vehicle may travel on more than one lane at once. This does
-        // also apply for the \c CanditateLane in the \c DetectedLane .
+        // also apply for the \c CandidateLane in the \c DetectedLane .
         //
         optional bool is_host_vehicle_lane = 2;
 

osi_logicaldetectiondata.proto

@@ -223,7 +223,7 @@ message LogicalDetection
     // \endrules
     //
     // \par Reference:
-    // [1] Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. (2020). <em>Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving</em> Automot. Engine Technol. 5, Fig 7, Fig 8. Retrieved May 10, 2021, from https://doi.org/10.1007/s41104-020-00066-x
+    // [1] Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. (2020). <em>Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving</em> Automotive Engine Technology 5, Fig 7, Fig 8. Retrieved May 10, 2021, from https://doi.org/10.1007/s41104-020-00066-x
     //
     optional double echo_pulse_width = 12;
 }

osi_logicallane.proto

@@ -590,7 +590,7 @@ message LogicalLane
     //
     // Definition of available lane types.
     //
-    // This is mostly aligned with OpenDRIVE, except that lane types modelling
+    // This is mostly aligned with OpenDRIVE, except that lane types modeling
     // access restrictions (e.g. "taxi") are not made available here. These are
     // already deprecated in OpenDRIVE.  To support this, access restrictions
     // should be added later, in alignment with OpenDRIVE.

osi_object.proto

@@ -48,7 +48,7 @@ message StationaryObject
     //
     // For example, to reference an object defined in an OpenDRIVE map
     // the items should be set as follows:
-    // * reference = URI to map, can remain empty if identical with definiton
+    // * reference = URI to map, can remain empty if identical with definition
     //               in \c GroundTruth::map_reference
     // * type = "net.asam.opendrive"
     // * identifier[0] = "object" for t_road_objects_object and
@@ -690,7 +690,7 @@ message MovingObject
             //
             optional string model_reference = 9;
 
-            // The value describes the kinetic friction of the tyre's contact point.
+            // The value describes the kinetic friction of the tire's contact point.
             // If different friction coefficients due to more than one contact points are available,
             // this value contains the average.
             //
@@ -746,14 +746,14 @@ message MovingObject
         // other OpenX standards (in particular, OpenScenario 1.x and 2.x, and OpenLabel).
         // This is primarily for historical reasons.  Where a single type from a
         // different standard can map to multiple OSI types it is left up to the
-        // discretion of the OSI implementor how that mapping is achieved.  For example,
+        // discretion of the OSI implementer how that mapping is achieved.  For example,
         // a simulator may use the dimensions of a provided 3d model of a vehicle with type
         // "car" in OpenScenario, to determine whether it should be a TYPE_SMALL_CAR or
         // TYPE_MEDIUM_CAR in OSI.
         //
         // \note Vehicle type classification is a complex area and there are no
         // universally recognized standards.  As such, the boundaries between some of the
-        // OSI vehicle types are not well-defined.  It is left to the implementor to
+        // OSI vehicle types are not well-defined.  It is left to the implementer to
         // decide how to distinguish between them and agree that with any applications which
         // make use of that specific interface instance.  For example, how to distinguish
         // between a HEAVY_TRUCK and a DELIVERY_VAN, or a TRAILER and a SEMITRAILER.
@@ -853,7 +853,7 @@ message MovingObject
             //
             TYPE_WHEELCHAIR = 15;
 
-            // Vehicle is a stand-up or kickboard scooter, including
+            // Vehicle is a stand-up scooter, including
             // motorized versions.
             //
             TYPE_STANDUP_SCOOTER = 17;

osi_referenceline.proto

@@ -158,12 +158,12 @@ message ReferenceLine
     //   point on the polyline. The resulting ST coordinate uniquely maps back
     //   to \c P1.
     // - \c P2 has multiple points "nearest points" on the polyline.
-    //   As can be seen here, two  ST coordinates map to \c P2 (red and grey
+    //   As can be seen here, two  ST coordinates map to \c P2 (red and gray
     //   dotted line).  Following the rules above, the one with the smallest S
     //   value is chosen (the red dotted line).
     // - \c P3 has a unique "nearest point" on the polyline. However, multiple
     //   points map to the same ST coordinate as that of \c P3, e.g. \c P4
-    //   (drawn in grey).
+    //   (drawn in gray).
     // - Finally, \c P5 shows how the reference line is extended infinitely for
     //   points that are "outside" the reference line.
     //
@@ -269,10 +269,10 @@ message ReferenceLine
     // in OSI. There are a few difficulties with this:
     // - The T coordinate is nearly the same as for OpenDRIVE, but
     //   unfortunately not perfectly. In OpenDRIVE, if the road is tilted using
-    //   superElevation, then the t coordinate system is tilted along, so the T
+    //   superelevation, then the t coordinate system is tilted along, so the T
     //   coordinate is no longer calculated in the XY plane (as proposed for
-    //   OSI). It doesn't seem feasable to implement the same tilting for OSI,
-    //   so simulation tools will have to consider superElevation and convert
+    //   OSI). It doesn't seem feasible to implement the same tilting for OSI,
+    //   so simulation tools will have to consider superelevation and convert
     //   the T coordinate accordingly: <code>t_OSI = t_OpenDRIVE *
     //   cos(alpha)</code>, where alpha is the superelevation angle.
     // - The angle will not be perfectly the same, due to the use of line