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

Added `withDefaultNoData` for all `DataType`s. #1966

merged 1 commit into from Feb 9, 2017


None yet
3 participants

metasim commented Jan 17, 2017

Signed-off-by: Simeon H.K. fitch

I have run into a number of situations where I'd like to enable the default ConstantNoData value for a DataType when the specific type isn't known at runtime. This PR is a draft implementation for the purposes of getting feedback. If this feature and implementation pass muster, I'll add unit tests.

  • Create unit tests
Added `withDefaultNoData` for all `DataType`s.
Signed-off-by: Simeon H.K. fitch <>

This comment has been minimized.


echeipesh commented Jan 26, 2017

This seems alright, I think we nearly wrote something like this originally but couldn't quite justify it so it was left out. It would be helpful to know what situations specifically prompted this for future understanding and design.


This comment has been minimized.


metasim commented Feb 3, 2017

@echeipesh This is where we've run into it: we have a directory structure of GeoTIFF images with different CellTypes without the NODATA value set. These images (e.g. L8) have an implicit no-data value that is the same as GeoTrellis' default value. So, instead of having to pattern match over all the different cell types to set the default no-data value when one isn't set, it would be nice to have a polymorphic method that does that for us.

@echeipesh echeipesh merged commit 49659cd into locationtech:master Feb 9, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed

This comment has been minimized.


echeipesh commented Feb 9, 2017

steam checked it, looks good and once again thank you.

@lossyrob lossyrob added this to the 1.0.1 milestone Mar 10, 2017

@echeipesh echeipesh removed this from the 1.0.1 milestone Mar 10, 2017

@lossyrob lossyrob added this to the 1.1 milestone Mar 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment