Use correct interpretation of xllcorner and yllcorner

[ole]

The current interpretation of xllcorner and yllcorner is wrong. As suggested by Joaquim Luis - see thread ​http://sourceforge.net/mailarchive/forum.php?thread_name=4727D555.7010208%40ualg.pt&forum_name=anuga-user

• we should redefine xllcorner as

x0 = xllcorner + 0.5*cellsize or x0 = xllcenter

and similarly for yllcorner.

[ole]

I think we need to do the following:

When we read ASCII files, we need to accept the possibility of both xllcorner and xllcenter as input parameter as in

xref = lines[2].split()
if xref[0].strip() == 'xllcorner':
    x_origin = float(xref[1].strip()) + 0.5*cellsize # Correct offset
elif xref[0].strip() == 'xllcenter':
    x_origin = float(xref[1].strip())
else:
    msg = 'Unknown keyword: %s' %xref[0].strip()
    raise Exception, msg

I started this in changeset:4824 except I didn't introduce the new varibable x_origin (and y_origin) which I think would be good to use throughout ANUGA as a name for our current internal use of xll and yllcorner (to avoid confusion).

What needs to be done is something like this:

• Modify any reading of ASCII files to the proper semantics
• Use x_origin, y_origin internally in ANUGA instead of xllcorner, yllcorner
• Modify any writing of ASCII files to the proper semantics (For example, use xllcenter, yllcenter as they are the same as x_origin, y_origin).
• Modify the sww format to use x_origin, y_origin - and perhaps also the viewers.

Most of this is derived from the correspondence with Joaquim Luis on Sourceforge

Let me know what you think of this approach.

Cheers Ole

PS I have delegated this ticket to Jane, but CC'd to Duncan whose insights will be very valuable as always.

T

[ole]

Perhaps we can use the files demtest.prj and demtest.asc currently located in the user_manual area (but not used) as test cases for the correct interpretation. We would have to move them (with svn mv) to an appropriate test area. Their current location is ​https://datamining.anu.edu.au/anuga/browser/anuga_core/documentation/user_manual/demtest.asc ​https://datamining.anu.edu.au/anuga/browser/anuga_core/documentation/user_manual/demtest.prj

[ole]

Here's an email from Chris Chamberlin [Chris.Chamberlin@…] dated 1 March 2008 that discusses the same problem:

Richard,

The xllcorner,yllcorner fields define the location of the lower-level 
corner of the southwesternmost grid cell (pixel).  The corresponding 
node (grid cell centroid) registration would be:
  xllcenter	95.00041666666667
  yllcenter	5.000416666666667

So the dataset defines values for a surface from (95,5) to (100,10); in 
node terms, the outermost nodes are 1.5 arcsec inside that range.

Sorry for the confusion on this; I should have clarified it in the readme.

chris


