On Fri, 21 Feb 2020 at 13:13, Arun Isaac <arunis...@systemreboot.net> wrote:
> >> > 2. a regression of r-rgdal introduced by your commit > >> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 > >> > >> Replacing proj.4 with proj in the r-rgdal package seems to fix this > >> regression. Can you confirm? > > > > Maybe, but it is not what the user expects. Upstream explicitly > > mentions proj.4, see [1]. > > > [1] https://cloud.r-project.org/web/packages/rgdal/index.html > > No, upstream says that both proj (aka proj6) and proj.4 are > supported. Quoting [1], > > "From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..." I agree, but I was referring to "access to projection/transformation operations from the 'PROJ.4' library." or "Windows and Mac Intel OS X binaries (including 'GDAL', 'PROJ.4' and 'Expat') are provided on 'CRAN'." Well, your comment below says my remark here is irrelevant. :-) > > The question is: why proj instead of proj.4 in libgeotiff? > > The bug [1] cannot be solved using proj.4, why? > > proj and proj.4 are different versions of the same software, with proj > being the newer version. See > https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely > deprecate our proj.4 package and replace all occurrences of proj.4 with > proj. Thank you for the pointer, I was not aware. Well, I agree. Let replace all the dependencies of proj.4 by proj and deprecate our proj.4 package. --8<---------------cut here---------------start------------->8--- $ guix graph -t reverse-package proj.4 \ | grep label | cut -d'=' -f2 | cut -d',' -f1 "proj.4@4.9.3" "r-sf@0.8-0" "r-spdep@1.1-3" "r-monocle3@0.1.2" "r-cicero-monocle3@1.3.2-1.fa2fb65" "r-adegenet@2.1.2" "r-rmetasim@3.1.7" "r-hierfstat@0.04-22" "r-pegas@0.12" "r-rgdal@1.4-8" "libosmium@2.14.2" "osm2pgsql@0.96.0" "mapnik@3.0.18" "python2-mapnik@3.0.16" "xygrib@1.2.6.1" "spatialite-gui@1.7.1" "libspatialite@4.3.0a" "libgaiagraphics@0.5" --8<---------------cut here---------------end--------------->8--- Thanks, simon
