著者：セルゲイ・ジノビエフ
ほとんどの場所で地図に遭遇するため、多くのモバイルおよびWebアプリケーションには異なる地理データが含まれています。 そのため、Foursquareのような地球社会的ネットワークからBlaBlaCarのような旅行検索サービスまで、さまざまなソーシャルアプリケーションで使用されています。 Google、Microsoft、Yahoo、および他の多くのITの巨人は、マップ、これらのマップ上のマーカーの表示、最も一般的な計算の実行などの簡単な操作のためのAPIを提供しています。 人気のあるRuby on Railsラピッド開発フレームワークは、地図データを使用して地理情報システム（GIS）およびWebアプリケーションを開発するためによく使用されます。 簡単な例を使用して、空間データを使用するときに予想される問題と、Ruby on Railsアプリケーションでそれらを回避する方法を示します。
邪悪な火山に出会わない方法
そのため、アプリケーションを開発していますが、ある時点で、2つの地理的ポイント間の最短直接距離を見つける機能を追加する必要があります。 複雑なことはないように思えますか？ どんなに！ Daniel Azumaは、ブログのGeoRailsタグの下にある一連のエントリで、空間データを操作できないことが悲劇につながる例を示しています。
ダニエルは次の仮説的な状況を考えることを提案します。 トーゴのほとんどの火山の次の噴火の間に、サンフランシスコからアテネへのフライトを行う必要がある飛行機を想像してください。アイスランドでは発音できません。 パイロットのタスクは、火山から安全な距離を飛行するようにルートを計画することです。 また、航空機に十分な燃料を補給するには、ルートの長さを知る必要があります。 すべてを正確に計算するために、航空機司令官は航空管制センターに要求を出します。
センターの従業員が最近、Ruby on Railsで最新のWebベースのフライトプランニングアプリケーションを開発しました。 リクエストを受け取った彼は、実際にアプリケーションを初めてテストすることにしました。旅行の始点と終点の座標を入力し、北緯38度の緯線に沿ってGoogleマップでそれらの間に直接線を引きます。
すべては順調です、火山は飛行の危険にさらされていません！ 次に、センターの従業員は2つのポイント間の距離を測定し（乗組員が適切な量の燃料を計算できるように）、必要なデータをすべて乗組員に送信し、パイロットに良いフライトを望みます。 数時間後、フライトコントロールセンターはこの航空機からSOS信号を受信し、火山噴火ゾーンに直行します。
おそらく既に推測されているように、これは地図上の投影の歪みが考慮されていないという事実によるものです。 私たちの惑星の球形は、平面上では歪みなく表現できません。 したがって、サンフランシスコとアテネを結ぶ直線の実際の最短ルートは、火山が噴火するアイスランドを直接通過することが判明しました。 フラットマップ上の直接ルートは、実際には直接ルートではありません。
一般に、各地図投影法には長所と短所があります。 希望する投影法の選択は、マップでキャプチャされた領域と開発者の目標に依存します。 主なことは、ルートを敷設することではなく、学校で慣れ親しんでいる緯度と経度の線形直交座標系を使用して距離を計算しないことです。
シンプルなソリューション：RGeo
Ruby on Railsの開発者として、座標の再計算、距離の計算、毎回ゼロからの投影の操作のすべてのビジネスロジックを実装する必要がないことを非常にうれしく思います。 最も一般的なSQLおよびNoSQLデータベースのアドオンなど、空間データを操作するためのツールがあります。それらを使用してマッピングアプリケーションを構築するのがはるかに簡単です。
この種の最大かつ最も機能的なライブラリの1つはPostGIS for PostgreSQLです。 Daniel Azumaは、さまざまなActiveRecord DBMS用のRGeo gemとアダプターも開発し、空間データを使用してRuby on Railsでの開発をより簡単かつ迅速に行えるようにしました。 したがって、開発者として、数百のプロジェクションから選択できます。 同時に、データの地理的表現から幾何学的な表現に切り替えるために必要なすべての式を記憶する必要はありません。
これは非常に優れた作業ツールです。 旅行仲間を検索するためのWebアプリケーションを開発していたとき、「Gimme」、gem、およびサービスは、開発時間を大幅に短縮するのに役立ちました。 空間データをいかに簡単かつ迅速に操作できるか想像できませんでした。