Subscribe to this thread
Home - General / All posts - offset problem with images in M9 (

1,695 post(s)
#11-Jun-18 19:23


I imported a drawing and a surface in M8. Then I saved the project and open it in M9. I exported the drawing and the surface (now an image). The projection has been defined in M8 and is the same for both. Everything is fine in M9, all is aligned.

Then I exported the components to a .tif and a .shp

Back in M8, the .tif is shifted around 15m to the North. The shapefile is fine.

Same in ArcGIS, the .tif is shifted around 15m to the North. The shapefile is fine.

The projection is 32187 (EPSG)

I attached a subset. If someone can confirm the problem, that would be appreciated.

The circles in the drawing are visible in the surface. That's the way to see the offset.


8,093 post(s)
#12-Jun-18 01:05

Excellent, though the workflow can be simplified a bit.


The projection is 32187 (EPSG)

The projection is not EPSG:32187 but standard MTM zone 7 (NAD83). We don't need to be concerned with EPSG.

When the Manifold 8 project is opened in both Manifold 8 and Manifold 9, all of the projection parameters initially match.

(Manifold 9 leaves off one decimal digit from both local offset values, compared to the values shown in 8. Perhaps this is due to different C++ compilers. In any case, the difference would not normally be noticeable, and it is not the issue here.)

So far so good.


In Manifold 8, when the Map is opened, the drawing and the surface are exactly aligned.

But in Manifold 9, when the Map is opened, there is an initial offset in the Y axis between drawing and image. The image is shown about 3m south of the aligned position in Manifold 8.

So that's one problem.


I now export the image from Manifold 9 to TIFF, and reimport the result straight back into Manifold 9. All projection parameters are again correct, unchanged from before.

But when this import is added to the same Map, it is further offset to the south--now about 31m compared with the drawing.

That seems very mysterious.


I reimport the TIFF exported from Manifold 9 into Manifold 8.

The projection shows as plain Transverse Mercator, and with datum WGS84 rather than NAD83. The change to plain TM should not cause misalignment, but the change of datum could be a minor problem.

(This is largely a red herring. It is a limitation in the way Manifold 8 reads projection information in a GeoTIFF header. This limitation is familiar to anyone working with Transverse Mercator imagery from other parts of the world--New Zealand Transverse Mercator in my case. The usual fix is to check the projection after import to Manifold 8, and adjust as necessary.)

Now reassign the correct projection to the imported image in Manifold 8 (using the original image as the source), and add it to the Map. Again it shows with an offset southwards of about 31m.

Results are the same using Manifold and in


4,899 post(s)
#12-Jun-18 06:33

The image is shown about 3m south of the aligned position in Manifold 8.

A wild guess without looking into it in detail (traveling right now):Is the datum the same as reported in the JSON string of the coordinate system actually used?

If not, here is another wild guess: could this or (3) be related to how the data is centered, that is whether in the center of the pixel or the corner? Consider this discussion from the Example: Link NLCD using Scan Raw Binary File topic:

The Local scalevalues came from the Abscissa_Resolutionand Ordinate_Resolutionvalues, both 30, in the delaware_fgdc.txtfile. The Local offsetvalues came from the Upper Left CornerX value and the Lower Right CornerY value in the delaware.txtfile, subtracting 15from both. We do that because the data set is centered on the middle of a 30 x 30 size pixel, but Manifold aligns rasters to the lower left edge. Therefore, we must subtract half a pixel's worth of meters, 15, from the local offsets to match alignment in Manifold with the alignment used by the raw data.


1,695 post(s)
#12-Jun-18 13:26

Pixels are 1 meter Dimitri. That cannot be that.


1,695 post(s)
#12-Jun-18 14:35

I don't know what I did while preparing the subset. The offset is southward in the subset. In my main project, the offset was northward. I'll look into the datum and report if I can get the expected output

8,093 post(s)
#12-Jun-18 18:46

That is useful.

To me it is starting to sound as if there is a problem in code Manifold 9 uses when it has to retile an image (change received or output tile size). Something like the accidental use of a one-based Y index that should be zero-based.


1,695 post(s)
#12-Jun-18 21:07

I'll post new data soon. For now, here is the workflow. I did it again.

1- Importing a surface and a drawing into M8.

2- Setting MTM 7 / Nad 83 Canada projection for both. Both items have been exported from ArcGIS with this projection.

3 - Saving the project. Importing it into M9. Projections seems ok to me. Details are good. Both layers are lined up.

4- Exporting the drawing and the image from M9.

5- Importing them again in M8. The drawing now is labeled with Transverse Mercator Projection and Geodetic Reference 1980 Datum. The surface is labeled with an Orthographic projection and a WGS84 datum.

6 - Assigning MTM 7 projection with Nad 83 Canada Datum for both. The drawing is lined up. The image is offset northward about 10 meters.


1,695 post(s)
#12-Jun-18 21:11

Test data


4,899 post(s)
#13-Jun-18 06:48

Thanks for the link. It seems to me there are two sets of questions:

1. What happens when you import data written by Arc directly into 9? Does it import correctly with everything lined up?

2. Multi-step interoperability issues. What happens when you do a multi-step chain: Arc->8, 8->9, 9->8, 9->Arc, etc.?

It seems to me that we first must answer 1. above, for these reasons:

a) 9 users who want to import files written by Arc do so directly. They do not first import into 8 and then import from 8 into 9.

