| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
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
|
@sindizzy Please check out public static bool IsFloatingPoint(Type typ) { return typ is float | typ is double | typ is decimal; }. VS is throwing CS0184 The given expression is never of the provided ('type') type warnings for all three types. Changing Type typ to ValueType typ as shown in your referenced link removes those errors but causes an error with the parameter given to IsFloatingPoint which is a Type. I have no data to try and check whether this works although it's throwing warnings. Furthermore you stated you added examples or tests. I can see those test.txts you added but no MergeGridTest.cs. What are those test.txts for? |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
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 |
Sorry, something went wrong.
Small tweaks
|
Yeah I think something is not right. var rstTypeA = Raster.GetGridFileType(fileNameA);
Debug.Print("gridA: RasterFileType={0}", rstTypeA);
var p = new GdalRasterProvider();
var gridA = p.Open(fileNameA);
Debug.Print("gridA: FileType={0} DataType={1}", gridA.FileType, gridA.DataType);
This outputs fileNameA=\Source\Tests\DotSpatial.Tools.Tests\bin\Data\Grids\TIFF\GTOPO30.tif gridA: RasterFileType=GeoTiff gridA: FileType=Ascii DataType=System.Int16 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? |
Sorry, something went wrong.
|
I've got no idea. Never used this tool before |
Sorry, something went wrong.
|
@jany-tenaj ok let me dig a little deeper. |
Sorry, something went wrong.
small tweaks
| Back | FazBrowse Home | New Git URL |
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.