New FreeCAD-agnostic BCF Python library

M by Moult on 30 May 2020, edited 12 Jun 2020 # +1 votes

The bcfplugin Python library was initially created by Patrick Podestplatz here. Back in December last year, I proposed that the library be converted into FreeCAD-agnostic so that it could be reused in the BlenderBIM Add-on, and who knows what else :) (FOSS OpenCDE API Server/Client, anyone?) For those interested, read the history.

Anyway, there is now a new Git repository, which contains some small new fixes and features, and is completely agnostic (Note: the BlenderBIM Add-on uses it for reading BCF files now!). Patrick, unfortunately, has let me know that he is too busy to maintain the library anymore, so I'm wondering if anybody here is interested in rewriting the FreeCAD integration as a thin wrapper on top of this new library? That way, both BIM authoring tools can benefit from mutual fixes (and support of future BCF versions, as BCF 2.2 is coming soon).

Happy hacking!

Y by yorik on 30 May 2020 #

I'd be interested in doing that. But need to look a bit further at what would be involved

M by Moult on 30 May 2020 #

Cheers @yorik - ping also @bitacovir / @carlopav / @bernd who might be interested in this development.

The library is almost unchanged in terms of API (though a few new endpoints added) - I believe the existing wrapper just needs to import the new library and swap out all the calls - the calls are the same though. Also, things like AddViewpoint needs to be refactored since that was previously tightly coupled to the UI.

B by bitacovir on 31 May 2020, edited 31 May 2020 # +2 votes

Unfortunately I am not a developer. I just started with my Python course these last weeks. My first goal is to create my first FC macro, soon. :)

R by ReD_CoDE on 31 May 2020, edited 31 May 2020 #

Take a look at the industry, everyone has started to develop an API-based platform

Personally I don't see any good future for IFC and BCF, especially "WHEN" they're too "noob" to be able to respond to changes at its right times

The industry won't wait years they develop solutions that many, especially big companies, have or are building

Yes, I know it's a standard, but who says we have to choose this standard or that standard?

M by Moult on 31 May 2020 #

@ReD_CoDE IFC and BCF is simply a schema. It is agnostic of the transport protocol, whether it is file based or API based. The very same BCF library can be used in an API form with a few tweaks, and it is exactly the plan to do so (see first post).

Both ISO, governments, and contract say we have to choose this standard. As much as I am astutely aware that IFC and BCF still have many faults, it is much, much better than anything else I have come across and there is a reason people are choosing it.

R by ReD_CoDE on 1 Jun 2020 #

@Moult A year ago I joined bSI forum with clear ideas that I constantly mentioned it "ISO19650 causes file sizes to increase" and do you know they don't have any plan in this area, IFC computationally is expensive even after migration to API-based

See the PLM industry, ask yourself why they built JT file format which is 10 times lighter, and then it became a standard, STEP AP242

Also, it's "model-based"

There're other obstacles that I won't talk about

Do you know why Autodesk corporate with "Aras"? do you think how many years takes BCF becomes like that?

Do you know why Autodesk uses "Node-RED"?

I don't say Autodesk is perfect but when I compare them with what bSI does, and what you even do, I don't feel alright

I said before the majority of European countries, including the UK, which Australia traditionally follows the UK schemes, always are behind of what the USA does

C by carlopav on 1 Jun 2020 # +2 votes

Sorry to arrive late, I just spotted the topic.

I still have low experience on IFC @Moult and I'd like to learn it, integrating it into the new FC arch tools i'm developing before throwing too much meat on the fire :)

Really interesting inputs @ReD_CoDE . From my side, I think I could live with very low tech standards... I think that most of the tasks 99% of the architects I know could be perfectly carried out with 2d DXF. And still are... So I'm not hasty in terms of having the best tools or using the best standard, I can live with something just open and usable :)

M by Moult on 1 Jun 2020 #

@ReD_CoDE several of your claims seem false. ISO19650 does not cause file sizes to increase. IFC is a schema, and so whereas one particular usage of a transport protocol might be computationally expensive, it doesn't mean IFC is computationally expensive. I don't see what a node-based UI has to do with BCF or IFC. Having a node-based UI is merely a thin graphical layer and does not affect any underlying system. Aras and BCF are two entirely different things.

R by ReD_CoDE on 2 Jun 2020, edited 2 Jun 2020 #

@Moult OK, do what you like to do

And I still will repeat "IFC and BCF are too weak for today needs"

S by StefanBoeykens on 9 Jun 2020 #

@ReD_CoDE said:

@Moult A year ago I joined bSI forum with clear ideas that I constantly mentioned it "ISO19650 causes file sizes to increase"

I think we discussed this in the past, but ISO 19650 is about the information management process and is not related at all to file sizes, APIs, or even IFC for that matter. I never read anything in ISO 19650 that points towards something like file sizes. Are you sure you aren't mixing things up somewhere?

R by ReD_CoDE on 9 Jun 2020 #

@StefanBoeykens Hi Stefan, just read ISO19650 implementation reports, especially the UK organizations

ISO19650 causes more information to be exchanged than before

Also, all international projects, especially some projects in the USA, Singapore, ..., are working on IDD, which is NOT about exchange information about ONE-TWO-THREE facilities, it's about massive amount of data/information and IFC and many other solutions are NOT suitable even after being API-based

R by ReD_CoDE on 9 Jun 2020 #

S by StefanBoeykens on 12 Jun 2020 # +1 votes

Since this discussion is actually on BCF... it is a good case in point on file sizes: BCF files can be small, but potentially become too large, e.g. if you select 1000s of elements and need to store all their guids to reference them. Especially if you start giving them all individual highlight Colors.

In the discussion of letting BCF evolve to BCF snippets, they may start to carry "change requests", e.g. object with guid X wants to change property Y to value 28. And this fits really well into an API-oriented and workflow oriented approach.

This is also the way into which IFC is evolving: becoming more transaction based and less like a static file dump. The same way that your image above is not about exchanging files, but having connected web services via APIs.

I see BCF playing a role into this, although, frankly, messaging and issue management systems exist from other domains and eventually, there is not that much in BCF that makes it so unique for the construction sector.

R by ReD_CoDE on 12 Jun 2020 #

@StefanBoeykens in the near future will share what was your mistakes, in bSI, and all software vendors who are part of bSI movement, bSDD, IFC, BCF, ...

And even Dion is following the wrong path, however, I won't stop anyone, even if I know they follow the wrong path

Just remember this: It's about a year I talk about "Data-Driven/Oriented-Design"