- From: Vladimir Alexiev <vladimir.alexiev@ontotext.com>
- Date: Mon, 15 Apr 2024 15:45:21 +0300
- To: BUS Nicolas <nicolas.bus@cstb.fr>, peter.bonsma@rdf.bg, Nataliya Keberle <nataliya.keberle@ontotext.com>
- Cc: public-lbd@w3.org
- Message-ID: <CAMv+wg4gQe1EACq8t_OQYZGw8O=2aEReGi7EVtHTfCDNA0+7eA@mail.gmail.com>
Hi Nicolas, thanks for the info! That's the IfcEngine by rdf.bg, right? And I see the older Zhang approach does the same. Nata, it converts to one of: - 3D meshes (using "TIN Z..."), - Axis Aligned Bounding Box (using "POLYHEDRALSURFACE Z..."), - Minimum Volume Bounding Box (using "POLYHEDRALSURFACE Z..."). Unfortunately I won't be at LDAC this year. But I'll be at the Digital Building Permit (DBP) conference until the end of this week, where the ACCORD and CHEK projects will have a discussion on this and related issues. Thomas Krijnen emailed with his approach, TUDelft has another approach, there's Oraskari's IFCtoLBD ... As Thomas said: it would be nice if the community can settle on some "standardized" approach. I hope we can discuss this and 2 more things at the DBP with OGC and others: - CityGML RDF representation, with similar concerns: how to capture geometry in literals, and how to avoid using "ADE" classes and props for extensibility - INSPIRE PLU RDF representation (that's for land-use) The IFC-RDF approach should align with GeoSPARQL as much as possible. The main issue with GeoSPARQL is the lack of 3D. It can store Z and M coordinates (for linear referencing) but doesn't do anything with them. So we also need to work out useful cases, as you write, relating to LOD1, LOD2, LOD2.5... > SVG, GLTF I think that OpenCascades is also used a lot. Such a format is great for full model visualization. There's no harm in keeping multiple representations of the same BIM, and the question/trick is which aspects of a full geometry are most important for the specific use cases. Thanks Nicolas! On Mon, Apr 15, 2024 at 2:57 PM BUS Nicolas <nicolas.bus@cstb.fr> wrote: > Hi Vladmir, > > We use an IFC renderer (https://github.com/opensourceBIM/IfcEngine) to > convert IFC implicit geometry to explicit vertexes (B-REP) and then > serialize it in WKT. > This approach has been inspired by Ruben de Laat and Chi Zang / Eindhoven > University works ( > https://pure.tue.nl/ws/portalfiles/portal/117493668/20190311_Zhang.pdf , > https://github.com/BenzclyZhang/IFC-to-WKT_Converter) > IfcOpenShell can also be used to extract geometry ( > https://ifcopenshell.org/ ) > From our point of view RDF geometry Level Of Detail has to be adapted to > use case needs : 2D WKT for floorplan based use cases, bounding box for LOD > 100, 2.5D (WKT polygon + height) or 3D for higher LODs > We only use RDF for inference purposes and still prefer SVG or GLTF for 2D > or 3D web rendering by using (eveBIM https://www.evebim.fr/telechargement or > IfcOpenSHell). > > Hope that helps > > Will you attend LDAC 2024 conference this year ? > > Regards, > Nicolas > > > > > > ------------------------------ > *De :* Vladimir Alexiev <vladimir.alexiev@ontotext.com> > *Envoyé :* dimanche 14 avril 2024 12:12 > *À :* public-lbd@w3.org <public-lbd@w3.org> > *Objet :* workable IFC-RDF conversion? > > Hi everyone! > What do you use to convert IFC to RDF with workable geometries? > Representing geometries with individual triples (eg EXPRESS lists, as > IfcOwl does) is imho not workable. > > We've tried IFCtoLBD but there are various issues > - see https://github.com/jyrkioraskari/IFCtoLBD/issues/106 for a diagram > - see https://github.com/jyrkioraskari/IFCtoLBD/issues/99 for a list > > Thanks in advance! >
Received on Monday, 15 April 2024 12:45:37 UTC