Greetings
I'm planning on using some global meteo datasets that are distributed in GRIB format. has anyone ever tried to parse GRIB NCEP files to GRASS?
Thanks
Best regards,
Antonio
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5084 (20100504) __________
The message was checked by ESET NOD32 Antivirus.
António wrote:
I'm planning on using some global meteo datasets that are
distributed in GRIB format. has anyone ever tried to parse
GRIB NCEP files to GRASS?
maybe this helps-
http://grass.osgeo.org/wiki/GRIB
Hamish
António
I have does this; I think it's helpful to first extract the fields you need and group them together, otherwise you will probably end up with a lot of unwanted fields being imported. I have written a Perl script to do this if you want it. I'm sure you would need to edit it to meet your needs.
Regards,
Tom
Hamish wrote:
António wrote:
I'm planning on using some global meteo datasets that are
distributed in GRIB format. has anyone ever tried to parse
GRIB NCEP files to GRASS?
maybe this helps-http://grass.osgeo.org/wiki/GRIB
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams@noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033
Hi Thomas and GRASS-people
THanks for your scripts Thomas
I have one question regarding Hamish's link.
/There is a cell-registration bug in GDAL: (grid vs cell-center convention) cells are all offset to the east and south by half a cell. You can fix this by hand with the r.region <http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html> module.
/Is this still happening, this error?/
/
Thomas Adams wrote:
António
I have does this; I think it's helpful to first extract the fields you need and group them together, otherwise you will probably end up with a lot of unwanted fields being imported. I have written a Perl script to do this if you want it. I'm sure you would need to edit it to meet your needs.
Regards,
TomHamish wrote:
António wrote:
I'm planning on using some global meteo datasets that are
distributed in GRIB format. has anyone ever tried to parse
GRIB NCEP files to GRASS?
maybe this helps-http://grass.osgeo.org/wiki/GRIB
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5181 (20100608) __________
The message was checked by ESET NOD32 Antivirus.
António wrote:
I have one question regarding Hamish's link.
/There is a cell-registration bug in GDAL: (grid vs
cell-center convention) cells are all offset to the east and
south by half a cell. You can fix this by hand with the
r.region <http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html>
module./Is this still happening, this error?/
well, the linked GDAL bug tickets are still open:
https://trac.osgeo.org/gdal/ticket/2637
https://trac.osgeo.org/gdal/ticket/2550
so I guess so. I'd encourage you to verify for yourself if your data is
offset or not, and post that verification (or not) to the appropriate
bug report with as much detail as you can; and if the patch attached
to the ticket fixes it for you (or not).
Hamish
Hello Hamish.
Yest, I used a NOAA's tool to verify it and it's misplaced. I will take a look at those tickets that you mention.
About this: /There is a cell-registration bug in GDAL: (grid vs cell-center convention) cells are all offset to the east and south by half a cell. You can fix this by hand with the r.region <http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html> module.
/How can I use r.region to fix this?
Hamish wrote:
António wrote:
I have one question regarding Hamish's link.
/There is a cell-registration bug in GDAL: (grid vs
cell-center convention) cells are all offset to the east and
south by half a cell. You can fix this by hand with the
r.region <http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html>
module./Is this still happening, this error?/
well, the linked GDAL bug tickets are still open:
https://trac.osgeo.org/gdal/ticket/2637
https://trac.osgeo.org/gdal/ticket/2550so I guess so. I'd encourage you to verify for yourself if your data is
offset or not, and post that verification (or not) to the appropriate
bug report with as much detail as you can; and if the patch attached
to the ticket fixes it for you (or not).Hamish
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5181 (20100608) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5185 (20100609) __________
The message was checked by ESET NOD32 Antivirus.
I'm planning on using some global meteo datasets that are
distributed in GRIB format. has anyone ever tried to parse
GRIB NCEP files to GRASS?
It is so interesting to see vastly different approaches to solve a
similar problem. I'm downloading NOAA forecast data which is in GRIB
format. I run the files through degrib and then parse the shape files with
a C program using the shapelib libraries and create a new shape file which I
import into GRASS with v.in.ogr. I plot the values with d.vect.thematic.
The resulting maps can be viewed at:
http://www.ars.usda.gov/npa/marc/heatstress
That reminds me, I originally set up a location for each region with an
eye forward on multithreading the map generation phases. I forgot the
reason in the middle of the project and created several regions in one
location. I had to revert back to a location for each region when I
implemented multithreading but reduced the total map generation time from
several hours to 15 minutes. 
Randy