Overview
When receiving data from Speckle, you’ll encounter three distinct types of data structures. Understanding which type you’re working with helps you choose the right approach.The Three Types
Type 1: Custom Data
What it is: Data you create from scratch with your own structure. Characteristics:- Simple Base objects with custom properties
- No connector-specific structure
- Direct property access
- Full control over schema
- Python-to-Python workflows
- Custom data pipelines
- Analysis results you’re sending
- Data you control end-to-end
Type 2: Simple Model Data
What it is: Geometry with attached properties, typically from simple exports or scripts. Characteristics:- Geometry objects (Point, Line, Mesh)
- Properties as dictionaries or direct attributes
- Optional
displayValuefor visualization - Material and layer information
- Moderate nesting (1-2 levels)
- Grasshopper exports
- Rhino script outputs
- Simple geometry with metadata
- Blender basic exports
- CAD-like data
Type 3: Complex BIM Data
What it is: Rich application data from BIM tools with complex nested structures. Characteristics:- Deep nesting (3+ levels)
- Rich property collections
- Display value proxies
- Encoded native data
- Instance/definition patterns
- Data chunk references
- Connector exports from any BIM authoring tool
- Rhino exports with complex objects
- ArchiCAD, Revit, Tekla exports
- Any application with rich metadata
Quick Decision Tree
Modern Approach: Instead of checking
speckle_type strings, check for structural patterns: Does it have a properties dict? Does it have displayValue? Is it a geometry class? This works reliably across all Speckle versions.Key Differences
- Structure
- Access Pattern
- Traversal
Custom Data:Simple Model Data:Complex BIM Data:
Practical Implications
Custom Data
✅ Pros: Simple, predictable, fast❌ Cons: No standard structure, manual schema Best for: Analysis results, custom pipelines, Python-to-Python
Simple Model Data
✅ Pros: Geometry-focused, moderate complexity❌ Cons: Limited metadata, manual property inspection Best for: Visualization, simple exports, geometry processing
Complex BIM Data
✅ Pros: Rich information, application semantics❌ Cons: Complex structure, defensive code needed, larger data Best for: BIM workflows, detailed analysis, cross-application exchange
Collections and Hierarchy
The elements Convention
Speckle uses a standardized convention for organizing hierarchical data: the elements property. This property has a special meaning and is the predictable way to traverse object hierarchies.
Key Concepts:
- Atomic Objects - Objects that represent actual “things” (walls, beams, points, etc.)
- Property Objects - Objects stored as properties for reference (materials, styles, etc.)
- Container Objects - Objects that organize other objects via
elements
Why
elements?While any property can technically contain Speckle objects, elements is the internal convention for managing hierarchy in a predictable way. This allows traversal code, connectors, and the viewer to consistently understand object relationships.Some typed properties also expect arrays of objects (like displayValue), but these serve different purposes - displayValue is for visualization, while elements is for logical hierarchy.Collections
TheCollection class formalizes this pattern:
name- Human-readable name (not necessarily unique)elements- List of contained objects (can include nested Collections)applicationId- Unique identifier for the collectionspeckle_type-"Speckle.Core.Models.Collections.Collection"
Collections map to familiar organizational structures:
- Rhino/AutoCAD - Layers
- Blender - Collections
- Revit - Categories or Worksets
- Custom - Any logical grouping you define
Atomic vs Property Objects
Understanding the difference helps you structure data correctly: Atomic Objects (stored inelements):
- Represent actual entities in your model
- Should be traversed when processing the model
- Examples: walls, beams, points, meshes, equipment
- Referenced by atomic objects
- Provide metadata or configuration
- Examples: materials, render properties, styles, definitions
Traversing with elements
The elements convention enables predictable traversal:
Not all objects use
elementsSimple geometry objects (Point, Line, Mesh) typically don’t have elements - they are leaf nodes. Always check hasattr(obj, "elements") before accessing it.Mixing Types
Real-world data often mixes types, organized using theelements convention:
Summary
Custom Data
You create it
- Direct access
- Simple structure
- Full control
Simple Model
Geometry + Props
- Properties dict
- DisplayValue
- Moderate nesting
Complex BIM
Rich BIM Data
- Deep nesting
- Properties dict
- Defensive code
- Custom → Direct property access
- Simple → Check common properties
- Complex → Defensive traversal