  |
はてなキーワード: バッファリングとは
megumin1 一般にはfdがterminalだと行単位でflushされる、結果write等のsyscallの回数が増えるなどの違いがありますよ。まずはその辺りから疑うべき話だと思うのですが、記事中で一切言及がないのはつまりはそういうことでしょうか？
https://b.hatena.ne.jp/entry/s/qiita.com/ko1nksm/items/f6c033c194935b642a39
つまりバッファリングの問題だということ…… ではないよね。日本語的に考えて。
はてなのテクノロジーの人気記事人気コメントでも、何だかよく分からない含みのあるコメントが最近増えてきた気がするのは俺だけかな。支持してる人たちは何を意味してる（と思った）のか解説してほしい。
Youtubeはマクロとミクロのレベルで数多くのネットワーク状況に対する情報を提供してくれます。我々はそれらの情報も利用可能でゲーマーの体験を調整、拡大が可能です。
その通りです。StadiaをYoutubeとは異ならせる2つの事象があります。YouTubeはバッファ使用が可能でリアルタイムでもなく、ゲームのようにインタラクティブでもありません。Stadiaはバッファリングができません。Stadiaはフレーム数が絶対的に正確である必要があります。
次に2つ目ですが、ユーザがDoomやAssasin's Creedレベルの画質のゲームを遊ぶ場合、その期待はYouTube向けにユーザが作成したコンテンツよりもずっと高くなります。
さらにもう1つお話する価値がある点として、YouTubeとStadiaの繋がりについて今後も多くのことを話し、デモをしていきますが、大前提としてゲームとはリンクであり、リンクは無数の方法で配布、探索、共有が可能であることが挙げられます。
その通り、全く仰る通りです。あなたが仰った通りのシナリオになります。また例えばEurogamerが新しいゲームをレビューしているとしたら、ユーザはレビュー記事をクリックするだけでダウンロードすることもなく、パッチを当てることもなく、インストールすることもなしに簡単にそのゲームを試すことが可能です。また他にはあなたの記事が新しいマップやキャラクター、レベルについて記述している場合でもそうです。我々にはState Share(状態共有)と呼ばれる既存の技術と一緒に働くとても強力な新技術を用意しています。
State Shareは本当にとても強力な機能でユーザが最新のバージョンのゲームを遊んでいる時に、同時に友人や私、または世界中にそのゲームをストリーミング可能です。誰が相手でも問題ありません。またユーザがゲーム内での最新の武器、例えばDoomのFlaming Swordや、とにかくそのゲームで最高のアイテムを入手したとします。そして私が「カッコイイ！ 私もそのFlaming Swordが欲しい！」と考えたとしましょう。私がそのビデオをクリックすればそのメタデータがそれら全ての属性を直接私のゲームにも転送します。だから誰でもが他人のビデオストリームに飛び込めるだけでなく、その他人の状況全てと共にゲームに飛び込めるのです。これは開発者とゲームが設定可能です。これについては他にも例がありますが、1つはユーザがゲームの特定の難しい状況に陥った場合に、ユーザはコミュニティにその状況を解決できるか試してもらうことが可能です。全く同じ状況で渡すことができます。
我々がYoutubeとの接続で行っている別の例は、典型的なシナリオとして、私がパズルベースのアドベンチャーゲームをやっている場合によくある状況があります。そのゲームのあるポイントで立ち往生してしまいました。その特定のパズル、例えばトゥームレーダーのある墓や何かができないとしましょう。現状では電話を取り上げるかラップトップに向かいヒントをダウンロードするでしょう。それかYoutubeに向かって動画を探します。しかしStadiaではボタンを押して「Hey, Stadia. このボスはどうやってやっつければ良いんだい？」と聞きます。するとStadiaがYoutubeの動画を探してきてゲーム内で再生します。私はレベルの解答を見て続けることができます。
先程、申しましたゲームとはリンクであるとの点ですが、任意のWebサイトはリンクを持つことができます。Discord、Facebook、Twitter、電子メール、テキストメッセージ、WhatsApp、Googleの検索結果、さらにはGoogle Play Storeですらゲームの配布が可能になります。
リンクです。
そうです。インターネット全体に渡り分散された広大な領域の利点を得ています。我々は開発者とパブリッシャに対し、インターネットがストレージであるとのコンセプトを広めています。もちろんStadiaは専用のストレージを持っています。しかし我々は開発者に対しゲームを自社のコミュニティへ持っていくことも、例えどこにコミュニティがあろうとも許可します。このことが配布と探索を開発者にとってとても良い意味で逆さにします。また我々にはとても高速なマーケティング技術がありますので、パブリッシャは体験をできる限り多くの人々にとても効率の良い手段で配布することが可能です。
コミュニティに対するモデレーションにはとても強固なアプローチを取ります。YouTubeは途方もない投資をこの領域に行ってきました。我々はそこに提携をし、さらに家庭レベルでも行います。我々はこの業界でも最も優れたペアレンタルコントロールとゲーマーの健康のコントロールを提供します。両親は子供が何を遊ぶか、誰と遊ぶか、いつ遊ぶかを管理可能です。
我々は全てをユーザの制御下に置くことを使命としています。Googleが提供する制御と機能と同じレベルのものがStadiaでも提供されるとお考え下さい。
それは私共が答えることではありません。Stadiaはゲームの新しい開発の仕方、ゲームの新しい探し方、ゲームの新しい楽しみ方を提供します。我々には大きな未来への志があります。大規模に発展したいと考えています。それは一晩で起こることではありません。また我々はこれまでに存在し、我々をここまで導いて下さった物、全てを尊敬しています。私達は業界全体が成功し、成長することを望んでいます。
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
確かに入出力にバッファーを挟む事で割り込み(Interrupt)が減るので(Stack処理されてるかもしれないが)Queueの処理速度は向上するかもしれません。
ただし
等といったExceptionに対して、特定のアクション(叱る)しか出来ていない事から、上位クラス(上司)が既に存在し
本来バッファーも存在しているハズだが上位クラスにも以下のようなバグが潜んでいる可能性が高く感じます。
※資料不足の為要調査
また、この資料からは詳細はわかりませんが(恐らく)
様に見受けられます。
以上の事から、上位クラスおよびFRIEND関係にあるクラスの間に、バッファリング、スケジューリング、同期処理をするラッパークラスを挟み
Table of Contents： ||||||
| オープンソースソフトウェアとGIS | Open Source software and GIS | Open Source software and GIS | 1 (6) |
| オープンソース概念 | Open Source concept | 1 (2) | |
| オープンソースGISとしてのGRASS | GRASS as an Open Source GIS | 3 (2) | |
| ノースカロライナサンプルデータセット | The North Carolina sample data set | 5 (1) | |
| この本の読み方 | How to read this book | 5 (2) | |
| GISの概念 | GIS concepts | GIS concepts | 7 (14) |
| 一般的なGISの原理 | General GIS principles | 7 (6) | |
| 地理空間データモデル | Geospatial data models | 7 (4) | |
| GISデータとシステムの構成 | Organization of GIS data and system | 11 (2) | |
| 機能 | functionality | ||
| 地図投影法と座標系 | Map projections and coordinate systems | 13 (8) | |
| 地図投影原理 | Map projection principles | 13 (3) | |
| 一般的な座標系とdatums | Common coordinate systems and datums | 16 (5) | |
| GRASSをはじめよう | Getting started with GRASS | Getting started with GRASS | 21 (32) |
| 第一歩 | First steps | 21 (16) | |
| GRASSのダウンロードとインストール | Download and install GRASS | 21 (2) | |
| データベースとコマンドの構造 | Database and command structure | 23 (3) | |
| GRASS6のためのグラフィカルユーザインタフェイス: | Graphical User Interfaces for GRASS 6: | 26 (1) | |
| QGISとgis.m | QGIS and gis.m | ||
| ノースカロライナを用いてGRASSを開始 | Starting GRASS with the North Carolina | 27 (3) | |
| データセット | data set | ||
| GRASSデータ・ディスプレイと3D可視化 | GRASS data display and 3D visualization | 30 (4) | |
| プロジェクトデータ管理 | Project data management | 34 (3) | |
| 新しいプロジェクトでGRASSを開始 | Starting GRASS with a new project | 37 (7) | |
| aのための座標系の定義 | Defining the coordinate system for a | 40 (4) | |
| 新しいプロジェクト | new project | ||
| 空間投影されていないxy座標系 | Non-georeferenced xy coordinate system | 44 (1) | |
| 座標系の変換 | Coordinate system transformations | 44 (9) | |
| 座標系のリスト | Coordinate lists | 45 (2) | |
| ラスタとベクトル地図の投影 | Projection of raster and vector maps | 47 (1) | |
| GDAL/OGRツールで、再投影 | Reprojecting with GDAL/OGR tools | 48 (5) | |
| GRASSデータモデルとデータの交換 | GRASS data models and data exchange | 53 (30) | |
| ラスターデータ | Raster data | 54 (16) | |
| GRASSの2Dの、3Dのラスターデータモデル | GRASS 2D and 3D raster data models | 54 (2) | |
| 領域の統合と境界 | Managing regions and boundaries | raster map resolution | |
| ジオコードされたラスターデータのインポート | Import of georeferenced raster data | 58 (8) | |
| スキャンされた歴史的地図のインポートとジオコーディング | Import and geocoding of a scanned | 66 (3) | |
| ラスターデータエクスポート | Raster data export | 69 (1) | |
| ベクトルデータ | Vector data | 70 (13) | |
| GRASSベクトルデータモデル | GRASS vector data model | 70 (3) | |
| ベクトルデータのインポート | Import of vector data | 73 (5) | |
| xy CAD描画のための座標変換 | Coordinate transformation for xy CAD drawings | 78 (2) | |
| ベクトルデータのエクスポート | Export of vector data | 80 (3) | |
| ラスターデータを使う | Working with raster data | 83 (86) | |
| ラスター地図を表示、管理 | Viewing and managing raster maps | 83 (22) | |
| ラスターデータの表示と、カラーテーブルの割り当て | Displaying raster data and assigning a color table | 83 (3) | |
| ラスター地図に関するメタデータを管理 | Managing metadata of raster maps | 86 (2) | |
| ラスター地図のクエリとプロファイル | Raster map queries and profiles | 88 (2) | |
| ラスター地図の統計 | Raster map statistics | 90 (1) | |
| ラスター地図のズームと、部分集合の生成 | Zooming and generating subsets from | 91 (1) | |
| 簡単なラスター地図の生成 | Generating simple raster maps | 92 (2) | |
| 再分類と再スケーリング | Reclassification and rescaling of | 94 (3) | |
| ラスター地図 | raster maps | ||
| ラスター地図タイプの記録と値の置換 | Recoding of raster map types and value replacements | 97 (2) | |
| カテゴリラベルの割り当て | Assigning category labels | 99 (4) | |
| マスキングとノーデータ値の取り扱い | Masking and handling of no-data values | 103(2) | |
| ラスター地図の計算 | Raster map algebra | 105(10) | |
| 整数と浮動小数点データ | Integer and floating point data | 107(1) | |
| 基本的な計算 | Basic calculations | 108(1) | |
| “if"状態を使う | Working with ``if'' conditions | 109(1) | |
| r.mapcalcのNULL値の取り扱い | Handling of NULL values in r.mapcalc | 110(1) | |
| r.mapcalcでMASKを作成 | Creating a MASK with r.mapcalc | 111(1) | |
| 特別なグラフ演算子 | Special graph operators | 112(1) | |
| 相対的座標での近傍演算 | Neighborhood operations with relative coordinates | 113(2) | |
| ラスタデータの変換と内挿 | Raster data transformation and interpolation | 115(11) | |
| 離散的ラスターデータの自動的ベクトル化 | Automated vectorization of discrete raster data | 115(3) | |
| 連続フィールドの等値線の描画を生成 | Generating isolines representing continuous fields | 118(1) | |
| ラスタデータのリサンプリングと内挿 | Resampling and interpolation of raster data | 119(5) | |
| ラスター地図のオーバーレイとマージ | Overlaying and merging raster maps | 124(2) | |
| ラスターデータの空間分析 | Spatial analysis with raster data | 126(29) | |
| 近傍分析とクロスカテゴリー統計 | Neighborhood analysis and cross-category statistics | 126(7) | |
| ラスタフィーチャのバッファリング | Buffering of raster features | 133(2) | |
| コストサーフェイス | Cost surfaces | 135(5) | |
| 地勢と分水界分析 | Terrain and watershed analysis | 140(13) | |
| ランドスケープ構造解析 | Landscape structure analysis | 153(2) | |
| ランドスケーププロセスモデリング | Landscape process modeling | 155(11) | |
| 水文学的、地下水のモデル | Hydrologic and groundwater modeling | 155(3) | |
| 浸食と宣誓証言モデル | Erosion and deposition modeling | 158(8) | |
| ラスタベースのモデルと解析に関するまとめ | Final note on raster-based modeling and analysis | 166(1) | |
| ボクセルデータを使う | Working with voxel data | 166(3) | |
| ベクトルデータを使う | Working with vector data | 169(94) | |
| 地図の表示とメタデータ管理 | Map viewing and metadata management | 169(4) | |
| ベクトル地図を表示 | Displaying vector maps | 169(3) | |
| ベクトル地図メタデータ維持 | Vector map metadata maintenance | 172(1) | |
| ベクトル地図属性管理とSQLのサポート | Vector map attribute management and SQL support | 173(14) | |
| GRASS6でのSQLサポート | SQL support in GRASS 6 | 174(7) | |
| サンプルSQLクエリと属性変更 | Sample SQL queries and attribute modifications | 181(4) | |
| 地図再分類 | Map reclassification | 185(1) | |
| 複数の属性があるベクトル地図 | Vector map with multiple attribute tables: layers | 186(1) | |
| ベクトルデータをデジタル化 | Digitizing vector data | 187(5) | |
| 位相的データのデジタル化の一般原理 | General principles for digitizing topological data | 187(2) | |
| GRASSでの対話的なデジタイジング | Interactive digitizing in GRASS | 189(3) | |
| ベクトル地図クエリと統計 | Vector map queries and statistics | 192(4) | |
| 地図のクエリ | Map queries | 192(2) | |
| ベクトルオブジェクトに基づくラスター地図統計 | Raster map statistics based on vector objects | 194(2) | |
| ポイントベクトル地図統計 | Point vector map statistics | 196(1) | |
| 幾何学操作 | Geometry operations | 196(20) | |
| 位相的な操作 | Topological operations | 197(6) | |
| バッファリング | Buffering | 203(1) | |
| フィーチャの抽出と境界のディゾルブ | Feature extraction and boundary dissolving | 204(1) | |
| ベクトル地図を修理 | Patching vector maps | 205(1) | |
| ベクトル地図のインターセクディングとクリッピング | Intersecting and clipping vector maps | 206(3) | |
| ベクトルの幾何の変換と3Dベクトルの作成 | Transforming vector geometry and creating 3D vectors | 209(2) | |
| 点からのコンベックスハルとトライアンギュレーション | Convex hull and triangulation from points | 211(1) | |
| 同じ位置の掘り出し物の複数のポイント | Find multiple points in same location | 212(2) | |
| 一般的な多角形境界の長さ | Length of common polygon boundaries | 214(2) | |
| ベクトルネットワーク分析 | Vector network analysis | 216(11) | |
| ネットワーク分析 | Network analysis | 216(5) | |
| 直線的な参照システム(LRS) | Linear reference system (LRS) | 221(6) | |
| ラスタへのベクトルデータ変化 | Vector data transformations to raster | 227(3) | |
| 空間的な内挿と近似 | Spatial interpolation and approximation | 230(19) | |
| 内挿方法を選択 | Selecting an interpolation method | 230(5) | |
| RSTによる内挿と近似 | Interpolation and approximation with RST | 235(2) | |
| RSTパラメタの調整: テンションとスムージング | Tuning the RST parameters: tension and smoothing | 237(4) | |
| RSTの精度を評価 | Estimating RST accuracy | 241(3) | |
| セグメント化処理 | Segmented processing | 244(3) | |
| RSTとのトポグラフィー分析 | Topographic analysis with RST | 247(2) | |
| ライダーポイントのクラウドデータを使う | Working with lidar point cloud data | 249(8) | |
| ボリュームに基づくは内挿 | Volume based interpolation | 257(6) | |
| 3番目の変数の追加: 高度のある降水量 | Adding third variable: precipitation with elevation | 258(3) | |
| ボリュームとボリューム-時間内挿 | Volume and volume-temporal interpolation | 261(1) | |
| 地球統計学とスプライン | Geostatistics and splines | 262(1) |
それはたぶん漫画における記号やら文脈やらを拾う慣れの違いと、
同意。
3倍の速度で読んで、バッファリングして、3倍の速度で処理可能な漫画読み込みエンジンにかける感じじゃないだろうか。
たとえアニメが頭の中で脳内再生されるとしても、それは別に実時間であるとは限らない。感覚として気持ち悪いのは理解できるけど。
そして横だけど、「理解している」のと「楽しむ」のはちょっと違うよなーと思った。「深く理解する」ことを重要視するあたり、オタク的主張なんだと思うけど。
自分はコマの構図とかより全体の流れを楽しむ派だから、むしろ早く読んで一気に頭に入力してしまいたかったりする。まあ、このあたりも趣味的な話。