b) If 9 imports the Arc-written data correctly, the primary task is done.

c) If 9 does not import the Arc-written data correctly, that can be fixed in a day.

d) If the interest is not getting Arc data into 9 but instead is testing interoperability between 8 and 9, knowing what happens Arc -> 9 and Arc -> 8 helps narrow down problems when doing 8 -> 9.

If we assume the initial export from Arc was correct (a risky assumption, but let's start with that), the first thing to verify is if pairwise interchange Arc -> 8 and Arc -> 9 are both correct.

I've asked before and for some reason have not gotten an answer: What do you mean by "Everything is fine in M9, all is aligned" ?

When importing the sample data set from the link, there are no dots in the c914_mnt raster against which alignment of the points in the buf drawing can be checked. I see no obvious way to tell if in the direct import into 9 that c914_mnt and buf are correctly aligned or not.

Overlaying c914_mnt with partial transparency over a google terrain layer seems to indicate it is in the correct place, but not to a level of detail where you can say plus or minus 1 meter it is exactly correct.

So, let's rephrase that key question: when you import the shapefile and the tif directly into 9, are they imported correctly, does everything line up as expected, and, how can you tell whether everything is correctly aligned or not?



1,695 post(s)
#13-Jun-18 14:05

Hi Dimitri,

You asked for the original data. That is what I sent. I pass from Arc to M8, because I need to modify the surface. I use queries in M8 to do so. The circles in the drawing are selected and the selection is transfered to the surface. The value of the selected pixel is changed by the queries. I go in M9 after, because it can export the image directly in .tif format. M8 cannot export a surface in .tif format. Using ESRI grid is longer to export from M8 and longer to import in Arc and it needs to be exported again in .tif format once in Arc. M9 allows to save a lot of time, but something in the image export or import seems odd.

About your question 1 :

I imported the original image in M9. The detected initial projection is Transverse Mercator. The detected Datum is Lat/Long WGS84.

I made a shapefile in Arc that contains a line which follows a river, visible on the image. I imported the original shapefile in M9. The detected initial projection is Transverse Mercator. The detected datum is Nad 83 (CONUS).

I modified both datum to NAD83 Canada, because this is the original datum. I made a map with Tranverse Mercator, Nad 83 Canada datum. You can see the parameters on the attached picture.

You can see on the attached picture that the river and the image are not lined up. The black vector line is the South-East side of the river. The offset of the image is southward (or maybe the shapefile is the one that is wrongly placed ?)

I did the whole process again, but this time applying the real coordinate system of the inputs (Canada NAD83 MTM zone 7) to all components. Result is the same. Offset is the same.



4,899 post(s)
#13-Jun-18 15:28

You can see on the attached picture that the river and the image are not lined up. The black vector line is the South-East side of the river. The offset of the image is southward (or maybe the shapefile is the one that is wrongly placed ?)

Yes, I can see. Suppose you just take the shapefile as exported from Arc, and the image as exported from Arc, and import both into 9. Do they correctly align if you don't change anything (no changing of datum, etc.)?

If a drawing exactly overlays a raster in Arc, and then if Arc exports that drawing as a shapefile correctly, and if Arc exports the raster as a .tif correctly, then both should import into 9 exactly correctly and overlay just like they did in Arc, with no need to manually change anything.

If that does not happen, that is a bug in 9 to be fixed. If that is what is going on, please file a bug report and offer to provide sample data that shows the bug.

If a vector and a raster align perfectly in Arc, but then when you export them from Arc using routine formats like a shapefile and a tif, they should align perfectly upon import into 9. If they do not, that's an error exporting from Arc, an error importing into 9, or both. With samples as exported from Arc, Engineering can investigate and fix any errors immediately.


1,695 post(s)
#13-Jun-18 16:03

Suppose you just take the shapefile as exported from Arc, and the image as exported from Arc, and import both into 9. Do they correctly align if you don't change anything (no changing of datum, etc.)?

No, they don't. They do in M8.

I'll investigate the export process from Arc before filling a bug report. ESRI is creating more bug than new features these days...

I'll keep posting here about it.

Thank you.


1,695 post(s)
#13-Jun-18 16:55

I loaded the full original DEM in M9, and it is aligned with the drawing.

Then I removed any Arc's auxilliary file created in the export process (we don't keep aux. files with the full DEMs) I loaded the TIF without aux. files in M9 and the problem is solved.

