- From: <peter.bonsma@rdf.bg>
- Date: Mon, 15 Apr 2024 16:15:39 +0300
- To: Vladimir Alexiev <vladimir.alexiev@ontotext.com>
- Cc: BUS Nicolas <nicolas.bus@cstb.fr>, Nataliya Keberle <nataliya.keberle@ontotext.com>, public-lbd@w3.org
Hi Vladimir and all, I am currently in Barcelona, but unfortunately cannot make it till end of the week here and will fly back to Sofia in Wednesday already. Of course I am always available for a talk in Sofia, the Friday afternoon pizza's were great last time :-) Personallhy I do not like the road of going to a mesh or something similar like a collection of polygons for example. Semantic Web / Linked Data should be about defining the semantics and this way we push out all semantics of geometry before even starting to use it. We just created a small converter from IFC to WKT (feel free to redistribute it, however not well tested so please send me feedback if there is an issue): https://rdf.bg/download/ifc2wkt-20240407.zip (./x64/Release/runme.bat, you can edit it in notepad to change the input files) Again, also here I think this is not the correct road but several people are asking for it; also in the context of improved GeoSPARQL with more 3D capabilities. In my perception we should try to convert the semantics in geometry towards an ontology, our first try (the GEOM ontology) has many issues but at least it captures the semantics. In practical use we combine it with technique where we can serialize any part of the geometry in a TTL file into a string (this string can be unpacked in a WASM web viewer to generate geometry for visualization for example). This allows us to 'pack' semantically poor geometrical representations with a lot of data in the triple store as a single or a few instances. Best regards, Peter. On 2024-04-15 15:45, Vladimir Alexiev wrote: > Hi Nicolas, thanks for the info! > That's the IfcEngine by rdf.bg [4], 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 >> [1] , https://github.com/BenzclyZhang/IFC-to-WKT_Converter [2]) >> IfcOpenShell can also be used to extract geometry ( >> https://ifcopenshell.org/ [3] ) >> 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! > > > Links: > ------ > [1] > https://pure.tue.nl/ws/portalfiles/portal/117493668/20190311_Zhang.pdf > [2] https://github.com/BenzclyZhang/IFC-to-WKT_Converter > [3] https://ifcopenshell.org/ > [4] http://rdf.bg
Received on Monday, 15 April 2024 13:53:00 UTC