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