itwin / bis-schemas Goto Github PK

The bis-schemas and bis-schema-validation repositories needs to be updated to consume the dependencies having the fix.

Seems like our test user is not working any more.

This list was built by looking at the latest released version of each schema. Unreleased schemas and legacy conversion schemas are not included.

• Analytical
  • WIP PR: #129
• BisCore
  • WIP PR: #129
• BridgeStructuralPhysical
  • WIP PR: #137
• CoreCustomAttributes
  • WIP PR: #136
• ECDbMap
  • WIP PR: #136
• ECDbSchemaPolicies
  • WIP PR: #136
• Functional
  • WIP PR: #129
• Generic
  • WIP PR: #129
• OpenBridgeModelerCE
  • WIP PR: #137
• OpenPlantExtensions
  • WIP PR: #137
• PhysicalMaterial
  • WIP PR: #129
• PlantCustomAttributes
  • WIP PR: #137
• PointCloud
  • WIP PR: #137
• PresentationRules
  • WIP PR: #137
• ProcessFunctional
• ProcessPhysical
• ProcessPidGraphical
  • WIP PR: #137
• QuantityTakeoffsAspects
• Raster
  • WIP PR: #137
• ScalableMesh
  • WIP PR: #137
• SchemaLocalizationCustomAttributes
  • WIP PR: #136
• ThreeMx
  • WIP PR: #137

Every concrete bis:PhysicalElement class in the StructuralPhysical schema shall have a corresponding PhysicalType subclass. E.g. Column --> ColumnType, Beam --> BeamType, etc.

The qto schema contains a FoundationAspect class, capturing a "Type" property in terms of the following enumeration:

The StructuralPhysical team needs to confirm if those types are already covered either by element-classes or PhysicalTypes in such schema, so we can deprecate the qto:FoundationAspect class accordingly.

Skip this step to avoid unnecessary blockage for users.

• Upgrade the package.json file to use the latest versions of the validation tools and other dependencies.
• Update the node version to 18.x in the related pipelines.
• Update the documentation

The issue is coming while executing the rush change -v command during the iTwinjsCoreTests stage.

Short-term concepts that iModel Connectors can align to include:

Rebar
RebarType
RebarSet
RebarAssembly
RebarEndDevice

Investigate and fix the builds.

Review architectural concepts introduced as Revit's Base-families and make sure they are covered by the Architectural BIS schemas accordingly in any way, either via element-classification or element-organization.

E.g. as element-class, type-definition, category, spatial-composition, etc.

We're aiming at deprecating the class "SlabAspect" in the QuantityTakeoffsAspects schema (qto). It contains two properties: "SlabDirection" and "Type". The latter will be replaced by the introduction of a "SlabType" class in StructuralPhysical.

As far as the former, the StructuralPhysical team (where the official "Slab" class is defined) needs to discuss whether the "SlabDirection" property needs to be captured as an aligned/standard concept in such schema, or not.

The build is failing with some compiler out of heap space error.

We're aiming at deprecating the "StructuralLinearMemberAspect" class in the "QuantityTakeoffsAspects" schema. It currently contains the following properties:

CrossSectionalArea, SectionName, Type.

Regarding the Type property, it lists the following enum:

<ECEnumeration typeName="StructuralFramingType" backingTypeName="int" isStrict="true">
    <ECEnumerator value="0" displayLabel="Beam"/>
    <ECEnumerator value="1" displayLabel="Column"/>
    <ECEnumerator value="2" displayLabel="Vertical Brace"/>
    <ECEnumerator value="3" displayLabel="Horizontal Brace"/>
    <ECEnumerator value="4" displayLabel="Pier"/>
    <ECEnumerator value="5" displayLabel="Pile"/>
    <ECEnumerator value="6" displayLabel="Purlin"/>
    <ECEnumerator value="7" displayLabel="Cladding"/>
</ECEnumeration>

The StructuralPhysical schema team to discuss whether its schema is already handling it these properties/types and/or aligned/standardize the appropriate ones, before we can deprecate the qto schema.

Review structural concepts introduced as Revit's Base-families and make sure they are covered by the Structural BIS schemas accordingly in any way, either via element-classification or element-organization.

E.g. as element-class, type-definition, category, spatial-composition, etc.

The QuantityTakeoffsAspects schema contains a class which we want to deprecate: "EnergyPerformanceAspect" with a single property "Rating". We need to identify a better home for such class/property in BIS.

Currently all sub-jobs of iModelNativeTests pipeline are required to pass for PR validation. Investigate and run iTwinjsCoreTests job as optional so that its status currently should not effect the PR.

The QuantityTakeoffsAspects schema contains a class that we want to deprecate: PileAspect. The only detail preventing us from deprecating it is its "EmbedmentDepth" property.

Discussions need to take place in order to decide a better home for such property (if it needs to survive as an aligned/standard property on a Discipline-Physical schema - e.g. StructuralPhysical).

The WIP version has already been upgraded but it has not been released.

Test to ensure no compatibility issues and release.

Test that new iModel created has no EC 3.1 schemas in it.

NOTE: SchemaLocalizationCustomAttributes is still EC 3.1 but is unused at the moment so it can be ignored.

The new version of imodel-schema-validator tools is released. update and test the dependencies to avoid any issues before new releases of connectors.

Investigate and fix the validation build.

We're aiming at deprecating the "StairsAspect" class in the QuantityTakeoffsAspects (qto) schema. It currently contains two properties (NumberOfRisers and RiserHeight).

The ArchitecturalPhysical team needs to discuss whether or not those two properties need to be considered aligned/standardized into its "Stair" class before we can deprecate the corresponding class from the qto schema.