Richard.Mleczko@ga.gov.au wrote:
> Hi guys just trying to clear up some confusion regarding the
> phuket_3s_160506.asc file we got from you for use in the boxing day
> validation.
> 
> The problem is there is a conflict as to whether the grid is normal 
> node Or pixel node registration.
> 
> The header in the file states:
> ncols         6000
> nrows         6000
> xllcorner     95
> yllcorner     5
> cellsize      0.00083333333333333
> NODATA_value  -9999
> 
> This implies that the grid starts at 95 longitude and ends at
> (6000*0.00083333333333333) 99.99916 longitude (which is 100 deg - 3 
> sec). It is 3 sec short of getting to 100 deg because the 1st line of 
> the 6000 lines of data is at 95 deg long. To get to the 100 deg long 
> there would have to be 6001 lines of data.
> 
> Same with the rows of latitude data, 3 secs short of 10 deg.
> 
> 
> Now the readme file in the zip file states:
> 
> Resolution: 3 arc-seconds
> Extent: (95E, 5N) - (100E, 10N)
> Horizontal units: decimal degrees, WGS84 datum
> Vertical units: meters above/below MLLW
> 
> File format: ESRI ASCII Raster
> 
> This can not be the extent of the file if the grid is 6000 X 6000. For 
> this to be the extent the grid needs to be 6001 X 6001.
> 
> If the grid is 6000 X 6000 then the header should read:
> 
> xllcenter     95
> yllcenter     5
> 
> which is pixel registration.
> 
> My guess is that it is pixel registration and the extents are: 95 plus 
> 1.5 secs to 100 minus 1.5 secs, 5 plus 1.5 secs to 10 minus 1.5 secs.
> 
> Any ideas would be greatly appreciated.
> 
> Please see original email stream below.
> 
> Regards,
> 
> 
> 
> Richard Mleczko
> -------------------------------------------
> 
> Natural Hazard Impacts Project
> Risk And Impact Analysis Group
> Geoscience Australia
> www.ga.gov.au
> PO Box 378, Canberra, ACT, 2601, AUSTRALIA
> Room: G.218 B, Phone: (02) 6249 9817
> E-mail: richard.mleczko@ga.gov.au
> -------------------------------------------- 
>  
> 
> -----Original Message-----
> From: Bartzis Nick
> Sent: Friday, 23 February 2007 12:10 PM
> To: 'Chris Chamberlin'; Vasily Titov
> Cc: Diego Arcas; Christopher Moore
> Subject: RE: TRIM: Re: Fwd: Data to validate ANUGA
> 
> Hi Vasily and Chris
> 
> Thanks for the data, it looks great! We are now working towards 
> building ANUGA models for these regions with MOST to provide the 
> boundary conditions (thanks to Diana at BOM)
> 
> We are hoping to validate the results from the anuga model with some 
> post-tsunami run-up survey data for Phuket and Banda Aceh, which I 
> believe you refered to having.
> 
> Do you have that run-up data and can you provide it to GA?
> 
> 
> 
> Thanks again for the elevation data and if there is any data you 
> require that we could help with please ask.
> 
> Best regards
> Nick
>  
> --------------------------------------------------
> Nick Bartzis
> Computational Modeller
> Risk Assessment Methods Project
> Geoscience Australia
> Ph. 02 6249 9254, Fax 02 6249 9969
> www.ga.gov.au
> 
> 
> 
> -----Original Message-----
> From: Chris Chamberlin [mailto:Chris.Chamberlin@noaa.gov]
> Sent: Tuesday, 13 February 2007 10:20 AM
> To: Bartzis Nick
> Cc: Vasily Titov; Diego Arcas; Christopher Moore
> Subject: TRIM: Re: Fwd: Data to validate ANUGA
> 
> 
> Nick,
> 
> Vasily asked me to pass along some of our bathymetry datasets to you.
> I've put bathy-topo grids for Banda Aceh, Phuket, and Hilo on our 
> website, here:
>   ftp://ftp.pmel.noaa.gov/tsunami/individuals/bartzis
> 
> e095n05_may02_bandaaceh.zip and phuket_3s_160506.zip are 3-arc-second
> (~90m) grids for modeling Banda Aceh and Phuket, respectively.  The two 
> grids actually have the same extent and resolution, but were developed 
> separately, so the area of interest got extra gridding atttention in each.
> 
> hilo_1_3s_20051220.zip is a 1/3s (~10m) grid covering Hilo, Hawaii.
> hawaii_6s_20060705.zip is a medium-resolution 6s grid covering all of 
> the main Hawaiian islands.
> 
> All of these are in the generic ESRI ASCII raster format. Horizontal
> units are decimal degrees, vertical units are meters with depths negative.
> 
> Chris
> 
> 
> 
>> Begin forwarded message:
>>
>>> *From: *Nick.Bartzis@ga.gov.au <mailto:Nick.Bartzis@ga.gov.au>
>>> *Date: *January 30, 2007 6:59:06 PM PST
>>> *To: *Vasily.Titov@noaa.gov <mailto:Vasily.Titov@noaa.gov>
>>> *Subject: **Data to validate ANUGA*
>>>
>>> Hi Vasily
>>>  
>>> Thanks for the great course and we also really appreciated your 
>>> visit and presentation at GA, it was very successful. I hope you had 
>>> a good flight back and have settled in a bit for the new year.
>>>  
>>> As with anything we want to hit the iron while it is hot, so we'd
>>> like
>>> to action some of what we discussed about bathymetry and validation 
>>> data. I suppose firstly we are interested in any raw bathymetry data 
>>> which you can release around Thailand and Banda Aceh. Followed by any 
>>> information from Hilo, the "Run-up of a solitary wave on conical 
>>> island" tank experiment and the 1D analytical model for a "solitary 
>>> wave run-up on a plain beach".
>>>  
>>> We have the resources to conduct a model validation and comparison 
>>> in February and March and getting hold of the data you mentioned 
>>> (elevation and run-up) would be very beneficial. The general idea is 
>>> to run ANUGA with a MOST boundary condition of the boxing day 
>>> tsunami and validate ANUGA with any data we can get. Then we can run 
>>> the same model with ComMIT and compare the results.
>>>  
>>> Best Regards
>>>  
>>> Nick
>>>  
>>>  
>>> --------------------------------------------------
>>> Nick Bartzis
>>> Computational Modeller
>>> Risk Assessment Methods Project
>>> Geoscience Australia
>>> Ph. 02 6249 9254, Fax 02 6249 9969
>>> www.ga.gov.au
>>>  
> 

-- 
Chris Chamberlin  <chris.chamberlin@noaa.gov>
NOAA Center for Tsunami Research, NOAA PMEL/UW JISAO
7600 Sand Point Way NE Bldg 3. Seattle, WA 98115-0070
phone: 206-526-6809  fax: 206-526-6485

[anonymous]

​http://www.salewroughtiron.cn installing metal stair rails Interior stair handrail installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails ​http://www.china-made-door.com.cn door gate ​http://www.beijing-door.cn wrought CONTEMPORARY designs stairways installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails ​http://www.hebei-railings.cn aluminum modern log banister DECK outdoor price installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails posts vinyl curved rails

[anonymous]

Thank you. ​ed hardy ​Christian Audigier ​ed hardy swimwear ​ed hardy clothing