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).
Lots of progress with adapting forgejo for this job, I need to put up a public instance of this (somebody remind me if I haven't in the next couple of weeks, though feel free to install and play with the code in git in the meantime):
Native IFC collaboration tools: a git-aware IFC viewer integrated into an IFC-aware forgejo mod. Tied together with an ifc:// URL scheme that allows sharing exact IFC versions and viewpoints as persistent links
@Moult said:
I'm just fishing in case someone knows something about the state of open source CDEs that's more than what's been mentioned here. I would love an open source Aconex replacement.
Are you aware of this https://www.openproject.org/bim-project-management/ ? I have not yet given it a try but would love to. AFAIK OpenSource but developed by a Company who earns money with it. It comes from project management and has put a ifc viewer on top of it.
This is a 'forge' very much like Github, except that it knows about IFC files, so:
Each commit gets an inline preview of the model showing what has changed
Each IFC file has a link to open the model in a 3d web viewer at whatever revision you like
The web viewer has tools to query entities, filter using the ifcopenshell selector syntax, create viewpoints and save them as a simple ifc:// URL
These URLs can be used in issues and discussions where they automatically embed previews of that viewpoint (with whatever filtering and clipping you like) that are also clickable links to open the model in the 3d viewer (with that exact flter and viewpoint)
These ifc:// URLs are completely compatible with BCF, so you can download a BCF if you like that sort of thing (you can also drop one of these bcf files into the viewer and it will open with that viewpoint)
Pull requests show a preview with new elements green, modified blue, and deleted red - this preview is zoomed to the part of the model that shows the changes
ifcmerge is installed on the server, so you can merge pull requests in the browser
There is probably other stuff I forgot, but actually I think the coolest thing is this ifc:// URL scheme that makes it finally possible to discuss BIM models and show what you are talking about at the same time.
(Contact me if you would like an account on this test server)
@brunopostle said: @theoryshaw I hadn't even checked that ssh access was enabled, yes this looks like a simple http POST size limit, will fix when I get a chance.
ssh access should be enabled now on https://hub.postle.net/, the paths have forgejo@ instead of git@, but apparently this is normal.
@brunopostle said:
ssh access should be enabled now on https://hub.postle.net/, the paths have forgejo@ instead of git@, but apparently this is normal.
I've configured outgoing email, the only thing left I think is actions/runners - we can do IFC validation and IDS checking server-side on every commit, do we want this? (I'm underimpressed by IDS so far, and there is no reason this sort of thing can't be automated in Bonsai for example)
IDS only allows you to work with Attributes and Properties, but it disallows virtual and inverse attributes, so all the interconnected richness of an IFC model is invisible.
Regarding implementing IDS checking in Bonsai, I have configured a couple of Github repos so that any IDS files in a IDS/ folder in a repo are automatically checked against IFC files in the repo whenever you push - this is zero effort once you set it up and you get email alerts once tests start failing (you can copy this config from one of my test repos, or I'll find a link).
..but I don't see how this scales, for every commit Github spins up a VM, installs the entire ifcopenshell stack, runs all the tests, then deletes the VM. We can do exactly the same with forgejo, but I'm not sure I want to (maybe we create a VM image that already has the stack installed).
Bonsai has IDS functionality, but this is hidden away, we should have a similar system where Bonsai is automatically checking your model using whatever IDS files are found in a designated folder - you should be able to set this up and forget about it until it finds a problem with your data.
I think IDS is good for basic model validation but you're right it's current implementation doesn't leverage the full extent of the IFC schema (can't do half what proprietary apps or IOS can do) however it is very good as converting a Clients EIR into 'quick checks' of model outputs. Personally I really like the idea of it being integrated as an option for running against models hosted on the Git as it could in future be wrapped into workflows.
defer to you. Long story short, server costs will be a factor.
It looks like it will work, podman images with the whole ifctester stack preinstalled will spin up in a few seconds and won't consume any bandwidth.
In general I don't see an easy way to have an open signup free service for any of this, at least initially, it would be easy for somebody with an account to DOS an IFC git service running on a single vps host.
Best approach would be using something like Docker Swarm/Kubernetes over multiple machines (these can be local desktops rather than expensive VPS's) then using a load balancer in conjunction with some form of VPN/Reverse Proxy (NGINX Proxy Manager/Pangolin/Netbird) to connect it all up. You could then just have a dedicated IfcTester machine then is connected to the swarm via VPN.
In general I don't see an easy way to have an open signup free service for any of this..
I have a feeling, we should have a point threshold for its use. That is, if you're over 30 points (which is basically nothing), in the forum, you can get login credentials. That would curtail spammy accounts.
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
Lots of progress with adapting forgejo for this job, I need to put up a public instance of this (somebody remind me if I haven't in the next couple of weeks, though feel free to install and play with the code in git in the meantime):
This has just about every feature I can think of, more information here: https://github.com/brunopostle/ifcurl
Hi @brunopostle, i didn't know where to post the following.
https://chatgpt.com/share/6a0a777f-c6e4-83ea-a7c0-e177baf96beb
was trying to push this repo: https://hub.openingdesign.com/OpeningDesign/3_Season_Porch_URGC
long story short. Got an error pushing a big blob that doesn't use git-crypt.
For large blob files, that need to be encrypted, i don't use lfs because they don't play nicely with each other.
I might start playing around with https://github.com/FiloSottile/age instead of git-crypt to avoid this problem.
https://chatgpt.com/share/6a0a7b46-6e04-83ea-8d7b-ea24908d6650
Are you aware of this https://www.openproject.org/bim-project-management/ ? I have not yet given it a try but would love to. AFAIK OpenSource but developed by a Company who earns money with it. It comes from project management and has put a ifc viewer on top of it.
@theoryshaw I hadn't even checked that ssh access was enabled, yes this looks like a simple http POST size limit, will fix when I get a chance.
Everyone else, I have put an instance of this mod here: https://hub.postle.net/explore/repos
This is a 'forge' very much like Github, except that it knows about IFC files, so:
There is probably other stuff I forgot, but actually I think the coolest thing is this ifc:// URL scheme that makes it finally possible to discuss BIM models and show what you are talking about at the same time.
(Contact me if you would like an account on this test server)
@brunopostle
needs to be more breezy! :)
https://hub.postle.net/assets/viewer.html?url=ifc://hub.postle.net/bruno/brown-street@d22893bad672920e4ff3cc7604b03164f7d92d9d?path=model.ifc&camera=38.9646,29.5067,4.5353,-0.5347,-0.8448,-0.0222,0,0,1&fov=60
test bcf export.
oh, man this is so cool!
ssh access should be enabled now on https://hub.postle.net/, the paths have forgejo@ instead of git@, but apparently this is normal.
I've configured outgoing email, the only thing left I think is actions/runners - we can do IFC validation and IDS checking server-side on every commit, do we want this? (I'm underimpressed by IDS so far, and there is no reason this sort of thing can't be automated in Bonsai for example)
@brunopostle could you better explain this?
IDS only allows you to work with Attributes and Properties, but it disallows virtual and inverse attributes, so all the interconnected richness of an IFC model is invisible.
Regarding implementing IDS checking in Bonsai, I have configured a couple of Github repos so that any IDS files in a
IDS/folder in a repo are automatically checked against IFC files in the repo whenever you push - this is zero effort once you set it up and you get email alerts once tests start failing (you can copy this config from one of my test repos, or I'll find a link)...but I don't see how this scales, for every commit Github spins up a VM, installs the entire ifcopenshell stack, runs all the tests, then deletes the VM. We can do exactly the same with forgejo, but I'm not sure I want to (maybe we create a VM image that already has the stack installed).
Bonsai has IDS functionality, but this is hidden away, we should have a similar system where Bonsai is automatically checking your model using whatever IDS files are found in a designated folder - you should be able to set this up and forget about it until it finds a problem with your data.
I think IDS is good for basic model validation but you're right it's current implementation doesn't leverage the full extent of the IFC schema (can't do half what proprietary apps or IOS can do) however it is very good as converting a Clients EIR into 'quick checks' of model outputs. Personally I really like the idea of it being integrated as an option for running against models hosted on the Git as it could in future be wrapped into workflows.
defer to you. Long story short, server costs will be a factor.
It looks like it will work, podman images with the whole ifctester stack preinstalled will spin up in a few seconds and won't consume any bandwidth.
In general I don't see an easy way to have an open signup free service for any of this, at least initially, it would be easy for somebody with an account to DOS an IFC git service running on a single vps host.
Best approach would be using something like Docker Swarm/Kubernetes over multiple machines (these can be local desktops rather than expensive VPS's) then using a load balancer in conjunction with some form of VPN/Reverse Proxy (NGINX Proxy Manager/Pangolin/Netbird) to connect it all up. You could then just have a dedicated IfcTester machine then is connected to the swarm via VPN.
I have a feeling, we should have a point threshold for its use. That is, if you're over 30 points (which is basically nothing), in the forum, you can get login credentials. That would curtail spammy accounts.