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

20030604: McIDAS GINI server

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20030604: McIDAS GINI server
  • Date: Wed, 04 Jun 2003 17:08:21 -0600
>From:  Dave Santek <address@hidden>
>Organization:  SSEC
>Keywords:  200306042048.h54KmxLd028039 McIDAS-X GINI giniadir giniaget

Hi Dave,

>I remember you writing a GINI server....is that part of your distribution?

Yes, I have been distributing the server with the Unidata distribution
of McIDAS for several years now.

>Do you have sites using it regularly?

Absolutely.  Access to the 1km VIS GINI imagery is the portion of
ADDE use on the several community data servers that I setup.

Also, the radar composite imagery that we are creating from the NEXRAD
Level III products are being put in GINI format and, so, are served by
the same servers, and those products are incredibly popular.  I know
that several people back at SSEC are accessing the NEXRAD composites
(the dataset is NEXRCOMP) routinely.  They may not know that they are,
in fact, using my GINI data servers to do the access.

>Is there anything we should know about it?

???  There is nothing special about them.  They are configured in the
same way as the NEXRAD server (DIRFILE= or INFO=BLAH.CFG) and share
much of the same code base as the NEXRAD server.  Should the GINI
servers be added to McIDAS core?

>We have a NOAAPORT SDI system we're putting together and would 
>like to include that server instead of a decoder.

I can tell you that I will be updating the servers to be able to
directly handle the Zlib compressed GINI imagery that will be the norm
in NOAAPORT; currently, the servers only work on uncompressed data.
This may sound like a given our use of the images is a little different
than you might expect:   we grab the imagery off of our NOAAPORT ingest
system, strip off the CCBs, and PNG compress it on the fly for IDD
transmission.  My ldm-mcidas "decoder", pngg2gini, then uncompresses
the images on the user machines for use in McIDAS ADDE.  GEMPAK, on the
other hand was modified to be able to directly use the PNG compressed
format.  The reason this could be done in GEMPAK and not McIDAS was
that GEMPAK reads in an entire image for display while McIDAS (as you
well know) reads in the portion of the image that is requested.

By the way, just for information sake I can tell you that our PNG
compression of the GINI images is _much_ better than the Zlib
compression adopted by the NWS.  Too bad that NOAA/SATEPS didn't see
fit to use our stuff instead of just using Zlib (PNG is based on
Zlib).

The updated GINI servers will be part of my v2003 McIDAS release
which I started working on last Friday about a half hour after seeing
Dee's announcement of its availability.

>thanx

No worries.

Tom

>From address@hidden Thu Jun  5 09:14:49 2003

Great! This is what we were hoping for!!

dave

>From address@hidden Thu Jun  5 10:19:21 2003

>Just for clarification,

>The NOAAPORT GINI products do not have a CCB, so we are not
>stripping anything off....just compressing the image portion with
>PNG. Only the non-image products on NOAAPORT NWSTG and Channel 4
>have a CCB.

>Steve Chiswell