APIにおける世界測地系

[Chris Atenasio]

Google Maps APIをご利用の皆様、

Google Maps APIで日本の地図を表示されている方へ、
Googleからのご協力のお願いです。

Google Maps APIにおいて、日本測地系（Tokyo Datum）
のずれを修正する準備が整いました。つきましては、修正
にあたりまして、皆様のご協力をお願いいたします。

日本でGoogle ローカル、Google マップの提供を開始
した際、全てのデータは日本測地系に基づいておりました。
（測地系とは緯度経度を決めるための基準となる座標系の
ことです。）しかしながら、皆様に国境のない
シームレスなサービスをご利用いただくためには、世界各国の
Googleローカル、Googleマップ（現在はGoogleローカルに
統合されています）、Google Earth、Google Maps APIなどを
同じ測地系でご提供する必要があります。

Googleは、これらのサービスが、多くのGPSなどでも使用され
ている世界測地系（WGS84）に正しく投影されるよう、作業を
進めて参りました。今回の移行作業が完了すると、これらの
すべてのサービスが統一された測地系でご利用いただけるように
なります。ここで皆様にお願いです。

Google Maps APIを世界測地系に移行する最後の
ステップとして、皆様が地図上に配置したデータを
日本測地系（Tokyo Datum）に基づいた緯度経度から、
世界測地系（WGS84）に基づいた緯度経度に移行
いただきたくお願い申し上げます。

この移行をサポートするため、本日より、APIのJavaScriptを
呼び出す際に、CGIに新しいパラメータを加えました。

http://maps.google.co.jp/maps?file=api&v=1&key=...&datum=wgs84

のようにCGIのパラメータとして&datum=wgs84を追加されることで、
世界測地系を基準とした地図をお試しいただくことができます。
（ただし、世界測地系への移行が完了した際には、このパラメータは
機能しなくなります。）

地図上に配置したデータの測地系を移行する方法として、下記のような
パターンが考えられます。

- "kjapandatumhack=false"パラメータを利用している、
またはその他のJavaScriptのパッチを利用して、
データを日本測地系へ変換している方はそれらの
パッチをはずしてください。

- 地図上に配置したデータの数が少ない場合は、
すでに世界測地系に移行されている
maps.google.co.jpより緯度経度情報をとること
ができます。maps.google.co.jpにアクセスし、
マークしたい場所をダブルクリックし、
画面右上にある「このページのリンク」と書いて
あるリンクをクリックしてください。URLの
パラメータ"ll"の部分をコピーし、皆様がお持ちの
データに反映させてください。

- 地図上に配置したデータの数が多い場合には、
国土地理院の提供するソフトウェアを利用する
方法もあります。下記リンクからダウンロード
できるソフトウェアを利用すると、
日本測地系（Tokyo Datum）のデータを
日本測地系2000（JGD2000）に変換することが
できます。世界測地（WGS84）と
日本測地系2000（JGD2000）の誤差は
+/-10cm程度です。

http://vldb.gsi.go.jp/sokuchi/tky2jgd/download/agreement.html

Google Maps APIコミュニティのメンバーの方でよりよい
解決案をお持ちの方は、ぜひ情報提供をお待ちしています。

Maps APIの世界測地系（WGS84）への移行は、12月1日に
行われる予定です。その後、日本測地系（Tokyo Datum）
のサポートを終了させていただきます。移行作業が難しい場合は、
できる限りのお手伝いをさせていただきますので、ご連絡ください。
お手数をおかけしますが、どうぞご協力をお願いいたします。

なお、測地系とは緯度経度を決めるための基準となる座標系のこと
です。日本測地系（Tokyo Datum）、世界測地系（WGS84）
などが存在します。詳細につきましては、国土地理院のサイトを
ご参照ください。

http://www.gsi.go.jp/LAW/G2000/g2000.htm

クリス

Dear Maps API users,

We're ready to fix the Japan datum skew on the API, but we need your
help. If you are using the Maps API to show maps of Japan, please
read on.

