Re: [gdal-dev] georeferenced but not georeferenced?

[Matt.Wilkie]

Thank you Even, especially for highlighting a DEM should be used. I 'knew' that 
but hadn't taken the time to fully ingest the meaning. It's drastically changed 
how I'm approaching this project.

-Matt

From: Even Rouault 
Sent: November 10, 2021 2:16 PM
To: Matt.Wilkie ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] georeferenced but not georeferenced?

Le 10/11/2021 à 22:03, matt.wil...@yukon.ca a 
écrit :

Hi all,



I'm creating images from SPOT6/7 archive DIMAP format. The resulting images 
display in the correct position in the world when combined with other sources, 
however all the usual tools say the images have no georeferencing.



* If the images have no georeferencing how do ArcMap/Pro and Qgis know to put 
them in the right place?

Those images have RPC. You can see RPC information with gdalinfo in the "RPC 
Metadata" section

listeo/geotiffcp and a number of utilities are not RPC aware. But gdalwarp is.



* How can I convert whatever-this-is into proper georeferencing so that other 
tools know how to handle them too?
You can use gdalwarp to orthorectify them.  You should generally specify -to 
RPC_DEM=some_dem_with_elevation_as_ellipsoidal_heights or -to 
RPC_HEIGHT=ellipsoidal_height. See 
https://gdal.org/api/gdal_alg.html?highlight=rpc_dem




Attached is a sample image.  It was created with (on one line):



gdal_translate  -outsize 100 0

-co compress=zstd -co predictor=yes -co level=17 -co bigtiff=yes -of cog

.\path\to\IMG_SPOT6_MS_001_A\DIM_SPOT6_MS_201609082010410_SEN_1.XML

source_tiny.tif



The biggest problem this causes me at the moment is that gdal_pansharpen.py 
output does not have any kind of goereferencing, and I can't use old faithfuls 
like listgeo, geotiffcp, or gdalcopyproj.py to copy the coordinate system 
across.



thanks in advance for your thoughts,



Matt Wilkie

Geomatics Developer & Administrator

Environment | Technology, Innovation and Mapping

T 867-667-8133 | Yukon.ca

Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away.



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

[Even Rouault]

Hi,

(writing to both GDAL and GRASS lists)

Working on the transition to CMake as the GDAL build system, the 
particular status of the GRASS driver in GDAL raised my attention.


(The following is based on my understanding. It has been ages since I 
didn't try this...)


This driver is a bit odd in the sense that there's a cyclic dependency 
to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs 
to be linked against GRASS.


So the usual procedure is:

- build GDAL without the GRASS driver

- build GRASS against GDAL

- build the GDAL GRASS driver from the separate gdal-grass tarball that 
GDAL distributes along its main tarball.


With the current GDAL autoconf build system, there's also the 
possibility to rebuild GDAL with the GRASS driver builtin in libgdal, 
but that's a bit odd, since you need to make sure that this new libgdal 
is the one that GRASS will link against at runtime, otherwise chaos will 
ensure. I'm not sure if that's used. This is typically something I would 
*not* want to support in the new GDAL cmake build.


All in all, given the particular nature of that driver, I believe it 
would be better in a dedicated repository, with its standalone build 
scripts, whose initial version could be just the ones of 
https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg, or evolve to 
CMake or whatever the maintainers of that driver would prefer. I believe 
this would make the situation clearer.


Opinions ? and people interested in setting up that dedicated repository ?

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Rahkonen Jukka (MML)]

Hi,

I have no experience on 32 bit images but play with gdaladdo and compression 
options and report what you find. External overviews (-ro) are handy for 
testing because you can simply rename or delete the .ovr file and make new run 
with other options. External overviews take some more space than it takes to 
add internal overviews into TIFF but best option as external should be best as 
internal too.

-Jukka Rahkonen-

