roadbump coming: Proj 5 release #545

rsbivand · 2017-11-09T13:28:15Z

Announced here; I already asked for a version number change in the github master to permit downstream conditioning. It looks as though proj-config will be available, but we'd need to test for it.

edzer · 2017-11-10T16:42:54Z

The question you asked there is a good one; let me know when it makes sense to start testing with a release candidate.

rsbivand · 2017-11-17T08:36:41Z

Now with a migration guide - post. My reply.

edzer · 2017-11-17T08:45:48Z

Looks to me like a change of similar magnitude as from sp to sf.

rsbivand · 2017-11-17T09:21:27Z

Lots of consequences - we are trapped by having to wait for gdal to upgrade to suit new proj as far as new releases are concerned. I've posted a more detailed question on the proj list for no-inverse projections.

rsbivand · 2017-11-17T09:28:02Z

Just found a description.

rsbivand · 2017-11-17T09:37:58Z

Actually, perhaps you could "reach out" (very modern) to them in relation to stars? If they follow through on spatio-temporal and epoch, stars might benefit from being involved at the beginning of st projection support ... just a thought. Otherwise they may well see everybody as simply rejecting change? A talk in Münster?

edzer · 2017-11-17T09:41:25Z

Thanks, great idea!

rsbivand · 2017-11-17T12:21:44Z

Could we help Kristian set up a valid and installed proj-config? I've found an installed {--prefix}/lib/pkgconfig/proj.pc file, but no further build of that to proj-config. Does anyone know how to create a stand-alone script?

$ pkg-config --exists proj
$ echo $?
1
$ pkg-config --with-path=/usr/local/lib/pkgconfig --exists proj
$ echo $?
0
$ pkg-config --with-path=/usr/local/lib/pkgconfig --modversion proj
4.9.3
$ pkg-config --with-path=/usr/local/lib/pkgconfig --libs proj 
-L/usr/local/lib -lproj 
$ pkg-config --with-path=/usr/local/lib/pkgconfig --cflags-only-I proj
-I/usr/local/include

work, but aren't obvious unless /usr/local/lib/pkgconfig is known. Can we work with this and a configure-arg for --with-path, falling back on the include and libs configure args if it fails?

rundel · 2017-11-17T16:59:04Z

geos's geos-config is fairly straight forward and would be a good model. It is just a shell script that is modified by the Makefile - see https://github.com/OSGeo/geos/blob/master/tools/geos-config.in

…

On Fri, Nov 17, 2017 at 7:21 AM Roger Bivand ***@***.***> wrote: Could we help Kristian set up a valid and installed proj-config? I've found an installed {--prefix}/lib/pkgconfig/proj.pc file, but no further build of that to proj-config. Does anyone know how to create a stand-alone script? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#545 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQuBiFB--OfOQuxED7WZh8PbXZb7kBzks5s3XpYgaJpZM4QX929> .

rsbivand · 2018-02-16T11:24:16Z

