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

[McIDAS #GSA-478310]: ingesting mcidas area files in awips



Hi Justin,

You asked one question that I hadn't really notice until now:

If I try to use âsize=allâ I run into the issue of âIMGREMAP: destination
image is too large.â This is especially problematic when using the mercator
projection due to the larger x/y dimensions. Any suggestions on this, Tom?

I believe that buffer sizes could be increased in the IMG* commands that
are being used, but I can't give any specifics as I have not delved into
the problem.

Cheers,

Tom

> I believe I diagnosed the issue regarding the display of Himawari-8 files in 
> AWIPS II.
> 
> The awips mcidas decoder does not recognize the rectilinear projection and I 
> donât believe I see a reference to this projection in the mcidas decoder. 
> This is the projection I was attempting to use when remapping the images in 
> mcidas. Also, I believe the format needs to be either VISR or GVAR in order 
> to always be recognized (dummy up the system?) with the plugin initially. My 
> reasoning is because all of a sudden â totally random â the product 
> browser is no longer showing "Himawari-8" as âUnknown-86.â It is actually 
> showing Himawari-8 as its own satellite category made in creatingEntities.xml 
> called, âHimawari-8.â The Himawari-8 SS entry has always been in the 
> lookup tables since I started and nothing else that I recall has changed (the 
> SS has always been defined in mcidas), so that is my guess at this point.
> 
> I have since changed to the mercator projection and the data is now 
> displaying.
> 
> Also of note, the higher ingest.sh memory is only needed when ingesting the 
> massive band 3 area files. The minimum acceptable memory when running the LDM 
> for ingest.sh that I have found when ingesting the very large files is about 
> 9000MB.
> 
> Only issue I am now having is midas-related. The very large images associated 
> with band 3 which are by default 22,000 x 22,000 in IMGCOPY are not easily 
> remapped. Upon running IMGREMAP, I am forced to either lower the resolution 
> from the default (0.50 km) or I have to reduce the size of the image. If I 
> try to use âsize=allâ I run into the issue of âIMGREMAP: destination 
> image is too large.â This is especially problematic when using the mercator 
> projection due to the larger x/y dimensions. Any suggestions on this, Tom?
> 
> Justin
> 
> 
> > On Jan 20, 2016, at 7:16 PM, Unidata McIDAS Support <address@hidden> wrote:
> >
> > Hi Justin,
> >
> > re:
> >> Thank you, Tom.
> >> Yes, the problem was exclusive with AWIPS.
> >
> > Yup, I thought it must be.
> >
> > re:
> >> On a side note and for consistencies sake I converted MSG3 HRV to AREA
> >> files and was able to successfully ingest and display the files in AWIPS
> >> each time -- no issues.
> >
> > Interesting!  Thanks for passing this along!!
> >
> > BTW, Michael reminded me of the following:
> >
> > re: have we had success bring AREA file-based imagery into AWIPS-II?
> >
> >  Outside of UNIWISC, no.  And the GVAR products are still not fully
> >  supported.  Right now all non-GVAR UNIWISC products decode and display
> >  perfectly, but the GVAR products return a persistence error if more
> >  than a single product is ingested (EDEX thinks that the product already
> >  exists if a previous scan was ingested that day, even though the timestamp
> >  is obviously different, so basically ingest works for one image per day
> >  per product).  This make me wonder if the same problem occurs with the
> >  Himawari images.
> >
> > So, the problem you have been having with the Himawari images may
> > (or may not) be tickling a more general problem in AWIPS-II.  We don't
> > like this situation, but...
> >
> > 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: GSA-478310
> > Department: Support McIDAS
> > Priority: Normal
> > Status: Closed
> >
> 
> 

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: GSA-478310
Department: Support McIDAS
Priority: Urgent
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.