Subscribe to this thread
Home - General / All posts - ascii format
tgazzard
146 post(s)
#22-Nov-21 03:34

Hi,

M9 Question:

I am guessing this is something to do with encoding/line breaks. When I export an image as .asc (or .grd) it shows up as 1 line of text.

Where as when I export from ArcGIS 10.7.1 it comes out as out as many rows (effectively matching the nrows number - so in this example 384 rows).

Is there a way to make M9 export to .asc with multiple rows? I have another program that can only handle .asc files with multiple rows.

Thanks in advance.

Attachments:
ascii example.png

tjhb
10,017 post(s)
#22-Nov-21 05:26

You forgot to say how you are reading the ascii files produced by either source.

... it shows up as ...

... it comes out as ...

... but where? How are you reading the results?

One reason why it could matter is that both environments might be exporting with line breaks--but perhaps one uses CRLF while the other uses CR only.

For example.

It's important to know.

tgazzard
146 post(s)
#22-Nov-21 07:00

Fair Point.

In terms of reading the files. I have another custom built file convertor which takes the file and compresses them into a zip format for use in another program. Unfortunately, this is black box to me and there are no error messages.

The above attachments are displayed in notepad++.

In both files they show up with CR LF and are both in UTF-8 encoding (not 100% sure if this is notepad ++ default or whether it actual in this format).

I can read either of the files in Arcgis desktop 10.3.1 - through to Arcgis desktop 10.7.1 and they display correctly.

I can also read the files in Qgis 3.10.

I can convert the files to ascii in both arcgis and qgis (gdal-translate). The qgis version puts a white space at the front of each row. I have to remove this using a powershell command to make it work in the custom file converter:

code

$file_path =$args[0]

$file_path_out = $args[1]

$content = Get-Content $file_path

$content | Foreach {$_.trimstart(" ")} | Set-Content $file_path

text

My guess is that M9 exports out as .asc and .grd in a different format to arcgis/qgis. I was hoping there might be a way to adjust the formatting of the .asc in M9.

I have a work around…. It just would have been nice to not have to translate from say .tiff > .asc > .zip…. Rather just go .asc > .zip

Sloots

612 post(s)
#22-Nov-21 11:49

The remainder of the file lists the raster values for each cell, starting at the upper-left corner. These real numbers (with optional decimal point, if needed) are delimited using a single space character.

From the wikipedia page... They do not mention anything about CR/LR. Only a single space is needed.


http://www.mppng.nl/manifold/pointlabeler

tjhb
10,017 post(s)
#23-Nov-21 02:15

With the exported text in Notepad++, you could try this.

https://superuser.com/a/914219

Not tested by me, might need a tweak or two.

adamw


10,239 post(s)
#29-Nov-21 14:45

Our export produces files in the same format as ESRI products do, in that differences like whether or not lines start with a space character are considered small and do not change the format, the format allows doing it either way. Since line breaks are optional, we are not inserting them (the principle of least surprise). There is no way to force the export to insert the line breaks currently, but we can add that. However, we need to understand more about where the line breaks should be inserted. You say that the requirement comes from some other software package not being able to handle the file without any line breaks. Does that package need a line break after each line of pixels in the image? Or a line break after some reasonable number of heights (eg, because it processes things line by line and reads each line into memory entirely, and this is why things fail without line breaks, as the required amount of memory becomes too large)?

lionel

989 post(s)
#01-Dec-21 13:51

here table for begin end question of data at many level : endianess , unicode, ASCII , stream, utf-8

I think the reality is more complex than this but with utf-8 no BOM question & easy copy from HTML /XML file !

Only Developper has to know/test if file contain information about endianess in the case file/specification say that file can be both LE or BE (not at same time, let the dev the choice when save to file) .

in utf-8 , hte 109 number can be count from the top to bottom first column and then go to the next column ...

Attachments:
character_endBegin.png


Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en

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