Subscribe to this thread
Home - General / All posts - M9 exported .asc location error
ColinD


1,924 post(s)
#29-Aug-19 11:05

Using manifold-9.0.169.7-x64

Imported 4 .asc all 4000x4000 1m resolution, set to projected coordinates then merged them. Filled sinks then created watershed lines. Exported the merged image as .asc and the watershed lines as .shp. Imported into an old M8 project and the lines drawing located correctly but the DEM was north by 4000m, against the top edge of the lines drawing.

The .asc header shows xllcorner 358000 and yllcorner 6346000. The mapmeta file shows LocalOffsetX": 358000, "LocalOffsetY": 6342000. yllcorner 6342000 would place it correctly.

Another question, what is the transform or function for changing an image size? Equivalent to resize in M8. Can't see it for looking!

Thanks


Aussie Nature Shots

tjhb

8,846 post(s)
online
#29-Aug-19 15:16

Colin,

I'm not sure of the exact problem without trying to reproduce it but this should be bulletproof I think:

After import, to create the map containing the 4 images, do it in 3 stages:

(1) Create an empty map. It will initially be given an arbitrary coordinate system.

(2) Open the map and drag in just the lower left image. Now the map has the coordinate system of that image, including metrics (offsets and scales).

(3) Drag in the remaining images. The CS doesn't change.

Do Merge Images in that map, without changing the coordinate system. That merges at original resolution, using the exact CS of the map.

Second thing. There is no built-in resize transform yet. However, if you want to do it with the default interpolation method (not sure if it is bicubic or bilinear), you can use Merge Images again, but this time, do changes the coordinate system, specifying the new resolution you want in the Local Scale X and Y (without changing anything else).

P.s. You can use Merge Images for the second purpose (resize) even if there is only one image in the map.

ColinD


1,924 post(s)
#30-Aug-19 01:06

No luck Tim. The merged image is located correctly in M9 whichever way the merge is done. The problem is with the exported .asc header writing the upper left y value for the lower left y value. Without the mapmeta file the .asc imports incorrectly back into M9.

Thanks for the resize tip.


Aussie Nature Shots

tjhb

8,846 post(s)
online
#31-Aug-19 04:55

I should have read your third paragraph better Colin, sorry.

Sounds like something worth reporting.

orerockon

377 post(s)
#05-Sep-19 02:58

I just searched for this exact issue, looks like I'm a couple weeks late. .asc files exported from 9 are off to the north every time, no matter how I mess with the parameters. Importing them to 9 is not an issue, they look just fine. This is exasperating. 8 chokes on big asc files for me, stops at 51% and sits there for hours. Importing and exporting in 9 seems to make them more papatable. Smallish files, no problem.

ColinD


1,924 post(s)
#05-Sep-19 10:03

I have reported this and tech are working on it.


Aussie Nature Shots

orerockon

377 post(s)
#05-Sep-19 15:51

Cool I'll be waiting with baited (or is it bated lol) breath. In the meantime have you tried the USGS DEMs from the national map site? I'm trying to open one and every file I click on results in a blank screen. The zipfile hsa a folder grdn45w117_13 that has a unch of .adf files in it. I tried each one and most of them look lke they're importing something but no dice. The coordinates in the lower right of the window are right. http://www.manifold.net/doc/mfd9/adf,_esri_arcgrid.htm says to sue the style pane after I impot it but I'm using 9 Edge and there is no pane.

oeaulong

213 post(s)
#05-Sep-19 18:58

I believe that the typical DEM data from USGS uses a different corner reference point than Manifold traditionally does. I remember having to do this translation with all products that use a world file. From the top of my head, I remember that the E-W coordinate is correct, but that manifold uses a SW corner as a reference and USGS uses NW. (ESRI .tfw format uses the NW corner) Anyway the reference will need to be adjusted by the (Y axis Pixel count * the pixel size ). I remember times where I added rather than subtracted and it placed the raster/image way off to the north. It just became something I had to adjust for when importing typical rasters + world files.

Can you post a link to an example you are having trouble with?

