Schema changes supporting live Drawing Production of Profiles.

Domains/2-DisciplinePhysical/Civil/RoadRailAlignment/RoadRailAlignment.ecschema.xml

@@ -95,14 +95,14 @@
             <Class class="AlignmentType"/>
         </Target>
     </ECRelationshipClass>
-    <ECEntityClass typeName="DesignAlignments" description="Entry-point element into an AlignmentModel containing Alignments used for design purposes in given Spatial Model.">
+    <ECEntityClass typeName="DesignAlignments" description="Entry-point element into a bis:SpatialLocationModel containing Alignments used primarily for design purposes.">
         <BaseClass>bis:SpatialLocationElement</BaseClass>
         <BaseClass>bis:ISubModeledElement</BaseClass>
         <ECCustomAttributes>
             <HiddenClass xmlns="CoreCustomAttributes.01.00.00"/>
         </ECCustomAttributes>
     </ECEntityClass>
-    <ECEntityClass typeName="HorizontalAlignments" description="Horizontal/Top perspective on Alignments in an AlignmentModel that will be broken down in more detail in a separate HorizontalAlignmentModel.">
+    <ECEntityClass typeName="HorizontalAlignments" description="Entry-point element into a bis:SpatialLocationModel capturing the Horizontal/Top perspective on Alignment instances.">
         <BaseClass>bis:SpatialLocationElement</BaseClass>
         <BaseClass>bis:ISubModeledElement</BaseClass>
         <ECCustomAttributes>
@@ -168,4 +168,20 @@
             <Class class="lr:ReferentElement"/>
         </Target>
     </ECRelationshipClass>
+    <ECEntityClass typeName="VerticalAlignmentViewDefinition" displayLabel="Vertical Alignment View Definition"  description="A VerticalAlignmentViewDefinition specifies parameters for a view of a VerticalAlignmentModel.">
+        <BaseClass>bis:ViewDefinition2d</BaseClass>
+    </ECEntityClass>
+    <ECEntityClass typeName="ProfileDrawing" displayLabel="Profile Drawing" description="A ProfileDrawing is a bis:Drawing based on a view of a VerticalAlignmentModel. A ProfileDrawing can be sub-modeled by a DrawingModel.">
+        <BaseClass>bis:Drawing</BaseClass>
+        <ECNavigationProperty propertyName="VerticalAlignmentView" relationshipName="ProfileDrawingIsBasedOnVerticalAlignmentView" direction="forward" displayLabel="Vertical Alignment View" description="The VerticalAlignmentViewDefinition that this ProfileDrawing is based on."/>
+    </ECEntityClass>
+    <ECRelationshipClass typeName="ProfileDrawingIsBasedOnVerticalAlignmentView" strengthDirection="backward" strength="referencing" modifier="Sealed" description="Identifies the VerticalAlignmentViewDefinition that the ProfileDrawing is based on.">
+        <!-- @see SectionDrawing.SpatialView ECNavigationProperty -->
+        <Source multiplicity="(0..*)" polymorphic="true" roleLabel="is based on">
+            <Class class="ProfileDrawing"/>
+        </Source>
+        <Target multiplicity="(1..1)" polymorphic="true" roleLabel="is used by">
+            <Class class="VerticalAlignmentViewDefinition"/>
+        </Target>
+    </ECRelationshipClass>
 </ECSchema>

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`.