At PROJ.4 5.0.0 RC3 (didn't test before), there is a CMD check failure in sf:

Running the tests in ‘tests/plot.R’ failed.
Last 13 lines of output:
  > plot(st_transform(nc, merc), bgMap = g)
  Warning message:
  plotting the first 10 out of 15 attributes; use max.plot = 15 to plot all 
  > 
  > m = st_make_grid()
  > st_crs(m) = NA_crs_
  > m = st_segmentize(m, 2)
  > st_crs(m) = 4326
  > plot(m, axes = TRUE)
  > g = st_transform(m, st_crs("+proj=ortho +lat_0=30 +lon_0=45"), check = TRUE)
  > plot(g, axes = TRUE)
  Error in CPL_geos_is_empty(st_geometry(x)) : 
    Evaluation error: IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4.
  Calls: plot ... plot.sfc_POLYGON -> st_is_empty -> CPL_geos_is_empty -> .Call
  Execution halted

Using rgdal, the error seems to come from:

> sp_m <- as(m, "Spatial")
> summary(sp_m)
Object of class SpatialPolygons
Coordinates:
   min max
x -180 180
y  -90  90
Is projected: FALSE 
proj4string :
[+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0]
> sp_p <- spTransform(sp_m, CRS("+proj=ortho +lat_0=30 +lon_0=45"))
non finite transformation detected:
[1] -180  -90  Inf  Inf
Error in .spTransform_Polygon(input[[i]], to_args = to_args, from_args = from_args,  : 
  failure in Polygons 1 Polygon 1 points 1
In addition: Warning message:
In .spTransform_Polygon(input[[i]], to_args = to_args, from_args = from_args,  :
  25 projected point(s) not finite

Note that m is plottable, and without st_segmentize it works too. It seems to be st_segmentize prior to st_transform, so the trick of pretending that m is planar and using GEOS maybe pushes coordinates out of the spherical domain. Is this a precision issue?

rsbivand · 2018-02-16T12:31:12Z

Aha, segmentize is in GDAL - what precision model is used there? And:

> library(lwgeom)
Linking to liblwgeom 2.4.1 r16012, GEOS 3.6.2, proj.4 5.0.0
> g = st_transform_proj(m, st_crs("+proj=ortho +lat_0=30 +lon_0=45"), check = TRUE)
transform: couldn't project point (-180 -90 0): tolerance condition error (-20)
Error in CPL_lwgeom_transform(x, c(st_crs(x)$proj4string, crs)) : 
  lwgeom error

This, and the rgdal::spTransform() errors are unchanged, that is, they fail for PROJ.4 5.0.0RC3 and 4.9.3. My sf is:

> sf_extSoftVersion()
          GEOS           GDAL         proj.4         lwgeom GDAL_with_GEOS 
       "3.6.2"        "2.2.3"        "5.0.0"             NA         "true" 
> lwgeom_extSoftVersion()
        lwgeom           GEOS         proj.4 
"2.4.1 r16012"        "3.6.2"        "5.0.0"

edzer · 2018-02-16T15:29:30Z

Trying to run check in a container with 5.0.0RC3, and

< Linking to GEOS 3.6.2, GDAL 2.2.3, proj.4 5.0.0

I can't reproduce the plot error, but do see some differences (which may be due to lwgeom taking another code route), and an error in testthat.

Step 33/34 : RUN R CMD check --no-build-vignettes --no-manual --as-cran --run-dontrun sf_*tar.gz
 ---> Running in 770a9a56b6b8
* using log directory '//sf.Rcheck'
* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: ASCII
* using options '--run-dontrun --no-manual --no-build-vignettes --as-cran'
* checking for file 'sf/DESCRIPTION' ... OK
* this is package 'sf' version '0.6-1'
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Edzer Pebesma <edzer.pebesma@uni-muenster.de>'

Package has a VignetteBuilder field but no prebuilt vignette index.
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package 'sf' can be installed ... OK
* checking installed package size ... NOTE
  installed size is  9.9Mb
  sub-directories of 1Mb or more:
    libs     6.1Mb
    sqlite   1.5Mb
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking contents of 'data' directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking line endings in shell scripts ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking compilation flags in Makevars ... OK
* checking for GNU extensions in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking files in 'vignettes' ... WARNING
Files in the 'vignettes' directory but no files in 'inst/doc':
  'sf.fig', 'sf1.Rmd', 'sf2.Rmd', 'sf2.png', 'sf3.Rmd', 'sf4.Rmd',
    'sf5.Rmd', 'sf6.Rmd', 'sf_xfig.png'
* checking examples ... OK
* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
  Running 'aggregate.R'
  Comparing 'aggregate.Rout' to 'aggregate.Rout.save' ...4c4
< Linking to GEOS 3.6.2, GDAL 2.2.3, proj.4 5.0.0
---
> Linking to GEOS 3.5.1, GDAL 2.2.1, proj.4 4.9.3
  Running 'cast.R'
  Comparing 'cast.Rout' to 'cast.Rout.save' ... OK
  Running 'crs.R'
  Comparing 'crs.Rout' to 'crs.Rout.save' ...76c76
< [2,] 111319.5  1.105800e+05
---
> [2,] 111319.5  1.113251e+05
  Running 'dist.R'
  Comparing 'dist.Rout' to 'dist.Rout.save' ... OK
  Running 'dplyr.R'
  Comparing 'dplyr.Rout' to 'dplyr.Rout.save' ...76,79c76,79
< 1 (0,0.1]           0.0760 (((-77.96073 34.18924, -77.96587 34.24229, -77.9752~
< 2 (0.1,0.12]        0.112  (((-84.29104 35.21054, -84.22594 35.2616, -84.17973~
< 3 (0.12,0.15]       0.134  (((-76.54427 34.58783, -76.55515 34.61066, -76.5377~
< 4 (0.15,0.25]       0.190  (((-76.64705 34.90633, -76.62562 34.89065, -76.7502~
---
> 1 (0,0.1]           0.0760 (((-77.96073 34.18924, -77.96587 34.24229, -77.9752…
> 2 (0.1,0.12]        0.112  (((-84.29104 35.21054, -84.22594 35.2616, -84.17973…
> 3 (0.12,0.15]       0.134  (((-76.54427 34.58783, -76.55515 34.61066, -76.5377…
> 4 (0.15,0.25]       0.190  (((-76.64705 34.90633, -76.62562 34.89065, -76.7502…
189c189
< 1 2.589362e-06 person/m^2 (((834893.7 95747.49, 833834.2 98254.6, 835420.2 986~
---
> 1     2.589362e-06 (((834893.7 95747.49, 833834.2 98254.6, 835420.2 98655.72, …
211c211
< 1       329962 person (((834893.7 95747.49, 833834.2 98254.6, 835420.2 98655.7~
---
> 1              329962 (((834893.7 95747.49, 833834.2 98254.6, 835420.2 98655.7…
  Running 'empty.R'
  Comparing 'empty.Rout' to 'empty.Rout.save' ... OK
  Running 'gdal_geom.R'
  Comparing 'gdal_geom.Rout' to 'gdal_geom.Rout.save' ...100c100
< GDAL has 63 drivers
---
> GDAL has 80 drivers
240,244c240,244
< [1,] 1752589760 0.114
< [2,]  942326000 0.061
< [3,] 2192666235 0.143
< [4,] 1069677150 0.070
< [5,] 2342306011 0.153
---
> [1,] 1760244757 0.114
> [2,]  946435667 0.061
> [3,] 2202248253 0.143
> [4,] 1074351919 0.070
> [5,] 2352539533 0.153
  Running 'geos.R'
  Comparing 'geos.Rout' to 'geos.Rout.save' ... OK
  Running 'graticule.R'
  Comparing 'graticule.Rout' to 'graticule.Rout.save' ... OK
  Running 'grid.R'
  Comparing 'grid.Rout' to 'grid.Rout.save' ... OK
  Running 'plot.R'
  Comparing 'plot.Rout' to 'plot.Rout.save' ... OK
  Running 'read.R'
  Comparing 'read.Rout' to 'read.Rout.save' ...334c334
< Reading layer `Parcely' from data source `/sf.Rcheck/sf/gml/20170930_OB_530964_UKSH.xml.gz' using driver `GML'
---
> Reading layer `Parcely' from data source `/home/edzer/git/sf.Rcheck/sf/gml/20170930_OB_530964_UKSH.xml.gz' using driver `GML'
352c352
< Reading layer `Parcely' from data source `/sf.Rcheck/sf/gml/20170930_OB_530964_UKSH.xml.gz' using driver `GML'
---
> Reading layer `Parcely' from data source `/home/edzer/git/sf.Rcheck/sf/gml/20170930_OB_530964_UKSH.xml.gz' using driver `GML'
  Running 'roundtrip.R'
  Comparing 'roundtrip.Rout' to 'roundtrip.Rout.save' ... OK
  Running 'sfc.R'
  Comparing 'sfc.Rout' to 'sfc.Rout.save' ...377c377
< bbox:           xmin: -10018760 ymin: 4139376 xmax: -8905533 ymax: 4275514
---
> bbox:           xmin: -10018760 ymin: 4163894 xmax: -8905533 ymax: 4300640
380,381c380,381
< POINT (-10018764 4139376)
< POINT (-8905533 4275514)
---
> POINT (-10018764 4163894)
> POINT (-8905533 4300640)
385c385
< "3.6.2" "2.2.3" "5.0.0" 
---
> "3.5.1" "2.2.1" "4.9.3" 
657c657
< Reading layer `nc' from data source `/sf.Rcheck/sf/shape/nc.shp' using driver `ESRI Shapefile'
---
> Reading layer `nc' from data source `/home/edzer/git/sf.Rcheck/sf/shape/nc.shp' using driver `ESRI Shapefile'
860c860
< 6370580 6370784 6370940 6370940 6371076 6371529 
---
>       1       1       1       1       1       1 
  Running 'sfg.R'
  Comparing 'sfg.Rout' to 'sfg.Rout.save' ... OK
  Running 'testthat.R'
 ERROR
Running the tests in 'tests/testthat.R' failed.
Last 13 lines of output:
  34: tryCatch(withCallingHandlers({    eval(code, test_env)    if (!handled && !is.null(test)) {        skip_empty()    }}, expectation = handle_expectation, skip = handle_skip, warning = handle_warning,     message = handle_message, error = handle_error), error = handle_fatal,     skip = function(e) {    })
  35: test_code(NULL, exprs, env)
  36: source_file(path, new.env(parent = env), chdir = TRUE, wrap = wrap)
  37: force(code)
  38: with_reporter(reporter = reporter, start_end_reporter = start_end_reporter,     {        lister$start_file(basename(path))        source_file(path, new.env(parent = env), chdir = TRUE,             wrap = wrap)        end_context()    })
  39: FUN(X[[i]], ...)
  40: lapply(paths, test_file, env = env, reporter = current_reporter,     start_end_reporter = FALSE, load_helpers = FALSE, wrap = wrap)
  41: force(code)
  42: with_reporter(reporter = current_reporter, results <- lapply(paths,     test_file, env = env, reporter = current_reporter, start_end_reporter = FALSE,     load_helpers = FALSE, wrap = wrap))
  43: test_files(paths, reporter = reporter, env = env, stop_on_failure = stop_on_failure,     stop_on_warning = stop_on_warning, wrap = wrap)
  44: test_dir(path = test_path, reporter = reporter, env = env, filter = filter,     ..., stop_on_failure = stop_on_failure, stop_on_warning = stop_on_warning,     wrap = wrap)
  45: test_package_dir(package = package, test_path = test_path, filter = filter,     reporter = reporter, ..., stop_on_failure = stop_on_failure,     stop_on_warning = stop_on_warning, wrap = wrap)
  46: test_check("sf")
  An irrecoverable exception occurred. R is aborting now ...
  Segmentation fault (core dumped)
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... WARNING
Package vignettes without corresponding PDF/HTML:
   'sf1.Rmd'
   'sf2.Rmd'
   'sf3.Rmd'
   'sf4.Rmd'
   'sf5.Rmd'
   'sf6.Rmd'

* checking running R code from vignettes ...
   'sf1.Rmd' using 'UTF-8' ... OK
   'sf2.Rmd' using 'UTF-8' ... OK
   'sf3.Rmd' using 'UTF-8' ... OK
   'sf4.Rmd' using 'UTF-8' ... OK
   'sf5.Rmd' using 'UTF-8' ... OK
   'sf6.Rmd' using 'UTF-8' ... OK
 NONE
* checking re-building of vignette outputs ... SKIPPED
* DONE

Status: 1 ERROR, 2 WARNINGs, 2 NOTEs
See
  '//sf.Rcheck/00check.log'
for details.

rsbivand · 2018-02-16T15:49:50Z

Yes, I saw that too, and backed out my tidyverse to CRAN releases (unsure why). I was running reverse dep checks for rgdal, and as sf Suggests rgdal, it gets drawn in. I'm for that reason testing 1.6.0 from CRAN, not current master.

edzer · 2018-02-17T16:57:13Z

When debugging I see numerous errors from gdal calling proj; are there some signs somewhere that gdal 2.2.3 should work with proj.4 5.0.0, or am I simply being naive here?

rsbivand · 2018-02-17T17:44:22Z

As the 5.0.0 RCs only started appearing recently, my guess is that not much (yet). From the GDAL logs, almost all of the commits since 2.2.3 are issues in drivers that themselves link to PROJ.4; I don't see any mention of "5.0.0" at all in the log. You've also got me thinking that while I'm OK with trying to make some progress on the rgdal/PROJ.4 code, rgdal is still very vulnerable to driver code with its own relationship with PROJ.4. I just found a proj-4.9.3 binary on my desktop brought in by qt-mobility-location, which I can't recall installing. Transition to 5.0.0 looks like being fun ...

rsbivand · 2018-02-20T10:25:24Z

See also an RC2 issue in PostGIS which looks like what I saw. The fix may be

I've solved it locally by resetting pj_errno to 0 after an error

and commented from PROJ.4

edzer · 2018-02-20T10:31:20Z

OK, maybe wait for RC4? Or test against the dev version?

rsbivand · 2018-02-20T11:54:22Z

I've recompiled proj (master) and gdal (and lwgeom), but still see:

> g = st_transform(m, st_crs("+proj=ortho +lat_0=30 +lon_0=45"), check = TRUE)
> plot(g, axes = TRUE)
Error in CPL_geos_is_empty(st_geometry(x)) : 
  Evaluation error: IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4.
> library(lwgeom)
Linking to liblwgeom 2.4.1 r16012, GEOS 3.6.2, proj.4 5.0.0
> g1 = st_transform_proj(m, st_crs("+proj=ortho +lat_0=30 +lon_0=45"), check = TRUE)
transform: couldn't project point (-180 -90 0): tolerance condition error (-20)
Error in CPL_lwgeom_transform(x, c(st_crs(x)$proj4string, crs)) : 
  lwgeom error

The spTransform error is also the same.

rsbivand · 2018-02-26T14:01:53Z

Found the sf/tests/testthat.R crash for st_proj_units() - 500 does add a double to the struct, so I've changed rgdal, and PR #652 for sf. The good news, the >=500 proj.h interface has proper listing functions, which become mandatory next time round.

rsbivand · 2018-03-01T10:44:37Z

As of RC6, unresolved issue with webmercator (which is a worse can of worms than coordinate order). See this thread, truncated at month shift (starts in Feb, but develops today - nadgrids=@null exposes the difference between the spheroid and implied but unstated ellipsoid giving a 10km vertical displacement ("jump into the lithosphere") and offsetting the 2D coordinates.

rsbivand · 2018-03-01T18:38:20Z

Latest at, reverting a cs2cs PR, but I think leaving the same exposed in pt_transform() (unchecked)? What might the case look like for us? They're going to let 5.0.0 go and have a bug-fix release in a month.

edzer · 2018-03-03T12:24:11Z

Proj 5 has been released now.

edzer · 2018-03-12T14:16:03Z

Oops! did CRAN spontaneously jump to 5.0.0 on linux & solaris?

rsbivand · 2018-03-12T16:35:55Z

I see GEOS 3.6.2, GDAL 2.2.3, proj.4 5.0.0 for 3.4.4 RC, and gcc and clang debian devel. Fedora gcc and clang devel have GEOS 3.6.1, GDAL 2.1.3, proj.4 4.9.3. Debian buster and sid have 5.0.0 as current. The latest for fedora is 4.9.3. I don't think that that is the source of the error, though.

rsbivand · 2018-03-12T16:45:15Z

Evaluation error: IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4.
  Calls: plot ... plot.sfc_POLYGON -> st_is_empty -> CPL_geos_is_empty -> .Call

looks very familiar - it cropped up in st_is_valid() throwing error instead of returning NA #501. But the GEOS version doesn't agree ... no, it was my comment above from three weeks ago ...

edzer · 2018-03-12T16:46:59Z

I didn't know these platforms would update so fast; in particular debian.

The "sorting out" commit message above has been sorted out: even if sf links to proj 5, it will use the GDAL interface to project, and GDAL may as well (and did for me) still link to proj 4.9.x. The comparison was equality of rgdal and sf, but was different (interestingly: for epsg 3857 - I guess not one of the least used projections). Would be good if sf could report which proj version gdal links to.

Yeah, I saw that error on the debian r-devel platforms; can't reproduce it (GEOS mismatch?)

ateucher · 2018-03-12T17:23:24Z

Homebrew has also updated to 5.0.0:

~ $ brew info proj
proj: stable 5.0.0 (bottled), HEAD
Cartographic Projections Library
http://proj4.org/
/usr/local/Cellar/proj/4.9.3 (54 files, 6MB) *
  Poured from bottle on 2017-10-18 at 14:01:59
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/proj.rb
==> Options
--with-vdatum
	Install vertical datum files (~380 MB)
--HEAD
	Install HEAD version

edzer · 2018-03-12T17:48:50Z

cool - thanks! Well, sf 0.6-1 is submitted now, let's see.

rsbivand · 2018-03-13T11:48:58Z

  s = st_sfc(st_point(c(1,1)), st_point(c(10,10)), st_point(c(5,5)), crs = 4326)
  s1.tr = st_transform(s, 3857)
  
  sp = as(s, "Spatial")
  sp.tr = rgdal::spTransform(sp, CRS("+init=epsg:3857"))
  s2.tr = st_as_sfc(sp.tr)
  library(lwgeom)
# Linking to liblwgeom 2.5.0dev r16016, GEOS 3.6.2, proj.4 5.0.0
  s3.tr <- st_transform_proj(s, 3857)
  all.equal(st_coordinates(s2.tr), st_coordinates(s3.tr))
# [1] TRUE
  all.equal(st_coordinates(s1.tr), st_coordinates(s3.tr))
# [1] "Mean relative difference: 0.003329494"

The 5.0.0 proj route gives different 3857 coordinates in rgdal::spTransform() and lwgeom::st_transform_proj() (these two are equal) compared to sf::st_transform(), which is equal to with 4.9.3 rgdal::spTransform().

We need a cs2cs version. Something like:

$ echo 1 1 | cs2cs +init=epsg:4326 +to +init=epsg:3857
111319.49	110579.96 -6.46
# 5.0.0

$ echo 1 1 | cs2cs +init=epsg:4326 +to +init=epsg:3857
111319.49	111325.14 0.00
# 4.9.3

but:

$ echo 1 1 0 0 | cct +proj=pipeline +step +init=epsg:3857
  111319.4908    111325.1429        0.0000        0.0000

which is what we want!!

$ echo 1 1 | cs2cs +init=epsg:4326 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m 
111319.49	111325.14 0.00

Issue OSGeo/PROJ#834 says that we need to drop +nadgrids=@null for 3857, until a future bug-fix release, for pj_transform() and cs2cs.

edzer · 2018-03-13T12:13:39Z

Heads up to @tim-salabim and @timelyportfolio -- should we hack this, and have st_crs(3857) strip the +nadgrids=@null, or rather have it issue a warning in case of 5.0.0? I'd guess a new proj release will get out pretty soon.

tim-salabim · 2018-03-13T12:51:05Z

Not necessary I think. For all vector data leafletjs expects layers to be in 4326. Unless there is a problem going from 3857 to 4326 (which we would do if data comes in 3857) there is nothing we can do.
For reference, this is where we define all projections. In case we need to hack something, then I think it should be there. Do you agree?
A warning on the sf side would be a good idea though to save people time figuring out what's happening.

rsbivand · 2018-03-13T13:10:46Z

Fix for rgdal::checkCRSArgs() committed to svn in R/Class-CRSx.R - both nadgrids and init need to be removed after expansion and before pj_transform, as it seems that init pulls nadgrids back in again if still present.

tim-salabim · 2018-03-13T13:15:55Z

For completeness, 3857 is only needed for rasters

edzer · 2018-03-15T20:01:30Z

@rsbivand I think the place to fix proj errors is in proj, not in sf. 5.0.1 won't take long.

rsbivand · 2018-03-15T20:04:15Z

OK. I'm just trying to keep on top of this, and to be able to test that 5.0.1 actually fixes this when it comes. I haven't built from the post-release master.

rsbivand · 2018-03-16T19:20:08Z

From the PROJ.4 ML:

If you plan on submitting a bug fix for 5.0.1, please do so before March 21st.

rsbivand · 2018-03-16T19:24:13Z

@Nowosad not a problem - rgdal only needed attention to projInfo("units"). rgdal as submitted to CRAN and current R-Forge thrunk (1.2-18) is OK with 5.0.0 (4.10.0 will not happen, they dropped the idea of continuing PROJ.4 4., have gone to PROJ.4 5.0.. See the proj ML. The API will change and will be easier to use.

Nowosad · 2018-03-16T19:33:15Z

Thanks Roger! I didn't even expect an answer - It was just a reminder where to start looking for the answers.
Once more - thank you.

rsbivand · 2018-03-21T09:00:38Z

Markus Metz has started rebasing the GRASS trunk https://lists.osgeo.org/pipermail/grass-user/2018-March/078008.html on the new PROJ API - plenty of insight as for example here:

https://trac.osgeo.org/grass/changeset?reponame=&new=72448%40grass%2Ftrunk%2Flib%2Fproj%2Fdo_proj_ll.c&old=72423%40grass%2Ftrunk%2Flib%2Fproj%2Fdo_proj_ll.c

edzer · 2018-03-21T13:51:30Z

Looks useful!!

rsbivand · 2018-03-22T08:15:21Z

And from Even Rouault about GDAL: https://lists.osgeo.org/pipermail/gdal-dev/2018-March/048278.html

I've just committed in trunk initial support for proj.5 API per:
https://trac.osgeo.org/gdal/changeset/41878

You have to use the to-be-released proj 5.0.1 / proj master to get all
reprojection results to work as expected.

rsbivand · 2018-03-23T11:01:20Z

Today on GRASS:

Now (last related commit is trunk r72522) it's finished. I have introduced
a new GRASS API that handles both PROJ 4 and PROJ 5, consisting of

GPJ_init_transform() (new, initializes coordinate transformation)
GPJ_transform() replacing pj_do_proj()
GPJ_transform_array() replacing pj_do_transform()

The old GRASS API is still there but is no longer used by core modules.

Only few ifdefs in lib/proj are needed for different PROJ versions. Modules
do not need any ifdefs, they can simply call GPJ_init_transform() +
GPJ_transform() without caring about the PROJ API.

As soon as PROJ 5.0.1 is out, I would like to drop support for PROJ 5.0.0
and only support PROJ 4 and PROJ 5.0.1 or higher (learning from GDAL :-)).

Markus M

rsbivand · 2018-04-07T10:08:16Z

The web-mercator issue is fixed in release 5.0.1. The work-around in rgdal's CRS handling will remain in case anyone has 5.0.0 installed.

rsbivand · 2018-04-16T07:59:11Z

Thread here about issues probably with GDAL drivers linking to stale PROJ shared objects.

edzer · 2018-05-15T11:22:15Z

It might make sense to first wait for GDAL to catch up with PROJ 5.0.1; they secured the funding it seems: https://gdalbarn.com/

rsbivand · 2018-05-15T12:05:38Z

Yes, I agree.

rsbivand · 2018-05-26T18:59:00Z

rgdal from R-Forge and current sf master seem OK with 5.1.0RC2; attaching check log for sf:

00check.log

edzer · 2018-05-27T08:24:14Z

Thanks for checking!

rsbivand · 2018-10-11T17:52:40Z

http://even.rouault.free.fr/proj_cpp_api/rfc-2.html# is the first cut at explaining the barn-raising product.

rsbivand · 2018-11-17T14:15:54Z

This is crucial: http://lists.maptools.org/pipermail/proj/2018-November/008505.html - axis order. See also https://trac.osgeo.org/osgeo/ticket/2218 for mailing list issues (may leave the maptools server).

rsbivand · 2018-11-27T20:23:56Z

See GDAL release proposal: https://lists.osgeo.org/pipermail/gdal-dev/2018-November/049381.html

GDAL 2.4.0 soon, GDAL 2.5.0 April/May 2019 with breaking changes.

rsbivand mentioned this issue Nov 17, 2017

Increment version number to 5.0.0 OSGeo/PROJ#673

Merged

edzer changed the title ~~roadbump coming: proj.4 release~~ roadbump coming: Proj 5 release Mar 3, 2018

edzer added a commit that referenced this issue Mar 12, 2018

addressing #545 but needs further sorting out!

4b69391

Nowosad mentioned this issue Mar 16, 2018

Proj.4 version 10 - potential issue geocompx/geocompr#102

Closed

etiennebr pushed a commit to etiennebr/sf that referenced this issue Mar 22, 2018

addressing r-spatial#545 but needs further sorting out!

12c66b2

rsbivand mentioned this issue Mar 31, 2018

leaflet does not handle projected coordinates and confuses naive users rstudio/leaflet#505

Open

edzer closed this as completed Jul 11, 2018

edzer mentioned this issue Feb 28, 2019

PROJ6 and GDAL 2.5 are coming #988

Closed

roadbump coming: Proj 5 release #545

roadbump coming: Proj 5 release #545

Comments

rsbivand commented Nov 9, 2017

edzer commented Nov 10, 2017

rsbivand commented Nov 17, 2017

edzer commented Nov 17, 2017

rsbivand commented Nov 17, 2017

rsbivand commented Nov 17, 2017

rsbivand commented Nov 17, 2017 • edited Loading

edzer commented Nov 17, 2017

rsbivand commented Nov 17, 2017 • edited Loading

rundel commented Nov 17, 2017 via email

rsbivand commented Feb 16, 2018

rsbivand commented Feb 16, 2018 • edited Loading

edzer commented Feb 16, 2018

rsbivand commented Feb 16, 2018

edzer commented Feb 17, 2018

rsbivand commented Feb 17, 2018

rsbivand commented Feb 20, 2018 • edited Loading

edzer commented Feb 20, 2018

rsbivand commented Feb 20, 2018

rsbivand commented Feb 26, 2018

rsbivand commented Mar 1, 2018

rsbivand commented Mar 1, 2018

edzer commented Mar 3, 2018

edzer commented Mar 12, 2018

rsbivand commented Mar 12, 2018

rsbivand commented Mar 12, 2018 • edited Loading

edzer commented Mar 12, 2018

ateucher commented Mar 12, 2018

edzer commented Mar 12, 2018

rsbivand commented Mar 13, 2018 • edited by edzer Loading

edzer commented Mar 13, 2018

tim-salabim commented Mar 13, 2018

rsbivand commented Mar 13, 2018

tim-salabim commented Mar 13, 2018

edzer commented Mar 15, 2018

rsbivand commented Mar 15, 2018

rsbivand commented Mar 16, 2018

rsbivand commented Mar 16, 2018

Nowosad commented Mar 16, 2018

rsbivand commented Mar 21, 2018

edzer commented Mar 21, 2018

rsbivand commented Mar 22, 2018

rsbivand commented Mar 23, 2018

rsbivand commented Apr 7, 2018 • edited by edzer Loading

rsbivand commented Apr 16, 2018

edzer commented May 15, 2018

rsbivand commented May 15, 2018

rsbivand commented May 26, 2018

edzer commented May 27, 2018

rsbivand commented Oct 11, 2018

rsbivand commented Nov 17, 2018

rsbivand commented Nov 27, 2018

rsbivand commented Nov 17, 2017 •

edited

Loading

rsbivand commented Nov 17, 2017 •

edited

Loading

rsbivand commented Feb 16, 2018 •

edited

Loading

rsbivand commented Feb 20, 2018 •

edited

Loading

rsbivand commented Mar 12, 2018 •

edited

Loading

rsbivand commented Mar 13, 2018 •

edited by edzer

Loading

rsbivand commented Apr 7, 2018 •

edited by edzer

Loading