パッケージの終わり
rgdalパッケージのメンテナンスが終わる
Provides bindings to the 'Geospatial' Data Abstraction Library ('GDAL') (>= 1.11.4) and access to projection/transformation operations from the 'PROJ' library. Please note that 'rgdal' will be retired during October 2023, plan transition to sf/stars/'terra' functions using 'GDAL' and 'PROJ' at your earliest convenience (see <https://r-spatial.org/r/2023/05/15/evolution4.html> and earlier blogs for guidance). Use is made of classes defined in the 'sp' package. Raster and vector map data can be imported into R, and raster and vector 'sp' objects exported. The 'GDAL' and 'PROJ' libraries are external to the package, and, when installing the package from source, must be correctly installed first; it is important that 'GDAL' < 3 be matched with 'PROJ' < 6. From 'rgdal' 1.5-8, installed with to 'GDAL' >=3, 'PROJ' >=6 and 'sp' >= 1.4, coordinate reference systems use 'WKT2_2019' strings, not 'PROJ' strings. 'Windows' and 'macOS' binaries (including 'GDAL', 'PROJ' and their dependencies) are provided on 'CRAN'.
rgdalパッケージのメンテナンスが終わり、sfパッケージに切り替わる経緯は、次のような感じだろうか（ザックリ）
| 年月 | 出来事 |
|---|---|
| 2003年 | rgdalパッケージがRoger BivandとTim Keittによって開発される |
| 2016年 | sfパッケージがEdzer Pebesmaらによって開発される |
| 2020年10月 | Roger Bivandがrgdalパッケージのメンテナンスを終了することを発表し、sfパッケージを推奨する |
| 2020年10月 | Edzer Pebesmaがrgdalパッケージのメンテナンス終了に対するコメントを発表し、sfパッケージがrgdalパッケージの機能を引き継ぐことを確認する |
| 2020年12月 | rgdalパッケージの最新バージョン（1.5-23）がリリースされる |
| 2021年以降 | rgdalパッケージは更新されず、sfパッケージがRで空間データを扱うための主要なパッケージとなる |
「rgdalパッケージを使ったことがある」程度の親近感ですが、少し寂しい気もします。
そこで、少しr-spatial.orgにある情報を整理してみた。
2022年4月12日 R-spatial evolution: retirement of rgdal, rgeos and maptools
evolutionの翻訳が難しいですが、「刷新」という感じでしょうか？ 新旧交替、吐故納新、革故鼎新、いわゆる代替わりですね
rgdal、rgeos、maptools（以下、3パッケージ）廃止について
3パッケージの廃止の背景や、機能の移行先やそれに伴う影響について言及している。
- パッケージ廃止の主な理由は、メンテナーであるRoger Bivandの引退にある。
- メンテナンスを引き継ぐこともできるが、これは20年以上前のパッケージのため、古い外部ライブラリに依存しており、コードの可読性が低くなっており、負荷が大きい。
- より新しいパッケージ（2016年の
sf、2018年のstars、2018年のvapour、2020年のterraなど）はGDAL、GEOS、PROJを扱え、rgdalとrgeosの役割を引き継げる可能性がある。 - また、新しいパッケージは、R/C/C++コードを外部ライブラリへリンクしており、GEOS、GDAL、PROJの変更に対応できる。
- さらに、CRANとR-coreのチームと連携して、WindowsとmacOS用にビルドできる体制がある。
つまり、個人の努力で維持していたが限界がきた、組織で維持できている代替法に切り替える、ということのようだ。 Rユーザーも増え、組織も大きくなった故の決断ということでしょうか？
依存パッケージへの対応
とはいえ、3パッケージに依存するパッケージは多く、この時点で200～400程度が依存関係にあった。
| rgdal | rgeos | maptools | |
|---|---|---|---|
| 直接 strong | 213 | 140 | 93 |
| 直接 most | 358 | 225 | 180 |
| 再帰的 strong | 265 | 190 | 641 |
「直接 strong」は"Depends", "Imports", "LinkingTo"のいずれか、「直接 most」は"Depends", "Imports", "LinkingTo", "Suggests"のいずれか、「再帰的 strong」はこのパッケージなしでは実行できない、ということで、老舗パッケージ故にヤバい状況のようです。
そこで、次の計画で、3パッケージの移行を進めることになった。
- 可能な限り、アクティブなメンテナがいるモダンなパッケージ（以下、代替手段）に移動する。
- 3パッケージに依存しているCRANパッケージのメンテナに連絡し、代替手段への移行方法についてのガイダンスを提供する。
spパッケージがrgdal、rgeosに依存しないように修正する。rasterパッケージがrgdal、rgeosを必要としないように修正するのを支援する。rgdal、rgeosにリンクしないプロキシパッケージを開発する。保守されているRパッケージに呼び出しを渡す（非推奨の関数が呼び出されていることも警告する）、それ以外の場合は解決方法へのポインタとともにエラーを発生させる。
3パッケージへの対応
この以降計画を進めるべく、3パッケージへの対応手順も決まって、
- 逆向きのCRAN依存関係の関数、呼び出しで設定されている引数のリストの作成
- このリストをもとに、移行するための関数で置き換えられる関数を決定（ベクトル表現が先、次にラスター表現）
- 最も影響を受けるパッケージのメンテナ、Rユーザー、およびsp/rasterに関する知識を持つ人を集めた「プロジェクトステアリング委員会」を設立し、適用可能な変更を探索。
- 直接的に
spに移動できる関数/メソッドの特定 - 他の関数は、新しい「プロキシ」パッケージのセットに再書き込みし、sf/stars/raster/terraに移行（ベクトル表現が先、次にラスター表現）
- この「プロキシ」パッケージを使用して、逆依存関係をチェックし、引数なしで呼び出される非推奨の関数を特定
- 他の関数が
rgdal、rgeosに依存しないことを確認、関数が正しく機能することをテスト
気が遠くなる作業です。 しかし、無償のソフトウェアに「プロジェクトステアリング委員会」を立ち上げて対応するなど、本当に頭が下がります。
2023年5月15日 sp evolution status: examples of migration from retiring packages
4回目のレポート、とはいえ残りわずかだから廃止前最後のレポートかもしれない
2023年中の3パッケージの廃止（アーカイブ化）に向けて、主な目標の説明、依存関係にあるパッケージを使用するパッケージのメンテナーに対する詳細なガイダンスの提供、と進んできました。
spの利用者へのアナウンス
spクラス、メソッド、および関数を使用するパッケージとワークフローのメンテナーへの連絡は次のとおり。
- 2023年6月から「
rgdalおよびrgeosの代わりにsfを使用する」に変更する spに依存するパッケージは、弱い依存関係にsfを追加し、出力の変更を監視する必要性が高まっている- 2023年10月から、最終ステップに入り、5か月後に廃止までに、3パッケージに強い依存関係を持つパッケージを
sf、terra、またはその他の代替手段に切り替える、または回避策を提供する必要がある - 必要なすべての変更を行えば、2023年6月からの
spの変更期間で完了するようにする - 廃止に伴う対応表は次のとおり
sp 1.6.0（2023年1月19日、CRAN公開）での対応状況
不具合を生じないためにspにいくつか変更を加えている。この適用により、ユーザーの混乱を極力、回避できるようにしているのだろう。
spを読み込む前に条件付きコードを設定するようにした。sp_evolution_statusを用意して、この引数が0なら「変更なし（rgdalを使用してPROJにアクセスする）」、1なら「rgdalまたはrgeosが存在しなければ停止」、2なら「sfでrgdalを代替する」としている。ただ、rgeos対応は用意しておらず、これを使用することを考慮していないようだ。
options("sp_evolution_status"=2)
library(sp)
spをロードするときの環境変数への対応も用意しており、メンテナーがコード内の潜在的な問題を検出できるようにしている。devtools::check()ならenv_vars=引数でチェックでき、コマンドラインからもチェックできる。
_SP_EVOLUTION_STATUS_=2 R CMD check
sp::get_evolution_status()を使用して現在の値を取得し、sp::set_evolution_status(value)を使用して値（0L、1L、2L）を変更できる。
影響を受けるspの関数とメソッドの使用
進化状況が2（sfでrgdalを代替する）になる2023年6月の対応を伝えている。
sp::CRS、sp::is.projected、sp::spTransformではrgdalの代わりにsfを使用してPROJにアクセスする。sfを使えないなら、進化状況0の動作と同じように警告を出す
依存関係にあるパッケージの一覧も記載されていて、この全てをrgdalおよびrgeosに代わってsfを使用するよう、具体的な移行ガイドライン、パッケージのドキュメント、R-spatial GitHubリポジトリなど、確認手段を準備していると思うと、驚きです。
所感
Tokyo.R #107がジオデータ特集ということで、GDALを思い出そうとしたのがきっかけでした。
次回、第107回 #TokyoR は2023年7月15日（土）開催ジオデータ特集です！
— Tokyo.R (@TokyoRCommunity) June 16, 2023
LT発表者募集を開始しました！ジオデータに限らずテーマもレベルも任意です。以下のフォームから奮ってご応募ください！ https://t.co/HAFnJOywhl
なお、発表者以外の方の参加受付は後日開始します。しばらくお待ち下さい。
当初は、sfパッケージを勉強して、rgdalとの対比をLTするつもりでしたが、気が付けば、どうでもよくなっていて、パッケージの終焉と後始末の壮大な計画を勉強させてもらいました。
テーマの終焉は実社会でもありうることで、企業の場合、金銭のやり取りもあるから大変です。漏れのない課題抽出とそれに対する適切な対応、スケジュールと適切な人材の配置など、なかなか難しいことを、Rメンバーはこなしていました。
私も参考にしたいと思います。
