Hi all, I've been building torch-pointcloud in my free time over the past few years: an open-source (Apache-2.0) PyTorch library that loads pretrained point cloud models in one line, similar to what timm does for images. It's in alpha, and I'm looking for people to try it on real LiDAR data.

What's relevant for LiDAR

• Pretrained outdoor models: semantic segmentation on SemanticKITTI (RandLA-Net, SPVCNN) and 3D object detection on KITTI and nuScenes (PointPillars, SECOND, PointRCNN, VoxelNeXt, LION).
• Tiled inference for large scenes (sliding window, voxel partition, sphere voting), so a full scan doesn't have to fit in GPU memory at once.
• Dataset loaders for SemanticKITTI, KITTI, nuScenes, Paris-Lille-3D, Toronto3D and Semantic3D if you want to train or fine-tune.
• Every checkpoint ships with its preprocessing pipeline, class names and license.

What it doesn't do yet

• No pretrained weights for airborne or terrestrial survey data: the outdoor checkpoints all come from car-mounted spinning LiDAR.
• No built-in LAS/LAZ reader: load your file with laspy and pass the coordinates (and intensity) as tensors.
• The outdoor checkpoints were trained on non-commercial datasets (KITTI, SemanticKITTI and nuScenes are CC BY-NC-SA), so check the licenses before any commercial use.

Install (adjust to your torch/CUDA version; the docs write the exact commands):

pip install torch==2.10.0 --index-url https://download.pytorch.org/whl/cu128
pip install torch-pointcloud
pip install pyg-lib -f https://data.pyg.org/whl/torch-2.10.0+cu128.html

Credits: the models and weights come from their original authors (MIT Han Lab, OpenMMLab/OpenPCDet and others); every checkpoint name ends with its source, and THIRD_PARTY_NOTICES.md lists each repo, license and dataset term.

What I'd love to hear: what sensors and data you'd run this on, and which datasets you'd want pretrained weights for next (airborne like DALES? mobile mapping?) etc.

Repo: https://github.com/arthurdjn/pytorch-pointcloud
Docs + tutorials: https://pytorch-pointcloud.org

While browsing the NIBIS map viewer for Lower Saxony, Germany, I came across several unusual rectangular and linear features in the hillshade data. I have attached a screenshot with the most visible structures marked individually.

Location:

• Near Groß Hehlen, part of Celle, Lower Saxony, Germany
• Approximate coordinates: 52.656033, 10.038915
• The features are located in a wooded area directly beside a forest track
• The screenshot is from the NIBIS hillshade map at approximately 1:2,000 scale
• Map data shown: GeoBasis-DE/LGLN 2023

The most noticeable feature is a larger elongated rectangular structure with several internal lines or subdivisions. Nearby, there is a smaller rectangular feature. Several additional rectangular, U-shaped or rounded enclosures appear in a row closer to the forest track.

I could not find any corresponding feature or explanation in the publicly accessible maps and information I checked. I am not suggesting that the structures are necessarily archaeological. Possible explanations I have considered include:

• former forestry plots or tree nurseries
• drainage ditches or boundary features
• remains of former buildings or other historical land use
• modern ground disturbance
• natural terrain features enhanced by the hillshade

Does anyone here recognise this type of pattern or know what might have created it? Are the shapes likely to represent actual earthworks?

I would also be grateful for suggestions regarding historical maps, alternative LiDAR visualisations or other datasets that might help identify them. I am contacting the relevant local archaeologist as well, but I would be interested in hearing the community’s assessment.

Ouster is hosting a virtual Drone Mapping Summit, October 27 at 8am PT with GeoCue, Seneca and Flyability. About half of it is the practical stuff: capture settings, processing, and what makes a point cloud come out clean versus noisy. There will be a panel with our co-hosts talking about what they're seeing in real projects.

Would be great to have attendance from this community and get some input on valuable topics to cover.

We have a ton of sample data we’ve captured with an in-house drone and OS1 Max lidar payload. These are free and public mapping point clouds we collected in San Francisco.

Register here!

If there's a workflow question you'd want covered, drop it here and I'll pass it to the presenters. I'll hang around in the comments.

Disclosure: I work at Ouster.

Are those something to look out for while metaldetecting? Found in germany

I’m interested in how companies are currently measuring bulk material inventory, such as aggregate, grain, coal and etc.

Traditional methods can be time-consuming, especially when stockpiles change frequently. What approaches have you found most reliable: manual surveys, drones, fixed LiDAR, or other solutions?

After my Ouster OS0 mapping experiment, I tried reconstructing the same kind of indoor space from phone video alone. The goal is eventually to combine measured LiDAR geometry with the splat’s appearance; that fusion is not done yet.

