[GRASS-user] Re: grass-user Digest, Vol 29, Issue 5

GRASS GRASS user
1

grass-user-request@lists.osgeo.org wrote:

Send grass-user mailing list submissions to
  grass-user@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body 'help' to
  grass-user-request@lists.osgeo.org

You can reach the person managing the list at
  grass-user-owner@lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-user digest..."

Today's Topics:

   1. Re: BIN raster import (Richard Chirgwin)
   2. Re: BIN raster import (Hamish)

----------------------------------------------------------------------

Message: 1
Date: Wed, 03 Sep 2008 17:52:06 +1000
From: Richard Chirgwin <rchirgwin@ozemail.com.au>
Subject: Re: [GRASS-user] BIN raster import
To: hamish_b@yahoo.com, grass-user@lists.osgeo.org
Message-ID: <48BE4226.20200@ozemail.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed

Hamish wrote:
  

here's the command:
r.in.bin 'input=/home/richard/Desktop/ausdem.bin' \
  output=RD_Bin bytes=2 rows=13760.5 cols=17361
    

you can't have half a row of data.
rows must be an integer.

Hamish
  

Ahh - so there's an error in the UI, which says:
Number of rows: (rows, float, optional)
Number of columns: (columns, float, optional)

It may be that rows and columns are floating point on the "inside", but the UI should make it clear that integer values are required! I was trying to fiddle the row/column combinations up and down to get the file size right ...

Thanks for the effort, will run in the new version later on (some work to do first), and see what happens.

RC
  
------------------------------

Message: 2
Date: Wed, 3 Sep 2008 01:56:09 -0700 (PDT)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-user] BIN raster import
To: grass-user@lists.osgeo.org, Richard Chirgwin
  <rchirgwin@ozemail.com.au>
Message-ID: <815913.44025.qm@web110006.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Richard:
  

Ahh - so there's an error in the UI, which says:
Number of rows: (rows, float, optional)
Number of columns: (columns, float, optional)
    
so there is. now fixed in SVN.

It may be that rows and columns are floating point on the "inside",
    
they are really ints on the inside.

but the UI should make it clear that integer values are required!
I was trying to fiddle the row/column combinations up and down to
get the file size right ...
    
no metadata with it?
sometimes the cell-center as coord versus grid confluences as coords
convention can cause the data to be off by 1 row/col from stated size.

Hamish
  

I'll make this suggestion for consideration in a possible future revision.

It would be nice if r.in.bin offered a "create new location" option. That way, the import could work byte-by-byte without worrying about bounds, and the user could georectify the imported raster to their target location after import.

Richard

------------------------------

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

End of grass-user Digest, Vol 29, Issue 5
*****************************************

2

Richard wrote:

It would be nice if r.in.bin offered a "create new location" option.
That way, the import could work byte-by-byte without worrying about
bounds, and the user could georectify the imported raster
to their target location after import.

wouldn't work, except if you sent the thing to a simple XY location.
GRASS needs to know the map projection information before it can create
a new location.

Binary files are just a long string of numbers. Without knowing the number
of rows and columns it could be either wide and short or narrow and tall.
There's no way for the module to pick that up otherwise. (unless like the
old GMT format (r.in.bin -h) there is some header info in the file)

If you know the rows and cols but are a bit fuzzy on what the bounds
should be I would recommend importing it into the target location with
south and west coords at 0 and north and east coords at number of rows
and cols. Then you can run r.region (with a 'r.') at your leisure until
r.info shows that the map resolution and bounds are ok.
At least then you can see something on the screen and know that the
other choices (byte swap, bytes per cell) are correct.

note that GRASS considers the region bound coordinate to be at the
outer edge of the border cells.

Hamish

3

On Wednesday 03 September 2008, Hamish wrote:

note that GRASS considers the region bound coordinate to be at the
outer edge of the border cells.

Now that you mention this, is there an authoritative description of how GRASS
(and maybe GDAL) treat cells/pixels:

1. region calculations (outer edge of the border cells)
2. cell locations (??? center, edge ???)
3. raster to vector conversions (??? center, edge ???)
4. resampling (??? center, edge ???)

I have often second-guessed myself on these very topics...

