.travis.yml

@@ -61,6 +61,8 @@ addons:
         - doxygen-gui
         - graphviz
         - python3-setuptools
+        - python3-pip
+        - python3-wheel
 
 
 jobs:
@@ -78,6 +80,8 @@ jobs:
           - cd ..
           - python3 setup.py build
           - python3 setup.py sdist
+          - python3 -m pip install -U pip
+          - python3 -m pip install .
           - cd build
           - cmake --build . --target install
           - cd ..
@@ -103,6 +107,8 @@ jobs:
           - cd ..
           - python3 setup.py build
           - python3 setup.py sdist
+          - python3 -m pip install -U pip
+          - python3 -m pip install .
           - cd build
           - cmake --build . --target install
           - cd ..
@@ -128,6 +134,8 @@ jobs:
           - cd ..
           - python3 setup.py build
           - python3 setup.py sdist
+          - python3 -m pip install -U pip
+          - python3 -m pip install .
           - cd build
           - cmake --build . --target install
           - cd ..

doc/howtocontribute.rst

@@ -7,7 +7,82 @@ Introduction
 ------------
 
 The purpose of this document is to help contributors get started with
-the Open Simulation Interface (OSI) codebase.
+the ASAM Open Simulation Interface (OSI) codebase.
+
+As an open-source standardisation project, we welcome and encourage the community to submit patches directly to the project. In our collaborative open source environment, standards and methods for submitting changes help reduce the chaos that can result from an active development community.
+
+This document explains how to participate in project conversations, log bugs and enhancement requests, and submit patches to the project so your patch will be accepted quickly in the codebase.
+
+Licensing
+---------
+
+OSI uses the Mozilla Public License, v. 2.0. (as found in the LICENSE file in the project’s GitHub repo).
+
+The license tells you what rights you have as a developer, provided by the copyright holder. It is important that the contributor fully understands the licensing rights and agrees to them. Sometimes the copyright holder isn’t the contributor, such as when the contributor is doing work on behalf of a company.
+
+Developer Certification of Origin (DCO)
+---------------------------------------
+
+To make a good faith effort to ensure licensing criteria are met, the OSI project requires the Developer Certificate of Origin (DCO) process to be followed.
+
+The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, (described more fully later in this document), the developer simply adds a Signed-off-by statement and thereby agrees to the DCO.
+
+When a developer submits a patch, it is a commitment that the contributor has the right to submit the patch per the license. The DCO agreement is shown below and `online <http://developercertificate.org/>`_.
+::
+
+  Developer's Certificate of Origin 1.1
+
+  By making a contribution to this project, I certify that:
+
+  (a) The contribution was created in whole or in part by me and I
+      have the right to submit it under the open source license
+      indicated in the file; or
+
+  (b) The contribution is based upon previous work that, to the
+      best of my knowledge, is covered under an appropriate open
+      source license and I have the right under that license to
+      submit that work with modifications, whether created in whole
+      or in part by me, under the same open source license (unless
+      I am permitted to submit under a different license), as
+      Indicated in the file; or
+
+  (c) The contribution was provided directly to me by some other
+      person who certified (a), (b) or (c) and I have not modified
+      it.
+
+  (d) I understand and agree that this project and the contribution
+      are public and that a record of the contribution (including
+      all personal information I submit with it, including my
+      sign-off) is maintained indefinitely and may be redistributed
+      consistent with this project or the open source license(s)
+      involved.
+
+DCO Sign-Off Methods
+--------------------
+
+The DCO requires a sign-off message in the following format appear on each commit in the pull request:
+::
+
+  Signed-off-by: Firstname Lastname <email@address.com>
+
+The DCO text can either be manually added to your commit body, or you can add either ``-s`` or ``--signoff`` to your usual Git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running ``git commit --amend -s``.  You can add sign-offs to multiple commits (including commits originally authored by others, if you are authorized to do so) using ``git rebase --signoff``. If you’ve pushed your changes to GitHub already you’ll need to force push your branch after this with ``git push --force-with-lease``.
+
+If you want to be reminded to add the sign-off for commits in your repository, you can add the following commit-message git hook to your repository:
+
+.. code:: shell
+
+  #!/bin/sh
+  #
+  # Check for DCO/Signed-off-by in message
+  #
+  
+  if ! grep -q "^Signed-off-by: " "$1"
+  then
+    echo "Aborting commit: Commit message is not signed off" >&2
+    exit 1
+  fi
+
+Placing this script into a file called ``.git/hooks/commit-msg`` and making it executable (e.g. using ``chmod a+x .git/hooks/commit-msg`` on unixoid operating systems) will prevent commits without a sign-off.
 
 
 Reporting issues