When we launched Local and Maps in Japan, all our data was in the
Tokyo geodetic datum. A "geodetic datum" said simply defines how to
measure the latitude and longitude of a point on the earth.

Since then we've been working to accurately re-project all the bits
and pieces into the WGS84 geodetic datum - this is the one most GPS
devices read. Once we're done, you'll be able to use the same
coordinate system internationally across Local, Maps API, Earth, not
to mention your GPS. But this is where we need your help.

For the final step, shifting API maps, we need you to transform your
latitude/longitude points in Japan into WGS84.

To help with the transition, starting today you can switch to the new
WGS84 maps by adding the CGI parameter &datum=wgs84 to your API
javascript request:

http://maps.google.com/maps?file=api&v=1&key=...&datum=wgs84

Don't worry, the parameter will just turn into a no-op once we make
the WGS84 default.

The best way to transform points (Tokyo datum -> WGS84) probably
depends on your situation:

- If you've been using "kjapandatumhack = false" or other javascript
patches, you might well be able to just rip the patch out and have
things work.

- If you have just a few points to re-project, you can probably get
away with reading them from local.google.com(already in WGS84).
Find and double-click the place you want to mark, hit the "Link to
this page" text in the upper-right of the screen, and copy down the
"ll" parameter from the URL bar.

- If you have more than just a few points, you might be interested in
using a more industrial conversion package. The Japan Geographical
Survey Institute has a nice grid+software solution for converting
Tokyo-datum coordinates to JGD2000(WGS84 +/- 10cm). You can
download it here:

http://vldb.gsi.go.jp/sokuchi/tky2jgd/download/agreement.html

Also I expect there might be a few members of the API community coming
out with with even better solutions, much like they did when we
launched maps with the datum hack in the first place.

Please switch to WGS84 maps by December 1st. We will be dropping Tokyo
datum support after that to make way for new and exciting things to
come.

Finally, for a bit more on geodetic datum in general, try here:

http://www.colorado.edu/geography/gcraft/notes/datum/datum_f.html

Thanks

chris

[joe]

> この移行をサポートするため、本日より、APIのJavaScriptを
> 呼び出す際に、CGIに新しいパラメータを加えました。
> http://maps.google.co.jp/maps?file=api&v=1&key=...&datum=wgs84

全国ロケ地ガイドのjoeと申します。
いつも、Googleマップを利用させていただきありがとうございます。

早速、世界測地系を試してみましたが、離島部分でずれが発生しています。
南大東島町役場では、西に515m、北に348mと、約800mずれています。
石垣市役所では、西に209m、南に161mと、約300mずれています。
このままでは、動作確認ができませんので、対応をお願いいたします。

ゼンリンの地図は、国土地理院の日本測地系ではなく、GPSなどで採用されている、測地系パラメータを使って3次元直交座標を経由して変換した、簡易的な日本測地系です。ですから、ゼンリンの地図に対して、国土地理院の変換パラメータを利用すると、位置がずれてしまうと思います。

同様に、現在のGoogleマップ（ゼンリンの地図）で表示されている緯度経度を、国土地理院の変換プログラムで世界測地系に変換すると、離島部分で約800mのずれが発生する可能性がありますので、ご注意ください。Googleマップではありませんが、以前、ゼンリンの地図の緯度経度を国土地理院の変換プログラムで処理をし、緯度経度がめちゃくちゃになってしまった苦い経験があります。

[joe]

全国ロケ地ガイドのjoeと申します。
連続投稿失礼します。
先ほどの投稿での、Googleマップのプログラムを提示しますので、参考にしてください。
離島以外では、どちらのプログラムもずれは発生しません。

●南大東島町役場
・国土地理院の2万5千分の1の地図閲覧サービス
http://watchizu.gsi.go.jp/watchizu.aspx?id=38315155&slidex=1444&slidey=219&w=800&h=600
南大東島町役場の世界測地系の緯度経度は、北緯25度49分41秒，東経131度13分55秒

