[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010601: Satoverlay and satradar



>From:  "Ng Say Teong" <address@hidden>
>Organization:  ABoM
>Keywords:  200106010114.f511E8p03324 BOM radar server

Say,

Sorry that this has taken me so long to get around to, but I have not had
hardly any free time in the past 2.5 months!

>The source codes to Bom Radar (C++ version) is in three classes dbADDE.cpp,
>dbRadar.cpp, dbMcRADAR.cpp; each deals separately with file-handling, native
>BOM Radar images conversion, and  McIDAS secondary server/parser interfaces
>respectively. They are currently located at:
>
>               ~nst/radar/src
>               ~nst/mcidas/src
>
>in servb of BOM.

I had a chance to look through this code last week some time.  I see several
things that should be upgraded at some point.  I will put together a list
of the changes I made to my server code during the acceptance into core
McIDAS.  This will have to be done catch as catch can, however.

>However, the latest codes of the above C++ classes are being held by Andrew
>Donalson (a member of aifs team) for the development of encompassing 16
>level reflectivity.

The code that I originally wrote was designed to handle 16-level reflectivity
data, but I did not have any example data to test it on.  It was also
designed to be able to handle a variety of radar products, not just
reflectifity.

>I have not yet update the my original source codes from
>him, as it is still subjected to his further development.

OK.

>At the time of integration, I do not have full-understanding of the entire
>original code you have written for Bom, the best I could do (and had done)
>is simply to encapsulate your original C codes into the C++ modules.

That is what the code looked like to me.  This will make it relatively
easy to fold in the changes that will be needed.

>I have yet to carry out a revision on these codes. Any improvement will be
>most desirable.

OK.

>Unfortunately, I am still being bogged down by the pending desire of making
>McIDAS (via ADDE) to read grib data files (configurable multiple grib files
>under a given dataset name), despite the initial success of making McIDAS
>accessing MARS data directly. These interfaces are similarly found in
>~nst/mcidas/src in the above.

I am _very_ interested in this project!  Any information you can provide
after you get things working would be most appreciated.

>Tom, would you be kind enough to browse through the sources code to the
>above three C++ classes (if it is possible) while contemplating a detail
>response, and advise on its improvement in relative to Jeff's comments?
>Please let me know how I can assist.

I promise to send you comments on what I ended up doing to my code for
incorporation into McIDAS core.  Since you rewrote my original C code
in C++, it is not likely that you will have to worry about the routine
name clashes that I had to deal with (the NEXRAD radar server code that
SSEC adopted links against the SDI library, and there were several routines
in the SDI library that had the same names as ones in my code).  I say
this _assuming_ that C++ name mangling will endup with entry point names
that are very different than ones from C.  Please let me know if this
is a bad assumption (I am not a C++ type, so you will have to be patient
with me).

>Thank you.

I hope to be able to detail the changes that will be needed/useful sometime
in the coming week.

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.