(Fix) Selecting records in a table with an identity index on text fields with external (eg, database) collates no longer sometimes fails to work.
(Fix) Writing a BIL / FLT / GRD / IMGERDAS / TIFF with pixel scale expressed in units other than meters no longer writes wrong local offsets to the accompanying MAPMETA.
Opening a LAZ with a COPC index validates index data and turns off the index if its data is invalid.
Reading a LAZ no longer progressively caches uncompressed data on disk and instead uses multiple reading heads. This significantly improves performance.
Performing a spatial search on a LAS / LAZ with a COPC / MAPINDEXP index works faster.
(Fix) Rendering a LAZ with a COPC index no longer sometimes prunes search too aggressively.
GeomOverlayXxx (non-topology) query functions can be canceled in the initial data collection phase.
GeomOverlayXxx (non-topology) query functions optimize cases where a big source table has a small overlap area with an overlay table, as long as the source table has a spatial index.
GeomOverlayXxx (non-topology) query functions optimize cases where a source table has a small overlap area with a big overlay table, as long as the overlay table has a spatial index and the source table can determine its bounds without being read in full (this usually means that the source table also has a spatial index and is static, that is, not a query).
GeomOverlayXxx (non-topology, non-filter) query functions now only return pairs of records for the actual overlay incidents. Previously they were also returning a single record for each record in the source table which had no corresponding records from the overlay table, similarly to a LEFT JOIN. We changed the behavior to be similar to an INNER JOIN, because otherwise the functions have to return at least as many records as there are in the source table, which is frequently undesired and just makes processing the result slower. If there is a need to obtain records from the source table that have no overlay incidents, that can be done separately after.
GeomOverlayXxxFilter query functions perform proportionally to the number of records that have overlay incidents. Previously, fetching all records of the overlay filter required going through all records of the source table. This and other changes to GeomOverlayXxx functions apply to various UI tools that use them, eg, they apply to the spatial overlay select templates and to the Join dialog when it transfers data between drawings.
SelectionXxx query functions perform proportionally to the number of selected records. Previously, fetching all selected records of a table required going through all records of that table. The change applies to various UI tools that work with selections, eg, copying a few selected records from a large table now performs much faster. The only exception is that selections that have been inverted continue to perform proportionally to the size of the table, not to the size of the selection.
(The above improvements significantly improve the performance of spatial overlays when the input data sets do not overlap much. The exact performance gains depend on the overlap size, and can easily be 5x, 10x or more. For LAZ, the improvements are even bigger. One of our tests was taking a LAZ file with a COPC index on 375 million points, and fetching 3.5 million points covered by an area in a different drawing using GeomOverlayTouchingFilter. The time to complete the test in the previous build was 9230 sec. After the improvements, the time to complete the test went to 363 sec, an improvement of 25x. If the area was smaller, the difference would have been even bigger.)
End of list.