Merged
Conversation
…d datasets, removing the NO_DATA collars from the various wxModel datasets. For issue #647
…ue, printing the NO_DATA value was already skipped but the calculations were still being done unnecessarily.
I also noticed that the NO_DATA check in sampleRawOutput() was placed a bit late in the code, causing the log profile calculations results to replace the NO_DATA values with crazy high values, causing problems with the later stuff in the code. So I moved up that NO_DATA check to a better spot in the code, looks to be working better now. This check being earlier also allows wind_uv_to_sd() to no longer be dealing with NO_DATA values in that section of code.
I found these spots in the code as I was looking through all the various uses of the wrap0to360(), wind_uv_to_sd(), and wind_sd_to_uv() ninjaMathUtility functions, which are NOT meant to be used on NO_DATA values. I was worried that adding more correct NO_DATA values would cause those functions problems, but it looks like I had already gotten the proper logic done ("if(inVal == NO_DATA){outVal = NO_DATA;}else{outVal = wrap0to360(inVal);}") back when I did the angleFromNorth work, other than these two spots in the code. All the other spots in the code that didn't have this check, were good to go, because they used simulation or interpolated to inner region datasets, that were guaranteed to not have NO_DATA values by that point.
I almost added another check like this to ninja.cpp for the ascii grid output, but since that spot is simulation ascii output and not wxModel ascii output, it was still fine. Found the wxModel ascii output in wxModelInitialization.cpp, looks like wxModel ascii and shp file output are fine, they do not warp to a new projection, they stay in the original pre-warped projection, with the original band of NO_DATA values from the original pre-warp, all that was needed in that part of the code was to just print the values as they were.
For issue #647. Related to issue #544.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #647, at least for the wxModels. Seems the method actually applied to ALL warp types that use
GDALWarpOptions, not just the specificGDALAutoCreateWarpedVRT()warping method.So here and here in
gdal_util.cppstill need checked (these functions seem to only be used bysurface_fetch.cppclasses), all the various warps done in the varioussurface_fetch.cppclasses also need checked, and here, here, and here need checked inascii_grid.cpp. But thewxModelInitialize.cppclasses SHOULD be good to go.I believe the remaining
surface_fetch.cppwarps in the code work correctly, because the DEM datasets actually HAVE pre-defined NO_DATA values, and if not and it is putting zeroes in for NO_DATA, we still clip the dataset to a subset area, clipping off the NO_DATA edges anyways. I believe theasciiToPng()output works out correctly, because NO_DATA values should already be defined for the dataset, and if not, then zeroes technically works out because the pixels are defined as 0 to 255 with NO_DATA values as 0 anyways.I am a bit more leery of the raw value
tiffoutput inascii_grid.cppthough, here and here. NO_DATA values as zeroes probably works for the 'gtiff' datasets, but using the actual NO_DATA values would probably be better.