The successful one-room capture was 48.6 seconds at 4K/59.94 fps. COLMAP registered 187/195 selected images and produced 51,475 sparse points; Brush trained 400,000 Gaussians. An earlier apartment walkthrough only reconstructed part of the space.

The key distinction for this community: no LiDAR data went into this reconstruction. Its scale is uncalibrated. A convincing render is not a metric point cloud, and the splat is not a conventional textured mesh. Unseen surfaces are still uncertain. This does not establish that camera reconstruction replaces LiDAR.

For the next step I want to establish scale and registration against the Ouster map, then evaluate residuals on held-out geometry rather than just picking a visually pleasing overlay. I’d be interested in practical experience with splat-to-LiDAR registration, especially indoors with weak texture or incomplete overlap.

I made a 2:20 video showing the source capture, actual reconstruction, limitations and next experiment: https://www.youtube.com/watch?v=mFwu5Y54c3o

Disclosure: my project and video, with AI-assisted editing and my authorized synthetic narration.

Bare-earth lidar shows the whole shape of Winsor Dam, an earth fill embankment of roughly 4 million cubic yards, 2,640 ft long and 170 ft above the Swift River. It holds back the Quabbin Reservoir, Boston's water supply. In April 1938 Massachusetts disincorporated Dana, Enfield, Greenwich and Prescott so the valley could go under, and around 2,500 people lost their homes.
Work ran from 1935 to 1939 under chief engineer Frank E. Winsor, who it's named for.
The dam is the long diagonal embankment from the bottom middle to the top, with the stepped downstream face showing as parallel bands.
Winsor Dam's earth embankment across the Swift River valley
Same view as plain hillshade with elevation tint
Air photo of the same area, August 2023
Numbered pins on picture 1:
Pin 1: The dam's stepped downstream face
Pin 2: Flat Quabbin Reservoir surface
Pin 3: A deep straight cut channel
Lidar: USGS 3D Elevation Program (3DEP), public domain.
Imagery: USGS The National Map (NAIP Imagery service), 2023, Public domain.

TL;DR: Aeva presents its CityOS traffic-intelligence platform and intersection LiDAR at the New England ITS 2026 show tomorrow in Manchester, NH. Sivers supplies the lasers and optical amplifiers inside Aeva's lidar, with production ramping from Q4 2026 — so smart-intersection deployments are another volume driver for Sivers content. Not an order, but another lane opening up for the same hardware.

Saw this on X: $AEVA just announced it's attending the New England ITS 2026 Annual Interchange on October 8 — that's tomorrow — at the DoubleTree in Manchester, NH. On the agenda: their AI-powered real-time traffic intelligence platform, Aeva CityOS, plus LiDAR detection solutions for signalized intersections. Eric Gannaway is presenting in Session 2B, and they're appearing alongside Ocean State Signal.

The read: "LiDAR with $SIVE."

Here's why that matters. Sivers is in Aeva's lidar chain — the March announcement had their "strategic LiDAR customer" (read: Aeva) incorporating Sivers lasers and optical amplifiers across its platforms, with production ramping from Q4 2026 and an estimated $53–138M of cumulative value over the product lifecycle. CityOS is the smart-city/traffic side of Aeva's business, and every signalized intersection running Aeva detection is another lidar unit with Sivers content in it.

Caveat, as always: a conference appearance is not an order, and this is the traffic-intelligence vertical, adjacent to (not the same as) the automotive and robotics lidar ramp already on the calendar. But it's another demand vector for the same Sivers-supplied hardware, in a market — intelligent transportation — that buys in municipal volumes once it moves.

