Hi Ken, re: > A point of clarification, for this current project we are attempting to > inject the GOES-South (GOES-12) data into our legacy > satellite processing system, not the applications Fred developed for us last > year (although these concerns do impact his stuff too). > > Our legacy system relies on the McIDAS-X workstations scheduler to do the > data ingesting and we rely on it to make sure we > only ingest the most current data (that we haven't already gotten, we don't > ever want to get any image more than once) from each SDI we connect to. > Our software doesn't do much time checking, whatever is received via the > McIDAS scheduler is processed, when compositing images together it tries > to find a matching time for each data set. So, the obvious problem is once > the UCAR SDI has future data our scheduler won't ingest any data until UCAR's > SDI has purged the future data or time passes the future file. I understand. re: > address@hidden data]$ skl.k > *** SCHEDULER IS ON *** MESSAGE DEVICE IS: N > T# ID XS NEXT EXECUTN # REM INTERVAL TOL NAME PROJ COMMAND TEXT... > -- ---- -- ------------ ----- -------- ----- ---- ---- ------------ > . > . > . > 1 650 12124 224200 MANY 500 400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES > 1 651 12124 224200 MANY 500 400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES > 1 652 S 12111 132700 MANY 500 400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES > --END OF LIST The situation is now clear to me: the IMGCOPY invocations always grab the "most recent" image from the server. The logic in the server is very simple: get a list of all images; sort the list by nominal image time; send back the one that has the newest time. This is a nice feature of ADDE image servers, but it is error prone in the face of image times that are in the future. A thought: the invocation of IMGCOPY could be replace by the invocation of a McBASI script that could do simple checking of times that are in the future. The only reason I keep returning to the point of doing checking on the receiving end is I want users to benefit by the data access we make freely available, not be hampered by it. Just so you know that we are taking this problem seriously: This past weekend we checked cabling, connections, and everything else we could think of in addition to moving the ingest to a dish that can track the latitudnal movement of GOES-12. There is not much more we can do to clean-up the data ingest given our constraints of dish location (between two buildings looking over the top of one the buildings and a tree that partially obstructs the view) and no funding to move the dish to a better location. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: GEJ-957244 Department: Support McIDAS Priority: Normal Status: Closed
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.