<div dir="ltr"><br><br>On Mon, Feb 25, 2019 at 9:42 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> On lundi 25 février 2019 15:10:10 CET Markus Metz wrote:<br>> > Hi all,<br>> ><br>> > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL<br>> > 2.5<br>> ><br>> > The plain text file "share/proj/epsg" no longer exists. This file is<br>> > currently required by the GUI location wizard to retrieve a list of known<br>> > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function<br>> > proj_get_codes_from_database(). I suggest to enhance g.proj with a new<br>> > option "list_codes_auth" which will print a list of codes for the given<br>> > autority name (EPSG, IGNF, etc.). This option can be made backwards<br>> > compatible to read "share/proj/epsg" with PROJ versions up to 5. The<br>> > location wizard can then use this new output of g.proj to construct a list<br>> > of known EPSG codes.<br>><br>> If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an<br>> enhanced version of proj_get_codes_from_database(), that will retrieve<br>> more information besides the code: name, area of use, type of CRS (geographic,<br>> projected, compound, etc...)<br>> in a very fast way (you can do the same with proj_get_codes_from_database(),<br>> and constructing a CRS for each code, but this is slower)<br><div><br></div><div>Thanks for the hint!</div><div><br></div><div>I have added a new option list_codes to g.proj that will print codes, names, and proj definitions for the given authority in trunk r74174. This new option works with PROJ 4, 5, and 6.</div><div><br></div><div>The GUI is now (r74175) no longer reading the file share/proj/epsg which no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get the list of EPSG codes. This is important e.g. for the location wizard to provide a list of known EPSG codes.<br></div><div><br></div><div>The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not compatible with PROJ 6.</div><div><br></div><div>There are other authorities besides EPSG, these are supported with g.proj list_codes= if compiled against PROJ 6. Maybe we should support them too.<br></div><div><br></div><div>I will look at the issues mentioned below in the next few days, should not be too much work I hope.</div><div><br></div><div>Markus M<br></div><div>></div>> ><br>> > We need to take care of axis order if a CRS is created from EPSG because<br>> > the axis order can now be northing, easting instead of traditional easting,<br>> > northing. Maybe it is enough to enforce +axis=enu,<br>><br>> You can only use this if you use a PROJ string when invokating<br>> proj_create_crs_to_crs(), and this is the default axis order for PROJ string anyway.<br>><br>> > or to use GDAL's<br>> > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)<br>><br>> Yes, if you use GDAL OGRSpatialReference this is the way to go.<br>><br>> If you don't use GDAL SRS and just PROJ API, you might also just reuse<br>> <a href="https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298">https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298</a><br>><br>> which is called for the source and target CRS of the PJ object created<br>> with proj_create_crs_to_crs()<br>> <a href="https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357">https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357</a><br>><br>> Even<br>><br>> --<br>> Spatialys - Geospatial professional services<br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a></div>