Re: [gdal-dev] resampling algs warp vs translate

[Even Rouault via gdal-dev]

That should be relatively straightforward to adapt 
GDALResampleChunk_AverageOrRMS_T to do sum. Reuse the average code path, 
but just don't divide the sum by dfTotalWeight at lines 1418, 1473, 
1688, 1700 and 1712. And error out if applied to a band with a color 
table (cf line 4361)


For other algorithms, it could potentially be possible to re-use the 
warping code with an adaptation layer like done in 
GDALRasterBand::RasterIOResampled() in the bUseWarp case. Of course that 
would be less performant than implementing a specific overview 
resampling kernel which can assume that a source rectangle maps to a 
target rectangle at the band level, while the warping code only process 
pixel by pixel.


Le 21/09/2023 à 22:25, Michael Sumner via gdal-dev a écrit :
Can we aspire to translate having the same set of resampling 
algorithms as the warper?


I see the warper adds min, max, mod, q1, q3, sum

I especially wanted sum for OVERVIEW_RESAMPLING in COG, and I can see 
where it's done and  ...  can maybe see my way through that ... but 
the 600 lines of code in GDALResampleChunk_AverageOrRMS_T kind of 
reins in my confidence.


https://github.com/OSGeo/gdal/blob/26e7ff91504e0303434f440e6d19e58f2a206b45/gcore/overview.cpp#L1211C15-L1211C47

It came up as a need for statistical properties required for 
overview-publishers, and while I think we can incrementally build up 
the SUM-pyramid with external overivews via CLI it would be awesome to 
have the same stats for the two resampling regimes.


Thank you



--
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsum...@gmail.com

___
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] resampling algs warp vs translate

[Michael Sumner via gdal-dev]

Can we aspire to translate having the same set of resampling algorithms as
the warper?

I see the warper adds min, max, mod, q1, q3, sum

I especially wanted sum for OVERVIEW_RESAMPLING in COG, and I can see where
it's done and  ...  can maybe see my way through that ... but the 600 lines
of code in GDALResampleChunk_AverageOrRMS_T kind of reins in my confidence.

https://github.com/OSGeo/gdal/blob/26e7ff91504e0303434f440e6d19e58f2a206b45/gcore/overview.cpp#L1211C15-L1211C47

It came up as a need for statistical properties required for
overview-publishers, and while I think we can incrementally build up the
SUM-pyramid with external overivews via CLI it would be awesome to have the
same stats for the two resampling regimes.

Thank you



-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsum...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for 4.0 ideas

[Even Rouault via gdal-dev]

| But I have more troubles to understand why breaking code that use 
spatial_ref for decades without any real need


Have you ever looked at the mess in the netcdf driver? Aligning with 
recommendations from standards, especially on the write side, and 
helping to reduce a bit code bloat (although mostly symbolic here) is 
helpful.


Another thing is that as currently we write both crs_wkt and 
spatial_ref, this can puzzle human or software readers, and that could 
result in inconsistencies if a writer would update one of the attribute 
without the other one.



@Even is it worth a pass through other drivers to swap default option 
values or remove obsolete options with 4.0?


I'd suggest people with interest in a particular driver do their own 
pass and add their suggestions to the meta-ticket (there have already 
been suggestions to change GTiff defaults to use LZW and tiling).


| And do another deprecation/cull through unused drivers?

maybe, but do we have data points to assess what can be deprecated? 
(other than me blowing off out of frustration occasionally and randomly 
picking candidates :-) :-))


--
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 4.0 ideas

[Robert Coup via gdal-dev]

Hi Joaquim,

There have been other similar changes... for example, GDAL added an
aspatial extension[1] to GeoPackage v1.0 to support non-geo tables... the
GeoPackage standard added support for such tables in v1.2; so our extension
is no longer needed: GDAL still reads it, but no longer writes it [2].
We've done similar things in other drivers, and obviously removed entire
drivers before.

Every line of code has some test and maintenance burden... Are there netcdf
readers that *don't* support crs_wkt and *only* support spatial_ref?

@Even is it worth a pass through other drivers to swap default option
values or remove obsolete options with 4.0? And do another deprecation/cull
through unused drivers?

Rob :)

[1] https://gdal.org/drivers/vector/geopackage_aspatial.html
[2]
https://gdal.org/drivers/vector/gpkg.html#drivers/vector/gpkg-lco-ASPATIAL_VARIANT


