Merge pull request #400 from asam-ev/396-editorial-changes-from-publi…

…c-review

Implement editorial changes from public review

content/00_preface/introduction.adoc

@@ -30,15 +30,15 @@ Standardization efforts have been made for scenarios and road data using ASAM Op
 
 === The two main chapters of {THIS_STANDARD}
 
-{THIS_STANDARD} is divided into distinct yet complementary chapters enabling a modular approach to implementation. Key to this is the distinction between material and geometry. Based on specific use cases, users of {THIS_STANDARD} can implement the standard for one or both chapters.  At least one of the two chapters shall be implemented to conform with the standard.
+{THIS_STANDARD} is divided into distinct yet complementary chapters enabling a modular approach to implementation. Key to this is the distinction between material and geometry. Based on specific use cases, users of {THIS_STANDARD} can implement the standard for one or both chapters. At least one of the two chapters shall be implemented to conform with the standard.
 
-* xref:08_material/introduction.adoc[*Material*]: This chapter includes definitions and file formats for storing and exchanging material properties. These properties can be physical, such as surface roughness, permittivity, and index of refraction, or measured data, like wavelength and angle-dependent reflectance values. Tools or systems focusing on material properties can implement support for the material chapter. For example: “This tool supports {THIS_STANDARD}: Material”.
+* *Material*, see xref:08_material/introduction.adoc[Section 8, "Material"]: This chapter includes definitions and file formats for storing and exchanging material properties. These properties can be physical, such as surface roughness, permittivity, and index of refraction, or measured data, like wavelength and angle-dependent reflectance values. Tools or systems focusing on material properties can implement support for the material chapter. For example: “This tool supports {THIS_STANDARD}: Material”.
 
-* xref:07_geometry/introduction.adoc[*Geometry*]: This chapter contains structures for different object classes. These structures define uniform node structure, naming scheme and coordinate systems to enable exchange, common integration and animation of 3D models. Tools or systems working primarily with geometric data, such as 3D models or spatial structures, can implement support for the geometry chapter. For example: “This tool supports {THIS_STANDARD}: Geometry”.
+* *Geometry*, see xref:07_geometry/introduction.adoc[Section 7, "Geometry"]: This chapter contains structures for different object classes. These structures define uniform node structure, naming scheme and coordinate systems to enable exchange, common integration and animation of 3D models. Tools or systems working primarily with geometric data, such as 3D models or spatial structures, can implement support for the geometry chapter. For example: “This tool supports {THIS_STANDARD}: Geometry”.
 
 For a full exchange of simulation-ready _3D assets_ however, both chapters must be supported. Systems or tools providing full support for both material and geometric data can be described as follows: “This tool supports {THIS_STANDARD}”.
 
-A list of use cases examples can be found in the xref:06_use_cases/use-cases.adoc[Use Cases] chapter, each highlighting its relevance to the material chapter, the geometry chapter, or both.
+A list of use cases examples can be found in xref:06_use_cases/use-cases.adoc[], each highlighting its relevance to the material chapter, the geometry chapter, or both.
 
 === Structure and file formats
 
@@ -70,7 +70,7 @@ Multiple formats can exist in parallel, so one asset file can have multiple _3D
 However, to be compliant with {THIS_STANDARD}, a simulation environment must support at least one of the named 3D data formats.
 3D data files may contain conventional materials, supporting visual rendering.
 These materials are unaffected by {THIS_STANDARD} and may still be used in parallel.
-In the overview image above, the 3D Data File has the exemplary materials "asphalt", "concrete" and "texture".
+<<fig-openmaterial-overview>> shows that the 3D data file has the exemplary materials "asphalt", "concrete", and "texture".
 The "texture" material has the visual texture of a stop sign.
 All these materials are purely visual materials embedded in the 3D data file.
 They may be used by conventional rendering systems.
@@ -87,9 +87,9 @@ The table also includes a human-readable description of the material.
 This setup therefore allows for two mapping possibilities:
 
 * Mapping one _material property_ file per _material_ name in the _3D model_.
-  In the overview image above, the material "asphalt" is mapped to a _material property_ file "asphalt.xomp".
+  In <<fig-openmaterial-overview>>, the material "asphalt" is mapped to a _material property_ file "asphalt.xomp".
 * Mapping an RGB color code from a dedicated {THIS_STANDARD} assignment texture to a _material property_ file, enabling detailed differentiation between _material properties_.
-  In the overview image above, the material "texture" belonging to the "Road sign" has a visual texture of a stop sign.
+  In <<fig-openmaterial-overview>>, the material "texture" belonging to the "Road sign" has a visual texture of a stop sign.
   The asset file of the 3D asset allows to define dedicated assignment textures for each material.
   They use the same uv-map as the visual textures.
   The RGB values of the texels in the assignment texture can be mapped to _material property_ files.
