興味深い質問に+1。これは間違いなくプログラミング設計の問題ですが、ほぼ UX の問題でもあります。
ひとつのフィールドですべてができると思います。私は住所を解析して処理するSmartyStreetsで働いています。あなたの質問に関連して、私が経験から学んだいくつかのことを次に示します。
- アドレスの解析や特定に正規表現を使用しないでください。複雑すぎます。マテジが言ったように、アドレスにはさまざまな形式があります。「フリーフォーム文字列」は何でもかまいません。誘惑は正規表現を使用することですが、よりスマートな方法があります。
- 少なくともその TOS によると、探している値と結果を実際に提供する場所/住所 API はほとんどありません。たとえば、Google、Yahoo!、およびその他のサービスでは、マップを表示する必要があり、自動クエリを許可していません (たとえば、ユーザーが積極的にリクエストを開始することはありません)。
- ほとんどの API はアドレスの概算のみを実行し、アドレスの検証は実行しません。したがって、得られる結果はせいぜい推測です。Google は推測に長けていますが、正当に見える結果が実際には正しくない結果を返す場合があります。私はこれをたくさん見てきましたが、私は噛まれました。Geolocation/geocoding API には適切な場所がありますが、制限もあります。
たとえば、ユーザーがそのテキスト フィールドに POI または住所を入力します。それがどちらなのか、それとも両方なのかはわかりません。知っていた場合、その POI または住所は存在しますか? 両方を同時に実行する (安価な) API を私は知りません。私が見たエンタープライズ レベルの API はありますが、おそらく多額の費用がかかりすぎるでしょう。これが私が試すより簡単なアプローチです。
アドレスを確認する CASS 認定サービスを検索します。SmartyStreets のLiveAddress API (ホームページの別のデモ) は、そのようなサービスの 1 つです (安価で、少量の使用では無料です)。API は単一行のアドレスを直接解析しませんが、このアルゴリズムを使用するのは非常に簡単です(実際の例はこちら)。Javascript のように JSONP をいじる必要がないため、Objective C ではさらに簡単です。 .
LiveAddress または同等のサービス (調査を行うことをお勧めします。さらに質問がある場合はお知らせください。喜んでお手伝いします) が結果を返した場合、文字列は住所でした。CASS 認定サービスの中には、偽のアドレスや推測を返すものもあることに注意してください。この 2 つを区別することは困難/不可能です。LiveAddress は有効なアドレスのみを返します。そのため、LiveAddress が結果 (通常は上記のアルゴリズムを使用した最初の結果) を返す場合、文字列は間違いなく住所、または POI の後に住所が続きます。(もちろん、LiveAddress は各住所をジオコーディングします。)
結果が返されなかった場合は、POI/お店の名前です。アプリが Google または Yahoo の TOS に準拠している場合は、それらの API にクエリを実行します。これらの API は、そのようなものでより一般的な一致を推測して見つけるのが得意だからです。
別のオプションとして、最初に Maps API にクエリを実行し、返されたアドレス (存在する場合) を LiveAddress 経由で送信して、そのアドレスが存在することを確認し、詳細を確認することもできます。
それがあなたを正しい方向に向けることを願っています(しゃれは意図されていません)。何か説明が必要な場合や、住所に関するその他の質問がある場合はお知らせください。