|Anonymous | Login||2020-09-23 12:35 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025170||Community||[OCCT] OCCT:Data Exchange||public||2014-08-20 13:55||2019-07-10 22:04|
|Platform||Windows||OS||VC++ 2010||OS Version||64 bit|
|Product Version||[OCCT] 6.6.0|
|Target Version||[OCCT] 7.5.0||Fixed in Version|
|Summary||0025170: STEP Reader - files with double points in float values can't be properly imported|
|Description||The original STEP file was generated by CATIA V5R19SP6 and contains float values with two points like this: 0000046=CARTESIAN_POINT('Pt',(-0.000207049553901,5.80242849033,-4..07988881588));|
The current master can't properly import such files (check the attached image of the modified as1 model)
|Steps To Reproduce||Import the attached modified as1 model|
|Tags||No tags attached.|
|Test case number|
|Attached Files|| as1-oc-214.stp (441,973 bytes) 2014-08-20 13:55|
doubles_master.jpg (163,196 bytes) 2014-08-20 13:56
Hoops.png (28,176 bytes) 2014-11-06 15:04
Exchanger.png (10,690 bytes) 2014-11-06 15:17
Branch CR25170 has been created by drazmyslovich.
This branch includes the following new commits:
new 532f325 0025170: Fix the incorrect parsed float values with two points
Detailed log of new commits:
Date: Wed Aug 20 11:57:17 2014 +0200
0025170: Fix the incorrect parsed float values with two points
|The fix is provided, please, review it|
Hello Dmitry, could you please confirm that this problem (diplicate points in floating point values) is systematically found in STEP files produced by CATIA V5R19SP6?
This seems to be quite strange, as we normally can expect problems related to semantic or some syntax errors in the file, but not on the level of floating-point number representation! I have serious doubt if treatment of such errors makes sense. If this is systematic for CATIA, do you know if other systems can read such files successfully?
Hello, Andrey, unfortunately, I can't confirm, that the problem can be systematically reproduced, since I have just 2 STEP files generated by CATIA V5R19SP6 in my database. I have no license for CATIA. And all our customers use native CATIA files import since the last version of our software.
Do you think, it's dangerous to integrate the fix provided?
|Hello Dmitry, no I do not think that fix will be dangerous, even if it is always possible to have some unpredictable effects. I rather think that it might be useless if this situation appeared only once in single file, e.g. due to data transfer error. Can you confirm that this problem appears systematically (i.e. in all or many floating point numbers) at least in both data files you have? Another question is whether your fix allows obtaining correct result (i.e. can you check that two points should be considered as one? or maybe second point should be interpreted as 0?).|
edited on: 2014-09-29 11:40
Hello, Andrey. I've checked once again all my STEP files generated by CATIA V5 and it seems that it was problem exactly in R19SP6, since neither other releases nor other service packs have something to do with it. Moreover, analyzing the files, generated by R19SP6 I found out, that this problem appears many times in the file, BUT it appears not only in the float values. It seems, that the second dot appears randomly near another dot. For example, the files are full of the following entity parameters: ".UNSPECIFIED..", ".F..", ".U.." and float values. But only float values can't be correctly parsed.
And especially for these files my fix seems to produce the correct result, since the geometry looks fine and the customer hasn't reported further problems with files after this fix.
I have also tried some other STEP software: IDA-STEP, STP Viewer, HOOPS Exchange Demo. Only HOOPS can correctly parse the file, all other detect an error.
So, I agree, that this fix is most probably irrelevant, since it appears only for CATIA V5R19SP6 (moreover we aren't sure if it appears consistently even for this CATIA version). But maybe it's reasonable to generate a parse error rather then proceed with wrong float value?
|Hello Dmitry, thank you for details and sorry for delay with my answer.. I have checked the situation with Hoops Exchange Demo and in my understanding its behavior is more like in current OCCT, i.e. it reads the number only until the second dot and does not report error. Thus the change you proposed seems to be not in line with behavior of other translators, so I am not in favor of taking it. I will try to check this more in depth a later, then we decide.|
|Hello, Andrey. I disagree, that current OCCT behaves similar to HOOPS, please, check the screenshots I uploaded.|
|2014-08-20 13:55||drazmyslovich||New Issue|
|2014-08-20 13:55||drazmyslovich||Assigned To||=> gka|
|2014-08-20 13:55||drazmyslovich||File Added: as1-oc-214.stp|
|2014-08-20 13:56||drazmyslovich||File Added: doubles_master.jpg|
|2014-08-20 13:57||git||Note Added: 0030931|
|2014-08-20 13:58||drazmyslovich||Note Added: 0030932|
|2014-08-20 13:58||drazmyslovich||Status||new => resolved|
|2014-09-26 16:20||abv||Note Added: 0032254|
|2014-09-29 10:34||drazmyslovich||Note Added: 0032284|
|2014-09-29 11:00||abv||Note Added: 0032286|
|2014-09-29 11:39||drazmyslovich||Note Added: 0032288|
|2014-09-29 11:40||drazmyslovich||Note Edited: 0032288||View Revisions|
|2014-11-06 06:45||abv||Note Added: 0034073|
|2014-11-06 06:45||abv||Assigned To||gka => abv|
|2014-11-06 06:45||abv||Target Version||6.8.0 => 7.1.0|
|2014-11-06 15:04||drazmyslovich||File Added: Hoops.png|
|2014-11-06 15:17||drazmyslovich||File Added: Exchanger.png|
|2014-11-06 15:18||drazmyslovich||Note Added: 0034104|
|2016-10-26 20:03||gka||Target Version||7.1.0 => 7.2.0|
|2017-08-29 09:37||abv||Target Version||7.2.0 => 7.3.0|
|2018-02-25 21:14||abv||Target Version||7.3.0 => 7.4.0|
|2019-07-10 22:04||abv||Target Version||7.4.0 => 7.5.0|
|Copyright © 2000 - 2020 MantisBT Team|