サービスエリアの定義方法-郵便番号を使用して？
私は在宅サービスのサイトに取り組んでいます。サービスプロバイダーのサービスエリアを定義するためのベストプラクティスは何ですか？
私の最初の考えは、各プロバイダーのサービスエリアを一連の郵便番号として定義することでした。お客様がサービスをリクエストした場合、郵便番号が一致するプロバイダーを検索するだけです-簡単です。少し調べてみましたが、正確に動作することを確信しています。正確な郵便番号データベースが見つかれば、私が見つけた最高のデータベースはコストがかかるので、この郵便番号の試みに着手する前に、このタスクを達成するためのより良い方法がないことを確認したいと思います。
たとえば、「サービスエリア」を定義するように要求するために使用される「Googleビジネスリスティング」。 Googleはどのようにしてこのデータを緯度と経度の座標ボックスまたは円として保存しましたか？
「サービス提供地域」を定義して保存し、それをリクエストに一致させるこのプロセスは当たり前のようです–では、このプロセスの今日のベストプラクティスは何ですか？
サービスプロバイダーがサービスエリアで何を意味するかを定義する必要があります。取得する具体的な内容に応じて、いくつかの方法があります。
簡単なものから難しいものまで、いくつかのオプションがあります：
- サービスセンターの緯度/経度と半径。つまり34.1234、-81.2235から20マイル。これは定義上、楕円です（緯度と経度は地上では同じ比率で増加しません）。
- 地域を指定する地理的ポリゴン（Zillowのように）。
- 隣接する郵便番号から地理的なポリゴンへの不正確なマッピング。データベースがそのマッピングを実行する必要があります
したがって、サービスプロバイダーがサービスエリアを定義する方法の観点から、サービスエリアについて考える必要があります。サービスプロバイダーがXマイルを進んで移動する場合は、最初のオプションで十分です。サービスプロバイダーが特定のエリアを念頭に置いている場合、そのエリアを地図上に描画し、それをサービスエリアにすることができます。サービスプロバイダーが郵便番号X、Y、およびZにサービスを提供すると言った場合、それらの郵便番号から境界ポリゴンを生成する必要がある場合があります。
単純なradiusクエリは、地理空間サポートを備えたデータベースで行うのはかなり簡単です。他のすべてのオプションでは、データベースに格納されたポリゴンが必要です。そのクエリを最適化するには、最初に、交差する境界ボックスがないすべてのレコードを除外します。地理空間ポリゴンの実行には時間がかかるため、通常、境界ボックスをすばやく事前チェックすると、クエリのパフォーマンスがはるかに速くなります。
ほとんどの場合、最初のオプションを使用して簡単に実装できますが、特定の場所に到達するための道路が範囲外になるいくつかのEdgeケースが発生する場合があります。
これを「ベスト」にする方法は、「ベスト」をどのように定義するかに大きく依存します。
郵便番号は、ストレージとルックアップの単純化にはおそらく最適ですが、サービスの起点（プロバイダーのオフィスなど）からの実際の距離や権限の境界（プロバイダーにライセンスがある場合は州の境界など）を説明できないため、最適ではありません。特定の状態で作業するため）およびブラックアウトエリア（たとえば、特定の道路または近所がある場合、プロバイダーは何らかの理由で作業を拒否します）。
したがって、短期的にはおそらくzipから始めることもできますが、地理空間クエリをサポートするデータベースに成長して、後でより詳細な到達圏オプションを追加できるようにする予定です。