[GRASS5] floating AI ASCII GRID import
hmitaso at unity.ncsu.edu
Mon Nov 29 17:33:35 EST 2004
I happen to work with ascii grid files right now and I have a situation
where I have both integer and FP values, the integer being -9999 for no data.
I tried it with r.in.gdal and indeed it imported it as integer (which for DEMs
can be a serious problem). I would guess that this may be the most common
situation when users get it imported as integer rather than FP (besides manually
changing some of the data) - I think that this could be fixed relatively
easily if the integer value for nodata defined in the header is skipped.
If this cannot be fixed we should keep r.in.arc
Frank Warmerdam wrote:
> Maciek Sieczka wrote:
>> From: "Michael Barton" <michael.barton at asu.edu>
>> Sent: Monday, November 29, 2004 5:56 PM
>> Subject: Re: [GRASS5] floating AI ASCII GRID import
>>> I haven¹t had a chance to test this to see if r.in.gdal is the same as
>>> r.in.arc. If it is, I agree completely that we need eliminate redundancy
>>> where possible. Perhaps Maciek can test it as he seems to have a set
>>> of AI
>>> ASCII grid files he is working with now. Let me know if it is redundant
>>> I¹ll take it off the input menu.
>> The problem is that GDAL may round the floating AI ASCII GRID to integer.
>> Below is what Frank Warmerdam once wrote on the gdal-list. Frank, is it
>> still not fixed? BTW - what is the chance that GDAL could be thought
>> to recognize if the AI AGRID is FCELL or DCELL?
>> From: "Frank Warmerdam" <warmerdam at pobox.com>
>> Sent: Tuesday, June 01, 2004 2:59 PM
>> Subject: Re: [Gdal-dev] floating point bug
>>> This is already a known issue in bug:
>>> Basically I scan the first 1K or so of the file to look for floating
>>> If I don't find any I assume the whole coverage is integer.
>>> I have been hesitant to "fix" this as a proper fix would seem to require
>>> scanning the whole file on open which is pretty expensive.
> This is still an open issue.
> Best regards,
More information about the grass-dev