Skip to main content

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 @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


Reply