On 2/16/22 12:46, Even Rouault wrote:
fix
queued in https://github.com/OSGeo/gdal/pull/5313
Cool, thanks!
--
Dr. Craig S. Bruce
Senior Software Developer
CubeWerx Inc.
https://www.cubewerx.com
I tried to submit this issue on GitHub, but it wouldn't let me press
the Submit button and wouldn't tell me why not.
## Expected behavior and actual behavior.
The generation of Cloud-Optimized GeoTIFF images sometimes includes
an fringe of random colors around t
On 11/6/20 7:07 AM, jratike80 wrote:
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY
On 07/06/2018 07:14 AM, Even Rouault
wrote:
NoData Value=3.40282346638529011e+38
Metadata:
STATISTICS_MAXIMUM=3.4028234663853e+38
ok, the issue is that nodata value (stored as text in GeoTIFF) is slightly
above the maximum value of a
On 11/11/2017 06:05 AM, Ari Jolma
wrote:
I'm
making a data request on the corner of the bounding box, let's say
it has minimum X of 75042.7273594. I'm setting my minX to that
value and I'm enforcing it to that value with MAX (this was
introduced bec
On 11/09/2016 04:14 PM, Even Rouault
wrote:
and it builds fine. Both with gcc 4.6.0 that comes with the DVD, and 4.6.3
after the updates.
So it would seem that it is one of the dependency that might cause the issue
(which seems odd)
It's very strange. It
I'm trying to build GDAL 2.1.2 on Fedora 15 Linux. I'm using a
complicated environment and collection of .a files (because .so's
are like a box of chocolates) and running into a some GDAL-internal
function that's missing:
g++ -L/cw/builds_3p/linux_f15_x64/lib gdalin
On 2015-10-02 19:19, Kurt Schwehr
wrote:
Why yes :). Slashdot...
The scuttlebutt on Slashdot was about how this format is D.O.A.
because the reference library is GPLv3-only, which is incompatible
with everything else.
--
Dr. Craig S. Bruce
In trying to check GDAL 2.0.0 into a local Subversion repository, I
get various errors about inconsistent newline styles. For instance:
svn add --force gdal-2.0.0
svn: E29: File
'/home/sourcetree/cw/src_3p/gdal-2.0.0/port/cpl_time.h' has
inconsistent newline
On 2015-04-07 16:33, Even Rouault
wrote:
This RFC modifies the GDALRasterBand GetHistogram(), GetDefaultHistogram() and
SetDefaultHistogram() methods to accept arrays of 64-bit integer instead of
the current arrays of 32-bit integer for bucket counts. This will fi
On 2015-04-05 16:25, Even Rouault
wrote:
struct {
GInt16 Year;
GByte Month;
GByte Day;
GByte Hour;
GByte Minute;
GByte TZFlag;
GByte Precision; /* value in OGRDateTimePrecision */
floa
I have encountered a couple of issues with the WCS driver of GDAL 1.9.0
when accessing my WCS 1.0.0 server. The WCS driver doesn't recognize
the color interpretations of image bands. For example (from a server
not accessible to the outside world):
[dev:~] gdalinfo gdal_wcs_terrapixel.xml
Driver
Even Rouault wrote:
> If you do GetMaskBand().GetMaskFlags(), then it will return 0x1, since
> the mask band itself has no mask.
Oops, that is what I did. Thanks.
--+--+--
Dr. Craig S. Bruce| Ph 819-771-8303 x205 |
I have run into a bug using GDALGetMaskFlags() with GTOPO30 data with
the GDAL 1.9.0 C API. The test data includes a NoData value:
[dev:~] gdalinfo /cw/testdata/gtopo30/w180s60.dem
Driver: EHdr/ESRI .hdr Labelled
...
Band 1 Block=7200x1 Type=Int16, ColorInterp=Undefined
NoData Value=-
When
Even Rouault wrote:
> There will be likely a compatibility problem if we do this, because
> GDAL up to now writes TIFF RGBA images with EXTRASAMPLE_ASSOCALPHA
> (pre-multiplied), but I think in most cases the data that people have
> feed in the GTiff driver was not pre-multiplied. So if we un-pre
Frank Warmerdam wrote:
> because it is hard to hit all the appropriate code paths safely and
> partly because the result will be lossy.
It depends on what you mean by "lossy". The value returned through the
GDAL interface won't be the literal sample value that is in a TIFF file
with associated
Tamas Szekeres wrote:
> I have added a ticked for such an issue long ago, but I don't remember
> what would be the expected solution.
> http://trac.osgeo.org/gdal/ticket/2279
>
> There should be an external config option to instruct the driver which
> representation should be used.
I think it wo
I have run into a problem using GDAL to read TIFF images with a alpha
channels. GDAL returns the source TIFF sample values verbatim regardless
of whether the alpha channel is associated (pre-multiplied) or unassociated
within the TIFF image samples. (In each alpha model, the same pixel
value with
18 matches
Mail list logo