From Mfd8 manual page, "Projection and Images" If an image is imported into Manifold form a geographically mute format such as .bmp or .jpeg, it is projected using Orthographic projection and placed with its lower left hand corner at the intersection of the Prime Meridian and the Equator (0 latitude and 0 longitude). This default georegistration decision together with size information about each pixel makes a specific choice as to where that image is located, what size it is and thus where the "center" of each pixel is located.

Though this mentions the default Orthographic projection and the 0,0 lat, long location. It remains accurate that Mfd8 uses the lower left hand corner for a reference point, putting its location read in by a world file the height of the image off in the N-S axis.

orerockon

377 post(s)
#05-Sep-19 20:10

I confused the hell out of myself with too many downloads. I did get a couple of the files from here https://prd-tnm.s3.amazonaws.com/index.html?prefix=StagedProducts/Elevation/13/ArcGrid/

Only the "ArcGrid" files project properly, but many are missing. the nXXwXXX do not at least for me. And they're identical formats. I did get exactly one to georegister correctly, they're in lat/lon and I had to change the MFD default parameters to match their projection metadata doc. I just did one that landed exactly on top of the one I got right, using the same procedure and parameters. It was supposed to be the tile below it (and it does have the right geography) . I'm beginning to suspect that USGS just threw the pre-staged files up without bothering to check if they were worth a crap. I'm handing this mess onto someone else who has more tolerance for crappy coverages than I do. He got a couple I sent him to work in QGIS.

orerockon

377 post(s)
#05-Sep-19 20:50

Forgot to say I took the corners from M 9 and plotted them on my M 8 map. They are right for the maps that register properly, and wrong for the ones that don't.

oeaulong

213 post(s)
#05-Sep-19 21:49

I see where you are getting the blank screen. I downloaded the 45_117 file in ArcGrid and imported to Mfd9. Each of the files imported is treated as a 3Channel RGB data until configured otherwise. These files actually only have one channel. This is changed in the Style tab under the Contents Tab.

  1. With the imported image file open in a window (using mfd9), hit the Ctrl+4 shortcut to open the Style box inside the Contents tab. Below Style, there will be a drop down box defaulting to "(use RGBA channels)".
  2. Pull down this box and select "Channel 0". This will select the appropriate data layer to view, we need to select a palette to assign to it. Once you select the Channel 0 a few changes appear below.
  3. Choose the Apply Palette button (colored 9 pixel icon) and select a color scheme. "Blacks to White" under the Classic menu item will give you a grayscale defined by the (default 5) classification numbers calculated.
  4. Click the Update Style button at the bottom. Voila!

There is much to change here to get it visually where you want, but this should give you initial visualization. This procedure is shown in the updated Manifold Viewer - Introducing v2 overview on youtube.com. About 7:30 into video the SRTM elevation images get imported, these seem to have different defaults so are immediately visible. Fast forward to 9:30 and follow along when the colors get changed. It should be the same as above in a walkthrough. https://youtu.be/cKZ7Q8PttSQ?t=570

I hope this helps. It doesn't address the manually changing of image origins I was referring to above. That would be another post.

orerockon

377 post(s)
#06-Sep-19 03:18

Since I dropped the DEMs, here's another one. I can't force this one to register either. Even using the metadata file that 9 spits out. Unless I'm completely misunderstanding it. 8 has no idea what it is, but if I export to .asc in 9 it recognizes it as a surface. I tried to attach it but I get an error screen. You can get it here https://www.fs.fed.us/rm/boise/AWAE/projects/NFS-regional-climate-change-maps/categories/us-raster-layers.html

Historical summer precipitation:

Lower 48

oeaulong

213 post(s)
#06-Sep-19 06:46

I am afraid we have hijacked Colin's thread. Manifold 9 opened this up without a hitch as a .TIF

Manifold 8 opened it up as a surface as well from the binary. No need for .asc, I don't know why you are getting errors. There would need to be a transform to prettify it in Display Options, I selected the negative values and made them invisible, then made the color classification.

I am not getting enough information on why you are getting tripped up by it. If you want to pursue this further, please start a new Thread as we are covering topics that have wandered from the subject.

<attached is screenshot from Mfd8 after import and thematic adjustment.>

Attachments:
PPT_summer_historical 2019-09-06 004118.png

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