Earthdata Forum

It's getting to be that time of year when there are more potential storms in the DC area (...both in the atmosphere and on Capital Hill...) so we're checking up on all of our alternate data sources.I'm trying to process an L1A file I obtained from LANCE and am running into issues in the modis_GEO.py command. The particular test granule I'm using was downloaded from nrt4.modaps.eosdis.nasa.gov as MYD01.A2019303.1750.061.NRT.hdf but I believe the issue to be more general to "recent" L1A files downloaded from there.When I call modis_GEO.py on the L1A file (I've re-named everything here to follow the soon to be old OBPG naming conventions) I get the following error:$ modis_GEO.py --threshold=10 -o A2019303175000.GEO A2019303175000.L1A_LACTraceback (most recent call last):  File "/marine-services/ocssw/scripts/modis_GEO.py", line 194, in <module>    sys.exit(main())  File "/marine-services/ocssw/scripts/modis_GEO.py", line 180, in main    modis_env(m)  File "/marine-services/ocssw/scripts/modules/modis_utils.py", line 271, in modis_env    self.start, self.stop, self.sat_name = modis_timestamp(self.file)  File "/marine-services/ocssw/scripts/modules/modis_utils.py", line 158, in modis_timestamp    sat_name = meta['ASSOCIATEDPLATFORMSHORTNAME'].lower()TypeError: 'NoneType' object has no attribute '__getitem__'I've tried it with copies of ocssw downloaded fresh from scratch on 10/31/2019 and this morning (11/4/2019) so it does not appear to be something recently fixed.Is this something that can be worked around and/or can you please update the script to query the different possible types of metadata?Another related question - do you know, please, where I would look on LANCE for ephemeris and attitude files that can be used as input to modis_GEO.py?Thank you,-Andrew L.

Andrew,

Works for me.  I grabbed the same file from nrt4 and it processed just fine through modis_GEO.py - both before and after renaming....so I got nothin'

As for where in to find the att/eph on nrt4 ... a same place as the L1A's:

https://nrt4.modaps.eosdis.nasa.gov/archive/allData/61/

Specifically:
https://nrt4.modaps.eosdis.nasa.gov/archive/allData/61/PM1ATTNR_NRT
https://nrt4.modaps.eosdis.nasa.gov/archive/allData/61/PM1EPHND_NRT

Sean

Works for me as well (on fedora 31).  I'm curious to know what is different with Andrew's setup.   Before I retired, we sometimes had issues with blocks of null data being inserted into as many as 10% of downloads by some ancient network gear,  so the first thing I check is sha1sum's.   Since the problem seems to be with the python script, it would be good to check python 2 and 3 and the sha1sum's of the scripts:

Here:
$ sha1sum MYD01.A2019303.1750.061.NRT.hdf
80438d927795c45d217379a989927fded5a61e2d  MYD01.A2019303.1750.061.NRT.hdf
$ python --version
Python 3.7.5
$ sha1sum $OCSSWROOT/scripts/modis_GEO.py
fc43de17c9106d3bb626d28d415006f3da2f5bf9  /home/g/ocssw/scripts/modis_GEO.py
$ sha1sum $OCSSWROOT/scripts/modules/modis_utils.py
7541a9746eb73742031c3139555ab3d75f9733f5  /home/g/ocssw/scripts/modules/modis_utils.py


"python2 ~/ocssw/scripts/modis_GEO.py -v MYD01.A2019303.1750.061.NRT.hdf" also works.