・世界測地系の緯度経度をGoogleマップ（datum=wgs84を指定）で表示
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N25.49.41.00&el_w=E131.13.55.00&datum=wgs84
南大東島町役場では、西に515m、北に348mと、約800mずれる

・世界測地系の緯度経度を全国ロケ地ガイドでGPS用日本測地系に変換しGoogleマップで表示
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N25.49.41.00&el_w=E131.13.55.00
ほとんど、ずれはない（町役場の記号の位置が違うのは地図が違うため）

●石垣市役所
・国土地理院の2万5千分の1の地図閲覧サービス
http://watchizu.gsi.go.jp/watchizu.aspx?id=36244100&slidex=946&slidey=1366&w=800&h=600
石垣市役所の世界測地系の緯度経度は、北緯24度20分26秒，東経124度9分20秒

・世界測地系の緯度経度をGoogleマップ（datum=wgs84を指定）で表示
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N24.20.26.00&el_w=E124.09.20.00&datum=wgs84
石垣市役所では、西に209m、南に161mと、約300mずれる

・世界測地系の緯度経度を全国ロケ地ガイドでGPS用日本測地系に変換しGoogleマップで表示
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N24.20.26.00&el_w=E124.09.20.00
ほとんど、ずれはない

[tato]

APIに感謝と敬意を込めて
高橋と申します

> Maps APIの世界測地系（WGS84）への移行は、12月1日に
> 行われる予定です。その後、日本測地系（Tokyo Datum）
> のサポートを終了させていただきます。移行作業が難しい場合は、
> できる限りのお手伝いをさせていただきますので、ご連絡ください。
> お手数をおかけしますが、どうぞご協力をお願いいたします。

今後も、日本測地系のデータを利用しなければならない場合もありますので、
とりあえず、&datum=wgs84を付加した上で、、、、

<script

src="http://maps.google.com/maps?file=api&v=1&key=自分のキー&datum=wgs84"

type="text/javascript">
</script>

GPointクラスに現在Googleさんが行っていらっしゃる平行移動処理をパッチしてみました。問題などありますでしょうか？

//GPointクラスを使用前に下記のように上書きします。
//世界測地系(wgs84)の座標を使うときは不要です
GPoint = function (a,b){
if(b>30&&(b<50&&(a>115&&a<152))){
this.x=a-0.0032027777777777775;
this.y=b+0.003236111111111111;
} else {
this.x=a ;
this.y=b ;
}
}

Google Maps APIの測地系変更にともなうTips
http://jsgt.org/mt/archives/01/000624.html

現状のサンプル(東京タワーをマーカーが指しています)
http://jsgt.org/ajax/newmon/samples/chapter03/03-12/sample_old.htm

APIキーのURLに「&datum=wgs84」を追記して
世界測地系モードにしてみたサンプル(芝公園を指しています^^;;;)
http://jsgt.org/ajax/newmon/samples/chapter03/03-12/sample_w.htm

APIキーのURLに「&datum=wgs84」を追記して
更にGpointクラスを修正後のサンプル
http://jsgt.org/ajax/newmon/samples/chapter03/03-12/sample_w_test.htm

[joe]

> 高橋と申します
高橋さん、はじめまして。全国ロケ地ガイドのjoeです。

> GPointクラスに現在Googleさんが行っていらっしゃる平行移動処理をパッチしてみました。問題などありますでしょうか？
> this.x=a-0.0032027777777777775;
> this.y=b+0.003236111111111111;

Googleさんが平行移動されているという情報をどこから入手されたかは知りませんが、少なくともGoogleさんは平行移動などしていないと思います。Googleさんが行っているのは、単なる平行移動ではなく、基準となる楕円体の変換です。
ですから、高橋さんのやり方には、問題があると思います。

たとえば、石垣市役所で、同じことを試してみてください。
私が試したところ、600mほどずれました。
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N24.20.26.00&el_w=E124.09.20.00
http://loca.ash.jp/cgi/googlemap3.cgi?nl_w=N24.20.26.00&el_w=E124.09.20.00

