Re: [gdal-dev] JPEG file with ESRI world file .jpgw but geotransform not established

Hi Even, On Mon, Jan 27, 2020 at 1:45 AM Even Rouault wrote: > Hi Markus, > > I've found some doc about this .jgwx in > http://resources.arcgis.com/en/help/main/10.1/index.html#//009t002800 > So this is a ESRI specific thing > """Starting at ArcGIS 9.2 SP2, if the transformation cannot be

Re: [gdal-dev] OPeNDAP support with libdap

On lundi 27 janvier 2020 22:09:35 CET celati Laurent wrote: > Good evening, > > Could you unsubscribe me from the list please? You can do it yourself. See the bottom-most text entry at https://lists.osgeo.org/mailman/listinfo/gdal-dev Even -- Spatialys - Geospatial professional services http:/

Re: [gdal-dev] OPeNDAP support with libdap

> which GDAL version includes the DODS driver (libdap)? > We need to query the NOAA GrADS Data Server for GFS data with c#. Debian/Ubuntu builds or the Docker "osgeo/gdal" (ubuntu-full) image at https://github.com/OSGeo/gdal/tree/master/gdal/docker have the DODS driver built. But you'll have to b

Re: [gdal-dev] OPeNDAP support with libdap

Good evening, Could you unsubscribe me from the list please? Thanks a lot. Le lun. 27 janv. 2020 à 21:55, Wilco K a écrit : > Any suggestions? > > -- > *Van:* Wilco K > *Verzonden:* donderdag 23 januari 2020 17:36 > *Aan:* gdal-dev@lists.osgeo.org > *Onderwerp:* OP

Re: [gdal-dev] OPeNDAP support with libdap

Any suggestions? Van: Wilco K Verzonden: donderdag 23 januari 2020 17:36 Aan: gdal-dev@lists.osgeo.org Onderwerp: OPeNDAP support with libdap LS, which GDAL version includes the DODS driver (libdap)? We need to query the NOAA GrADS Data Server for GFS data with

Re: [gdal-dev] Recommended process for running a intersect test between a raster and a simple vector

So If I have X,Y, Z numbers how do I select just that tile like mapserver does? On Tue, Jan 14, 2020 at 10:09 PM Patrick Young < patrick.mckendree.yo...@gmail.com> wrote: > One trick I like regarding accessing overview levels is to use the open > option to snag a handle direct to the overview le

Re: [gdal-dev] mosaicking is very slow

Hi, You can read considerations about memory from https://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#WillincreasingRAMincreasethespeedofgdalwarp My guess it that increasing CACHEMAX might help a bit in this use case because it feels similar to the example that is used in the user doc "This cou

Re: [gdal-dev] mosaicking is very slow

Hi, Yes, you can change the tile size. It is documented in https://gdal.org/drivers/raster/gtiff.html, BLOCKXSIZE and BLOCKYSIZE. Make a controlled test and measure timings. Optimizing one thing may lead to something suboptimal in another place and what is optimal for me does not need to be op

Re: [gdal-dev] Why GTModelTypeGeoKey in EPSG:3857 GeoTIFF is User-Defined?

Hi Jukka, Thanks for raising this. This is a unfortunate regression of GDAL 3.0 due to RFC 73 / PROJ 6 integration. It decided to use the GEOTIFF_KEYS_FLAVOR=ESRI_PE code path whereas it shouldn't have too. I've just fixed this in master and 3.0 branches so that it writes the way it did in 2.4.

Re: [gdal-dev] mosaicking is very slow

Hi, Okay, thank you. By the way, while making copy of gtiffs, is not it good idea to increase GDAL_CACHEMAX? Simon ‐‐‐ Original Message ‐‐‐ On Monday, January 27, 2020 9:04 PM, Rahkonen Jukka (MML) wrote: > Hi, > > If your source images are 4 GB then their size is at least 4 by 40

Re: [gdal-dev] mosaicking is very slow

hi, thanks for nicely explaining. Can i change size of tile, 256*256; for speeding up? ‐‐‐ Original Message ‐‐‐ On Monday, January 27, 2020 9:04 PM, Rahkonen Jukka (MML) wrote: > Hi, > > If your source images are 4 GB then their size is at least 4 by 4 > pixels, or more if the

[gdal-dev] Why GTModelTypeGeoKey in EPSG:3857 GeoTIFF is User-Defined?

Hi, See more details from this Geoserver issue https://osgeo-org.atlassian.net/browse/GEOS-9475. The core is that when GDAL writes a GeoTIFF in EPSG:3857 is sets this tag: GTModelTypeGeoKey (Short,1): User-Defined Geoserver is awaiting GTModelTypeGeoKey (Short,1): ModelTypeProjected Is there so

Re: [gdal-dev] mosaicking is very slow

Hi, If your source images are 4 GB then their size is at least 4 by 4 pixels, or more if they are compressed. If gdalwarp now needs 256*256 pixels worth of source data, from a striped image it must read 256*4 (rows*pixels per row), while from tiled source it can read just from 1 to

Re: [gdal-dev] mosaicking is very slow

Hi, Thanks for your answer. The source images are not tiled. So, how can I tile them? Is not it additional load? I will try removing these ones: --config GDAL_CACHEMAX 8000 -co TILED=YES ‐‐‐ Original Message ‐‐‐ On Monday, January 27, 2020 7:48 PM, jratike80 wrote: > Hi, > > I would su

Re: [gdal-dev] mosaicking is very slow

Hi, I would suggest to remove --config GDAL_CACHEMAX 8000 first. Then I would check if the source images are tiled. If they are not it could be worth an extra step to make tiled copies. -Jukka Rahkonen- Simon-4 wrote > Hello everyone, > > I am stiching aroung 100 geotiff images each of around

[gdal-dev] mosaicking is very slow

Hello everyone, I am stiching aroung 100 geotiff images each of around 4gb. However, translating the vrt file into geotiff is going on for days. gtranslate --config GDAL_CACHEMAX 8000 -co TILED=YES -co COMPRESS=LZW -co BIGTIFF=YES infile.vrt outfile.tif How can I speed up it? Thank you. Simon__