I think it makes a lot of sense to start some sort of initiative under the ifcopenshell umbrella for something CDE-like: to cater to a new category of devs and to get ifcopenshell's rich ecosystem of tools available to a wider variety of end-users.
Existing initiatives to connect to such as forgejo / openproject / ...
Is 'it' a stand-alone project or a plug-in (I can imagine that some 3D viewing functionality for specific file formats is a nice addition to general hosted version control platforms)
I would say it makes sense to figure out some use cases to prioritize and draw an ecosystem map. In the end development will likely happen more organic and bottom-up, but setting out a vision might help to inspire some first contributors (even if they disagree https://xkcd.com/386/)
@aothms a file storage backend for IFC models makes sense if you are doing standard 'open bim' (where IFC models are basically snapshots shared as a reference, the real models live elsewhere).
For those doing Native IFC, git forges are ideal (even without fork/merge workflows). This could be a hybrid with generated data, ie. drawings and reports, placed in structured file storage rather than git.
Is there any serious prospect of IFC models being stored in server-side graph databases with client API access? This seems unlikely technically, and it has downsides in terms of potential for lock-in and rent-seeking.
These kind of efforts are fairly diffuse and low energy in our community, I'd rather aim a bit more ambitious and allow for graph db tech to catch up to our data volumes than aim for something that's mainstream now, but doesn't really inspire end-users or developers. I'm not too worried about lock-in if it is IFC.
Git is indeed a really nice middle-ground. For the non-semantic or non-text data you could also use sth like LFS. But I'd be a little bit worried about non-natively authored data and the scalability on huge data sets.
Even it we opt for a file storage backed system there is a lot of potential in the tooling we have around IFC, such as IfcTester or 4D that can see more adoption if we're able to offer a more integrated workflow.
I guess we also shouldn't make one choice, but rather standardize on the interfaces, build something modular and extensible, but it sound rather abstract in this case.
Let me know if something not working properly. I will soon bake some new IfcOpenShell worflow examples.
IFC5 and git-based design-platforms could be the perfect match, I guess... Exciting times !
Cheers,
Milovann
This funding campaign will cover costs associated with transferring and migrating the existing hub.openingdesign.com instance to hub.osarch.org, where it will be managed under OSArch's governance.
Meissa, a third-party consultancy, has developed a proposal to ensure a smooth migration to OSArch's platform.
Migration Steps
DNS & Certificate Update: Configure the OSArch domain name and update SSL certificates.
Server Configuration: Update the HTTP server to recognize the new domain.
Customization: Adjust branding, including text and logos, to reflect OSArch’s identity.
Proposed Fee
Migration Services | Fixed price for DNS, certificates, and branding |
€1,600
Support Services after Migration | Hourly rate for 2nd & 3rd level support (as needed) |
€80/hour
Note: Meissa will donate 10% of the project’s turnover to the open-source Forgejo project at codeberg.org.
Funding Matching
In line with OSArch’s funding campaign, all contributions to this project will be matched by OSArch's general funds.
This funding campaign will cover the ongoing monthly and periodical maintenance costs associated with this platform.
Current and Projected Costs:
Monthly costs: Currently around $75/month, which may fluctuate based on the number of users and storage requirements.
Maintenance: While the exact cost is still to be determined, a placeholder estimate of $3,000/year has been set for the time being.
Any surplus funds from this campaign will be allocated toward funding the development of additional, AEC-specific functionality on hub.OSArch.com. A few potential tools for future development are outlined below.
Current and Proposed Functionality
The platform will enable the OSArch community to effectively manage and share BIM content, with a focus on open collaboration via NativeIFC. Key benefits include:
Centralized Hosting for IFC Content Libraries
A space to host, maintain, and share IFC libraries for easy community access and contribution.
Code Sharing and Collaboration
A repository for code snippets, tools, and workflows shared within the community.
Support for Company Projects
A platform where companies can host both public and private projects, encouraging open-source adoption.
Tool Development
A space for collaborative improvement of community-driven projects like IfcMerge.
Integration of IFC Workflows
Over time, the platform could include advanced features such as an embedded IFC viewer and tools for IFC diffing and merging (demo).
Comments
I think it makes a lot of sense to start some sort of initiative under the ifcopenshell umbrella for something CDE-like: to cater to a new category of devs and to get ifcopenshell's rich ecosystem of tools available to a wider variety of end-users.
But we have some technological choices to make:
1)
2)
3
I would say it makes sense to figure out some use cases to prioritize and draw an ecosystem map. In the end development will likely happen more organic and bottom-up, but setting out a vision might help to inspire some first contributors (even if they disagree https://xkcd.com/386/)
@aothms a file storage backend for IFC models makes sense if you are doing standard 'open bim' (where IFC models are basically snapshots shared as a reference, the real models live elsewhere).
For those doing Native IFC, git forges are ideal (even without fork/merge workflows). This could be a hybrid with generated data, ie. drawings and reports, placed in structured file storage rather than git.
Is there any serious prospect of IFC models being stored in server-side graph databases with client API access? This seems unlikely technically, and it has downsides in terms of potential for lock-in and rent-seeking.
I don't know. I have some clients that use Neo4j, but I don't think it's full-fledged IFC. @krande made quite some progress with https://github.com/Krande/ifcdb And we also had some other people outlining the options: https://github.com/IfcOpenShell/IfcOpenShell/issues/4276#issuecomment-1927008332 Years back I heard good things about the scalability of https://github.com/dgraph-io/dgraph but it's unverified.
These kind of efforts are fairly diffuse and low energy in our community, I'd rather aim a bit more ambitious and allow for graph db tech to catch up to our data volumes than aim for something that's mainstream now, but doesn't really inspire end-users or developers. I'm not too worried about lock-in if it is IFC.
Git is indeed a really nice middle-ground. For the non-semantic or non-text data you could also use sth like LFS. But I'd be a little bit worried about non-natively authored data and the scalability on huge data sets.
Even it we opt for a file storage backed system there is a lot of potential in the tooling we have around IFC, such as IfcTester or 4D that can see more adoption if we're able to offer a more integrated workflow.
I guess we also shouldn't make one choice, but rather standardize on the interfaces, build something modular and extensible, but it sound rather abstract in this case.
Hi all,
Regarding Forgejo, I'm pleased to announce a new version of Git/AEC with a docker image ready to go if you want to give it a try :
https://gitaec.org
Let me know if something not working properly. I will soon bake some new IfcOpenShell worflow examples.
IFC5 and git-based design-platforms could be the perfect match, I guess... Exciting times !
Cheers,
Milovann
@mko cool! Seems like there could be some excited synergies here!
Sorry the delay, but wanted to wait until the holidays were over, before initiating the following campaigns.
OSArch's Git Platform: Transferring the Instance
go here to help fund: https://opencollective.com/osarch/projects/hub_osarch_migration
This funding campaign will cover costs associated with transferring and migrating the existing hub.openingdesign.com instance to hub.osarch.org, where it will be managed under OSArch's governance.
Meissa, a third-party consultancy, has developed a proposal to ensure a smooth migration to OSArch's platform.
Migration Steps
Proposed Fee
Migration Services | Fixed price for DNS, certificates, and branding |
Support Services after Migration | Hourly rate for 2nd & 3rd level support (as needed) |
Note: Meissa will donate 10% of the project’s turnover to the open-source Forgejo project at codeberg.org.
Funding Matching
In line with OSArch’s funding campaign, all contributions to this project will be matched by OSArch's general funds.
OSArch Git Platform: Monthly Expenses
go here to help fund: https://opencollective.com/osarch/projects/hub_osarch_monthly_expenses
This funding campaign will cover the ongoing monthly and periodical maintenance costs associated with this platform.
Current and Projected Costs:
Any surplus funds from this campaign will be allocated toward funding the development of additional, AEC-specific functionality on hub.OSArch.com. A few potential tools for future development are outlined below.
Current and Proposed Functionality
The platform will enable the OSArch community to effectively manage and share BIM content, with a focus on open collaboration via NativeIFC. Key benefits include:
Centralized Hosting for IFC Content Libraries
Code Sharing and Collaboration
Support for Company Projects
Tool Development
Integration of IFC Workflows