Thanks for the input. I was hoping you'd contribute to the discussion. The Unisys DIFAX ftp system can be very irritating at times. But, it is reliable enough that we've never considered going over to Alden. In retrospect, this appears to have been a wise decision.
The FTP setup here is a bit of a kludge. The FTP server is a RedHat 6.0 system which has some NFS incompatibilities with LANtastic TCP/IP. We run LANtastic on our LAN. Even though the rest of the network is monitored, the FTP system isn't. I'm working on a way to monitor that system better.
My biggest complaint is having to pull the charts. That gives me just one chance to get a chart under normal circumstances. Since cron does this, if it doesn't make a connection, I just get a nastygram from the OS (via email) in the morning. That isn't as useful as the chart would have been.
The Ku feed is the best way but that's not for everyone. FTP service is not as reliable as other services. I've developed a more reliable FTP pull mechanism written in Perl. It does a remote directory listing, queries the time for each file and then writes the time to a local database. Then, any time the remote time is different from the local databased time, it transfers the file. This makes sure you don't lose data even if you have a network outage. I'm doing this with the NWS FTP server for Fax charts. I transfer all 900+ charts (.TIF) from that site to the FTP server here. Then I convert them to PCX in preparation for uplinking (see difax directory .pcx files). I will eventually save these in GIF as well. The only problem is that many of the multipanel charts (4 panel ones) are saved on the FTP site as two 2 panel charts. I am working with ImageMagick's montage program to piece these together. When I get this working fully, we may use this as our primary method of obtaining Difax charts. On a side note, our main feed from NWS is not working. Thanks to a mushroom barn fire 9 months ago (local arson spree), the dedicated line to NWS is too noisy to use for Difax. We've been fighting the phone company for months on this issue. Anyway, our backup is... guess... Alden! Considering Alden's situation, this is putting a priority on getting these other sources working.
I do go back via cron (at about 2300L California time) and run a long request for all charts produced the previous UTC day. I figure net congestion and other ftp users will be at a minimum then. It usually works, but significantly increases Unisys' cpu time per chart.
Our FTP server is not on a fast network connection so speed will always be an issue. This is another reason why feeding IDD could be a problem for us. This doesn't count potential firewall problems. If you are curious, the web server isn't located at our facility due to the same bandwidth issues. It is 30 miles away at another facility. We are in the process of upgrading network capabilities here. With upgrades for E-Commerce, our network bandwidth should increase by an order of magnitude. However, it is unclear how weather will link into this or whether we'll be able to.
The charts are really great quality. When printed, they're very crisp and clear. You might consider placing a map out where any Unidata people who are curious can grab it.
I haven't dealt with Alden's charts that are in g3 format. The PCX files we have are very good quality.
Preferably in gif format. That cuts the file size (and tranferred bytes) considerably.
That wouldn't be a problem.
I hope Unisys is considering allowing paying Unidata customers to get DIFAX charts via the LDM?
We're considering it. I'm getting some resistance due to a lot of factors here. But I will continue to pursue this... ________________________________________________________ Daniel Vietor Mail: devo@xxxxxxxxxxxxx Unisys Corp Title: Engineer/Meteorologist 221 Gale Lane Phone: 610-444-2407 Kennett Square PA 19348 Fax: 610-444-2420