r.import inconsistent behavior when using r.in.gdal and r.proj

[annakrat]

Module r.import has options for output resolution and extent, but they are basically ignored when coordinates system matches and r.in.gdal is used, they are used only when reprojecting. So when there is no reprojection needed:

1. r.in.gdal has new -r flag, so that should be used if extent=region
2. when resolution=value or resolution=region, r.import should resample the raster. The default (resolution=estimated) means r.in.gdal uses resolution of the raster as it is now.

Any objection to this behavior?

[mmetz]

Replying to annakrat:

Module r.import has options for output resolution and extent, but they are basically ignored when coordinates system matches and r.in.gdal is used, they are used only when reprojecting. So when there is no reprojection needed:

1. r.in.gdal has new -r flag, so that should be used if extent=region
2. when resolution=value or resolution=region, r.import should resample the raster. The default (resolution=estimated) means r.in.gdal uses resolution of the raster as it is now.

Any objection to this behavior?

The purpose and intention of [r|v].import is easy import of GIS data with optional reprojection. I suggest to have a minimalistic interface for the two modules and refer to other modules if more control over the import process is needed.

There are a number of r.resamp.* modules available. The appropriate module and method depends on both the kind of input data (categorical, nominal, metric) and the kind of resampling (upsampling or downsampling). IMHO it would be safer to leave this decision to the user.

[annakrat]

Replying to mmetz:

Replying to annakrat:

Module r.import has options for output resolution and extent, but they are basically ignored when coordinates system matches and r.in.gdal is used, they are used only when reprojecting. So when there is no reprojection needed:

1. r.in.gdal has new -r flag, so that should be used if extent=region
2. when resolution=value or resolution=region, r.import should resample the raster. The default (resolution=estimated) means r.in.gdal uses resolution of the raster as it is now.

Any objection to this behavior?

The purpose and intention of [r|v].import is easy import of GIS data with optional reprojection. I suggest to have a minimalistic interface for the two modules and refer to other modules if more control over the import process is needed.

I am not suggesting more complicated interface, I just want the interface to behave consistently. Or are you suggesting simplification of the current interface?

From my perspective, everybody (including power users) likes 'easy import'. Importing and reprojection in one step is a huge step towards making GRASS accessible to beginners. I don't see anything wrong with having more control over importing with r.import as long as defaults are reasonable. I understand that we don't want people to blindly use default nearest neighbor resampling when they should be using bicubic, but on the other hand, without r.import, a lot of people would be stuck, or they would check 'override projection' and end up with nonsense (which happens quite a bit at least in my experience).

There are a number of r.resamp.* modules available. The appropriate module and method depends on both the kind of input data (categorical, nominal, metric) and the kind of resampling (upsampling or downsampling). IMHO it would be safer to leave this decision to the user.

Yes, that's what I want, in this case we would just use the resampling method selected in resample option. If users keep defaults, nothing changes in the processing, here I talk only about situations when user specifes extent=region and resolution=value or resolution=region.

Regarding the resampling, we could have a warning when they use nearest neighbor but the raster is floating point.

[mmetz]

Replying to annakrat:

Replying to mmetz:

Replying to annakrat:

Module r.import has options for output resolution and extent, but they are basically ignored when coordinates system matches and r.in.gdal is used, they are used only when reprojecting. So when there is no reprojection needed:

1. r.in.gdal has new -r flag, so that should be used if extent=region
2. when resolution=value or resolution=region, r.import should resample the raster. The default (resolution=estimated) means r.in.gdal uses resolution of the raster as it is now.

Any objection to this behavior?

The purpose and intention of [r|v].import is easy import of GIS data with optional reprojection. I suggest to have a minimalistic interface for the two modules and refer to other modules if more control over the import process is needed.

I am not suggesting more complicated interface, I just want the interface to behave consistently. Or are you suggesting simplification of the current interface?

From my perspective, everybody (including power users) likes 'easy import'. Importing and reprojection in one step is a huge step towards making GRASS accessible to beginners. I don't see anything wrong with having more control over importing with r.import as long as defaults are reasonable. I understand that we don't want people to blindly use default nearest neighbor resampling when they should be using bicubic, but on the other hand, without r.import, a lot of people would be stuck, or they would check 'override projection' and end up with nonsense (which happens quite a bit at least in my experience).

There are a number of r.resamp.* modules available. The appropriate module and method depends on both the kind of input data (categorical, nominal, metric) and the kind of resampling (upsampling or downsampling). IMHO it would be safer to leave this decision to the user.

Yes, that's what I want, in this case we would just use the resampling method selected in resample option. If users keep defaults, nothing changes in the processing, here I talk only about situations when user specifes extent=region and resolution=value or resolution=region.

Regarding the resampling, we could have a warning when they use nearest neighbor but the raster is floating point.

You would at least need to add the resampling methods of r.resamp.stats:

average, median, mode, minimum, maximum, range, quart1, quart3, perc90, sum, variance, stddev, quantile, count, diversity

add explanations about which method is appropriate for which combination of the kind of input data and the direction of resolution change (upsampling or downsampling) and modify r.import to use r.resamp.stats if need be.

If the input CRS matches the location's CRS, I would rather have an important message that the raster is imported as is and resampling can be done with with any of the r.resamp.* modules.

[annakrat]

Replying to mmetz:

You would at least need to add the resampling methods of r.resamp.stats:

average, median, mode, minimum, maximum, range, quart1, quart3, perc90, sum, variance, stddev, quantile, count, diversity

add explanations about which method is appropriate for which combination of the kind of input data and the direction of resolution change (upsampling or downsampling) and modify r.import to use r.resamp.stats if need be.

If the input CRS matches the location's CRS, I would rather have an important message that the raster is imported as is and resampling can be done with with any of the r.resamp.* modules.

OK, fair enough. Do we agree on the first point - incorporating the -r flag of r.in.gdal or is there some caveat?

[mmetz]

Replying to annakrat:

Replying to mmetz:

You would at least need to add the resampling methods of r.resamp.stats:

average, median, mode, minimum, maximum, range, quart1, quart3, perc90, sum, variance, stddev, quantile, count, diversity

add explanations about which method is appropriate for which combination of the kind of input data and the direction of resolution change (upsampling or downsampling) and modify r.import to use r.resamp.stats if need be.

If the input CRS matches the location's CRS, I would rather have an important message that the raster is imported as is and resampling can be done with with any of the r.resamp.* modules.

OK, fair enough. Do we agree on the first point - incorporating the -r flag of r.in.gdal or is there some caveat?

I can't see a caveat, for consistency it makes sense to use the new -r flag of r.in.gdal with extent=region.

[annakrat]

In 71412:

r.import: include r.in.gdal r flag to limit region, see #3374