[Gdal-dev] question about AsciiGrid

Frank Warmerdam fwarmerdam at gmail.com
Fri Apr 15 11:39:30 EDT 2005


On 4/15/05, Stephane Routelous <route at cae.com> wrote:
> the problem that I'm facing is for asciigrid. 
> In an elevation data (asciigrid or dted), the pixels are representing a
> posting point, and not a surface. 
> This means that outside the box defined by the lowerleft and the upperleft
> postings, the data is not defined. 
> For a DTED, all is fine, because a dted posting is defined a the lowerleft
> corner of the pixel. 

Stephane, 

I'm not sure why you say that for DTED the posting is defined at the
lower left corner of the pixel.  In the DTED file the bounds are such 
that the upper left posting is the upper left corner of the file in 
question.  I offset this in the GDAL driver for DTED by half a pixel
to account for the fact that my pixel is an area, and so the posting
value will be represented as covering an area around the posting
location - that is the posting is at the center of the pixel. 

> But for the asciigrid, the definition of the pixel posting is 

I think you forgot to finish this sentance. 

> So, if the asciigrid is defined with xllcenter and yllcenter, asking for a
> pixel between [0,0.5[ or ]nXSize-0.5,nXSize] returns an undefined value
> (same for y). 
> 
> in the case where the asciigrid is defined with xllcorner/yllcorner, the
> undefined values are from ]nXSize-1,nXSize] 
> 
> In my framework, I change the georeferenced bounding box to take in account
> this 1/2 pixel deplacement. 
> But for asciigrid, I need to know if the asciigrid is defined with
> xllcenter/yllcenter or xllcorner/yllcorner. 
> 
> Is there a way to get this information, once I have the GDALDataset ? 

There is no information returned from the driver for this sort of thing. 
Personally, I had never assumed that use of xllcenter meant something
different than xllcorner other than that if the pixel center was given I 
needed to offset by half a pixel to get the ll corner of pixel value I 
would use in building the geotransform. 

In general GDAL strictly uses a "pixel is area" view of raster data, 
and the geotransform origin is the top left corner of the top left
pixel.  Adjustments are made in drivers for formats that take
different interpretations to convert stuff to the GDAL view.  

If you would like, we could add a metadata item for GDALDatasets
that indicates whether the underlying format considered the pixel
values point postings or area values if that would help ... and then
add this to formats as needed (such as the ascii grid driver).  But
I'm not sure if that really fully addresses your need.  After all, DTED
is a point posting product too.  Perhaps you have just been hardcoding
rules about this based on the driver name so far, and asciigrid is the
first format you have run into that could do either? 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent



More information about the Gdal-dev mailing list