Re: [R-sig-Geo] Package 'gdalUtils' when using 'gdal_translate' on HDF files it gives error "no installation match"

[Lorenzo Busetto]

The `gdal_chooseInstallation ` issue should be indeed related to switching
to GDAL3. The problem should have been already addressed in the github repo
here:

https://github.com/gearslaboratory/gdalUtils/commit/a94bbe422e7fe3bda1f571fc3629c3d052b4f195


Therefore, installing from github should solve the issue and allow you to
keep working with GDAL3 (at least, it did it for me).

Note that on Windows the gdalUtils package has some additionals problems
related with GDAL 3 migration due to issues reported here:

https://github.com/r-spatial/discuss/issues/31

HTH,

 Lorenzo

PS: For Francisco: sorry for the double replies, but I noticed that by
mistake I replied only to you and not to the list.

On Fri, 13 Dec 2019 at 13:40, Francisco Zambrano  wrote:

> Hi all,
>
> I'm using the package gdalUtils to work with HDF (MODIS data), I've used
> for a while without problems, but now (I believe after the update of gdal)
> is giving me the following error when I use the function 'gdal_translate'
> over HDF files. A time before this used to work fine.
>
> Error in gdal_chooseInstallation(hasDrivers = of) :
>   No installations match.
>
>
> also,
>
> gdal_chooseInstallation(hasDrivers=c("HDF4","HDF5"))Error in
> gdal_chooseInstallation(hasDrivers = c("HDF4", "HDF5")) :
>   No installations match.
>
> The version and date for gdal are:
>
> > getOption("gdalUtils_gdalPath")[[1]]$versionversion
> "3.0.2" > getOption("gdalUtils_gdalPath")[[1]]$datedate
> "2019-10-28"
>
>
> Searching the HDF drivers I get:
>
> >
> getOption("gdalUtils_gdalPath")[[1]]$drivers[grep('HDF',getOption("gdalUtils_gdalPath")[[1]]$drivers$format_name),]
> format_code read write update virtualIO subdatasets  format_name
> 43  HDF4Image-raster- TRUE  TRUE   TRUE FALSE   FALSE HDF4 Dataset
> 114 HDF5Image-raster- TRUE FALSE  FALSE  TRUE   FALSE HDF5 Dataset
>
>
> My sessionInfo():
>
> R version 3.6.1 (2019-07-05)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
>
> locale:
>  [1] LC_CTYPE=es_CL.UTF-8   LC_NUMERIC=C
> LC_TIME=es_CL.UTF-8
>  [4] LC_COLLATE=es_CL.UTF-8 LC_MONETARY=es_CL.UTF-8
> LC_MESSAGES=es_CL.UTF-8
>  [7] LC_PAPER=es_CL.UTF-8   LC_NAME=C
> LC_ADDRESS=C
> [10] LC_TELEPHONE=C LC_MEASUREMENT=es_CL.UTF-8
> LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] stringr_1.4.0  gdalUtils_2.0.1.14 purrr_0.3.3
> raster_3.0-7   sp_1.3-1
>
> loaded via a namespace (and not attached):
>  [1] Rcpp_1.0.2lattice_0.20-38   codetools_0.2-16
> foreach_1.4.7 R.methodsS3_1.7.1
>  [6] grid_3.6.1magrittr_1.5  stringi_1.4.3 rlang_0.4.1
>   R.oo_1.23.0
> [11] R.utils_2.9.0 rgdal_1.4-8   iterators_1.0.12  tools_3.6.1
>   compiler_3.6.1
>
>
> Regards,
>
> Francisco
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: [R-sig-Geo] sp/rgdal workflows with PROJ >= 6 and GDAL >= 3

[Lorenzo Busetto]

Thanks. I'll check it out on Monday and let you know if there are any
issues.

Lorenzo

On Sat, 30 Nov 2019, 11:53 Roger Bivand,  wrote:

