>From: Rob Petrini <address@hidden> >Organization: ABoM >Keywords: 200012202351.eBKNplo14280 McIDAS netCDF ADDE Rob, >The three files that I couldn't find last time are located at : > >http://www.epic.noaa.gov/java/ncBrowse/data OK. No wonder I couldn't find the files on our site. >The URL gets you there directly else one can navigate from Unidata's home >page. OK. >The two local files, meso_PREC_024.nc and meso_SOILM_024.nc that you could not >get from radaraifs.ho was because of the firewall. However, I have put these >files on servb.ho.bom.gov.au in the anonymous ftp dir pub/incoming. If you >succeeded in FTPing to servb.ho, they should be obtainable now. I grabbed them from servb with no problems. >Thanks for your attention/help. Here is the story: I played around with your netCDF files in preference to those that you grabbed from the NOAA site. I got to exactly the same position that you did, and was stumped. So, I contacted the author of the netCDF ADDE servers in SSEC and asked him to take a look. The following is the final message of our email conversation. Scott Lindstrom's comments (the author) begin with a '>'; mine do not. >From address@hidden Mon Feb 26 15:05:57 2001 >To: Scott Lindstrom <address@hidden> >Subject: 20010226: problem understanding how to tailor a netCDF grid config file (cont.) Scott, re: I am stumped setting up netCDF grid configuration file for ABoM grids >I think I have discovered the problem. The quick answer is that >you can't do it. Nuts. >Here's why. > >ncdfgdir and ncdfgget try to make McIDAS grids, which contain in their >grid headers projection information. With netcdf grids from NMC >(oops, NCEP), this is achieved by looking for the mapname variable, >which is 'conformal' or 'mercator' and the proceeding to get different >grid projection information from the netcdf file. Hmm... I am confused (a semi-normal state, by the way). When I look through the example netCDF configuration file, netcdfgrid.cfg, I don't see any variable named 'mapname'. The closest I can come to a reference to a known projection is: # int model_id(nmodels) ; # model_id:long_name = "generating process ID number" ; # char nav_model(nav, nav_len) ; # nav_model:long_name = "navigation model name" ; What am I missing here? >The file you are working on has no such information. Neither does the example configuration file. >So, when the >module CreateParmObj is called (this module is in ncdffunc.c -- the >version I have -- 1.10 -- is searching for the map name at around >line 1007 in the source file). Because the grid type cannot be computed, >the grid header cannot be made, and the server gives up. So, the initial implementation is to determine what "well known" grid the data is on (e.g. NCEP 211, 212, etc.) and proceed from there? >When the netcdf servers were built, they were tested only on grids >originating from NCEP, because that was all we had. The decision >was made to ship out what was done, and expand capabilities as >non-conforming netcdf files were found. This file seems to be >non-conforming in this sense. OK. Perhaps what is needed is the ability to describe, through configuration file entries, the underlying grid if the information is not contained in the netCDF? I am thinking of something like what is contained in the GRIB specification. >I'm cc-ing this to Dave, and I've talked to him about it as well, >so he knows what's going on. OK. >Sorry I didn't have a better answer for you! As soon as I get your feedback to this message, I will pass along the information to Rob. Thanks again for taking a look at this! Tom You will notice that I asked Scott some particulars about what should be in the netCDF file in order to get things to work, but I have not yet heard back from him. As soon as I do, I will pass the information along to you. So, the answer that neither of us wanted is that it is not yet possible to serve _arbitrary_ netCDF grid files through the McIDAS-X 7.7x ADDE server. This is not really suprising given that there has not been enough work done to formalize how one might specify the navigation information in the netCDF file itself. I am hopeful that your attempts at using the server with data files that are different from the ones that SSEC has been used to will prompt the next phase of development on those servers. Sorry for the discouraging news... Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.