@@ -105,17 +105,17 @@ Some material properties depend on other simulation quantities, such as waveleng
 To avoid overloading one material file with large look-up tables, these are placed in auxiliary look-up table files linked with URIs in the main _material property_ file. 
 The defined look-up tables include:
 
-* xref:08_material/material-emp-schema.adoc[Electromagnetic properties]
-* xref:08_material/material-optical-schema.adoc[Optical properties]
-* xref:08_material/material-brdf-schema.adoc[Bidirectional reflectance distribution functions (BRDFs)]
-* xref:08_material/material-reflectance-schema.adoc[Reflectance table]
+* Electromagnetic properties, see xref:08_material/material-emp-schema.adoc[]
+* Optical properties, see xref:08_material/material-optical-schema.adoc[]
+* Bidirectional reflectance distribution functions (BRDFs), see xref:08_material/material-brdf-schema.adoc[]
+* Reflectance table, see xref:08_material/material-reflectance-schema.adoc[]
 
 Examples for _material property_ files and look-up table files are provided in the https://github.com/asam-ev/OpenMATERIAL-3D/tree/main/examples/[examples folder] of the repository.
 
 == Interaction with other ASAM standards
 
 ASAM OpenX standards strive to provide comprehensive, realistic, and exchangeable simulation data for the development and testing of autonomous systems.
-{THIS_STANDARD} asset files and 3D objects defined in the xref:07_geometry/introduction.adoc[Geometry] chapter act as a connecting link between {THIS_STANDARD} and the ASAM OpenX ecosystem.
+{THIS_STANDARD} asset files and 3D objects, as defined in xref:07_geometry/introduction.adoc[Section 7.1, "Geometry-Introduction"], act as a connecting link between {THIS_STANDARD} and the ASAM OpenX ecosystem.
 Specifically, asset files are referenced from other ASAM OpenX standards to integrate and use 3D objects, their metadata and materials:
 
 * ASAM OpenDRIVE standardizes the description of road networks, including geometric definitions of the road, but primarily focuses on the semantic description of the road. 
@@ -129,7 +129,7 @@ Specifically, asset files are referenced from other ASAM OpenX standards to inte
   The paths to 3D assets specified in the _scenario_ definition shall serve as single source of truth and be used consistently in simulation environments.
   In the case of distributed simulation environments, the paths shall be synchronized between all relevant simulation components.
   Synchronization may be implemented using ASAM Open Simulation Interface (OSI).
-* ASAM Open Simulation Interface is a specification for interfaces between models and components in a distributed simulation.
+* ASAM OSI (Open Simulation Interface) is a specification for interfaces between models and components in a distributed simulation.
   ASAM OSI primarily focuses on the environmental perception of automated driving functions, but it also covers interfaces for models of traffic participants.
   So called *model_references* in OSI enable enrichment of the object-list based environment representations by referencing 3D objects defined by {THIS_STANDARD}:
   The asset file (.xoma) of a _3D environment_ shall be linked in ASAM OSI using the https://opensimulationinterface.github.io/osi-antora-generator/asamosi/current/gen/structosi3_1_1GroundTruth.html#a83042861723a4a9e890a53aa98d88858[GroundTruth::model_reference].
@@ -139,7 +139,7 @@ Specifically, asset files are referenced from other ASAM OpenX standards to inte
   As ASAM OSI transfers the data between tools and simulation models, the root path that a relative model reference path is relative to, has to be given or known to all tools and models in the tool chain.
   This can be done with tool settings, configs, or model parameters, for example, an functional mock-up interface (FMI) parameter.
 
-The transformation of reference frames between these ASAM standards is described in xref:07_geometry/general.adoc#_local_coordinate_system[Geometry - Local coordinate system].
+The transformation of reference frames between these ASAM standards is described in xref:07_geometry/general.adoc#_local_coordinate_system[Section 7.2.2.2, "Local coordinate system"].
 
 Examples for all interactions are provided in the https://github.com/asam-ev/OpenMATERIAL-3D/tree/main/examples/scenario_example[scenario_example folder].
 

content/02_normative_references/normative-references.adoc

@@ -15,11 +15,10 @@ Standards referenced in this section shall be cited normatively in the text.
 
 * {GLO_VAR_STA_ASAM_OpenCRG} cite:[ocr]
 * ASAM OpenSCENARIO XML cite:[osc]
-* ISO 3166-1 cite:[iso3166-1]
-* ISO 3166-2 cite:[iso3166-2]
+* ASAM OpenLABEL cite:[ola]
+* ASAM OpenDRIVE cite:[odr]
+* ASAM OSI cite:[osi]
+* FMI cite:[fmi]
 * ISO 8855 cite:[iso8855]
 * ISO 8601 cite:[iso8601]
