Mike,
Jeff Whitaker just patched basemaps so that we can handle any GOES images.
I'll get back back to pygrads and images sometime next week after I get the
current set of binaries relesead on sf.net.
The main question in my mind is: 1) should we handle images entirely on
the python end? or 2) Teach GrADS to read images (just another data file),
and display them with a pixmap extension. The problem with 2) is that GrADS
does not understand too many map projections, and we could make much faster
progress in 1) than in 2). The problem with 1) is that matplotlib is
*slow*. However, these 2 approaches are not exclusive.
Another trick that may help integrating GrADS graphics and python is to
write a small function that reads the gx metafile from memory and draws it
on the matplotlib canvas. This would give us the speed of GrADS graphics
(I'm expecting that rendering the gx meta is fairly quick as matplotlib uses
cairo underneath). And if we translate the metafile (x,y) coordinates back
into lat/lon, then we can use matplotlib projections to warp the plots on
the screen, on any basemap supported map transformation. One by-product of
this is to write out the lat/lon gx metafile to disk as a shapefile. (In
fact, matplotlib/basemap can draw shapefiles --- this is the way the draw
the coastlines).
Here is a proposed roadmap:
1) Write GaIL.py as an extension of PIL which not only reads the images (as
PIL does), but collects the geo-referencing as well. Initial formats to be
supported would be AREA, the NetCDF files you sent me the other day (not the
atrocity written out by AreaToNC.jar), geotiff, and PNG/JPEG/GIF provided
that a KML kind of metadata is provided (much like a "ctl" for images).
2) Integrate GaIL into GaLab so that we can handle these and contour/image
plots transparently. (A call to GaIL.open() would automatically set basemap
to match the image coordinates).
3) Write ga.show() which would render the gx metafile in memory on the
current matplotlib figure, using the current basemap settings. These would
give us the speed of GrADS basic graphics, and the ability to handle sat
images.
4) Bring back "set gxout pixmap" as an extension. By providing an
appropriate DDF GOES images in NetCDF could be read in as a regular grads
variable, and displayed on the screen, and contour plots supperimposed. At
this point the 100 color limit will get on the way.
5) The "set clevs"/"set ccols" way of associating colors with contour
intervals is very awkward when you are dealing with a continuous color
scale. The notion of a colormap and scaling will need to be implement. One
may be able to handle this as an extension. Perhaps we should wait until v2
is out doing 4) and 5).
Any comments greatly appreciated. Any body willing to help with any of
that?
Regards,
Arlindo
On Jan 25, 2008 11:39 AM, Mike Fiorino <mfi...@gm...> wrote:
> hi arlindo,
>
> good news, got code from ncdc that seems to work area files...
>
> see:
>
> ftp://ftp.nhc.noaa.gov/users/fiorino/ncdc_mcidas.tgz
>
> the tarball is what i got from ken knapp at ncdc and includes a sample
> data file.
>
> it was orginally built under lahey fortran, but i got g95 to work...
> i've asked ken for the code that creates those nice .nc files too...
>
> i had to make a couple of small hacks, an array was not declared as
> allocatable and the usual problem with non-standard i/o -- had to use
> the compiler specific access='stream' option in the open the file for
> access like in C.
>
> seems like a good candidate for your extensions...
>
> thanks best /r mike
>
>
>
--
Arlindo da Silva
da...@al...
|
