9.0.174.3

Here is a new build.

manifold-9.0.174.3-x64.zip

SHA256: 407632388d73874be90497b74b4d5fcc3302b86a8ff54b35c440fd8944bfd771

manifold-viewer-9.0.174.3-x64.zip

SHA256: 6d80dafd1b8b6692441f5f2fe2e05c745828417e9fbf51e5d47da6f9197e550f

This build contains improvements for LAS and LAS library as well as various system changes. We have also been maintaining several other development branches (eg, with various improvements to labels), changes from these branches will appear in the near future. We are planning to issue the next build in about two weeks.

Changes

The welcome text in the gray background area can be turned off via an option.

The layout window supports keyboard shortcuts for the cursor modes: Default = Shift-Space, Create Text = Shift-T, Create Area Sample = Shift-A, Create Color Sample = Shift-C, Create Line Sample = Shift-L, Create Point Sample = Shift-P, Create Text Sample = Shift-X.

The LAS dataport exposes data in builtin and custom LAS headers as Info and InfoVLR tables.

The LAS library dataport exposes data in builtin and custom LAS headers from individual files as Info and InfoVLR tables. Both tables contain an additional field for the file path. Processing a folder of LAS files using the Index LiDAR Files tool caches header data in MAPMETA files. MAPMETA files composed by older versions of the tool that contain no header data are accepted and updated on the fly.

Exporting data to LAS / LAZ sets the name of the generating software package to 'Manifold System x.x.x.x'.

Activation dialogs cite the short version of the product in the title (XX.YY), use the product name in text prompts.

(Fix) Cutting edge builds of Manifold Viewer are now correctly reported as '... Beta'.

MSI install packages use product-specific banners.

There are two new projections: Natural Earth, Natural Earth II. This is a modern projection designed to better portray the entire Earth. Details here.

There is a new command line switch to install the ODBC driver or update it to the desired location, requires running with admin privileges:

manifold.exe -odbcupdate

There is a new command line switch to remove the ODBC driver, requires running with admin privileges:

manifold.exe -odbcdelete

The About dialog allows updating or removing the ODBC driver from a non-admin account. Attempting to update or remove the ODBC driver from a non-admin account asks the system to perform an action with admin privileges, which in turn prompts the user for admin credentials using a system screen.

Copying and pasting a table with geometry data from a MAP file into a data source that does not allow mixing geometry types within a single table (eg, GDB) automatically sets the geometry type of pasted data to that used by most records.

End of list.

Excellent, good to see support for the Natural Earth projections.

There's an abundance of base data over on the companion site Natural Earth to use in regional or world wide maps.

I'm very pleased to see the las header tables. Thanks so much for implementing this, it is going to be extremely useful to be able to query across the headers of many linked or imported las files for both QA and processing workflows.

While we are on this, if you come across a custom header that contains useful data that fails to parse (because the data is binary, for example), let us know. If the header is reasonably well established (not going to change tomorrow) and documented, we will add support for it.

Thanks Adam, I am finding these tables really useful to grab bits of metadata from. While you are on this, I notice that there are a number of public header fields in my las files (V1.4) which lastools exposes but but M9 seems to miss. See public header block description for las 1.4 attached.

Below is a dump from lastools of the public header entries. Those proceeded with a '>' dont seem tobe exposed by Manifold

> file signature: 'LASF'

> file source ID: 0

global_encoding: 17

project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000

version major.minor: 1.4

system identifier: 'Leica Terrain Mapper'

> generating software: 'las2las (version 191018)'

file creation day/year: 136/2020

> header size: 375

> offset to point data: 1360

number var. length records: 1

point data format: 6

> point data record length: 30

number of point records: 0

number of points by return: 0 0 0 0 0

scale factor x y z: 0.001 0.001 0.001

offset x y z: 0 5000000 0

> min x y z: 1929760.001 5616240.000 3.166

> max x y z: 1930239.999 5616959.999 83.939

> start of waveform data packet record: 0

> start of first extended variable length record: 0

> number of extended_variable length records: 0

extended number of point records: 5477177

extended number of points by return: 4430490 794791 189935 48574 10967 2079 341 0 0 0 0 0 0 0 0

Attachments:
las v1pt4 public header.jpg

One other thought. It would be really handy to have the source las component name as an attribute attached to point records in a laslib table.

I dont know whether this would be a ridiculous overhead or whether it could be done economically, but during my QA process, I am often reading reading through the points in a laslib and judging whether they pass or fail certain conditions. In the case of failures, it would be great to be able to show in which component a test has failed and even better to be able to subset the points which have failed.

A good idea. Yes, this can be done economically. We will look into adding this, thanks!

That's great. Thanks for picking this up.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

File signature / header size / offset to point data / point data record length / start of waveform data packet record / start of first extended variable length record / number of extended variable length records are all service info that we use to read the file. We do not show this info because we are not sure how that would be useful. What would you use this for?

Generating software is in the 'xxx Info' table, see 'Generating Software'.

Min x y z / max x y z are in the 'xxx Info' table as well, see 'Bounds' (the first three numbers are min XYZ, the second three numbers are max XYZ).

Hi Adam, thanks for the explanation I understand that most of it would be of limited use.

Having thought about it a bit more, I still believe that the inclusion of the first two (file signature: and file source ID:) would be useful.

I actually have a QA item around 'file source ID' in the list as it has been mandated to be set to a certain value in all files. At the moment I am falling back to the LasInfo dumps to check this item.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

A follow-up. Regarding file source ID - we actually report it, as long as it is non-zero. We only do not report it, if it is zero. The meaning of zero file source ID is that the ID has not been assigned, that's why we did not report that zero before. We thought about this and will change the code to always report it, even if it is zero, simply so that you don't have to wonder about whether it is not there because it is zero or because we do not report that ID in general.

Regarding file signature - it is always 'LASF'. It does not make much sense to report that value until the standard allows different values (it probably never will).

Status report:

We are planning to issue the next build at the end of this week. We have some fairly big improvements to the query engine, a number of additions to labels, some updates to LAS / LAZ, and various additions and improvements all over the system.

The status report from adamw on 12 July referred to some additions to labelling that were to appear in the next build, but the notes for 9.0.174.4 don't make any mention of what those are. Did the additions make it into the build and if so, what are they?

Nothing on labels that I saw. These notes about upcoming builds are just the current thinking but what actually comes out is often very different both in content and timing. As much as I'd love to see labeling improvement and that agitating for your priorities is helpful, we shouldn't discourage Mfd from giving us these hints about what's nearing the end of the pipeline by expecting too much from these notes of future builds. :-)

The improvements to labels and some other things have been temporarily pushed away by other priorities. We are doing these improvements in a separate code branch, they will come a little later -- in a couple of weeks.