-* ISO 19111 cite:[iso19111]
-* OMG® UML 2.5.1 cite:[omguml]
-* W3C XML cite:[w3cxml]
-* W3C XML Schema cite:[w3cxmlschema]
+* OGC CDB cite:[ogc]

content/05_terms_and_definitions/terms-and-definitions.adoc

@@ -28,9 +28,8 @@ co-simulation platform handles the timing, synchronization, and data transfer be
 individual models.
 
 [[sec-Electromagnetic-property]] Electromagnetic property::
-Denotes a characteristic of an object or material when interacting with electric and magnetic fields.
-+
-Examples: conduction, magnetization, polarization.
+Denotes a characteristic of an object or material when interacting with electric and magnetic fields. +
+*Examples*: conduction, magnetization, polarization.
 
 [[sec-Ground-truth]] Ground truth::
 Defines true static and dynamic states of objects. The true states are either
@@ -40,9 +39,7 @@ example, a simulation platform.
 [[sec-Machine-perception]] Machine perception::
 The ability of systems to interpret sensory data and to reliably detect objects
 and other road users relevant to the operation of automated driving. The data is
-used to generate situational awareness of the vehicle environment.
-+
-Source: Klaus Dietmayer, Predicting of Machine Perception for Automated Driving, 2016
+used to generate situational awareness of the vehicle environment cite:[die]. 
 
 [[sec-Material]] Material::
 A collection of material properties belonging to one entity.
@@ -63,32 +60,28 @@ A file in JSON format containing defined material properties according to the
 Denotes a physical, chemical, or geometric property of a material.
 
 [[sec-Multispectral_hyperspectral-material]] Multispectral or hyperspectral material::
-Material with wavelength-specific properties that are defined for multiple spectra. 
-+
-Multispectral material shows up in imagery as 3-10 wider bands.
-+
+Material with wavelength-specific properties that are defined for multiple spectra. +
+Multispectral material shows up in imagery as 3-10 wider bands. +
 Hyperspectral material shows hundreds of narrow bands. 
 
 [[sec-Object]] Object::
 A tangible thing with defined 3D boundaries and discrete meshes. An object ID can be assigned.
 In the JSON schemas, the term _object_ also refers to the JSON data type.
-This is not to be confused with a 3D object, but it is clearly marked as "Type: `object`" in the schemas.
+This is not to be confused with a 3D object, but it is clearly marked as type: `object` in the schemas.
 
 [[sec-Object-part]] Object part::
 A segment of an object that has distinct characteristics, for example, material,
-shape, or function.
-+
-Example: A car door differs from the rest of the vehicle due to its function
+shape, or function. +
+*Example*: A car door differs from the rest of the vehicle due to its function
 to open and close.
 
 [[sec-Object-type]] Object type::
 Class of objects with the same set of properties. Each instance of the class is
 described by the same properties, but has individual property values.
 
 [[sec-Physical-property]] Physical property::
-Denotes a characteristic of an object or material that can be measured.
-+
-Examples: permittivity, density, index of refraction.
+Denotes a characteristic of an object or material that can be measured. +
+*Examples*: permittivity, density, index of refraction.
 
 [[sec-Post-rendering-effect]] Post rendering effect::
 Visual modification applied to graphics after initial rendering, enhancing
@@ -98,15 +91,11 @@ appearance or realism without impairing performance.
 A description of the behavior or temporal evolution of physical objects and
 environmental conditions on the driving infrastructure over an interval of time,
 including the movement of traffic participants or the change of environmental
-conditions.
-+
-Source: ASAM OpenSCENARIO XML v1.3.0 standard, 2024
+conditions cite:[osc].
 
 [[sec-Signal-energy-propagation]] Signal energy propagation::
 The act of a signal traveling through the environment and potentially
-interacting with objects and particles.
-+
-Source: Linnhoff et al., Towards Serious Perception Sensor Simulation for Safety Validation of Automated Driving - A Collaborative Method to Specify Sensor Models, 2021
+interacting with objects and particles cite:[lin].
 
 [[sec-Simulation-platform]] Simulation platform::
 Application that orchestrates and runs the simulations. It can be either an

content/06_use_cases/use-cases.adoc