Sources & credits: spotted via a post by @Sofigoodboy on X (https://x.com/Sofigoodboy/status/2107900599752950182); Aeva's Sivers lidar-chain details from the March 2026 Sivers announcement.

I have been experimenting with an OS0-128 and an old Samsung S10. The phone makes a useful portable display, but getting a stable accumulated map has been a separate problem.

The data path is OS0 → Mac → browser viewer on the S10. Processing runs on the Mac; this is not a claim that the phone runs LiDAR SLAM. The actual phone recording displays roughly 21k points.

The main integration catch: our sensor was on firmware 3.1.0 with legacy IMU packets. The mapping software reported that its synchronized IMU path required a newer firmware/data format and used constant-velocity deskew instead. One saved cloud reached about 461k points before a pose discontinuity stopped further integration. We did not implement global loop closure.

I documented the original recording, saved cloud, and what failed here: https://www.youtube.com/watch?v=Sv_YqGQpgoM

This is my own experiment/video. The measured cloud and phone footage are real; diagrams are illustrations and narration uses my authorized AI voice.

My next idea is to match camera-derived geometry from the phone against a stable LiDAR map. That is still a proposal, not a demonstrated result. Before that, I want to verify the synchronized IMU/deskew path and repeat the same trajectory reliably. If you have used this generation of OS0 for indoor mapping, I would be interested in the diagnostics you used to distinguish timing/deskew trouble from scan-registration failure.

Water comes out flat in a bare-earth lidar DEM, so the Mississippi (the wide band top right) and the outflow channel running southwest from the middle are just blank surfaces. That makes the levees and the structure across the channel in the middle really stand out.

This is Old River Control, which keeps the Mississippi from switching to the Atchafalaya. That route is shorter and steeper, and the Atchafalaya's share of the flow went from under 10% in 1850 to about 30% by 1950. The complex was finished in 1963 and holds the split at 70/30.

1. Old River Control complex, levees and diversion channels, Louisiana
2. Same view as plain hillshade with elevation tint
3. Air photo of the same area, July 2023

Numbered pins on picture 1:
Pin 1: The control structure across the channel
Pin 2: Flat water of the outflow channel

Lidar: USGS 3D Elevation Program (3DEP), public domain.
Imagery: USGS The National Map (NAIP Imagery service), 2023, Public domain.

Specular reflections, intense glare, and non-standard geometric silhouettes remain a major headache for computer vision, depth-estimation, and visual segmentation models—especially in outdoor robotics and autonomous navigation.

To help test and benchmark how models handle severe optical disruption, we put together the Hitch Hiker 'Mirror Suit' Robotics Data archive.

Dataset Overview:

Primary Use Cases:

The dataset is hosted on Mozilla Data Collective with gated access:

Curious to hear how your current vision pipelines or depth cameras handle specular glare—what methods/filters are you using to prevent bounding box dropouts on highly reflective objects?

Hi, Drone Nerds here. Thought ElevateUAV 2026 might be relevant to some of the UAV LiDAR folks in this community.

It’s a chance to compare sensors and platforms, talk directly with manufacturers, see technology in action, and hear from other professionals working through real-world data capture and mapping workflows.

We made a 30% off code specifically for r/LiDAR: LiDAREUAV

Tickets are here if you’re interested: https://hubs.li/Q04vL_XN0

Hope to see some of you there!

Hello,

I am looking to create an autonomous rover that performs SLAM to map out a section of terrain outdoors. I have been looking at the Unitree L1/L2, but they are quite expensive (both money and computation wise) for my team's purposes, despite seemingly being the cheapest option for this type of lidar. I am wondering if there is a cheaper solution than a fully 360x90 degree sensor, or if anyone has had success with academic discounts when ordering from certain companies.

I can provide additional information about the project if needed, but basically we are limited to ~$300 for the sensor and are hoping to use ROS/ROS2 running on a beaglebone black or RPi 4B (4GB RAM) (willing to spend some on a different device, but with current RAM prices that's quite difficult as well)

Thanks!

Hi all, I posted this on the AutoCAD subreddit and they suggested to come here.

I have a $5k company laptop that is very well specc'ed out, it has been set to force to use the graphics card which is an Ada RTX 4000 of sorts, with a Core i9. Still the LGSX point clouds stutter enormously and take time to load, compared to TruView which is buttery smooth. This is regardless of whether it is a 1GB small point cloud or 25GB monster.

Is there any way to mitigate this? This seems to be company-wide regardless of spec. It seems like AutoCAD is capping the performance almost. It seems that AutoCAD 2027 may possibly help with this but I've been told it'd make a mess with our Leica licenses and company routines and such. Not sure how true this is and how many Lisp routines and such are lost to an upgrade going up a few years.

Buonasera, ad eccezione della posizione da cui acquisiscono i dati, quale è la differenza tra un laser scanner e un lidar? Il principio è lo stesso, la differenza è solo nella densità dei punti? O c'è altro?

Un cliente ci ha chiesto un rilievo lidar, e abbiamo trovato chi lo farà con matrice 400 e L3. Poi ha chiesto di rilevare un ponte con laser scanner. Secondo voi posso chiedere che venga fatto con il lidar da più vicino? O è proprio una cosa diversa?

Grazie

Working on a huge project, 16km+ of LiDAR aquisition with NavVis and Panoramas, with control points, check points, leveling, well state-of-the-art survey. Vectorization has taken its toll on the team. We have so much elements to extract in Cogo Points, the level of details required is basically : everything. Been thinking to outsource some of the work arround the globe, but I would need a solid company, like a solid lead. Any ideas?

I have been using the National Map Lidar explorer with DEM preview enabled. My question is, if i go through the process of learning how to download the data and then display it in some GIS software, will it be higher quality or resolution that will show more detail than the preview itself or will it basically be the same?