<div dir="ltr"><div><div><br><br>On Mon, Aug 28, 2017 at 9:11 PM, Jeshua Lacock <<a href="mailto:jeshua@3dtopo.com">jeshua@3dtopo.com</a>> wrote:<br>><br>><br>> > On Aug 27, 2017, at 8:54 PM, Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br>> ><br>> > On Tue, Aug 22, 2017 at 7:46 PM, Jeshua Lacock <<a href="mailto:jeshua@3dtopo.com">jeshua@3dtopo.com</a>> wrote:<br>> >><br>> >> To hopefully help troubleshoot; I just reprojected one of the raster tiles (from epsg: 3857), into the source location of one of the lonlat vectors (reverse projections from my OP), and the datasets are offset by the same distances. Since the dimensions of the raster are being changed (by r.proj), it leads me to think it must be a datum or coordinate system misalignment and not a projection issue.<br>> ><br>> > I have the same problem, working with NAIP imagery. It is related to:<br>> > <a href="https://trac.osgeo.org/grass/ticket/2229">https://trac.osgeo.org/grass/ticket/2229</a><br>> ><br>> > I have to remove nadgrids: @null from the PROJ_INFO file to be able to<br>> > reproject into that location, but then it is shifted. gdalwarp helps.<br><br>EPSG:3857 is problematic because it<br>"Uses spherical development of ellipsoidal coordinates. Relative to WGS 84 / World Mercator (CRS code 3395) errors of 0.7 percent in scale and differences in northing of up to 43km in the map (equivalent to 21km on the ground) may arise."<br><br>Therefore you would need to use the WKT EXTENSION PROJ4:<br><br>+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +wktext  +no_defs<br><br></div>without +nadgrids=@null<br><br></div>In GRASS, you could use this proj4 definition to create a new location, then import the data (the -o flag might be needed), then reproject to the desired CRS.<br><div><br></div><div>Considering this particular CRS (EPSG:3857), it is strange than gdalwarp works while GRASS reprojection does not work because GRASS uses GDAL to convert WKT to proj4, then to GRASS terminology. Some debugging is needed to figure out why within GRASS, the conversion from WKT to proj4 (using GDAL) produces wrong results.<br></div><div><br></div><div>Markus M<br></div><div><br><div>><br>> Hi Anna!<br>><br>> Thank you very much for confirming that! I am working with the NAIP imagery as well.  :)<br>><br>> I have found that their original Geotiff assets work perfectly.<br>><br>> In fact, I was very happy to stumble on to the fact that the complete NAIP archive (~250 terabytes) is available as a bucket drive on Amazon Web Services (AWS). So I setup GRASS instances to process the tiles, then download the processed, reprojected images compressed as JP2s. I am paying for the bandwidth and compute time, but I think its worth it for my purposes. I’ll be able to process and download the imagery I need in about 60 days compared to over 300 days without AWS!<br>><br>><br>> Cheers,<br>><br>> Jeshua Lacock<br>> Founder/Engineer<br>> <3DTOPO.com><br>> GlassPrinted.com<br>><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br></div></div></div>