Subscribe to this thread
Home - Cutting Edge / All posts - Manifold

10,391 post(s)
#17-Jun-22 14:58

SHA256: 508da372e66a075f55722de65f37dd1a1f30a8b5a7741b9a2242ccf40f8c757e

SHA256: 650eb5e856b0dcfb345942cbc5cdedf5c131f2ff780b5a3886c33e9722b66daa

SHA256: 316dead208ee13ed6125c67067998d8831c81995f5a0c75bfd5e6b35ab9ba61a

This build contains significant improvements for the spatial overlay algorithms that are widely used throughout the system and several big improvements for LAS / LAZ. The next build will contain various improvements for the UI as well as additions to MANIFOLDSRV.


10,391 post(s)
#17-Jun-22 15:15


(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.

10,049 post(s)
#19-Jun-22 09:54

It has been nearly 6 months since the last public build (30 December 2021).

I think we will need a new baseline soon?


7,233 post(s)
#19-Jun-22 11:03

That's imminent. I hear there will be a quick build soon to deliver Server implemented as a service plus a variety of small, but useful, things. After a few days so everybody can try out Server running as a service, just to double-check the implementation, it would be a good time for a new base build.

10,049 post(s)
#21-Jun-22 03:19

Thank you Dimitri.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.