diff --git a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.ecschema.xml b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.ecschema.xml
index 959ec4ee4..ee924aa52 100644
--- a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.ecschema.xml
+++ b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.ecschema.xml
@@ -95,14 +95,14 @@
-
+ bis:SpatialLocationElementbis:ISubModeledElement
-
+ bis:SpatialLocationElementbis:ISubModeledElement
@@ -168,4 +168,20 @@
+
+ bis:ViewDefinition2d
+
+
+ bis:Drawing
+
+
+
+
+
+
+
+
+
diff --git a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.remarks.md b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.remarks.md
index affc99bed..5ef26d8b6 100644
--- a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.remarks.md
+++ b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.remarks.md
@@ -12,11 +12,17 @@ Contains the main classes to capture Alignment information primarily used in Roa
### Alignment
-When an `Alignment` drives the design of a linear asset, it is referred to as a *Design Alignment*. `Alignment`s used for design purposes shall be contained in a `SpatialLocationModel`, submodel of a `DesignAlignments` instance, and by default, shall use the Domain-ranked `Alignment` category.
+An `Alignment` that drives the design of a linear asset, it is referred to as a *Design Alignment*. Whereas an `Alignment` that describes a secondary entity of a linear asset, but it is still expected to capture the kind of data typically associated to Alignments, it is referred to as a *Linear*.
-On the other hand, when an `Alignment` describes a secondary entity of a linear asset, it is referred to as a *Linear*. `Alignment`s created for the purpose of a *Linear* shall be contained in any `SpatialModel`, and by default, shall use the Domain-ranked `Linear` category.
+By default, *Design Alignments* may use the Domain-ranked `Alignment` category, while *Linears* by default may use the Domain-ranked `Linear` category.
-An `Alignment` shall always have an associated `HorizontalAlignment`, but `VerticalAlignment`s are optional. When an `Alignment` has one or more associated `VerticalAlignment`s, it refers to the one used to describe its profile as being the *Main Vertical*.
+Data-writers need to decide the most appropriate organization for Alignment data. `Alignment` instances can be stored in either SpatialLocationModels or PhysicalModels.
+
+A data-writer may choose to organize `Alignment` instances in a direct submodel of the corresponding `InformationPartitionElement` (i.e. `PhysicalPartition` or `SpatialLocationPartition`) at the leaves of the Subject Hierarchy. That is the most typical approach. Another strategy involves storing them in models deeper in the overall Information Hierarchy in a BIS repository.
+
+In the latter strategy, `Alignment`s used for design purposes can be stored in a `SpatialLocationModel`, submodel of a `DesignAlignments` instance. Moreover `Alignment`s created for the purpose of a *Linear* can be contained in any `SpatialModel` (i.e. `PhysicalModel` or `SpatialLocationModel`).
+
+An `Alignment` shall always have one and only one associated `HorizontalAlignment`, but `VerticalAlignment`s are optional. When an `Alignment` has one or more associated `VerticalAlignment`s, it refers to the one used to describe its profile as being the *Main Vertical*.
The `Alignment` class inherits its `LengthValue` property from the `ILinearElement` mix-in. In the case of `Alignment`s, such property shall store its horizontal length rather than its 3D length. Such horizontal length is computed from the associated `HorizontalAlignment` instance and cached into the `LengthValue` property of the `Alignment`.
@@ -32,17 +38,19 @@ Equivalent to [IfcAlignmentTypeEnum](https://standards.buildingsmart.org/IFC/REL
### DesignAlignments
-A `DesignAlignments` instance, by default, shall use the Domain-ranked `Alignment` category.
+A `DesignAlignments` instance is mainly used by data-writers who do not organize Alignment data directly from the Subject hierarchy, via a PhysicalPartition or SpatialLocationPartition, but wish to do so at a deeper level of the overall Information Hierarchy.
+
+By default, a `DesignAlignments` instace may use the Domain-ranked `Alignment` category.
### HorizontalAlignments
-Every set of `Alignment`s, contained in a `SpatialModel`, shall have one and only one instance of `HorizontalAlignments` leading to a *Plan-projection* `SpatialLocationModel` containing one `HorizontalAlignment` instance for each `Alignment` in the parent model.
+A data-writer may choose to organize `HorizontalAlignment` instances in a direct submodel of the corresponding `InformationPartitionElement` (i.e. `PhysicalPartition` or `SpatialLocationPartition`) at the leaves of the Subject Hierarchy. That is the most typical approach. Another strategy involves storing them in models deeper in the overall Information Hierarchy in a BIS repository. A `HorizontalAlignments` instance is used in the latter case. That is, every set of `Alignment`s, contained in a `SpatialModel`, shall have one and only one instance of `HorizontalAlignments` leading to a *Plan-projection* `SpatialLocationModel` (i.e. with its *IsPlanProjection* property set to *true*) containing one `HorizontalAlignment` instance for each `Alignment` in the parent model.
-Each `HorizontalAlignments` instance shall set its `CodeValue` property to "Horizontal Alignments", and by default, shall use the Domain-ranked `Alignment` category in the case of *Design Alignments* or the `Linear` category in the case of *Linears*.
+Each `HorizontalAlignments` instance shall set its `CodeValue` property to "Horizontal Alignments", and by default, may use the Domain-ranked `Alignment` category in the case of *Design Alignments* or the `Linear` category in the case of *Linears*.
### HorizontalAlignment
-A `HorizontalAlignment` instance shall be contained in a *Plan-projection* `SpatialLocationModel` submodel of a `HorizontalAlignments` instance, and shall be associated with one `Alignment` on such parent model via the `AlignmentRefersToHorizontal` relationship.
+A `HorizontalAlignment` instance shall be contained in a *Plan-projection* `SpatialLocationModel` or `PhysicalModel` (i.e. with its *IsPlanProjection* property set to *true*), submodel of the corresponding `InformationPartitionElement`, or a `HorizontalAlignments` instance, depending upon the chosen data-organization strategy. A `HorizontalAlignment` instance shall be associated with one and only one `Alignment` via the `AlignmentRefersToHorizontal` relationship.
A `HorizontalAlignment` typically has the same `CodeValue` and Category as its associated `Alignment`.
diff --git a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.cmap b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.cmap
index 7a6054d95..79b16fcf8 100644
Binary files a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.cmap and b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.cmap differ
diff --git a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.png b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.png
index 000619634..aea204c35 100644
Binary files a/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.png and b/Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/media/RoadRailAlignment-classes.png differ