[GRASS5] [GRASSLIST:5023] Re: R.in.arc in GRASS 5.7 menus

Markus Neteler wrote:

> Abyway in my a grass57_exp_2004_11_13 it isn't there.

We intend to remove it anyway as r.in.gdal should do the job.
Please report cases (with data) where r.in.gdal fails to the
GDAL bugtracker.

Do we know if and when Frank is going to fix that GDAL takes the floating point AI ASCII GRID as an integer if there is more than 1K of null values, ususally represented as "-something", in the beginning of such an FP grid?

Besides - would r.in.gdal recognize if the grid is DCEL or FCELL? Or is there a way to force either like in r.in.arc?

Maciek

From: "Maciek Sieczka" <werchowyna@pf.pl>

Markus Neteler wrote:

We intend to remove it anyway as r.in.gdal should do the job.
Please report cases (with data) where r.in.gdal fails to the
GDAL bugtracker.

Do we know if and when Frank is going to fix that GDAL takes the floating
point AI ASCII GRID as an integer if there is more than 1K of null values,
ususally represented as "-something", in the beginning of such an FP grid?

Nobody answers so I assume that we don't know. In that case removing
r.in.arc makes no sense yet - until this bug in gdal is fixed. Otherwise
ther will be problems an bug reports from people having nulls in the
beginning or their grids, which is not that unlikely to happen.

Besides - would r.in.gdal recognize if the grid is DCEL or FCELL? Or is
there a way to force either like in r.in.arc?

So I assume that r.in.gdal doesn't let one to recognize or force the
required accuracy. Another reason for not removing r.in.arc yet.

What do you think?

Maciek

On Mon, Dec 06, 2004 at 11:32:36AM +0100, Maciek Sieczka wrote:

From: "Maciek Sieczka" <werchowyna@pf.pl>

>Markus Neteler wrote:

>>We intend to remove it anyway as r.in.gdal should do the job.
>>Please report cases (with data) where r.in.gdal fails to the
>>GDAL bugtracker.

>Do we know if and when Frank is going to fix that GDAL takes the floating
>point AI ASCII GRID as an integer if there is more than 1K of null values,
>ususally represented as "-something", in the beginning of such an FP grid?

Nobody answers so I assume that we don't know.

IMHO this message should be posted to the GDAL mailing list as
it belongs to GDAL. Please post there as well.

In that case removing
r.in.arc makes no sense yet - until this bug in gdal is fixed. Otherwise
ther will be problems an bug reports from people having nulls in the
beginning or their grids, which is not that unlikely to happen.

>Besides - would r.in.gdal recognize if the grid is DCEL or FCELL? Or is
>there a way to force either like in r.in.arc?

So I assume that r.in.gdal doesn't let one to recognize or force the
required accuracy. Another reason for not removing r.in.arc yet.

What do you think?

Maybe related flags could be added to r.in.gdal to enforce CELL/FCELL/DCELL.

Markus

Markus Neteler wrote:

On Mon, Dec 06, 2004 at 11:32:36AM +0100, Maciek Sieczka wrote:

From: "Maciek Sieczka" <werchowyna@pf.pl>

Markus Neteler wrote:

We intend to remove it anyway as r.in.gdal should do the job.
Please report cases (with data) where r.in.gdal fails to the
GDAL bugtracker.

Do we know if and when Frank is going to fix that GDAL takes the floating
point AI ASCII GRID as an integer if there is more than 1K of null values,
ususally represented as "-something", in the beginning of such an FP grid?

Nobody answers so I assume that we don't know.

IMHO this message should be posted to the GDAL mailing list as
it belongs to GDAL. Please post there as well.

I suggest to keep r.in.arc in GRASS5.7/6.0 until this is fixed in r.in.gdal,
Maciek, please post to GDAL list because it needs to be fixed in GDAL.

Helena

In that case removing
r.in.arc makes no sense yet - until this bug in gdal is fixed. Otherwise
ther will be problems an bug reports from people having nulls in the
beginning or their grids, which is not that unlikely to happen.

Besides - would r.in.gdal recognize if the grid is DCEL or FCELL? Or is
there a way to force either like in r.in.arc?

So I assume that r.in.gdal doesn't let one to recognize or force the
required accuracy. Another reason for not removing r.in.arc yet.

What do you think?

Maybe related flags could be added to r.in.gdal to enforce CELL/FCELL/DCELL.

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5