熱いプルリクエストをお待ちしております
今日の話。先日CRANにあげたパッケージに早速バグが見つかって、ちょっと直していた。直していると人間不思議なもので、余計な機能改善までしたくなってしまう。それで罠にはまった、という失敗談。
...失敗談でもあるのだけど、罠にはまっていたところ r-wakalang というRコミュニティのSlackでどうすれば良いか質問した。するとすぐに答えが返ってきた（その間、俺は昼飯を食べていた。回答してくれた方々には感謝しかない）。
https://r-wakalang.slack.com/archives/C0Q1QP2CX/p1511922665000141
んで、図々しくもじゃあもうちょっと良いのが実装できたらプルリクエストしてくれ〜的なことを伝えたら、数時間後には熱い（かどうかはさておき）プルリクエストが来ていた。件の内容のものだ！
早速マージしてニコニコしている。ありがとう id:yutannihilation = ｻﾝ（彼はﾆﾝｼﾞｬかもしれない。ｱｲｴｴｴ）。
誰かのアイデアを取り入れるのは、将来自分のアイデアとしても取り入れられる可能性を広げられて良い... 。今回のプルリクエストも、単純ながら俺では思いつかなかったものだ。素晴らしい。OSS最高...。
というわけで、皆さんからの🔥 熱い🔥 プルリクエスト、お待ちしております 💪
標準地域メッシュを扱うRパッケージを更新しました: jpmesh v.1.0.0
ここでさりげなく触れたのですが、jpmeshという、国勢調査などの統計調査に用いる標準地域メッシュをRで扱うためのパッケージを更新し、CRANにリリースしました。これまで対応していたメッシュのスケールをより細かくし、125mメッシュまでを扱えるようになりました。これにより基準(3次)メッシュの分割地域メッシュに対応したこととなり、バージョン1.0.0としました。以下、主要な変更点と開発話です。
利用の際はCRANからインストールしてください。Windows版も1.0.0が登録されています。
install.packages("jpmesh") library(jpmesh) library(magrittr)
更新内容
これまで、基準地域メッシュと分割地域メッシュの算出には別々の関数を用いる必要がありましたが、1.0.0からは一つの関数で対応できるようになっています。
coords_to_mesh(longitude = 139.71475, latitude = 35.70078) ## [1] "53394547" coords_to_mesh(139.71475, 35.70078, mesh_size = "80km") ## [1] "5339" coords_to_mesh(139.71475, 35.70078, mesh_size = "125m") ## [1] "53394547112"
coords_to_mesh()は座標から地域メッシュを出力する関数です。引数mesh_sizeで出力するメッシュの大きさを変更できます。初期値では基準(3次)メッシュ(1km)が返却されます。
jpmeshでは、緯度と経度を関数の引数として扱う場合、それぞれlatitude、longitudeとして指定します。出力時には省略形としてlng、latが与えられます。また順番は経度が先になります。経度、緯度の順番なので注意してください。
メッシュから座標を知りたい時は、メッシュの中心座標およびメッシュの大きさを出力するmesh_to_coords()を使ってください。メッシュの形状をsfc_POLYGONオブジェクトとして出力するexport_mesh()もあります。
mesh_to_coords(5133) ## # A tibble: 1 x 4 ## lng_center lat_center lng_error lat_error ## <dbl> <dbl> <dbl> <dbl> ## 1 133.5 34.3333333333 0.5 0.3333333333 export_mesh(5133) ## Geometry set for 1 feature ## geometry type: POLYGON ## dimension: XY ## bbox: xmin: 133 ymin: 34 xmax: 134 ymax: 34.66667 ## epsg (SRID): NA ## proj4string: NA ## POLYGON ((133 34, 134 34, 134 34.6666666666, 13...
隣接するメッシュコードや、スケールダウンした時に含まれるメッシュコードを出力する関数も整備されました。この関数は地味に便利で気に入っています。
coords_to_mesh(133, 34, "80km") %>% fine_separate() ## [1] "513311" "513312" "513313" "513314" "513315" "513316" "513317" ## [8] "513318" "513321" "513322" "513323" "513324" "513325" "513326" ## [15] "513327" "513328" "513331" "513332" "513333" "513334" "513335" ## [22] "513336" "513337" "513338" "513341" "513342" "513343" "513344" ## [29] "513345" "513346" "513347" "513348" "513351" "513352" "513353" ## [36] "513354" "513355" "513356" "513357" "513358" "513361" "513362" ## [43] "513363" "513364" "513365" "513366" "513367" "513368" "513371" ## [50] "513372" "513373" "513374" "513375" "513376" "513377" "513378" ## [57] "513381" "513382" "513383" "513384" "513385" "513386" "513387" ## [64] "513388" coords_to_mesh(133, 34, "80km") %>% fine_separate() ## [1] "513311" "513312" "513313" "513314" "513315" "513316" "513317" ## [8] "513318" "513321" "513322" "513323" "513324" "513325" "513326" ## [15] "513327" "513328" "513331" "513332" "513333" "513334" "513335" ## [22] "513336" "513337" "513338" "513341" "513342" "513343" "513344" ## [29] "513345" "513346" "513347" "513348" "513351" "513352" "513353" ## [36] "513354" "513355" "513356" "513357" "513358" "513361" "513362" ## [43] "513363" "513364" "513365" "513366" "513367" "513368" "513371" ## [50] "513372" "513373" "513374" "513375" "513376" "513377" "513378" ## [57] "513381" "513382" "513383" "513384" "513385" "513386" "513387" ## [64] "513388" coords_to_mesh(133, 34, "500m") %>% find_neighbor_mesh() ## [1] 513299894 513299903 513299904 513299992 513299994 513300001 513300002 ## [8] 513300003 513300004
開発よもやま話
rlangがわからんぐ
あまり理解せず、雰囲気で導入しています。
例1 (この関数は廃止されています)
ddd <- function(var = "Species") {
my_var <- rlang::enquo(var)
iris %>% dplyr::select(!! my_var)
}
ddd() %>% names()
## [1] "Species"
ddd(var = "Sepal.Length") %>% names()
## [1] "Sepal.Length"
vars <- c("Sepal.Length", "Petal.Width")
ddd(var = vars) %>% names()
## [1] "Sepal.Length" "Petal.Width"
ふむー。
雰囲気で（略
uribo、purrlyrやめるってよ
Rユーザとして尊敬する id:yutannihilation
がpmap()を使えって言っているのでそうします（なんという意志の弱さ。ちなみにpurrrlyrパッケージが推奨されない理由についてはRラジオ#1でも触れています）。
purrr::pmap()については、挙動を覚えたと思ったら別の機会で利用した際は完全に忘れていたり、あれこんなんだったけと勘違いすることもあるのですが、試行錯誤で徐々に慣れていきたいです。ちなみに、めちゃ便利です。
試行錯誤しながらもクセがわかってきた。変数名と引数名の一致と...が肝とみた。purrrはこういう楽しみがあって好き（イヤイヤ💦） pic.twitter.com/yl9NRngHMu
— Uryu Shinya (@u_ribo) November 20, 2017
次期バージョン
早くも(?)次期バージョンのスケジュールがスタートしています。一件一件の出力では問題ないのですが、扱うレコード数が多いと処理に時間がかかるので（特にポリゴンの出力）Rcppでの実装により高速化を目指したいです。
バグ報告や機能改善・追加などはGitHub IssuesあるいはTwitter経由でお伝えいただけると幸いです。
自分のRパッケージページにORCIDを表示させる
Rのパッケージについて、CRANでその情報を見る際、Authorの欄にORCIDを埋め込めるという話。
RのパッケージはAuthor欄にORCIDを埋め込めるって知ってました？ 例：https://t.co/mDCdLxJZOw
— Hiroaki Yutani (@yutannihilation) November 16, 2017
これについては答えはYES。厳密にいつからかはわからないが、私の観測したうちでは先月(2017年10月)の中頃からの機能だ。百聞は一見にしかず、ということでその例を見てもらいたい。
https://cran.r-project.org/package=jpmesh
緑色のidというアイコンがそれ。リンク先はORCIDのページになっている。Rのパッケージは大学の教員や研究者が開発に携わることも多々ある(というか経歴的にはそっちが主流かも)ので、学術的な業績や活動をまとめられるORCIDへのリンクがあることは良いように思える。
研究者の名前問題はORCID https://t.co/9q4qxfaXER を使う以外に良い方法はないと思う
— Haruhiko Okumura (@h\_okumura) November 16, 2017
名前が同じ研究者がいたり、諸事情によって氏名が変わったり、うっかり論文の著者名を間違えてしまったり、研究者の同定問題は色々あるように思える。国内にも科研費データベースの「KAKEN」、国外でも「ResearcherID」があったりするわけだけど、CRANがORCIDに対応したというのはちょっと驚きがあった。
さて、どうやって自分のパッケージのページにORCIDのリンクを表示させるかというと、自分のORCIDをメモってきてDESCRIPTIONにちょっとした変更を加え、CRANにアップロードするだけ。こんな感じ。
https://github.com/uribo/jpmesh/blob/master/DESCRIPTION#L5-L7
研究者な皆さん、もっとRパッケージ開発やっていきましょう。 もっと便利なパッケージを作っていくぞ！ (先日の統計数理研究所でのRユーザ集会では大学教員の皆さんのRパッケージ開発についても話が聞けてよかった...)
Enjoy!
