  |
はてなキーワード: メタデータとは
マンガ画像のブログへの無断転載･掲載はみんなやっているからやってよいのか？という問題の話。
案の定コメント欄にkensuu御大が登場して和解しちゃってるいつものパターンだけど、俺もこの説得される前のブログ主(yarukimedesu)さんと同じ考えなんだよね。批評目的じゃないのに転載するべきじゃないと思ってる。
漫画一冊のページって250ページぐらいだっけ？そのうちの一つのページを一つのブログが転載しても、「分量的にごく僅かだから批評目的じゃなくても問題無い」ってkensuuみたいな人は主張するわけだ。
でもさ、例えば同じ人間が250のブログ作ってそこに1ページづつ転載したらどうなるんだろう。
一つ一つのブログに掲載されているページはたったの1ページだから問題無い？
でもトータルで見れば全てのページがネット上にアップされてることになるから、「この漫画の12ページ目のurlはhttp://~~~で、13ページ目はhttp://~~、14ページ目は....」というメタデータさえあれば一冊丸々自動で取得できちゃうよね。
分量が少ないからお咎め無いだろうとか、そういう問題じゃないんだわ。ましてや「違法でもネットにアップしたら売り上げが伸びて作者も喜ぶからOK」ってどの口がそういう事を言えるんだよ。ちょっと酷い。絶句。
批評目的で無ければ転載しちゃいけないっていう決まりがある以上はそれを守るべきじゃない？
nanapiに投稿されているレシピがどのくらいあるのか知らないけど例えば10万レシピだとして、一つのブログにつき10レシピだけ転載して、そういうブログを1万作ればnanapiのコンテンツは全て丸写しできるよね。それっていいの？そういうことされて、kensuuは平然としていられる？一つのブログには10個のレシピしか転載されてないからnanapi側は抗議しようが無いってことになるよ。
仮にも社長としてサービスを運営している人の態度じゃないよなあ。まあブログ主もamazon画像なら何に使ってもいいと思ってる時点で同じアナのムジナだけど。
例えばCiNii Articlesみたいに図書館系のDBにGoogleが乗り入れるようになった結果、そのデータつーかメタデータ・レコード自体はWebで容易に目にできるようになったし、その先にあるフルテキストとか資料のアクセシビリティもある程度向上した。
んだけど、これって一方で、図書館情報学系の用語で探す時のノイズを爆発的に増加させたんですよね。
例えば"機関リポジトリ"＋hogeで検索すると、機関リポジトリとは関係ないCiNiiに収録されてる論文のレコードがことごとく上位にヒットするようになってしまった。なんでかってとレコードのページにJAIRO（機関リポジトリポータル）へのリンクが必ず含まれてるから。
普通の図書館のOPACのレコードでも、Googleが拾ってくる館では同様の状況があって、「タイトル」とかの書誌的事項というか項目名が明示されている＝OPACが返すHTMLに文字列として含まれてるせいで、"[書誌的事項]"+hogeとかで検索してもそうなる。
これって、site指定やinurl使っての除外検索すればなんとかならなくはないんだけど、それだと図書館系DBのリソースは別に検索をしなきゃならないっつうね。
こういう図書館のもってるリソースの存在感が増したせいで（語の）図書館情報学用語（として）の存在感が減ったのって、Web屋と図書館屋のどっちかが責をおうべきものなんですかね。負うならどっちがより重いんですかね。
膨大なメタデータを準備して、添付して、っていうだけでも、かなりのコストがかかるよね。
まあ大半をプログラムで処理するにしても、そのプログラムの開発にもコストがかかるわけで、
まだ電子書籍がロクに売れていない状況で、そうした投資をするのは難しいんじゃね。
メタデータにしても、
独自規格でやると汎用性が無くなるから世界的に規格を統一して、
とかやってると時間がかかりそう。
徐々にやっていくしかないんじゃないの。
電子書籍議論が華々しいけど、どうしても僕は納得がいかない。なので、一度某所に名前付きで書いたものを、少しでも騒ぎになってくれる事を願って、編集してここに掲載する。僕が誰かわかった人は、黙ってくれるとありがたい。
まず、今の電子書籍に対する不満は、そもそも今の電子書籍の環境じゃ、生涯付き合えないということ。iBooks程度のインターフェイスだって、100冊もあれば面倒な事が多い。検索機能も無い、それ以外のツールはもっと酷い。生涯付き合うなら一万冊の管理をこなせるようになってほしい。一万冊というのは、読書家の一生を考えれば、決して無謀な数字じゃない。数代続く学者一家ならそれくらい書庫にあったりしてもおかしくないし、図書館で借りたりすれば、10歳から60歳までで一万というのはあり得る数字。マンガを買い込めば、普通の人でも数千冊は読破可能。
これくらいでも、一万冊と付き合うのは難しいだろうけど、ひとつひとつの機能は決して難しいとは思わない。
また、書籍自身も単なる複製で終わってしまっているので、これも不満。例えばこんな機能があってもいいはずだ。
要するに、紙だと必然的に対処せざるを得ないものを排除して、今まで頭を使ってこなしていた事を電子側でこなしてほしいのだ。
特に歴史物だと、今自分が読んでいる箇所がどこの場所で、いつの年代かがわからなくなる。紙の場合は、巻頭または巻末に資料があるけど、電子であれば、読んでいる場所からその場で呼び出せるようになってほしい。もし小説のネタバレをするようなら、進行状況に合わせて内容を変化させれば良い(既出の地名だけを表示する、など)。
こうした機能はゲームならおなじみで、主人公の位置をマップで示したり、あらすじが進行中に挟まって後から確認すると言った事が出来るけど、今の電子書籍は全くそういうことを学んでいない。これじゃ、値段を下げるくらいしか売り方が無い。こうした機能がつけば、同額か、値段を上げたって問題ないと思うくらい。元々文庫やマンガは安いので、これ以上値段を下げる議論なんてしていたら、業界自体が死んでしまう。付加価値で勝負してくれた方がよっぽど良い。
たまに「やっぱり紙の方が良い」という議論があるけど、決してそんな事無い。引っ越しでダンボールの中に蔵書がまぎれたり、本棚を二重に組んで取り出せないとか、紙の不便さは山のようにある。問題は、それを電子書籍が解決していない事だ。イノベーションでも、顧客需要でもなく、惰性で電子書籍に取り組んでいるからいけないのだけど。読書家の皆さんは、もっと声を大にして「紙は不便」と言おう。
うまくまとまらないので、箇条書きにする。思考メモみたいなもんなので、結局何が言いたいのになってるかもしれない。
価値付け→目新しさ、ためになる、需要のある事実、歴史的に重要な事実、リスペクトしてる発信者からの情報、etc、色々な価値があるけど、まとめて｢情報の重さ｣ということにする。
時事問題や災害等、事実自体が重いケースは除き、情報の一次発信者によってある程度重さの初期値が左右される。
既存メディアでは、大手マスコミなど、情報を加工し提供している所で重さが操作される。
ネットでは、情報の受け取り手がバズによって重さを加算していく。
http://anond.hatelabo.jp/20110307103006 自分の書いたものから一部
TL に出てきたものを RT するとき→自分がフォローしている人が回してきた情報→フォローしてるってことは信用や友好や情報価値などがあるということ→情報の価値や精査の連鎖がある
工作アカウントが RT する→こういうアカウントはスパムっぽかったりするのであまりフォローされない（単純につまらん）→フォローするのはフォロワー数が欲しいだけの人や自動フォロー→そういう人のツイートはまたつまらないのであまり有意義なツイートをする人にフォローされて無い→情報価値が上がらない連鎖
てな感じで、Twitter の場合、ツイートが RT されて自分の TL に来るまでに｢信用の連鎖｣や｢情報の精査｣がある。だれが RT したか調べなくても TL という経路を伝わってくる以上、それがあるわけ。
ところが、はてぶのような仕組みにはそれがない。数字にしか意味が無いのがまずい。クソみたいな工作員の3ブクマでも、3ブクマなわけよ。これが Twitter なら全然フォロワーいない奴の 3RT には意味ないじゃん。そうはならないのがはてぶ。
情報を重くする。情報にメタデータをつける。情報に信用度をつける。または下げる。色々が処理がされて、再発信される。受け取り手は発信者でもある。発信者と受信者の区別がなくなっていく。ゆるやかな情報の共有。
同時性が必要。
情報を重くするには人の判断が必要→判断をするにはリテラシーだけでなく感情もかかわる。同じ瞬間に共有していることで一気に意思や感情がかかわりやすくなる。
リアルタイムで中東からの声を聞いた人達が、国内の発信者と同じ距離感でそれを捉えて、革命自体を身近に感じたように。
さらに同時性がどれだけ高いかということ自体が情報に重みを加算する。
シーケンシャルなメディアって他に言い方わからないので俺俺用語。
シーケンシャルでないメディア。検索エンジンや過去のログや Wikipedia や書籍等。いつでもどれでもどこからでも見れるメディア。これらは人の好奇心や知識欲がある限り、ずっと生き残るだろう。
例えば、アニメは初放送の時はシーケンシャルなメディアで、放送後に発売された DVD はシーケンシャルじゃないメディア。
最大のシーケンシャルなメディアは現実世界。現実世界は万人と共有している。
現実世界の時間軸とリンクした仮想世界も同等の同時性がある、MMORPG など。
ニコニコ動画は、動画の中にコメントの時間軸を入れる事で、仮想的に同時性を演出している。ニコニコ動画のどの動画をいつ見ているかというのは、現実世界の時間軸での同時性だし、これにも大きな価値があるが。（世界の新着動画や生放送など）
今サッカーの放送を見ている、今人気アニメの第何話を見ているという同時性。それと相互に依存する情報の重み付けと共有。
今の日本のテレビの一番のネックはこの情報の重み付けと共有が外部に依存していること。
ネットでは境目がない。内包されている。
テレビでは、分離されている。テレビで発せられた情報がネットで重みを加算されることも多い。
（俺俺メモ。そー考えると、昔ながらのライブやイベントというのは、テレビよりむしろネットにずっと性質が近い気がする。いや、もっと昔ながらの口コミや言い伝えにはネットと同じように情報を重くする仕組みが受け取り手自身にあった。テレビというメディアが逆に異質なんじゃないか？）
情報の重み付けと共有は、同時性によって加速されるから、同時性のないシーケンシャルなメディアは段々価値がなくなっていくか、ウケが悪くなっていくだろう。
海外メディアでは新聞局や通信社やテレビ局がネットの利点を生かした発信をしている。ライブブログなど、ほぼリアルタイムで更新される情報群。テレビ側では、ネットのゆるやかな共有、重み付け、同時性を放送の中に取り込む動き。
http://wiredvision.jp/news/201103/2011030719.html wiredvision アルジャジーラの「ソーシャル・ネットTV」
この差を解決できないメディアはただのインフラになっていくと考えている。（百年スケールだろうが）
まともな考えなら、それもメディアに取り込もうとするから、アルジャジーラのような取り組みはとめられないだろう。（日本国内はしらん）
この差を解決できないメディアはただのインフラになっていくと上で書いたけど、そのインフラこそがテレビの強さ。同時性、共有、これが巨大になっていくと今のネットワークでは帯域幅が足りない。テレビにはそういう問題がない。
そう考えると、ネットがインフラとしてテレビを利用するようなものが今後増えてくる。アルジャジーラの取り組みはまさしくそれ。
ネットの情報は信用できない、だからネットはと言われるが、情報に重みをつけるのは俺ら自身だ。そのために出来る事は、リテラシーを育てること。
http://anond.hatelabo.jp/20110307054102 俺の書いたもので申し訳ないけど、伝えたいことは大体書いてある。
今後iPadでWWWを見る人が増えるかも知れないので、サークルのWWWサイトで公開しているパロディ同人誌をsigilでePub化しようかと思ったんだが、メタデータの取り扱いがよくわからないので色々考えてみたメモ。
まず前提として、同人誌のePub化を行うにあたり、各種メタデータを書く必要がある。その際、一部同人界隈で使われている、暗喩、符丁、伏字の類は一切使わないこと。それに抵抗があるコンテンツはePub化しないほうがいい。(そもそもそんな内容のものをWWWで公開すんなって話でもある。mixiでやっとけ。pixivは他人に見られることが前提のサービスだからやめとけ。)
メタデータを読むにあたり参考にしたのはこれ http://ryoji.sakura.ne.jp/references/rfc2413-j.txt
何がどこまで決まっているのかさっぱり分からないので、的外れな使い方をしているかも知れない。特に著者名とサークル名の扱いの違い(AuthorとPublisherに分けるべきか、どちらもAuthorにすべきか）と、Rightsが怪しい。
2.2.15: ＜rights＞ ＜/rights＞
諸権利に関する表明や、ある権利への参照を表す。本仕様では著作権表示やさらなる諸権利についての説明は直接的に示されるべきである（should）。本仕様ではコンテンツ供給者が、購読権や販売用コンテンツの複製などのライセンス用語を、安全な販売業者に向けて指定する方法を定義していない。
http://lost_and_found.lv9.org/opf/opf_2.0_final_spec_ja.html
完全なオリジナルであれば、堂々と
と書けばよい。もっとも、日本の場合はオリジナルだろうがパロディだろうが、電子書籍としてこれが世に出た時点でメタデータの Title/Author/Date of publication を元に著作権が発生する(無方式主義)ので、わざわざ明記する必要はない気もする。
パロディ同人誌の場合、『元の作品タイトル』を書き、それに対応する著作権情報を書くのがやはり礼儀であろう。複数年続いている作品の場合、年は省いて書いたほうがいいのかもしれない。
例：『バクマン。』であれば、
＞バクマン。 (c) Tsugumi Ohba (c) Takeshi Obara
となる。この場合、(c)表記に出版社がないので書かなくてよいだろう。複数連名の場合漏れなく書くこと。
となる。
例：アニメ『ストライクウィッチーズ』の本であれば、
＞ストライクウィッチーズ (c) 第501統合戦闘航空団
例：『WORKING!!』のアニメ版の足湯回後日談本などを出した場合は俺に教えてくれ、じゃなくて、
＞WORKING!! (c)高津カリノ／スクウェアエニックス・「WORKING!!」製作委員会
自分のサークルでわざわざePub化するとこなんてほとんどないと思う。どこかが同人誌をePub化するサービスを始めたとき、これらのメタデータがどう使われるのか？にとても興味がある。ツッコミとか、自分とこのブログで取り上げて修正とか自由にやってほしい。誰か規格を作ってくれたらそれに乗っかりたい。
iPhoneで撮影した写真に位置情報が付加され云々ということで、先週あたり盛り上がっていたのでまとめておく。
iPhoneのスペック表( http://www.apple.com/jp/iphone/specs.html )には以下のように記されている。
位置情報
このうち、デジタルコンパスは、(静止画のExifには含まれるけど)位置情報ではないので省く。
http://www.fdma.go.jp/neuter/topics/jouhou/190126unyou.html にあるとおり、現在携帯電話からの緊急電話では位置情報を通知する義務がある。それに対しSoftbankでは、http://mb.softbank.jp/mb/support/2G/protect/report_position/ に示されているように、GPSあるいは携帯基地局の情報を用いて知らせるとある。これがiPhoneでも使用されている。その精度は、数100ｍから10,000ｍ程度で、もちろん電波圏外では使用することができない。
これは、Wi-Fi機器のMACアドレスとその位置をひも付けすることにより、Wi-Fiを搭載した携帯機器(今回はiPhone)からのWi-Fi機器の見え方から位置情報を推測する方法で、iPhoneでは、Skyhook( http://www.skyhookwireless.com/ )と提携することによりこの機能を実現している。http://www.skyhookwireless.com/howitworks/coverage.php を見れば分かるとおり、日本でも都市圏ではそこそこの範囲がカバーされている。精度に関しては http://www.skyhookwireless.com/howitworks/performance.php に、10m円で99.8％(つまりほぼ10mの精度が出る)と書いてあるけど本当かなー。
余談だけれども、Skyhookの中の人は少々ビッグマウスなようす。
説明はいらないと思うけどいちおう。詳しい話はWikipediaを参照してもらうとして、GPSの精度は10m円80％というのがさっきの所に書いてあったけど、現在の民生用ではだいたいそのとおり。屋内に関しては、最近では窓から数mであれば測位できるものも多い。GPSはその特性上、移動体での測定に強く(というか、加速度から位置を出すので静止状態だと精度があまりでないGPSは等速直線運動時にいちばん精度が出る。高速移動体はその運動の一部をみると等速直線移動と見なせるため)電車や飛行機(ベルトのランプが消えてから使ってね！)でも使用することができる。AGPSというのは、測位初期に必要な衛星そのものの情報を他の通信手段により取得するもので、精度には本質的には関わらない。
| 方式 | 精度 | 備考 |
|---|---|---|
| 基地局情報 | 数100ｍから10,000ｍ程度 | 圏外では使用不可 |
| Wi-Fi(Skyhook) | 約10m | ほぼ都市圏のみ |
| GPS | 約10m | 屋内使用不可 |
iPhone GPS問題関連のブックマークで「iPhoneのGPSは精度でない」と書いている人がいるけど、たまたまその時がそうだっただけで、そんなことないよ。
静止画にメタデータを埋め込むフォーマットとしてExifというのが策定されていて、GPS情報もここに含まれる。現在発売されているデジタルスチルカメラはだいたい対応しているよ。
んで、iPhoneでは、デフォルトではONの設定を切らない限り、上の3つの方式のうちで取得できた精度のいいものを自動的に静止画に付加しているじゃないかな。
ここからが本題。一番の問題は、ユーザに知らされずに位置情報が付加され、それが外部に出てしまう可能性があることだと思う。これまでのGPSに対応した静止画撮影可能な通信端末(つまりいまどきのGPS搭載携帯電話)はGPS情報が自動的に付加されることはなく、かならずユーザ操作を必要とする。これは、GPSが常時ONでないと測位に数10秒かかるという制限からきているという側面もあるけれど、ユーザに位置情報がついているということを意識付けするという意味でも必要な操作なのだと思う。
まずは位置情報が付加されることを認識すること。アップルは静止画に位置情報を付加するかどうかのオプションつけてデフォルトOFFにするくらいした方がいいと思う。
で、データを外部に出す際に位置情報を出してはまずいものだったら位置情報を削除。iPhoneで削除できるかは知らないので教えてください。PCでやるなら手段はいろいろあるけど、Picasaなら、静止画を選んで、[ツール]-[ジオタグ]-[ジオタグをクリア]で削除できる。Picasaではサムネイルの一覧で位置情報の有無がアイコンで表示されるのでわかりやすい。
はてなフォトライフでは、オプションで位置情報の表示のON/OFFを選択(デフォルトOFF)できるんだけど、位置情報付きの写真を表示して「名前をつけて保存」すると、位置情報のON/OFFに関わらず、位置情報がついたまんまだよ。これってまずくない？
(追記)そういえば、はてなフォトライフでは機種で検索できる(これもExifにふくまれている)よなーということで実験。 http://f.hatena.ne.jp/model/iPhone%203GS から写真を適当に保存して、Picasaにつっこむと…。
(http://www.kev009.com/wp/2008/11/on-file-systems/)
訳した。分からなかったところは英語のまま。ファイルシステムについて完全な素人なので変な所があるかも。
ファイルシステムはOSの重要な要素だが最近ではあまり関心を払われていない。ビットが入ってきてビットがでていく……デスクトップシステムにとっては、たいてい十分に働いてくれる……ただし、電源が落ちるまでは。しかし、そんな状況ですら近頃ではあまり困ったことにはならない。
Linuxのファイルシステムの分野には競合製品が多い。ext2が長い間標準とされてきたが、2001年辺りから他の選択肢も主流となった。あまり歴史に深入りせずに要約すると(順番は適当)、ext2が進化してext3となり、ジャーナリング機能が付いた。ReiserFSがリリースされた。SGIはXFSを移植した。IBMはJFSを移植した。
いくつかの理由があって(主に政治的な理由で)ext3がLinuxのデファクトのファイルシステムとなった。
私が古典的ファイルシステムと呼ぶとき、基本的にいつも同じ概念を指している。つまり古典的なUnixレイアウトのファイルシステムにジャーナリング機能を追加したものだ。ここに述べるのは、それら古典的ファイルシステムのハイライトである。
これは後知恵だが、JFSやXFSが牽引力を持たずに、ext3が人々を古典的時代に停滞させたのは一種の悲劇だった。しかしながらext3は信頼性を証明し、きちんと動くように一貫として保守されてもいる。
2005年にSunはZFSという爆弾をリリースした。ZFSは私が次世代ファイルシステムと呼ぶ時代への案内人である。
ハードディスクが大きくなるにつれて、バックアップの戦略、完全性(integrity)の検証、巨大なファイルのサポートは前より遥かに重要になってきている。
ここあげるファイルシステムは古典的なVFS lineを曖昧にしたりLVMとRAIDを強固な結合することによって管理を楽にする事を目的としている。
ダメなハードウェアで起きる静かな(観測されない)データの破損も心配の種である。これに対抗するために、次世代のファイルシステムはチェックサムを供えている。
いろんな意味でLinuxのコミュニティーは完全に油断しきっており、多くの開発者はZFSがリリースされるまで次世代ファイルシステムについて真剣に考えてこなかった。Reiser4はいくつかの新しいアイデアを持っていてキラーファイルシステムとなろうとしたが、Hans Reiserは、他のカーネル開発者との著しく酷い関係を楽しんでいたのだった。ただ幸運な事に、いまではいくつかの、より先進的なファイルシステムが登場しようとしている。
kernel 2.6.28と一緒にext4がリリースされるが、BtrfsやTuxs3が安定するのを待った方がよい。Btrfsの開発陣は短距離走開発を行っているので、Linuxのカーネルの開発サイクルに次か、あるいはその次で取り込まれると思われる。
SSDが普及するのは明白だ。理論的に速度の面で磁気ストレージより圧倒的に早く、現実にも既に書き込み速度が追い付きはじめている。最新のIntelのランダムアクセスやIOPSは非常に印象的である。Btrfsは当初からSSDへの最適化を取りいれようとしている。しかし、これらの新しいデバイスは、更に速度の早い新しいファイルシステムを生むだろう。
私自身の考えでは、ウェアレベリングやFATエミュレーションがSSDの性能を押し止めているため、 新たなファイルシステムが登場すればパフォーマンスを改善できるだろう。
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) |
要旨：
はてブシステムは成長の限界に達しつつある。「現状の方式では」もはやヒューマンな方法でコミュニティをコントロールするしかないが、改善の道はある。
コミュニティが大きくなりすぎたこと。何事も適切な規模がある。例：40人学級はありうるが、400人学級はありえない。
「分割して統治せよ」。コミュニティを適正規模に分割し、問題を局所化し、摩擦を減らせ。
ニコニコ動画のトップページ、「はてブニュース」が参考になりうる。
はてなの現時点での強みは、ネットリテラシーの高いユーザーベースにこそある。これを活用しない手はない。
注：
タグは（カテゴリと違い）複数付加できる。したがって、2chでありがちな問題、「あるスレッドをどの板で建てるべきか」という問題は起きにくい。（cf. 「カモノハシのパラドックス」）。板は決してスレッドの上位概念ではなく、単なる分類（＝メタデータ）に過ぎない。本質的に重要なのはデータつまりスレッドそのもののみである。板概念を破棄すれば、「過疎板」などという存在は生じ得ない。
もはやネットはインスピレーションでサービスを動かす段階ではない。各種の専門家の知見を取り入れ、学際的に綜合して適用すべきだろう。はてなは京都にいるのだから、学校の力を活用するか、優秀なユーザーに聞くのもいいかもしれない。
という問題だと思えば法律とかめんどくさいこと考えずに済むというreblog肯定派向けライフハック。
法とか著作権とかを持ち出すのは要するに相手を黒く（あるいは自分を白く）塗ろうとするただのロビー活動であって、それで問題が解決するわけじゃない。論争は収まるかもしれないけど、怒りだの何だのは未解決のままでしょう。法的に解決したって、イレギュラーな事例を挙げてこれもダメ（あるいはOK）なのかとか、転載はダメだから引用として体裁を整えるなどの抜け穴を活用するとか、法で負ければ次は個人の心情だの何だのを吐露して同情票を集めるとか、結局泥沼じゃん。無意味じゃん。誰が幸せになんのよ。
自分しか見れないローカル、ウェブ上で公開され全員が見れるパブリック、一部の人だけが見れる会員制やリファラ判別など、ある条件下でのみ見れる環境限定の3つにしかアクセスレベルは分けられない（商業レベルではDRMみたいなコピープロテクト手法も取れるけど、いち個人がそれをやるのは非現実的なので無視した）。
泣こうがわめこうがスーパーハッカーの友人が居ようが、これはダメだけどこれはいいなどと個別に閲覧権を設定する方法は存在しない。環境限定が著作者の理想にもっとも近いが、リファラ判別のような古典的なものですら、実現するには技術的な知識が要るし、間違った設定は間違った結界を作る。そもそも画像が表示された画面をキャプチャされる可能性があるので完璧な保護は不可能だ。出来ることといえばお願いだけだが、これも相手が良心的かつ協力的でなければ意味がないので万能ではない。もちろん、あまりに酷い例があれば裁判だの何だので差し止められるが、差し止めたければ時間的なものも含めたコストを著作者が負担する必要がある。
いい悪い関係なく、ウェブ上に何かを置く限りはこのルールを承諾しなければならない。日本の絵描きが描いたイラストをイタリア人が自作だと言ってロシアあたりの掲示板に貼ったのをアメリカ人がまとめてサイトを作りadsenseで儲けるかもしれない可能性は常にあるし、止めようがない。だからこそ著作者たる自分を主張したいなら、イラストにサインを付けたり動画にクレジットを埋め込んだりエロ画像にドメインやロゴを付与したりメタデータにコピーライト入れといたりして、ある程度は自衛する必要がある。
繰り返すが、いい悪いは関係ない。それが可能で、実際に起こりうるんだから受け入れるしかない。街を歩けば自動車に轢き殺されるリスクはゼロじゃない。泣き言を言っても始まらない。マナーで問題は解決しない。承服できないならウェブに置かず、あきらめるか、100%ではないが「お願い」よりは強い権利が得られる商業ルートに乗せるか、マナーよりは強力な世論を形成するしか道はない。
これは現行のブログシステムによって既に実現されているよ。それが読み上げブラウザに優しいかどうかは別だけど。TeXで書いてtex2htmlでHTMLに変換してもいいし。メタデータ作成の自動化は案外存在する。いまさらスクラッチからデザインやらメタデータ作成やらをやるのは効率悪いと思う。どうしても実現したいデザインがブログシステム等では出せないのなら、プログラマ雇って、Movabletype改造させるのも一つの手かな。
この世には音声読み上げタイプのブラウザがあってだな。皆がみんな、同じ画面見ながらネットサーフィンしてるわけじゃないってこと。
それは
なんだよ。
あるいは帯域はすでにボトルネックで無いのだから可視のドキュメントと不可視のメタデータを分離するとか。
ライターとデザイナーとコーダーと全部専門職で分業するよりライター・デザイナーと画面読んでメタデータ作るバイトくんの方が生産性が高いと思うんだけど。
このようにand条件を増やしていくと作業負荷は指数的に増える。
ゆえに日常で進捗させるためには各条件をorにすることが必要。
とか？
うーん、どんな絵面でもHTML+CSSで解釈（コーディング）できるかどうかって聞いてるわけではないんだ。
この中吊りを見れば分かるように写真の配置、コピーの大きさと関係、罫線の引き方、明暗のバランス…とにかく人間の目に入ってくるもの全部には「意味が付加できる」という事実があるのは分かるかな。
なのにHTML+CSSにはそのなんにでも意味が付与できるという現実からごく簡単なテキスト情報（HTML）とその他（CSS）に分離しないといけないという理不尽な強制があるんだよ。
そしてテキスト情報以外は代替可能（＝無価値）だと位置づけられている。
だからHTML+CSSでデザインを始めるとワープロ的使い方以上の場合を志すと必要以上の制限下から作業を始めないといけない苦痛があり、既存デザインをHTML+CSSに直すときには（現実 - 数段構造のテキスト情報)という負荷の高い演算をしないといけない苦痛がある。
100ページのドキュメントがあるサイトならその苦労は反復再利用でペイされる。
しかし一般化してこれからはHTML+CSSでOKと言い切れるのか？と思わずには居られない。
何が問題かというと、ドキュメントのメタデータ作成は本来潤沢なリソースのコンピュータがやるべき仕事なのに、人間様がまずメタデータを作ってからドキュメントの肉付けをすると言う本末転倒の設計がなされていることなんだ。
具体的にコーディングが10年前より楽になった？
ツールとかPCは早く使いやすくなったけどHTML周辺は実効果として全然進歩して無くないかなあ。むしろコードは増えてるのに未だに目でベタに確認しなくちゃいけないのとか。超泥縄じゃん。
