<div dir="ltr"><br><br>On Thu, Nov 7, 2019 at 6:47 PM Martin Landa <<a href="mailto:landa.martin@gmail.com">landa.martin@gmail.com</a>> wrote:<br>><br>> Hi,<br>><br>> čt 7. 11. 2019 v 15:17 odesílatel Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> napsal:<br>> > PROJ 6 support is not yet finished in GRASS. Currently it sort of works in master and relbr78, but I expect troubles because GRASS is heavily relying on deprecated proj strings as CRS definitions. This is becoming problematic e.g. when creating locations from GDAL/OGR datasets because GRASS goes from OGR spatialreference through proj string to GRASS definition.<br>><br>> OSGeo4W packages are planned to be switched to GDAL3/PROJ6 soon, are<br>> you aware of any known bugs?<br><div><br></div><div>yes, EPSG:3857 is causing trouble. This is the WGS 84 / Pseudo-Mercator projection on a sphere with radius 6378137 that needs special treatment which no longer works with GRASS + PROJ 6 + GDAL 3.</div><div><br></div><div>g.proj epsg=3857 -p gives me</div><div>-PROJ_INFO-------------------------------------------------<br>name : WGS 84 / Pseudo-Mercator<br>datum : wgs84<br>ellps : wgs84<br>proj : merc<br>lat_ts : 0<br>lon_0 : 0<br>x_0 : 0<br>y_0 : 0<br>k : 1<br>wktext : defined<br>no_defs : defined<br>-PROJ_EPSG-------------------------------------------------<br>epsg : 3857<br>-PROJ_UNITS------------------------------------------------<br>unit : meter<br>units : meters<br>meters : 1<br></div><div><br></div><div>which is wrong because it should be a Mercator projection on a sphere, not an ellipsoid</div><div><br></div><div>from <a href="https://proj.org/operations/projections/webmerc.html">https://proj.org/operations/projections/webmerc.html</a>:</div><div>"This is a variant of the regular Mercator projection, except that the computation is done on a sphere, using the semi-major axis of the ellipsoid."</div><div>and</div><div>"All parameters for the projection are optional, except the ellipsoid definition, which is WGS84 for the typical use case of EPSG:3857."</div><div>and</div><div>"+ellps=<value><br><br> See proj -le for a list of available ellipsoids.<br><br> Defaults to “GRS80”."</div><div><br></div><div>projinfo -o PROJ EPSG:3857</div><div>gives me<br>PROJ.4 string:<br>+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs +type=crs</div><div> </div><div>that is correct, but unfortunately not returned by GDAL's function OSRExportToProj4() which is now deprecated. That means GRASS needs to avoid OSRExportToProj4() with GDAL 3+:</div><div><a href="https://gdal.org/doxygen/ogr__srs__api_8h.html#ae410c0b0bb86b7d7903193828db8a1f5">https://gdal.org/doxygen/ogr__srs__api_8h.html#ae410c0b0bb86b7d7903193828db8a1f5</a></div><div><dl class="gmail-section gmail-warning"><dt>--><br></dt><dt>Warning</dt><dd>Use of this function is
discouraged. Its behaviour in GDAL >= 3 / PROJ >= 6 is
significantly different from earlier versions. In particular +datum will
only encode WGS84, NAD27 and NAD83, and +towgs84/+nadgrids terms will
be missing most of the time. PROJ strings to encode CRS should be
considered as a legacy solution. Using a AUTHORITY:CODE or WKT
representation is the recommended way.</dd><dt><--<br></dt></dl></div><div> Thus GRASS should use an SRID or WKT instead of proj4 strings.</div><div><br></div><div>Markus M<br></div><div><br></div><div>></div>> > For GDAL 3 + PROJ 6, GRASS should switch to WKT as main CRS definition format, ideally also storing a WKT definition next to PROJ_INFO. When creating locations from GDAL/OGR datasets, GRASS should go from OGR spatialreference through WKT to GRASS definition, and probably use the new PROJ6+ methods as much as possible.<br>><br>> Yes, good topic for<br>> <a href="https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Prague_2019">https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Prague_2019</a><br>> :-)<br>><br>> > When getting the projection info of a GRASS location, GRASS should then check in that order 1) WKT, 2) EPSG or other SRID, 3) GRASS native definition (which deviated from proj definition some decades ago).<br>> ><br>> > That means, g.proj, r.in.gdal, r.external, v.in.ogr, v.external need updates, and the mechanism of conversion between different formats of CRS definitions in lib/proj needs to be largely rewritten.<br>><br>> This task for next stable GRASS release (7.10?) I guess.<br>><br>> Ma<br>><br>> --<br>> Martin Landa<br>> <a href="http://geo.fsv.cvut.cz/gwiki/Landa">http://geo.fsv.cvut.cz/gwiki/Landa</a><br>> <a href="http://gismentors.cz/mentors/landa">http://gismentors.cz/mentors/landa</a></div>