同様に、北海道の納沙布岬灯台で、同じことを試してみてください。
私が試したところ、100mほどずれました。
http://loca.ash.jp/cgi/googlemap2.cgi?nl_w=N43.23.06.85&el_w=E145.48.59.90
http://loca.ash.jp/cgi/googlemap3.cgi?nl_w=N43.23.06.85&el_w=E145.48.59.90

[tato]

>joe wrote:
>> > 高橋と申します
> > 高橋さん、はじめまして。全国ロケ地ガイドのjoeです。

joeさん、はじめまして。
ご指摘有り難うございます。確かにずれますね。

> Googleさんが平行移動されているという情報をどこから入手されたか

Googleさんが現在配布されているmaps.js(現在のバージョンはmaps.27.js)などの
http://maps.google.com/mapfiles/maps.27.js
下記のあたりから推測しました。(
このスクリプトは、どんどん変更されていますから
そのうち消えてしまうかもしれませんが、、、)

C.prototype.getBitmapCoordinate=function(a,b,c,d){
if(this.japanDatumHack&&(a>30&&(a<50&&(b>115&&b<152)))){
a+=0.003236111111111111;
b+=-0.0032027777777777775
}
return this.getBitmapCoordinateWGS84(a,b,c,d)
}

2005.11.14現在、たとえば、メソッドcenterAndZoomなどは、Gpointオブジェクトの座標x,yを、getBitmapCoordinate(this.centerLatLng.y,this.centerLatLng.x,this.zoomLevel)といった形で
getBitmapCoordinateへ渡しているのですが、上記のように、getBitmapCoordinate内部では、japanDatumHack==trueで(a>30&&(a<50&&(b>115&&b<152)))な場合には、平行移動を行っているように見えたからです。
ただ、いろいろなケースをトレースして精密に試してみたわけではありませんので、間違いがあるかもしれません。

というわけで、わたしが試した方法は、現在Googleさんが簡易的に行っている上記部分を2005.12.1以降も有効にすることでいままでのデータを利用できるようにしたい、ということなのですが、厳密な、測地系変換の根本治療ではありません。

で、石垣市役所ですけれど、joeさんの書かれている座標によりますと、124.156947222222,
24.3363888888889ということで、
getBitmapCoordinateが行っている四角形のエリアの外にありますから、今ちょっと見ただけではなんともいえないのですが、
少なくとも、(a>30&&(a<50&&(b>115&&b<152)))なので動作しないと思います。でも、納沙布岬灯台の方はエリア内ですね。。
うーむ、、、。

#全国ロケ地ガイドすばらしいですね。
#今後ともよろしくお願い致します。

[joe]

全国ロケ地ガイドのjoeです。

