mysql空間拡張とGeoHash, quadkeyについて検索速度を比較してみた & quadkeyって何？の紹介 - Code for History
1週間程前かな？退社間際にやったSQL調整がどうしてもうまくいかず、100ms程度だった検索速度が空間検索条件を外すと爆速になったので、十分な確認もなく短絡して、Twitterで「mysqlの空間検索遅過ぎる！使えねー」と呟いてしまいました。 明日になればGeoHashとかquadkey*1のような一次元空間コード検索に変更してやるぞと。 が、翌日取り急ぎ検索条件をquadkeyに変更してやっても、特に速くならない。 あり？と思ってよくよくさらにチェックしてやると、複合検索のプロファイルの見方を間違えてて、テーブル間のリレーションキーで非空間テーブル=>空間テーブルの向きは主キーでリンクされてたけど、その逆はリレーションキーにインデックスを張ってなかったので、オプティマイザの選択が先に非空間テーブルの検索条件=>フィルタされたレコードに対し逐次空間検索、となっていたのが遅い原因でした。 非
Google Mapsが発明した、球面メルカトルタイル地図 - Code for History
社内で日誌を付けていて、最近まで味気ない業務報告だけしてたのですが、割といろんな話題投げる人が多いので、私も地図/位置情報の話題毎日投げるようにしました。 その中からいくつか、外に出せる話題はブログでも転載しようかと思います。 業務終了の10分程度の間に仕上げるので、あまり追調査もせず用語の説明も省いたり*1、記憶違いや事実誤認*2もあるかもしれませんが、その辺は補足や突っ込みいただければ幸いです。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 2005年に登場したGoogle Maps、やはり注目はAjaxスクロール地図でしたが、実は世界で初めてAjaxスクロール地図を実現したのはGoogleでなく日本のマピオンです。 標準地図ではなくマピオンラボというクローズサイト内のみでしたが、Googleより1年以上早くAjaxスクロール地図を実現していました。 Google
結局iPCのデータはiOS地図のどこに使われているのか＆おまけで暗峠 - Code for History
iOS6地図にデータを提供していると言う事で、一時は悪者にされかけてたインクリメントPやOpenStreetMapですが*1、日本ジオ業界の古老森さんの記事の拡散等もあって、無事問題はAppleの編集能力にあり、データ提供元に問題はないという認識が広まったように思います。 それじゃ、そもそもインクリメントPのデータはどこに使われてるのだろう？というのをちょっと調べてみました。 建物の外郭形状 iOS6の建物外郭。右下が空き地で建物ないのに注目してください。 (c) Apple MapFanの建物外郭。驚く程そっくり。 iOSで空き地の部分に建物があるが、この描画色が少し他の建物と違います。 (c) IncrementP 参考までに同じ地域のGoogle Maps。やっぱり元データが違うから、大分違います。というか、本当に大分違うね…。 (c) Google / Zenrin ご覧の通り、建
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