Lähettäjä: Duarte Carreira 
Lähetetty: torstai 18. marraskuuta 2021 18.30
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with 
LERC_DEFLATE

Well, it didn't even occur to me to compress the overviews with translate...
I was expecting a bit more compressing from lerc...

About tif 32bit, what compression do you think would yield better ratios?

Thanks.

Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 escreveu no dia quinta, 18/11/2021 à(s) 12:41:
Hi,

I made some tests with an 8 bit RGB image.
First observation was that gdaladdo supports lerc_deflate (even it is not 
documented), but it does not support “MAX_Z_ERROR”. This yields same sized ovr 
file with or without max_z_error.
gdaladdo -ro lerc_def2.tif --config compress_overview lerc_deflate --config 
MAX_Z_ERROR 10

Another observation was that this option would really save some disk space. I 
compressed the lossless ovr file with gdal_translate by using -co 
max_z_error=10 and file sizes were:

source tiff: 432 072 372 bytes
lecr_deflate cog without overviews: 311 258 085 bytes

lossless lerc_deflate overviews: 118 954 009 bytes
lerc_deflare overviews with z_error=10: 52 400 583 bytes

For comparison even not relevant to original question about 32 bit data
jpeg-ycbcr overviews with default quality: 14 481 967 bytes

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Duarte Carreira
Lähetetty: torstai 18. marraskuuta 2021 13.45
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE and it 
works. But I'm trying to set the precision loss and get better compression, 
since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed with 
LERC_DEFLATE?

More context:
My reasoning is to compress losslessly the dem with deflate predictor 3, and 
then compress "lossly"  the overviews with lerc_deflate.
Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Duarte Carreira]

Hi Even. I created a ticket:
https://github.com/OSGeo/gdal/issues/4848

Thanks.

>We would need a MAX_Z_ERROR_OVERVIEW config option for that. Please >file an
enhancement ticket
>
>Even

>Le 18/11/2021 à 12:44, Duarte Carreira a écrit :
>>* Hi there.
** I am looking into compressing overviews for a DEM, with LERC_DEFLATE
*>>* and it works. But I'm trying to set the precision loss and get better
*>>* compression, since for overviews I don't really care that much.
*>>* Ok, so the question is how to set the MAX_Z_ERROR for overviews
*>>* compressed with LERC_DEFLATE?
** More context:
*>>* My reasoning is to compress losslessly the dem with deflate predictor
*>>* 3, and then compress "lossly"  the overviews with lerc_deflate.
*>>* Since this is 32bit dataset, I can't use jpeg on the overviews.
** Thanks in advance.
*>>* Duarte*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Duarte Carreira]

Well, it didn't even occur to me to compress the overviews with translate...
I was expecting a bit more compressing from lerc...

About tif 32bit, what compression do you think would yield better ratios?

Thanks.

Rahkonen Jukka (MML)  escreveu no dia
quinta, 18/11/2021 à(s) 12:41:

> Hi,
>
>
>
> I made some tests with an 8 bit RGB image.
>
> First observation was that gdaladdo supports lerc_deflate (even it is not
> documented), but it does not support “MAX_Z_ERROR”. This yields same sized
> ovr file with or without max_z_error.
>
> gdaladdo -ro lerc_def2.tif --config compress_overview lerc_deflate
> --config MAX_Z_ERROR 10
>
>
>
> Another observation was that this option would really save some disk
> space. I compressed the lossless ovr file with gdal_translate by using -co
> max_z_error=10 and file sizes were:
>
>
>
> source tiff: 432 072 372 bytes
>
> lecr_deflate cog without overviews: 311 258 085 bytes
>
>
>
> lossless lerc_deflate overviews: 118 954 009 bytes
>
> lerc_deflare overviews with z_error=10: 52 400 583 bytes
>
>
>
> For comparison even not relevant to original question about 32 bit data
>
> jpeg-ycbcr overviews with default quality: 14 481 967 bytes
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Duarte
> Carreira
> *Lähetetty:* torstai 18. marraskuuta 2021 13.45
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] setting MAX_Z_ERROR on overviews compressed with
> LERC_DEFLATE
>
>
>
> Hi there.
>
>
>
> I am looking into compressing overviews for a DEM, with LERC_DEFLATE and
> it works. But I'm trying to set the precision loss and get better
> compression, since for overviews I don't really care that much.
>
> Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed
> with LERC_DEFLATE?
>
>
>
> More context:
>
> My reasoning is to compress losslessly the dem with deflate predictor 3,
> and then compress "lossly"  the overviews with lerc_deflate.
>
> Since this is 32bit dataset, I can't use jpeg on the overviews.
>
>
>
> Thanks in advance.
>
> Duarte
>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr, perform queries to obtain values from the database