Any hint about what can be wrong ?

Auxilliary files are : .tfw, .xml and .ovr (for pyramids). Which one M9 reads ?


4,899 post(s)
#13-Jun-18 19:27

Auxilliary files are : .tfw, .xml and .ovr (for pyramids). Which one M9 reads ?

I had to look that up:

Some file formats utilize accessory files such as "world" files, or .PRJ files to convey coordinate information for formats, such as shapefiles, which do not automatically convey coordinate system information. When reading formats Manifold will automatically read coordinate system information from accompany files, if they exist, in the following order: "world" files, .PRJ files, .XML files (Manifold System 8.00 accessory file) and .MAPMETA files (Manifold accessory files). In the event of conflicting coordinate definitions the last read file wins, since the read order is in order of more rigorous definitions.

However, if Arc wrote the internal tags as a GeoTIFF I would have expected that the internal tags within the GeoTIFF would take precedence over any external .tfw or .xml files. So this is puzzling:

I loaded the TIF without aux. files in M9 and the problem is solved.

That could not have happened, I don't think, if the tif were not a GeoTIFF.

My totally inexpert guess is that something in the auxiliary files does not agree with what the tif says. 9 should be able to handle that. I think it is worth reporting.

Thanks a lot for your patience!

8,093 post(s)
#13-Jun-18 19:43

Regardless of what happens with data out of Arc, with or without a .tfw worldfile (interesting), there are still at least two issues (which may or may not be the same bug) using just Manifold (8 and) 9.

See my points (2) and (3) above. Easily reproduced.


1,695 post(s)
#13-Jun-18 20:06

I have to leave. I'll resume testing/reporting on Friday.


4,899 post(s)
#13-Jun-18 20:30

Easily reproduced.

If 9 does not correctly consume something 9 itself has written, that's a bug. If it can be reproduced it is best to file a bug report, providing example data. I file a lot of bug reports and I'm always happy to file another one, but it is usually best for those people who are closest to a specific issue to report.

Likewise with 2. The ideal is perfect interoperability 8->9. The problem could arise with how 8 consumes anomalous data, how 8 exports such a situation, or how 9 imports that, or any combination of all three. Real world bug reports with example data help a lot.

8,093 post(s)
#13-Jun-18 21:17

I will file a report referring to Vincent's thread.


7,972 post(s)
#14-Jun-18 10:01

I am late to the thread.

(2) looks very much like our bug. I get a different shift, but still a shift, the image read from 8 seems to be put into the wrong place.

We will investigate this, then check the rest of the thread and I will try to report the results here.

8,093 post(s)
#19-Jun-18 03:16

Thanks Adam.

I made a simpler test file which I hoped would show the same issue. Instead it seems to show a different issue (somehow related?).

The Manifold 8 project has two images and two surfaces, one each at 128x128 pixels and one at 160x160 pixels. (Sizes chosen to need one even tile, and one tile plus residue, in Manifold 9, at the default tile size of 128x128. I thought I might get a different result with one size compared with the other. As it turned out, not really.)

There is also a grid of lines and buffered points, used to mark pixels in the rasters for comparison (as Vincent did).

Everything is in the default Manifold 8 coordinate system, Orthographic/WGS84, with local offsets of 0, local scales of 1.

Opening the project in Manifold shows...

The Rect properties for each 128x128 image should be [ 0, 0, 128, 128 ], and for the 160x160 images [ 0, 0, 160, 160 ]. Instead we have [ 0, 32, 128, 160 ] and [ 0, 32, 160, 192 ] respectively.

We see only part of each image--there are 32 pixels missing along the upper and right edges. In both X and Y, even though the Rect values in X are apparently correct.

On the other hand, correcting the Rect properties does not fix the issue--apparently no change.

And yet... here the marks in the images line up exactly with the marks in the drawings.


8,093 post(s)
#19-Jun-18 07:32

Sorry, I meant to attach the Manifold 8 project and thought I had. Here it is.

20180619 test rasters

8,093 post(s)
#20-Jun-18 23:38

Results for this issue in

Rect properties are now correct, [ 0, 0, 128, 128 ] and [ 0, 0, 160, 160 ].

Images now display differently, still not correctly. There are now bands of 32 empty pixels at the bottom and right edges.


8,093 post(s)
#21-Jun-18 00:55

In, the symptoms that I was calling issue (2) above no longer appear.

The points and point markers in Vincent's Manifold 8 project now line up, when it is opened in 9.

That seems to be fixed.


7,972 post(s)
#21-Jun-18 16:40

Thanks for this other test, it steps onto a slightly different issue. We will fix it.


1,695 post(s)
#05-Jul-18 14:05

