| 82 | | |
| 83 | | There is one issue that disturbs me though. I found an issue with the |
| 84 | | current driver code whereby if you have a data set in which the top y |
| 85 | | coord value is less than the bottom y coord value the image gets |
| 86 | | flipped. It's hard to explain but it happens with a very useful |
| 87 | | bathymetry file we have at CSIRO. With the old driver no matter what I |
| 88 | | did there is no way I could get the image coming up the right way. It's |
| 89 | | a long time since I looked into that issue so my recollection of the |
| 90 | | reason is not clear but there are comments in the code describing it. |
| 91 | | |
| 92 | | //Here we have arranged the transformation such that the maximum |
| 93 | | //y values are always top and the scale is always negative. |
| 94 | | //Stictly speaking this is clearly not necessary although I am |
| 95 | | //doing it this because I need to, as images of that type end up |
| 96 | | //being flipped for some reason that I'm unsure of. |
| 97 | | double dOrigin; |
| 98 | | . |
| 99 | | . |
| 100 | | |
| 101 | | |
| 102 | | The reason why I'm mentioning it to you is that my gut feeling is that |
| 103 | | the real source of the problem lies elsewhere but I don't understand the |
| 104 | | code well enough (and don't have the time to learn it in detail) to be |
| 105 | | able to fix it in the right place. The fix I wrote seems to work without |
| 106 | | side effect, and I did the re-write to the latest code base such that it |
| 107 | | does not utilise my fix if opening in the old way, only when you add |
| 108 | | extra parameters to the filename. Therefore, it should be safe for |
| 109 | | existing users. If you happen to figure out the "real" reason why this |
| 110 | | happens and the "best" fix then I'd be truly greatful. |
| 111 | | |
| 112 | | Regards, |
| 113 | | |
| 114 | | Paavo. |