On Thu, 21 Sept 2023 at 15:31, Joaquim Manuel Freire Luís via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Even, I understand that. Specially because not all nc files are created
> with GDAL 
> But I have more troubles to understand why breaking code that use
> spatial_ref  for decades without any real need. Sorry, and I know it's not
> decided yet, but it looks so much the Linux culture of *easy breaking*.
>
> Joaquim
>
> -Original Message-
> From: Even Rouault 
> Sent: Thursday, September 21, 2023 12:33 AM
> To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Call for 4.0 ideas
>
>
> Le 21/09/2023 à 01:12, Joaquim Manuel Freire Luís a écrit :
> > Remove spatial_ref WKT export in netCDF driver (GDAL 4) #4712
> >
> > Would this mean all codes that use spatial_ref would be broken
>
> yes, spatial_ref is AFAIK a GDAL specific thing that predates the
> introduction of crs_wkt in the CF conventions (cf
> https://github.com/cf-convention/cf-conventions/issues/222,
> https://github.com/opendatacube/datacube-core/issues/837 where this is
> also discussed). Recent GDAL versions write both crs_wkt and spatial_ref as
> a transition step. This would complete the transition by removing writing
> spatial_ref (presumably we'd still accept it on the reading side for older
> datasets). Code that only checks for spatial_ref should be adapted to deal
> with crs_wkt, since it is the standardized attribute, independently on
> whether GDAL discontinues writing spatial_ref or not.
>
> --
> 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] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

On Thu, Sep 21, 2023, at 18:05, Even Rouault wrote:
> 
>> Of course, but I'm asking if it's worth calling ReadBlock on multiple 
>> threads (if it always takes a lock, it's not, and I should use RasterIO 
>> instead).
> Not on the same dataset object, otherwise you'll get crashes as no lock is 
> taken
I've filed https://github.com/OSGeo/gdal/issues/8448 for this. Even if 
rejected, it will serve as documentation for other people who want this.___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Even Rouault via gdal-dev]

Of course, but I'm asking if it's worth calling ReadBlock on multiple 
threads (if it always takes a lock, it's not, and I should use 
RasterIO instead).
Not on the same dataset object, otherwise you'll get crashes as no lock 
is taken


(*) I think these can also be implemented at VSI level by wrapping a 
file handle and turning Seek + Read into a PRead (when supported), 
even for drivers that don't explicitly support PRead.


The multi-threaded optimization also works for VSI file systems not 
supported PRead(), but doing what you mention above: doing Seek+Read 
under a lock. This is of course less efficient.


I meant something slightly different here: if a file supports PRead, 
but a driver doesn't (maybe it's using some external library like 
libtiff, which has _tiffReadProc and _tiffSeekProc), threading could 
still be supported with a hack. The driver could ask the library to 
open the same file multiple times, wrapping the same VSI handle, but 
passing in a seekProc that only keeps track of the current offset. So 
the library could seek and read as it pleases, but GDAL would turn 
those into PRead calls. The backing file handle would never see a 
seek, just PRead.


Ah I see what you mean. Having generic multi-threading isn't possible. 
Each driver would have to be modified to be ready to cope with that. 
Besides file handles, there are often other state variables at the 
GDALDataset/GDALRasterBand level.




Laurentiu


--
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 4.0 ideas

[Joaquim Manuel Freire Luís via gdal-dev]

Even, I understand that. Specially because not all nc files are created with 
GDAL 
But I have more troubles to understand why breaking code that use spatial_ref  
for decades without any real need. Sorry, and I know it's not decided yet, but 
it looks so much the Linux culture of *easy breaking*.

Joaquim

-Original Message-
From: Even Rouault  
Sent: Thursday, September 21, 2023 12:33 AM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Call for 4.0 ideas


Le 21/09/2023 à 01:12, Joaquim Manuel Freire Luís a écrit :
> Remove spatial_ref WKT export in netCDF driver (GDAL 4) #4712
>
> Would this mean all codes that use spatial_ref would be broken

