Features or geometry?

Help
, ,
1

I have for some time tried to become familiar with Speckle. My background is from BIM/GIS information modelling. Seems like Speckle prefer geometry to feature types:

  • when transferring a dataset with pipelines and manholes from a QGIS project, it ends up in the Speckle web browser as PolyLines and Points.
  • when transferring IFC entities with attributes and propertyTypes from Speckle (filled up using IFC file import), transferring it into QGIS ends up with geometry (Mesh type) instead of the IFC entity names and attributes.

Is this

  1. a general truth for Speckle?
  2. a remaining challenge for the QGIS connector?
  3. caused by my lack of knowledge of Speckle?

I have also searched for the mapping setup of information used in the connectors. Sure there must be one. At least the IFC information is modified through the QGIS connector.

Anyone interested in helping, e.g. pointing to proper user guides/documentation?

Regards
Erling Onstein
Norway

2

Thanks for sharing your experience with understanding Speckle, given your background. As you noted, Speckle primarily transfers geometry data and associated metadata as the default. Each connector and the web assumes a basic fallback to a Mesh display with metadata, but this is a crude simplification.

While we don’t think of the translations of IFC → QGIS, we imbue the Connectors with an “understanding” or mapping from Native Type → Speckle Type and Speckle Type → Native.

Speckle mappings are our dynamic response to deliver solutions to our users. A constantly evolving platform that is designed to support a wide range of object types where it makes sense to do so. We like to consider these as supporting specific workflows. It is tempting to try and take any format of 3d data and present it in any of the supported applications, but this isn’t how users are trying to solve problems with Speckle.

Rather than deal in the general case of what any IFC object translates to in a GIS application beyond the default, we’d like to hear specific cases we can test and build upon.

Take IFCWall, a staple BIM object; in a GIS context, what is the ideal representation of this? QGIS has only a few geometry types in its armoury and doesn’t currently have specific mappings for any BIM elements beyond the Mesh + Metadata fallback. What should the opinionated view be? Is it the support for the 3Dimentsional entity that the wall represents, or something else?

If a Wall is a member of an IFC_Collection with its own property sets, how should this metadata be represented on the eventual GIS feature? We’re always open to suggestions! :smiley:

As a community-driven effort, Speckle relies on user feedback like yours and contributions to expand its capabilities and support new workflows and use cases. If you have specific feedback or suggestions for how Speckle can better support your workflows, I encourage you to share them :pray:t2:.

So answers your questions 1,2 & 3 - yes, yes & no, you have a handle on it but we’re happy to address any further questions to help grow your understanding

3

Thanks for clarifying answer.

I understand streaming data from one platform/software to another is a very challenging task,

I let the complicated geometry streaming be without comments her. Finding a working solution on this is challenging, and the Speckle way of doing it, seems good. At least so far.

But the handling of attributes/properties i had expected could be easier to follow.
The legend in QGIS, after receiving IFC-data, seems rather cryptic, see QGIS_Legend

When I see the structure of the QGIS attribute table, I find that important parts of the IFC structure in fact have “survived” the translation and are available in QGIS, see QGIS_IFC_Attributes.

Here it seems like the attributes “ObjectType” and Speckle_ID" has been selected as the visible attributes in the QGIS legend. I would rather prefer attribute “type” in the QGIS Legend (replacing Speckle_ID).

Is this kind of modification possible in an easy way using the Github open code?

(I must admit I am not quite sure of possible negative consequences of my suggestion. My wish is to easier understand which IFC entities are hiding behind the legend items. I see there is a grouping of entities also, level one in the legend. Unsure what this is. And I see the limitations with QGIS just showing a 2D picture of the 3D IFC data.)

If this is of interest, I could also follow up the pipeline example from QGIS to Speckle. Might be better directly to jonathon?

4

That is a valid observation!

We have recently introduced a new Base class for collections. All the applications we support now use this to a degree. It will be useful as we implement handling them better in all the receiving Connectors. IFC and Navisworks, in particular, deeply nest objects within collections of collections - which is why you see elements_elements_elements...

Looking at your legend example, we could surface the Collection types and Element types in constructing and naming the QGIS Layers. Whether it is preferable to name this way or construct groups of groups of layers, we can debate with the GIS team.

You are more than welcome to contribute to the QGIS connector if you are familiar with Python. @Kateryna owns that project and can review any submission you wish to make. It would be best to raise an issue on the repo before commencing as we don’t want any effort to go wasted, and fitting into the roadmap will be helpful: QGIS - speckle-qgis.

Kateryna is presenting at the QGIS conference this week!

image

6

Soo many good points! Jonathan already covered most of it, just some extra notes:

  • The QGIS legend in based on the object structure, which you can check in the web view after uploading an IFC model (“Expand data view”). QGIS is going through multiple levels of the objects and bringing them on the same hierarchical level, which might not be an optimal way, here some use cases would really help with understanding/organizing the legend better.
  • “elements” within “elements” naming issue is a known one, and it hurts my eyes too :see_no_evil: It’s a recent change and we need to work on the naming.
  • The attributes are not selected individually, these are all directly “unpacked” properties from the Speckle object. Renaming them on the fly might be done, but it needs to be universal in a way to work with, let’s say, all IFC data types. It also needs extra caution to not clash with reserved attribute names or any properties the other models might potentially have.
  • Speckle_ID is the only property implemented in a “hacky” way, with a sole purpose is to differentiate between individual features within a layer. It is currently used to assign Symbology renderers to the features (as it’s the only fully “individual” property of any object, and can be associated with individual material/color). It is especially needed for non-GIS originated geometry, where each object can have it’s own color, but when imported in QGIS it needs some kind of rule to do so. Basically the first level of groupings that you see is just a layer itself, with expanded symbology based on Speckle_ID value.
  • 3d data should be visible unless we introduced a new bug :smiley: In View → 3D Map Views
    → New 3D Map View. Let me know if it’s not and, if possible, attach a Stream link so I can take a look (you can pm me if you don’t want to publicly share it).

But coming back to the basic issue, I definitely agree the legibility of the elements should be improved, and we might need to wait a little bit, as the Speckle objects are now undergoing restructuring and might soon have a better way to identify themselves.

I would also be curious to know more about the case, why would it be useful to import IFC model into QGIS, and how to process it there further? Also, given the structure of the IFC model uploaded to Speckle, and given the structure of the object properties, how would you see an “ideal” legend and ideal attribute table? Any follow up and any examples are very welcome!

2 Likes
7

I have made a document where I explain my “testing”. Would rather send it as a personal message than uploading it here. Any address for such?

8

Just followed up in a private message with you and @Kateryna :slight_smile: