テキストフィールドに緯度/経度を入力するための標準
ユーザーが2つのテキストフィールドに緯度と経度を入力するための標準はありますか？
10度は1回で入力できるため、おそらく最も簡単です。ジオキャッシングの標準（私たちのアプリケーションには関係ありませんが、それでも頻繁に使用されます）は、全学位と10進数の分です。そしておそらく、何人かのユーザーは度分分秒を入力したいと思うかもしれません。
テキストを解析する標準的な方法はありますか？ （例：「45d 15m 20.91s」）
さらに、このアプリケーションは主に北米で使用され、緯度は正（赤道の北）、経度は負（グリニッジの西）と見なされます。北度と東度の単位、または単に度の単位を表示する必要がありますか（ユーザーが南北と東西の規則を知っていると仮定します）？
もう1つの潜在的な「機能」は、米国大陸の緯度/経度および「自動修正」ユーザーの範囲を検出することです。もちろん、東南アジアのユーザーが彼らの資産が米国にあるように見える理由を疑問視するまで、それは機能します。
私は10進数で行くでしょう、そしてここに2つの例があります。
1）アプリケーションを使用してTwitterで現在地を正確に設定した場合、Twitterは緯度/経度を10進形式で出力します（iPhone：33.948615、-118.401382）
2）Googleマップで場所を共有する場合、リンクは緯度/経度で10進形式でエンコードされます http://maps.google.ca/maps?ll=43.367559、-80.980482＆spn = 0.01106,0.01869＆t = m＆z = 16＆iwloc = A＆lci = com.panoramio.all
緯度/経度のフォーマットに10進フォーマットを使用しているのは、これら2つの主要なプレーヤーだけではありません。
したがって、ユーザーが緯度/経度を知らずに検索した場合、10進形式で取得する可能性が高くなります。
10進はプログラマにとって「簡単なこと」ですが、常にユーザーを満足させるわけではありません。緯度と経度の形式には標準があります- ISO 6709 -ヒューマンインターフェイスの形式を定義します。
以下は、ISO 6709フォーマットの抜粋[from Wikipedia ]です。
- 座標値（緯度、経度、高度）はスペースで区切る必要があります。
- 小数点は値の一部であるため、通常はオペレーティングシステムで設定する必要があります。
- 複数の点は複数の線で表されます。
- 緯度と経度は、6進法の分数で表示する必要があります（つまり、分と秒）。
- 分と秒が10未満の場合は、先行ゼロを表示する必要があります。
- 度、分、秒の後には、記号°（U + 00B0）、 '（U + 0027）、および "（U + 0022）を使用し、数字と記号の間にスペースを入れないでください。
- 北と南の緯度は、数字の直後に続くNとSで示されます。
- 東と西の経度は、数字の直後に続くEとWで示す必要があります。
仮定は危険です。ユーザーがxxxxから緯度/経度を取得する可能性が最も高いと言うのは、VERY BADの仮定です。 GPSデバイスの緯度/経度の表示/入力オプションを確認します。ほとんどが次の形式をサポートしています。
- DD.DDDDDD
- DD MM.MMMM
- DD MM SS.SS
IOS/OS Xは、上記のLat/Long形式を処理するために簡単にカスタマイズできる非常に強力なコンバータークラスを提供します。
NSScanner-ユーザー入力（NSString）を度（double）に変換する
NSFormatter-度（double）から文字列に変換します。
さまざまなWebおよびアプリマッピングUIを扱ってきたので、入力に小数度を使用することをお勧めします。ソースが代替フォーマットを提供することはますますまれです。ただし、スペースと状況が許せば、別のフォーマットに変更するオプションを提供することを検討してください。 （おそらく、ユーザーはこれをデフォルトとして設定することさえ許可されているかもしれません）。
フィールド内で定型入力を使用することをお勧めします。 00.000000。これにより、ユーザーをデフォルトのフォーマットにさらに手がかりが得られます。 （ちなみに、メーターレベルの精度を確保するには、小数点以下6桁で十分です）。
東/西または北/南を表す正または負の単位については、推奨を行うのは簡単ではありません。ある程度（おおよそ）、この領域におけるユーザーの知識に依存します。彼らは負の数が西または南を示すことに気づいているかもしれません。さらに問題を複雑にしているのは、ソースからコピーされた数値です。 Googleマップはその形式になります。 「44.463005、-110.366479」
1つの可能性は、ユーザーが変更可能なE/WおよびN/S UIを持つことです。たとえば、ユーザーが経度フィールドに負の値を入力すると、このUIは自動的に「W」に変更されます。ユーザーが正の値を入力した場合でも、手動で、たとえば自動的に「W」に変更できます。
（ユーザーが代わりに「E」を選択した場合、負の符号を削除して値を修正することは理にかなっています）。
あるいは、方向インジケーターの情報のみの側面を強制することもできます。
これは、緯度/経度の値がどのように機能するかをユーザーに示してトレーニングします。そして、それでもうまくいかない場合は、間違ったエリアが表示されたマップを表示する可能性があります。
そして、あなたが本当に派手な趣味を得たいなら：
緯度/経度の入力に関しては、すべてを統制する1つの方法を見たことはありません。また、より一般的で一般的に使用されている地理関連のサイトやWebアプリでは、両方を提供していないよりも頻繁に見ていますHDDD MM.MMおよびユーザー向けの10進オプション。
あなたのアプリが汎用アプリである場合、これは、アプリを使用するときに知っている可能性が高い、または自由に使える表記に特に重点を置いて、ペルソナを思い付くのにある程度の時間を費やす絶好の機会です。私はまた、どのような決定を下しても、A/Bテストのために潜在的なユーザーの前にワイヤーフレームを取得するのは遅かれ早かれと言うでしょう。両方のオプションに対応する必要があることがわかった場合は、その情報が必要になります。それを最後にデザインに押し込まないようにするために、できるだけ早く。
また、これが本当に明確にターゲットを絞ったアプリであり、ユーザーの知識に非常に自信がある場合を除き、ユーザーが記法に関して何を行っているか、または何を知らないかについてanyを想定しないように注意します。フォーカスグループとテストによって、適切なデータが提供されるようにします。これは、最初の仮説を証明する場合としない場合があります。