Closed jsbrujy closed 8 years ago
Unless there's a need to build the entire project, I recommend using nuget.
It's also possible that the spaces in you path could cause an issue. grib_api assumes Linux and hence may read the path incorrectly. As a general rule I avoid paths with spaces whenever possible, even on Windows.
Also, did you try without the env variables?
@bremy Try https://github.com/0x1mason/grib_api_example
Clone it and build. Should just work. Spaces may not matter.
Ah, I see there's an issue with your path. It should be C:\Users\Bruno\Documents\Visual Studio 2015\MyRepositoryGit\GribApi.NET-master\bin\x64\Release\
. The way I set it up is confusing, but it should be unnecessary.
I recommend using nuget.
Great that is good ways to explore. I like the grib_api_example suggestion. I have no need to build by myself but getting a DLL will be wondefull
I am going to explore this and will tell you for the results
thanks
Grib_api_example is refering a Package version 0.7.1 for Grib.api Visual studio seems not able to update for this version
I replaced all "0.7.1" by "0.7.0" in GribExample.csproj
Now able to compile and execute
Grib.api seems to have some issues to extract this type of grib2 data : ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/ngac/prod/ngac.20160712/ngac.t00z.aod_860nm (link available 2 days only either need to update for a freshest date in the link)
Content for that grib2 file described here http://www.nco.ncep.noaa.gov/pmb/products/ngac/ngac.t00z.aod_340nm.shtml
wgrib2.exe has no issue to extract those data
I observed that msg.Values(out myValues) is not extracting good values. Count is OK Also msg informations are not well extracted probably, like Name, TypeOfLevel
what do you think?
Regarding the values, do the GeoSpatialValues
contain the information you need? Also some libraries start at the bottom of the grid and read up and vice versa.
Assuming GeoSpatialValues
has the correct data, it sounds like NOAA is using parameters that ECMWF doesn't. The strings are simply written in a text file in the Grib.Api definitions folder -- definitions/grib2/template.4.48.def
, for example. I'll take a look at NOAA's grid definition and see if I can tell what's missing.
It looks to me like the remaining information you need is in the web page you linked. Is that right? I.e., if you can get the correct data from GeoSpatialValues, then you already know the parameter name, the description of each msg.
If you need more information, lmk. I can contact the grib_api team if I can't figure it out myself.
Whaoa the definition settings are really powerfull
include "template.4.parameter_aerosol_optical.def", in "definitions/grib2/template.4.48.def" refers to a non existing table : 4.233.table
codetable[2] aerosolType ('4.233.table',masterDir,localDir) : dump;
Perharp the reason that Values are non correctelly decoded????
extracting into a text format using wgrib2.exe, I can get these values bellow for the bottom of the grid. I have really different Values when extracted with Grib_api. Only for that Gib2 Optical Aerosal Depth file (strangely GribCS also have difficulties to extract. GribCS returns a null arry, when Grib_api is doing better but not fully perfect. Correct count of values but wrong values along the grid)
So probably only the Grib_api team can fix that? I guess they have an automatic process to update the definitions files???
360 181 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 7.47512e-05 ..........
Are those the values you see or the values you expect to see? I'm looking at the aod_860nm file and I see grid data like this:
-76 12 4.2121328125E-05
-76 13 4.2121328125E-05
-76 14 4.2121328125E-05
...
-90 357 8.3081328125E-05
-90 358 8.3081328125E-05
-90 359 8.3081328125E-05
Can you tell me what you expect to see?
I took those values from the first message in this file. You need to change the extension to "zip". ngact00zaod860nm.txt
Can you tell me what wgrib2 gives you?
Extracting your file aod_860nm as Text format with wgrib2, I have those values for the first record. This is for the bottom of the grid (i.d South Pole)
360 181
8.94194e-05
8.94194e-05
8.94194e-05
8.94194e-05
8.94194e-05
......
Looks to be coherent with what you have
When extracting with Grib_api, I can see these type of values (from double[] lesValues; in the code bellow)
Very different values!!!
0.062219401328125014
0.062219401328125014
0.062219401328125014
0.062219401328125014
My extraction code looks like this
using (GribFile file = new GribFile(@"ngac.t00z.aod_860nm"))
{
foreach (GribMessage msg in file)
{
Console.WriteLine(msg.Name + " " + msg.TypeOfLevel);
Console.WriteLine(" " + msg.ValuesCount);
double[] lesValues;
msg.Values(out lesValues);
}
}
Try GeoSpatialValues
. There's an example in the README. Lmk how it goes.
On Jul 14, 2016 5:00 AM, "bremy" notifications@github.com wrote:
Extracting your file aod_860nm as Text format with wgrib2, I have those values for the first record. This is for the bottom of the grid (i.d South Pole)
360 181 8.94194e-05 8.94194e-05 8.94194e-05 8.94194e-05 8.94194e-05 ......
Looks to be coherent with what you have
When extracting with Grib_api, I can see these type of values (from double[] lesValues; in the code bellow)
Very different values!!!
0.062219401328125014 0.062219401328125014 0.062219401328125014 0.062219401328125014
My extraction code looks like this
using (GribFile file = new GribFile(@"ngac.t00z.aod_860nm")) { foreach (GribMessage msg in file) { Console.WriteLine(msg.Name + " " + msg.TypeOfLevel); Console.WriteLine(" " + msg.ValuesCount); double[] lesValues; msg.Values(out lesValues); } }
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/0x1mason/GribApi.NET/issues/30#issuecomment-232607643, or mute the thread https://github.com/notifications/unsubscribe/AEX_-4lZfHk-qEBMWLw8X_bqMglVBI-Cks5qVfqVgaJpZM4JItl6 .
OK I understand now. Wgrib2 and Grib_api are providing values in different orders Wgrib2 starts at lat -90 Grib_api starts at lat 90 Knowing that, I can see the same values but in different orders
I was able to see that thanks to GeoSpatialValues providing lat & lon for each value
And finaly both GeoSpatialValues and msg.Values(out lesValues) are providing the same and correct "values"
many thanks for your help
You're welcome. Glad you got it working. I'll file a ticket re the param strings. Not sure why they don't display correctly.
On Jul 14, 2016 6:41 PM, "bremy" notifications@github.com wrote:
OK I understand now. Wgrib2 and Grib_api are providing values in different orders Wgrib2 starts at lat -90 Grib_api starts at lat 90 Knowing that, I can see the same values but in different orders
I was able to see that thanks to GeoSpatialValues providing lat & lon for each value
And finaly both GeoSpatialValues and msg.Values(out lesValues) are providing the same and correct "values"
many thanks for your help
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/0x1mason/GribApi.NET/issues/30#issuecomment-232813461, or mute the thread https://github.com/notifications/unsubscribe-auth/AEX_-6dal3NjCSjV3E5QOMFyAYKqUMxFks5qVrsMgaJpZM4JItl6 .
@bremy It's a small thing, but if you like the project, please :star: it :) Thanks for using it!
Hi Eric, I am actually using GribCS and would like to switch to your solution but I can't understand the how to install and setup. to have a short sample working correctly I am on Win7 64bits and uisng VS2015
from what I undestood, it is necessay to run build\build_gribapi.cmd build 14 Release 2.6.4
then bin\x64\Release\Grib.Api\lib\win\x64 is created then I can used the create DLL Grib.Api.dll for my example as with the lines of code here bellow
When excuting I am always getting this exception Could not find Grib.Api.Native. If you're using ASP.NET or NUnit, this is usually caused by shadow copying. Please see GribApi.NET's documentation for help
How could I fix that?
Many Thanks
BR