はてなキーワード: 航空写真とは
(ソース:世界の中の東京(東京都環境局) http://www.kankyo.metro.tokyo.jp/attachement/1-1.pdf )
(ソース:東京都建設局 http://www.kensetsu.metro.tokyo.jp/kouen/kouenannai/image/22menseki.pdf )
しかしながら、東京は狭い、というのは数字の上では間違いです。
むしろ、平面的な広がりでは、世界の中でも広い方で、現に人口密度でも、世界の大都市の中では、むしろかなり低いほうです。
その上に、東京の土地使用においては、住宅の占める比率はむしろ他の都市に比べても高い方です。
それにも関わらず、一人当り公園面積が小さく、住宅は狭く感じるのは、なぜなのでしょうか。
それは、「低層の建物が多いから」です。特に、「低層住宅が多いから」です。
森ビルのHPによると、東京23区の平均の容積率は、僅か131%です。
また、いかに東京に低層の建物が多く、公園が少ないかはGoogleマップでも確認できます。
シンガポール: http://goo.gl/maps/EUQR
他の都市では、航空写真で見ても、この縮尺でも確認できる建物が多いですが、東京では、新宿近辺などを除き、この縮尺で確認できないような小さい建物が広がっています。このような低層住宅が広がるのが東京の特徴と言えます。
しかし、このような低層住宅が延々と広がることは、それほど良いものなのでしょうか。
低層住宅といえば聞こえはいいが、しかし、東京の低層住宅というのは、私には良いものだとは思えません。
庭などはほとんどなく、1階の日当たりもほとんどない。また、建蔽率が50%であっても、建物の他の敷地はほとんど駐車場…一般的な東京の低層住宅街と言うのは、このようなものではないでしょうか。
そうではないという人は、高い家賃を払っているか、駅から遠いか、あるいは、郊外に住んでいるような人でしょう。
日本は地震国であるため、高層建築が発達せず、多くの床面積を作るためには、平面的に広がるという方法を選択してきました。しかし、地震に強い建築が確立されつつある今、もはや、僅かな人数しか居住させられないいにも関わらず土地を占有する低層住宅は最早害悪以外の何ものでもないような気がします。
少なくとも、狭い土地建っている木造3階の一戸建てなんかは、床面積に占める階段の比率が多くなってしまい、非効率この上ないのではないでしょうか。
加えて、平面的に広がる住宅街は、通勤時間を長いものにしてしまいます(家は駅から遠くなり、また、電車による移動時間も長くなります)。これらは、余暇の時間・家族の時間の減少に繋がっていきます。
東京は高層化さえできれば、広く、駅から近く、また職場にも近いゆとりのある住環境を提供できるポテンシャルを持っているはずです。
高層マンションに反対している人は、狭い家とか、駅から長い時間歩くとか、また長い時間電車に乗ってるのが好きか、ただゴネ得を狙ってるとしか思えません。
高層ビルは景観を壊すとか言ってる人は、公園も庭もない家が延々と続く景観が好きという奇特な方なのでしょう。
シンガポールなんかは、東京より多い人口密度(6283人/km2)でありながら、緑が多くて「ガーデンシティ」なんて言われています。
10/18 改訂
なお、取得した画像の著作権はグーグル他各社が保持しています。
ご利用は計画的に私的範囲でどうぞご利用ください。
#!/usr/bin/perl use strict; use warnings; use Getopt::Long; use LWP::UserAgent; use GD; my $cmdline = join(" ", $0, @ARGV); my $usage = "usage: $0 -sx=116423 -sy=51603 -ex=116426 -ey=51605 -dx=4 -dy=3 -z=17 -size=300 -get=30 -dir=cache -output=output.jpg -nodebug"; my ($sx, $sy) = (0, 0); my ($ex, $ey) = (0, 0); my ($dx, $dy) = (4, 3); my $z = 17; my $size = 300; my $get = 30; my $dir = "cache"; my $output = "output.jpg"; my $debug = 0; GetOptions("sx=i" => \$sx, "sy=i" => \$sy, "ex=i" => \$ex, "ey=i" => \$ey, "dx=i" => \$dx, "dy=i" => \$dy, "z=i" => \$z, "size=i" => \$size, "get=i" => $get, "dir=s" => \$dir, "output=s" => \$output, "debug!" => \$debug) or die "$usage\nDied"; if ($ex == 0) { $ex = $sx + $dx; } else { $ex++; $dx = $ex - $sx; } if ($ey == 0) { $ey = $sy + $dy; } else { $ey++; $dy = $ey - $sy; } $sx>0 and $dx>0 and $sy>0 and $dy>0 and $z>0 and $dir and $output or die "$usage\nBad arguments"; $dx*$dy > $size and die "Getting too large."; $debug and print "debug: mkdir $dir\n"; mkdir $dir; -d $dir or die "can't make dir $dir: $!"; my $base = sprintf("http://khm%d.google.co.jp/kh/v=46&z=%d", int(rand(4)), $z); my $ua = LWP::UserAgent->new; printf "now get %d images...\n", $dx*$dy; for (my $x=$sx; $x < $ex; $x++) { for (my $y=$sy; $y < $ey; $y++) { my $file = sprintf("%s/%02dz%06dx%06d.jpg", $dir, $z, $x, $y); $debug and print "debug: check of $file\n"; -s $file and next; --$get < 0 and last; my $req = HTTP::Request->new(GET=>+"$base&x=$x&y=$y"); $debug and print "debug: fetch from ".$req->uri."\n"; my $res = $ua->request($req); unless ($res->is_success) { print "fail fetch from $file: ", $res->status_line, "\n"; next; } if (open(my $fh, ">", $file)) { $debug and print "debug: write of $file\n"; binmode $fh; print $fh $res->content; close $fh; } else { print "fail open in $file: $!\n"; } } } $get < 0 and print "reach the getting limit, skip after all.\n"; printf "creating %dX%d image...\n", 256*$dx, 256*$dy; my $image = new GD::Image(256*$dx, 256*$dy); for (my $x=$sx; $x < $ex; $x++) { for (my $y=$sy; $y < $ey; $y++) { my $file = sprintf("%s/%02dz%06dx%06d.jpg", $dir, $z, $x, $y); $debug and print "debug: check of $file\n"; -s $file or next; $debug and print "debug: read of $file\n"; my $part = GD::Image->newFromJpeg($file); $debug and print "debug: image copy\n"; $image->copy($part, 256*($x-$sx), 256*($y-$sy), 0, 0, 256, 256); } } #$image->string(gdSmallFont, 0, 0, $cmdline, $image->colorAllocate(255, 255, 255)); open(my $fh, ">", $output) or die "fail open $output: $!"; $debug and print "debug: write of $output\n"; binmode $fh; print $fh $image->jpeg(); close $fh;
例えば秋葉原とか
perl gmwall.pl -sx=116423 -sy=51603 -ex=116427 -ey=51606
駅だけとか
perl gmwall.pl -sx=465701 -sy=206420 -ex=465705 -ey=206423 -z=19
使う数値はfirebugなどで拾ってください。
元増田です。すみません、適度に改行入れたつもりが全部詰まっちゃって読みにくくなったようです。あと引用の時の半角「>」も文字化けするようなんで以下全角で。
>あんたを安心さす為に、先にネタばらしはしとくわ。被害者総数もな、600万人説以外にも色々あんねん。
もちろん、知ってます。まとめたものがリンク先にあります
http://revisionist.jp/faurison_02.htm
このようなブレがありまくり、正確な数字がわからないというのがおかしいと思うのです。
たとえば、原爆や空襲による死者数に多少ブレがあるのはわかります。即死で亡くなった人、その傷がもとで随分後に亡くなった人、二次災害で亡くなった人等々。どれをカウントに加えるか色々あるでしょうし、爆心地近くにいた人ならば、遺体が跡形も無く消え去ることも有り得るでしょう。しかし、どんなに想定が難しいといっても数万の誤差におさまるのではないでしょうか。数十万、数百万単位で増減したりはありえない。
議論した方が質問に答えてくれなかったのは、諸説あり過ぎ、具体的な数字を出したら突っ込まれる要素があり不利なのであえて答えなかったというのが私の推測ですが。
焦点をしぼるため、アウシュビッツの話にします。定説ではここで150万人が死んだと言われていますが、それも少し前までは400万とされていました。碑文が書き換えられたのはご存知ですよね。
250万人減。日本の第二次世界大戦での戦死者数とほぼ同じ。この250万人はどこへ消え去ったのでしょうか…
>労働もできひんようなヤツは収容せんかったんやな。その手前で始末して。
いわゆる、ガスで殺された人達は収容者名簿に登録もされず、収容所に着いてすぐガス室送りにされたという説ですね。
名簿が無いから名前がわからない=誰かわからない=誰が殺されたかわからない
でっちあげるのには非常に都合のいいやり方だと邪推してしまいますね。誰が何人死んだか、このようなやり方では誰もわかりませんもの。
>すぐに殺されたらしいけどな。ちなみに子供生まれたて話とすぐ殺されたて話は、同じ女性の証言から出たお話や。否定論では生まれたて話だけしか取り上げへんけどな。w
出産があったという事実は証言だけでなく、出生の記録が公式に残っています。ちなみに死亡記録もオフィシャルなものが残っています。それは病死等の自然死で(アンネの死因がチフスとわかるのも、死亡者の記録があったからですね)、人体実験やガス処刑の記録は何も残っていません。
人体実験もそうですが、証言以外にそれが行われたと証明するものが何もない時点で片手落ちでしょう。
メンゲレ医師は悪魔のような人体実験を行ったとされていますが、実際には逆で、収容者達を治療したという記録があります。
研究結果は全て燃やされた、あるいは連合国側に持ち去られたという理屈はやめてください。「ひとつも」無いのは明らかにおかしいです。
>知ってんねん、もう。w後な、教えといたる。皮膚吸収で死んでまう、ちゅう話もあるんや。後な、蒸発温度にナランちゅう話とかな、
皮膚呼吸で死んでしまう猛毒ならなおさら執行者にとって危険でしょう。さらに、ガスマスクもつけずに死体搬出作業とか。よく、この場合のチクロンBの濃度では発火爆発しないと主張されてますが、濃度の問題でなく、爆発の危険性が少しでもあるものなのに対応がいい加減すぎると言いたいです。
>焼却炉の話もあんねん。燃やされへん、とか骨はどないしたんやーとか。
まさに自分が違和感を感じる部分はここです。何を読んでも納得出来ません。24時間焼却出来る炉があったとか。でも航空写真に煙も何も映ってないとか。
死体を燃やす燃料はどこから調達したのか。(廃油とか言わないで下さいね)燃やされた灰はすべて肥料にしてしまったとか
でも周辺を掘っても骨も灰も見つからない、と。
>俺が話ししてても、にいちゃんの話、歪んでんもん。なんや、よう解らん所にムリクリ否定論括りつけたようになってんで?
私も少し前までは、ホロコーストが無かったと言ってる人はネオナチかトンデモな人しかいないイメージだったので、受け入れるのは少し抵抗がありました。
(まあ、あなたの中でも私は歪んだトンデモな人なのかも知れませんが)今はほぼ、「なかった」という考えに落ち着いています。
ブラウザの検索バーが膨らまないよう、厳選して一つとするなら的参考用。
呼び出しクエリの作りやすさ、過去航空写真やルート検索、時刻表連動やスポットデータ等は、
瑣末として省略。
シングルC時 住所検索結果 色分け その他
mapion × 全文・数字× ○ 縮尺に注釈、バルーンに中心からの距離、絞りワースト
mapfan ○ 前方・数字○ × 賢い検索絞込みの基準
Yahoo! ○ 全文・数字○ ○ 色分け単位が条でなく丁目なのはYahooさんだけ
excite ○ 前方・数字× ○ シングルC対応mapion。やや絞れる代わりに重い
goo × 全文・数字○ × 住宅街でも営業所・建物名記載が異常に細かい
google × 前方・数字○ × 丁目が任意だがmapfan並に賢い絞り、禁スクリプト地図クソ
ちず丸 × 前方・数字○ × 検索は賢いが地図が最も使いづらい
項目の意味は左から、
*シングルクリック時にダブルクリックで全サイト共通で起こるセンタリングが起動するか
*例えば○○を字として「○○2条」を検索して…
西○○や新○○まで出る=全文(検索型)、出ない=前方(一致型)
データ通りに漢数字のみ解釈・算用数字を無視して1条~99条まであるだけ出すのが数字×
解釈して1条と3条~を出さないのが数字○
ようやく携帯に対応!これは大変便利!
プライバシーがどうの言われているけど、これまで見た限りでは逆に犯罪対策に利用するという発想はないんかな?
PCからはログインユーザーだけが見れたり、IPをとるようにするとか、携帯からは固有番号とるようにするとかすれば、窃盗犯が自宅を事前に表示していたら、警察もIPである程度のめぼしや状況証拠がつかめるのでは?
あと、2mの高さって批判されてるのはパノラマ処理する際にちょっとつぶすとか?でも航空写真で普通に見えるよね?
法律だのマナーだののめんどうな批判じゃなくて、そういう技術的な解決策の要望であればGoogleさんも喜んでやってくれそうでは?