Never mind! I just checked the histogram and the data is getting scaled,
I forgot that I was also scaling it in my mapfile so the results where
getting masked.
-Steve
On 1/23/2020 8:20 PM, Stephen Woodbridge wrote:
Hi all,
I'm having trouble getting my VRT file to scale the source data into
Putting something like mapserver/mapcache in front of your requests might
work, if I understand correctly. We serve COGs out of s3 via WMS like this
and the performance is pretty nice.
See
https://github.com/pedros007/mapserver-docker
for some discussion on such a setup.
Best,
Patrick
On Thu
> Hi gdal-devs,
> I have a question, if there is some way to use gdalwarp in a clustering
> system (e.g., Sparks) or with GPU to speed up the process? My task involves
> re-projection and re-sampling of hundreds of high-resolution images. Any
> ideas to make use of Sparks or GPU is welcomed. Tha
Hi all,
I'm having trouble getting my VRT file to scale the source data into my
ColorTable.
I've been looking at this https://gdal.org/drivers/raster/vrt.html
The source GeoTiff has:
Band 1 Block=4500x1 Type=Float32, ColorInterp=Gray
Minimum=1.082, Maximum=46.322, Mean=34.181, StdDev=2.049
Hi,
I've already reported an issue a while back related to the OGRSQL dialect
along with the FDGB driver, when the where clause contains expression for
the FID column. I'm still experiencing the problem in GDAL master, where
the following query doesn't seem to apply the specified filter:
*ogrinfo
On jeudi 23 janvier 2020 14:10:03 CET Brian wrote:
> Strange because the files were created by GDAL I created the COG using
> these steps ( original file is too large it is an georaster export). Do you
> see anything that would introduce the corrupt data? What can be done to fix
> it? I attached ea
On jeudi 23 janvier 2020 13:26:01 CET Brian wrote:
> Currently using the master and received these warnings when running
> gdal_translate
>
> "Warning 1: TIFFReadDirectory:Invalid data type for tag TileByteCounts
> Warning 1: TIFFReadDirectory:Invalid data type for tag TileOffsets"
>
> The exact
Currently using the master and received these warnings when running
gdal_translate
"Warning 1: TIFFReadDirectory:Invalid data type for tag TileByteCounts
Warning 1: TIFFReadDirectory:Invalid data type for tag TileOffsets"
The exact command was
gdal_translate -stats raster_trans.tif raster_cog.tif
The new docs are searchable
https://gdal.org/search.html?q=ExecuteSQL
Mateusz Loskot, mate...@loskot.net
(Sent from mobile, may suffer from top-posting)
On Thu, 23 Jan 2020, 18:04 Andrew Bell, wrote:
>
> Thanks. Just located it in the documentation. Google was not my friend
> in this case.
Thanks. Just located it in the documentation. Google was not my friend in
this case.
Sorry to bother,
On Thu, Jan 23, 2020 at 1:03 PM Even Rouault
wrote:
> On jeudi 23 janvier 2020 12:49:38 CET Andrew Bell wrote:
> > Hi,
> >
> > This function returns a pointer to a layer. Does the dataset re
On jeudi 23 janvier 2020 12:49:38 CET Andrew Bell wrote:
> Hi,
>
> This function returns a pointer to a layer. Does the dataset retain
> ownership of the layer, or does the user need to make sure that the layer
> gets deleted?
>
https://gdal.org/api/gdaldataset_cpp.html#_CPPv4N11GDALDataset10Ex
Hi,
This function returns a pointer to a layer. Does the dataset retain
ownership of the layer, or does the user need to make sure that the layer
gets deleted?
Thanks,
--
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.o
On jeudi 23 janvier 2020 18:35:40 CET Edzer Pebesma wrote:
> On 1/23/20 5:58 PM, Even Rouault wrote:
> >> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
> >> fine; I'm OK with the warning, I just don't see how the subsequent error
> >> relates to syntax that is deprecated.
On 1/23/20 5:58 PM, Even Rouault wrote:
>> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
>> fine; I'm OK with the warning, I just don't see how the subsequent error
>> relates to syntax that is deprecated.
>
> I'm looking at this, but haven't yet an explanation. This is
> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
> fine; I'm OK with the warning, I just don't see how the subsequent error
> relates to syntax that is deprecated.
I'm looking at this, but haven't yet an explanation. This is very subtle,
and seems to be linked specifically
On 1/23/20 5:29 PM, Sean Gillies wrote:
> Hi,
>
> On Thu, Jan 23, 2020 at 8:01 AM Edzer Pebesma
> mailto:edzer.pebe...@uni-muenster.de>>
> wrote:
>
> The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
> platforms is causing some havoc for some spatial R packages. I could
>
LS,
which GDAL version includes the DODS driver (libdap)?
We need to query the NOAA GrADS Data Server for GFS data with c#.
Kind regards
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
On Thu, Jan 23, 2020 at 8:01 AM Edzer Pebesma
wrote:
> The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
> platforms is causing some havoc for some spatial R packages. I could
> bring one particular problem back to the following C++ program:
>
> #include
> #include "ogrsf_frmt
The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
platforms is causing some havoc for some spatial R packages. I could
bring one particular problem back to the following C++ program:
#include
#include "ogrsf_frmts.h"
#include
int main() {
OGRSpatialReference *aSRS = new OGRSpa
Hi,
I have a large (global, 30m resolution, 50GB+) GeoTIFF dataset, from which I
need to read many (millions) of pixel values at given input coordinates. I've
got reasonable performance out of the code, about a million queries over five
minutes, but:
1. There are actually twelve separate d
Hi,
Do I estimate right that you have about 125 terabytes image data as
uncompressed , and the first level overview would make about 32 terabytes?
As JPEG compressed it would still make about 3 terabyte .ovr file. That is
not too much for BigTIFF that has a size limit at 18000 petabytes, but it
ma
Mats,
> I'm trying to build overviews on a large vrt file, but I'm getting the >
following error message
>"gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion >
`datalength<0x8000UL' failed."
Ouch, you hit a bug in libtiff. What you are trying to create is an absolutely
lar
Hi,
I'm trying to build overviews on a large vrt file, but I'm getting the
following error message
"gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion
`datalength<0x8000UL' failed."
Operating system ubuntu server 18.04
256 Gb memory
GDAL version 2.4
This is what I do:
- cr
Hi,
On Mageia we have an issue with gdalinfo (and some others scripts), during
build it creates a bash script instead of a real binary, I checked what is
going wrong but without success:
$ gdalinfo --version
/usr/bin/gdalinfo: error: '/usr/bin/.libs/gdalinfo' does not exist
Mageia7 and Mageia Ca
24 matches
Mail list logo
