<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Andre,</div><div><br></div><div>Given the magnitude of the shift, I suspected that could be due to the lack of +towgs84 parameters of ESRI 102164.</div><div><br></div><div>But I does not understand why it worked correctly in GDAL 2.2.2.</div><div><br></div><div>Now I see that <br></div><div><br></div><div>C:\>gdalinfo --version<br>GDAL 2.3.2, released 2018/09/21</div><div><br></div><div>C:\>gdalsrsinfo EPSG:102164<br>PROJ.4 : +proj=tmerc +lat_0=39.66666666666666 +lon_0=-8.131906111111112 +k=1 +x_0=200000 +y_0=300000 +ellps=intl +units=m +no_defs<br>OGC WKT :<br>PROJCS["Lisboa_Hayford_Gauss_IGeoE",<br>    GEOGCS["GCS_Datum_Lisboa_Hayford",<br>        DATUM["Datum_Lisboa_Hayford",<br>            SPHEROID["International_1924",6378388.0,297.0]],<br>        PRIMEM["Greenwich",0.0],<br>        UNIT["Degree",0.0174532925199433]],<br>    PROJECTION["Transverse_Mercator"],<br>    PARAMETER["False_Easting",200000.0],<br>    PARAMETER["False_Northing",300000.0],<br>    PARAMETER["Central_Meridian",-8.131906111111112],<br>    PARAMETER["Scale_Factor",1.0],<br>    PARAMETER["Latitude_Of_Origin",39.66666666666666],<br>    UNIT["Meter",1.0],<br>    AUTHORITY["Esri","102164"]]</div><div><br></div><div>while</div><div><br></div><div>pedro@pedro-VirtualBox:~$ gdalinfo --version</div><div>GDAL 2.2.2, released 2017/09/15</div><div><br></div><div>pedro@pedro-VirtualBox:~$ gdalsrsinfo EPSG:102164<br>ERROR 1: ERROR - failed to load SRS definition from EPSG:102164</div><div><br></div><div>I checked and in both versions, this SRS is listed in proj esri file as</div><div><br></div><div># Lisboa Hayford Gauss IGeoE<br><102164> +proj=tmerc +lat_0=39.66666666666666 +lon_0=-8.131906111111112 +k=1.000000 +x_0=200000 +y_0=300000 +ellps=intl +units=m  no_defs <></div><div><br></div><div>and not in the epsg file.<br></div><div><br></div><div>So, is there any explanation for the different behaviour between those versions?</div><div><br></div><div>Thank you very much!</div><div><br></div><div>Best regards,</div><div>Pedro</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Andre Joost <<a href="mailto:andre%2Bjoost@nurfuerspam.de">andre+joost@nurfuerspam.de</a>> escreveu no dia segunda, 17/12/2018 à(s) 13:17:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pedro,<br>
<br>
if you compare gdalsrsinfo epsg:20790 and gdalsrsinfo EPSG:102164 from <br>
ESRI, you see that ESRI omits the datum shift between Lisbon Hayford and <br>
WGS84.<br>
<br>
So you should use -s_srs EPSG:20790 to get the warping correctly.<br>
<br>
HTH,<br>
Andre Joost<br>
<br>
Am 17.12.18 um 11:09 schrieb Pedro Venâncio:<br>
> Hi,<br>
><br>
> I'm getting an error when clipping a raster by a mask layer, in GDAL 2.3.2.<br>
><br>
> This beaviour does not happen in GDAL 2.2.2.<br>
><br>
> To be more specific, in a Windows machine with GDAL 2.3.2, the clip is<br>
> done, but the image is clipped about 200 meters away from the correct<br>
> bounding box of the vector layer.<br>
><br>
> In Linux, with GDAL 2.2.2, the clip is done exactly by the vector bounding<br>
> box, as expected.<br>
><br>
> The command I'm using is just:<br>
><br>
> gdalwarp -of GTiff -tr 4.235097023884323 -4.2350970238843235 -tap -cutline<br>
> PATH_TO_FOLDER\Cartograma_20790_19D.gpkg -dstalpha PATH_TO_FOLDER\19-D.jpg<br>
> PATH_TO_FOLDER\19-D_clip.tif<br>
><br>
> The distance of the error made me think that could be something related to<br>
> the coordinate system. In fact, the aux.xml file from the raster layer (in<br>
> jpg format), and which must have been generated in some ESRI software, has<br>
> the EPSG:20790 coordinate system declared as:<br>
><br>
>        <SpatialReference xsi:type="typens:ProjectedCoordinateSystem"><br>
><br>
> <WKT>PROJCS["Lisboa_Hayford_Gauss_IGeoE",GEOGCS["GCS_Datum_Lisboa_Hayford",DATUM["D_Datum_Lisboa_Hayford",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",200000.0],PARAMETER["False_Northing",300000.0],PARAMETER["Central_Meridian",-8.131906111111112],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",39.66666666666666],UNIT["Meter",1.0],AUTHORITY["Esri",102164]]</WKT><br>
>          <XOrigin>-5423400</XOrigin><br>
>          <YOrigin>-14095000</YOrigin><br>
>          <XYScale>450251902.2805022</XYScale><br>
>          <ZOrigin>-100000</ZOrigin><br>
>          <ZScale>10000</ZScale><br>
>          <MOrigin>-100000</MOrigin><br>
>          <MScale>10000</MScale><br>
>          <XYTolerance>0.001</XYTolerance><br>
>          <ZTolerance>0.001</ZTolerance><br>
>          <MTolerance>0.001</MTolerance><br>
>          <HighPrecision>true</HighPrecision><br>
>          <WKID>102164</WKID><br>
>          <LatestWKID>102164</LatestWKID><br>
>        </SpatialReference><br>
><br>
> Simply making a gdal_translate -a_srs EPSG:20790 to the original raster<br>
> layer, produces the following info in the aux.xml:<br>
><br>
>      <PAMDataset><br>
>        <SRS>PROJCS["Lisbon (Lisbon) / Portuguese National<br>
> Grid",GEOGCS["Lisbon<br>
> (Lisbon)",DATUM["Lisbon_1937_Lisbon",SPHEROID["International<br>
> 1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-304.046,-60.576,103.64,0,0,0,0],AUTHORITY["EPSG","6803"]],PRIMEM["Lisbon",-9.131906111111112,AUTHORITY["EPSG","8902"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4803"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",39.66666666666666],PARAMETER["central_meridian",1],PARAMETER["scale_factor",1],PARAMETER["false_easting",200000],PARAMETER["false_northing",300000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","20790"]]</SRS><br>
>        <GeoTransform>  1.6169619321196713e+05,  4.2462876699946506e+00,<br>
> -9.3136981756810518e-03,  3.6360765297460271e+05,  4.1234595692999079e-03,<br>
> -4.2324755960434057e+00</GeoTransform><br>
>      </PAMDataset><br>
><br>
> Making the gdalwarp cutline to this new raster layer, with EPSG:20790<br>
> assigned, already gives the correct output.<br>
><br>
> So, the strange thing is the diferent beaviour between GDAL 2.2.2 and<br>
> 2.3.2. Can this be a bug in GDAL 2.3.2?<br>
><br>
> Here is a sample dataset to test:<br>
><br>
> <a href="https://cld.pt/dl/download/0fcb8923-ed23-45a0-b518-0e5168d0cc0b/19-D.zip" rel="noreferrer" target="_blank">https://cld.pt/dl/download/0fcb8923-ed23-45a0-b518-0e5168d0cc0b/19-D.zip</a><br>
><br>
> Thank you very much.<br>
><br>
> Best regards,<br>
> Pedro Venâncio<br>
><br>
><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>
><br>
<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></blockquote></div>