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

20010410: time issues in meteosat imagery (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20010410: time issues in meteosat imagery (cont.)
  • Date: Tue, 10 Apr 2001 09:32:00 -0600
>From: address@hidden (Chris Hennon)
>Organization: Ohio State University
>Keywords: 200104061848.f36ImGL26255 McIDAS METEOSAT time

Chris,

>I made all of my meteosat images universally writable and it still would
>not change the time.  However, when I followed your procedure (copied the
>file to a new area, then changed the time), it changed the time.  But when
>I tried to copy it back to the original image, it wouldn't work:
>
>IMGCOPY MYDATA/IMAGES.2001 METSAT-7.158 SIZE=ALL
>Beginning Image Data transfer, bytes= 6250928
>Transferring AREA data outbound, bytes= 6251008
>IMGCOPY: MCAOUT rc= -1
>IMGCOPY: done
>IMGLIST METSAT-7.158
>Image file directory listing for:METSAT-7
> Pos Satellite/         Date       Time      Center   Band(s)
>     sensor                                 Lat  Lon
> --- -------------  ------------  --------  ---- ---- ------------
> 158  METEOSAT7      9 NOV 98313  24:00:00     0    0 8
>IMGLIST: done

This is still telling us that we have a write problem.  The fact that
you can do the IMGCHA to a copy of the images in question further says
that the problem is one of writing.  When you make the copy it will end
up in the first writable directory in your MCPATH set of directories.
This is typically ~<user>/mcidas/data for users other than 'mcidas' and
~mcidas/workdata for the user 'mcidas'.

Since the permissions on the files are OK, it must be that the files
are in a directory that you are not allowed to write in.  Test this by
creating a file using 'touch':

touch /whatever_directory/xxx

If 'touch' can't create the file xxx in the directory 'whatever_directory'
(this is the directory you put the original AREA files in), then we
have found your problem.

>Maybe I have to delete the old before I can copy in a new one?

No, existing images will be overwritten by IMGCOPY if you have the appropriate
write permission.

>In any
>case, I'm still stuck in a little rut here.  Thanks again for any hot
>tips.

Check the permissions on the directory.

Tom