12th December 2018
High resolution LIDAR data is great but its also limited in coverage and focused on urban areas generally. What happens when you need to see coverage beyond the city limits where coverage stops?
What happens when you live in Cornwall?
With the Signal Server propagation engine you can model LIDAR high resolution data but where the data has a void or stops entirely, you will receive an ugly hole in your coverage prediction or even worse a failure if the requested radius far exceeds the available LIDAR. To see wide area coverage without the voids a coarser resolution would need to be used which won’t have the detail of the LIDAR.
Customers using CloudRF’s LIDAR capabilities occasionally report terrain data anomalies which upon closer inspection reveal voids. In the UK 2m LIDAR for example, this was flown by light aircraft in strips like mowing a lawn so its not uncommon to see nice coverage around a city but voids out in the country, especially in remote regions like Cornwall.
A Cornish customer highlighted a region with some prominent voids which we used to develop a solution to this tricky problem. Previously Signal-Server worked with legacy SRTM DEM converted to the unique SPLAT! SDF raster format and then later ASCII Grid tiles but the two datasets could only be use exclusively. The solution required a fundamental re-design of the engine and its relationship with the data and is one of the biggest changes in the history of CloudRF…
Sleipnir
‘Slayp-nir’: The fastest horse in Norse mythology, capable of traversing any terrain on eight legs.
Working with senior C++ developer,
Gareth Evans, the loading of data was re-designed from scratch to not only make it faster but format and resolution agnostic. By doing this from the outset, different text data sources could be rapidly loaded into memory to form a single, seamless elevation model. For urban LIDAR this means a city tile with voids at the edges can be layered on top of a 100km 30m DSM tile to fill voids. The step between the two formats is indistinguishable to the human eye.
This benefits not only city planners frustrated by the unsightly hard edges at city limits but also the emerging DIY Drone LIDAR market where users might submit their own very small tile to CloudRF covering just a forest block for example. With this engine you can backfill the surrounding area to fit your high resolution 1m Drone LIDAR onto some lower resolution DSM like 20m for example.
The changes required to make this solution could not be done by adding more code to Signal-Server which as a fork of the much older SPLAT! engine was becoming difficult to maintain and has well documented problems in its public commit history with handling rectangular LIDAR tiles or tiles which span the Greenwich Meridian.
CloudRF has a long and proud history of using and supporting open source software, starting with SPLAT! in 2011 but this re-design and re-build from scratch allowed for a fresh licence. Sleipnir will not be open source and for this reason will not contain GPL licensed code from SPLAT! or Signal Server. It has faster, Intel CPU optimised, implementations of the same public domain models found in Signal server (ITM, Hata, COST231, SUI, ECC, Ericsson,ITU-R P.525) except for the ITWOM 3.0 model which has been excluded as its license and provenance is unclear.
Signal-Server LOS model
| 
Sleipnir Free space path loss including LOS
|
A key difference in how Sleipnir’s models work is line-of-sight (LOS) analysis. With Signal-Server, LOS was an optional mode, comparable to a propagation model which meant basic models like ITU-R P.525 (Free space path loss) would continue to show coverage behind obstacles unless knife-edge-diffraction was explicitly enabled.
With Sleipnir, LOS is factored into every model by default so you will
always see the impact of obstacles. Beyond obstacle diffraction can also be modelled with optional knife-edge-diffraction.
What this means for basic models is that you now get a result which combines line of sight with the model. Perfect for microwave links requiring a high SNR.
Case study #1: Patchy LIDAR, Cornwall
Tregony in Cornwall is served by three datasets presently: 90m DEM, 30m DSM and 2m LIDAR.
The LIDAR covers the town but has a void to the north west and a giant vertical strip missing to the east. The 30m DSM covers everything because it was mapped from space but lacks the detail of the 2m LIDAR in the town. Using Sleipnir the town and surrounding area were modelled using the 2m LIDAR resampled to 5m and rural LIDAR voids were (automatically) filled with 30m DSM. Not only were the voids filled but due to the redesigned engine it was
executed in a fifth of the time on the same processor.
Case study #2: Localised LIDAR, Sweden
Malmo in Sweden is served by 4m LIDAR but this is limited to the city centre only for now. Beyond the tile coverage falls back to 30m DSM. This scenario is common since LIDAR is expensive and difficult to justify beyond cities. It is also a problem faced by the DIY LIDAR market made possible by Drones and photogrammetry suites like
Pix4D which you will see more of in the future.. When your drone has a 15 minute battery life your LIDAR tile isn’t going to take long to upload but as drones and laws improve this potential will grow.
Aside from the obvious difference with coverage beyond the tile limit, you may notice the propagation in the city is different also. This is because the basic models like Hata have all been enhanced to include Line-Of-Sight (LOS) as standard now.
Performance test: Signal-Server vs Sleipnir
Tests were conducted on an a hex core Intel(R) Xeon(R) CPU E5-1650 v2 clocked at 3.50GHz. Signal server used four threads and Sleipnir was limited to eight although can use
n threads, hardware permitting. Times include image post processing conducted by the CloudRF service.
| Test | Signal-Server (seconds) | Sleipnir (seconds)
| | 30m DSM, 10km Path Profile | 1.2s | 0.1s
|
| 30m DSM, 10km radius | 5s | 2s
|
| 30m DSM, 30km radius | 34s | 12s
|
| 5m LIDAR, 5km radius | 29s | 39s
|
| 5m LIDAR + 30m DSM, 5km radius (Multi-mode) | N/A | 44s
|
| 30m DSM, 50km radius | 95s | 27s
|
| 60m DSM, 100km radius | 8min | 2min
|
Integration status
Sleipnir is currently available in CloudRF with the new ‘model’ parameter. For API users, model=1 is Signal-Server and model=2 is Sleipnir. In the web interface the choice is easier in the model section. For now, Sleipnir is available for area coverage only with Signal Server used for path profile but we’re working on Sleipnir path-profile along with new ‘best server’ features to exploit its incredibly fast path profile capability.