yes, spatial_ref is AFAIK a GDAL specific thing that predates the introduction 
of crs_wkt in the CF conventions (cf 
https://github.com/cf-convention/cf-conventions/issues/222,
https://github.com/opendatacube/datacube-core/issues/837 where this is also 
discussed). Recent GDAL versions write both crs_wkt and spatial_ref as a 
transition step. This would complete the transition by removing writing 
spatial_ref (presumably we'd still accept it on the reading side for older 
datasets). Code that only checks for spatial_ref should be adapted to deal with 
crs_wkt, since it is the standardized attribute, independently on whether GDAL 
discontinues writing spatial_ref or not.

--
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] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

Hi,

On Thu, Sep 21, 2023, at 17:02, Even Rouault wrote:
> Laurentiu,
> 
>> 
>> GDAL 3.6 added support for multi-threaded reading using PRead, but I 
>> couldn't spot ReadBlock using the same code path.
> If you read one single block at a time, the multi-threaded optimization 
> cannot kick in, since the elementary decoding unit is a block. You must call 
> RasterIO() with a window intersecting several block.
> 
Of course, but I'm asking if it's worth calling ReadBlock on multiple threads 
(if it always takes a lock, it's not, and I should use RasterIO instead).
>> 
>> (*) I think these can also be implemented at VSI level by wrapping a file 
>> handle and turning Seek + Read into a PRead (when supported), even for 
>> drivers that don't explicitly support PRead.
> The multi-threaded optimization also works for VSI file systems not supported 
> PRead(), but doing what you mention above: doing Seek+Read under a lock. This 
> is of course less efficient.
> 
I meant something slightly different here: if a file supports PRead, but a 
driver doesn't (maybe it's using some external library like libtiff, which has 
_tiffReadProc and _tiffSeekProc), threading could still be supported with a 
hack. The driver could ask the library to open the same file multiple times, 
wrapping the same VSI handle, but passing in a seekProc that only keeps track 
of the current offset. So the library could seek and read as it pleases, but 
GDAL would turn those into PRead calls. The backing file handle would never see 
a seek, just PRead.

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

Re: [gdal-dev] GeoTIFF and concurrent block reads

[Even Rouault via gdal-dev]

Laurentiu,



GDAL 3.6 added support for multi-threaded reading using PRead, but I 
couldn't spot ReadBlock using the same code path.


If you read one single block at a time, the multi-threaded optimization 
cannot kick in, since the elementary decoding unit is a block. You must 
call RasterIO() with a window intersecting several block.




(*) I think these can also be implemented at VSI level by wrapping a 
file handle and turning Seek + Read into a PRead (when supported), 
even for drivers that don't explicitly support PRead.


The multi-threaded optimization also works for VSI file systems not 
supported PRead(), but doing what you mention above: doing Seek+Read 
under a lock. This is of course less efficient.


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] Creation of a new driver from scratch

[Abel Pau via gdal-dev]

Hello again!

I need to know that some shared code is being compiled in GDAL project. I can 
see that GDAL_COMPILATION  (at Preprocessor definition i Visual Studio Project) 
is everywhere.

It's apropiate to use that variable to know if I am compiling in GDAL or not?
#ifdef GDAL_COMPILATION
I'm in GDAL
#else
I can ignore that code in gdal
#endif

I'm not using that in the code, only in some .h

Thanks!!!


-Mensaje original-
De: Abel Pau 
Enviado el: dimarts, 5 de setembre de 2023 15:26
Para: Even Rouault ; gdal-dev@lists.osgeo.org
Asunto: RE: [gdal-dev] Creation of a new driver from scratch

Hi again,
after looking for that in the code, I think that versions depends on layer, so 
-lco is working fine (instead of -dsco, les used).
So, if there is no inconvenience, I'll use -lco Version=V20, etc...

Thanks again

-Mensaje original-
De: Abel Pau 
Enviado el: dimarts, 5 de setembre de 2023 10:43
Para: Abel Pau ; Even Rouault 
; gdal-dev@lists.osgeo.org
Asunto: RE: [gdal-dev] Creation of a new driver from scratch

Sorry
there was a mistake. I meant: ogr2ogr src dst -dsco Version=V11 ... 

-Mensaje original-
De: gdal-dev  En nombre de Abel Pau Enviado 
el: dimarts, 5 de setembre de 2023 10:26
Para: Even Rouault ; gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

Hi Everyone,

