<div dir="ltr">Hi Joaquim,<div><br></div><div>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. <div><br></div><div>Every line of code has some test and maintenance burden... Are there netcdf readers that <i>don't</i> support crs_wkt and <i>only</i> support spatial_ref?</div><div><br></div><div>@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?</div><div><br></div><div>Rob :)</div><div><br></div><div>[1] <a href="https://gdal.org/drivers/vector/geopackage_aspatial.html">https://gdal.org/drivers/vector/geopackage_aspatial.html</a></div><div>[2] <a href="https://gdal.org/drivers/vector/gpkg.html#drivers/vector/gpkg-lco-ASPATIAL_VARIANT">https://gdal.org/drivers/vector/gpkg.html#drivers/vector/gpkg-lco-ASPATIAL_VARIANT</a></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Sept 2023 at 15:31, Joaquim Manuel Freire Luís via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even, I understand that. Specially because not all nc files are created with GDAL 😊<br>
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*.<br>
<br>
Joaquim<br>
<br>
-----Original Message-----<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> <br>
Sent: Thursday, September 21, 2023 12:33 AM<br>
To: Joaquim Manuel Freire Luís <<a href="mailto:jluis@ualg.pt" target="_blank">jluis@ualg.pt</a>>; <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
Subject: Re: [gdal-dev] Call for 4.0 ideas<br>
<br>
<br>
Le 21/09/2023 à 01:12, Joaquim Manuel Freire Luís a écrit :<br>
> Remove spatial_ref WKT export in netCDF driver (GDAL 4) #4712<br>
><br>
> Would this mean all codes that use spatial_ref would be broken????!!!!<br>
<br>
yes, spatial_ref is AFAIK a GDAL specific thing that predates the introduction of crs_wkt in the CF conventions (cf <a href="https://github.com/cf-convention/cf-conventions/issues/222" rel="noreferrer" target="_blank">https://github.com/cf-convention/cf-conventions/issues/222</a>,<br>
<a href="https://github.com/opendatacube/datacube-core/issues/837" rel="noreferrer" target="_blank">https://github.com/opendatacube/datacube-core/issues/837</a> 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.<br>
<br>
--<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>