[gdal-dev] Variable Tile Sizes

We have a custom tiling scheme (tilematrixset) for satellite imagery that varies tile widths as they move closer/farther from the equator. We do this for speed/efficiency reasons and the amount of error introduced is minimal over short distances and doesn't impat running CV algorithms. However,

Re: [gdal-dev] Testing the driver

Hi, It’s in debug mode, yes, as you suggested. yes, it crashes in the same way. Same big number. It crashes because of the variable is not read from the file (this variable should be 1). But debugging in windows (where not crashes) this variable is set when opening the layer, and then I

Re: [gdal-dev] Testing the driver

At #10 we can see the variable nNum set to a non-sense megabignumber. Is it on a -DCMAKE_BUILD_TYPE=Debug build ? Otherwise stack traces and variable content in the debugger might look like garbage because of optimizations. If it is a debug build, then there's likely some memory corruption

Re: [gdal-dev] Testing the driver

Hi, I think that I found the way to debug and the trace makes me ask a question that can be interesting to everybody who uses python and it's not an expert, like me. In my test I do: ds = gdal.OpenEx("data/miramon/Polygons/SimplePolygons/SimplePolFile.pol") lyr = ds.GetLayer(0) assert lyr is

Re: [gdal-dev] Motion: adopt RFC 99: Geometry coordinate precision

+0 KurtS. It seems like a good idea, but I worry about unintended consequences, but can't come up with any. On Thu, Mar 7, 2024 at 11:07 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > The flow of comments calming down, I motion to adopt RFC 99: Geometry > coordinate

[gdal-dev] Motion: adopt RFC 99: Geometry coordinate precision

Hi, The flow of comments calming down, I motion to adopt RFC 99: Geometry coordinate precision https://github.com/OSGeo/gdal/pull/9300 Pre-rendered view at https://github.com/rouault/gdal/blob/rfc99_text/doc/source/development/rfc/rfc99_geometry_coordinate_precision.rst Starting with my

Re: [gdal-dev] Renaming multiple layers when loading gpkg into postgis

Richard, Tried to google for this, but asking here: is it only possible to rename one layer per ogr2ogr call? (while it is possible to load several layers) Not with ogr2ogr If so I will make my scripts do the loading one by one, but just want to check. or using

[gdal-dev] Renaming multiple layers when loading gpkg into postgis

Hi, Loading a gpkg with multiple layers (from a zip) into Postgis is a breeze (all PG-stuff from env): ogr2ogr -overwrite -f PostgreSQL PG:"schemas=target" /vsizip//home/richard/data/data.zip/this.gpkg layer1 layer3 but now I want to rename those layers ogr2ogr -overwrite -f PostgreSQL

Re: [gdal-dev] gdalwarp different behavior for tif and netCDF files

I should also have added that original nc has data in Lat Lon, but is not actually stamped with EPSG:4326 SRS. Here is what I get from gdalinfo. (I used a tool called grdcut to create the sample, but the behaviour is same This is what gdalinfo shows on original nc file from which I created a

[gdal-dev] gdalwarp different behavior for tif and netCDF files

I am trying to reproject a netCDF file which is in Lat Lon (EPSG:4326) projection to EPSG:3857 (Google mercator) (on GDAL 3.4.3, released 2022/04/22). If I reproject to a tif file, it is reprojected correctly. If I reproject to a nc file it reproject incorrectly/different location that tif file. I

Re: [gdal-dev] Vagrant & VirtualBox

Even setting CPU to 6 it's extremly slow... Any recent experience on that from windows and vagrant + Virtual Box? Any other recomendation? De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dijous, 7 de març de 2024 16:30 Para: gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Vagrant &

Re: [gdal-dev] Vagrant & VirtualBox

Perhaps with that? Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| # specify memory size in MiB vm_ram = ENV['VAGRANT_VM_RAM'] || 4096 vm_cpu = ENV['VAGRANT_VM_CPU'] || 2 vm_ram_bytes = vm_ram * 1024 * 1024 De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dijous, 7

Re: [gdal-dev] Vagrant & VirtualBox

I see now that if I shutdown the machine and execute "vagrant up" again + "vagrant ssh" it login automatically. On the other hand cmake -build. is extremly slow. The is anyway to configure more CPU or memory to the process? De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el:

[gdal-dev] Vagrant & VirtualBox

Hi, in my seekness to find a friendly environment to compile and debug some of my tests I am trying now to use vagrant and a virtualBox. Setting up a development environment - GDAL documentation Once I have both installed I run from

Re: [gdal-dev] Creating NetCDF dataset with sub datasets

Hi, If your input dataset has multiple bands, each band will be written as a separate netCDF variable, and thus read as multiple subdatasets. The constraint is that as your input is a single raster, all bands must share the same georeferencing. If you want to write multiple independent

Re: [gdal-dev] Building on windows

Le 07/03/2024 à 09:41, Abel Pau via gdal-dev a écrit : Hi, I am a windows and VS2019 user anc C/C++ developer and I asked this question myself a long time ago. Finally the best way for me was: 1)Install vcpkg https://vcpkg.io/en/getting-started and install this on c:/dev/vcpkg. Follow

[gdal-dev] Creating NetCDF dataset with sub datasets

Hello, I just had my first encounter with a NetCDF file. GDAL opens that flawlessly, I can identify the subdatasets and open/read them thanks to the SUBDATASET_n_NAME, as advertised in https://gdal.org/drivers/raster/netcdf.html However, I am confused by the ability to create such a file

Re: [gdal-dev] Building on windows

Hi, I am a windows and VS2019 user anc C/C++ developer and I asked this question myself a long time ago. Finally the best way for me was: 1) Install vcpkg https://vcpkg.io/en/getting-started and install this on c:/dev/vcpkg. Follow their instructions. And then gdal instructions