INGR driver does not respect veritcal scanline orientations

[mpd]

The attached file has a vertical scanline orientation.

[mpd]

Vertically oriented INGR raster

[warmerdam]

Ivan, over to you.

[ilucena]

Good point.

Your sample file is LLV and what you are saying is that the driver is not giving you the correct GeoTransform =

-1938278049.920774, 0, 1302.089095963633 -1470053330.548775, -1302.089095963633, 0

Nine dregree rotation should give you "1" on GeoTransform[3]. Isn't it right?

Thank you for pointing that out. I am going to work on that.

But for the other 6 possible orientation there is not much we can do besides adding a Metadata item. I am going to do that too.

"""Intergraph has chosen Upper-Left-Horizontal (ULH) and Lower-Left-Vertical (LLV) as the default orientations. These two orientations differ only in a 90 degree rotation relative to the image content.""" [Intergraph Raster File Format Reference Guide]

[ilucena]

Martin,

The Intergraph Raster File Format Reference Guide mentions:

"""To obtain full transformation from local coordinates to world coordinates, catenate the homogeneous transformation matrix (TRN) with a flip matrix (T=TRN * FLIP). The concatenated matrix (T) now contains all the information required to map a particular pixel to the world coordinate system including the scanline orientation (SLO)."""

I added one Flip Matrix for each Scanline Orientation and a function to multiply those matrix to the homogeneous transformation matrix, just as the document indicates.

I applied that technique to your data sample (LLV) and the results as far I could see are very good. I don't have more data sample to test it further.

You if you don't mind, take a look in those Flip Matrix and compare with your previous implementation:

http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/ingr/IngrTypes.cpp#L118

Let me know if you find anything incorrect.

Thanks,

Ivan

[mpd]

The GeoTransform looks OK now, but the band dimensions in X and Y are not flipped.

[ilucena]

Martin,

I can be wrong but I believe that the dimensions of the raster matrix should not change, since the driver is not flipping the image, it is only documenting it so that the applications would how to handle it.

I tell you what I did. I loaded your file in ArcMap 9.2 and it shows you image correctly in a horizontal aspect. Then I used gdal_translate to create a GeoTiff and a HFA version of the same data and all three images overlap perfectly. Before the fix gdal_translate was generating the .tif and .img as an upside down image.

Thanks for your help,

Ivan

[mpd]

Sorry, you're right, our misunderstanding.

[cleo]

Sorry for bringing up an old item, but mpd here was right. The flip matrix incorrectly changes the world coordinates. The width and height should be included in the flip matrix when that axis is flipped.

There is a frmt24.cit file in your test data that has a bottom right orientation. By using the original matrix, you get a cover of (0,0)-(189,135) in world coordinates. By flipping the resolution, you get a world coordinate of (-189,-135)-(0,0) completely changing the cover. The cover should not change. The orientation simply tells you where to start drawing pixel data within the original cover.

The problem I'm having is that I'd have to guess what is a flipped matrix and what is a transform intentionally giving me negative world coordinates.

[-1 0 0 w] [0 -1 0 h]

The above is what the first two rows of the flip matrix should be if both axis are flipped. This will keep the same cover (world coordinates) but still let you know that the draw direction has been reversed. If it's not flipped, then [1 0 0 0] is fine.