Z-values of a text file into a mesh?

[Anonymous]

Hi!
I have a text file(* which has thousands of Z-values separated by a space. I wonder is it possible to get them into a MESH using GDL script?
I’ve been able to read the values from text file using Text I/O add-on, and even put them into parameter buffer (using PUT command). But the problem is that I should be able to read them in ”inside” MESH command. Like:
mesh a, b, m, n, mask, [and then:] z11, z12, z13… etc.
I guess there is no way to do that?

*) Nevermind the lack of X- and Y-values here; the file format is Esri Ascii file where the X and Y are defined in the beginning of the file via coordinates, number of columns and rows, and cell size.

[Alex Moruzzi]

Sorry, I realize I did not use the for next inside the 3d instruction but prepared the buffer in order to use the NSP values using the "use" instruction inside the 3d instruction. No for next instruction in but before in order to prepare the buffer.

[Anonymous]

Here's an update.
I couldn't make the translation from QGIS reliably. Or kind of I could: the Z-values have 13 to 15 decimal numbers, but the rounded value is (quite) similar to the original value in ASC.

In the end I made the conversion with FME software, and it seems to be fine. I checked both ASC and XYZ files in QGIS and they look the same grayscale image. File size is around 200 MB. When I read it into AC using 'Place Mesh From Surveyors Data' it turned out to be impossible to handle; there is a point in every 2 meters and the area is 6x6 km's... But the benefit of XYZ file is that it's possible to decrease the rows in Mac's Terminal, for example by leaving every 10th (or anything) row only. That produces the mesh with points in every 20 m. This decreasing process couldn’t be done with ASC file.

Because XYZ from QGIS has many decimal numbers, it explains the difference in file sizes:
- XYZ from QGIS ca. 310…320 MB.
- XYZ from FME ca. 200…210 MB.

QGIS translation would have been better, because the software is free, while FME isn’t.

(I realized that of course XYZ is much larger in file size, because for every point it includes also X- and Y-values, when ASC doesn't.)