@@ -28,7 +28,7 @@ This clear organization helps users understand the practical applications of {TH
 |===
 |*Description*                      |As a content creator, I want to create _3D assets_ for perception sensor simulation in a standardized format. The assets shall be linked to _material properties_.
 |*Relevant OpenMATERIAL 3D chapters*|Geometry and Material
-|*Influencing standards*            |OGC CDB
+|*Influencing standards*            |OGC CDB cite:[ogc]
 |*Influencing technologies*         |3D Modeling (for example, 3dsMax and Maya), 3D Engine (for example, Unreal Engine)
 |*Relevant user*                    |Content creator
 |===
@@ -69,7 +69,7 @@ To distribute material data and _3D assets_ efficiently, it shall be possible to
 |===
 |*Description*                      |As a sensor model developer, I want to import _3D assets_ that are packaged as FMUs into sensor models.
 |*Relevant OpenMATERIAL 3D chapters*|Geometry and Material
-|*Influencing standards*            |FMI, ASAM OSI (OSMP), ASAM OpenLABEL, ASAM OpenDRIVE, ASAM OpenSCENARIO
+|*Influencing standards*            |FMI cite:[fmi], ASAM OSI (OSMP) cite:[osi], ASAM OpenLABEL cite:[ola], ASAM OpenDRIVE cite:[odr], ASAM OpenSCENARIO cite:[osc]
 |*Influencing technologies*         |Unreal Engine, Unity, OptiX, CUDA
 |*Relevant user*                    |Sensor model developer
 |===
@@ -89,7 +89,7 @@ To distribute material data and _3D assets_ efficiently, it shall be possible to
 |===
 |*Description*                      |As a simulation platform developer, I want to be able to add or change _material properties_ independently of _3D assets_ geometries in a _simulation platform_.
 |*Relevant OpenMATERIAL 3D chapters*|Material
-|*Influencing standards*            |ASAM OpenLABEL
+|*Influencing standards*            |ASAM OpenLABEL cite:[ola]
 |*Influencing technologies*         |Unreal Engine, Unity, OptiX, CUDA
 |*Relevant user*                    |Simulation platform developer
 |===
@@ -99,7 +99,7 @@ To distribute material data and _3D assets_ efficiently, it shall be possible to
 |===
 |*Description*                      |As a _simulation platform_ or sensor model developer, I want to move _objects_ as well as individual parts of the _objects_ during simulation runtime. These can be parts of a vehicle, for example, wheels and doors or the skeleton bones of a pedestrian. One option to manipulate the imported _3D assets_ during simulation runtime is using ASAM OSI. In the https://opensimulationinterface.github.io/osi-antora-generator/asamosi/V3.6.0/gen/structosi3_1_1GroundTruth.html[osi3::GroundTruth] message, information about moving and stationary _objects_ is provided from the _scenario_ engine to the sensor model. This entails _object_ positions, orientations, speeds and so on for every simulation time step, but also a so-called model reference. This reference is the path to a _3D asset_ associated with the _object_ or the stationary environment. Using the pose information together with the 3D mesh data, a _3D environment_ is constructed and updated for every simulation time step. Further attributes, such as https://opensimulationinterface.github.io/osi-antora-generator/asamosi/V3.6.0/gen/structosi3_1_1MovingObject_1_1VehicleAttributes_1_1WheelData.html[wheel positions] for vehicles or https://opensimulationinterface.github.io/osi-antora-generator/asamosi/V3.6.0/gen/structosi3_1_1MovingObject_1_1PedestrianAttributes_1_1Bone.html[bone poses] for pedestrians, enable a more refined movement of traffic participants in the _3D environment_.
 |*Relevant OpenMATERIAL 3D chapters*|Geometry
-|*Influencing standards*            |ASAM OSI
+|*Influencing standards*            |ASAM OSI cite:[osi]
 |*Influencing technologies*         |-
 |*Relevant user*                    |Simulation platform developer
 |===
@@ -120,7 +120,7 @@ The simulation shall be able to cope with different real-time requirements, for
 |===
 |*Description*                      |As a perception algorithm developer, I want to use simulated environments for model training and testing, as real-world information collection is too expensive and inconvenient.
 |*Relevant OpenMATERIAL 3D chapters*|Geometry and Material
-|*Influencing standards*            |ASAM OSI, ASAM OpenSCENARIO, ASAM OpenDRIVE
+|*Influencing standards*            |ASAM OSI cite:[osi], ASAM OpenSCENARIO cite:[osc], ASAM OpenDRIVE cite:[odr]
 |*Influencing technologies*         |Unity, OptiX, Regeneration AI
 |*Relevant user*                    |End user
 |===

content/07_geometry/file-format-support.adoc

@@ -19,7 +19,7 @@ Both delivery options are supported in {THIS_STANDARD}.
 +
 The glTF coordinate system is right-handed, with +Y as the up axis, +Z as forward, and -X as right. The front of a glTF asset faces +Z. 
 +
-This setup differs from how coordinate systems are defined in {THIS_STANDARD}, see xref:07_geometry/general.adoc#_coordinate_systems[Coordinate systems].
+This setup differs from how coordinate systems are defined in {THIS_STANDARD}, see xref:07_geometry/general.adoc#_coordinate_systems[Section 7.2.2, "Coordinate systems"].
 While modeling, the {THIS_STANDARD} coordinate definitions shall be used.
 During export to and import from glTF, a coordinate transformation shall be applied to conform with the glTF specification.
 Common modeling tools like Blender handle this conversion automatically.