Re: workable IFC-RDF conversion?

Hi all,

Hope you had a great conf. If there's any conclusions on this I'd love to
hear them.

For me going to WKT has two reasons:
- it can be CRS-aware, so you can even harmonize geometries that come from
differently georeferenced models, or maybe use a custom project-specific
CRS definition for eastings + northings so that the actual vertices
themselves can remain somewhat similar to the engineering coordinates.
- they can go right into an indexed geometry column in PostGIS so you can
do efficient (3d!) spatial queries on them in a database context. what I
tried to do in [0] is to connect the 3d-aware sql functions in postgis to
the predicates in GeoSPARQL. This worked well, but marmotta as a project
has been moved to "the attic" and its GeoSPARQL implementation never was
merged into the main branch to begin with, so it didn't prove to be a very
future-proof basis to experiment upon. I wouldn't advise to look into this
specifically anymore, but conceptually it's not so hard.

This is of course specific to a use case where you'd ingest a lot of data
and want to do some querying on those. I imagine there can be other use
cases where a more parametric/semantic view on the geometry needs to be
retained.

[0] https://github.com/aothms/marmotta

Kind regards,
Thomas


Op ma 15 apr 2024 om 15:54 schreef <peter.bonsma@rdf.bg>:

> 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
>
>
>