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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: black spots in IR images
> I'm sorry to report they still appear for me.  I'm attaching two more
> images, newwv1.gif is band 9 from lead.unidata.ucar.edu.  They appear
> in band 13 as well, but are more obvious in band 9.

OK.  This should all be fixed when I get the true calibration module
written.  And, having a "registered" calibration module will allow
IMGCOPY to create viable (meaning fully usable) AREA files.

re: makes the use of EU tables easier.

> FWIW, newwv2.gif is a sample from my local data, prior to updating
> McIDAS to the latest version.  The side-by-side of the two clearly
> shows how brightness has increased in your latest version.

The brightness definitely increased, but the pixel-to-pixel variation
at the lowest IR temperatures is visibly less than for the GRB-delivered
GOES-16 images.  Investigating this is what I was spending my time 
(aside from all of the other things needing to be done around here)
yesterday and Monday.  Admitting that I need to write a full calibration
module was a disappointment yesterday afternoon, but it should solve
two major problems that exist currently.

re: available bandwidth in NOAAPort

> Bingo.  The GOES-R NOAAPort document states the data rate "is not
> expected to exceed 25 Mbits/second."  But that's per satellite, so
> after GOES-17 lights up that's up to 50 Mbits/s.  While that's just
> the estimated peak rate, our NOAAPort receiver is only rated to handle
> 80 Mbits/s, with only a 10/100BaseT network interface.  I don't know
> if WFOs have a different kind of receiver, but I do know NOAAPort
> bandwidth was a concern for the GOES-R series.  So I think you're
> right, I think that's at least part of why the full disk is as coarse
> as it is.

I assume that it is exactly the reason that the full disk images all
have reduced resolution.  An interesting comparison is the size of
band 2 images between GRB and NOAAPort:

GRB C02    NP C02    (worst case today)
441316419  1752893

440 MB vs 1.7 MB (both approx.) !!

re: decision to remap imagery for AWIPS

> Funny you mention this.  One of the things I've been exploring is
> re-creating our current satellite page using GOES-16 data with McIDAS.
> The projection used for the CONUS sector seems very close to the
> GOES13/15 data coming over the NIMAGE feed.  But since IMGCOPY still
> isn't working with GOES-16,

See my comment above...

re:
> I've been using IMGREMAP which does work
> to get the data into area files.  My question is this: is there a way
> to read the projection information from a data set (GOES-13/15) to
> know exactly what parameters I need to pass IMGREMAP in order to
> create an identical projection?

The way to create an identical projection is to remap onto an existing
image.  Quick example:

IMGCOPY GINICOMP/GSN8KIR MYDATA/IMAGES.3000 SIZE=SAME
IMGREMP NPGOESR/CONUSC13 MYDATA/IMAGES.3000 SSIZE=ALL

re:
> Side note:  The conical projection doesn't bug me too much, though I'm
> somewhat biased as we've been plotting satellite imagery in that
> projection here for as long as I can remember.

What annoys me about the remap is loss of information in the data.

re:
> What does annoy me is
> the northern extent of the CONUS domain being so close to the border.

I completely agree!  WTF, Canada doesn't have weather that is important
for the U.S.!?

re:
> So now the only option we have to plot imagery into Canada is to use
> the overly-coarse full disk data.  Is what it is I suppose.

Yes, for now.  As soon as we get our data serving component of our
GOES-16 ingest up and running, sites will be able to create image
sectors with the coverages they want.  We will, of course, have to
keep a close eye on use of this service so that it doesn't keel
over from over subscription.

re: stay tuned

> Looking forward to it.  Thanks for everything!

Having you testing code changes and giving feedback and advice has
been very useful for me.  I really do appreciate it!

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: JGN-249914
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.