Ships, hammers, and powerlines – solving point cloud problems

You know the joke about the old ships engineer who gets called in to fix an engine, walks around for half an hour, taps it once with a hammer, the engine goes, and the engineer sends a $20 000 invoice?

That’s what Spatialised does for point cloud datasets.

…we also help you walk around your metaphorical ship to figure out how to prevent the engine stopping in the first place!

Walking around the ship…

In the past few months we’ve helped PowerCor, a Victorian company which operates pole-and-line networks, wrestle with their data needs. This work was super interesting because the first engagement was ‘oh, you already started on the path I would have recommended anyway…’ so we got to dive into what happens next – once the easy 90% is done. It turns out we went from a technical consultation about point clouds to a strategic discussion of how to change organisational thinking about data querying and usage.

…this is what modern point cloud infrastructures give you! So we went into metadata management and associated ‘make it all useful’ topics, drawing heavily on US Geological Survey work in the same space – thinking about how PowerCor analysts can effectively catalogue and then find data in wyas which work for their analytical processes. As it turns out, once you have infrastructure-scale data needs, you need to start to think differently about the way all your geospatial data requirements work – from files and disks to ‘where is it’; and build systems around that which work.

In a way, this was about walking around the ship deciding what to do. In this case, the doing was ‘here are some ideas about what you can do with new plumbing’, rather than ‘how to solder some pipes’

Knowing where to whack the engine

Drawing on experiences in many roles and with different clients, it always pays to spend time listening about what exists, what tools people know and want to use, how they like to use them and what things they feel they’re missing. In a way, consulting work is an interview process, where the first while is a mutual process of discovery. I have my limits, so it is critical that the client understands where I can help and where I can’t.

Something we say a lot here is ‘I don’t know – lets find out…’

…which might be frowned upon in some circles, but really we can’t claim to be an ethical operation otherwise. Part of the job is ‘we know stuff’, the other is ‘we know how to learn stuff with you’. After that, we can decide precisely where to aim the metaphorical hammer.

More recently I worked on a strange lidar formatting issue. A lot of utility providers fly a lot of lidar – imagine thousands of kilometres of poles and wires, at least once a year. Being the bottom end of a long chain means there’s pressure to get lidar into usage as soon as possible. Maintenance crews on the ground are always working, and the in-between analysts working on where to send them need to know as soon as possible. With that in mind the company had a new provider send a new file format – which didn’t magically walk through their PDAL processing chain, and there was a lot of pressure to sort it out.

Lidar file formats are wilderness of engineering dreams about doing it best, spawned partly from need and partly from just not knowing enough about how existing formats actually work (mea culpa here also, I did a whole conference talk once based on not knowing as much as I should have). LAS is a daunting format – especially modern LAS 1.4 with extendable records. I still feel on shaky ground a lot of the time. In the end the issue was a badly formatted variable length record, which wasn’t used anyway. So we were able to cobble together a small toolchain addition using the fully-open parts of LAStools to fix it. Disaster averted! And a lot of company stress releived. We’ll look later at why PDAL couldn’t read the VLR, if we get curious enough.

Here, I was able to help by quickly pinpointing the weirdness and knowing enough about the vast variety of tools out there to help fix it fast using open tooling which the client understood.

Open by default

Because Spatialised is an open source shop, a lot of our wisdom comes from engagement with a huge community of experts. We give a lot to the community, and try to help people out in the open when we can. To paraphrase Paul Ramsey’s ‘why we code’, this gives us ‘social credit’ in the open geospatial ecosystem. It’s a key competitive advantage, expanding our pool of knowledge almost indefinitely.

We also deliver whole solutions – things clients can take away and reuse / recycle as much as they need. We don’t have to worry about IP protection, and we can all relax.

If you’ve got point cloud pain points combined with subscription service / vendor lock in pain points, come talk to us! We’d love to help you out – via consulting, training, processing your data into shape for you or all of the above. Let us walk the metaphorical ship together, then decide what will work to get you moving!

The sales pitch

Spatialised is a fully independent consulting business. The tutorials and write-ups here are free for you to use, without ads or tracking.

If you find the content here useful to your business or research or billion dollar startup idea, you can support production of ideas and open source geo-recipes via Paypal or Patreon; or hire me to do stuff; or hire me to talk about stuff; or buy stuff from the store; or just give me a seat on your advisory board and a 1% stake.