Hi @rawansaleh, would you be able to share a sample dataset that causes this error? It would help to reproduce the problem and find out what's causing it. Thanks!
Hi @XiaomengAtSafe
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
That should work, @rawansaleh. Some geometry types might gets converted into geometries Geodatabase support. Here is
some background information that might be helpful. If you run into any problems with the writing part, please feel free to post a new question in the Q&A; forum, so our community can help out. Thank you!
That should work, @rawansaleh. Some geometry types might gets converted into geometries Geodatabase support. Here is
some background information that might be helpful. If you run into any problems with the writing part, please feel free to post a new question in the Q&A; forum, so our community can help out. Thank you!
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.
@XiaomengAtSafe
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
@XiaomengAtSafe
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
Hi @nmiller, yes, our developer will work to improve the reader to handle this case. Do you have other sample data with similar issues? If you do, it would be great if you can share that with us, so we can try to ensure the improvement covers your case as well. Thanks!
Hi @nmiller, yes, our developer will work to improve the reader to handle this case. Do you have other sample data with similar issues? If you do, it would be great if you can share that with us, so we can try to ensure the improvement covers your case as well. Thanks!
Hi @XiaomengAtSafe,
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 @XiaomengAtSafe,
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