@@ -69,7 +144,7 @@ the commits are combined
 into one commit and merged into the master branch.
 Once a pull request is ready, it is reviewed and
 approved, then squashed using the ``--fast-forward`` option of Git in order to
-maintain a streamlined Git history.
+maintain a streamlined Git history. Pull requests without a Sign-Off message (see DCO above) will not be accepted.
 
 **We also enforce a few hygiene rules**:
 

doc/interfaceconventions.rst

@@ -7,7 +7,7 @@ When adding new messages, enums, field messages and field enums to OSI we enforc
 
 Message Naming
 ---------------
-A message definition should always be in camel case. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
+A message definition should always be in PascalCase. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
 
 .. code-block:: protobuf
 
@@ -37,7 +37,7 @@ All messages that are intended to be exchanged as a stand-alone message, i.e. no
 
 Field Message Naming
 ---------------------
-After defining a message fields can be added to it in snake case format. This means every letter is lower case and the words are connected through an underline character. See example below:
+After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
 
 .. code-block:: protobuf
 
@@ -55,7 +55,7 @@ All field numbers of 10000 and above are reserved for user-defined extensions an
 
 Enum Naming
 ------------
-The naming of an enum should be camel case. See example below:
+The naming of an enum should be PascalCase. See example below:
 
 .. code-block:: protobuf
 
@@ -70,7 +70,7 @@ The naming of an enum should be camel case. See example below:
 
 Enum Field Naming
 ------------
-The naming of an enum field should be all in upper case. The start should be converted from the enum name camel case to upper case snake case. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
+The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
 
 .. code-block:: protobuf
 
@@ -92,12 +92,12 @@ Summary
 --------
 Here a small summary for the naming conventions:
 
-Messages: camel case
+Messages: PascalCase
 
-Message Fields: snake case
+Message Fields: snake_case
 
-Enum: camel case
+Enum: PascalCase
 
-Enum Fields: upper case, name of enum converted in upper case snake case and then following the specified name
+Enum Fields: Name of enum converted in UPPER_CASE_SNAKE_CASE and then following the specified name
 
 After defining the messages do not forget to comment them. See also the `section for commenting <https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/commenting.html>`_ of fields and messages.

format/OSITrace.py

@@ -44,6 +44,7 @@ def __init__(self, path=None, type_name="SensorView"):
         self.type_name = type_name
         self.timestep_count = 0
         self.retrieved_scenario_size = 0
+        self._int_length = len(struct.pack("<L", 0))
 
     def from_file(self, path, type_name="SensorView", max_index=-1, format_type=None):
         """Import a scenario from a file"""
@@ -161,19 +162,18 @@ def get_messages_in_index_range(self, begin, end):
         """
         Yield an iterator over messages of indexes between begin and end included.
         """
+        self.scenario_file.seek(self.message_offsets[begin])
+        abs_first_offset = self.message_offsets[begin]
+        abs_last_offset = self.message_offsets[end] \
+            if end < len(self.message_offsets) \
+            else self.retrieved_scenario_size
 
-        if self.format_type == "separated":
-            self.scenario_file.seek(self.message_offsets[begin])
-            abs_first_offset = self.message_offsets[begin]
-            abs_last_offset = self.message_offsets[end] \
-                if end < len(self.message_offsets) \
-                else self.retrieved_scenario_size
-
-            rel_message_offsets = [
-                abs_message_offset - abs_first_offset
-                for abs_message_offset in self.message_offsets[begin:end]
-            ]
+        rel_message_offsets = [
+            abs_message_offset - abs_first_offset
+            for abs_message_offset in self.message_offsets[begin:end]
+        ]
 
