Hi folks,
Each time I tried to read an IFC file in IFC reader I got an error states that “ISO 10303-21: the input data file has a syntax error in instance ‘’#879 ”


I tried several IFC files but I got the same error, how can I fix this?
Cheers,
Rawan
Hi folks,
Each time I tried to read an IFC file in IFC reader I got an error states that “ISO 10303-21: the input data file has a syntax error in instance ‘’#879 ”


I tried several IFC files but I got the same error, how can I fix this?
Cheers,
Rawan
Thank you for your answer, kindly find the attached file. Really appreciated your help
Cheers,
Rawan
Hi @rawansaleh, Thank you for sharing your sample data.
I have taken a look at it, and found that in the line with instance number indicated in the error message (#879 in this case) there is a Ø character. Further down the file, there are 3 more lines with the same character. If we remove these characters using a text editor, the IFC file can be read successfully. Hope this is an acceptable workaround for you.
(Note: the "Ø" character may show up as "?" or other special characters in a text editor, depending on the system locale setting of your computer.)
With special characters like these, the file is technically considered invalid. However, our developer think we can work to improve the reader, so they can read these files, and avoiding failures in some cases. I'll update in this thread, when the fix is added to the product, in the future.
Hi @rawansaleh, Thank you for sharing your sample data.
I have taken a look at it, and found that in the line with instance number indicated in the error message (#879 in this case) there is a Ø character. Further down the file, there are 3 more lines with the same character. If we remove these characters using a text editor, the IFC file can be read successfully. Hope this is an acceptable workaround for you.
(Note: the "Ø" character may show up as "?" or other special characters in a text editor, depending on the system locale setting of your computer.)
With special characters like these, the file is technically considered invalid. However, our developer think we can work to improve the reader, so they can read these files, and avoiding failures in some cases. I'll update in this thread, when the fix is added to the product, in the future.
Thank you for spending time to check this, I need to convert this file to multipatch in a file geodatabase to be able read this file in ArcGIS Pro, Do I need to setup any thing rather than a geodata base file writer?
Best Regards,
Rawan
Thank you for spending time to check this, I need to convert this file to multipatch in a file geodatabase to be able read this file in ArcGIS Pro, Do I need to setup any thing rather than a geodata base file writer?
Best Regards,
Rawan
Thank you ! really appritated .
Hi @rawansaleh, Thank you for sharing your sample data.
I have taken a look at it, and found that in the line with instance number indicated in the error message (#879 in this case) there is a Ø character. Further down the file, there are 3 more lines with the same character. If we remove these characters using a text editor, the IFC file can be read successfully. Hope this is an acceptable workaround for you.
(Note: the "Ø" character may show up as "?" or other special characters in a text editor, depending on the system locale setting of your computer.)
With special characters like these, the file is technically considered invalid. However, our developer think we can work to improve the reader, so they can read these files, and avoiding failures in some cases. I'll update in this thread, when the fix is added to the product, in the future.
is this IFC file compliant with the IFC specification at: http://www.buildingsmart-tech.org/specifications ? If it is, then can the IFC reader be improved to handle IFC files with this special character in it?
Regards,
Nick
is this IFC file compliant with the IFC specification at: http://www.buildingsmart-tech.org/specifications ? If it is, then can the IFC reader be improved to handle IFC files with this special character in it?
Regards,
Nick
Thanks for following up with this, I can provide you with more sample data if you can give me your email (or any other way to share the files only with you) because we are not allowed to share the files in public due to privacy policy.
Thanks in advance
Rawan
Thanks for following up with this, I can provide you with more sample data if you can give me your email (or any other way to share the files only with you) because we are not allowed to share the files in public due to privacy policy.
Thanks in advance
Rawan
Hi Rawan, I think we do have your sample data already. So we should be good. Thank you!
Hi Rawan, I think we do have your sample data already. So we should be good. Thank you!
@XiaomengAtSafe Thank you! Hope that this problem solved soon
Hi @rawansaleh, Thank you for sharing your sample data.
I have taken a look at it, and found that in the line with instance number indicated in the error message (#879 in this case) there is a Ø character. Further down the file, there are 3 more lines with the same character. If we remove these characters using a text editor, the IFC file can be read successfully. Hope this is an acceptable workaround for you.
(Note: the "Ø" character may show up as "?" or other special characters in a text editor, depending on the system locale setting of your computer.)
With special characters like these, the file is technically considered invalid. However, our developer think we can work to improve the reader, so they can read these files, and avoiding failures in some cases. I'll update in this thread, when the fix is added to the product, in the future.
Hi Xiao. I'm having a similar issue. Please see error message and problem line below. I think the degrees symbol is causing the issue, as line 1916 is the first occurrance of the symbol:
ISO10303-21: The input data file has a syntax error in instance '#1916':
syntax error, unexpected TOK_INTEGER, expecting ')'
ISO10303-21: Invalid file format, unable to continue reading
A fatal error has occurred. Check the logfile above for details
Translation FAILED with 4 error(s) and 0 warning(s) (0 feature(s) output)
FME Session Duration: 7.2 seconds. (CPU: 4.3s user, 2.2s system)
END - ProcessID: 7576, peak process memory usage: 48736 kB, current process memory usage: 48736 kB
A fatal error has occurred. Check the logfile above for details
Program Terminating
Translation FAILED.
#1916= IFCPROPERTYSINGLEVALUE('pit symbol bearing dms',$,IFCLABEL('312°39\\X2\\0027\\X0\\15\\X2\\0022\\X0\\'),$);
Please let me know if there is a work-around for this.
Thanks
Hi Xiao. I'm having a similar issue. Please see error message and problem line below. I think the degrees symbol is causing the issue, as line 1916 is the first occurrance of the symbol:
ISO10303-21: The input data file has a syntax error in instance '#1916':
syntax error, unexpected TOK_INTEGER, expecting ')'
ISO10303-21: Invalid file format, unable to continue reading
A fatal error has occurred. Check the logfile above for details
Translation FAILED with 4 error(s) and 0 warning(s) (0 feature(s) output)
FME Session Duration: 7.2 seconds. (CPU: 4.3s user, 2.2s system)
END - ProcessID: 7576, peak process memory usage: 48736 kB, current process memory usage: 48736 kB
A fatal error has occurred. Check the logfile above for details
Program Terminating
Translation FAILED.
#1916= IFCPROPERTYSINGLEVALUE('pit symbol bearing dms',$,IFCLABEL('312°39\\X2\\0027\\X0\\15\\X2\\0022\\X0\\'),$);
Please let me know if there is a work-around for this.
Thanks
Hi @andrewflaws, if you open the file in a text editor, and remove the degree symbols, will the error go away?
If it does, would that serve as a workaround, for now?
I'll let the developer know, and see if we can support this character in the future.
Hi @andrewflaws, if you open the file in a text editor, and remove the degree symbols, will the error go away?
If it does, would that serve as a workaround, for now?
I'll let the developer know, and see if we can support this character in the future.
Hi @xiaomengatsafe, we are having the exact problem. We have found in the IFC file we received there are two special characters including ° and ×. We could work with it by removing these two special chars in a text editor. However, we won't know what other special chars will be carried by the IFC files we received in the future. Supporting more special chars in IFC reader sounds like the ultimate solution for the problem. thanks.
Hi @xiaomengatsafe, we are having the exact problem. We have found in the IFC file we received there are two special characters including ° and ×. We could work with it by removing these two special chars in a text editor. However, we won't know what other special chars will be carried by the IFC files we received in the future. Supporting more special chars in IFC reader sounds like the ultimate solution for the problem. thanks.
Hi @sealjackii, (Sorry for my delayed response!)
Thank you very much for your note here. And you make a good point about the limitation of the workaround. We will
I've added your case to our existing issue tracking, and also raised the importance of the issue a bit, as this seems to be affecting quite a few people. We'll post an update in this thread when we have some news.
@xiaomengatsafe, @rawansaleh, @sealjackii and @nmiller
Hi Folks,
please see my comments on this particular case here: https://knowledge.safe.com/answers/109687/view.html
I hope it can also add some help on the issue
Best Regards
Hi @sealjackii, (Sorry for my delayed response!)
Thank you very much for your note here. And you make a good point about the limitation of the workaround. We will
I've added your case to our existing issue tracking, and also raised the importance of the issue a bit, as this seems to be affecting quite a few people. We'll post an update in this thread when we have some news.
OK, here might be the reason, according to BuildingSmart:
The IFC exchange format “STEP physical file” uses characters represented by decimal value 32 to 126 from the code table in ISO 8859-1. Any other character, like some Western characters, like the German “Umlaut”, Greek or Cyrillic letters, or Asian characters, has to be encoded before being exchanged as part of a string value. Up until IFC4.x this encoding is used in IFC. In the future, IFC will adopt the UTF8 encoding.As our IFC file using IFC2x3 schema, it should not contains any char that outside the 32-126 range, but it does in our case. So it is an issue with whatever software that generates the IFC file didn't encode string properly, or should use IFC4x