I understand about the gap. But what you must determine is exactly what's intended by the data producers. There's no magic here, just the details of data and how to preserve the data for visualization. If the data are 1 degree apart in a cylindrical equidistant projection and the data are on nodes/vertices (dep positions), then you need 361x181, not 360 x 181. If the data are for cells (dep connections), then the positions are the same, but you only need 360x180 of them.
Not to belabor the point, but neither GriB nor netCDF supports this distinction. So, you have to find out what's the story to have the data handled correctly. Typical weather model output should be defined on grid points (dep positions), although some variables (e.g., velocity) may be on offset coordinates. Despite this, the data may not be defined completely. I have seen this in GriB output from operational weather models, archived observations, etc. In both cases, these are the products that are "blessed" for external consumption, but are incomplete to do the visualization correctly. So, I've often had to go to original rather than post-processed data to ensure correctness. If you are really missing say the sector at the prime meridian, you should verify where longitude is defined. In the one degree case, you may actually have the points defined at half degree intervals so that the gap straddles the grid points. Again the solution, unfortunately, is to duplicate points via a Slab and then Mark,(,"positions")->Compute->Unmark, followed by CollectMultiGrid. I say unfortunately, because the duplication may not be correct for the data set, although that's the way you would do it in DX. As to the problem with WorldMapProjections, well, I wrote that macro at least 7 years ago, which was before MultiGrid support was added. I haven't had the need to use it with multigrids, so I didn't enhance it. There is no interpolation involved -- that's a key point. The original data and topology are preserved through the projection. Because there was a gap in the original data, it remains. That's the proper way to do it because some global data have gaps or a discontinuity at a nominal international date line. It would not be too hard to modify the macro to Inquire if a multigrid and apply the projection to each member. Or simply use the Sphere macro that it calls to the original grid and the Slab'd/offset grid and CollectMultiGrid. As to reading data from GriB, there are a couple of approaches, which I've outlined below in increasing difficulty. The tradeoff is that the more difficult methods allow you to integrate access to data within DX as opposed to reprocessing the entire data set prior to visualization, which is standard (and wasteful) practice. 1. Uncompress the GriB files to flat binary (or ASCII) and Import with the general array importer. It doesn't matter what tools you use to access the GriB files. 2. Use wgrib or another utility to extract specific arrays, which are specified via general array importer templates. 3. Invoke wgrib via shell scripts executed by ! Import filters to extract specific arrays via dx or general array importers. These could be encapsulated within a set of macros, particularly for assembling a set of layers into a volume. 4. Do 4. but after extracting the headers that identify what variables you have and pass them to a Selector interactor for user choice, the result of which is then used to invoke wgrib the extract the appropriate array(s). 5. Create a custom import module, which uses your preferred deGriB'g software to tightly integrate GriB access, including header querying, with DX (i.e., to incorporate 4. and 5.) Paul Skeie <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 12/18/2000 04:52:09 AM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: Re: [opendx-users] How control layers? I still haven't found a good way to solve my problem with the sectorial gap near the dateline. I'll be more specific this time. In many of my visualizations I have a global grid on cylinder coordinates, typically output from a forecasting model. The data are frequently supplied to us in grib format. It would be desireable to read in data to DX directly from the grib file. If someone could suggest solutions here it would be highly appreciated. Then to a particular case: I have an ascii data file with data defined at grid points with a one degree grid increment. The data is organized in an array 360x181 in size. The head of the file looks like this: ------------------------- 360 181 102280 102280 102280 102280 102280 102280 102280 102280 102280 ------------------------- I've written a header file that looks like this: ------------------------- file = /home/paul/pdata12.tmp grid = lines 0,0,3,1,3 format = ascii interleaving = record majority = column header = lines 1 field = MSLP structure = scalar type = float dependency = positions positions = regular, regular, -180, 1, -90, 1 end ------------------------- When I plot this using spherical (proj No 7 in WorldMapProjections) I get a sectorial gap near the dateline which must imply that the interpolator fails to understand that the data on the dateline (-180 deg Lon) should be connected to the data at +179 deg Lon. I've had the same problem in many visualization programs and a typical fix is to define the dateline (or the Greenwich meridian if this is where the origin is) twice i.e. on both sides of the array prior to plotting. In many NetCDF files from NCEP, data on the dateline is actually represented twice. In my datafile used in the example above, data on the dateline is not represented twice. I tried to use 'Slab' and 'CollectMultiGrid' to copy dateline data (as suggested by Lloyd Treinish), but the resulting multigrid wasn't accepted as input to 'Projection'. If my problem is just a question of defining the data correct in the header file I would be delighted to learn about it. Cheers, Paul Skeie Lloyd A Treinish wrote: > > > 3. This may be a "feature" in your data or how your defined it to DX. DX > understands the difference between data defined at grid points or vertices > (e.g., dep positions) and data defined at cell centers (e.g., dep > connections). The former would be typical for data from a simulation > (e.g., from finite difference calculations) while the latter would be > typical for an image, DEM, finite element grid, etc. Unfortunately, many > data formats and visualization tools, particularly in atmospheric and space > sciences ignore this distinction, which can be a real problem. So, your > data may have global coverage but is defined to DX as dep positions, > implying the data are at vertices. For example, consider a global > cartesian grid at one degree resolution (e.g., 360x180). If you define the > data at vertices of the quads every degree, then you will have the gap that > you describe. If the data are defined at intermediate locations (e.g., at > half degree intervals) then the gap may be smaller but misregistered. If > the data are defined at cell centers, then there's no gap. You could use > Slab to extract a "column" and then CollectMultiGrid to add it to the end > of the grid, but this could be wrong as far as the data are concerned. You > really need to find out what the data are actually defined and then tell DX > so it does the right thing. >
