| 1 | | Hi, |
| 2 | | |
| 3 | | I'd previously sent this to ticket #2550 but as it seems to be mostly unrelated to the problem described there I think it deserves its own one. |
| 4 | | |
| 5 | | I am seeing a shift in GRIB data. |
| 6 | | |
| 7 | | AFAICT it is simply shifted half a cell to the SE from where it should be. I assumed this was due to the usual grid vs. cell-center convention mistake, but that's just a round up the usual suspects guess. |
| 8 | | |
| 9 | | attaching screenshot. |
| 10 | | |
| 11 | | a list of commands to recreate my image is here: |
| 12 | | http://grass.osgeo.org/wiki/GRIB |
| 13 | | |
| 14 | | |
| 15 | | GRIB data in the screenshot downloaded from globalmarinenet.net. |
| 16 | | I can't guarantee the integrity of globalmarinenet's data (I have no idea about it other than the link); so it would be good to verify that this is happening with other datasets (ie something directly from the WMO) and in the spec. In the PDF which speaks of triangulation method it talks about data being at the vertices, fwtw. |
| 17 | | |
| 18 | | |
| 19 | | thanks, |
| 20 | | Hamish |
| 21 | | |
| 22 | | ps- Is there an internal tag in the format for no-data? In the above data it is represented by "9999", which is easy to set with gdal_translate -a_nodata, but in other GRIB data I have it is what I guess is the max for Float64, which is a number 4-6 lines long; too much to type by hand. |
| | 1 | It would be really nice if this error gets fixed. It has been open for a long time. |
