[gdal-dev] default for RelativeToVRT field

Michael Sumner mdsumner at gmail.com
Thu May 5 23:59:23 PDT 2022


On Sat, Apr 23, 2022 at 7:37 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Michael,
>
> > Or is it just a matter of forcing an input path to be absolute?
>
> for regular use cases (ie VRT name not set to empty), you might not even
> been able to do that in master since
>
> https://github.com/OSGeo/gdal/commit/6d7001656d06af138f8e46ff1651056626db11e8
> which tries to write relative filename as much as possible, even if all
> paths are absolute
>
> Testing with your use case with empty VRT filename, I see the behavior
> has not changed, and that you'll indeed get relativeToVRT="0" only if
> using a source dataset with an absolute path. For most use cases where
> you use an empty filename, it doesn't matter much because you don't
> actually re-open it and use it immediately, and thus the source dataset
> is not re-opened. I can imagine though that you could get into trouble
> if serializing it from the xml:VRT content and re-opening the resulting
> VRT.
>
> > Is it possible to force GDAL to make the SourceFilename absolute by
> > setting options?
>
> The solution would probably be to add an explicit creation option to the
> VRT driver, like SOURCE_PATH=ABSOLUTE, that would override the current
> heuristics.
>
>

Thanks a lot Even, very helpful as always. I can see why relative is the
(hard) default, (for auxiliary files to move around with sources).

I do think I would benefit from this creation option to make some workflows
easier, but I still need a bit longer exploring to get all the parts clear
(to me) -  I'll  PR this at some point.

Best, Mike



> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220506/bd96ebc1/attachment.htm>


More information about the gdal-dev mailing list