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.
