[Paraview] netCDF reader

[Moreland, Kenneth]

> I have identified those points which causes problems with the actual
> /ParaView3/VTK/IO/vtkNetCDFCOARDSReader.cxx
> - if a regular spacing coordinate variable decreases (90 to -90 for
> example), you always get a vtkRectilinear grid.
> It should reach, wth the computing choice made, to the creation of
> vtkImageData. This is the case if you put
> the axis in an increasing order.
> You can correct this by placing a fabs set on tolerance variable
> 108c108
> < double tolerance = fabs(0.01*this->Spacing);
> ---
> > double tolerance = 0.01*this->Spacing;

I'm not sure vtkImageData (and everything that uses it) really supports
negative spacing.  See, for example, this email thread:
http://www.vtk.org/pipermail/vtkusers/2009-May/100989.html.

> - Test on units should be case independant
> line 133, units.find(" since ")
> I have netCDF files where "since" is typed with uppercase (generated by
> ferret software from the NOAA/PMEL).

That is easy enough to change.

> Spherical coordinates should be possible in any case (regular spacing or
> not), even with a 2D variable where
> height is 0 because field is at surface.

Yup.  I already made those changes.

> User choices for zorigin and zscale should be taken in consideration .
> Both set to 1 by default.
> In addition, a user choice zpositive to tell the direction in which the
> coordinate values are increasing
> should also be proposed. With allowed values : up or down (up by default).
> Perhaps also a zorder choice to treat files where zdimension has to be
> reordered to get k=1 representing
> surface.

I am confused here.  Where are zorigin and zscale defined?  I do not see any
mention of them in the CF or COARDS specifications.

> 
> There is also the problem of connectivity and blank cells (and Z
> clipping range - in spherical coordinates you
> don't want to see the globe when missing cells exist).

Of course I have noticed this.  I have left it this way because it is not
clear what the right solution is.  There are two issues to closing the grid.
The first is that the CF/COARDS convention does not really specify whether
the grid is actually supposed to be closed.  It is perfectly valid to have
an open sphere (in fact common in the latitudinal dimension).  Of course, a
simple check of the distance between the two should clear that up.  Or
perhaps looking at the bounds of the data.

The second issue is one of connectivity.  More on that below.

> Plus, the fact that CF conventions covers also curvilinear grids where
> longitudes and latitudes
> are described with a 2D arrays.

Uh, isn't this the only way to define curvilinear grids in CF?  It is
already supported by the netCDF reader.

> This is why I haved used a vtkPolydata
> structure (with limitation
> that the application was not really to visualize 3D field, only 2D
> fields in a 3D mapping when
> projection uses spherical coordinates.

Oh.  I see why you proposed using poly data now.  I still don't think this
is feasible because of the 3D grid issue.  However, we could change the
netCDF reader to generate a structured grid that would be spatially closed
but not topologically closed.  If you needed the data to be topologically
closed, you could always run the clean to grid filter, which would convert
it to an unstructured grid that would support such topology and remove the
duplicated points.

-Ken