>From: "James D. Marco" <address@hidden> >Organization: Cornell >Keywords: 200006211552.e5LFqCT10971 Unidata-Wisconsin ldm-mcidas pnag2area Jim, > Yes, the conversion time is a bit rushed, but do-able for >straight forward McIDAS users such as myself. The time frame >doesn't permit enough testing before the semester starts, if you >delay. I agree. >If the delta-formatted products remain available, then >customized programs should still work, sans new stuff. Yes, we could start broadcasting the same products in both PNG and delta compressed formats, but I would much rather not do this. I figured that essentially all folks out there were converting the UW stream image products back into their native McIDAS AREA format; I guess that I was wrong about at least one site. The other assumption that I was making was that either pnga2area would work on a user's system or it wouldn't. If it did, then the user would be in exactly the same position as s/he was before. If it didn't, I would be here to step in and help get it working. The addition of the CIMSS products would give the sites some products _they are not dependent on_ that they could use to get the new decoding working. >A thought (these are rare): > Would it possible to modify a copy of the pnga2area decoder > to produce an intermediate delta encoded file that could be > piped back in to the local LDM data queue for decoding by > the old tools? (Work for Unidata while users get ready for the > new format.) This could be done, but I think that it is time that would be better spent getting sites up using the new compression. >Goal: > Allow unmodified customized programs to use the new format. I think that NMIT might be using WXP's ability to read the delta encoded image files directly (which I always considered a bad idea since the delta encoding format was not guaranteed). If this is the case, there shouldn't be a problem since WXP can also read AREA files directly. All that would have to happen is the addition of the decoding. > Allow compression of the network feed to: > Reduce network bandwidth > Increase product availability > Allow users time to perform the modifications to their > locally customized programs, without slowing much needed > upgrades to the data stream. Good thinking. I will keep this in mind as a backup position. >Downside: The local machine would spend more CPU cycles, and > handle data twice, with a 'conversion' program running. > > Hence, any home-grown programs using the old format are > eventually forced into rewrite, simply for efficiency. Right. > ...and, of course, "We'll get Tom to do it." Hmm... :-o Tom
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.