To reproduce the table below you can use the following command:

$ sbt
> project benchmark
> jmh:run -i 10 -wi 5 -f1 -t1 .*DEMRasterSourceBench.*

# VM options: -Xmx4G
# Cores: 4

• PDAL (native rasterizer) - benchmarks a DEMRasterSource that uses PDAL Delaunay and uses native (C++) Rasterizer.
• PDAL (JVM rasterizer) - benchmarks a DEMRasterSource that uses PDAL Delaunay and uses JVM Rasterizer.
• GT - benchmarks a DEMRasterSource that uses GeoTrellis Delaunay and uses JVM Rasterizer.

PDAL Delaunay + Native rasterization makes a lot of sense and it is at it behaves at least two times faster comparing to other methods. It makes no sense to use GeoTrellis Delaunay Triangulation at this point.

• PDAL reproject - benchmarks reprojection done on the PDAL side via filters.reprojection.
• GT region reproject - benchmarks reprojection done using GeoTrellis capabilities.

GeoTrellis reprojection tends to be a slightly faster. The performance is pretty much the same with taking into account the standard deviation. We decided to rely on the GeoTrellis reprojection capabilities at this point.

This benchmark is done against PDAL Java bindings to get the sense of what is slow in the DEMRasterSource. It does not use the RasterSource abstraction and uses only PDAL Java API.

To reproduce the table below you can use the following command:

$ sbt
> project benchmark
> jmh:run -i 10 -wi 5 -f1 -t1 .*ReadEPTBench.*

# VM options: -Xmx4G
# Cores: 4

• Pipeline execute - benchmarks raw Pipeline execution without generating a triangulation mesh.
• Pipeline Delaunay execute - benchmarks a Pipeline execution with generating a triangulation mesh.
• Pipeline Delaunay rasterize - benchmarks Pipeline execution with generating a triangulation mesh with the mesh rasterization.