> For the complete documentation index, see [llms.txt](https://stage-precision.gitbook.io/grid/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stage-precision.gitbook.io/grid/spatial-interactive-experiences/understanding-spatial-sensor-data.md). # Understanding Spatial Sensor Data Spatial sensing systems can observe the physical world in very different ways. Some scan a single plane, others capture complete 3D environments, and camera-based systems may calculate depth for thousands of image pixels at once. Grid Studio brings these different sources into a common spatial representation so they can be aligned, combined, filtered, analyzed, and used for interaction. The important distinction is therefore often not how a sensor creates its measurements, but what information those measurements provide and what the project needs to detect. *** ## Spatial Points At the core of the spatial processing pipeline are points representing measured positions in space. A point normally contains a spatial position: * X * Y * Z Depending on the sensor, additional information may be attached to each point, such as: * Reflection or reflectivity * Intensity * Color * Other sensor-specific attributes These additional attributes remain part of the point data as it moves through the processing pipeline. They can also be visualized in the Viewport. For example, points may be colored uniformly, by distance, or according to sensor attributes such as reflection. {% hint style="info" %} Sensor attributes such as intensity, reflection, or color can be used to colorize the point cloud. The selected representation is not only useful for visualization. Filters later in the processing pipeline can also operate on this color information. For example, if a Color Filter should work with intensity values, the contributing Sensor Objects must represent their point data using the corresponding **Source** colorization. {% endhint %} *** ## 2D LiDAR Data A 2D LiDAR measures points along a single scan plane. At first glance this may appear fundamentally different from a 3D sensor, but inside a Grid Studio project the scan plane is positioned and rotated like any other spatial object. Once the Sensor Object has been aligned, every measured point has a position in the shared 3D project space. A 2D LiDAR can therefore contribute points to the same environment as a 3D LiDAR. For example, a horizontal 2D scan may add additional measurements around the legs of people while several 3D sensors observe the rest of the room. The clustering system does not need to treat these points as belonging to a separate "2D world". Once aligned, they are simply spatial measurements within the same environment. *** ## 3D LiDAR Data A 3D LiDAR captures points across multiple scan lines or a larger three-dimensional field of view. This produces a point cloud that directly describes surfaces and objects throughout the surrounding space. Depending on the sensor and configuration, the density of these points may vary significantly across: * Distance * Vertical scan angle * Horizontal scan angle * Surface material * Sensor resolution A point cloud should therefore not be understood as a solid representation of the environment. It is a collection of individual measurements with spaces between them. This becomes especially important during alignment, filtering, and clustering. *** ## Depth and Stereo Cameras Depth cameras and stereo-based systems create spatial measurements differently from LiDAR sensors. Instead of mechanically or electronically scanning individual laser directions, these systems may derive depth from techniques such as: * Stereo vision * Active illumination * Structured light * Time-of-flight imaging The result can still be converted into spatial points and placed inside the same Grid Studio project space. This allows depth-camera data to participate in the same general processing workflow as LiDAR data when the integration provides point-based spatial measurements. *** ## One Shared Coordinate System Each sensor initially measures the world relative to itself. Without alignment, two sensors looking at the same person may report that person at completely different coordinates. The purpose of sensor alignment is to transform those individual measurements into the shared Grid Studio project coordinate system. Once aligned: **Sensor A Point Cloud + Sensor B Point Cloud + Sensor C Point Cloud → Shared Spatial Environment** This is what makes multi-sensor installations possible. A project may combine: * Several sensors of the same type * Different models from different manufacturers * 2D and 3D LiDARs * LiDAR and depth-camera data The resulting points can then be processed together. *** ## Sensor Type vs. Application A common mistake is to design the project primarily around the distinction between 2D and 3D sensors. In Grid Studio, it is usually more useful to think about the final application. For example: **People Tracking** The goal is to identify and track complete people in a room. Any aligned sensor providing useful spatial points may contribute to that tracking result. **Touch Surface** The goal is to identify small interactions close to a particular surface. This requires a different spatial setup and typically a different clustering method. The deciding question is therefore: **What should this set of spatial measurements represent after processing?** That question determines the Point Cloud Volume, clustering method, filtering, and output strategy more directly than the sensor technology itself. *** ## From Measurements to Tracked Objects Raw spatial measurements are not automatically people, hands, or objects. Before Grid Studio can produce useful interaction data, the measurements typically pass through several processing stages: **Sensor Data → Alignment → Spatial Selection → Point Filtering → Clustering → Cluster Processing** The individual stages have different responsibilities. **Alignment** places all sensors into the same coordinate system. **Spatial Selection** removes parts of the environment that should not participate in tracking. **Point Filtering** reduces noise, background measurements, and unwanted points. **Clustering** groups related points into detected objects or interactions. **Cluster Processing** stabilizes and refines those detections over time. The result can contain information such as: * Object position * Cluster ID * Bounding Box * Object count These final results can then drive interactions, Zones, Workflows, data outputs, or local installation areas. *** ## Spatial Data and Image-Based Workflows The spatial processing pipeline described in this documentation focuses on point-based sensor data. Grid Studio can also work with RGB and infrared camera imagery, but those workflows follow a different processing approach and are not covered in this section. Spatial point data can, however, also be converted back into images. For example, a processed point cloud can be rendered as a depth image using a camera or the UV coordinates of a mesh. These images can then be sent to external real-time visual or interaction systems for additional processing. This allows the same spatial sensing environment to support both structured tracking data and image-based workflows. *** ## Next Steps With this basic model in mind, the next step is to build the complete processing pipeline. Continue with **Building an Interactive Tracking Project** to connect a real sensor, align it in the project, combine its data inside a Point Cloud Volume, and turn the resulting spatial measurements into interaction and output data.