> http://maps.google.com/mapfiles/maps.27.js
> 下記のあたりから推測しました。(

なるほど、確かにソースには、平行移動処理が記述されていますね。
では、私の推測を述べさせていただきます。あくまで、推測ですので、参考程度にしてください。

Googleマップは、当初、世界測地系だったにもかかわらず、途中から、GPS用日本測地系に変更されています。
これは、最初は、世界測地系を平行移動して、東京付近だけ対応し、私が指摘したような問題があったため、ゼンリンの地図の緯度経度をそのまま指定するように仕様変更したのだと思います。ですから、ソースの平行移動処理は、現在、使われていないと思います。

ゼンリンの地図は、楕円体の変換のみを行うGPS用日本測地系だと思われますし、事実、私の計算では、ほぼ正確に位置付けることができています。Googleさんも、私の処理と同じ処理をすれば、GPS用日本測地系に変更しなくても、世界測地系のまま利用できたはずです。
私の処理も正しいとは限りませんが、離島部分も含む日本全国約1万個所のデータで確認していますが、ずれはほとんどありません。しかも、一番、問題になりやすい、石垣島と西表島には、ハンディGPSを持って行き、現地での位置確認もしてきましたので、多分、大丈夫です。処理が誤っていることを示すためには、異常な例を1件提示すればいいのですが、処理が正しいことを証明するのは大変です。

> わたしが試した方法は、現在Googleさんが簡易的に行っている上記部分を2005.12.1以降も有効にすることでいままでのデータを利用できるようにしたい、ということなのですが、厳密な、測地系変換の根本治療ではありません。

単に、現在のGoogleAPIで利用している緯度経度を、datum=wgs84を指定した場合でも利用したいということでしたら、私（j...@ash.jp）にメールしてください。全国ロケ地ガイドで採用している簡易的な処理方法（誤差数m）で良ければ教えますよ。
本当ならば、ソースを公開したいところなのですが、部分的に引用した個所もあったりしますので、ソースの公開には時間がかかってしまいます。

> #全国ロケ地ガイドすばらしいですね。

ありがとうございます。
全国ロケ地ガイドでは、ロケ地マップの表示でGoogleマップを利用させていただいています。

[Digital Life Innovator]

全国ロケ地図(http://saya.s145.xrea.com/x/lmap.html)のmasaです。

現時点で確かめたわけではないですが、平行移動処理はサテライトモードで行われており、マップモードではGPS用の日本測地系になっていました。これが話をややこしくしている原因ですね。
したがって、同じ座標でもモードを切り替えるとずれが発生したりします。
全国ロケ地図では、モードの切り替え時に座標を変更して表示しています。
参考記事：http://saya.s145.xrea.com/archives/2005/08/ff.html
今回の世界測地系対応(&datum=wgs84)では、サテライトモードは平行移動処理をなくし（これは正しい世界測地系）、マップモードは(アナウンスにも出てくる)TKY2JGDを使って変換したと思われます。本当はjoeさんのおっしゃるように楕円体の変換を行うべきだったのでしょう。
実際、世界測地系(&datum=wgs84)で石垣島付近を見るとマップとサテライトはずれています。
参考記事：http://saya.s145.xrea.com/archives/2005/11/google_maps_api_2.html

[tato]

Digital Life
Innovatorさん joeさん ありがとうございます。

>ソースの平行移動処理は、現在、使われていないと思います。
確認しました。確かに、平行移動処理は、今は動作していませんでした。

> 現時点で確かめたわけではないですが、平行移動処理はサテライトモードで行われており、マップモードではGPS用の日本測地系になっていました。これが話をややこしくしている原因ですね。
> したがって、同じ座標でもモードを切り替えるとずれが発生したりします。

これも確認しました。サテライトモードとデュアルモードでは、C.prototype.getBitmapCoordinateを経由して平行移動を行っていました。
これは、複雑ですね、、、。

> 全国ロケ地図では、モードの切り替え時に座標を変更して表示しています。
> 参考記事：http://saya.s145.xrea.com/archives/2005/08/ff.html

powered by 全国ロケ地ガイド ,
CSVアドレスマッチングサービス and Googleなんですね。
良い感じで動作してますね。

[joe]

　全国ロケ地ガイド（http://loca.ash.jp/）のjoeです。

> 現時点で確かめたわけではないですが、平行移動処理はサテライトモードで行われており、マップモードではGPS用の日本測地系になっていました。これが話をやや­こしくしている原因ですね。

　なるほど、サテライトモードに関してはチェックしていませんでした。
　datum=egs84を指定した世界測地系でサテライトモードにすると、日本全国、ピッタリですね。
　地図のない与那国島も確認しましたが、一致していました。しかし、与那国島の雲の多さは、なんとかして欲しいですね。あと、世界に対応する予定でしたら、与那国島の地図も欲しいです。

> powered by 全国ロケ地ガイド、CSVアドレスマッチングサービス and Googleなんですね。

　全国ロケ地ガイドの約1万件のデータの内、9割以上は緯度経度情報を持っていますが、一部のデータには、緯度経度情報がないものがあります。いずれは、すべてのデータに緯度経度情報を持つ予定です。
　全国ロケ地ガイドでは、国土地理院準拠の日本測地系、GPS用の日本測地系、世界測地系と3種類の緯度経度に対応していますので、どのようなシステムにでも対応可能なのですが、それ以外の処理をされると、さすがに対応できません。

　現在、販売されている電子地図は、アルプス社と昭文社が国土地理院準拠の日本測地系で、ゼンリンがGPS用の日本測地系です。私が知る限りでは、世界測地系の電子地図はないようですから、Googleマップの世界測地系対応を機会に、世界測地系への移行が進むことを期待しています。

[tato]

joeさんに教えて頂いた修正処理をGPointに埋め込んでみました。

GPoint = function (a,b){
this.y = b - b * 0.00010695 + a * 0.000017464 + 0.0046017;
this.x = a - b * 0.000046038 - a * 0.000083043 + 0.010040;
}

テストのサンプル 今回の修正
http://jsgt.org/ajax/newmon/samples/chapter03/03-31/200511tokyo2wgs/test_w_syusei.htm
石垣だけ地図が少しずれますが、かなり改善されています（^^）。

平行移動処理も同様に確認
http://jsgt.org/ajax/newmon/samples/chapter03/03-31/200511tokyo2wgs/test_w_syusei2.htm

おかげさまで、だいぶ良くなりました。

Google Maps APIの測地系変更にともなうTips2
http://jsgt.org/mt/archives/01/000646.html

[joe]

全国ロケ地ガイド ( http://loca.ash.jp/ ) のjoeです。

tatoさんのサンプルページを拝見させていただきました。
サテライトモードでは、ほぼ、問題はなくなりましたね。サテライトモードと地図モードを切り替えるとずれが発生しますので、Googleマップ側で、対処していただくしかありません。Googleマップ側で、国土地理院のTKY2JGD準拠の測地系変換ではなく、測地系パラメータを使って3次元直交座標を経由した測地系変換を使って、地図を移動して頂ければ、解決すると思いますので、よろしくお願いいたします。

なお、Nowralさんのページの国土地理院のページは、リンク切れとなっていますので、下記のURLを参考にしていただければ、直交座標を経由した計算式なども掲載されています。
http://vldb.gsi.go.jp/sokuchi/surveycalc/main.html

余談になりますが、Yahooマップも航空写真に対応したようです。こちらは、国土地理院準拠のアルプス社の地図を利用していますので、石垣島や与那国島などの離島でも、地図と航空写真のずれはありませんでした。競合他社の地図も参考にして、よりよい地図となることを期待しています。

石垣島で、各社の地図を比較するプログラムを作成してみましたので、参考にしてください。
http://loca.ash.jp/cgi/tky2jgd.cgi?nl_t=N24.20.06.11&el_t=E124.09.18.72

[joe]

全国ロケ地ガイド（ http://loca.ash.jp/ ）のjoeです。

本日、確認しましたところ、世界測地系でも正しい位置で表示されることを確認しました。
また、マップとサテライトを切替えても、位置がずれないことも確認しました。
対応、ありがとうございました。

あとは、与那国島、西表島、小浜島、鳩間島など、地図がない地域への対応を、是非、お願い致します。

[Apostle...@gmail.com]

アップルップル（ http://www.appleple.com/
）の千賀と申します。

Google Mapsの世界測地系への変更ですが、
予定通り2005年12月1日に実施されたのでしょうか？
現状では、まだ日本測地系を使用しているように思えます。

[Y]

さぁ？・・・

俺にはわかりません。

[noki]

まだ切り替わっていないように見えます。テンポラルなパラメーターdatum=wgs84を外すと、地図と座標の関係が狂ってしまいます。

ただjoeさんがすでに切り替えを確認しているので、私が何か感違いをしているのか、何らかの理由で変更を戻してしまったのでしょうかね。

[joe]

　全国ロケ地ガイド ( http://loca.ash.jp/ ) のjoeです。

＞ただjoeさんがすでに切り替えを確認しているので、私が何か感違いをしているのか、何らかの理由で変更を戻してしまったのでしょうかね。

　説明が不十分で申しわけありませんでした。
　少なくとも、11月30日までは、datum=wgs84を指定すると、石垣島などで地図がずれてしまい、使い物にならなかったため、移行作業ができませんでした。
　12月1日のリリースで、石垣島などでの地図がずれが修正されましたので、ようやく世界測地系への移行作業を行うことができました。
　今後は、放置しておいても、地図がずれることはないはずですから、事実上、移行作業が完了したと認識しております。

[taramo]

はじめまして、こちらのグループはよく見させていただいてます。

結局、移行は完了しているのでしょうか？
私もまだ、日本測地系を使用しているように思えるのですが・・・

[Apostle...@gmail.com]

アップルップル（ http://www.appleple.com/
）の千賀と申します。

12月1日以前にGoogleMaps上から作成した地図座標（日本測地系）を使用して、
現在もGoogleMapsを表示させているのですが、
既に世界測地系に変更されているのであれば、座標がずれるはずですよね？
ですが、まだ意図した位置に正常に表示されている状態なのです。
当方の認識が間違っているようであれば、ご指摘お願い致します。

[taramo]

うちも、同じ状態です。
datum=wgs84をつけると位置がずれてしまうので、日本測地系なんだと推測してるのですが。

map.google.comを見ているか、map.google.co.jpを見ているかで違うということありますでしょうか？
apiキーを取得するときに、そのようなことが書いてあったような、なかったような・・・すみません。うろ覚えです。

こちらで作ってます。
http://map.138files.com/

[joe]

　全国ロケ地ガイド（ http://loca.ash.jp/ ）のjoeです。
　11月9日の掲載された文章を読み直して見ましたが、下記のスケジュールだと思います。

11月09日
世界測地系の試行開始（datum=wgs84が利用可能）
　datum=wgs84 世界測地系（離島で位置のずれが発生）
　datum無指定 日本測地系（位置のずれはない）
12月01日 世界測地系へ移行開始
　datum=wgs84 世界測地系（位置のずれはない）
　datum無指定 日本測地系（位置のずれはない）
時期未定
世界測地系へ移行完了（日本測地系のサポート終了）
　datum=wgs84 世界測地系（位置のずれはない）
　datum無指定 世界測地系（位置のずれはない）

　datum=wgs84を指定しないと、いつずれるか分からないから、とにかくdatum=wgs84を指定し、世界測地系に移行して欲しいということだと思います。ですから、全国ロケ地ガイドでは、wgs84を追加し、世界測地系に移行させていただきました。
　私が指摘したようなバグは試行中だから、すみませんという意味みたいですね。
　しかし、Googleが推奨している国土地理院の測地系変換プログラムを利用してしまうと、離島で800mもずれることがありますので、これだけは警告しておきます。誤差は+/-10cm以内と掲載されていますが、Googleマップの日本測地系はGPS用の日本測地系であり、TKY2JGDがサポートする国土地理院の測量図の日本測地系とは、異なる測地系ですから、誤差が+/-10cm以内となることは絶対にありません。

[taramo]

こんにちは

なるほど、これから順次移行されていくのですか。
うちは、離島はありませんのでdatum=wgs84をつけてデータを移行していこうと思います。

今までこういう地図のデータは扱ったことがなかったので勉強になります。
色々な体系があるんですね。

どうもありがとうございました。

[joe]

全国ロケ地ガイド（ http://loca.ash.jp/ ）のjoeです。
日本測地系のサポートが終了したようです。
やはり、何の告知もありませんでしたね。

[Apostle...@gmail.com]

アップルップル（ http://www.appleple.com/
）の千賀と申します。

当方でも世界測地系への移行を確認致しました。
joeさんや他の皆様も、有難う御座いました。

[tato]

私のところでも今日ようやく確認できましたので、「入門Ajax」のダウンロードサンプルをすべて修正版に差し替えました(この点はCD-ROMより便利です)。

ところで、バージョンはまだ、27aのままなんですよね、、、複雑にいじってるなぁ、、、。
http://maps.google.com/mapfiles/maps.27a.js