macOS (High Sierra)で利用しているRからタイムゾーンの警告がでる件とその対策
タイトルの通り、macOSを使っている皆さん、こんな警告を見たことはないだろうか。
lubridate::today() # [1] "2017-11-30" Warning message: In as.POSIXlt.POSIXct(x) : unknown timezone 'zone/tz/2017c.1.0/zoneinfo/Asia/Tokyo'
なにやらタイムゾーンで怒られている。これはセッション中に日付・時間のオブジェクトを扱う処理を実行すると出る警告だが、よくわからない理由で怒られるとビビる。
これはOSとR間でのバグらしく、すでに報告が上がっている。
17355 – unknown timezone when printing (on OSX High Sierra)
で、この問題は次期バージョンとなるR 3.4.3で修正されるらしい。ちなみにR 3.4.3は今日リリースされた(というのを先ほどメーリングリストで知った)ので、バイナリも近いうちにダウンロード可能になるだろう。安心安心。
A workaround has been added for the changes in location of time-zone files in macOS 10.13 'High Sierra' and again in 10.13.1, so the default time zone is deduced correctly from the system setting when R is configured with --with-internal-tzcode (the default on macOS).
しばらくバージョンをあげる予定がなかったり、いますぐにこの警告を消したい時は、ここにある通り「裏技」を使う。
Sys.setenv("TZ" = "Asia/Tokyo")
安心安心。
熱いプルリクエストをお待ちしております
今日の話。先日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経由でお伝えいただけると幸いです。