> Streaming link now published (thanks to Arild Schanke), only live when
> transmission active.
>
> Roger
>
> On Fri, 29 Nov 2019, Roger Bivand wrote:
>
> > Thanks, we use the local, institutional interface which provides the
> > quality we delivered at the 2014 Geostat summer school. The link will be
> > posted on
> > https://rsbivand.github.io/ECS530_h19/streaming_ecs530_h19.html when
> > available (delayed because I've been off work). We'll just have to use
> > Monday's classes to check that things are working, feedback info in the
> > link above.
> >
> > Roger
> >
> > --
> > Roger Bivand
> > Norwegian School of Economics
> > Helleveien 30, 5045 Bergen, Norway
> > roger.biv...@nhh.no
> >
> >
> > 
> > Fra: Lorenzo Busetto 
> > Sendt: fredag 29. november 2019 18.30
> > Til: Roger Bivand
> > Kopi: r-sig-geo@r-project.org
> > Emne: Re: [R-sig-Geo] sp/rgdal workflows with PROJ >= 6 and GDAL >= 3
> >
> > Dear Roger,
> >
> >I'd be very interested in participating to the stream talk. Is it
> confirmed?
> >
> > Concerning testing the connection, I'd be happy to do it but I do not
> know how much I will be available online in the coming days. You can drop
> me a mail/DM on twitter, and if I am available I'll gladly help.
> >
> > Concerning technology, Zoom usually works quite well (https://zoom.us/<
> https://zoom.us/ent?zcid=3172>)
> >
> >   regards,
> >
> > Lorenzo
> >
> > On Sat, 23 Nov 2019 at 13:04, Roger Bivand  roger.biv...@nhh.no>> wrote:
> > A description of the status now with regard to a prototype resolution is
> > online at:
> >
> > https://rsbivand.github.io/ECS530_h19/ECS530_III.html
> >
> > I'm planning to stream a talk about this at 09:15-11:00 CET on Tuesday 3
> > December. I need a volunteer to test the streaming link in advance during
> > next week. I'm unsure which technology to use for remote participants to
> > provide feedback.
> >
> > Contributions/comments welcome!
> >
> > Roger
> >
> >
> > On Fri, 15 Nov 2019, Roger Bivand wrote:
> >
> >> The development version of rgdal on R-Forge is now at rev 894, and is
> now
> >> ready for trying out with PROJ6/GDAL3 workflows, and workflows that may
> >> migrate within 6 months to modern CRS representations. The motivating
> RFC is
> >> also updated to cover coordinate operations, the use of prepared
> >> (pre-searched) coordinate operations, and should be read carefully by
> anyone
> >> using rgdal::spTransform(). Note further that rgdal::project() will not
> be
> >> adapted for PROJ6, and is effectively deprecated.
> >>
> >> I'll be running reverse dependency checks, and may be bugging package
> >> maintainers. I would really prefer that mainainers of packages using
> >> spTransform() checked themselves and joined this thread or the
> associated
> >> twitter thread:
> https://twitter.com/RogerBivand/status/1194586193108914177
> >>
> >> Be ready for modern PROJ and GDAL, they are already being deployed
> across
> >> open source geospatial software, like GRASS, QGIS, pyproj, spatialite
> etc.
> >>
> >> Waiting, hopefully not in vain, for contributions.
> >>
> >> Roger
> >>
> >> On Wed, 13 Nov 2019, Roger Bivand wrote:
> >>
> >>>  And this link explains the CDN proposal for grid distribution:
> >>>
> >>>  https://www.spatialys.com/en/crowdfunding/
> >>>
> >>>  Roger
> >>>
> >>>  On Wed, 13 Nov 2019, Roger Bivand wrote:
> >>>
> >>>>   Because PROJ >= 6 and GDAL >= 3 change the way that PROJ strings
> >>>>   (representations of coordinate reference systems) are handled,
> steps are
> >>>>   being taken to find ways to adapt sp/rgdal workflows. A current
> proposal
> >>>>   is to store the WKT2_2018 string as a comment to CRS objects as
> defined
> >>>>   in
> >>>>   the sp package.
> >>>>
> >>>>   A draft development-in-progress version of rgdal is available at
> >>>>   https://r-forge.r-project.org/R/?group_id=884, and for sp at
> >>>>   https://github.com/rsbivand/sp (this vers

Re: [R-sig-Geo] sp/rgdal workflows with PROJ >= 6 and GDAL >= 3

[Lorenzo Busetto]

Dear Roger,

I'd be very interested in participating to the stream talk. Is it
confirmed?

Concerning testing the connection, I'd be happy to do it but I do not know
how much I will be available online in the coming days. You can drop me a
mail/DM on twitter, and if I am available I'll gladly help.

Concerning technology, Zoom usually works quite well (https://zoom.us/
)

   regards,

Lorenzo

On Sat, 23 Nov 2019 at 13:04, Roger Bivand  wrote:

> A description of the status now with regard to a prototype resolution is
> online at:
>
> https://rsbivand.github.io/ECS530_h19/ECS530_III.html
>
> I'm planning to stream a talk about this at 09:15-11:00 CET on Tuesday 3
> December. I need a volunteer to test the streaming link in advance during
> next week. I'm unsure which technology to use for remote participants to
> provide feedback.
>
> Contributions/comments welcome!
>
> Roger
>
>
> On Fri, 15 Nov 2019, Roger Bivand wrote:
>
> > The development version of rgdal on R-Forge is now at rev 894, and is
> now
> > ready for trying out with PROJ6/GDAL3 workflows, and workflows that may
> > migrate within 6 months to modern CRS representations. The motivating
> RFC is
> > also updated to cover coordinate operations, the use of prepared
> > (pre-searched) coordinate operations, and should be read carefully by
> anyone
> > using rgdal::spTransform(). Note further that rgdal::project() will not
> be
> > adapted for PROJ6, and is effectively deprecated.
> >
> > I'll be running reverse dependency checks, and may be bugging package
> > maintainers. I would really prefer that mainainers of packages using
> > spTransform() checked themselves and joined this thread or the
> associated
> > twitter thread:
> https://twitter.com/RogerBivand/status/1194586193108914177
> >
> > Be ready for modern PROJ and GDAL, they are already being deployed
> across
> > open source geospatial software, like GRASS, QGIS, pyproj, spatialite
> etc.
> >
> > Waiting, hopefully not in vain, for contributions.
> >
> > Roger
> >
> > On Wed, 13 Nov 2019, Roger Bivand wrote:
> >
> >>  And this link explains the CDN proposal for grid distribution:
> >>
> >>  https://www.spatialys.com/en/crowdfunding/
> >>
> >>  Roger
> >>
> >>  On Wed, 13 Nov 2019, Roger Bivand wrote:
> >>
> >>>   Because PROJ >= 6 and GDAL >= 3 change the way that PROJ strings
> >>>   (representations of coordinate reference systems) are handled, steps
> are
> >>>   being taken to find ways to adapt sp/rgdal workflows. A current
> proposal
> >>>   is to store the WKT2_2018 string as a comment to CRS objects as
> defined
> >>>   in
> >>>   the sp package.
> >>>
> >>>   A draft development-in-progress version of rgdal is available at
> >>>   https://r-forge.r-project.org/R/?group_id=884, and for sp at
> >>>   https://github.com/rsbivand/sp (this version of sp requires rgdal >=
> >>>   1.5-1). This adds the WKT comments to CRS objects on reading vector
> and
> >>>   raster data sources, and uses WKT comments if found when writing
> vector
> >>>   and raster objects (or at least does as far as I've checked, possibly
> >>>   fragile).
> >>>
> >>>   An RFC with tersely worked cases for using CRS object comments to
> carry
> >>>   WKT strings but maintaining full backward compatibility is online at
> >>>   http://rgdal.r-forge.r-project.org/articles/PROJ6_GDAL3.html.
> >>>
> >>>   If you have other ideas or concerns about trying to use this
> mechanism
> >>>   for
> >>>   sp CRS objects, please contribute at your earliest convenience.
> >>>
> >>>   http://rgdal.r-forge.r-project.org/reference/list_coordOps.html
> shows
> >>>   the
> >>>   beginning of the next step, to query transformation operations to
> find
> >>>   viable coordinate operation pipelines.
> >>>
> >>>   I'm assuming that the previous behaviour (transform without
> considering
> >>>   accuracy with whatever is to hand) is not viable going forward, and
> that
> >>>   we will need two steps: list coordinate operations between source and
> >>>   target CRS (using the WKT comments as better specifications than the
> >>>   PROJ
> >>>   strings), possibly intervene manually to install missing grids, then
> >>>   undertake the coordinate operation.
> >>>
> >>>   The fallback may be simply to choose the least inaccurate available
> >>>   coordinate operation, but this should be a fallback. This means that
> all
> >>>   uses of spTransform() will require intervention.
> >>>
> >>>   Is this OK (it is tiresome but modernises workflows once), or is it
> not
> >>>   OK
> >>>   (no user intervention is crucial)?
> >>>
> >>>   These behaviours may be set in an option, so that package maintainers
> >>>   and
> >>>   users may delay modernisation, but all are undoubtedly served by
> rapid
> >>>   adaptation (GRASS 7.8.1 released yesterday, libspatialite, pyproj,
> QGIS
> >>>   development versions all state that they list candidate coordinate
> >>>   operations).
> >>>
> >>>   We cannot ship all the grids, they