Archived issue #0033099
Data Exchange, Step Import - Wrong PMI values in GDT
Description
When read step file contains the GDT with complex type of measure(main value). The GDT value does set to XCAD (0,0 by default)
It is needed to update handle measure as a complex type too (use a base class to keep the entity)
Complex measure type is a StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI. Now we only process StepBasic_LengthMeasureWithUnit as a measure entity
It is needed to update handle measure as a complex type too (use a base class to keep the entity)
Complex measure type is a StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI. Now we only process StepBasic_LengthMeasureWithUnit as a measure entity
Public activity
14 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 15:02:44 2022 +0300
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Fixed magnitude class to handle main GDT value.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 15:02:44 2022 +0300
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Fixed magnitude class to handle main GDT value.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 15:02:44 2022 +0300
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Fixed magnitude class to handle main GDT value.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 15:02:44 2022 +0300
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Fixed magnitude class to handle main GDT value.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 13:02:44 2022 +0100
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Create StepRepr_MeasureWithUnit class for select type of measure.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Aug 12 13:02:44 2022 +0100
0033099: Data Exchange, Step Import - Wrong PMI values in GDT
Create StepRepr_MeasureWithUnit class for select type of measure.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Dear ika,
The fix is ready and tested. Branch for integration is CR33099_2.
Please review.
The fix is ready and tested. Branch for integration is CR33099_2.
Please review.
Dear anv,
The general approach is not OK from my point of view:
1) Creating of new StepRepr_MeasureWithUnit while we already have StepBasic_MeasureWithUnit will lead to problems with understanding in the future.
2) The STEP reading classes copy the STEP schema as much as possible, so it will be better to avoid creating an auxiliary SELECT entity that does not exist in the schema.
Summarising these items, I would suppose a bit another approach.
First of all, the root of the problem are complex entities used in the file to define the GDT value. The class for them is already implemented in OCCT StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI. It will be better to use it, but here we will face another issue. Two entities reference this complex type: SHAPE_DIMENSION_REPRESENTATION and GEOMETRIC_TOLERANCE. The first one should process the StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI properly because the inheritance branch of the corresponding attribute is OK, but GEOMETRIC_TOLERANCE supposes measure_with_unit as the magnitude parameter, which is not inherited from the same item, but we can use the root Standard_Transient for the magnitude pole. ReadEntity() is smart enough to read both StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI and StepBasic_MeasureWithUnit into it.
The last step will be to check the processing of the value in STEPCAFControl_Reader and add necessary ifs.
The general approach is not OK from my point of view:
1) Creating of new StepRepr_MeasureWithUnit while we already have StepBasic_MeasureWithUnit will lead to problems with understanding in the future.
2) The STEP reading classes copy the STEP schema as much as possible, so it will be better to avoid creating an auxiliary SELECT entity that does not exist in the schema.
Summarising these items, I would suppose a bit another approach.
First of all, the root of the problem are complex entities used in the file to define the GDT value. The class for them is already implemented in OCCT StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI. It will be better to use it, but here we will face another issue. Two entities reference this complex type: SHAPE_DIMENSION_REPRESENTATION and GEOMETRIC_TOLERANCE. The first one should process the StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI properly because the inheritance branch of the corresponding attribute is OK, but GEOMETRIC_TOLERANCE supposes measure_with_unit as the magnitude parameter, which is not inherited from the same item, but we can use the root Standard_Transient for the magnitude pole. ReadEntity() is smart enough to read both StepRepr_ReprItemAndLengthMeasureWithUnitAndQRI and StepBasic_MeasureWithUnit into it.
The last step will be to check the processing of the value in STEPCAFControl_Reader and add necessary ifs.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Reminder sent to: Commenter 3
Needs to clear code style changes.
Needs to clear non-PMI related updates. Changes must to be mostly for PMI related objects.
Recommended way is read as Entity and put into PMI anly needed type.
So, only RW will need to be updated. But for the beginning need to revert any code style changes.
Needs to clear non-PMI related updates. Changes must to be mostly for PMI related objects.
Recommended way is read as Entity and put into PMI anly needed type.
So, only RW will need to be updated. But for the beginning need to revert any code style changes.
Related records