Hello Ethan,
sorry for not replying earlier ... I agree with the approach suggested,
regards,
Martin
________________________________
From: Ethan Davis <edavis at ucar.edu>
Sent: 18 April 2018 20:07
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: Jim Biard; cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"
Hi Martin, all,
OK. I agree we need to fix this.
As this has been a part of the CF spec for awhile, I think we need to deprecate the current usage rather than just replace it. Similar to the alias mechanism for standard names, the current usage would be clearly indicated as incorrect but would remain part of the CF specification. I think a deprecation note in the geostationary projection section is all that would be needed.
I will put together a proposal for two new standard names and make an initial stab at updating the text for the geostationary projection section. That will give us a concrete proposal around which we can discuss this deprecation approach.
Cheers,
Ethan
On Tue, Apr 17, 2018 at 2:55 PM, Martin Juckes - UKRI STFC <martin.juckes at stfc.ac.uk<mailto:martin.juckes at stfc.ac.uk>> wrote:
Dear All,
I don't know if this helps, but our plan for the CMIP6 data request is to deal with any conflict between the metadata requested and the convention by providing users with a list of exceptions. We do our best to make all the requested parameters fit the convention, but with thousands of parameters, each carrying a complex bundle of CF attributes, it is likely that there will be, as here, some problems.
The angle subtended from the satellite and geometric distance on the ground are quite fundamentally distinct parameters, so it would require a substantial departure from the current procedures of the convention to permit both to be represented by the same standard name. As Jonathan has already said, there is a lot of software out there which assumes that each standard name has well defined canonical units.
Can you deal with this by declaring (in documentation and catalog entries) that the data has one exception to the CF convention and then working to get a suitable correction implemented as soon as possible. It should be possible to agree a pair of standard names quickly, as the use case is very clear.
Regards,
Martin
________________________________
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu<mailto:cf-metadata-bounces at cgd.ucar.edu>> on behalf of Jim Biard <jbiard at cicsnc.org<mailto:jbiard at cicsnc.org>>
Sent: 17 April 2018 14:04
To: cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"
So, should we consider loosening the standard name definitions for projection_x/y_coordinate? That is one solution.
On 4/17/18 5:55 AM, Daniel Lee wrote:
Dear group,
but I'd like to add that EUMETSAT also will be depending on using radians as units for our products using geostationary projections. We have the same issue that Randy notes - the scan characteristics of the instrument mean that it steps its view along an axis which changes its angle to the viewed point, and thus there's a non-linear relationship between length between view centroids on the ground and the grid. m vs rad is dependent on the angular distance from the satellite's nadir view. For us, switching to another standard name would also be very difficult, and switching to another unit would be impossible whilst preserving the integrity of the data.
Best regards,
Daniel
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu<mailto:cf-metadata-bounces at cgd.ucar.edu>] On Behalf
> Of Randy Horne
> Sent: 11 April 2018 19:02
> To: j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk><mailto:j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk>>
> Cc: cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu><mailto:cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>>
> Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
> "Geospatial projection"
>
> Dear All:
>
> Unfortunately, for this projection, the relationship between m and rad is
> non-linear, (not tho mention that angular measure / radians is a fundamental
> characteristic of the projection).
>
> v/r
>
> randy
>
>
> > On Apr 11, 2018, at 12:10 PM, Jonathan Gregory
> <jonathan.gregory at ncas.ac.uk<mailto:jonathan.gregory at ncas.ac.uk><mailto:jonathan.gregory at ncas.ac.uk<mailto:jonathan.gregory at ncas.ac.uk>>> wrote:
> >
> > Dear Ethan
> >
> > It wouldn't be nice to allow this name to have two different canonical
> > units (I mean not interconvertible). No doubt there is other software
> > that wouldn't like that situation, and it's a principle of standard
> > names that they specify the canonical unit, so that we need distinct
> > names for two quantities which have different canonical units. If the
> > coordinates are truly in radians, I think the right solution is to define a new
> standard name and change App F.
> >
> > However, I realise that you need some workrounds to use during the
> > (possibly
> > infinite) time before this change is thoroughly implemented, and for
> > archived data. Would it be practical to patch the software that
> > processes this data so that it doesn't object to the erroneous units?
> > If a conversion can be done between m and rad by making some standard
> > assumption about distances, then you could relabel the existing
> > numbers, which are actually in microradians, with units="m" and a
> > scale_factor, or which units="X m", where X is the scale factor, so that the
> numbers themselves don't have to be changed.
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from Ethan Davis <edavis at ucar.edu<mailto:edavis at ucar.edu><mailto:edavis at ucar.edu<mailto:edavis at ucar.edu>>> -----
> >
> >> Date: Tue, 10 Apr 2018 11:59:55 -0600
> >> From: Ethan Davis <edavis at ucar.edu<mailto:edavis at ucar.edu><mailto:edavis at ucar.edu<mailto:edavis at ucar.edu>>>
> >> To: Jonathan Gregory <j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk><mailto:j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk>>>
> >> Cc: CF metadata <cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu><mailto:cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>>>
> >> Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
> >> "Geospatial projection"
> >>
> >> Hi Jonathan,
> >>
> >> Yes, the change of units is unfortunate. However, there are now
> >> operational platforms generating data using this projection as it
> >> stands. It will be years (if ever) before a change like this would
> >> propagate through those operational systems.
> >>
> >> This means software would have to support two variants and I am very
> >> hesitant to move in that direction.
> >>
> >> There is much discussion in Trac #72 comments 12
> >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:12>, 13
> >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:13>, 14
> >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:14> on the whys and
> >> wherefores around the transformation between radians and meters for
> >> these coordinates. I wonder if there is an alternate path forward
> >> that would allow us to keep projection_{x|y}_coordinate for this
> >> projection. Maybe add (a very brief) discussion of how radians maps
> >> in this case to linear distance. Not perfect but perhaps better than the
> alternative.
> >>
> >> Cheers,
> >>
> >> Ethan
> >>
> >>
> >> On Tue, Apr 10, 2018 at 11:30 AM, Jonathan Gregory <
> >> j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk><mailto:j.m.gregory at reading.ac.uk<mailto:j.m.gregory at reading.ac.uk>>> wrote:
> >>
> >>> Dear all
> >>>
> >>> Metres and radians are not interconvertible, so
> >>> projection_[xy]_coordinate should not be used as a standard name for
> >>> a quantity in radians. I think that a defect ticket is needed to
> >>> change App F for this projection. Possibly we might need new
> >>> standard names if there aren't appropriate ones.
> >>>
> >>> Best wishes
> >>>
> >>> Jonathan
> >>>
> >>>
> >>> ----- Forwarded message from Jim Biard <jbiard at cicsnc.org<mailto:jbiard at cicsnc.org><mailto:jbiard at cicsnc.org<mailto:jbiard at cicsnc.org>>> -----
> >>>
> >>>> Date: Tue, 10 Apr 2018 12:32:00 -0400
> >>>> From: Jim Biard <jbiard at cicsnc.org<mailto:jbiard at cicsnc.org><mailto:jbiard at cicsnc.org<mailto:jbiard at cicsnc.org>>>
> >>>> To: CF metadata <cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu><mailto:cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>>>
> >>>> Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
> >>>> "Geospatial projection"
> >>>>
> >>>> Hi.
> >>>>
> >>>> It sounds like perhaps we should avoid the word "canonical".
> >>>> Perhaps we should change the relevant bit of the definition to read
> >>>>
> >>>> The x (abscissa) and y (ordinate) rectangular coordinates are
> >>>> identified
> >>> by
> >>>> the standard_name attribute values projection_x_coordinate and
> >>>> projection_y_coordinate respectively. In the case of this
> >>>> projection, the projection coordinates in this projection are
> >>>> directly related to the scanning angle of the satellite instrument
> >>>> - typically an angular
> >>> quantity.
> >>>>
> >>>>
> >>>> Software shouldn't assume the units. Microradians, degrees, grads,
> >>>> etc should all be fine. Does anyone think there is a problem with
> >>>> storing an angle in a variable with the standard name
> >>>> projection_x_coordinate? Do we need different standard names for
> these?
> >>>>
> >>>> This may indicate that projections that have specific requirements
> >>>> about units in the coordinates need to declare that information in
> >>>> the grid_mapping variable attributes. We tend to gloss over that,
> >>>> but there
> >>> are
> >>>> projections that expect the coordinates to be latitude and
> >>>> longitude instead of x and y. In addition, spherical or cylindrical
> >>>> coordinate systems would expect at least one coordinate to be angular.
> Thoughts?
> >>>>
> >>>> Grace and peace,
> >>>>
> >>>> Jim
> >>>>
> >>>> [image: CICS-NC] <http://www.cicsnc.org/>Visit us on Facebook
> >>>> <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar*
> >>>> Cooperative Institute for Climate and Satellites NC
> >>>> <http://cicsnc.org/
> >>>>
> >>>> North Carolina State University <http://ncsu.edu/> NOAA National
> >>>> Centers for Environmental Information <
> >>> http://ncdc.noaa.gov/>
> >>>> *formerly NOAA?s National Climatic Data Center*
> >>>> 151 Patton Ave, Asheville, NC 28801
> >>>> e: jbiard at cicsnc.org<mailto:jbiard at cicsnc.org><mailto:jbiard at cicsnc.org<mailto:jbiard at cicsnc.org>>
> >>>> o: +1 828 271 4900
> >>>>
> >>>> *Connect with us on Facebook for climate
> >>>> <http://www.facebook.com/NOAANCEIclimate> and ocean and
> geophysics
> >>>> <http://www.facebook.com/NOAANCEIoceangeo> information, and
> follow
> >>>> us on Twitter at _at_NOAANCEIclimate
> >>>> <http://www.twitter.com/NOAANCEIclimate>and _at_NOAANCEIocngeo
> >>>> <http://www.twitter.com/NOAANCEIocngeo>.*
> >>>>
> >>>>
> >>>> On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne
> >>>> <rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com><mailto:rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com>>>
> >>>> wrote:
> >>>>
> >>>>> Ethan:
> >>>>>
> >>>>> What you suggest is fine.
> >>>>>
> >>>>> As an aside ?.
> >>>>> If you look at the CF standard name table, the canonical units for
> >>>>> standard name ? projection_x_coordinate? and
> ?projection_y_coordinate?
> >>> are
> >>>>> meters (not radians).
> >>>>>
> >>>>> The GOES-R designers (specifically me) inadvertently used these
> >>>>> two standard names, not realizing they should NOT have used them
> >>>>> because a standard name can not have two different canonical units.
> >>>>>
> >>>>> Now, because the GOES-R system is already operational and in use,
> >>>>> it
> >>> would
> >>>>> be major rework for GOES-R to use a yet to be defined standard
> >>>>> name
> >>> (such
> >>>>> as projection_x_angilar_coordinate and projection_y_angular_
> >>> coordinate).
> >>>>>
> >>>>>
> >>>>> Not sure what to d about this ?.
> >>>>>
> >>>>>
> >>>>>
> >>>>> v/r
> >>>>>
> >>>>> randy
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Apr 9, 2018, at 3:54 PM, Ethan Davis <edavis at ucar.edu<mailto:edavis at ucar.edu><mailto:edavis at ucar.edu<mailto:edavis at ucar.edu>>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> The "Geostationary projection" section of Appendix F "Grid
> Mappings"
> >>> says
> >>>>>
> >>>>> The x (abscissa) and y (ordinate) rectangular coordinates are
> >>> identified
> >>>>> by the standard_name attribute values projection_x_coordinate and
> >>>>> projection_y_coordinate respectively. In the case of this
> >>>>> projection,
> >>> the
> >>>>> projection coordinates in this projection are directly related to
> >>>>> the scanning angle of the satellite instrument, and their units
> >>>>> are
> >>> radians.
> >>>>>
> >>>>>
> >>>>> To more explicitly fit CF expectations for units of variables with
> >>>>> a standard_name attribute, I believe the last bit should read:
> >>>>>
> >>>>> ... and their *canonical* units are radians.
> >>>>>
> >>>>>
> >>>>> This came up because the GOES-16 Full Disk data (example below
> >>>>> [1]) is stored with the projection_{x|y}_coordinate values in
> >>>>> microradians
> >>> and, it
> >>>>> turns out, the netCDF-Java code didn't like that as it expected
> >>> radians.
> >>>>> (Oops!)
> >>>>>
> >>>>> Unless anyone disagrees, I will open a CF Trac ticket for this
> >>>>> change later this week.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Ethan
> >>>>>
> >>>>> [1]
> >>>>> http://thredds-test.unidata.ucar.edu/thredds/dodsC/
> >>>>> satellite/goes16/GOES16/FullDisk/Channel08/20180406/
> >>>>> GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W.nc4.html
> >>>>>
> >>>>> netcdf GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W {
> >>>>> dimensions:
> >>>>> x = 1808 ;
> >>>>> y = 1808 ;
> >>>>> variables:
> >>>>> int time ;
> >>>>> time:units = "seconds since 2017-01-01" ; time:standard_name =
> >>>>> "time" ; time:long_name = "The start date / time that the
> >>>>> satellite began
> >>> capturing
> >>>>> the scene" ;
> >>>>> time:axis = "T" ;
> >>>>> time:calendar = "standard" ;
> >>>>> short y(y) ;
> >>>>> y:standard_name = "projection_y_coordinate" ; y:units =
> >>>>> "microradian" ; y:scale_factor = -167.999999999971 ; y:add_offset
> >>>>> = 151788. ; short x(x) ; x:standard_name =
> >>>>> "projection_x_coordinate" ; x:units = "microradian" ;
> >>>>> x:scale_factor = 167.999999999971 ; x:add_offset = -151788. ; int
> >>>>> fixedgrid_projection ; fixedgrid_projection:grid_mapping_name =
> >>>>> "geostationary" ;
> >>>>> fixedgrid_projection:latitude_of_projection_origin = 0. ;
> >>>>> fixedgrid_projection:longitude_of_projection_origin = -75. ;
> >>>>> fixedgrid_projection:semi_major = 6378137. ;
> >>>>> fixedgrid_projection:semi_major_axis = 6378137. ;
> >>>>> fixedgrid_projection:semi_minor = 6356752.31414 ;
> >>>>> fixedgrid_projection:semi_minor_axis = 6356752.31414 ;
> >>>>> fixedgrid_projection:perspective_point_height = 35785831. ;
> >>>>> fixedgrid_projection:sweep_angle_axis = "x" ; short
> >>>>> Sectorized_CMI(y, x) ; Sectorized_CMI:_FillValue = 0s ;
> >>>>> Sectorized_CMI:standard_name = "brightness_temperature" ;
> >>>>> Sectorized_CMI:units = "kelvin" ; Sectorized_CMI:grid_mapping =
> >>>>> "fixedgrid_projection" ; Sectorized_CMI:add_offset = 138.05f ;
> >>>>> Sectorized_CMI:scale_factor = 0.04224986f ;
> >>>>> Sectorized_CMI:valid_min = 0s ; Sectorized_CMI:valid_max = 4095s ;
> >>>>> Sectorized_CMI:coordinates = "time y x" ;
> >>>>>
> >>>>> // global attributes:
> >>>>> :title = "Sectorized Cloud and Moisture Imagery for the EFD
> >>>>> region." ; :ICD_version = "GROUND SEGMENT (GS) TO ADVANCED
> WEATHER
> >>>>> INTERACTIVE PROCESSING SYSTEM (AWIPS) INTERFACE CONTROL
> DOCUMENT (ICD) Revision B"
> >>> ;
> >>>>> :Conventions = "CF-1.6" ;
> >>>>> :channel_id = 8 ;
> >>>>> :central_wavelength = 6.19f ;
> >>>>> :abi_mode = 3 ;
> >>>>> :source_scene = "FullDisk" ;
> >>>>> :periodicity = 15.f ;
> >>>>> :production_location = "RBU" ;
> >>>>> :product_name = "EFD-060-B12-M3C08" ; :satellite_id = "GOES-16" ;
> >>>>> :product_center_latitude = 0. ; :product_center_longitude = -75. ;
> >>>>> :projection = "Fixed Grid" ; :bit_depth = 12 ;
> >>>>> :source_spatial_resolution = 2.f ; :request_spatial_resolution =
> >>>>> 6.f ; :start_date_time = "2018096201540" ; :number_product_tiles =
> >>>>> 4 ; :product_tile_width = 1024 ; :product_tile_height = 1024 ;
> >>>>> :product_rows = 1808 ; :product_columns = 1808 ; :pixel_x_size =
> >>>>> 6. ; :pixel_y_size = 6. ; :satellite_latitude = 0. ;
> >>>>> :satellite_longitude = -75. ; :satellite_altitude = 35785831. ;
> >>>>> :created_by = "ldm-alchemy" ; :product_tiles_received = 4 ; }
> >>>>>
> >>>>> _______________________________________________
> >>>>> CF-metadata mailing list
> >>>>> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>>
> >>>>>
> >>>>> _____________________________________
> >>>>>
> >>>>> Randy C Horne (rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com><mailto:rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com>>) Principal Engineer,
> >>>>> Excalibur Laboratories Inc.
> >>>>> voice & fax: (321) 952.5100
> >>>>> cell: (321) 693.1074
> >>>>> url: http://www.excaliburlabs.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> CF-metadata mailing list
> >>>>> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>>
> >>>>>
> >>>
> >>>> _______________________________________________
> >>>> CF-metadata mailing list
> >>>> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _____________________________________
>
> Randy C Horne (rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com><mailto:rhorne at excaliburlabs.com<mailto:rhorne at excaliburlabs.com>>) Principal Engineer, Excalibur
> Laboratories Inc.
> voice & fax: (321) 952.5100
> cell: (321) 693.1074
> url: http://www.excaliburlabs.com
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system.
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu><mailto:CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
[CICS-NC] <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly NOAA?s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org<mailto:jbiard at cicsnc.org><mailto:jbiard at cicsnc.org<mailto:jbiard at cicsnc.org>>
o: +1 828 271 4900
Connect with us on Facebook for climate<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at _at_NOAANCEIclimate<https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo<https://twitter.com/NOAANCEIocngeo>.
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Apr 25 2018 - 05:30:33 BST
