  |
はてなキーワード: 航空写真とは
デモや集会の人数で色々と齟齬が出るのはいつものことであるけども…。
例えばミュージシャンのライブであるとかマラソンの参加人数を数えるのは簡単だ。
参加者は”一斉”に”一定の定められた区画内”に集まるのだからそれを数えればいい。
というより数えるまでもなく、チケットやエントリーの数を集計すればいいだけの話だ。
動きは流動的で何処から何処までが参加者なのかもはっきりしないだろうし、
いつ来ていつ帰っていくのかもやはりはっきりしないだろう。
そういうわけで、ああいうデモの人数集計なんて端から無理であるように思える。
というわけで、警察発表の”1万7千人”は一体どうやって数えたんだろうか。
まさか、何処かに人員を配置して野鳥の会的な数え方をしたんだろうか。
1万7千、と千の位まで指定しているのだから、それなりにちゃんとした
数え方をした結果のように思えるが…。（とはいえ1000人単位も十分に大雑把ではあるが）
（ソース:世界の中の東京（東京都環境局） 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などで拾ってください。
ブラウザの検索バーが膨らまないよう、厳選して一つとするなら的参考用。
呼び出しクエリの作りやすさ、過去航空写真やルート検索、時刻表連動やスポットデータ等は、
瑣末として省略。
シングルC時 住所検索結果 色分け その他
mapion × 全文・数字× ○ 縮尺に注釈、バルーンに中心からの距離、絞りワースト
mapfan ○ 前方・数字○ × 賢い検索絞込みの基準
Yahoo! ○ 全文・数字○ ○ 色分け単位が条でなく丁目なのはYahooさんだけ
excite ○ 前方・数字× ○ シングルC対応mapion。やや絞れる代わりに重い
goo × 全文・数字○ × 住宅街でも営業所・建物名記載が異常に細かい
google × 前方・数字○ × 丁目が任意だがmapfan並に賢い絞り、禁スクリプト地図クソ
ちず丸 × 前方・数字○ × 検索は賢いが地図が最も使いづらい
項目の意味は左から、
＊シングルクリック時にダブルクリックで全サイト共通で起こるセンタリングが起動するか
＊例えば○○を字として｢○○2条｣を検索して…
西○○や新○○まで出る＝全文(検索型)、出ない＝前方(一致型)
データ通りに漢数字のみ解釈・算用数字を無視して1条～99条まであるだけ出すのが数字×
解釈して1条と3条～を出さないのが数字○
ようやく携帯に対応！これは大変便利！
プライバシーがどうの言われているけど、これまで見た限りでは逆に犯罪対策に利用するという発想はないんかな？
PCからはログインユーザーだけが見れたり、IPをとるようにするとか、携帯からは固有番号とるようにするとかすれば、窃盗犯が自宅を事前に表示していたら、警察もIPである程度のめぼしや状況証拠がつかめるのでは？
あと、2mの高さって批判されてるのはパノラマ処理する際にちょっとつぶすとか？でも航空写真で普通に見えるよね？
法律だのマナーだののめんどうな批判じゃなくて、そういう技術的な解決策の要望であればGoogleさんも喜んでやってくれそうでは？
