Lloyd (or others familiar with remote sensing topics), please tell me more about this dep "positions" vs. dep "connections" issue. I have some knowledge of it, but never have gotten a complete handle on it. I have inherited one of those visualization tools in the atmospheric sciences which has "ignored the distinction". I have tried to set things straight in the past, but am still hindered by confusion.
Currently I am reading in satellite data as dep "positions". I know that this isn't exactly correct because when the data is displayed in an image, the colors are interpolated across data points. This is an unwanted effect, because the data points do, in fact, correspond to an "area" of some (not easily obtained) size. But, following inquiries about this issue, I concluded that it's not as simple a solution as to merely convert my data to dep "connections" or cell-centered data, that this wouldn't be 100% "correct" either (I do know that it doesn't work well to do the conversion after the data has been read in, that if data truly does fit the definition of cell-centered, it must be defined that way up-front. But, I gather that there is more to it than that). So, my data remains dep "positions". With a huge data set, the eye can't detect the interpolation very well. But with a subset, there is a huge problem. I get around this by displaying the small number of points in the subset with a glyph of appropriate (data scaled) color. However, this is a flaky work-around. The difficulty that I've had with the concept of satellite data being treated as cell-centered is that any "grid" that a particular data set would "fit" into would be irregular and highly variable, depending on geolocation. I'm sure that the vertices of each grid cell for each data set could be calculated or determined some how, but the idea of specifying them within dxseems to me too big a bear to even think about handling. So, how do us misguided atmospheric/space science folks recover from a mess like this ? Lloyd, this topic came up briefly some time back when someone asked for a DX/IDL comparison. It was my opinion that IDL's treatment of data as arrays was a much more straight forward concept in terms of applications to satellite data, but you seemed to suggest that DX is perfectly suited to handle it, and well, or better. I wanted to query you more about that at the time, but didn't. There didn't seem to be much interest in remote sensing topics within the user's group. But now, there is some meteorologist out there apparently who is beginning to build a dx tool from scratch. I would highly recommend to him tackling these sorts of things at the onset. By the way, I've also had a similar problem to this "sectorial hole" that Paul describes. I don't know what kind of global projection he is using, but when I use rectangular (cylindrical equidistant), I get wrap-around problems (a line across the globe trying to "connect" fragmented satellite swath of data). Is this also a dep "positions" vs. dep "connections" issue ? Regards, Sharon On Dec 14, 8:20am, Lloyd A Treinish wrote: > Subject: Re: [opendx-users] How control layers? > > 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. > > > To: opendx users <[email protected]> > cc: > Subject: [opendx-users] How control layers? > > > > First I want to thank L.A. Treinish for a very helpful reply > to my first submittance to this list. > > 3. > When I display data that are on a global geographical grid I get > a sectorial hole in the plot near the dateline (origo). I guess I could > avoid this by copying the leftmost column of my datamatrix (data at 180W) > to a new column on the right of the datamatrix. I could do this on the > datafile, > but this would take up diskspace and is not a very elegant solution. Could > someone suggest another workaround? Can I use the Compute module? > > > Cheers, > Paul Skeie > > > >-- End of excerpt from Lloyd A Treinish
