[McIDAS #VMY-981880]: GOES (GVAR V1) geometry

Hi Ioan,

re: how are you doing?
> quite well, I have a 8 weeks old baby boy at home:)) so quite busy :)))

So, this means that neither you nor your wife are getting much sleep! :-)

re:
> I guess Yes, there are definitively navigation issues with GOES08 and
> GOES10 data from 1999.

Have you done a web search to see if there have been investigations
made of the navigation issues?  That is how I found out about inter-band
problems with GOES-13 imagery.  I was first alerted to the problem by
a user who was trying to create fog products, and the results were not
making a lot of sense when compared with surface observations.  It
turned out that there was a problem with pixel registration in the
IR bands, and those problems were not easily accounted for.

re:
> I believe these were streamed using GVAR ver 1 (i will confirm by looking
> into the block0 header "version" property of some sample images)

Just so you know, I have seen navigation registration problems with
GVAR imagery throughout our effort of ingesting the data, but the
problem did not seem to be consistent.

re:
> Fixing  this images is not a simple task, and without doubt SSEC could do
> it. I do not know if they would if I asked them. These things can be quite
> costly and we are a small private company:))) so I do not know....

I doubt if SSEC would embark on fixing navigation issues in historic
images if they have not already done so.  I do know that they have
made several data rescue efforts over the years, and their results
seemed quite successful (they made a presentation about their latest
data rescue effort at either the last MUG meeting or the one before).

re:
> Now, I have some  experience fixing these kind of issues with MTSAT 1 and 2.
> Specially MTSAT 1 suffers from very large shifts (up to 20 pixels/25km). I
> fixed some months from 2002 if I recall with relatively good results. Once
> I fix GOES I am going to fix all MTSAT images and MSGIODC as well. Hell of
> a job. I guess after I finish this they can fire me:)))

:-)  I would say that if the errors are not systematic, then it would be
a HUGE job to fix each image in a large archive.

re:
> My method is empirical and uses VIS channel. Most of the the empirical
> methods use IR channels because of the night, but using VIS channel allows
> me to get really high accuracy (1km vs 5 km). I am aware of some japanese
> guys trying to fix MTSAT using similar methods with average results.

Do you assume that the registration fix based on a VIS channel is
applicable to the IR channels?  That certainly was not the case for
GOES-13 imagery that I mentioned above.

re:
> I won't go into details here because it is to some degree complicated and
> sophisticated but my assessment was that it really improved the navigation
> and wobbling of MTSAT images as well as MSGIODC:))

OK.

re:
> perhaps I'll write a paper someday about all this.

In your copious spare time?  ;-)

re:
> This is where Solargis actually beats up the market or our competitors if
> you will.  I do not believe anybody is as crazy as my boss and will try to
> fix by themselves these kind of issues.
> The truth is that we conducted some experiments and if we manage to improve
> the wobbling of images we can reduce the uncertainty of our model by up to
> 2%. That does not seem much but when we talk about millions of dollars
> investment from our clients into PV plants this really makes a difference.

This is very interesting.  I can see the value of "fixing" navigation problems
in real-time/near real-time imagery since you are forecasting for PV power
generation, but I don't readily see how going back and fixing registration
errors in historic imagery would be that useful ** unless ** you routinely
use historic data to run ground truths for your model.

re:
> There are many parameters in a GVAR navigation block, some of them simple
> some of them complex. When you say "tweaking some of the header
> information" what exactly do you have in mind? (any specific parameters?)

I was referring to something very simple: if the image is shifted by
a fixed, integral number of pixels in either/both the N-S or E-W directions,
then one can "correct" the image by adjusting the beginning line,element
in the AREA file header.  If the problem is not so simple, one would have
to tweak navigation block values, and this would not be very simple.

re:
> The screenshot comes from an image from NOAA CLASS.  I use only NOAA CLASS
> GVAR images for this project.

OK.  That should say that there have been no systematic navigation
adjustments to the images in the CLASS archive, or, at least, for
the images that you have looked at.

re:
> I attached just the worse part of the image that was cloudless. I did not
> want to send you a large image over the email.

OK.

re:
> In my opinion the shifts are nonlinear, generally speaking, the left half
> (east) of the image suffers from a larger shift than west and north suffers
> from a larger shift than south. This is clearly visible on FD images.

OK.  This is the type of registration problem that I would classify as
being non-trivial to fix, and it might also indicate that each image
would need to be adjusted individually.  That would be a HUGE job for
a long term archive!

re: How have you been finding the GOES-16 imagery (meaning is it working
nicely for you)?

re:
> I am constantly improving  pyarea, pygvar and pyadde packages.  It is
> really working nicely. The ADDE is a real leverage for us, because in days
> when CLASS is in maintenance mode we still get data from you. In fact i
> realized today CLASS is missing some data for specific days. Maybe they fix
> it at a later time, but for example DOY 048 is one of such days where some
> images are missing.

I have not thought about your Python packages for quite some time.  Can
you remind me which package(s) we can safely use in software we develop
here and make generally available?  Also, can you send us the latest
version of each of the packages?  Thanks in advance!

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: VMY-981880
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.