I finally have the ability to set up and manage repositories in GitHub. As discussed in various contexts, I would like to create a repository for sample IFC files, IFC2x3 and IFC4, with varied levels of complexity (though let’s not get too crazy), for “public” testing and example purposes. I propose that there be a single “SAMPLE FILES” repository with folders for each of the different “purposes”, e.g.:
Sample_Files >
IFC_documentation_samples
IFC2x3
IFC4 (includes .ifc, .ifcxml, .rdf, .ttl)
ISG_testing
Experimentation
…???
We can also set up GitHub Pages to help provide documentation/guidance on the purpose/use of the files.
The sample files repository is great. May I request for some more repositories…
Please, if possible, make a single repository with the IFC class library in C#.
This single repository (without all the IfcDoc collateral functionality) can hopefully accommodate native serialisation and deserialisation to XML and JSON (embedded with annotations in code).
Also, this single repository can be directly associated with a NuGet package manager account, so people can easily plug a released version of IFC (e.g. IFC 4.1) in their own codebase (instead of having to write some EXPRESS parser again).
Please, do the same for Java - single repository with IFC classes in Java, including publication in the maven package manager.
Python -> third repository?
Of course, changes over time and over diverse class libraries need to be managed by one or more people who are able to integrate suggested changes in the different code bases (C#, Java, Python). That might be a role for Technical Room and/or Model Support Group?
I think what you’re asking for is C# code that is owned and maintained by BSI. I believe IfcDoc is the only version of that, and I haven’t received a lot of feedback that suggests that situation will change any time soon.
You may know already about the IFC-gen project. The mission of that project was to generate IFC libraries in numerous languages. We’re currently generating C# because that’s what we use at Hypar but we’ve also demonstrated using IFC-gen to create Typescript libraries, Protocol Buffer definitions, and even a GraphQL API straight from the EXPRESS schema. IFC-gen is open source and just waiting for people to contribute a code generator for the language of their choice. I’m happy to help if you’re interested in contributing
The IFC-generated C# libraries are currently available on NuGet as Hypar.IFC2X3 and Hypar.IFC4. We use them currently inside the Elements library for reading and writing IFC.
Hi all,
I’m not a programmer so maybe make a mistake, however, I think it’s better to try:
First of all, it seems that we’re going to build a “web-based” IfcDoc which sounds great
So, what about “microservices” and “Function as a service (FaaS)” and choosing some services like “AWS Lambda” which gives us the feasibility to breakdown the IFC schema to small parts/functions and work on each one and improve them constantly, with any language we want, like C#, C++, Java, Python, PHP, etc
I think we can categorize IFC-STEP in two-three parts:
A. Data and information (TYPE): Which I think the majority of them are DataTypes and Enums that can convert them to MySQL tables/lists and also SQLite (Which is vital for IoT approaches) - SQL and NoSQL
B. Geometries: Which it seems that had a huge improvement in IFC4 and I don’t know well about. Still, is it based on Compound Solid Geometry (CSG), Boundary Representation (B-Rep), and Swept Geometry (Sweep Volume)? Or something added or improved?
So, is there any web-based technologies like WebGL (asm.js) or even WebAssembly to have lite web-based geometry (if possible in client-side)?
C. Functions: Which I think should be translated to other aforementioned languages too
A sample files repository is a great idea. Absolutely go for it! People can also fork the repo to have their own experiments.
This repo should ideally be language/platform agnostic. Another repo might exist which is tailored towards a language, but the spec itself should try to remain as partial as possible - I believe that would be the approach to promote an equal ecosystem.
Everyone is in a Great need for Sample Files, Because it is very diff to justify who is right or wrong.
If we allow Users a Sample IFC files then they can easily compare and Work Accordingly.
Sample Files will also be a Great platform for New/old Software’s to check their working of IFC import/Export.
Also, sample files are the first/start/base step to bring “web-based IfcDoc” to reality (also, as we know IfcDoc has some issues)
There are some great IFC server projects and sample files can help them too to find their way to the next step and develop and improve their solutions and their performance
Wow, everyone is talking in programing languages which are not my language
Anyway, I support this idea and I am looking forward to learn/exchange some information.
What I am missing in all these discussions are the results from the examples which should ideally be documented. Hopefuly this will create more tansparency in the work done…
Colleagues, I am afraid topics above about programing languages and tools are irrelevant to IFC samples.
IFC samples are not depending on lang. and tools. Or did I miss something?
It may have following subfolders for IFC4
Simple units
RV samples
CGS (Boolean) geometry
NURBs geometry
Huge models (for performance testing)
Maybe 2nd level subfolders to group by vendor or exported application?
I understand that the goal for such repository is for developers.
Is there any other IFC samples official repository for “users”, instead of programmers?
I think the idea of having some examples of “best-practices” regarding the different ways of working with IFC schema is very interesting and useful.
At the moment what you mentioned is inside the IfcDoc, and it seems that IfcDoc has some issues too and doesn’t produce IFC files well.
And I think there’s a need to produce new sample files with development purposes that help “software companies” to be interoperable more with IFC (which here is the problem)
However, some like me think a step ahead and think about the IfcDoc and Schema development on the web and in “federated way”
How can we say to the industry that the next level of BIM is “federated” when we have’t worked and haven’t developed IFC based on?
IFC developed for “desktop software” and today this is not the main need (which this is another problem too)
IFC needs a modern structure than EXPRESS/STEP which was good for 19s
Is there any other IFC samples official repository for “users”, instead of programmers?
What is the difference in IFC samples ‘for users’ vs ‘for programmers’?
At the moment what you mentioned is inside the IfcDoc
If I understand proper IfcDoc is a tool to generate documentation.
The subject of this topic (I though) is about to have samples from different vendors. It sounds different to me.
I appreciate the enthusiasm, but let’s please stick to the topic at hand… sample files.
On that note, I’ve further developed ideas about criteria. Please take a moment to review and respond. If it looks good and you have no further comments, just favorite and we’ll move onward and upward by the end of this week.
Sample File Repository Criteria
Files:
Files based on “bSI official” MVDs - Should conform to IFC2x3 CV2.0 or IFC4 RV1.2
Files based on “other official” MVDs - Could be GSA CB2010, or others. There should be a link to the MVD specification the file was based on.
“Experimental” files based on new or ad-hoc MVDs - There should be a link to the MVD specification the file was based on, or some kind of documentation describing the intent.
ISG Testing Files -
…
General Criteria:
Files for this repository can only be submitted by known bSI community members, usually members of the different Rooms, Projects, or Groups. If you want to make an impression, then interact with the community via the Forums, your chapters, and events.
All files MUST have a header that conforms to bSI specifications;
A list and description of files should be maintained in the README.md or Wiki. This helps the user understand the purpose of the file and expectations for performance on import;
Files should not contain proprietary or sensitive information (or could have documented authorization for release) and must be free to use for all;
Files can be of varying size and complexity, but max limit is <1GB.
As the same “source native model” could be exported into sample files for all of these Categories, this may have as in interesting side effect that you can illustrate how the same input may lead to varying output, and very differently optimised IFC-exports, depending on a well-chosen MVD or even a custom MVD and the configuration of the exporter in your modelling software.
Files created directly from code libraries are often very differently structured than exports from current BIM software.
As most sample files floating around these days stem from rather old models with old IFC convertors, we should be wary of including them here as well. Some review may be required… Will these files be judged and “benchmarked” so they represent good and valid examples, fully adhering to the IFC-schema?
The point you mention is one of the issues these days, and I think the goal of these team and all friends who join is: not only have natural MVDs and RVs, also solve export issues some software have when generating IFC files
Mine Ques is
How we will validate IFC file which are uploaded and that are going to uploading is correct to every extent and best example of that particular query.
I think we have to also explain in detail the working of that IFC file. So that by reading documentation user will understand it and select files as per its requirement.
Dear all. My thoughts. This discussion is at the same time interesting and indeterminate. “Validate” an IFC model rely on computer language theory. To be strict, a “valid” IFC model must only conforms with the STEP (EXPRESS) meta-grammar and nothing else. For example, in C, we can write a valid sentence “a = a - a;”, but in practice it is a nonsense statement. This same occurs with IFC and many many other “program codes”. I think to have a “checking IFC model bank” will be awesome only for grammar parsing purposes, but not to “validate” the geometry of building itself. Further, I think this “IFC model bank” should be divided in terms of model complexity and size. Small models with little entities at diferent geometry representations to measure parser correctness and very big model for measure performance.