Everything seems to be fixed. However I'd like to report the following issue (already reported upper here I attached files to see the problem and to test it.

Importing an image in M9 with or without auxiliary is leading to different results. The provided .tif has been produced with ArcGIS 10.6.1. If I import the .tif with the aux. files, run a Traces Areas transform and export the resulting shapefiles, the shapefiles is off northward by 5 kilometers. Not using the .aux files leads to correct results. Initial coordinates system is ok and used in both processes and exports.


8,093 post(s)
#10-Jul-18 01:21

Everything [else] seems to be fixed.

Not quite. This issue is also still present in A fix is no doubt coming.

8,093 post(s)
#10-Jul-18 01:26

If I import the .tif with the aux. files

What do mean by "the aux. files"?

There is one file called image_feu.tif.aux.xml, another called image_feu.tfw.

Which? Or only both?

8,093 post(s)
#10-Jul-18 02:17

It looks as if it is the world file, .tfw. I think the .aux.xml file is a red herring.

To reproduce, open two instances of


Import image_feu.tif, from a folder that also contains image_feu.tfw.

Open mfd_meta. Inspect 'image_feu Tiles' > 'FieldCoordSystem.Tile'.

EPSG:32187,mfd:{ "LocalOffsetX": 350165.3977791705, "LocalOffsetY": 5437603.857325403, "LocalScaleX": 50.368675765618775, "LocalScaleY": 50.3093835835618 }


Import only image_feu.tif, that is, from a folder where that is the only file.

Open mfd_meta. Inspect 'image_feu Tiles' > 'FieldCoordSystem.Tile'.

{ "Accuracy": 4, "Axes": "XY", "Base": "NAD83 (EPSG:4269)", "CenterLat": 0, "CenterLon": -70.5, "Eccentricity": 0.08181919104281579, "FalseEasting": 304800, "LocalOffsetX": 350165.3977791705, "LocalOffsetY": 5442584.48630016, "LocalScaleX": 50.3686757656, "LocalScaleY": 50.3093835836, "MajorAxis": 6378137, "Name": "NAD83 \/ MTM zone 7 (EPSG:32187)", "Rect": [ -172.54, 23.81, -47.74, 86.46 ], "ScaleX": 0.9999, "ScaleY": 0.9999, "System": "Transverse Mercator", "Transform": "Molodensky-Badekas", "Unit": "Meter", "UnitScale": 1, "UnitShort": "m" }

The most obvious difference is that in A we have plain EPSG plus local metrics, while in B we have many more things specified.

In particular:

  • In B we have an extra parameter "Accuracy". Does this indicate an export from the geodatabase, with resolution/precision set to 0.0001? I can't test, since I don't use ESRI. In any case, I expect that this parameter is ignored by Manifold 9.
  • More importantly, while the LocalOffsetX values match exactly, the other metrics differ:
    • LocalOffsetY: 5437603.857325403 ≠ 5442584.48630016
    • LocalScaleX: 50.368675765618775 ≠ 50.3686757656
    • LocalScaleY: 50.3093835835618 ≠ 50.3093835836

Ideally these should all match exactly. The differences in the LocalScale* values look like rounding/truncation/representation errors or limitations. OK.

But the LocalOffsetY parameters look worrying. The difference is 4980.628974757, closely matching Vincent's measured offset of 5 km.

So, an ESRI problem or a Manifold problem?

8,093 post(s)
#10-Jul-18 03:47

It is worth noting that the pixel scale for this image is not the same in X and Y. That may be material.

8,093 post(s)
#10-Jul-18 04:53

It would be good to test this some more, but I have sent in a bug report in the meantime.


4,899 post(s)
#12-Jun-18 14:59

Just been able to download and try...

I imported a drawing and a surface in M8. Then I saved the project and open it in M9. I exported the drawing and the surface (now an image). The projection has been defined in M8 and is the same for both. Everything is fine in M9, all is aligned.

When I opened the Release 8 .map saved within in Release 8, the Buf Drawing and Mosa 2 raster align in the Map. When I opened the the Release 8 .map saved within in Release 9, the Buf Drawing and Mosa 2 raster were not aligned but were slightly off. When you reported "Everything is fine in M9, all is aligned" what did you do?

This definitely needs looking into and should be reported. Out of curiosity, do you have the original raster and the original drawing that were imported into 8? What happens when you import those into 9?

BoldItalicUnderlineStrikethroughSuperscriptSubscriptInsert Bullet ListInsert Numbered ListInsert ImageInsert LinkRemove LinkInsert Horizontal RuleInsert HeadingInsert SubheadingInsert TextInsert QuoteInsert CodeRemove Formatting
Insert Symbol SmileWinkGrinBlinkBlushOh, My!HuhSadAngryPh34rSleepCool
Link URL: Text Raw HTML

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