[Rahkonen Jukka (MML)]

Hi,

I would suggest to consider other options first.


  *   Use OGR foreign data wrapper https://github.com/pramsey/pgsql-ogr-fdw and 
make the shapefile to appear as a PostGIS table. The you can make the JOIN in 
your PostGIS.
  *   Add both the shapefile and the classification table from PostgreSQL into 
GeoPackage or SpatiaLite database as separate tables and update the coded 
values into definition string with SQL locally.


If you really want to join shapefile and PostgreSQL tables directly with GDAL 
and ogr2ogr I believe the only way is to write a vector VRT file 
https://gdal.org/drivers/vector/vrt.html#vector-vrt  that makes those two to 
appear as two layers in one datasource. The result is actually logically rather 
similar than by using foreign data wrappers on the PostgreSQL side.

If I would need to do the task just once I would take the GeoPackage road but I 
have done that before and my view is therefore certainly biased.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Andrés Nadal
Lähetetty: torstai 18. marraskuuta 2021 16.50
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr, perform queries to obtain values from the database

Hello.

Excuse me my English, it's not my native language.

I need to convert the names (string) of classes, in some fields of a Shapefile, 
to the respective numerical values of the database.

In some cases, the fields have up to 3 different classes, for different rows.

CLASS A = 1
CLASS B = 2
CLASS B = 3

The destination table, this already exists, and contains many other fields, 
this using ogr2ogr.exe, from Windows CMD.

How to indicate to ogr2ogr.exe, which performs a query first, to obtain the 
numerical value of the ' CLASS B', from PostGIS.

In this way insert the value 2 in the table.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ogr2ogr, perform queries to obtain values from the database

[Andrés Nadal]

Hello.

Excuse me my English, it's not my native language.

I need to convert the names (string) of classes, in some fields of a
Shapefile, to the respective numerical values of the database.

In some cases, the fields have up to 3 different classes, for different
rows.

CLASS A = 1
CLASS B = 2
CLASS B = 3

The destination table, this already exists, and contains many other fields,
this using ogr2ogr.exe, from Windows CMD.

How to indicate to ogr2ogr.exe, which performs a query first, to obtain the
numerical value of the ' CLASS B', from PostGIS.

In this way insert the value 2 in the table.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Black borders after reprojection GDAL_WARP

[Even Rouault]

Black borders are completely expected: reprojection changes the geometry 
of the image.


That said, if the area of interest is sufficiently small and the 
geometry change being approximatively an affine transformation, you can 
try https://gdal.org/programs/gdalmove.html instead of gdalwarp to only 
alter the georeferencing information and not touch pixel values at all.


Even

Le 18/11/2021 à 15:34, Lorenzo Di Giacomo a écrit :
Hi Carl, thanks for your reply, i noticed that it happens even if i 
just reproject the image, without cutting.
Of course the dstalpha works, but it increases the size of the image 
and it changes its nature (adding another band) since this operation 
is an intermediate operation the resulting image can't be different 
from the original, just reporojected.




