測地系の種別で緯度経度の座標数字はズレる！GoogleMAPとゼンリン地図APIで比較
測地系の種類の違いによって、緯度経度の座標数字にはズレが存在します。
『座標数字入力⇒地図にマーカーピン表示』の場合、測地系と言われるGPSの規格の様なものが発する座標数字が微妙に異なるためです。
地図APIを活用した開発を行う際は、スマホやタブレットやパソコンなど『デバイスのGPSで採用されている測地系規格』と『地図APIで利用する測地系規格』の整合性を確認しなければならないです。
Google MAP APIが更新を繰り返してきている理由は、測地系の規格や精度の進化の歴史と共に歩んできたという事も予測されます。ありがた迷惑。
東日本大震災により国土地理院が測地成果2011をリリース、日本測地系2011（JGD2011,世界測地系（測地成果2011））が世の中に出てきたが、ヤフージャパン、MAPFAN、GOO等も含めてゼンリンも『日本測地系（旧日本測地系、Tokyo Datum、TKY）』のままなんだろうか？ググってもよくわからない。どなたか教えてください。
最初は以下の点でロジックや作戦を検討しておくといいかもしれません。
- 開発プロダクトで主要な機能は何が必要なのか？
- 各種APIのどのオブジェクトを使うのか？
- 住所テキスト入力による緯度経度の座標数字取得の精度は確保できるのか？（IPアドレスの場合は限界がある。どこかで妥協が必要）
各種APIのオブジェクトは、kintoneのJSファイル側で、一度、モジュール化して用途別に使い分け出来る形で実装する事がベストです。
「測地系の規格名」や「表記形式」の「用語」や「略称」がバラバラで統一感が無い
表記ブレによる重複など、極めてわかりにくい（コスト増加要因）。
コードを書く前の前のドキュメントリーディング時に、色々と疑いながら把握していく必要が有りめんどくさい。おそらく、サードパーティ地図API、開発アプリケーションのAPI、Geolocation API、座標互換のproj4jsライブラリなどjavascriptで4種以上のAPI/ライブラリを同時にリーディングする事になりがちです、リーディングや参照時間が多いのでうかつな見積は赤字を招きます。
シングル/ダブルクリック、シングル/ダブルタップなど、jsのイベントトリガーやモバイル対応も実装量の増加要因で複雑化します。
GPS？
Global Positioning System、全地球測位システム
測地系（測地基準系）について
「測地系（測地基準系）」でググると地球上の色々な空間座標システムの規格的なものが出てきます。色々な種類を知りたい方は、おググりください。WIKIPEDIA、かなりまとまっていました。表記ブレかどうかわかりませんが、測地系を空間参照と言う事もあるのかもしれない。紛らわしい。よくわからない。
日本測地系（旧日本測地系、Tokyo Datum、TKY）
ゼンリンは、http://www.zenrin.co.jp/support/software/faq/faq2.php?q=90も合わせて見ると、APIでは『日本測地系（旧日本測地系、Tokyo Datum、TKY）』。
※Datumとは、TOKYOかWGS84か、という測地系種別の事を指します。
住所検索、施設検索、緯度経度検索、ルート検索、その他検索など、検索種別により利用するAPIオブジェクトが異なります。ゼンリンの「いつもNAVI」にログインしてAPIを確認する必要が有ります。
日本測地系と旧日本測地系は同じもの？
（たぶん）同じ。日本の測地系、おそらく統一非営利団体とかの情報発信力（WEB推進力）が弱い。国土地理院の測量計算サイトにもAPIがあります。
世界測地系（WGS84）
googlemapは、『世界測地系（WGS84）』。
緯度経度の座標の表記形式が主に2タイプ存在する
代表的なものは以下の2タイプの様です。ググると表記形式を変換するWEBサイトがたくさん出てくる。
- ミリ秒表示/秒表示/分表示・・・小数点を含まない数字の表示形式。ミリ秒は1000分の1秒、秒表示の1分=60秒、分表示の1時間=60分です。ミリ秒だけ異なるという事に注意！
- 十進度表示（度表示）・・・小数点を含む数字。google map（世界測地系 WGS84）、おそらく一番慣れ親しんでいる表記形式。
1の使いどころは、今のところ調べていません。
『日本測地系（旧日本測地系、Tokyo Datum、TKY）』と『世界測地系（WGS84）』の座標数字はズレている
- 稚内付近では北西方向へ400m
- 東京付近では北西方向へ450m
- 福岡付近では北西方向へ420m
http://blog.asial.co.jp/iphone/1160 より。
ニシインターナショナルの所在地でテスト
http://dev24.php.xdomain.jp/zenrin-test/を参照ください。googlemapが採用している規格の世界測地系（WGS84）基準の緯度経度の座標数字でゼンリンとGooglemapでマーカーピンを立てました。ズレています。確かに、見た目フィーリングで400mくらい。
ゼンリンAPIの使い方やポイント
- いつもNAVI デベロッパーズサイトに登録、さらにリファラー登録（APIを使うドメインを登録。ドメイン登録2個以上できました）
- headタグ内でCGI向けの読み込みスクリプトにドメインとkeyの設定（keyを暗号化したい・・・）
- headタグ内でCGI向けの読み込みスクリプトのGETのURLパラメータ『alert=1』を付ける（APIファイルのダウンロード失敗時、エラーダイアログを表示する）
- 文字エンコーディングEUC-JP推奨！なんと、推奨はUTF-8ではない。レガシーですな。
いつもNAVI開発キット APIマニュアル V2 を参照ください。
予算があるなら、Google MAP APIの方が良いと思う。世の中は金だぜ。
ゼンリンAPIの課金はPV（ページビュー）基準
- １回の地図表示（初期表示やページのリロードによる再表示）は１PV
- １回の検索は１PV
APIにHTTPリクエストが1回飛んだらカウント1だと思われる。ディベロッパー登録者は月5000回まで無料。
※『いつもNAVI デベロッパーズサイト』ログイン状態⇒『リクエストレポート』（アクセスログ）で回数確認ができますが、当日の回数は確認できず、昨日以前の回数を自由に確認できます。おそらくホスト側で1日1回データ更新のCronかも。
位置情報検証のデバイス設定
iphone5sのバージョン10.3.3の場合
iphone5sでiCloudにサインインしておいてください。
そして、「設定」⇒「プライバシー」⇒「位置情報サービス」をオンにします。
さらに、「設定」⇒「ユーザー名」⇒「iCloud」⇒「iPhone を探す」をオンにします。iphone紛失時の追跡に使う機能です。
最後に、パソコン等のブラウザでhttps://www.icloud.com/にログインして、『iphoneを探す』に進む。
iphone5sのGPSは世界測地系（WGS84）です。ということで、地図API開発は、費用が上がるとしてもGoogleMAPのAPI世界測地系（WGS84）を採用したほうが基本的には楽かも・・・。でも、開発案件により大人の事情もいろいろあると思います。
ゼンリン地図APIで測地系の選択肢があった
ゼンリンは、『日本測地系（旧日本測地系、Tokyo Datum、TKY）』で座標数字入力（検索）⇒地図表示ではなく、ZDC.Search.getLatLonByAddrのオブジェクトを使って日本語（漢字や平仮名など）で住所入力（検索）⇒地図表示の場合、旧日本測地系でも世界測地系のWGS84でもどちらでも座標数字取得できるAPIになっています。各種プラグインの存在も見えてきましたが、各プラグインが何をしているか？不明。
『文字列でPOI（point of information）検索』 と 『住所で緯度経度検索』の違いは現在不明。
Windows10（バージョン1703）、Creators Update後の場合
『windowsの設定』⇒「プライバシー」⇒「位置情報」⇒「位置情報サービス」⇒オンにする。
パソコンなどでGPSが搭載されていないと位置情報取得不可です。
GPSが搭載されている場合、パソコンの機種や型式等からGPS機種名等を調べて、測地系の規格まで調べてください。
GPSが無い場合、プロジェクトの測地系の規格をチェックして該当する測地系のUSBタイプのGPSを買うという手があります。
デバイスのGPSから現在地の緯度経度座標を取得する
javascriptの世界測地系（WGS84）のGeolocation APIを使うことがあります。SSL化していないと使えないブラウザが増えています。
http://dev24.php.xdomain.jp/zenrin-test/ を参照ください。今、利用されているデバイスではGPSを使えるかどうか可否を確認できます。GPS利用可能であってもデバイスに正しいGPS利用設定（位置情報の取得許可の設定）がされていないとダメです。
日本測地系（旧日本測地系、TokyoDatum、TKY）と世界測地系（WGS84）との緯度経度の座標数字相互変換
Objective-C上で行う方法がQiitaにあります。http://qiita.com/glayash/items/882d101f4a49db28090c。javascriptの場合、落とし穴がいくつかある様ですが、空間参照系変換ライブラリproj4jsがある。
Google MAP、ゼンリンMAP、その他MAPの緯度経度の座標数字ズレ問題は開発精度確保に対してに厄介な課題
測地系についての悩みにも記載されていますが、根本的には、利用する地図をグーグルマップならグーグルマップだけ、ゼンリンならゼンリンだけなど完全に地図サービスの利用を制限統一するしかない様です。
Geolocation APIで経度緯度のaccuracy（精度）の数値が大きい原因は、WiFi アクセス ポイントや携帯電話の基地局ではなく、リクエストの IP に基づいて位置情報を算出している場合に発生する。有効な携帯電話の基地局やアクセス ポイントがない場合や、認識できない場合に発生する。とのこと。
Google Maps Geolocation APIのよくある質問より。
住居表示に関する法律
昭和37年に制定されたもので、〇×丁目などが住所に入る様になり、「地番」と「住居表示」で2タイプの住所記法が日本は混在しています。システムの中で判別が必要になる事があります。GPSのAPI開発は、地理を通して少し歴史を垣間見る感じで興味深いです。
分析活用
CSVとデータ連携して分析活用するなら、BIツールでPower BI、Treasure Data、tableau、QlikView、etc。グラフ処理系のjsライブラリならamcharts、chartjs、canvasjs、Google Charts、highcharts、amcharts、NVD3.js、Vis.js、etc。ファイルストレージならAzure Data Lake Store、Azure blob storage、AWS S3とAthenaの組み合わせなど。ストレージについては、色々考えられるが、Azure CosomosDBやAmazon DynamoDBなどの非構造的データ向けのNoSQL（Document DB）に保存という手もある。NoSQLはダイナミックスキーマに応じたBIツールを検討する必要が有る。NoSQLに押され気味ですが、並列分散処理のHadoop（Azure HDInsight、AMAZON EMR）などもあります。データの種類や量が増え続け、構造部分にもフレキシブルなデータ分析が求められる場合、NoSQLのダイナミックスキーマが良いかもしれません。
AMAZON AthenaはS3上のデータ（CSV, JSON, その他フラットファイル）に対して、インタラクティブにSQLを実行する。
Hadoopは高速処理というよりも大量データを手分けして複数のストレージに分散格納する事で大量データ処理専門で速さを出すという感じ、オンライン処理よりも夜間バッチ処理などに向いている感じ。詳細は、
BI（Business Intelligence）とBA（Business Analytics）
BIは分析するためのデータ、BAはそのデータ達の分析です。