Even, after a meeting with the team, we have took in consideration your opinion 
and we have discard the option of writing V1.1 and change to V2.0 in the middle 
of writing.
We have a long tradition with V1.1 and we can't ignore that now but we are 
going to offer both possibilities: read both and write V1.1 and V2.0 according 
to user's choice (default 2.0). 
If V1.1 is not enough for its limitations we are going to show a message:
"MiraMon format limitations." and "Try V2.0 option." and return OGRERR_FAILURE;

Can you confirm that is enough a -f parameter like?
For version 1.1:   ogr2ogr src dst - dsco=V11
For version 2.0:   ogr2ogr src dst - dsco=V20
For last version (to make it simple for possible future versions):  
ogr2ogr src dst - dsco=last_version

Thanks a lot for all your kind support.

-Mensaje original-
De: Even Rouault  Enviado el: dimecres, 30 d’agost 
de 2023 22:57
Para: Abel Pau ; gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

Abel,
>
> I am interested in proportionate 3 ways of proceeding when a used calls 
> translation from one format to our format.
> way 1: force to write V1.1 and stop writing features if the limit is reached.
> way 2: force to write V2.0 (and stop writing features if the limit is reached 
> (it will no happen in a near future, I think)).
> way 3: leave that the program decides if V1.1 is not enough and then it 
> changes automatically to V2.0. It does it in the middle of the process, when 
> FID or some used internal offset gets the limit.

Not knowing anything about the ecosystem of the miramon format, but ideally I 
would bend on the side of simplicity if possible, and I would just write V2.0 
if V1.1 can be considered as a legacy format, that deserves perhaps only 
read-only support (at our times of terabytes+ storage capacity, the saving of 4 
bytes per feature seems like a anachronic concern). But if you really want to 
use V1.1 when possible and V2.0 only when possible, and provided that you 
implement the writing of the final file only at dataset closing as it was my 
understanding, then you know already the max(FID) of features that have been 
passed to CreateFeature, so you could decide automatically the version needed. 
I would strongly discourage starting writing a V1.1 file and then switching to 
V2.0 in the middle of the writing. That sounds like a serious complication.

>
> So, my questions:
> 1.- Which ogr2ogr parameter is the best for doing that?
>   -f? specificating "MiraMon V1.1" or "MiraMonV2.0" or "MiraMon" 
> (automatic way).

If you really need to implement the 2 formats, a dataset creation option in a 
single driver would probably be better.


>Or there is another way I haven't seen (I've read all options 
> in https://gdal.org/programs/ogr2ogr.html#ogr2ogr)
>
> 2.- When using -progress some points appear on screen informing the progress. 
> At the end of the progress (or sometimes driver requires) there is a gap of 
> time that driver is writing some pendant information.
-progress works by counting the number of features in the source layer, and 
computing the progress percentage at each call to CreateFeature()
> There is any way to inform the user what the process is doing?

Not really. You could possibly implement it using CPLDebug() statements if you 
want to monitor the progress in debug mode (the GeoPackage driver implemets 
something similar during spatial index writing, which can be a long operation), 
but there's nothing dedicated in the OGR API or ogr2ogr to monitor the progress 
of long operations occuring during dataset 

[gdal-dev] GeoTIFF and concurrent block reads

[Laurențiu Nicola via gdal-dev]

Hello,

GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't 
spot ReadBlock using the same code path. On the other hand, I didn't see it 
taking a lock either, so I'm a little confused :-). My question is whether 
ReadBlock supports concurrent reads or not (*).

(*) I think these can also be implemented at VSI level by wrapping a file 
handle and turning Seek + Read into a PRead (when supported), even for drivers 
that don't explicitly support PRead.

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

Re: [gdal-dev] layer.GetSpatialRef() fails on linux for shapefiles

[Even Rouault via gdal-dev]

Run ogrinfo on one shapefile to see if some more interesting error 
message is displayed


Also check if the environment isn't messed up regarding PROJ and the 
PROJ_LIB/PROJ_DATA environment variable


Le 21/09/2023 à 14:34, Jonathan Moules via gdal-dev a écrit :


Yeah, I'm afraid the error message is pretty much non-existent:

Traceback (most recent call last):
  File

"/home/name/Code/DSHub/PoC/Extract-Transform-Load-POC/Metadata/AME/src/info_vector.py",
line 119, in get_layer_metadata
    tmp_projection = layer.GetSpatialRef()
 ^
  File

"/home/name/anaconda3/envs/AME_env/lib/python3.11/site-packages/osgeo/ogr.py",
line 1990, in GetSpatialRef
    return _ogr.Layer_GetSpatialRef(self, *args)
   ^