Cheers,

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

4

Hamish wrote:

> It would be nice if r.in.bin offered a "create new location" option.
> That way, the import could work byte-by-byte without worrying about
> bounds,

Import (r.in.*) modules ignore the current region; no resampling is
performed.

With r.in.bin, you can specify the bounds via the
north=/south=/east=/west= options, but this is just used to set the
bounds of the imported map (analogous to running r.region after
importing); it doesn't otherwise affect the import process.

Binary files are just a long string of numbers. Without knowing the number
of rows and columns it could be either wide and short or narrow and tall.
There's no way for the module to pick that up otherwise. (unless like the
old GMT format (r.in.bin -h) there is some header info in the file)

Depending upon the data, you may be able to infer the number of
columns from a 1-dimensional FFT of (a portion of) the data.

Or you can factor the total number of cells, treating each factor as a
candidate for the number of columns, checking for similarity between
adjacent cells and discontinuities at the edges.

Such approaches tend to be more effective if the data isn't made up of
clusters of (real) data surrounded by a sea of no-data/zero/sea-level/etc.

--
Glynn Clements <glynn@gclements.plus.com>

5

Hamish wrote:

Richard wrote:
  

It would be nice if r.in.bin offered a "create new location" option. That way, the import could work byte-by-byte without worrying about bounds, and the user could georectify the imported raster
to their target location after import.
    
wouldn't work, except if you sent the thing to a simple XY location.
GRASS needs to know the map projection information before it can create
a new location.
  

A simple xy was what I had in mind - just as I would use to import an unreferenced image...

RC

Binary files are just a long string of numbers. Without knowing the number
of rows and columns it could be either wide and short or narrow and tall.
There's no way for the module to pick that up otherwise. (unless like the
old GMT format (r.in.bin -h) there is some header info in the file)

If you know the rows and cols but are a bit fuzzy on what the bounds
should be I would recommend importing it into the target location with
south and west coords at 0 and north and east coords at number of rows
and cols. Then you can run r.region (with a 'r.') at your leisure until
r.info shows that the map resolution and bounds are ok.
At least then you can see something on the screen and know that the
other choices (byte swap, bytes per cell) are correct.

note that GRASS considers the region bound coordinate to be at the
outer edge of the border cells.

Hamish

6

Dylan Beaudette wrote:

> note that GRASS considers the region bound coordinate to be at the
> outer edge of the border cells.

Now that you mention this, is there an authoritative description of how GRASS
(and maybe GDAL) treat cells/pixels:

Inevitably, the authoritative description is the source code. Any
other documentation describes how modules are supposed to behave,
while the source code describes how they actually behave.

1. region calculations (outer edge of the border cells)

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

