Hi Gary,
The derived data is a little tricky, and you're right the header isn't
very helpful here. In fact, there's only one character that will
differentiate what product is what (IXT"W"01) in your example). That
document you linked still holds up, the derived products are treated
differently than SCMI products.
There will be four iterations of each product per time, one per
satellite region a.k.a. scene: Full Disk, CONUS, Mesoscale-1 and
Mesoscale-2. Not every product will be available for each of those,
but most are. That's why you see different domain information in your
example above. Full Disk shouldn't ever change, except for when they
move the satellite to the GOES-East position. CONUS might change
slightly if the satellite goes into ABI mode 4 (5-minute Full Disk
mode), plus same caveat with the satellite moving. But the mesoscale
sectors can bounce around wherever & whenever, all depends on where
they set them to.
What you'll have to do is save the .nc file then read it to get some
metadata. I'm using ncdump -h for these exampels, but it's straight
forward in python too.
To get the domain of whatever sector you're looking at, find the
'geospatial_lat_lon_extent' variable:
float geospatial_lat_lon_extent ;
geospatial_lat_lon_extent:geospatial_westbound_longitude = -79.18151f
;
geospatial_lat_lon_extent:geospatial_northbound_latitude = 43.12478f ;
geospatial_lat_lon_extent:geospatial_eastbound_longitude = -62.72912f
;
geospatial_lat_lon_extent:geospatial_southbound_latitude = 29.836f ;
geospatial_lat_lon_extent:geospatial_lat_center = 35.94258f ;
geospatial_lat_lon_extent:geospatial_lon_center = -72.28245f ;
geospatial_lat_lon_extent:geospatial_lat_nadir = 0.f ;
geospatial_lat_lon_extent:geospatial_lon_nadir = -89.5f ;
geospatial_lat_lon_extent:geospatial_lat_units =
"degrees_north" ;
geospatial_lat_lon_extent:geospatial_lon_units =
"degrees_east" ;
geospatial_lat_lon_extent:long_name = "geospatial
latitude and longitude references" ;
There is the center point and bounds of your domain. If you'd like to
figure out what scene this is for, use the information below. What I
do is save the data with a temporary file name initially, read the
metadata, and use that to save it again with a more appropriate name
that represents what the data actually is. The following can be found
under the "global attributes" section:
:dataset_name =
"OR_ABI-L2-DSIM2-M3_G16_s20172701422338_e20172701422395_c20172701423257.nc"
;
The M2 in DSIM2 tells me it's Mesoscale-2. For Mesoscale-1 that
section should be DSIM1, and for CONUS, it's DSIC. Again, I'd have to
find a full disk product and look up what it's format is, but I don't
have one handy. It may also be something else during ABI mode 4 or
30-second mesoscale imagery, I'm not positive so be aware.
Normally, you can use the scene_id variable for this purpose, but for
derived products it leaves out if it's Mesoscale 1 or 2:
:scene_id = "Mesoscale" ;
So you might be better off parsing the dataset_name variable to know
as much as you can. Up to you depending on what you need.
If you want to know which products are available for which scene,
these may help:
https://mesonet.agron.iastate.edu/wx/afos/p.php?pil=PNSWSH&e=201705311950
https://mesonet.agron.iastate.edu/wx/afos/p.php?pil=PNSWSH&e=201706151305
-Mike
======================
Mike Zuranski
Meteorology Support Analyst
College of DuPage - Nexlab
Weather.cod.edu
======================
On Wed, Sep 27, 2017 at 8:51 AM, Gary Lucas <gwlucas@xxxxxxxxxxxxx> wrote:
> I am implementing a data ingest system for GOES-16 derived products coming
> through the NOAAport test channel. Does anyone know whether there are data
> elements in the products I can use to as the equivalent concept to a sector
> or area-of-coverage. The WMO headers do not appear to be useful for that
> purpose.
>
>
>
> For example, when I look at the data currently streaming through with the
> head IXTW01 (Cloud Particle Size), I am seeing groups of 3 different images
> which are positioned at 3 different locations. I’m assuming that these may
> be subject to change on a day-to-day basis. For header “IXTW01 NES 271215”
>
>
>
> Received size longitude latitude
>
> 11:47:25 2500x1500 -140.6 to -49.2 14.0 to 52.8
>
> 11:50:03 500x500 -72.1 to -59.2 13.5 to 23.8
>
> 11:50:33 500x500 -79.6 to -63.9 28.5 to 41.3
>
>
>
> I don’t know if it is relevant, but these values do not seem to be
> consistent with the information in
> https://vlab.ncep.noaa.gov/web/data-format-registry
>
>
>
> My requirement is to be able to present something to the user so that he can
> select a product and have a basic understanding of the area of coverage.
> For the conventional GOES-16 products, this need is met quite nicely by the
> sector code. Does anyone know if there is something equivalent in the
> derived products? Is there documentation that covers this issue? If so, I
> would be grateful if you pointed me in the right direction to find it.
>
>
>
> Also, I am interested in knowing if the areas of coverage provided by the
> broadcast will be consistent over time. Does anyone have information about
> NOAA’s plans with this regard? Will the coverage areas included in the
> derived products match the sectors being cut for the standard products?
>
>
>
> Thanks.
>
>
>
> Gary
>
>
>
>
>
>
>
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> noaaport mailing list
> noaaport@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
