Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Clip raster by mask layer" produces different results than "Clipper" from Raster Menu #17998

Closed
qgib opened this issue Jan 22, 2014 · 8 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms

Comments

@qgib
Copy link
Contributor

qgib commented Jan 22, 2014

Author Name: Filipe Dias (@fsdias)
Original Redmine Issue: 9400
Affected QGIS version: 2.4.0
Redmine category:processing/gdal
Assignee: Alexander Bruy


I tried clipping a raster with "Clipper" from the Raster Menu and "Clip with mask layer" from the Processing Toolbox and obtained different results

The outputs of both functions had:

  • different raster statistics (Layer properties ->Metadata->Band 1)

  • handled no "NoDataValues" differently. While Clipper kept "NoDataValue" undefined, Clip with mask layer assigned "0" as NoDataValue, even though I set "none" in Nodata value

Am I missing something? I attached test data to reproduce the issue


@qgib
Copy link
Contributor Author

qgib commented Jan 22, 2014

Author Name: Filipe Dias (@fsdias)


SAGA 2.10/"Clip grid with polygon" produced a raster with the same statistics as the output from "clip raster with mask layer" and assigned -32767 as NoDataValue

@qgib
Copy link
Contributor Author

qgib commented Jan 22, 2014

Author Name: Giovanni Manghi (@gioman)


The different stats are explained because all the pixels that have 0 value are evidently counted in the stats (that does not happens for NO DATA).

If you need to have NO DATA in the output from the tool in the raster menu then you must check the "no data value" option (and set it to 0).


  • status_id was changed from Open to Closed

@qgib
Copy link
Contributor Author

qgib commented Jan 22, 2014

Author Name: Filipe Dias (@fsdias)


Giovanni Manghi wrote:

The different stats are explained because all the pixels that have 0 value are evidently counted in the stats (that does not happens for NO DATA).

You're right

But one issue remains: if the original raster doesn't have a NoDataValue, then the tool in the processing toolbox automatically assigns it to 0. The function "clipper" does not do this.


  • status_id was changed from Closed to Reopened

@qgib
Copy link
Contributor Author

qgib commented Jan 22, 2014

Author Name: Giovanni Manghi (@gioman)


Filipe Dias wrote:

Giovanni Manghi wrote:

The different stats are explained because all the pixels that have 0 value are evidently counted in the stats (that does not happens for NO DATA).

You're right

But one issue remains: if the original raster doesn't have a NoDataValue, then the tool in the processing toolbox automatically assigns it to 0. The function "clipper" does not do this.

to me makes much more sense that the areas outside the clipped area are NO DATA rather than 0. So in this sense the processing tool acts better by default than the tool in th vector menu, that has the option unchecked.

@qgib
Copy link
Contributor Author

qgib commented Jan 22, 2014

Author Name: Filipe Dias (@fsdias)


There is that. But maybe the tool in the Raster Menu was designed that way because of some use case?

Anyway, it's important that both tools behave the same way.

@qgib
Copy link
Contributor Author

qgib commented Oct 4, 2014

Author Name: Giovanni Manghi (@gioman)


  • project_id was changed from 78 to 17
  • crashes_corrupts_data was configured as 0
  • version was configured as 2.4.0
  • category_id removed 58

@qgib
Copy link
Contributor Author

qgib commented Oct 4, 2014

Author Name: Giovanni Manghi (@gioman)


  • category_id was configured as Processing/GDAL

@qgib
Copy link
Contributor Author

qgib commented May 23, 2016

Author Name: Alexander Bruy (@alexbruy)


Works fine in master. There is a minor difference in statistics cause by the fact that Processing tool aligns the coordinates of the extent of the output file to the values of the resolution ("-tap" option).

Please reopen if necessary.


  • status_id was changed from Reopened to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms labels May 24, 2019
@qgib qgib closed this as completed May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms
Projects
None yet
Development

No branches or pull requests

1 participant