Re: [gdal-dev] Call for discussion on RFC 92 text: WKB Only geometries
This RFC seems to have some things in common with the direct access to compressed raster blocks. Both by-pass the older raster and vector data models, yes? And they're quite specific to certain formats. Do you anticipate that GDAL and OGR will continue to develop more specialty APIs in addition to the general ones? I have no preconceived ideas. I'd say that specialized API have their place when they bring enough value, and don't do that at the cost of complicating things that don't benefit from them. RFC 92 just doesn't pass my own criteria (my vote for it would be 0 in its current state, but maybe someone will want to restart from it and give it a second life). Even On Sat, Feb 4, 2023, 11:55 AM Even Rouault wrote: Hi Sean, but wouldn't it be possible for all OGRFeatures to carry WKB data by default and add a method to provide it to callers? My understanding of what you propose would involve massive code rewrites in all drivers and wouldn't be desirable from a performance point of view, because most drivers can't generate WKB easily (PostGIS and GPKG are the exceptions rather the norm). So either all other drivers should be modified to compose WKB at hand (massive coding effort. Probably several weeks of effort and significant risk of regressions). Or get it from the ExportToWkb() method of the OGRGeometry instance they currently build, but then you pay the price in memory and CPU time to generate WKB that might not be consumed by users. | And only construct an OGRGeometry when it's asked for? Such as when GetGeometryRef is called? Good point, we could both make GetGeometryRef() and GetGeomFieldRef() virtual methods whose default implementation would be the same as currently, ie. return the value of the corresponding member variable in the base OGRFeature class stored with SetGeometry[Directly]()/SetGeomField[Directly]() And add a new virtual method: virtual GByte* OGRFeature::GetWKBGeometry(int iGeomField, size_t* pnOutSize) const whose default implementation would just use GetGeomFieldRef(iGeomField)->ExportToWkb(). The few drivers that can provide a more efficient implementation (GPKG typically) would create a derived class OGRFeatureGPKG with a specific implementation of those new virtual methods to avoid systematic OGRGeometry instantiation. The only drawback I see is that making GetGeometryRef() and GetGeomFieldRef() virtual would have a slight performance impact, but probably small enough. But fundamentally I'm wondering if RFC 92 hasn't been made mostly out fashioned now that we have RFC 86. RFC 86 generally leads to 2x speed-up or more on real-world datasets compared to OGRFeature iteration (as measured by the bench_ogr_c_api vs bench_ogr_batch utilities) on drivers that have implemented it (currently Arrow, Parquet, FlatGeoBuf, GPKG), whereas RFC 92 only applies to GPKG & PostGIS and in the best - artificial - case only lead to 30% speed-up. Of course, adopting RFC 86 requires significant effort from GDAL users, but the benefit is really measurable whereas with RFC 92 it would be marginal in most scenarios. As far as I can tell, the performance boost of RFC 86 comes mostly from saving creation & destruction of millions of OGRFeature instances, its array members, string attributes, geometries objects, more than the columnar organization of the ArrowArray data structures. In the GeoPackage driver, I've also shown that it makes it possible for efficient multi-threading pre-fetching, totally transparent for the user. But to avoid selling false hopes, the benefit of RFC 86 in end-to-end scenarios would probably drop significantly (at least if looking at performance gain in percentage. The absolute performance savings on the GDAL side would remain) if you need to recreate individual features (QGIS' QgsFeature or MapServer' msShape objects) from the content of ArrowArray. So this is likely a complete shift of concepts that would be required. Even On Tue, Jan 31, 2023 at 4:27 AM Even Rouault wrote: Hi, Please find for review "RFC 92 text: WKB Only geometries" at https://github.com/OSGeo/gdal/pull/7149 This RFC provides shortcuts to avoid instantiation of full OGRGeometry instances in scenarios where only the WKB representation of geometries is needed. The hope is to save CPU time. This is something I wanted to at least experiment. I've mixed feelings if it's something we actually want to adopt. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org
Re: [gdal-dev] Call for discussion on RFC 92 text: WKB Only geometries
Hi Even, I'm glad you mentioned a shift of concepts. The older Feature API and new Arrow API are really quite different. I actually don't know how often I will ever combine them in one program, for example to turn shapefiles into a huge Parquet file or the reverse. If anybody is doing this kind of thing I'd be interested to read about it. This RFC seems to have some things in common with the direct access to compressed raster blocks. Both by-pass the older raster and vector data models, yes? And they're quite specific to certain formats. Do you anticipate that GDAL and OGR will continue to develop more specialty APIs in addition to the general ones? On Sat, Feb 4, 2023, 11:55 AM Even Rouault wrote: > Hi Sean, > > but wouldn't it be possible for all OGRFeatures to carry WKB data by > default and add a method to provide it to callers? > > My understanding of what you propose would involve massive code rewrites > in all drivers and wouldn't be desirable from a performance point of view, > because most drivers can't generate WKB easily (PostGIS and GPKG are the > exceptions rather the norm). So either all other drivers should be modified > to compose WKB at hand (massive coding effort. Probably several weeks of > effort and significant risk of regressions). Or get it from the > ExportToWkb() method of the OGRGeometry instance they currently build, but > then you pay the price in memory and CPU time to generate WKB that might > not be consumed by users. > > | And only construct an OGRGeometry when it's asked for? Such as when > GetGeometryRef is called? > > Good point, we could both make GetGeometryRef() and GetGeomFieldRef() > virtual methods whose default implementation would be the same as > currently, ie. return the value of the corresponding member variable in the > base OGRFeature class stored with > SetGeometry[Directly]()/SetGeomField[Directly]() > > And add a new virtual method: > > virtual GByte* OGRFeature::GetWKBGeometry(int iGeomField, size_t* > pnOutSize) const > > whose default implementation would just use > GetGeomFieldRef(iGeomField)->ExportToWkb(). > > The few drivers that can provide a more efficient implementation (GPKG > typically) would create a derived class OGRFeatureGPKG with a specific > implementation of those new virtual methods to avoid systematic OGRGeometry > instantiation. The only drawback I see is that making GetGeometryRef() and > GetGeomFieldRef() virtual would have a slight performance impact, but > probably small enough. > > > But fundamentally I'm wondering if RFC 92 hasn't been made mostly out > fashioned now that we have RFC 86. RFC 86 generally leads to 2x speed-up or > more on real-world datasets compared to OGRFeature iteration (as measured > by the bench_ogr_c_api vs bench_ogr_batch utilities) on drivers that have > implemented it (currently Arrow, Parquet, FlatGeoBuf, GPKG), whereas RFC 92 > only applies to GPKG & PostGIS and in the best - artificial - case only > lead to 30% speed-up. > > Of course, adopting RFC 86 requires significant effort from GDAL users, > but the benefit is really measurable whereas with RFC 92 it would be > marginal in most scenarios. As far as I can tell, the performance boost of > RFC 86 comes mostly from saving creation & destruction of millions of > OGRFeature instances, its array members, string attributes, geometries > objects, more than the columnar organization of the ArrowArray data > structures. In the GeoPackage driver, I've also shown that it makes it > possible for efficient multi-threading pre-fetching, totally transparent > for the user. > > But to avoid selling false hopes, the benefit of RFC 86 in end-to-end > scenarios would probably drop significantly (at least if looking at > performance gain in percentage. The absolute performance savings on the > GDAL side would remain) if you need to recreate individual features (QGIS' > QgsFeature or MapServer' msShape objects) from the content of ArrowArray. > So this is likely a complete shift of concepts that would be required. > > Even > > > > On Tue, Jan 31, 2023 at 4:27 AM Even Rouault > wrote: > >> Hi, >> >> Please find for review "RFC 92 text: WKB Only geometries" at >> https://github.com/OSGeo/gdal/pull/7149 >> >> This RFC provides shortcuts to avoid instantiation of full OGRGeometry >> instances >> in scenarios where only the WKB representation of geometries is needed. >> The >> hope is to save CPU time. >> >> This is something I wanted to at least experiment. I've mixed feelings >> if it's something we actually want to adopt. >> >> 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 >> > > > -- > Sean Gillies > > ___ > gdal-dev mailing > listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > --
Re: [gdal-dev] Call for discussion on RFC 92 text: WKB Only geometries
Hi, I've captured in the RFC text the interesting discussion points. As I don't see a clear way forward for this RFC that offers a good balance between usefulness, efficiency, elegance and level of effort to implement, I'll commit the RFC text with a "on hold" status. Even Le 31/01/2023 à 12:27, Even Rouault a écrit : Hi, Please find for review "RFC 92 text: WKB Only geometries" at https://github.com/OSGeo/gdal/pull/7149 This RFC provides shortcuts to avoid instantiation of full OGRGeometry instances in scenarios where only the WKB representation of geometries is needed. The hope is to save CPU time. This is something I wanted to at least experiment. I've mixed feelings if it's something we actually want to adopt. 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] Call for discussion on RFC 92 text: WKB Only geometries
> PS: I believe I joked some time ago that it was a pity that GDAL, GEOS, QGIS, > PostGIS, ... didn't share the same geometry classes given that they all > implement the same Single Features/ ISO SQL MM Part 3 model (it is kind of > crazy that we have all to implement WKB, WKT, etc etc), but it really looks > like this is completely what the RFC works around. But I'm afraid this > "libgeom" is a pipe dream 100% agree, but GEOS gets some exemption from this list because it doesn't have curved geometry support. Honestly I'd be totally behind a modern "libgeom" library. Not as a replacement for GEOS, but just to provide a common "geometry representation" container with support for ALL the geometry types. It could even be written in rust :) Nyall > > 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 ___ 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 92 text: WKB Only geometries
Hi Dan, | And only construct an OGRGeometry when it's asked for? Such as when GetGeometryRef is called? I'm wondering about a more broad application of this. Would it be helpful to have the ability to lazy-initialize an OGRGeometry from multiple source types such as WKB and GEOS, initially storing only a reference to the external data in WKB/GEOS/etc and actually materializing the geometry when required? That's definitely something doable. At a minimum, you would have to inspect the top geometry type to instantiate the appropriate OGRGeometry subclass, and then its members could be lazy initialized, but that means that all methods of OGRGeometry and its subclasses would have to do a check whether the object has been fully initialized. There might be performance implications for people doing for example lineString->getX(idx) to iterate on big geometries, although branch predictors of modern CPUs are probably very good at repeatedly evaluating stuff like "if (!materialized) materialize();". The main drawback is that is a substantial & risky change that requires to revisit *all* methods of the geometry classes. For setters, you would also have to make sure to invalidate the potentially initial WKB / GEOS source. PS: I believe I joked some time ago that it was a pity that GDAL, GEOS, QGIS, PostGIS, ... didn't share the same geometry classes given that they all implement the same Single Features/ ISO SQL MM Part 3 model (it is kind of crazy that we have all to implement WKB, WKT, etc etc), but it really looks like this is completely what the RFC works around. But I'm afraid this "libgeom" is a pipe dream 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] Call for discussion on RFC 92 text: WKB Only geometries
| And only construct an OGRGeometry when it's asked for? Such as when GetGeometryRef is called? I'm wondering about a more broad application of this. Would it be helpful to have the ability to lazy-initialize an OGRGeometry from multiple source types such as WKB and GEOS, initially storing only a reference to the external data in WKB/GEOS/etc and actually materializing the geometry when required? Then methods such as OGRGeometry::exportToWkb and OGRGeometry::exportToGEOS could check the external data type and use it directly if it is compatible, avoiding materialization. This would avoid multiple conversions to/from GEOS in cases where operations are chained, as well as allowing WKB to pass directly between input and output drivers that support it. Relatedly, this ability could be used to cache external-format data when it is generated for an OGRGeometry, avoiding inefficiencies such as two conversions to GEOS when checking to see if two geometries intersect before calculating their intersection. Dan On Sat, Feb 4, 2023 at 1:55 PM Even Rouault wrote: > Hi Sean, > > but wouldn't it be possible for all OGRFeatures to carry WKB data by > default and add a method to provide it to callers? > > My understanding of what you propose would involve massive code rewrites > in all drivers and wouldn't be desirable from a performance point of view, > because most drivers can't generate WKB easily (PostGIS and GPKG are the > exceptions rather the norm). So either all other drivers should be modified > to compose WKB at hand (massive coding effort. Probably several weeks of > effort and significant risk of regressions). Or get it from the > ExportToWkb() method of the OGRGeometry instance they currently build, but > then you pay the price in memory and CPU time to generate WKB that might > not be consumed by users. > > | And only construct an OGRGeometry when it's asked for? Such as when > GetGeometryRef is called? > > Good point, we could both make GetGeometryRef() and GetGeomFieldRef() > virtual methods whose default implementation would be the same as > currently, ie. return the value of the corresponding member variable in the > base OGRFeature class stored with > SetGeometry[Directly]()/SetGeomField[Directly]() > > And add a new virtual method: > > virtual GByte* OGRFeature::GetWKBGeometry(int iGeomField, size_t* > pnOutSize) const > > whose default implementation would just use > GetGeomFieldRef(iGeomField)->ExportToWkb(). > > The few drivers that can provide a more efficient implementation (GPKG > typically) would create a derived class OGRFeatureGPKG with a specific > implementation of those new virtual methods to avoid systematic OGRGeometry > instantiation. The only drawback I see is that making GetGeometryRef() and > GetGeomFieldRef() virtual would have a slight performance impact, but > probably small enough. > > > But fundamentally I'm wondering if RFC 92 hasn't been made mostly out > fashioned now that we have RFC 86. RFC 86 generally leads to 2x speed-up or > more on real-world datasets compared to OGRFeature iteration (as measured > by the bench_ogr_c_api vs bench_ogr_batch utilities) on drivers that have > implemented it (currently Arrow, Parquet, FlatGeoBuf, GPKG), whereas RFC 92 > only applies to GPKG & PostGIS and in the best - artificial - case only > lead to 30% speed-up. > > Of course, adopting RFC 86 requires significant effort from GDAL users, > but the benefit is really measurable whereas with RFC 92 it would be > marginal in most scenarios. As far as I can tell, the performance boost of > RFC 86 comes mostly from saving creation & destruction of millions of > OGRFeature instances, its array members, string attributes, geometries > objects, more than the columnar organization of the ArrowArray data > structures. In the GeoPackage driver, I've also shown that it makes it > possible for efficient multi-threading pre-fetching, totally transparent > for the user. > > But to avoid selling false hopes, the benefit of RFC 86 in end-to-end > scenarios would probably drop significantly (at least if looking at > performance gain in percentage. The absolute performance savings on the > GDAL side would remain) if you need to recreate individual features (QGIS' > QgsFeature or MapServer' msShape objects) from the content of ArrowArray. > So this is likely a complete shift of concepts that would be required. > > Even > > > > On Tue, Jan 31, 2023 at 4:27 AM Even Rouault > wrote: > >> Hi, >> >> Please find for review "RFC 92 text: WKB Only geometries" at >> https://github.com/OSGeo/gdal/pull/7149 >> >> This RFC provides shortcuts to avoid instantiation of full OGRGeometry >> instances >> in scenarios where only the WKB representation of geometries is needed. >> The >> hope is to save CPU time. >> >> This is something I wanted to at least experiment. I've mixed feelings >> if it's something we actually want to adopt. >> >> Even >> >> -- >> http://www.spatialys.com >> My software is free, but my time
Re: [gdal-dev] Call for discussion on RFC 92 text: WKB Only geometries
Hi Sean, but wouldn't it be possible for all OGRFeatures to carry WKB data by default and add a method to provide it to callers? My understanding of what you propose would involve massive code rewrites in all drivers and wouldn't be desirable from a performance point of view, because most drivers can't generate WKB easily (PostGIS and GPKG are the exceptions rather the norm). So either all other drivers should be modified to compose WKB at hand (massive coding effort. Probably several weeks of effort and significant risk of regressions). Or get it from the ExportToWkb() method of the OGRGeometry instance they currently build, but then you pay the price in memory and CPU time to generate WKB that might not be consumed by users. | And only construct an OGRGeometry when it's asked for? Such as when GetGeometryRef is called? Good point, we could both make GetGeometryRef() and GetGeomFieldRef() virtual methods whose default implementation would be the same as currently, ie. return the value of the corresponding member variable in the base OGRFeature class stored with SetGeometry[Directly]()/SetGeomField[Directly]() And add a new virtual method: virtual GByte* OGRFeature::GetWKBGeometry(int iGeomField, size_t* pnOutSize) const whose default implementation would just use GetGeomFieldRef(iGeomField)->ExportToWkb(). The few drivers that can provide a more efficient implementation (GPKG typically) would create a derived class OGRFeatureGPKG with a specific implementation of those new virtual methods to avoid systematic OGRGeometry instantiation. The only drawback I see is that making GetGeometryRef() and GetGeomFieldRef() virtual would have a slight performance impact, but probably small enough. But fundamentally I'm wondering if RFC 92 hasn't been made mostly out fashioned now that we have RFC 86. RFC 86 generally leads to 2x speed-up or more on real-world datasets compared to OGRFeature iteration (as measured by the bench_ogr_c_api vs bench_ogr_batch utilities) on drivers that have implemented it (currently Arrow, Parquet, FlatGeoBuf, GPKG), whereas RFC 92 only applies to GPKG & PostGIS and in the best - artificial - case only lead to 30% speed-up. Of course, adopting RFC 86 requires significant effort from GDAL users, but the benefit is really measurable whereas with RFC 92 it would be marginal in most scenarios. As far as I can tell, the performance boost of RFC 86 comes mostly from saving creation & destruction of millions of OGRFeature instances, its array members, string attributes, geometries objects, more than the columnar organization of the ArrowArray data structures. In the GeoPackage driver, I've also shown that it makes it possible for efficient multi-threading pre-fetching, totally transparent for the user. But to avoid selling false hopes, the benefit of RFC 86 in end-to-end scenarios would probably drop significantly (at least if looking at performance gain in percentage. The absolute performance savings on the GDAL side would remain) if you need to recreate individual features (QGIS' QgsFeature or MapServer' msShape objects) from the content of ArrowArray. So this is likely a complete shift of concepts that would be required. Even On Tue, Jan 31, 2023 at 4:27 AM Even Rouault wrote: Hi, Please find for review "RFC 92 text: WKB Only geometries" at https://github.com/OSGeo/gdal/pull/7149 This RFC provides shortcuts to avoid instantiation of full OGRGeometry instances in scenarios where only the WKB representation of geometries is needed. The hope is to save CPU time. This is something I wanted to at least experiment. I've mixed feelings if it's something we actually want to adopt. 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 -- Sean Gillies ___ 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] Call for discussion on RFC 92 text: WKB Only geometries
Hi Even, I'm not much of a C++ programmer, but wouldn't it be possible for all OGRFeatures to carry WKB data by default and add a method to provide it to callers? And only construct an OGRGeometry when it's asked for? Such as when GetGeometryRef is called? On Tue, Jan 31, 2023 at 4:27 AM Even Rouault wrote: > Hi, > > Please find for review "RFC 92 text: WKB Only geometries" at > https://github.com/OSGeo/gdal/pull/7149 > > This RFC provides shortcuts to avoid instantiation of full OGRGeometry > instances > in scenarios where only the WKB representation of geometries is needed. The > hope is to save CPU time. > > This is something I wanted to at least experiment. I've mixed feelings > if it's something we actually want to adopt. > > 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 > -- Sean Gillies ___ 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 92 text: WKB Only geometries
Hi Seth, Le 31/01/2023 à 14:20, Seth G a écrit : Hi Even, Is it correct to say the workflow for OGR layer in MapServer is similar to that of QGIS? Not quite, because currently MapServer as you point out use "materialized geometries" to get the points, the number of rings in a polygons, etc. Would using WKB here be any more performant? In the general case where the geometries in the datasource aren't encoding using WKB, probably not because you would have to pay for the WKB serialization & deserialization. It could, perhaps, help, a bit, for GeoPackage. To get the best performance, you'd need to have 2 code paths: one for OGR materialized geometry (the current one), and another one for OGR WKBOnly geometries. The PostGIS driver already has code to convert from WKB to shape [2] which could be repurposed. Yes, if that was done, reusing the WKB -> msShapeObj converter from the PostGIS connector would be the way to go Even Seth [1] https://github.com/MapServer/MapServer/blob/f3f05d4cf30af615d5f443a1c47c20b6117e52cb/mapogr.cpp#L250 [2] https://github.com/MapServer/MapServer/blob/f3f05d4cf30af615d5f443a1c47c20b6117e52cb/mappostgis.cpp#L663 -- web:https://geographika.net twitter: @geographika On Tue, Jan 31, 2023, at 12:27 PM, Even Rouault wrote: Hi, Please find for review "RFC 92 text: WKB Only geometries" at https://github.com/OSGeo/gdal/pull/7149 This RFC provides shortcuts to avoid instantiation of full OGRGeometry instances in scenarios where only the WKB representation of geometries is needed. The hope is to save CPU time. This is something I wanted to at least experiment. I've mixed feelings if it's something we actually want to adopt. 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 -- 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] Call for discussion on RFC 92 text: WKB Only geometries
Hi Even, Is it correct to say the workflow for OGR layer in MapServer is similar to that of QGIS? OGR features / geometries are loaded, and then converted into MapServer shapes using the OGRGeometry function [1]. Would using WKB here be any more performant? The PostGIS driver already has code to convert from WKB to shape [2] which could be repurposed. Seth [1] https://github.com/MapServer/MapServer/blob/f3f05d4cf30af615d5f443a1c47c20b6117e52cb/mapogr.cpp#L250 [2] https://github.com/MapServer/MapServer/blob/f3f05d4cf30af615d5f443a1c47c20b6117e52cb/mappostgis.cpp#L663 -- web:https://geographika.net twitter: @geographika On Tue, Jan 31, 2023, at 12:27 PM, Even Rouault wrote: > Hi, > > Please find for review "RFC 92 text: WKB Only geometries" at > https://github.com/OSGeo/gdal/pull/7149 > > This RFC provides shortcuts to avoid instantiation of full OGRGeometry > instances > in scenarios where only the WKB representation of geometries is needed. The > hope is to save CPU time. > > This is something I wanted to at least experiment. I've mixed feelings > if it's something we actually want to adopt. > > 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