+        if self.format_type == "separated":
             message_sequence_len = abs_last_offset - \
                 abs_first_offset - SEPARATOR_LENGTH
             serialized_messages_extract = self.scenario_file.read(
@@ -190,25 +190,26 @@ def get_messages_in_index_range(self, begin, end):
                 yield message
 
         elif self.format_type is None:
-            self.scenario_file.seek(0)
-            serialized_message = self.scenario_file.read()
-            INT_LENGTH = len(struct.pack("<L", 0))
-            message_length = 0
+            message_sequence_len = abs_last_offset - abs_first_offset
+            serialized_messages_extract = self.scenario_file.read(message_sequence_len)
+
+            for rel_index, rel_message_offset in enumerate(rel_message_offsets):
+                rel_begin = rel_message_offset + self._int_length
+                rel_end = (
+                    rel_message_offsets[rel_index + 1]
+                    if rel_index + 1 < len(rel_message_offsets)
+                    else message_sequence_len
+                )
 
-            i = 0
-            while i < len(serialized_message):
                 message = MESSAGES_TYPE[self.type_name]()
-                message_length = struct.unpack("<L", serialized_message[i:INT_LENGTH+i])[0]
-                message.ParseFromString(serialized_message[i+INT_LENGTH:i+INT_LENGTH+message_length])
-                i += message_length + INT_LENGTH
+                serialized_message = serialized_messages_extract[rel_begin:rel_end]
+                message.ParseFromString(serialized_message)
                 yield message
 
         else:
             self.scenario_file.close()
             raise Exception(f"The defined format {self.format_type} does not exist.")
 
-        self.scenario_file.close()
-
     def make_readable(self, name, interval=None, index=None):
         self.scenario_file.seek(0)
         serialized_message = self.scenario_file.read()     
@@ -235,7 +236,7 @@ def make_readable(self, name, interval=None, index=None):
 
             if interval is None and index is not None:
                 if type(index) == int:
-                    f.write(str(scenario.get_message_by_index(0)))
+                    f.write(str(self.get_message_by_index(0)))
                 else:
                     raise Exception("Argument 'index' needs to be of type 'int'")
 

osi_common.proto

@@ -470,9 +470,9 @@ message BaseMoving
 //
 message StatePoint
 {
-    // The timestamp of a StatePoint
+    // The timestamp of a StatePoint.
     //
-    // \note Zero time point does not need to coincide with the UNIX epoch.
+    // \note Zero time does not need to coincide with the UNIX epoch.
     //
     optional Timestamp timestamp = 1;
 

osi_groundtruth.proto

@@ -155,4 +155,20 @@ message GroundTruth
     // \note It is implementation-specific how map_reference is resolved.
     //
     optional string map_reference = 15;
+
+    // Opaque reference of an associated 3D model.
+    //
+    // The model covers the static parts of the environment that are not
+    // provided as individual models referenced from ground truth objects
+    // like moving or stationary objects.
+    //
+    // \note Origin and orientation of the model have to coincide with the
+    // inertial coordinate frame of the ground truth.
+    //
+    // \note It is implementation-specific how model_references are resolved to
+    // 3d models. The parts the world model contains are also implementation-specific.
+    // For example, the world model can wether contain street geometries or
+    // derives street geometies automatically from a map reference.
+    //
+    optional string model_reference = 16;
 }

osi_object.proto

@@ -341,8 +341,8 @@ message MovingObject
     // The trajectory that this moving object expects to follow in the future.
     //
     // This is not externally perceivable information, rather this is to aid
-    // realistic simulation of traffic participants not under test.  This
-    // information should not be made available to the stack under test.
+    // realistic simulation of traffic participants that are not under test.  
+    // This information should not be made available to the stack under test.
     //
     // \note Moving objects are not required to stick to this trajectory, it is
     // indicative, and equivalent to the output of a perception + prediction