2. cell locations (??? center, edge ???)

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

  { (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
      north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

  (west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

3. raster to vector conversions (??? center, edge ???)

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

4. resampling (??? center, edge ???)

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

r.resample uses the built-in resampling, so it should produce
identical results.

r.resamp.interp method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, r.resamp.rst behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For r.resamp.stats without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

I have often second-guessed myself on these very topics...

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.

2. Operations which need a point (e.g. interpolation) use the cell's
centre.

From a programming perspective, the functions:

  G_row_to_northing()
  G_col_to_easting()
  G_northing_to_row()
  G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

--
Glynn Clements <glynn@gclements.plus.com>

7

Thanks Glynn. I am going to look for a relevant page on the Wiki to
post much of this information, as it may be very helpful to others.

Cheers,

Dylan

On Thu, Sep 4, 2008 at 12:46 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Dylan Beaudette wrote:

> note that GRASS considers the region bound coordinate to be at the
> outer edge of the border cells.

Now that you mention this, is there an authoritative description of how GRASS
(and maybe GDAL) treat cells/pixels:

Inevitably, the authoritative description is the source code. Any
other documentation describes how modules are supposed to behave,
while the source code describes how they actually behave.

1. region calculations (outer edge of the border cells)

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

2. cell locations (??? center, edge ???)

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

       { (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
                 north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

       (west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

3. raster to vector conversions (??? center, edge ???)

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

4. resampling (??? center, edge ???)

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

r.resample uses the built-in resampling, so it should produce
identical results.

r.resamp.interp method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, r.resamp.rst behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For r.resamp.stats without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

I have often second-guessed myself on these very topics...

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.

2. Operations which need a point (e.g. interpolation) use the cell's
centre.

From a programming perspective, the functions:

       G_row_to_northing()
       G_col_to_easting()
       G_northing_to_row()
       G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

--
Glynn Clements <glynn@gclements.plus.com>

8

Thanks Glynn. I am going to look for a relevant page on the Wiki to
post much of this information, as it may be very helpful to others.

Cheers,

Dylan

On Thu, Sep 4, 2008 at 12:46 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Dylan Beaudette wrote:

> note that GRASS considers the region bound coordinate to be at the
> outer edge of the border cells.

Now that you mention this, is there an authoritative description of how GRASS
(and maybe GDAL) treat cells/pixels:

Inevitably, the authoritative description is the source code. Any
other documentation describes how modules are supposed to behave,
while the source code describes how they actually behave.

1. region calculations (outer edge of the border cells)

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

2. cell locations (??? center, edge ???)

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

       { (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
                 north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

       (west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

3. raster to vector conversions (??? center, edge ???)

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

4. resampling (??? center, edge ???)

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

r.resample uses the built-in resampling, so it should produce
identical results.

r.resamp.interp method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, r.resamp.rst behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For r.resamp.stats without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

I have often second-guessed myself on these very topics...

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.

2. Operations which need a point (e.g. interpolation) use the cell's
centre.

From a programming perspective, the functions:

       G_row_to_northing()
       G_col_to_easting()
       G_northing_to_row()
       G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

--
Glynn Clements <glynn@gclements.plus.com>

9

For further documentation / reference, I have started the following
page, based on Glynn's (verbatim) suggestions.

http://grass.osgeo.org/wiki/GRASS_pixel_rules

Thanks,

Dylan

On Thu, Sep 4, 2008 at 7:52 AM, Dylan Beaudette
<dylan.beaudette@gmail.com> wrote:

Thanks Glynn. I am going to look for a relevant page on the Wiki to
post much of this information, as it may be very helpful to others.

Cheers,

Dylan

On Thu, Sep 4, 2008 at 12:46 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Dylan Beaudette wrote:

> note that GRASS considers the region bound coordinate to be at the
> outer edge of the border cells.

Now that you mention this, is there an authoritative description of how GRASS
(and maybe GDAL) treat cells/pixels:

Inevitably, the authoritative description is the source code. Any
other documentation describes how modules are supposed to behave,
while the source code describes how they actually behave.

1. region calculations (outer edge of the border cells)

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

2. cell locations (??? center, edge ???)

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

       { (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
                 north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

       (west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

3. raster to vector conversions (??? center, edge ???)

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

4. resampling (??? center, edge ???)

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

r.resample uses the built-in resampling, so it should produce
identical results.

r.resamp.interp method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, r.resamp.rst behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For r.resamp.stats without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

I have often second-guessed myself on these very topics...

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.

2. Operations which need a point (e.g. interpolation) use the cell's
centre.

From a programming perspective, the functions:

       G_row_to_northing()
       G_col_to_easting()
       G_northing_to_row()
       G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

--
Glynn Clements <glynn@gclements.plus.com>

10

Dylan Beaudette wrote:

For further documentation / reference, I have started the following
page, based on Glynn's (verbatim) suggestions.

http://grass.osgeo.org/wiki/GRASS_pixel_rules

FWIW, I've renamed the page to "GRASS raster semantics". A pixel is a
"picture element", and rasters aren't necessarily pictures.

--
Glynn Clements <glynn@gclements.plus.com>

11

Returning to my original problem: is there a program for Linux that will read a BIN DEM, and let me save it in something like GeoTIFF, because I cannot beat the two-byte file size error detected by r.in.bin.

Richard

Glynn Clements wrote:

Dylan Beaudette wrote:

For further documentation / reference, I have started the following
page, based on Glynn's (verbatim) suggestions.

http://grass.osgeo.org/wiki/GRASS_pixel_rules
    
FWIW, I've renamed the page to "GRASS raster semantics". A pixel is a
"picture element", and rasters aren't necessarily pictures.

12

Richard Chirgwin wrote:

Returning to my original problem: is there a program for
Linux that will read a BIN DEM, and let me save it in something
like GeoTIFF, because I cannot beat the two-byte file size
error detected by r.in.bin.

You can try gdal_translate, but I think if the numbers don't
add up in r.in.bin then as a fundamental matter they won't add
up anywhere else either. Unless GDAL's autodetect magic finds
something special about the file format.

Can you provide all the known info you can about the file?
Exact filesize, expected dimensions, given bounds, endianness,
bytes per cell, data type (floating point, integer, ..),
expected data range, etc.? Maybe we can figure it out with a
hand calculator.

It could be that there is some header info written before the
stream of data which is padding the filesize by several bytes
thus throwing off the sanity check math.

Hamish

13

Hamish wrote:

Richard Chirgwin wrote:
  

Returning to my original problem: is there a program for
Linux that will read a BIN DEM, and let me save it in something
like GeoTIFF, because I cannot beat the two-byte file size
error detected by r.in.bin.
    
You can try gdal_translate, but I think if the numbers don't
add up in r.in.bin then as a fundamental matter they won't add
up anywhere else either. Unless GDAL's autodetect magic finds
something special about the file format.

Can you provide all the known info you can about the file?
Exact filesize, expected dimensions, given bounds, endianness,
bytes per cell, data type (floating point, integer, ..),
expected data range, etc.? Maybe we can figure it out with a
hand calculator.
  

I'll have to pick it up on Monday - the documentation is back at the office! gdal_translate and gdalinfo don't recognise the file format ...

Cheers,
Richard

It could be that there is some header info written before the
stream of data which is padding the filesize by several bytes
thus throwing off the sanity check math.

Hamish

14

On Fri, Sep 5, 2008 at 11:42 PM, Richard Chirgwin
<rchirgwin@ozemail.com.au> wrote:

Hamish wrote:

Richard Chirgwin wrote:

Returning to my original problem: is there a program for
Linux that will read a BIN DEM, and let me save it in something
like GeoTIFF, because I cannot beat the two-byte file size
error detected by r.in.bin.

You can try gdal_translate, but I think if the numbers don't
add up in r.in.bin then as a fundamental matter they won't add
up anywhere else either. Unless GDAL's autodetect magic finds
something special about the file format.

Can you provide all the known info you can about the file?
Exact filesize, expected dimensions, given bounds, endianness,
bytes per cell, data type (floating point, integer, ..),
expected data range, etc.? Maybe we can figure it out with a
hand calculator.

I'll have to pick it up on Monday - the documentation is back at the office!
gdal_translate and gdalinfo don't recognise the file format ...

You'll need to write a VRT file:
http://www.gdal.org/gdal_vrttut.html
and use that as input to gdalinfo etc.

Markus

15

Another way for gdal to recognize bin files is to write a header file.
The bad news is that you mus know the number of collumns, rows, bands etc etc

http://www.gdal.org/frmt_various.html#EHdr

Daniel

On Sun, Sep 7, 2008 at 5:12 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Sep 5, 2008 at 11:42 PM, Richard Chirgwin
<rchirgwin@ozemail.com.au> wrote:

Hamish wrote:

Richard Chirgwin wrote:

Returning to my original problem: is there a program for
Linux that will read a BIN DEM, and let me save it in something
like GeoTIFF, because I cannot beat the two-byte file size
error detected by r.in.bin.

You can try gdal_translate, but I think if the numbers don't
add up in r.in.bin then as a fundamental matter they won't add
up anywhere else either. Unless GDAL's autodetect magic finds
something special about the file format.

Can you provide all the known info you can about the file?
Exact filesize, expected dimensions, given bounds, endianness,
bytes per cell, data type (floating point, integer, ..),
expected data range, etc.? Maybe we can figure it out with a
hand calculator.

I'll have to pick it up on Monday - the documentation is back at the office!
gdal_translate and gdalinfo don't recognise the file format ...

You'll need to write a VRT file:
http://www.gdal.org/gdal_vrttut.html
and use that as input to gdalinfo etc.

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user