Closed MathieuDutSik closed 8 years ago
I have experienced the same problem. It looks like nansat no longer use the get_time attribute, but have replaced it with time_coverage_start and time_coverage_end
Hi - this is correct. Sorry for the late answer - I'm currently on holiday. The master version of openwind should work with the master version of nansat, or a given tag of nansat. You could try that, or update your fork of openwind develop and submit a pull request. Make sure to add tests. I plan to get openwind updated in august, if you can wait.
Regarding your points:
1) These are in the SPH file, right? It is accurate enough to just use the start time
2) In nansat, the start time is added as timing of every band. This is useful if data from several source is included in the same nansat object. I'm not sure if there is a specific reason to use this in openwind but we probably could have (explicitly) used the time_coverage_start
of the main nansat object.
3) This error message is a result of changes in nansat but you should be able to use the stable master versions of both
Hi Morten,
thanks for help. I used the 0.6.1 branch for both and I pass this bug. Maybe if nansat and openwind are so tight then they should be merged in a single package?
Now my problem is following: 09:13:48|40|nansat|_get_mapper|GDAL could not open metno_local_hires_seaice_20120202, trying to read with Nansat mappers... 09:13:48|40|nansat|_get_mapper|GDAL could not open metno_hires_seaice:20120202, trying to read with Nansat mappers... But I will look and investigate this problem.
Thanks,
Mathieu
On 18 July 2016 at 16:48, Morten W. Hansen notifications@github.com wrote:
Hi - this is correct. Sorry for the late answer - I'm currently on holiday. The master version of openwind should work with the master version of nansat, or a given tag of nansat. You could try that, or update your fork of openwind develop and submit a pull request. Make sure to add tests. I plan to get openwind updated in august, if you can wait.
Regarding your points:
1) These are in the SPH file, right? It is accurate enough to just use the start time
2) In nansat, the start time is added as timing of every band. This is useful if data from several source is included in the same nansat object. I'm not sure if there is a specific reason to use this in openwind but we probably could have (explicitly) used the time_coverage_start of the main nansat object.
3) This error message is a result of changes in nansat but you should be able to use the stable master versions of both
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nansencenter/openwind/issues/19#issuecomment-233351089, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTOKuS_WwJ7WWyn2bfhaVKcSyAEISd4ks5qW5JNgaJpZM4JDDFt .
Hi Mathieu,
This error should not be a problem unless you need to filter out ice cover in the image. I have created a new issue #21 to handle this.
Best regards, Morten
The get_time error is still present when running the master versions of nansat and openwind. Reopened issue.
Solved in 53e9025afdd20949adadc1847899f0c5941190db
I am trying to use sar_wind.py to extract the wind from SAR images and run into a problem.
The command I tried is mathieu@mathieu-N56VJ:~/Works/Oceanography/SAR$ python ./sar_wind.py -s ASA_WSM_1PNIPA20120202_205929_000000923111_00187_51925_1786.N1 -w 0 -f file.png
And the error is Traceback (most recent call last): File "./sar_wind.py", line 543, in
sw = SARWind(args.SAR_filename, wind_direction, pixelsize=args.pixelsize)
File "./sar_wind.py", line 81, in init
self.SAR_image_time = self.get_time(
AttributeError: 'SARWind' object has no attribute 'get_time'
Remarks on this: 1) The ASA files does contain time information with a SENSING_START and SENSING_STOP strings.
2) The full entry in question is self.SAR_image_time = self.get_time( self.sigma0_bandNo).replace(tzinfo=None) and it is somewhat strange to me to have the time obtained from self.sigma0_bandNo
3) It is quite possible that my input is wrong and I do plan to use a real wind file in the future. However, even then it is best to have caught explicitly with a clear error message precising what is wrong with my input.
Thanks in advance for any help,
Mathieu