Il giorno gio 18 nov 2021 alle ore 14:11 Carl Godkin 
mailto:cgod...@gmail.com>> ha scritto:


 Hi Lorenzo,

I have faced this and there are two things to consider.

First, you can specify the georeferenced extents _and_ the SRS  of
the extents using something like this:

    gdalwarp -t_srs EPSG:3857 \
        -te_srs EPSG:4326 -te -109 32 -102 36 \
        input.tif output.tif

Note that I'm warping to one coordinate system but trimming based
on another one.  Is it possible that your black boundary is due to
trimming in the wrong coordinate system?  For instance, if your
input map is projected but the boundary of the map consists of
parallels of latitude or meridians of longitude, then you could
use something like the above.  (You can actually get even fancier
by trimming with polygons too; see this example for inspiration:

https://gis.stackexchange.com/questions/45053/gdalwarp-cutline-along-with-shapefile


.)

Second, recognize that the output will always be a rectangle in
the output SRS.  If the black border is due to "no data" areas
outside the input map's extent appearing in the output map, then
you can use -dstalpha ("Create an output alpha band to identify
nodata (unset/transparent) pixels.") to mark the output pixels
that shouldn't be part of the map.  Basically your black pixels
become transparent in this case.

I hope that helps,
carl


On Wed, Nov 17, 2021 at 8:11 AM Lorenzo Di Giacomo
mailto:loridi...@gmail.com>> wrote:

Hi all, i have a question, how is it possible to avoid black
borders after reprojection with "gdal_warp" ?
Basically i have an image that is little rotated, when i
reprojected from 32632 to 4326 the resulting image has black
borders more or less tight depending on the rotation.
I saw i can change the colors of those no_data (using
-dstnodata) but how can i do if i dont want it at all? Adding
another band result in a size increase, that i don't want either.

Thanks !!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Even Rouault]

We would need a MAX_Z_ERROR_OVERVIEW config option for that. Please file 
an enhancement ticket


Even

Le 18/11/2021 à 12:44, Duarte Carreira a écrit :

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE 
and it works. But I'm trying to set the precision loss and get better 
compression, since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews 
compressed with LERC_DEFLATE?


More context:
My reasoning is to compress losslessly the dem with deflate predictor 
3, and then compress "lossly"  the overviews with lerc_deflate.

Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Black borders after reprojection GDAL_WARP

[Lorenzo Di Giacomo]

Hi Carl, thanks for your reply, i noticed that it happens even if i just
reproject the image, without cutting.
Of course the dstalpha works, but it increases the size of the image and it
changes its nature (adding another band) since this operation is an
intermediate operation the resulting image can't be different from the
original, just reporojected.



Il giorno gio 18 nov 2021 alle ore 14:11 Carl Godkin  ha
scritto:

