Re: [gdal-dev] Esri REST PBF support

sert nicely into GDAL, but let's see... > > Even > Le 23/07/2025 à 00:04, Craig de Stigter via gdal-dev a écrit : > > Hi folks > > OGR has support for ESRI FeatureService endpoints via the ESRI JSON > <https://gdal.org/en/stable/drivers/vector/esrijson.html> drive

[gdal-dev] Esri REST PBF support

Hi folks OGR has support for ESRI FeatureService endpoints via the ESRI JSON driver. I am wondering if there would be interest in adding PBF support to that driver, so that we could ingest the more efficient PBF versions of those endpoints.

Re: [gdal-dev] GTI: override SRS of source tiles (disable reprojection)

Thanks for the replies. Using a FGB tile index without GTI/VRT unfortunately doesn't solve the problem since at some point the caller will still have to (pointlessly) transform the tiles, but thanks for the suggestion anyway. The VRT connection string sounds ideal; I hadn't seen that before. I had

[gdal-dev] GTI: override SRS of source tiles (disable reprojection)

Hi folks I'm working on converting an existing VRT mosaic pipeline to use GTI to improve its scalability with huge layers. A problem is that our individual raster tiles may have projections with subtly varying WKT, since they were often produced by customers using different tooling and in differe

Re: [gdal-dev] Adding external overviews for a VRT whose source tiles already have overviews

👍 Thanks :) On Wed, 17 Jul 2024 at 19:59, Craig de Stigter < craig.destig...@koordinates.com> wrote: > Hi folks > > I have a VRT which is a mosaic of several thousand s3-stored COGs. Doing > any kind of low-res downsampling from this VRT causes very slow performance >

[gdal-dev] Adding external overviews for a VRT whose source tiles already have overviews

Hi folks I have a VRT which is a mosaic of several thousand s3-stored COGs. Doing any kind of low-res downsampling from this VRT causes very slow performance and high memory usage because it causes requests to all the individual source tiles. I'd like to add external overviews to the VRT via a `.

Re: [gdal-dev] GDAL 3.9: How to pass negative flag values to GDALArgumentParser?

A colleague has noticed a workaround: prefix the argument with a space: $ gdalwarp '-dstnodata' ' -inf' ... On Tue, 2 Jul 2024 at 16:04, Craig de Stigter < craig.destig...@koordinates.com> wrote: > While trying to upgrade to GDAL 3.9 i'm hitting this error:

[gdal-dev] GDAL 3.9: How to pass negative flag values to GDALArgumentParser?

While trying to upgrade to GDAL 3.9 i'm hitting this error: $ gdalwarp '-dstnodata' '-inf' ... ERROR 1: Too few arguments for '-dstnodata'. ... The same happens with `gdalbuildvrt -vrtnodata '-1 -1 -1' ...` We use negative values for NODATA in a few places because they're unlikely to already be

[gdal-dev] WFS: How to use feature ordering?

Hey folks We're having a lot of trouble getting data out of a WFS server that doesn't have primary keys. (previous work on this) The URL that's causing us grief is this one: https://opendata.maps.vic.gov.au/geoserver/wfs?REQUEST=GetFeature&SERVICE=WFS&VE

[gdal-dev] Shapefile: Write alternative PRJ WKT format

Hi there We export data in a variety of coordinate systems and formats. Most formats work with most coordinate systems. However, the SHP driver always calls MorphToESRI() on its SRS objects before writing them as WKT to the PRJ files. I haven't been able to find information on why it does this.

[gdal-dev] Deciding whether to use WFS paging after opening the datasource

Hi folks We're having trouble with OGR trying to fetch a response from this WFS2 URL: https://geo.irceline.be/wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=realtime:pm25_24hmean_station&COUNT=100&STARTINDEX=0 The error from the server is Cannot do natural order without a primary

Re: [gdal-dev] VSI CIFS driver

_SYS_ADMIN: https://github.com/docker/for-linux/issues/321 - which defeats the purpose; we might as well just use `mount.cifs` at that point. We're going to switch back to looking into implementing a VSI driver for wrapping libsmb. On Mon, 16 Dec 2019 at 15:41, Craig de Stigter

Re: [gdal-dev] VSI CIFS driver

Sorry, that's `fusesmb`, not `smbfuse` On Mon, 16 Dec 2019 at 15:40, Craig de Stigter < craig.destig...@koordinates.com> wrote: > I haven't quite exhausted my frustration budget for this yet but here's > what I've found so far: > > >- `smbfuse` a

Re: [gdal-dev] VSI CIFS driver

's probably more straightforward to implement a VSI CIFS than a FUSE CIFS. On Sat, 14 Dec 2019 at 20:42, Craig de Stigter < craig.destig...@koordinates.com> wrote: > Thanks Even > > That sounds like a possible path forward, although it works for FUSE > filesystems only, so we'

Re: [gdal-dev] VSI CIFS driver

Thanks Even That sounds like a possible path forward, although it works for FUSE filesystems only, so we'd have to find a good FUSE implementation of CIFS (currently we're using the kernel provided cifs) If anyone can recommend a well-maintained FUSE CIFS implementation I'd gladly look into it. A

[gdal-dev] VSI CIFS driver

Hey folks! We have to access some customer data via their CIFS shares on a regular basis. To date we have been doing it via a setuid script which mounts and unmounts the CIFS share locally, then treats the files as local. We're containerising our workers, and using kernel mounts is no longer poss

[gdal-dev] Python IOError during file object destructor

Hey there We're using the python bindings to do all sorts of translates and warps and things, and I don't have a proper traceback but we got this in some of our processes lately: Exit code: 0 stderr: ... close failed in file object destructor: IOError: [Errno 5] Input/output error

