-
-
Notifications
You must be signed in to change notification settings - Fork 1
/
16-synthesis-ja.Rmd
327 lines (260 loc) · 39.6 KB
/
16-synthesis-ja.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
# 結論 {#conclusion}
```{r, include=FALSE}
source("code/before_script.R")
```
## イントロダクション {- #introduction-16}
第 1 章と同様、結論にはコードチャンクはほとんどない。
ここでの目的は、繰り返されるテーマ/概念に言及しながら、本書の内容を総括し、今後の応用や開発の方向性を鼓舞することにある。
この章には前提条件はない。
しかし、第I部 (基礎編) の練習問題を読んで挑戦し、第II部 (拡張機能) のより高度な問題に挑戦し、第III部 (応用編) の章を参考に、ジオコンピュテーションが仕事、研究、その他の問題の解決にどのように役立つかを考えていたならば、より多くのものを得ることができるであろう。
本章は、以下のように構成されている。
Section \@ref(package-choice) は、R で地理データを扱うための幅広いオプションについて説明する。
選択は、オープンソースソフトウェアの重要な特徴である。このセクションでは、様々なオプションの中から選択するためのガイダンスを提供する。
Section \@ref(gaps) では、本書の内容とのギャップを説明し、意図的に省略された研究分野、強調された分野の理由を説明している。
Section \@ref(questions) では、問題に直面した時にどのように質問し、オンラインで解決を探すためのアドバイスを行う。
Section \@ref(next)は、この本を読んだあとで、次はどこへ行くのかという問いに答える。
Section \@ref(benefit) は、Chapter \@ref(intro) で提起されたより広範な問題に戻る。
その中で、ジオコンピュテーションを、手法が一般にアクセス可能で、再現性\index{さいげんせい@再現性}があり、協力的なコミュニティによってサポートされていることを保証する、より広い「オープンソースアプローチ」の一部として考えている。
この最終章では、参加するためのポイントも紹介している。
## パッケージの選択 {#package-choice}
オープンソース全般に言えることだが、R\index{R} の特徴として、同じ結果を得るために複数の方法が存在することが多い。
下記のコードでは、Chapter \@ref(attr) と Chapter \@ref(geometry-operations) にある 3 つの関数を使って、New Zealand の 16 の地域を 1 つの幾何学的形状にまとめている。
```{r 16-synthesis-1}
#| message: FALSE
library(spData)
nz_u1 = sf::st_union(nz)
nz_u2 = aggregate(nz["Population"], list(rep(1, nrow(nz))), sum)
nz_u3 = dplyr::summarise(nz, t = sum(Population))
identical(nz_u1, nz_u2$geometry)
identical(nz_u1, nz_u3$geom)
```
作成されたクラス、属性、列の名称は `nz_u1` から `nz_u3` まで異なるが、その幾何学的な形状は同一であることを Base R 関数 `identical()` を使って検証している。^[
最初の操作は、関数 `st_union()`\index{べくた@ベクタ!けつごう@結合 (union)} によって行われ、クラス `sfc` のオブジェクト (シンプルフィーチャ列) が作成される。
後者の2つの操作は、`sf` オブジェクトを作成し、その各オブジェクトはシンプルフィーチャ列を<u>含んでいる</u>。
したがって、同一なのはシンプルフィーチャ列の中に含まれる形状であって、物体そのものではない。
]
どの方法を使うべきかは、ケースバイケースである。
1番目の方法は `nz` に含まれるジオメトリデータのみを処理するので高速であるが、2・3番目の方法は属性操作を行うので、この後の処理に役立つ可能性がある。
Base R の `aggregate()` 関数を使うか、**dplyr** の `summarise()` を使うかは好みの問題であるが、後者の方が読みやすいだろう。
つまり、R で地理データを扱う場合、たとえ 1 つのパッケージであっても、複数の選択肢から選ぶことができる場合が多いということである。
R のパッケージが増えれば、さらに選択肢は広がる。例えば、古いパッケージの **sp** を使っても同じ結果を得ることができる。\index{sp (package)}
しかしながら、良いアドバイスをしたいという本書のゴールに従うと、パフォーマンスもよく将来性のある **sf** パッケージを推奨する。
このことは、本書のすべてのパッケージに当てはまるが、他の手段の存在を知って自分の選択について正当化できることは、(邪魔にならない程度に) 役に立つことがある。
ジオコンピュテーションをする際の選択で困ることの代表として、 **tidyverse**\index{tidyverse (package)} と Base R のどちらを使うかという簡単に答えられない問題がある。
例えば、次のコードチャンクは、Chapter \@ref(attr) で説明したした `nz` オブジェクトから `Name` 列を抽出する操作を、**tidyverse** と Base R の 2 つの方法を示している。
```{r 15-synthesis-2, message=FALSE}
library(dplyr) # TidyVerse パッケージをアタッチ
nz_name1 = nz["Name"] # Base R による方法
nz_name2 = nz |> # TidyVerse による方法
select(Name)
identical(nz_name1$Name, nz_name2$Name) # 結果の確認
```
ここで、「どちらを使うべきか?」という問題が出てくる。
答えは、「人それぞれ」である。
それぞれのアプローチには利点がある。Base R\index{R!base} は、安定でよく知られており、依存関係が最小である傾向があるため、ソフトウェア (パッケージ) 開発に好まれることが多い。
一方、Tidyverse アプローチは、対話型プログラミングに好まれている。
したがって、2つのアプローチのどちらを選ぶかは、好みと用途の問題である。
本書では、Rの基本演算子である `[` サブセット演算子や、上のコードで示した **dplyr** 関数 `select()` など、一般的に必要とされる関数を取り上げているが、地理データを扱うための、他のパッケージの関数には触れていないものが多くある。
Chapter \@ref(intro) では、地理データを扱うための 20 以上の有力なパッケージが紹介したが、この本ではそのうちのほんの一握りしか紹介されていない。
R で地理データを扱うためのパッケージは他にも何百とあり、毎年多くのパッケージが開発されている。
2024年現在、Spatial [Task View](https://cran.r-project.org/web/views/)で紹介されているパッケージは 160 以上あり、地理データ解析のための無数の関数が毎年開発されている。
```{r 16-synthesis-3, eval=FALSE, echo=FALSE}
# aim: find number of packages in the spatial task view
# how? see:
# vignette("selectorgadget")
stv_pkgs = xml2::read_html("https://cran.r-project.org/web/views/Spatial.html")
pkgs = rvest::html_nodes(stv_pkgs, "#reading-and-writing-spatial-data---gis-software-connectors+ ul li , #geographic-metadata+ ul li , #raster-data+ ul li , #specific-geospatial-data-sources-of-interest+ ul li , #data-processing---general+ ul li , #data-cleaning+ ul li , #data-processing---specific+ ul li , #spatial-sampling+ ul li , #base-visualization-packages+ ul li , #thematic-cartography-packages+ ul li , #packages-based-on-web mapping-frameworks+ ul li , #building-cartograms+ ul li , p+ ul li , #spatial-data---general+ ul li")
pkgs_char = rvest::html_text(pkgs)
length(pkgs_char)
```
R の空間生態系の進化のスピードは速いが、幅広い選択肢に対応するための戦略がある。
アドバイスは、まず 1 つのアプローチを<u>深く</u>学び、利用可能なオプションの<u>広さ</u>を知っておく。
このアドバイスは、R で地理的な問題を解決する際にも他の分野の知識や応用と同様に適用される。
他の言語での開発については、Section \@ref(next) で説明する。
もちろん、同じタスクでもパッケージによっては他のパッケージより性能が良いものもあり、その場合はどのパッケージを使うべきかを知ることが重要です。
この本では、将来性があり (将来も使える)、(他の R パッケージと比較して) 高性能で、(ユーザーや開発者のコミュニティがあり) よくメンテナンスされており、補完的なパッケージに焦点を当てることを目的としている。
また、本書で取り上げたパッケージの中には、重複しているものもあり、例えば、「地図作成用パッケージの多様性」については、本章の「地図作成用パッケージの多様性」で紹介している。
機能が重複することは良いことである。
既存のパッケージと同様の (しかし同一ではない) 機能を持つ新しいパッケージは、オープンソースソフトウェアでジオコンピュテーションを行う重要な利点である回復力、パフォーマンス (開発者間の切磋琢磨と相互学習による部分もある)、選択肢を増やすことができる。
この文脈では、**sf**、**tidyverse**、**terra** や他のパッケージのどの組み合わせを使用するかを決めることは、代替案を知った上で行うべきである。
例えば、**sf**\index{sf} が取って代わるように設計されている **sp** エコシステムは、本書で取り上げたことの多くを行うことができ、その古さゆえに他の多くのパッケージが構築されている。
2024年の執筆時点で、463 のパッケージが **sp** を `Depend` または `Import`しており、2018年10月の 452 からわずかに増加しており、そのデータ構造が広く使われ、多くの方向に拡張されていることを示している。
**sf** の方はというと、2018年に 69、2023年に 431 であり、このパッケージが将来性を持ち、ユーザーベースと開発者コミュニティが拡大していることを強調している [@bivand_progress_2021]。
点パターン解析でよく知られている **spatstat** パッケージは、ラスタ\index{らすた@ラスタ}やその他のベクトルジオメトリもサポートし、空間統計などのための強力な機能を提供する [@baddeley_spatstat_2005]。
また、既存のパッケージでは満たされないニーズがある場合は、開発中の新しい選択肢を研究する価値があるかもしれない。
```{r 16-synnthesis-4, eval=FALSE, echo=FALSE}
# aim: find number of packages that depend on sp, sf and spatstat
sfdeps = devtools::revdep(pkg = "sf", dependencies = c("Depends", "Imports"))
spatstatdeps = devtools::revdep(pkg = "spatstat", dependencies = c("Depends", "Imports"))
spdeps = devtools::revdep(pkg = "sp", dependencies = c("Depends", "Imports"))
length(sfdeps) # 431
length(spatstatdeps) # 34
length(spdeps) # 463
431 / 69
```
## ギャップとオーバーラップ {#gaps}
ジオコンピュテーションは巨大な分野であり、多くのギャップがあることは避けられない。\index{じおこんぴゅてーしょん@ジオコンピュテーション}
特定にトピックやテクニック、パッケージを意図的に強調し、あるいは省略するなど、選択的に行っている。
地理データの操作、座標参照系の基本、データの読み書き、可視化技術など、実際のアプリケーションで最もよく必要とされるトピックを重視するよう努めた。
また、本書は、ジオコンピュテーションに必要なスキルを身につけ、さらに高度なトピックや特定のアプリケーションに進む方法を紹介することを目的としており、いくつかのトピックやテーマは何度も登場する。
また、他で深く取り上げられているトピックをあえて省略した。
例えば、点パターン解析\index{てんぱたーんかいせき@点パターン解析}、空間補間\index{くうかんほかん@空間補間} (例えばクリギング)、空間回帰\index{くうかんかいき@空間回帰}といった空間データの統計的モデリングは、機械学習の文脈で Chapter \@ref(spatial-cv) で触れているが、詳細には触れていない。
これらの手法については、@pebesma_spatial_2023 の統計学的指向の章や、ポイントパターン分析に関する書籍 [@baddeley_spatial_2015]、空間データに適用するベイズ手法 [@gomez-rubio_bayesian_2020;@moraga_spatial_2023]、健康 [@moraga_geospatial_2019] や[山火事深刻度分析](https://bookdown.org/mcwimberly/gdswr-book/application---wildfire-severity-analysis.html) など特定のアプリケーションに焦点を当てた書籍といった優れた資料がすでに存在している [@wimberly_geographic_2023]。
その他の話題としては、リモートセンシングや、GIS 専用ソフトと並行しての R の利用 (ブリッジとしてではなく) などが挙げられるが、これらは限定的である。
これらの話題については、[R におけるリモートセンシングについての議論](https://github.com/r-spatial/discuss/issues/56)、@wegmann_remote_2016 や [Marburg University](https://geomoer.github.io/moer-info-page/courses.html) から入手できる GIS 関連教材など、多くの資料がある。
Chapter \@ref(spatial-cv) と Chapter \@ref(eco) で空間統計推論よりも機械学習に焦点を当てたのは、このトピックに関する質の高いリソースが豊富にあるためである。\index{とうけいすいろん@統計推論}
これらのリソースには、生態系のユースケースに焦点を当てた @zuur_mixed_2009、@zuur_beginners_2017、そして [css.cornell.edu/faculty/dgr2](https://css.cornell.edu/faculty/dgr2/teach/) でホストされている *Geostatistics & Open-source Statistical Computing* の自由に利用できる教材とコードがある。
[*R for Geographic Data Science*](https://sdesabbata.github.io/r-for-geographic-data-science/) では、地理データサイエンスとモデリングのための R の紹介をしている。
また、「ビッグデータ」(ハイスペックなラップトップに収まらないデータセットという意味) に対するジオコンピュテーションはほとんど省略している。\index{びっぐでーた@ビッグデータ}
この決定は、一般的な研究や政策アプリケーションに必要な地理的データセットの大部分は、個人用ハードウェアに収まるという事実によって正当化される (Section \@ref(cloud) 参照)。
コンピュータの RAM を増やしたり、[GitHub Codespaces: 本書のコードを実行可能](https://github.com/codespaces/new?hide_repo_select=true&ref=main&repo=84222786&machine=basicLinux32gb&devcontainer_path=.devcontainer.json&location=WestEurope) のようなプラットフォームで利用できる計算能力を一時的に「借りる」ことは可能である。
さらに、小さなデータセットで問題を解くことを学ぶことは、巨大なデータセットで問題を解くための前提条件であり、本書で強調しているのは「始めること」であり、ここで学んだスキルは大きなデータセットに移行したときに役立つものである。
「ビッグデータ」の解析には、特定の統計解析のためデータベースからデータを抽出することもある。
Chapter \@ref(gis) で紹介した空間データベースは、メモリで処理しきれないデータセットの解析に有用である。
'Earth observation cloud back-ends' は、**openeo** パッケージを使うことで R でアクセスすることができる。
大きな地理データを扱う必要がある場合は、[Apache Sedona](https://sedona.apache.org/) などのプロジェクトや、[GeoParquet](https://paleolimbot.github.io/geoarrow/) などの新しいファイル形式について調べることも勧める。
## ヘルプを求める {#questions}
<!-- Now wondering if this should be an appendix, or even a new chapter?? -->
<!-- Chapter \@ref(intro) states that the approach advocated in this book "can help remove constraints on your creativity imposed by software". -->
<!-- We have covered many techniques that should enable you to put many of your ideas into reproducible and scalable code for research and applied geocomputation. -->
<!-- However, creativity involves thinking coming up with *new* ideas that have not yet been implemented, raising the question: what happens when software *does* impose a constraint because you are not sure how to implement your creative ideas? -->
<!-- In Chapter \@ref(intro) we set out our aim of providing strong foundations on which a wide range of data analysis, research and methodological and software development projects can build. -->
<!-- Geocomputation is about not only using existing techniques but developing new tools which, by definition, involves generating new knowledge. -->
ジオコンピュテーションは大規模で困難な分野であるため、問題や一時的な作業中断は避けられない。
多くの場合、データ解析のワークフローの特定の時点で、デバッグが困難な不可解なエラーメッセージに直面し、「立ち往生」することがある。
また、何が起こっているのかほとんどわからないまま、予期せぬ結果が出ることもある。
このセクションでは、そのような問題を克服するために、問題を明確に定義し、解決策に関する既存の知識を検索し、それらのアプローチで問題が解決されない場合は、良い質問をする技術によって、ポイントを提供する。
<!-- generating new open knowledge by engaging with the community. -->
ある地点で行き詰まったとき、まず一歩下がって、どのようなアプローチが最も解決につながるかを考えてみるのもよいだろう。
以下のステップを順番に試すことで、問題解決のための構造的なアプローチが得られる (すでに試している場合はステップをスキップすることもできる)。
1. 第一原理から始めて、何を達成しようとしているのかを正確に定義する (多くの場合、以下のようなスケッチも必要)。
2. コードの個々の行や個々のコンポーネントの出力を実行し、調べることによって、コードのどこで予期せぬ結果が発生したかを正確に診断する (例えば、RStudio でカーソルで選択し、Ctrl + Enter を押すことによって、複雑なコマンドの個々の部分を実行することができる)。
3. 前のステップで「問題のポイント」と診断された関数のドキュメントを読んでみよう。関数に必要な入力を理解し、ヘルプページの下部によく掲載されている例を実行するだけで、驚くほど大きな割合の問題を解決できる (コマンド `?terra::rast` を実行し、その関数を使い始めるときに再現する価値のある例までスクロールダウンする。例)
4. 前のステップで説明したように R の付属ドキュメントを読んでも問題が解決しない場合は、あなたが見ている問題について他の人が書いていないかどうか、オンラインで広く検索してみるのもよいだろう。検索する場所については、以下のヘルプリストを参照。
5. 上記のすべてのステップが失敗し、オンライン検索で解決策が見つからない場合、再現性のある例で質問を作成し、適切な場所に投稿することができる。
上記のステップ 1 から 3 は自明なことであるが、インターネットは広大であり、検索オプションも多数あるため、質問を作成する前に効果的な検索方法を検討する価値がある。
### オンラインによる解決方法の検索 {#searching-for-solutions-online}
多くの問題に対して論理的なスタートを切るのは、検索エンジンである。
「ググる」ことで、あなたが抱えている問題についてのブログ記事、フォーラムメッセージ、その他のオンラインコンテンツを発見することができる場合があるのである。
問題や質問について明確に記述することは有効な方法であるが、具体的に記述することが重要である (例えば、データセット固有の問題であれば、関数やパッケージ名、入力データセットのソースなどを参照すること)。
また、詳細な情報を記載することで、オンライン検索をより効果的にすることができる。
<!-- To provide a concrete example, imagine you want to know how to use custom symbols in an interactive map. -->
- 引用符を使用すると、返される結果の数を減るため、検索結果が問題に関連する確率を上げる。たとえば、GeoJSON ファイルをすでに存在する場所に保存しようとして失敗した場合、"GDAL Error 6: DeleteLayer() not supported by this dataset" というメッセージを含むエラーが表示される。引用符を使わずに `GDAL Error 6` を検索するよりも、`"GDAL Error 6" sf` のような特定の検索クエリを使用したほうが、解決策が見つかる可能性が高くなる
- [期間の制限](https://uk.pcmag.com/software-services/138320/21-google-search-tips-youll-want-to-learn)を設定する。例えば、過去1年以内に作成されたコンテンツのみを返すようにすれば、進化するパッケージのヘルプを検索する際に便利である
- 追加の[検索エンジン機能](https://www.makeuseof.com/tag/6-ways-to-search-by-date-on-google/)を利用する。例えば、site:r-project.org で CRAN にホストされているコンテンツに検索を限定する
### 助けを求めるための検索 (依頼) 場所 {#help}
ネットで検索しても解決しない場合は、助けを求めてもよい。
これを行うには、以下のような多くのフォーラムがある.
- R の Special Interest Group on Geographic データメーリングリスト ( [R-SIG-GEO](https://stat.ethz.ch/mailman/listinfo/r-sig-geo))
- GIS Stackexchange のウェブサイト ([gis.stackexchange.com](https://gis.stackexchange.com/))
- 大型・汎用プログラミングQ&Aサイト [stackoverflow.com](https://stackoverflow.com/)
- [Posit Community](https://forum.posit.co/)、[rOpenSci Discuss](https://discuss.ropensci.org/) ウェブフォーラム、 [Stan](https://discourse.mc-stan.org/) フォーラムなど、特定のソフトウェアツールに関連するフォーラムなど、特定のエンティティに関連するオンラインフォーラム。
- GitHub などのソフトウェア開発プラットフォームは、R-spatial パッケージの大半の課題トラッカーや、最近では **sfnetworks** パッケージに関する議論 (バグ報告だけでなく) を促すために作られた議論ページなどをホストしている ([luukvdmeer/sfnetworks/discussions](https://github.com/luukvdmeer/sfnetworks/discussions/)を参照)。
- チャットルームやフォーラム [rOpenSci](https://ropensci.org/blog/2022/09/13/contributing-ropensci/) や [geocompx](https://geocompx.org) コミュニティ (これには質問をすることができる [Discord server](https://discord.com/invite/PMztXYgNxp) もある)。本書もここに関係している。\index{geocompx}
- [OSGeoJapan のメーリングリスト](https://www.osgeo.jp/mailing_list) (日本語)
- [r-wakalang Slack](https://github.com/tokyor/r-wakalang) (日本語)
### **reprex** による再現性の例 {#reprex}
良い質問とは、明確に述べられた質問で、さらにアクセスしやすい完全に再現可能な例があるとよい (https://r4ds.hadley.nz/workflow-help.html も参照)。\index{さいげんせい@再現性}
また、ユーザーの視点から「うまくいかなかった」コードを示した後、何を見たいかを説明することも有効である。
再現可能な例を作成するための非常に便利なツールが、**reprex** パッケージである。
予期せぬ動作を強調するために、問題を示す完全に再現可能なコードを書き、`reprex()`関数を使って、フォーラムや他のオンラインスペースに貼り付けられるようなコードのコピーを作成することができる。
青い海と緑の陸地がある世界地図を作ろうとしているとしよう。
前項で説明したような場所で、その方法を尋ねることもできできる。
しかし、あなたがこれまでに試したことの再現可能な例を示すことで、より良い回答が得られる可能性がある。
次のコードは、青い海と緑の陸地がある世界地図を作成するが、陸地は塗りつぶされない。
```r
library(sf)
library(spData)
plot(st_geometry(world), col = "green")
```
このコードをフォーラムに投稿すれば、より具体的で有用な回答が得られる可能性がある。
例えば、Figure \@ref(fig:16-synthesis-reprex) のように、問題を解決する以下のようなコードを投稿してくれる人がいるかもしれない。
```r
library(sf)
library(spData)
# 塗りつぶすために引数を使用
plot(st_geometry(world), col = "green", bg = "lightblue")
```
```{r 16-synthesis-reprex, out.width="49%", fig.show="hold", fig.cap="世界地図の土地を緑色で示した再現可能な例題 (左) と解 (右) の地図。", echo=FALSE, message=FALSE, warning=FALSE}
library(sf)
library(spData)
plot(st_geometry(world), col = "green")
plot(st_geometry(world), col = "green", bg = "lightblue")
```
読者のための練習: 上記のコードをコピーし、コマンド `reprex::reprex()` を実行し (またはコマンドを `reprex()` の関数呼び出しにペーストし)、その出力をフォーラムや他のオンラインスペースにペーストしなさい。
ジオコンピュテーションが、オープンソースとコラボレーションすることで、膨大で進化し続ける知識体系を生み出すことは強みとなり、本書もその一部である。
問題を解決するための自分自身の努力を示し、問題の再現可能な例を提供することは、この知識体系に貢献する方法である。
### 問題の定義とスケッチ {#defining-and-sketching-the-problem}
場合によっては、ネット上で問題解決策を見つけることができなかったり、検索エンジンで答えられるような質問を立てることができないこともある。
新しいジオコンピュテーションの方法論やアプローチを開発するときの最良の出発点は、ペンと紙 (または共同スケッチやアイデアの迅速な共有を可能にする [Excalidraw](https://excalidraw.com/) や [tldraw](https://www.tldraw.com/) などの同等のデジタルスケッチツール) である。方法論開発の作業の最も創造的な初期段階においては、<u>どのような</u>ソフトウェアも思考の速度を落とし、重要な抽象概念から思考を遠ざけることになる。
方法論開発の最も創造的な初期段階において、ソフトウェア (あらゆる種類のもの) は、思考を鈍らせ、重要な抽象的思考から思考を遠ざけることができる。
また、数値的に「前と後」をスケッチできる最小限の例を参照しながら、数学で質問を組み立てることも強く推奨される。
もし、あなたにスキルがあり、問題がそれを必要とするならば、代数的にアプローチを記述することは、場合によっては効果的な実装を開発するのに役立つ。
## 次はどこへ行く? {#next}
Section \@ref(gaps) にあるように、この本は R の地理的なエコシステムのほんの一部しかカバーしておらず、まだまだ発見があるはずである。
Chapter \@ref(spatial-class) の地理データモデルから、Chapter \@ref(eco) の高度なアプリケーションまで、急速に進展している。
学習した技術の統合、地理データを扱うための新しいパッケージやアプローチの発見、新しいデータセットやドメインへの手法の適用が今後の方向性として提案されている。
このセクションでは、この一般的なアドバイスに加え、具体的な「次のステップ」を提案し、以下の**太字**で強調している。
R\index{R} を使って、例えば前節で引用した研究を参考に、さらなる地理的手法や応用について学ぶことに加え、**R そのもの**の理解を深めることが、論理的な次のステップとなる。
R の基本クラスである `data.frame` や `matrix` は、**sf** や **terra** クラスの基礎となるものなので、これらを勉強することで地理データの理解が深まるだろう。
これは、R の一部であり、`help.start()` コマンドで見つけることができるドキュメントや、@wickham_advanced_2019 や @chambers_extending_2016 などによるこのテーマに関する追加リソースを参照することで行うことができる。
また、ソフトウェア関連の今後の学習方向としては、**他の言語によるジオコンピュテーションの発見**が挙げられる。
Chapter \@ref(intro) で紹介されているように、ジオコンピュテーションのための言語として R を学習することには理由があるが、R が唯一の選択肢というわけではない。^[
R の強みは、科学的な再現性を重視し、学術研究において広く使用され、地理データの統計的モデリングを比類なくサポートすることから、特にジオコンピュテーションの定義に関連しています。
さらに、他の言語やフレームワークを学ぶのはコンテキストスイッチというコストが発生するため、ジオコンピュテーションのための 1 つの言語を深く学ぶことを推奨する。
]
*Python*\index{Python}、*C++*、*JavaScript*、*Scala*\index{Scala}、*Rust*\index{Rust} を使っても、同じ深さでジオコンピュテーションを勉強することができる。
それぞれが進化した地理空間能力を有している。
例えば、Pythonのパッケージ [**rasterio**](https://github.com/rasterio/rasterio) は、この本で使われている **terra** パッケージを補足/置換できるものである。
Python のジオコンピュテーションについては、[*Geocomputation with Python*](https://py.geocompx.org/) を参照。
C++\index{C++} では、GDAL\index{GDAL} や GEOS\index{GEOS} などのよく知られたライブラリから、リモートセンシング (ラスタ) データを処理する **[Orfeo Toolbox](https://github.com/orfeotoolbox/OTB)** などのあまり知られていないライブラリなど、数十の地理空間ライブラリが開発されている。
[**Turf.js**](https://github.com/Turfjs/turf) は、JavaScript でジオコンピュテーションを行う可能性を示す一例である。
[GeoTrellis](https://geotrellis.io/) は、Java ベースの言語である Scala でラスタおよびベクタデータを扱うための関数を提供する。
また、[WhiteBoxTools](https://github.com/jblindsay/whitebox-tools) は、Rust で実装された急速に進化するコマンドライン GIS の例を示している。
\index{Rust}
\index{WhiteboxTools}
これらのパッケージ/ライブラリ/言語はそれぞれジオコンピュテーションに有利であり、オープンソースの地理空間リソースのキュレーションリスト [Awesome-Geospatial](https://github.com/sacridini/Awesome-Geospatial) に記されているように、さらに多くの発見がある。
しかし、ジオコンピュテーション\index{じおこんぴゅてーしょん@ジオコンピュテーション}には、ソフトウェア以上のものがある。
学術的・理論的な観点から、**新しい研究テーマや手法の探求・習得**をお勧めできる。
これまで書かれてきた手法の中には、まだ実装されていないものも多くある。
そのため、コードを書く前に、地理的な手法や潜在的なアプリケーションについて学ぶことは有意義なことである。
R で実装されることが多くなった地理的手法の例として、科学的なアプリケーションのためのサンプル戦略がある。
この場合の次のステップは、 [github.com/DickBrus/TutorialSampling4DSM](https://github.com/DickBrus/TutorialSampling4DSM) でホストされている再現可能なコードとチュートリアルコンテンツを伴う @brus_sampling_2018 などの領域の関連記事を読み解くことである。
## オープンソースのアプローチ {#benefit}
この本は技術書であるから、前節で説明した次のステップも技術的なものであることに意味がある。
しかし、この最後のセクションでは、ジオコンピュテーション\index{じおこんぴゅてーしょん@ジオコンピュテーション}の定義に戻り、より広範な問題を検討する価値がある。
Chapter \@ref(intro) で紹介した用語の要素のひとつに、「ジオグラフィック・メソッドはポジティブな影響を与えるものでなければならない」というものがある。
もちろん、「ポジティブ」をどう定義し、どう測定するかは、本書の範囲を超えた、主観的で哲学的な問題である。
どのような世界観を持っていても、ジオコンピュテーションがもたらす影響について考えることは有益なことである。
また逆に、新しい手法は多くの応用分野を開拓する可能性がある。
これらのことから、ジオコンピュテーションはより広範な「オープンソースアプローチ」の一部であるという結論が導き出される。
Section \@ref(what-is-geocomputation) は、地理データ科学 (geographic data science, GDS)\index{でーたさいえんす@データサイエンス} や GIScience など、ジオコンピュテーションとほぼ同じ意味を持つ他の用語を提示した。
どちらも地理データを扱うことの本質を捉えているが、ジオコンピュテーションには利点がある。本書で提唱する地理データの「計算」的な扱い方 (コードで実装されているので再現性がある) を簡潔に捉え、初期の定義にあった望ましい要素に基づいて構築されている [@openshaw_geocomputation_2000]。
- 地理データの<u>クリエイティブ</u>な活用法
- <u>実社会の問題</u>への応用
- 「科学的」な道具を作る
- 再現性\index{さいげんせい@再現性}
再現性は、ジオコンピュテーションの初期の研究ではほとんど言及されていなかったが、最初の 2 つの要素に不可欠な要素であることを強く主張することができる。
再現性\index{さいげんせい@再現性}は、
- (共有コードで容易に利用できる) 基本から応用へと焦点を移すことで、<u>創造性</u>を促進する。
- 「車輪の再発明」を防ぐ: 他の人がやったことを、他の人が使えるのであれば、やり直す必要はない。
- あらゆる分野の誰もが新しい分野であなたの方法を適用できるようにすることで、研究をより実世界での応用に近づけられるようにする。
もし再現性がジオコンピュテーション (あるいはコマンドライン GIS) の決定的な資産であるならば、何が再現性をもたらすかを考える価値がある。
そこで、「オープンソースアプローチ」に行き着くのだが、これには 3 つの主要な要素がある。
- コマンドラインインターフェース\index{こまんどらいんいんたーふぇーす@コマンドラインインターフェース} (CLI): 地理的な作業を記録したスクリプトの共有と再現を促進する
- オープンソースソフトウェア: 世界中の誰もが検査し、改良できる可能性がある。
- 活発なユーザーと開発者コミュニティは、補完的でモジュール化されたツールを構築するために協力し、自己組織化している。
ジオコンピュテーション\index{じおこんぴゅてーしょん@ジオコンピュテーション}という言葉があるように、オープンソース的アプローチは単なる技術的な存在にとどまらない。
商業的、法的な制約を受けず、誰でも使える高性能なツールを作るという共通の目的を持って日々活動している人たちで構成されるコミュニティである。
地理データを扱うオープンソース的アプローチには、ソフトウェアの動作に関する技術的な問題を超えて、学習、コラボレーション、効率的な分業を促進する利点がある。
特に GitHub のような、コミュニケーションとコラボレーションを促進するコードホスティングサイトの出現により、このコミュニティに参加する方法はたくさんある。
手始めに、興味のある地理的なパッケージのソースコード、issues、commits のいくつかに目を通すとよいだろう。
`r-spatial/sf` GitHub リポジトリをざっと見ると、**sf**\index{sf} パッケージの基礎となるコードをホストしており、100 人以上がコードベースとドキュメントに貢献していることがわかる。
さらに何十人もの人が、質問をしたり、**sf** が使っている「上流」のパッケージに貢献している。
その [issue tracker](https://github.com/r-spatial/sf/issues) には 1,500 以上の問題がクローズされ、より速く、より安定した、ユーザーフレンドリーな **sf** を実現するための膨大な作業が行われている。
この例は、数十のパッケージのうちのたった一つの例であるが、R を非常に効果的で継続的に進化するジオコンピュテーションとするために行われている知的作業の規模を表している。
GitHub のような公的な場で絶え間なく起こる開発活動を見るのも勉強になるが、自分が積極的に参加することでより大きな収穫を得ることができる。
これは、オープンソースの最大の特徴で、人々の参加を促すものである。
この本自体もオープンソース化した結果である。
これは、過去 20 年間の R の地理的機能の驚くべき発展によって動機づけられたが、共同作業のためのプラットフォーム上での対話とコード共有によって、現実的に可能になった。
本書が、地理データを扱うための有用な手法を広めるだけでなく、よりオープンソースに近いアプローチをとるきっかけになればと願っている。