RuntimeError


Suggestions welcome.


On 18/09/2023 12:51, Javier Jimenez Shaw wrote:

Hi Jonathan

Which exact RuntimeError are you getting? It can be for several 
reasons (probably an installation or configuration issue).


Best,
Javier


On Mon, 18 Sept 2023 at 11:06, Jonathan Moules 
 wrote:


Hi List,

I'm trying to get vector layer information via OGR and Python:

```

layer.GetSpatialRef()

```

This works fine for me on Windows with GDAL 3.7.1 on various
different
types of files (Shapefile, GPKG, GML, KML, GDB).

But for my colleague on Ubuntu 22.0.4.3, also on GDAL 3.7.1 (via
Conda),
they get a Python RuntimeError for all shapefiles (the exact same
shapefiles that work fine for me). It works for Geopackages for them.

Anyone have any thoughts?
Thanks,
Jonathan

___
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] layer.GetSpatialRef() fails on linux for shapefiles

[Jonathan Moules via gdal-dev]

Yeah, I'm afraid the error message is pretty much non-existent:

   Traceback (most recent call last):
  File
   
"/home/name/Code/DSHub/PoC/Extract-Transform-Load-POC/Metadata/AME/src/info_vector.py",
   line 119, in get_layer_metadata
    tmp_projection = layer.GetSpatialRef()
 ^
  File
   
"/home/name/anaconda3/envs/AME_env/lib/python3.11/site-packages/osgeo/ogr.py",
   line 1990, in GetSpatialRef
    return _ogr.Layer_GetSpatialRef(self, *args)
   ^
   RuntimeError


Suggestions welcome.


On 18/09/2023 12:51, Javier Jimenez Shaw wrote:

Hi Jonathan

Which exact RuntimeError are you getting? It can be for several 
reasons (probably an installation or configuration issue).


Best,
Javier


On Mon, 18 Sept 2023 at 11:06, Jonathan Moules 
 wrote:


Hi List,

I'm trying to get vector layer information via OGR and Python:

```

layer.GetSpatialRef()

```

This works fine for me on Windows with GDAL 3.7.1 on various
different
types of files (Shapefile, GPKG, GML, KML, GDB).

But for my colleague on Ubuntu 22.0.4.3, also on GDAL 3.7.1 (via
Conda),
they get a Python RuntimeError for all shapefiles (the exact same
shapefiles that work fine for me). It works for Geopackages for them.

Anyone have any thoughts?
Thanks,
Jonathan

___
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] Invitation for the Open Standards Code Sprint 

[Joana Simoes via gdal-dev]

***

Good morning,

**

The Open Standards Code Sprint, will run from October 30 - November 1, 
in Geovation  (London, UK). All OGC standards are 
in scope for this code sprint and various Standards Working Groups 
already confirmed their participation 
.



A Code Sprint is a three day hybrid event, where dozens of developers 
from around the world come together to code and share their ideas 
regarding sharing geospatial information.This code sprint will include a 
mentor stream targeted at newcomers, which includes an onboarding day 
with lots of introductory tutorials.


*

*OSGeo projects that wish to participate are encouraged to advertise it 
at the sprint wiki page 
, 
and to register for the project pitches 
.* 



**

*You can find more information, including a registration link in the 
code sprint website: https://developer.ogc.org/sprints/22/ *


*This event is generously supported by our sponsors and supporters 
 
and some funding opportunities for selected participants may be 
available. If you want to apply, please express your interest in the 
registration form 
, as 
soon as possible.*


*Hope to see you at the code sprint,*

*All the Best,*

*Joana *

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

Re: [gdal-dev] adding metadata -mo in a domain?

[Michael Sumner]

cool thanks, I'll deal with that 



On Thu, 21 Sept 2023, 18:48 Even Rouault, 
wrote:

>
> >
> > which don't seem to exist. Is that just an outdated comment?
>
> yes, as far as I can see from history those functions have never
> existed. This comment dates back to the initial commit and they didn't
> even exist at that time.
>
>
> --
> 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] adding metadata -mo in a domain?

[Even Rouault]

which don't seem to exist. Is that just an outdated comment?


yes, as far as I can see from history those functions have never 
existed. This comment dates back to the initial commit and they didn't 
even exist at that time.



--
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