カスタムストリートビューの作成方法 - Google Maps Api Custom Street View
＜2020追記＞
この記事は古いので、あまり参考にしないでください。
APIキーあたりの仕様が変わっています。
ある程度のWebサイトの知識があれば作れるレベルで解説します。
また、このページのHTMLやJavascriptをコピペし、解説通り画像を用意すると作れるようになってます。
カスタムストリートビューはGoogle Maps Api内のストリートビューの表示機能を自由にカスタマイズして利用でき、自分で撮影したパノラマ画像の表示や、複数のパノラマ画像を使えば自作ストリートビューも作成する事が出来ます。例として私が作成したものがこいつです。
UK School View.beta
最低限の機能を載せたプログラムを例として、HTML→Javascript→画像→フォルダ構成 の順で必要な部分だけ解説していきます。また、最後に今回の例を丸ごとZIPとして載せますので参考にしてください。
HTML
まずHTML。
Google Maps Apiを実現させるためにGoogleが提供した外部ファイルや、カスタムストリートビューに関する外部ファイルの読み込み設定のほか、ストリートビューの表示範囲となるDIVコンテナを設定します。
<html>
<head>
<script src="https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false" type="text/javascript"></script>
<script src="js_gsv.js" type="text/javascript"></script>
<title>タイトル</title>
<style type="text/css">
<!--
body {
height: 100%;
}
#streetview_canvas {
margin: 0 auto;
width: 900px;
height: 500px;
}
-->
</style>
</head>
<body>
<div id="streetview_canvas"></div>
</body>
</html>
<script src="https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false" type="text/javascript"></script>
<script src="js_gsv.js" type="text/javascript"></script>
一行目はGoogle Maps Apiを機能させるのに必要な一文です。googleが用意した外部のJavascriptファイルを読み込みます。
二行目は、後述するカスタムストリートビューに関連するJavascriptファイルです。js_gsv.js というのはそのファイルの名前になります。タイトルにはこのページの題名を書きます。検索結果に表示されるタイトルですね。
width: 900px;
height: 500px;
ストリートビューを表示させる領域の大きさを指定します。
<div id="streetview_canvas"></div>
ストリートビューを表示させる領域のDIVコンテナです。
streetview_canvasというのは後述するJavascript内で指定するものです。
Javascript
つぎにjavascript。上のHTMLをコピペして使用する場合、こちらを「js_gsv.js」で保存してください。
このプログラムの概要として、初期表示のパノラマ画像と視点およびコントロールバーなどの表示の設定と、視野に従って、いくつかのブロックに分割されたパノラマ画像を逐次読み込むシステムの設定になります。またこのとき、複数のパノラマ画像でストリートビューを構築する場合は、周辺へのリンクを表示する設定や、パノラマ画像などの情報に関するデータベースも設定します。
var streetView;
function initialize() {
//ストリートビューの全体的な設定
var streetViewOptions = {
pov: { heading: 0,pitch: 0,zoom: 1 }, //初期表示の方角：仰角：視野（ズーム）
pano : "pano_01", //初期表示するのパノラマ画像のパノラマID
panControl : false,
panoProvider : getCustomPanorama
};
//ストリートビューを表示するHTML内のDIVコンテナを設定
var streetViewDiv = document.getElementById("streetview_canvas");
streetView = new google.maps.StreetViewPanorama(streetViewDiv, streetViewOptions); //ここ根幹
//リンクの登録
google.maps.event.addListener(streetView, "links_changed", createCustomLink);
}
function getCustomPanoramaTileUrl(panoID, zoom, tileX, tileY) { //タイル画像読み込み
return 'pano_images/' + panoID + '/' + panoID + '_' + tileX + '_' + tileY + '.jpg';
}
function getCustomPanorama(panoID) {
//基本パノラマデータ定義
var streetViewPanoramaData = {
links: ,
copyright: "(C) 2013 Created by hogehoge", //著作者表示
tiles: {
tileSize: new google.maps.Size(512, 512), //各タイルサイズ
worldSize: new google.maps.Size(4096, 2048), //全面サイズ(ﾀｲﾙｻｲｽﾞとｲｺｰﾙで一枚表示
centerHeading: 0, //初期方角
getTileUrl: getCustomPanoramaTileUrl
}
}
//各パノラマデータ登録
switch(panoID) {
case "pano_01":
streetViewPanoramaData["location"] = {
pano: "pano_01", //パノラマID
description: "西パノラマ", //パノラマ表示名
latLng: new google.maps.LatLng(36.552575, 139.870435) //パノラマの座標
};
break;
case "pano_02":
streetViewPanoramaData["location"] = {
pano: "pano_02",
description: "中央パノラマ",
latLng: new google.maps.LatLng(36.552325, 139.870465)
};
break;
case "pano_03":
streetViewPanoramaData["location"] = {
pano: "pano_03",
description: "北パノラマ",
latLng: new google.maps.LatLng(36.551927, 139.870502)
};
break;
}
return streetViewPanoramaData;
}
function createCustomLink() {
var links = streetView.getLinks(); //現在のリンクの取得
var panoID = streetView.getPano(); //現在のパノラマID取得
switch(panoID) {
case "pano_01": //pano_01のときに表示するリンク
links.push({ //links.push()は複数設置可
description : "中央", //リンク表示名
pano : "pano_02", //リンク先パノラマID
heading : 90, //リンク方角
});
break;
case "pano_02":
links.push({
description : "西",
pano : "pano_01",
heading : 270,
});
links.push({
description : "北",
pano : "pano_03",
heading : 0,
});
break;
case "pano_03":
links.push({
description : "中央",
pano : "pano_02",
heading : 180,
});
break;
}
}
google.maps.event.addDomListener(window, 'load', initialize); //initializeを一度のみ実行
var streetViewOptions = {
pov: { heading: 0,pitch: 0,zoom: 1 }, //初期の方角：仰角：視野
pano : "pano_01", //初期のパノラマID
panControl : true, //パノラマ操作のコントローラ表示するか
panoProvider : getCustomPanorama
};
pov:で初期表示の視野と方向を設定します。heading:は北を0として時計回りに359まで方角を設定できます。pitch:は水平を0として、真上へ90、真下へ-90の範囲で設定できます。zoom:はそのまま拡大ですが、使い難いので1が基本で良いかと。
pano : "pano_01"はページを開いて最初に表示するパノラマ画像を設定します。pano_01は表示するパノラマ画像の名前で、一般にpanoIDと呼びます。このプログラムでは、panoIDがそのままパノラマ画像のファイル名(panoID.jpg)となります。
panControl :はパノラマ操作に使うコントロールの表示の有無を決めます。trueで表示、falseで非表示。
panoProvider : getCustomPanoramaはパノラマ画像の画像データや情報を呼び出すものです。
var streetViewDiv = document.getElementById("streetview_canvas");
HTMLのDIVコンテナを指定します。ここではstreetview_canvasというidをもつDIVコンテナを指定してます。
google.maps.event.addListener(streetView, "links_changed", createCustomLink);
複数のパノラマ画像で自作ストリートビューとする場合に必要な一文です。streetView内で"links_changed"というイベントが発生したらcreateCustomLinkという関数を実行する、というような意味になります。links_changedはリンクの変更、つまりパノラマ画像を切り替えた時に相当し、createCustomLink関数は、切り替えた先のパノラマ画像のpanoIDをもとに、その周辺のパノラマ画像へのリンクを探して表示するものです。
'pano_images/' + panoID + '/' + panoID + '_' + tileX + '_' + tileY + '.jpg';
ここで読み込む画像のアドレスを設定します。「panoID」は表示しようとするパノラマ画像名、「tileX」が左から何番目か、「tileY」が上から何番目かを意味します。この三つのパラメータは、ユーザの操作に応じて自動的に指定されます。なお、panoIDがパノラマ画像のファイル名というのはここでそのように設定されているからです。例えば「pano_01」というpanoIDを持つパノラマを表示させるとき、上のプログラムは下記のようにパノラマ画像のアドレスを指定します。
pano_images/pano_01/pano_01_0_0.jpg
このように、pano_imagesというフォルダ内のpano_01というフォルダ内にある「pano_01_0_0.jpg」というブロック画像が指定されることになります。
var streetViewPanoramaData = {
links: ,
copyright: "(C) 2013 Created by hogehoge", //著作者表示
tiles: {
tileSize: new google.maps.Size(512, 512), //各タイルサイズ
worldSize: new google.maps.Size(4096, 2048), //全面サイズ(ﾀｲﾙｻｲｽﾞとｲｺｰﾙで一枚表示
centerHeading: 0, //初期方角
getTileUrl: getCustomPanoramaTileUrl
}
}
copyright:はパノラマ画像の表示の際に、右下で著作者として表示されるものです。HTMLのタグも使えるので、うまく利用すればいろいろ使えます。
tileSizeとworldSizeは画像の大きさを設定します。
例えばworldSizeが(4096, 2048)で、tileSizeが(512, 512)であれば、横方向に８つ、縦方向に４つのブロックとして表示されます。左上から順に表示するので、割り切れない数値に設定すると、当然ですが南方向もしくは真下の画像の辻褄が合わなくなります。
centerHeading: とは、パノラマ画像の位置をズラします。補正機能のようなもので、用意したパノラマ画像の中央が北を向いている場合、これは0にして構いません。もしパノラマ画像の中央が東を向く場合、これを90にすればパノラマ画像が右方向に90度移動して表示されます。これは視点を設定するheading:の方角パラメータとは異なり、パノラマ画像を移動させるだけということに注意してください。
getTileUrl: getCustomPanoramaTileUrlは、分割されたブロック画像を呼び出すものです。
switch(panoID) {
case "pano_01":
streetViewPanoramaData["location"] = {
pano: "pano_01", //パノラマID
description: "西パノラマ", //パノラマ表示名
latLng: new google.maps.LatLng(36.552575, 139.870435) //パノラマの座標
};
break;
- - - - - - - -
パノラマ画像のpanoIDが初期設定やリンクを押して選択されたとき、このswitch case文が実行され、選択されたpanoIDに関する設定を読み込みます。pano:はこのパノラマ画像のpanoID、description:はこのパノラマ画像の名称、例えば駅前のパノラマ画像の名称を「駅前」とすれば、そのパノラマ画像が表示された際、左上に「駅前周辺」と表示されます。latLng:はパノラマが撮影された座標です。
用意したパノラマ画像の数だけ、このcase文を用意してそれぞれ設定してあげます。
switch(panoID) {
case "pano_01": //pano_01のときに表示するリンク
links.push({ //links.push()は複数設置可
description : " ", //リンク表示名
pano : "pano_02", //リンク先パノラマID
heading : 90, //リンク方角
});
break;
パノラマ画像のpanoIDがリンクを押して選択されたとき、このswitch case文が実行され、選択されたpanoIDに表示されるリンクの設定を読み込みます。links.push()がひとつのリンクに対応しており、複数のリンク（例えば交差点のパノラマのときなど）が必要な際はこのlonks.push()を複数用意してもよいです。description:はリンクに表示する名称です。リンクを押した先のパノラマ画像の名称を書いたりします。pano :はリンクを押した先のパノラマ画像のpanoIDを設定します。間違えると異なるパノラマ画像に飛んでしまうので注意です。heading:は視点と同じく北を0として時計回りに359度の方角を設定でき、リンクの矢印方向を設定します。
用意したパノラマ画像でリンクを用いる画像の数だけ、このcase文を用意し、case内ではそのパノラマ画像で表示するリンクの数だけlinks.push()をそれぞれ設定します。
google.maps.event.addDomListener(window, 'load', initialize);
これを必ずプログラムの最後に置きます。
すべて読み込んだらプログラム（initialize関数）を実行するという意味です。
パノラマ画像
次にパノラマ画像について。
パノラマ画像を用意します。パノラマ画像の作り方は以下を参照してください。
縦横無尽にパノラマ写真を作成 hugin - ITpro
単純な画像の合成であればMicrosoft ICEが操作が簡単なのでオススメですが、Microsoft ICEは複雑な画像の合成に関しては手動による補正も行えないので苦手です。なのでhuginというソフトがオススメです。
パノラマ画像は横4096px、縦2048pxにする事を薦めます。後述する分割ソフトでリサイズも可能です。
このパノラマ画像を分割しないでも、js.gsv.jsのtileSizeの設定によっては表示することが出来ますが、ネット上のサーバで公開した際にはデータ受信速度がローカルより圧倒的に遅いため、一枚表示するのに20秒くらい掛かることがあります。そこで、いくつかに分割することで圧倒的な高速表示ができるため、ネット上で公開する予定であれば分割する事をオススメします。
しかし分割するにしても一枚だけならまだペイントソフトで加工すれば良いですが、ストリートビューのように複数、または多量のパノラマ画像の処理の場合は手作業では絶望的なほど時間が掛かってしまいます。そこでprocessingを用いた自動分割ソフトを作成しました。下のURLからダウンロードし、ZIPを解凍してください。説明はreadme.txtを読んでもらうとしてここでは省く事にします。
GSVcutter - Skydrive
このソフトではパノラマ画像ごとに自動的にフォルダが作成され、ここに分割したブロック画像が規則どおりの名前で収納されます。このフォルダを後述するフォルダ構成でそのまま用います。
例：
パノラマ画像「pano.jpg」
↓分割ソフト GSVcutter
「pano」フォルダ生成、フォルダ内に「pano_0_0.jpg」～「pano_7_3.jpg」生成
フォルダ構成
最後にフォルダ構成について。
これまでパノラマ画像のブロックや、HTML、Javascriptを解説しましたが、これらは場所を間違えると正しく機能しません。ので、ここでしっかり見ておきましょう。
例えばCustomStreetViewというフォルダに、HTMLとJavascript、パノラマ画像を全てまとめた場合とします。
このとき、パノラマ画像３つ（pano_01.jpg、pano_02.jpg、pano_03.jpg）を用意し、それぞれ分割したとします。
-CustomStreetView(フォルダ)
|--pano_images(フォルダ)
| |--pano_01(フォルダ)
| | |--pano_01_0_0.jpg(ブロック画像)
| | |--pano_01_0_1.jpg
| | |--pano_01_0_2.jpg
| | |--pano_01_0_3.jpg
| | |--pano_01_1_1.jpg
| | |--pano_01_1_2.jpg
| | |-- /略/ .jpg
| |
| |--pano_02(フォルダ)
| | |--pano_02_0_0.jpg
| | |--pano_02_0_1.jpg
| | |-- /略/ .jpg
| |
| |--pano_03(フォルダ)
| |--pano_03_0_0.jpg
| |--pano_03_0_1.jpg
| |-- /略/ .jpg
|
|--index.html
|--js_gsv.js
例のZIP
これで、単純なストリートビューを作ることが出来る筈です。
とはいえ、やっぱり間違えてしまう人は少なからず居ますので、今回用いた例を、丸ごとZIPにして配ります。
CustomStreetView - Skydrive
このZIPファイル内のプログラムはフリーとしますが、画像の著作権および著作者人格権は全てkazu.に帰属します。あくまで例から学ぶタイプの方へ向けて学習用に渡すだけであって、公開する場合は画像を流用する事の無い様、己の良心とモラルに従って常識の範囲内で使ってください。
- kazu.
機械製図で用いる部品欄の工程略称記号の一覧
ウェブでもあまり無かったので一覧をあげておきますね。
注意１ ： JISなどで特に決まっている訳ではなく、慣例のようです。詳細は後記。
注意２ ： 訪れてくれた学生の諸兄、これはあくまで私見であって、レポートの参考文献には相応しくないぞ。
「木」 … 木型工場
鋳造時の原型の一種、木型の製造工程ですね。
「イ」 … 鋳物工場
木型などで鋳物を作る工程ですね。
「キ」 … 機械仕上工場 / 機械工場 / 機械加工
機械を用いた仕上げ工程でしょうか。
「仕」 … 仕上組立工場 / 仕上げ
手作業などで仕上て組み立てる工程でしょうか。
「タ」 … 鍛造工場
鍛造による塑性加工の工程ですね。
「カ」 … 製缶工場
タンクなどを作る板金加工のひとつらしいです。
「シ」 … 試験場
品質検査の試験でしょうか。
「テ」 … 鉄板加工
そのまま鉄板の加工のようです。アバウトですね。
「プ」 … プレス加工
プレス機械による塑性加工ですね。鉄板加工の一つでもあるようです。
「ヨ」 … 溶接加工
溶接を用いた工程ですね。これも鉄板加工の一つなのでは。
「ヌ」 … 塗装
塗装する工程ですね。
「ネ」 … 熱処理
金属を熱処理する工程ですね。「熱」とも書かれる場合があるようです。
「ソ」 … 倉庫
倉庫から出す＝在庫品や市販品を用いるという意味ですね。定番ネタ。
～後記～
これらの加工略称の表記がJISに記載されているのか一通り調べましたが、製図ハンドブックには無いようでした。なのでこれら略称はこの界隈の慣例によるものかと思います（違ってたら教えてください）。製図関係の教本を幾つか調べてもそれぞれ載っている略称が異なり、非常に煩雑な印象を受けました。例えば 「機会仕上工場」 と 「機械仕上加工」 と 「機械仕上」と「機械工場」。熱処理の「ネ」と「熱」など。今回の記事は、こういった曖昧さを正す目的があります。
なお、表面性状に用いる加工方法の記号は 「JIS B 0122」 の 『加工方法の記号』 に一覧がありますが、部品欄で用いるものとは性質がずいぶん異なるようです。
Google Earthへの3Dモデル投稿ができなくなりまして、今後どうするかという駄文
終わってしまいましたねー。
とても残念です・・・。
と、いうのは今までの記事で何回も言っている事（関連記事参照）なので、今回の本題は今後についてです。
※空いた時間につらつら書いたものなのでかなり駄文です。てか気温差のせいでダルメシアン。
Googleは大都市を中心に3D画像という最新の技術で3D化していくと思われます。もちろん東京や大阪もそう遠くない時期に行われてしまうでしょう。
しかし問題は地方都市です。私のホームタウンである宇都宮が3D画像化されるかといえば、ちょっと怪しい。もちろん3D画像の整備はそこまで難しくは無いのだろうけど、その性質上、航空写真と同じように月日が経つにつれて何度か更新する必要があるはず。となれば、無闇やたらに3D化していけばコストもバカにならない。しかして、3D画像を整備するのは大都市もしくはGoogleの本拠地であるアメリカ本土の都市に限られると考えるのが妥当でしょう。
まぁ、これが今回の3Dギャラリーとのパイプライン廃止に反対していた理由なんですけどね。
ちなみに以下のサイトで現在の3D化地域の一覧を見れます。
https://support.google.com/earth/answer/2661942?hl=ja&ref_topic=2376200
もしパイプライン廃止が金銭的なものであるなら、別の3Dモデラーによる団体で運営していける可能性は無きにしも非ずですが、Googleとしてはそれは望んでいない筈。それに団体の運営自体そう簡単ではないだろう。データセンターの維持管理費も掛かるし、なにより世界中から集まる大量のモデルを一つ一つ承認していくプロセスは負担が大きすぎる。適当な品質のモデルを大量にアップロードするようなユーザがいれば尚の事だ。
つまり、今後、公式のGoogle Earthへ表示させる仕組みを構築するのは不可能に近いと考えていいでしょう。
可能性として考えてるのが、前の記事に少し述べた、自分の世界を構築する事です。
Googleは Google Maps Api というサービスを提供しています。そこではGoogle Earthと同じ3D空間があり、プログラムを変更することで様々なコンテンツが作れます。例えば、Apiを組み込んだ宇都宮の専用ページで、宇都宮の3DデータをGoogle Earthに表示させることが可能なのです。
もちろん、そんなページでは公式のGoogle Earthに比べて閲覧され難いとは思いますが、それはまた別の話です。後々考えればいいことでしょう。
今、私が提案したのは「自分が作る街ごとに独自の世界を作る」ということです。
ではGoogle Earthのように複数のユーザを統合できないかというと…出来そうです。
というのは、モデラーが送って運営が処理する構造では、絶対に選別を行う運営役が必要です。ならば、モデラー自身がデータの更新などが出来れば良い訳です。
少し専門的な話になりますが、Google Maps Api はJavascriptというプログラム言語で記述する事ができます。そのApiのプログラムの中に、3Dモデルのデータの位置（URL）とその座標や名称を記述することで、Api内の3D空間に表示することが出来ます。ここで、3D空間を構築するプログラムと3Dモデルの情報があるデータベース的プログラムを分け、空間構築プログラムをサイトの管理者（発起人など）が管理し、データベース的プログラムをモデラーが各自管理する。モデラーが新たな3Dモデルを作ったならば、3Dモデルを何所かWeb上にアップロードし、そのデータのURLと詳細を自分専用のデータベース的プログラムに記述してWeb上にアップロード。サイトの管理者は、空間構築プログラムから外部JSファイルとしてユーザのデータベース的プログラムのURLを記述し、読み込んで表示する。これならば、Apiを組み込んだサイトの管理権限を無闇に公開する必要もなく、また各ユーザ自身が更新することで、運営の負担が大幅に減ります。
この場合の心配事としては、ユーザが記述を誤って、サイト全体がエラーを起こす可能性があることや、同じ建物が競合してしまうことです。まぁそれはまた別の話でしょう。
これが私の今後の提案です。
一応、こうしたプログラムの作成には今後チャレンジしてみたいとは思っています。
あくまで参考までに。
関連記事
近頃の Google Earth と Sketchup 3Dギャラリー の今後に関するお話 (他 ビルディングメーカー)
ついに3DギャラリーがGoogle Earthから切り離される…についての駄文
とても残念です・・・。
と、いうのは今までの記事で何回も言っている事（関連記事参照）なので、今回の本題は今後についてです。
※空いた時間につらつら書いたものなのでかなり駄文です。てか気温差のせいでダルメシアン。
Googleは大都市を中心に3D画像という最新の技術で3D化していくと思われます。もちろん東京や大阪もそう遠くない時期に行われてしまうでしょう。
しかし問題は地方都市です。私のホームタウンである宇都宮が3D画像化されるかといえば、ちょっと怪しい。もちろん3D画像の整備はそこまで難しくは無いのだろうけど、その性質上、航空写真と同じように月日が経つにつれて何度か更新する必要があるはず。となれば、無闇やたらに3D化していけばコストもバカにならない。しかして、3D画像を整備するのは大都市もしくはGoogleの本拠地であるアメリカ本土の都市に限られると考えるのが妥当でしょう。
まぁ、これが今回の3Dギャラリーとのパイプライン廃止に反対していた理由なんですけどね。
ちなみに以下のサイトで現在の3D化地域の一覧を見れます。
https://support.google.com/earth/answer/2661942?hl=ja&ref_topic=2376200
もしパイプライン廃止が金銭的なものであるなら、別の3Dモデラーによる団体で運営していける可能性は無きにしも非ずですが、Googleとしてはそれは望んでいない筈。それに団体の運営自体そう簡単ではないだろう。データセンターの維持管理費も掛かるし、なにより世界中から集まる大量のモデルを一つ一つ承認していくプロセスは負担が大きすぎる。適当な品質のモデルを大量にアップロードするようなユーザがいれば尚の事だ。
つまり、今後、公式のGoogle Earthへ表示させる仕組みを構築するのは不可能に近いと考えていいでしょう。
可能性として考えてるのが、前の記事に少し述べた、自分の世界を構築する事です。
Googleは Google Maps Api というサービスを提供しています。そこではGoogle Earthと同じ3D空間があり、プログラムを変更することで様々なコンテンツが作れます。例えば、Apiを組み込んだ宇都宮の専用ページで、宇都宮の3DデータをGoogle Earthに表示させることが可能なのです。
もちろん、そんなページでは公式のGoogle Earthに比べて閲覧され難いとは思いますが、それはまた別の話です。後々考えればいいことでしょう。
今、私が提案したのは「自分が作る街ごとに独自の世界を作る」ということです。
ではGoogle Earthのように複数のユーザを統合できないかというと…出来そうです。
というのは、モデラーが送って運営が処理する構造では、絶対に選別を行う運営役が必要です。ならば、モデラー自身がデータの更新などが出来れば良い訳です。
少し専門的な話になりますが、Google Maps Api はJavascriptというプログラム言語で記述する事ができます。そのApiのプログラムの中に、3Dモデルのデータの位置（URL）とその座標や名称を記述することで、Api内の3D空間に表示することが出来ます。ここで、3D空間を構築するプログラムと3Dモデルの情報があるデータベース的プログラムを分け、空間構築プログラムをサイトの管理者（発起人など）が管理し、データベース的プログラムをモデラーが各自管理する。モデラーが新たな3Dモデルを作ったならば、3Dモデルを何所かWeb上にアップロードし、そのデータのURLと詳細を自分専用のデータベース的プログラムに記述してWeb上にアップロード。サイトの管理者は、空間構築プログラムから外部JSファイルとしてユーザのデータベース的プログラムのURLを記述し、読み込んで表示する。これならば、Apiを組み込んだサイトの管理権限を無闇に公開する必要もなく、また各ユーザ自身が更新することで、運営の負担が大幅に減ります。
この場合の心配事としては、ユーザが記述を誤って、サイト全体がエラーを起こす可能性があることや、同じ建物が競合してしまうことです。まぁそれはまた別の話でしょう。
これが私の今後の提案です。
一応、こうしたプログラムの作成には今後チャレンジしてみたいとは思っています。
あくまで参考までに。
関連記事
近頃の Google Earth と Sketchup 3Dギャラリー の今後に関するお話 (他 ビルディングメーカー)
ついに3DギャラリーがGoogle Earthから切り離される…についての駄文
ついに3DギャラリーがGoogle Earthから切り離される…についての駄文
Google Earth の 3D モデリング パイプラインは 2013 年 10 月 1 日で終了となります。
8月初旬にGoogleからこのように通知され、未だ多くのモデラーがショックを隠せない状況ですね。
しかし前兆はありました。このブログでも既に切り離すであろうことは書きましたし。
（参照：http://blogs.yahoo.co.jp/kazu_kazu_souri/38162317.html）
この通知の詳細は以下の通り。
Hi folks,
With the goal to have every building in the world accurately displayed in 3D, we’ve explored different methods for modeling large areas of our planet in 3D, including technologies like SketchUp, Building Maker and lately 3D Imagery. We’ve decided that in order to pursue the most consistent user experience, we'll be focusing our resources on the technology that will scale to the entire world and will be discontinuing support of the user generated 3D program.
We’d like to thank all of you who helped form the landscape of Google Earth and helped cities around the globe grow out of the 2D realm, and into the imaginations of virtual 3D explorers everywhere.
Models can still be uploaded to the Trimble 3D Warehouse, where they can continue to be shared with the modeling community, but they will no longer be published to Google Earth starting October 1st, 2013. Existing models will remain visible in Google Earth, until a time when they're replaced by new models generated for that region. Google Takeout lets you download an archive containing all of your models.
On a personal note: I’ve had the good fortune of being involved in the 3D modeling effort for Google Earth from the beginning, and I've watched many of you create collections of amazingly detailed architectural wonders from every corner of the Earth. I'm very thankful to have been along for that ride and to have gotten to know many of you over the years.
With respect and appreciation,
- CraigD and the 3D Modeling Team
User generated 3D model pipeline to be retired October 1st, 2013
翻訳は各自に任せるとして、クレイグ氏が言いたいことはつまり、新しくなるGoogle Earthの開発に集中するために、余計な部分を廃止して整理しようという話である。
クレイグ氏のその他の回答を見るに、やはり3DギャラリーをGoogle Earthに承認するプロセスやシステムは開発にとって負担が大きく、Googleの刷新にはどうしても邪魔だったことが窺える。それもよくよく考えれば当然のことで、Googleが持つ最新の3D技術（参照 http://www.youtube.com/watch?feature=player_embedded&v=N6Douyfa7l8）では一つの巨大なポリゴンデータで都市をカバーできる。いままでのような建物一つ一つの3Dモデルに座標などのタグ付けて管理するのと比べて非常に容易なはずだ。
外部から航空写真を買って自らは提供するだけだった過去のGoogleとは違い、既に彼らは、自社の飛行機で、自社のプログラムや機材を用いて、正確な航空写真を作り、正確な3Dモデルを作り出すことができる。3Dモデラーは既にお役目御免なのである。
さて、3Dモデラーはこの通知に対していろいろな反応を見せている。ある者は残念がりながらもGoogleを理解しようとするし、ある者は反発して自らのテリトリーの建物をすべて削除してメディアと組んで騒ぎにしようとしている(注釈)。そんな私は一連の流れを残念に思いながらGoogleに失望している一人であります。
クレイグ氏によれば、10月1日までに承認されたモデルは、その建物が3D画像（前述した3Ｄ技術の名称）更新するまでずっと残るのだという。なので、GＥへの承認を目指す人はお早めに。もしくは、Googleに反発したくて建物を削除する人も、お早めに。
※注釈
欧州などの小さな町では、3D化を町全体で盛り上げている所もある。そういう町では3D製作自体が一定の市民権を得た存在となっていたりする。製作者と地域の新聞社が通じている事もしばしば。ここで、今回のGoogleの対応を理由にモデルを削除してGEから一掃すれば、新聞社含め町がGoogleを批判するだろうという算段だ。つまり脅しである。ただし、こういった仮想と現実の繋がりを強固な方面へ扇動したのはGoogle本人である（Your Town Competitionなど）。
さて、楽しみが一つ消えてしまう訳ですが、どうしましょうね。
私の予定としては、Google Maps Api を用いて、宇都宮付近だけを独立させようかとも考えています。
すでにノウハウは分かっているので、作ろうと思えば作れる自信はあります。その方がいろいろと自由も利くので悪くないかと考えます。
あくまで構想段階です。さらにどうするかは、また今度考えましょう。
それでは
Google Earthにて沖ノ鳥島が表示されなかった問題についてのお話
Google Earthで沖ノ鳥島が表示されない時期が、去年の暮れごろから今年の６月までありました。
混乱している人も多いようでしたので、今更ですがここに事実関係をつらつらとまとめておきます。
沖ノ鳥島が表示されなくなったのは、Google Earthバージョン7.0がリリースされたと同時に起きました。
Google Earth 7.0 は今までとは描写や処理方法が大きく変更され、スマートフォンなどの携帯端末でも快適に見られるよう、不必要なデータを省略する処理が行われるようになりました。
その例として、次の図を見てください。右が 7.0 左が 6.0 です。
同じ条件でキャプチャーしたものですが、7.0の方が地形の描写が雑なのが分かるかと思います。
そして海底はさらに省略され、例として次の図を（ｒｙ
左の 6.0 に比べ、右の7.0ではまっ平らになってるのが分かります。ぺったんこですねぇ
つまり、陸上部分と、海底部分では省略レベルが大きく異なる処理（のようなもの）が行われています。
となれば、何かしら 「陸上部分か否か」 というデータ（のようなもの）があると考えられますよね。
もしそのデータに、とある離島が欠落していたとすれば、ただの海底としてまっ平らになってしまうでしょう。
で、
Google Earth 7.0 が公開された当初、日本近海の島嶼の一部のデータが欠損していたらしく、島として認識されていなかった結果、それらの島がGoogle Earthから消えてしまったと考えられるのです。
なお、欠損していた部分は私が確認できただけで 沖ノ鳥島 南硫黄島 南鳥島 の三つです。
自分は今年初旬にGoogle本社、５月中旬に日本のフォーラムにこれらを連絡しました。これに効果があったのか無かったのか、6月ごろのデータベースアップデートで、沖ノ鳥島 南硫黄島 が正確に表示されるようになりました。南鳥島はもう一度本社の方へ連絡してみます。
沖ノ鳥島がGoogle Earthから消えた事で、国際社会に認められなくなったのではないか、などと勘繰ってしまう方が多かったかもしれませんが、さすがに南硫黄島や南鳥島を認めていないなんて事はなく、ただ単にデータベースのミスによるものだと考えられるでしょう。
以上で今回のGoogle Earth沖ノ鳥島消失問題のまとめとさせていただきます。
ちなみに私はGoogle Earth 6 の方が好きです。
Blog Front CG 13 : Terrain Mt.Nyohou - red relief image map
日本国内では、女峰山（2,483m）より東に女峰山より高い地点はないそうです
近頃の Google Earth と Sketchup 3Dギャラリー の今後に関するお話 (他 ビルディングメーカー)
バージョン 7.1 が公開され、また、3D表示することができる都市がより増えました。
Google Earthは日々進歩していますね。
しかし最近の動向について気になる点が出てきました。
結論から言えば、
Googleは 「Google Earth」から「Sketchup & 3Dギャラリー」を大方切り離そう としているようです。
いやまぁ、うすうす勘づいてはいましたが、ついに来たかといった感じですね。
いや、もう既に切り離されているように思いますが。
…ところで、私が3Dモデルを作り始めた頃のGoogle Earthはどんな風だっただろうか
上は今から5年前、2008年4月ごろの東京・六本木付近。
ちなみに上空の雲のようなものは私が加工したもので本来は存在しない。
なお、一番最初にGoogle Earthに触れた時はまだ日本語ではなかった覚えがある。
日本語版のSketchupが出た頃で、Google Earthの3Dモデルなんてものは日本ではまだ珍しかった。3Dギャラリーでは世界各地の様々な有名建築物のモデルが競うように投稿され、3Dモデルは加速度的に増加していった。Google Earthの建物はユーザーが主体となって街づくりをしていた。
そんな流れが変わり始めたのは2009年後半。マイクロソフトのVirtual Earth（バーチャルアース）がGoogle Earthを追い上げようと大都市を中心に航空測量で高品質な3Dモデルを大規模に作るようになったのを受け、Googleも対抗するように航空測量で大都市を中心に3D化するようになった。
それで生まれたのが今の東京のような、自動生成した個別の建物を配置するタイプの"初期型"3D都市だ。
これは建物が個別に配置されているため、Sketchupの3Dモデルに置き換えることが可能だ。
このGoogleの対抗措置は強力で、あっという間に世界の大都市を網羅してしまった。なお、Virtual Earthは現在廃止されているようだ。少なくとも最近は情報が来ていない。
この大規模な3Dモデル追加の際、東京にあったユーザーによる3Dモデルの多くが置き換えられた。とはいっても、見るに耐えないような低品質なモデルが淘汰されたといった感じだろうか。まぁ、多くの都市圏のユーザーが新たに3Dモデルを作る必要性を感じなくなったのは間違いないだろう。
そしてその数ヵ月後、2009年の終わり頃にリリースされたのが「ビルディングメーカー」だ。こいつはSketchupを使わなくとも、そして建物の写真を撮らなくとも、Googleの用意した航空写真とWebツールで3Dモデルを作成できる。この主な画像提供地は大都市とその近郊（大宮など）だった。
私は面倒なので使う事はなかったが、かなり手軽に作成する事ができる。ただ、自分としては、ビルディングメーカーのモデルはSketchup製に比べて品質が低く、かつ手軽に作成出来たため、3Dギャラリーの新着モデルの全体的な質が低下していたのが気に入らなかった。
なお、ビルディングメーカーは2013年の5月いっぱいでサービスを廃止する予定である。
（参照：A second spring of cleaning ）
この頃は、まだSketchupで上質なモデルを作れば大都市でも登録されていた。
それから2年経った2012年5月、Sketchup事業がTrimbleへ売却された。3Dギャラリーも同時にTrimbleへ売却され、Googleはあくまで機能の提供のみに徹するようになる。
（参照：Sketchup事業のTrimbleへの売却の話）
いやいや、これはまだ始まりに過ぎない。
この半月後の6月6日、Googleは、『Google Earth を刷新する』と発表し、自社の画像処理で人口3億人分もの世界の都市を3D化していくと宣言した。また、3D都市化のプロセスに関するこんな動画も作成された。
実はGoogleはこの発表の少し前、3Dマップ技術を持つ Poly9 と C3 Technologies の二社を買収しており、Google Earth をモノ好きのマイナーな地球儀ソフトから、誰もが使うような Google Map を構成する重要なパーツとして昇華させようと着々と準備を進めていたことがわかる。
Googleがこういった3D都市化を急いだのは恐らく、スマートフォンの爆発的な普及と、それに伴うアップル社の跳躍に危機感を持ったからだと考えられる。というのも、Googleがこの発表をした、そのわずか6日後の12日、Apple社は「AppleはiOSで独自の地図サービスを提供する」と発表、Google Earth を凌ぐ高品質な3D都市を披露した。つまり、Google 対 Appleによるスマートフォン界隈での激しい地図アプリ開発競争が行われており、Google Earth はその3D部門を担う攻め駒となっている訳だ。
（参照：Goodbye To Google Maps With Street View, Hello To Apple’s New Maps With 3D Flyovers）
（参照：「Google マップ」「Google Earth」を刷新へ - 3D地図がアップルとの一大争点に）
Googleの発表から約5ヵ月後の10月31日（米時間）、Google Earth 7.0 が発表され、それに伴い世界約20都市もの"新型"3D都市を発表。6月の宣言通り怒涛の勢いで3D都市化が広がっている。
（参照： Explore the world with tour guide and 3D imagery in Google Earth 7）
[補足] 初期型3D都市 と 新型3D都市 の違い
NYの同じ地点で比較図を作りました。左が初期型3D都市＋個人モデル。右が新型3D都市。
この図では右の方が写真で撮ったかのようにリアルですよね。これが「3D画像」と呼ばれる所以でしょうか。
しかし人間の目線に立ってみると優劣は逆転します。
上空からはまるで写真のように見えていた右の図は、粘土の様に波打った醜い姿になります。すなわち、新型3D都市は上空からの見栄えの良さ以外には地図としての情報が非常に乏しいのです。
分かる人には分かるイメージとして、左がベクタグラフィックス、右がラスタグラフィックスのようなものです。
[以上、補足終]
さて、今に至るまでの一通り Google Earth の変遷を見てきたが、なんだかまるでアイドル下積み時代を経てトップへ上り詰める一歩手前、といった感じだ･･････すまないなんでもない。
この"新型"3D都市というのが、Sketchup や3DギャラリーとGoogle Earth を大方切り離す決定的なものだと思う。というのも、この新型3D都市は都市を丸ごと、建物や樹木や道路や直下の地形も全て含めて丸ごと3D化するものである。つまり、Sketchupで3Dモデルを作ったとしても"新型"3D都市の建物に代わって追加されることはない。これからメインとなるであろう"新型"3D都市内に3Dギャラリーのモデルを追加する事はできない。
一応、Google Earthのオプションの[地形]で「3D画像を使用する（従来の3Dモデルを無効にする）」のチェックを外せば今までの個人ユーザによる3Dモデルを閲覧する事ができるが、デフォルトでチェックが入るようになっている事から都市部における旧来の3DデータはGoogleにとって重荷になっていると考える事ができる。
つまり、Sketchupや3Dギャラリーの大都市における3D建物モデルは既にお払い箱という訳だ。
もちろん、都市部以外の観光地における個人ユーザの3D建物モデルは今後も重宝するとは思われる。結局、航空写真による画像処理は超高層ビルが林立する大都市で威力を発揮しますから、範囲の狭い観光地の3D化は苦手の筈だ。だから"新型"3D都市のない地域は未だ3Dギャラリーの3D建物モデルがメインである。
これらの事から、Googleは今後Sketchupや3Dギャラリーと次第に距離を置いていくと推測する。そしてもしそうなったとして、果たしてGoogle Earth という中心的存在を失ったSketchupや3Dギャラリーがやっていけるかどうか、それが一番の懸念である。
ここで冒頭に回帰し、
これが今回の結論です。
p.s.
実はこの記事は上記の結論を書くことが目的ではなく、Sketchupや3Dギャラリーがどのように歩んだかを記録する事が目的です。このブログはどちらかというと自分へのメモ帳なんです。
2013/8/20 追記
3DモデルとGoogle Earthとの接続は2013年10月1日に切断される予定である。
というわけで、ついに終わりを迎えます…
10月までに投降した建物は更新されるまで残るという話です。
http://sketchup.google.com/3dwarehouse/?hl=ja
Googleがこういった3D都市化を急いだのは恐らく、スマートフォンの爆発的な普及と、それに伴うアップル社の跳躍に危機感を持ったからだと考えられる。というのも、Googleがこの発表をした、そのわずか6日後の12日、Apple社は「AppleはiOSで独自の地図サービスを提供する」と発表、Google Earth を凌ぐ高品質な3D都市を披露した。つまり、Google 対 Appleによるスマートフォン界隈での激しい地図アプリ開発競争が行われており、Google Earth はその3D部門を担う攻め駒となっている訳だ。
（参照：Goodbye To Google Maps With Street View, Hello To Apple’s New Maps With 3D Flyovers）
（参照：「Google マップ」「Google Earth」を刷新へ - 3D地図がアップルとの一大争点に）
Googleの発表から約5ヵ月後の10月31日（米時間）、Google Earth 7.0 が発表され、それに伴い世界約20都市もの"新型"3D都市を発表。6月の宣言通り怒涛の勢いで3D都市化が広がっている。
（参照： Explore the world with tour guide and 3D imagery in Google Earth 7）
[補足] 初期型3D都市 と 新型3D都市 の違い
NYの同じ地点で比較図を作りました。左が初期型3D都市＋個人モデル。右が新型3D都市。
しかし人間の目線に立ってみると優劣は逆転します。
分かる人には分かるイメージとして、左がベクタグラフィックス、右がラスタグラフィックスのようなものです。
[以上、補足終]
さて、今に至るまでの一通り Google Earth の変遷を見てきたが、なんだかまるでアイドル下積み時代を経てトップへ上り詰める一歩手前、といった感じだ･･････すまないなんでもない。
この"新型"3D都市というのが、Sketchup や3DギャラリーとGoogle Earth を大方切り離す決定的なものだと思う。というのも、この新型3D都市は都市を丸ごと、建物や樹木や道路や直下の地形も全て含めて丸ごと3D化するものである。つまり、Sketchupで3Dモデルを作ったとしても"新型"3D都市の建物に代わって追加されることはない。これからメインとなるであろう"新型"3D都市内に3Dギャラリーのモデルを追加する事はできない。
一応、Google Earthのオプションの[地形]で「3D画像を使用する（従来の3Dモデルを無効にする）」のチェックを外せば今までの個人ユーザによる3Dモデルを閲覧する事ができるが、デフォルトでチェックが入るようになっている事から都市部における旧来の3DデータはGoogleにとって重荷になっていると考える事ができる。
つまり、Sketchupや3Dギャラリーの大都市における3D建物モデルは既にお払い箱という訳だ。
もちろん、都市部以外の観光地における個人ユーザの3D建物モデルは今後も重宝するとは思われる。結局、航空写真による画像処理は超高層ビルが林立する大都市で威力を発揮しますから、範囲の狭い観光地の3D化は苦手の筈だ。だから"新型"3D都市のない地域は未だ3Dギャラリーの3D建物モデルがメインである。
これらの事から、Googleは今後Sketchupや3Dギャラリーと次第に距離を置いていくと推測する。そしてもしそうなったとして、果たしてGoogle Earth という中心的存在を失ったSketchupや3Dギャラリーがやっていけるかどうか、それが一番の懸念である。
ここで冒頭に回帰し、
Googleは「Google Earth」から「Sketchup & 3Dギャラリー」を大方切り離そうとしている
p.s.
実はこの記事は上記の結論を書くことが目的ではなく、Sketchupや3Dギャラリーがどのように歩んだかを記録する事が目的です。このブログはどちらかというと自分へのメモ帳なんです。
2013/8/20 追記
3D Modeling Pipeline for Google Earth will be retired October 1, 2013.
というわけで、ついに終わりを迎えます…
10月までに投降した建物は更新されるまで残るという話です。
http://sketchup.google.com/3dwarehouse/?hl=ja
