Merge grid update#1482
Conversation
added logic for closest data type
Some minimal changes to comments. Major changes to the logic that determines the best data type for the output raster. Some test files that show the output of the data type logic for various cases.
small updates
|
@jany-tenaj let me review the IsFloatingPoint routine. I remember I had some issues with it but it did compile. Ill take a look again. The test.txts files are nothing more than simple tests to see how the logic to determine the best output data type works. For example, if the inputs are DTED and ASCII and the requested output is GRB what would be the best data type for the merge. I just dont have access to all the raster formats and data types. |
Added test cases and raster data. The merge test showed that the new logic wasn't quite working as expected. Added back the original logic until the new logic can be reviewed.
Small updates
|
@jany-tenaj ok I have updated IsFloatingPoint so that it now has no warnings. Oddly enough the current production logic also bombs. Maybe I am missing something on this method. fileNameA=C:\Users\DarkPax\Documents\GitHub\DotSpatial\Source\Tests\DotSpatial.Tools.Tests\bin\Data\Grids\TIFF\GTOPO30.tif fileNameB=C:\Users\DarkPax\Documents\GitHub\DotSpatial\Source\Tests\DotSpatial.Tools.Tests\bin\Data\Grids\BIL\GTOPO30.bil fileNameOut=C:\Users\DarkPax\Documents\GitHub\DotSpatial\Source\Tests\DotSpatial.Tools.Tests\bin\Data\Grids\merged.bgd The size of the file was 558 which didn't match the expected 5586380 |
Small tweaks
|
Yeah I think something is not right. This outputs It appears that the FileType (and maybe some other properties) are not set with the GdalRasterProvider.Open method. Should I be using Raster.Open instead? |
|
I've got no idea. Never used this tool before |
small tweaks

Fixes #1443. This PR suggests a method to intelligently determine the best data type for the output raster. Production is hard coded to generate a raster of type int so I introduced some crude methods to determine the best data type fit. However, the routines that determine the best data type are only called once per operation so it's not too expensive. I am attaching data type logic testing and will follow up with actual grid testing.
Checklist
Changes proposed in this pull request:
Due to the issue #1443 I started to look at the routine thinking it was an easy fix. It was not an easy fix. The aim of the routine DotSpatial.Tools.MergeGrids.Execute is to take two grids and merge them. Easy enough, but due to a myriad of raster types, the current routine had to be adjusted.