[gdal-dev] Vagrant build environment

Hi folks I sat down to finish off a pull request I started months ago, and realised that GDAL's vagrant build no longer works. It fails quite early in provisioning. I think this is probably because Ubuntu 14.04 is no longer in upstream support, and the ubuntugis PPA has stopped supplying packages

Re: [gdal-dev] ubuntu_1804

strap) inside the travis Trusty environment. It's not terribly elegant but gets the job done. So the kernel is the travis trusty kernel but the userland is ubuntu 18.04. Hope that clarifies things. Craig de Stigter On Fri, 25 Jan 2019, 12:34 Alan Stewart, wrote: > The raw log for the ubunt

Re: [gdal-dev] Motion: adopt RFC 72: Run tests with pytest

11 Dec 2018 at 13:07 Craig de Stigter < craig.destig...@koordinates.com> wrote: > Thanks for the votes and kind words :) > > I'd applied Kurt's super-minor wording suggestions but haven't added any > new sections (on fiona, extra examples, etc) yet. I'll try an

Re: [gdal-dev] Motion: adopt RFC 72: Run tests with pytest

ward >> >> >> On 12/9/18 9:48 PM, Kurt Schwehr wrote: >> > I haven't had a chance to read the RFC yet, so I can't yet vote. >> However, >> > a huge thank you to Craig and everyone else who put in effort to make >> this >> > happen! &

Re: [gdal-dev] Motion: adopt RFC 72: Run tests with pytest

l/963/commits/8db599e7bc08b7dc73d81591898ed0f5f4243a58 I didn't see any way to use `pytest_make_parametrize_id` really; IDs rightly vary enough between tests that I can't see that hook being very useful here. Cheers Craig de Stigter On Mon, 10 Dec 2018 at 09:59 jratike80 wrote: > +0 > > -Jukka Rahkonen- &g

[gdal-dev] Motion: adopt RFC 72: Run tests with pytest

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

Re: [gdal-dev] Call for discussion on RFC 72: Update autotest suite to use pytest

y gdal-bin program or adding checker fixtures that make > multiple asserts patterns that will help or hurt long term? I'm not super > concerned, just want to point out that pytest isn't a panacea and doesn't > default to the golden path of testing. > > Thanks

[gdal-dev] Call for discussion on RFC 72: Update autotest suite to use pytest

productivity gains for writing, reading and debugging python tests, compared with the current home-grown approach. -- Please submit feedback soon, as we'd like to have this merged in time for the imminent GDAL 2.4.0 RC if possible. Thanks Craig de St

Re: [gdal-dev] Refactoring the test suite with pytest

I posted the link earlier in the thread, but to clarify: https://github.com/OSGeo/gdal/pull/963 On Fri, 26 Oct 2018 at 14:54 Craig de Stigter < craig.destig...@koordinates.com> wrote: > My work on this branch is starting to wind down. There's still a few test > failures to co

Re: [gdal-dev] Refactoring the test suite with pytest

ption is reasonably useful to describe what I've been up to, but please ask questions if you have them, or comment/review on the PR itself. Thanks Craig de Stigter On Fri, 5 Oct 2018 at 22:50 Kurt Schwehr wrote: > The python tests in autotest2 are pretty much a subset of GDAL's > a

Re: [gdal-dev] Refactoring the test suite with pytest

I've got some initial steps toward this work at https://github.com/OSGeo/gdal/pull/963 It doesn't have any of the automated conversion yet but I've added a todo list and am hoping to have something semi-useful running in CI soon. On Tue, 2 Oct 2018 at 22:04 Craig de Stigter

Re: [gdal-dev] Refactoring the test suite with pytest

ppy to contribute any or all of the code to > the GDAL tree under the GDAL license. > > On Mon, Oct 1, 2018 at 3:32 PM Craig de Stigter < > craig.destig...@koordinates.com> wrote: > >> Hi folks >> >> I've been looking at a potential large change to the

[gdal-dev] Refactoring the test suite with pytest

alphabetical name order within a given module. It appears to me that some of GDAL's tests are *not* independent of each other within the same module. However, most are already in alphabetical name order, so I don't believe this is a problem; we are not worse off with pytest than p

Re: [gdal-dev] vsicurl configuration design decisions

Hi folks We're slightly invested in this because we use VSI paths reasonably heavily, though not so much for cloud services yet. > One downside is that you need to URLEncode the URL, which can make it > painful when composing it at hand. True, but that does eliminate ambiguity in the URL, and

Re: [gdal-dev] cubic / bilinear resampling with gdalwarp looks similar to nearest neighbour

methods much slower, though its questionable whether anyone would complain given that the quality of current output is so poor... Thanks for your help Craig de Stigter On Thu, Sep 30, 2010 at 12:30 PM, Seth Price wrote: > The only way to 'force' it is to use cubicspline or lanczos

Re: [gdal-dev] cubic / bilinear resampling with gdalwarp looks similar to nearest neighbour

even forcing cubic to notice all of the 5x5 pixels would still be faster. Regards Craig de Stigter On Thu, Sep 30, 2010 at 10:34 AM, Even Rouault wrote: > Craig, > > The main reason is that you are using gdalwarp to reduce an image by a > large > factor and not reproject it, which

[gdal-dev] cubic / bilinear resampling with gdalwarp looks similar to nearest neighbour

Hi folks I filed this bug <http://trac.osgeo.org/gdal/ticket/3740> on gdal a few weeks back and haven't heard anything since. Would someone mind taking a look at it? Thanks Craig de Stigter -- Koordinates Ltd PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Fa