IDS import ..error Report !!

[Yara Oweiss]

I can not import IDS file, i keep getting this error report, and in the Import window, there's no Classification or properties to show and pick from.

  

[mitchSyd · Accepted solution]

Hi Yara

I think your issue is that the version of your IDS file is 0.9.7, which has been superceded by 1.0.

One of the upgrades was to make the Name attribute for properties to baseName , and datatype to dataType

here is a good file from the Singapore code checker project

I'd be happy to test any of your files & collaborate using IDS

[Yara Oweiss]

Hello Mich,

thank you for your Reply, the file that you added worked fine, I think that you were right about the version Problem, is there a quick way to upgrade the old file to the new version? so we can use it in Archicad IDS import?

[mitchSyd]

Hi Yara

the ids file is just a text file in html format

if the file was small you could perhaps hand edit it - compare with the SG one, but your supplier should be using IDS v1.0 and should update it as there may be other issues.

I followed up the author CRTI-B of the files and discovered their excellent site https://www.bimids.eu/lu-en/downloads

I opened one  of the many files and they are v0.9!

I imagine Moreno Viola at crti-b is not too happy to have the suite of IDS resources updated, but v1.0 is the current version and as you found out ArchiCAD, Revit, Allplan, Solibri... are/will be using V1.

To anyone seeking IDS examples the CRTI-B site is a must.

Let me know how you go. How does CRTI-B intend to use the IDS resources - automated code checking , or ?

[Franz Sdoutz]

Tried IDS files from PLANNERLY (free version)  with weird classifications I could not figure how to specify in plannerly.

@mitchSyd 's file worked perfectly.

One thing though:

Since IDS imported properties are made available for all Classifications - and imported classifications allow (automatically) only imported properties - one can choose wheather to classify within the imprted system or to just ignore that. Export with Archicad28 classification will result in an IFC file with those required ids properties, regardless their "intended" classification.

Since the imported IDS classification is completely useless (no predefined types, no linked properties ... no access to Arch28 calculations) one needs to retrofit IFC-Elements and Predefined-Types of Archicad28 in order to match feasible classification requirements... (we are talking non-standard DACH idiosyncracies here)

But how will I do that for comprehensive specifications? 

 

 

 

[Franz Sdoutz]

Update:

Created IDS-files with usBim by acca (free) - works like a charm.

Youtube tutorial:

https://youtu.be/wkdwzTAB8FE?si=mpwBz2_AteA5RFkQ

[JENOGUES]

Hi,

After loading the file you suggest (IDS for SG Doors...) and checking the IDS is configured only for doors, now I can see these new Psets not only for doors, but also for any other element such as walls... Is this a bug? Or did I do something wrong?

Thanks

[Franz Sdoutz]

@JENOGUES 

Yes, all imported porperties are accessable to all preexisting classifications. This means that all elements regardless off their classification can "see" them.  If you know what you*re doing, you can restrict those properties manually. This could be tricky for large comprehenive IDS-files.

One could also switch entirely to the imported IDS classification. Though I doubt, that this iwould be a good idea (depending on the IDS).

Imported Classifications are dealt with as a seperate system. Up to Archicad 27 ist was highly dissuaded to use more than one classification system for one project, for such would result in weird IFC Export "ideosyncracies" ... (I live to tell that tale)

You could also just set your export parameters to the following:

This will limit imported IDS properties to their assigned classifications, as long as those classifications corelate with the Archicad 28 template (used for my screenshots). This way it won't matter, what element "sees" or "fills" what property as long as it is correctly classified. Export to IFC will clense all.

However such will be true for all properties in the IDS induced template.

As long as the Information Delivery Specification File is available up front for all design phases, one can make a custom template for that specific project by assigning properties and adjusting calculations manually ... This way also required non-standard IfcElements and Types could be incorporated.

All hell breaks loose when forced to import an IDS into an existing project.

The issue here is NOT Archicad 28 importing classifications the way it does. I can*t come up with a logically consistent alternative. The problem is that one can easily compile a legit IDS file with free software that will NOT work for Archicad. In the sense that some requirements will not be workable with the implemented IFC standards or well tried Archicad CAD structuring strategies...

[mitchSyd]

IDS is very new and implementers are rapidly adopting it.

An excellent presentation is here https://www.youtube.com/watch?v=SaRtOFpW0zk&t=483s.

The principal purpose of IDS is to define a machine interpretable (client) specification of the required model. The fact that ArchiCAD imports IDS properties to all IFC elements seems a massive overkill, as IDS specifies the IFC entity the property needs. Vimal Kumar, SG Graphisoft offered this explanation:

I had discussed about the issue of having the properties assigned to all elements in Archicad to our product manager last month. The reason why the properties are made available to all elements is that the IFC type mapping in Archicad could be edited by end users, and they have the flexibility to customise the type mapping based on Classifications or element types. Hence, we might not be able to decide which property should be linked to which element. And the argument was that the property mapping in translators is done as per the IDS file, hence the IFC elements will not have the all the properties attached to all of them.

Leon's youtube describes many new opportunities to produce rich information!

[Franz Sdoutz]

 @mitchSyd Just watched that very informative Video ...

The next step should be Archicad internal IDS checking. But checking against what? The current method of dealing with anecdotal IDS classification requirements as separate rudimental classification systems can`t facilitate that - since NO element should be classified according to multiple (ids imported) classification systems (which could define contradictory nonsense like: IfcDoorType AND IfcWallType.Userdefined.movable-light-wall ...)

What if the imported IDS classification scheme could be checked against the implemented standard on import:

1) IDS classifications match completely: A copy of ArchiCAD classifications is made, with all IDS defined accessibilities/restrictions. I choose whether to switch to this new IDS defined, complete Classification system or keep the Archicad standard tweaking it manually to my needs.

2) There are viable nonstandard IDS requirements like a "IfcNixi" classification: ArchiCAD tries to integrate them to its standard copy. An interface guides me through some decisions regarding access, restrictions and type modifications.

--> IDS defines nonstandard classification. ignore? substitute for supported IfcClass? implement?

--> add "IfcNixi" to newly generated ArchiCAD classification

--> attach and restrict properties according to IDS automatically yes? no? edit?

--> mapping options on export?  i.e. IfcBuildingElementPrtoxy.USERDEFINED.NIXI yes? choose other Archicad supported PredefinedType?

 Based on these choices a new (complete) custom classification system is generated.

3) IDS requirements ArchiCAD cannot deal with: List of issues, I can show the client and demonstrate how crap his IDS really is.

Side note: BuildingSmart keeps emphasising how all encompassing and sufficient their standard is. To us DACH users such assertions are pure anglo-saxon cultural bias. What our building traditions require, is either lacking or unintelligibly defined. Also: translations SUCK.