GeoTrellis is a geographic data processing engine for high performance applications.
dependabot[bot] on npm_and_yarn
Bump prismjs from 1.22.0 to 1.2… (compare)
pomadchin on master
Fix spelling (#3337) Stiching … (compare)
@metasim yes, to determine the celltype correctly we need bitsPerSample
and sampleFormat
, bitsPerSample is number of bits per tiff sample, and the sampleFormat
is used to determin the ‘sing’ of values.
LIBTIFF exposes this information and in geotiff native jvm reader we also use this information to determine the cellType properly: https://github.com/locationtech/geotrellis/blob/7871e015129ae4a1ccfd06a23544a6de9ac68c6e/raster/src/main/scala/geotrellis/raster/io/geotiff/BandTypes.scala#L37
However GDAL doesn’t expose such information, or I didn’t find a proper way of doing it. Probably you can find smth in the GDAL C API and somehow get the information from the used driver about the raster cellType, but I’m not sure that it is possible to expose such information via GDAL
import geotrellis.spark._
in the call scope. If you have it and function still doesnt work try to use withGetBoundsMethod(rdd).getGridBounds
in your code, this at least will give you a readble compile time error.
case
here is always true and the second is never evaluated?
NoData Value=255
It would be awesome if you could sign an ECA https://github.com/locationtech/geotrellis/blob/master/docs/CONTRIBUTING.rst#eclipse-contributor-agreement-eca
after that commit changes via git commit -s -m “commit message”
command
typeSizeInBits
is passed
@metasim we didnt resolve that; imagine the case that you have multiple RasterSources
you want to figure out how to tile them to some layout in some projection…
it would mean that you probably need to collect metadata in some CRS or reprojet it into some CRS to have some idea of the entire rasters list extent