<div dir="ltr"><br><br>On Thu, Mar 7, 2019 at 5:17 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>><br>><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>><br>> Thanks for the hint!<br>><br><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>Unfortunately it does not work yet with PROJ 4 because new fns have been added to the old proj_api.h...</div><div><br></div><div>Markus M</div><div><br></div>><br>> 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>><br>> The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not compatible with PROJ 6.<br>><br>> 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>><br>> I will look at the issues mentioned below in the next few days, should not be too much work I hope.<br>><br>> Markus M<br>> ><br>> > ><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>