[GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

[Markus Metz]

On Mon, Feb 25, 2019 at 9:42 PM Even Rouault <even.rouault at spatialys.com>
wrote:
>
> On lundi 25 février 2019 15:10:10 CET Markus Metz wrote:
> > Hi all,
> >
> > GRASS needs some adjustments in order to be compatible with PROJ 6 +
GDAL
> > 2.5
> >
> > The plain text file "share/proj/epsg" no longer exists. This file is
> > currently required by the GUI location wizard to retrieve a list of
known
> > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function
> > proj_get_codes_from_database(). I suggest to enhance g.proj with a new
> > option "list_codes_auth" which will print a list of codes for the given
> > autority name (EPSG, IGNF, etc.). This option can be made backwards
> > compatible to read "share/proj/epsg" with PROJ versions up to 5. The
> > location wizard can then use this new output of g.proj to construct a
list
> > of known EPSG codes.
>
> If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an
> enhanced version of proj_get_codes_from_database(), that will retrieve
> more information besides the code: name, area of use, type of CRS
(geographic,
> projected, compound, etc...)
> in a very fast way (you can do the same with
proj_get_codes_from_database(),
> and constructing a CRS for each code, but this is slower)

Thanks for the hint!

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.

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.

The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not
compatible with PROJ 6.

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.

I will look at the issues mentioned below in the next few days, should not
be too much work I hope.

Markus M
>
> >
> > We need to take care of axis order if a CRS is created from EPSG because
> > the axis order can now be northing, easting instead of traditional
easting,
> > northing. Maybe it is enough to enforce +axis=enu,
>
> You can only use this if you use a PROJ string when invokating
> proj_create_crs_to_crs(), and this is the default axis order for PROJ
string anyway.
>
> > or to use GDAL's
> > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)
>
> Yes, if you use GDAL OGRSpatialReference this is the way to go.
>
> If you don't use GDAL SRS and just PROJ API, you might also just reuse
>
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298
>
> which is called for the source and target CRS of the PJ object created
> with proj_create_crs_to_crs()
>
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190307/b2fa17cd/attachment-0001.html>