>  Hi Lorenzo,
>
> I have faced this and there are two things to consider.
>
> First, you can specify the georeferenced extents _and_ the SRS  of the
> extents using something like this:
>
> gdalwarp -t_srs EPSG:3857 \
> -te_srs EPSG:4326 -te -109 32 -102 36 \
> input.tif output.tif
>
> Note that I'm warping to one coordinate system but trimming based on
> another one.  Is it possible that your black boundary is due to trimming in
> the wrong coordinate system?  For instance, if your input map is projected
> but the boundary of the map consists of parallels of latitude or
> meridians of longitude, then you could use something like the above.  (You
> can actually get even fancier by trimming with polygons too; see this
> example for inspiration:
> https://gis.stackexchange.com/questions/45053/gdalwarp-cutline-along-with-shapefile
> .)
>
> Second, recognize that the output will always be a rectangle in the output
> SRS.  If the black border is due to "no data" areas outside the input map's
> extent appearing in the output map, then you can use -dstalpha ("Create an
> output alpha band to identify nodata (unset/transparent) pixels.") to mark
> the output pixels that shouldn't be part of the map.  Basically your black
> pixels become transparent in this case.
>
> I hope that helps,
> carl
>
>
> On Wed, Nov 17, 2021 at 8:11 AM Lorenzo Di Giacomo 
> wrote:
>
>> Hi all, i have a question, how is it possible to avoid black borders
>> after reprojection with "gdal_warp" ?
>> Basically i have an image that is little rotated, when i reprojected from
>> 32632 to 4326 the resulting image has black borders more or less tight
>> depending on the rotation.
>> I saw i can change the colors of those no_data (using -dstnodata) but
>> how can i do if i dont want it at all? Adding another band result in a size
>> increase, that i don't want either.
>>
>> Thanks !!
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Black borders after reprojection GDAL_WARP

[Carl Godkin]

 Hi Lorenzo,

I have faced this and there are two things to consider.

First, you can specify the georeferenced extents _and_ the SRS  of the
extents using something like this:

gdalwarp -t_srs EPSG:3857 \
-te_srs EPSG:4326 -te -109 32 -102 36 \
input.tif output.tif

Note that I'm warping to one coordinate system but trimming based on
another one.  Is it possible that your black boundary is due to trimming in
the wrong coordinate system?  For instance, if your input map is projected
but the boundary of the map consists of parallels of latitude or
meridians of longitude, then you could use something like the above.  (You
can actually get even fancier by trimming with polygons too; see this
example for inspiration:
https://gis.stackexchange.com/questions/45053/gdalwarp-cutline-along-with-shapefile
.)

Second, recognize that the output will always be a rectangle in the output
SRS.  If the black border is due to "no data" areas outside the input map's
extent appearing in the output map, then you can use -dstalpha ("Create an
output alpha band to identify nodata (unset/transparent) pixels.") to mark
the output pixels that shouldn't be part of the map.  Basically your black
pixels become transparent in this case.

I hope that helps,
carl


On Wed, Nov 17, 2021 at 8:11 AM Lorenzo Di Giacomo 
wrote:

> Hi all, i have a question, how is it possible to avoid black borders after
> reprojection with "gdal_warp" ?
> Basically i have an image that is little rotated, when i reprojected from
> 32632 to 4326 the resulting image has black borders more or less tight
> depending on the rotation.
> I saw i can change the colors of those no_data (using -dstnodata) but how
> can i do if i dont want it at all? Adding another band result in a size
> increase, that i don't want either.
>
> Thanks !!
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Rahkonen Jukka (MML)]

Hi,

I made some tests with an 8 bit RGB image.
First observation was that gdaladdo supports lerc_deflate (even it is not 
documented), but it does not support “MAX_Z_ERROR”. This yields same sized ovr 
file with or without max_z_error.
gdaladdo -ro lerc_def2.tif --config compress_overview lerc_deflate --config 
MAX_Z_ERROR 10

Another observation was that this option would really save some disk space. I 
compressed the lossless ovr file with gdal_translate by using -co 
max_z_error=10 and file sizes were:

source tiff: 432 072 372 bytes
lecr_deflate cog without overviews: 311 258 085 bytes

lossless lerc_deflate overviews: 118 954 009 bytes
lerc_deflare overviews with z_error=10: 52 400 583 bytes

For comparison even not relevant to original question about 32 bit data
jpeg-ycbcr overviews with default quality: 14 481 967 bytes

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Duarte Carreira
Lähetetty: torstai 18. marraskuuta 2021 13.45
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE and it 
works. But I'm trying to set the precision loss and get better compression, 
since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed with 
LERC_DEFLATE?

More context:
My reasoning is to compress losslessly the dem with deflate predictor 3, and 
then compress "lossly"  the overviews with lerc_deflate.
Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

[Duarte Carreira]

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE and it
works. But I'm trying to set the precision loss and get better compression,
since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed
with LERC_DEFLATE?

More context:
My reasoning is to compress losslessly the dem with deflate predictor 3,
and then compress "lossly"  the overviews with lerc_deflate.
Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDALWMS - error: TCP connection reset by peer

[Rahkonen Jukka (MML)]

Hi,

It seems that the WMS server is closing the door and there is nothing else to 
do on the GDAL side except to try again later. Contact the WMS service 
maintainer and report your troubles. They may be able to provide you a more 
reliable service especially if you are ready to pay for it.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Roman 
Breitfuss-Schiffer
Lähetetty: torstai 18. marraskuuta 2021 11.59
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GDALWMS - error: TCP connection reset by peer


Dear all!

We are running a Python application an a linux distribution (RedHat) which 
creates clips in MBTILES format from a WMS. We are using the Python-API and are 
basically doing something like this:

src_ds = gdal.Warp(
tmp_file,
ds_in,
format='GTiff',
outputBounds=[bbox[0], bbox[2], bbox[1], bbox[3]],
dstSRS=output_srs,
)
ds_out = gdal.Translate(
out_filepath,
src_ds,
format='MBTILES',
creationOptions=creation_options,
)

The application throughs an error from time to time since a few days. We 
couldn't figure out a pattern yet and therefore we are also not able to 
reproduce the error. The error is the following:

Mon Nov 15 13:48:13 2021: CPLError: GDALWMS: Unable to download block 2765, 602.
URL: TCP connection reset by peer
  HTTP status code: 0, error: TCP connection reset by peer.
Add the HTTP status code to  to ignore this error (see 
http://www.gdal.org/frmt_wms.html).
Mon Nov 15 13:48:13 2021: CPLError: /wms_xml/wms_config.xml, band 1: IReadBlock 
failed at X offset 2764, Y offset 601
Mon Nov 15 13:48:13 2021: CPLError: GetBlockRef failed at X block offset 2764, 
Y block offset 601

The exact same data gets processed successfully in one run and not successfully 
in another run. We didn't change the code nor the Python or GDAL version. 
Hence, we are kind of puzzled as the error comes and goes seemingly at random.

Does anyone of you have any hints?

Thanks & best regards!
Roman

___

Dipl.-Ing. Roman Breitfuss-Schiffer, MSc. (GIS)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDALWMS - error: TCP connection reset by peer

[Roman Breitfuss-Schiffer]

Dear all!

We are running a Python application an a linux distribution (RedHat) 
which creates clips in MBTILES format from a WMS. We are using the 
Python-API and are basically doing something like this:


src_ds = gdal.Warp(
    tmp_file,
    ds_in,
    format='GTiff',
    outputBounds=[bbox[0], bbox[2], bbox[1], bbox[3]],
    dstSRS=output_srs,
)
ds_out = gdal.Translate(
    out_filepath,
    src_ds,
    format='MBTILES',
    creationOptions=creation_options,
)

The application throughs an error from time to time since a few days. We 
couldn't figure out a pattern yet and therefore we are also not able to 
reproduce the error. The error is the following:


Mon Nov 15 13:48:13 2021: CPLError: GDALWMS: Unable to download block 
2765, 602.

URL: TCP connection reset by peer
  HTTP status code: 0, error: TCP connection reset by peer.
Add the HTTP status code to  to ignore this error 
(see http://www.gdal.org/frmt_wms.html).
Mon Nov 15 13:48:13 2021: CPLError: /wms_xml/wms_config.xml, band 1: 
IReadBlock failed at X offset 2764, Y offset 601
Mon Nov 15 13:48:13 2021: CPLError: GetBlockRef failed at X block offset 
2764, Y block offset 601


The exact same data gets processed successfully in one run and not 
successfully in another run. We didn't change the code nor the Python or 
GDAL version. Hence, we are kind of puzzled as the error comes and goes 
seemingly at random.


Does anyone of you have any hints?

Thanks & best regards!
Roman

___
Dipl.-Ing. Roman Breitfuss-Schiffer, MSc. (GIS)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev