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

[LDM #UKZ-297744]: mcidas decode issue

Hi Dan,

re:
> First of all, thanks so much for the support. In my case the ldm library was
> not linked, so a quick LD_LIBRARY_PATH fix got me underway.

Very good!

re:
> As for the "what-I-plan-to-do-with-this-once-I have-it" part: I am the new
> sysadmin/tech person for the meteorology department. As such, I am learning
> the LDM and its decoders (gempak and mcidas) is order to get the data that is
> possible.

OK.

re:
> Part of my discovery was to see if any of this would yield GOES 16/17 data.

The east and composited east-west sectors in the Unidata-Wisconsin datastream'
(IDD feed type UNIWISC aka MCIDAS) are GOES-16 images that have been remapped
into GOES-13 (east sectors) and rotated METEOSAT (east-west composites)
projections.  They both "look" like they are from GOES-13, but in both cases
the eastern portion is from GOES-16.

re:
> The position I am beginning has been vacant for over a year, and I have seen
> discussions regarding a change in how to get this data. I do not believe we
> are getting this data at present.

I just checked the real-time statistics that Plymouth machines are
reporting:

http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex

sleet.plymouth.edu is REQUESTing:

UNIWISC - GOES-16 imagery remapped into GOES-13 projection and
          GOES-15 imagery for western views and GOES-16 + GOES-15
          remapped into a rotated METEOSAT projection for east-west
          composites
NIMAGE  - GOES-15 (west) sectors in GINI format

It is also REQUESTing the NOTHER feed from the Plymouth NOAAPort ingest
machine, but only a portion of it.  NOTHER contains GOES-16 and GOES-17
imagery and Level 2 products.  The imagery (which are also Level 2 products)
are sent as tiles (pieces) that need to be stitched together in order to
create full "scenes" (coverages; there are tiles for the CONUS and Full
Disk coverages while the mesoscale scans are small enough to be sent
to be entirely sent in single pieces/tiles.  More on the NIMAGE feed
later in this reply...

re:
> Now that I have MCIDAS-LDM working, I can see area files, but do not know
> their source, but from the gempak decoders it looks like I am getting
> GOES-13/15 data (based on directory names that are being auto-generated)
> but I don't think that's possible.

The images that are being filed in GOES-15 hierarchies are, in fact, from
GOES-15.  GOES-15 imagery will stop being created/distributed in the
June/July time from when GOES-15 is turned off.

re:
> Any guidance you can provide would be very helpful.

We are just getting ready to announce that we will be adding 
fully reconstituted GOES-16/-17 images that have been created
by stitching together tiles distributed in NOAAPort to the
NIMAGE datastream and the other Level 2 products that are currently
distributed in the NOTHER datastream.  This will allow sites to
not have to do the work of stripping off NOAAPort headers and
footers and stitching together tiles to create full scenes.
The downside of this is that the full volume of these images
and products is, on average, on the order of 6.3 GB/hour.  Sites
that do not have large pipes to the Internet and are currently
running a NOAAPort ingest locally, will likely want to continue
to do the work of stitching together tiles to create full scenes
from their own NOAAPort ingest.

Some comments:

- the most recent/current version of GEMPAK supports (can use) the
  reconstituted images created by stitching together NOAAport
  tiles

  If you are not running the current release of GEMPAK, you should
  upgrade as soon as you get the chance.

- our adding the reconstituted imagery and Level 2 products to
  NIMAGE will require that sites REQUEST all/some of the NIMAGE
  datastream from the IDD

  This will be normal for sites without NOAAPort ingest capability,
  but new/different for sites (like Plymouth) that have their own
  NOAAPort ingest capability.

- because we will be significantly beefing up the offerings in
  the NIMAGE datastream, we will be revisiting the imagery that
  is currently being sent in the UNIWISC datastream

  We will continue to create east-west composites, and potentially
  provided GOES-East CONUS coverages remapped into a Lambert
  Conformal projection.  We will be removing other imagery as
  equivalents will be available in higher resolution, both
  spatial and temporal, from the revamped NIMAGE datastream.

Advice:

- if you haven't already done so, you should install current versions
  of GEMPAK and McIDAS (if you use McIDAS-X) and the IDV

- you should do an assessment of your bandwidth to the Internet so that
  you can decide if you want/are able to REQUEST the imagery you want
  from the revamped NIMAGE datastream

  If you determine that you do not have enough bandwidth to REQUEST
  the reconstituted imagery that we will be making available in the
  revamped NIMAGE datastream, you will need/want to setup stitching
  together of the tiles you are receiving in the NOTHER feed on
  your NOAAPort ingest machine, but are apparently not sending to
  your other machine(s).  We can help you with this process, so please
  do not hesitate to ask!

I think that the above is quite enough information for right now.  If
you would like to talk about the various items above, please let me
know of a day/time that would be convenient to talk.

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: UKZ-297744
Department: Support ldm-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.