<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">I think you should target master only for your changes (and consider only GDAL<br></span><span style="font-size:12.8px">>= 2 case). It is unlikely they are appropriate for backporting, or that<br></span><span style="font-size:12.8px">should be considered in a later stage depending on the impact they have.</span> </blockquote><div>Since on my older machine, getting master to run properly is problematic, </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>I didn't dig up into that but the issue here is with tables with multiple<br>
geometry columns, right ? In that case, the OGR uri should likely have a<br>
geometry= parameter so that the right column is selected. Similarly to what<br>
the spatialite or postgresql providers do.<br></blockquote><div>yes, layername contains the geometry column with the syntax needed for GDALDatasetGetLayerByName</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
><br>
> --<br>
> Problem 02:<br>
><br>
> Since 2015, new code has been added implementing gdal 2.* specific<br>
> functions, which will only be included when compiled/built against gdal<br>
> 2.*.<br>
><br>
> Thus, when QGIS is complied against gdal 2.*, symbols/functions are added<br>
> - that doe not exist in gdal 1.*.<br>
<br>
</span>To me, this is a non issue, or rather an issue we shouldn't try solving. In<br>
normal user environements this will not happen. This is just an issue for us<br>
developers that might play with multiple versions.<br>
What we might perhaps eventually want to ensure is that if QGIS is compiled<br>
with GDAL 2.X, it works reasonably well when running against GDAL 2.Y where Y<br>
>= X. And even that can be painful, because 2.Y can introduce for example new<br>
geometry types not handled in 2.X, so that would oblige to have runtime checks<br>
in addition to compile time checks. Binary distributions of QGIS are normally<br>
recompiled against a new major GDAL version if they will run against it.<br></blockquote><div>The runtime check are a part of this solution and the assumption is that both runtime and compile checks will be needed in the future. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> For QGIS 3.0: gdal 1.* support should be removed.<br>
<br>
</span>This is probably reasonable. I guess that all target environments that will be<br>
able to run QGIS 3.0 will have at least GDAL 2.0.<br></blockquote><div>Once in place in release-2_18, it will be easy to port to master (QGIS 3.0) and to remove everything within the runtime/compile checks < 2 that have been isolated and checked.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br></div></div>