2007/03/23
ここギコ！さんから、ロカポの変更案を頂きました
ここギコ！さんから、ロカポの桁数を変更してより計算しやすく、という案を出して頂いている。
現在のロカポのチャンクを
[A-Z][A-Z][0-9] ⇒ [A-X][A-Y][0-9] などにするという案です。
まずメリットとしては、最初の文字がA-Xまでに２４に分割できるので、経度方向では15度となりタイムゾーンとほぼ一致させることができる。というもの。また、ローカルコードが度で割る場合に非常に割り切りやすい数字となるので、緯度経度との相互変換が暗算できる可能性がある。
もともとロカポは緯度経度を使わない、使わない人向けなので、緯度経度との割り切りやすさは、プライオリティは高くない。もっともGISをやっている人たちにとっては緯度経度は重要ですし、
私を含めプログラムをする人間からすると、割り切れる数字でないと、計算を繰り返したときの丸め処理や小数点の精度の制限で、エンコード⇒デコードでもとの値がらずれる場合もあったりして、13の倍数なんかよりは５の倍数や１２の倍数の方がなにかとやりやすいのは確かです。
でも一般の人には統計135度の明石天文台より西か東か、というのはやはり「緯度経度は難しい」を超えられないと思う。
また、WGS84をベースにするロカポだが、他の測地系に変換したり、XYZの3次元直交座標を使ったり、度ではなくラジアンで表したりする場合もあるので、計算のしやすさの重要性はあまり高くないと思います。
ただし、一つ素晴らしい点がある。それは、2地点のロカポ（エリアコード）を聞いただけで、およその時差までも分かるということ。
特に海外旅行などで、目的地のロカポだけで時差が分かる！
まさに「普段緯度経度を使わない人から見た直感的な分かりやすさ」を追求しているロカポの方向性にぴったりである。
つまり、24で割るのは緯度経度との整合というよりは「時差」というより一般の人の感覚とマッチする。これはすばらしい。
問題点は、まずは下位互換性。現在のロカポ（実はバージョン２ですが）と同じコードで互換性が無くなるのはまずい。わずかとはいえ、すでに使って頂いている方がいますし、将来Googleのキャッシュなどで古い仕様が出てきてそれを参考にされた方が場所を間違うというのは避ける必要がある。海外ので見ていただいていて、私からコンタクトできない人もいる。早い話、この時代は一旦ネットにアップしたものはなかなか変えにくい。
区切り文字をピリオド以外にするとか、何かフォーマット変えて対応する必要があるかもしれません。
例えば現行の
AA0.AA0.AA0.AA0
を
AA0-AA0-AA0-AA0
とか
AA0.AA0-AA0.AA0
とか
AA0-AA0.AA0-AA0
とか
うーん、、、、、、どうしよう、、、、
また、もともとロカポは「数字といえば０～９」「アルファベットといえばAからZ」という既成概念みたいなものを踏み台にしているので、
桁によってXまでだったりYまでだったりすると、繰り上がりの際の連続性をイメージしにくいかもしれない。
たとえば
例えばグリニッジ（経度０）をはさんで西から東へ移動していくと、
***.MZ9.***.ZZ8
***.MZ9.***.ZZ9
***.NA0.***.AA0 <--0度
***.NA0.***.AA1
***.NA0.***.AA2
だったのが[A-X][A-Y][0-9]のフォーマットを導入すると
***.LMY9.***.XY8
***.LY9.***.XY9
***.MA0.***.AA0 <--0度
***.MA0.***.AA1
***.MA0.***.AA2
となってしまう。
9999の次が10000みたいな感じでZZ9のZと9を「最後の文字」みたいなイメージで使っているので、
もしXとかYまでにするのだったら、「最後はX」みたいに全桁同じフォーマットにする必要がある。
もしくは、エリアコードの１桁目なんて、実際にはほとんど使わないし、桁上がりには(日付変更線越え以外は)関係ないので、一桁目だけXまでとするのが直感的な使いやすさとのバランスかもしれない。
つまり、
[A-X][A-Z][0-9].[A-X][A-Z][0-9].[A-Z][A-Z][0-9].[A-Z][A-Z][0-9]
にするのがいいのかも。これだと、0度超えは
***.LZ9.***.ZZ8
***.LZ9.***.ZZ9
***.MA0.***.AA0 <--0度
***.MA0.***.AA1
***.MA0.***.AA2
となる。
まだ検討は足りないが、ここギコ！さんに頂いたアイデアからいいものを取り入れるとすると
・エリアコードの先頭だけ24進法
・あとは現状のロカポのまま
とするのが一番スマートなのかもしれない。
直感的な時差把握という点は非常に気に入ったので、導入を検討してみます。
みなさんのご意見をお待ちしています。
現在のロカポのチャンクを
[A-Z][A-Z][0-9] ⇒ [A-X][A-Y][0-9] などにするという案です。
まずメリットとしては、最初の文字がA-Xまでに２４に分割できるので、経度方向では15度となりタイムゾーンとほぼ一致させることができる。というもの。また、ローカルコードが度で割る場合に非常に割り切りやすい数字となるので、緯度経度との相互変換が暗算できる可能性がある。
もともとロカポは緯度経度を使わない、使わない人向けなので、緯度経度との割り切りやすさは、プライオリティは高くない。もっともGISをやっている人たちにとっては緯度経度は重要ですし、
私を含めプログラムをする人間からすると、割り切れる数字でないと、計算を繰り返したときの丸め処理や小数点の精度の制限で、エンコード⇒デコードでもとの値がらずれる場合もあったりして、13の倍数なんかよりは５の倍数や１２の倍数の方がなにかとやりやすいのは確かです。
でも一般の人には統計135度の明石天文台より西か東か、というのはやはり「緯度経度は難しい」を超えられないと思う。
また、WGS84をベースにするロカポだが、他の測地系に変換したり、XYZの3次元直交座標を使ったり、度ではなくラジアンで表したりする場合もあるので、計算のしやすさの重要性はあまり高くないと思います。
ただし、一つ素晴らしい点がある。それは、2地点のロカポ（エリアコード）を聞いただけで、およその時差までも分かるということ。
特に海外旅行などで、目的地のロカポだけで時差が分かる！
まさに「普段緯度経度を使わない人から見た直感的な分かりやすさ」を追求しているロカポの方向性にぴったりである。
つまり、24で割るのは緯度経度との整合というよりは「時差」というより一般の人の感覚とマッチする。これはすばらしい。
問題点は、まずは下位互換性。現在のロカポ（実はバージョン２ですが）と同じコードで互換性が無くなるのはまずい。わずかとはいえ、すでに使って頂いている方がいますし、将来Googleのキャッシュなどで古い仕様が出てきてそれを参考にされた方が場所を間違うというのは避ける必要がある。海外ので見ていただいていて、私からコンタクトできない人もいる。早い話、この時代は一旦ネットにアップしたものはなかなか変えにくい。
区切り文字をピリオド以外にするとか、何かフォーマット変えて対応する必要があるかもしれません。
例えば現行の
AA0.AA0.AA0.AA0
を
AA0-AA0-AA0-AA0
とか
AA0.AA0-AA0.AA0
とか
AA0-AA0.AA0-AA0
とか
うーん、、、、、、どうしよう、、、、
また、もともとロカポは「数字といえば０～９」「アルファベットといえばAからZ」という既成概念みたいなものを踏み台にしているので、
桁によってXまでだったりYまでだったりすると、繰り上がりの際の連続性をイメージしにくいかもしれない。
たとえば
例えばグリニッジ（経度０）をはさんで西から東へ移動していくと、
***.MZ9.***.ZZ8
***.MZ9.***.ZZ9
***.NA0.***.AA0 <--0度
***.NA0.***.AA1
***.NA0.***.AA2
だったのが[A-X][A-Y][0-9]のフォーマットを導入すると
***.LMY9.***.XY8
***.LY9.***.XY9
***.MA0.***.AA0 <--0度
***.MA0.***.AA1
***.MA0.***.AA2
となってしまう。
9999の次が10000みたいな感じでZZ9のZと9を「最後の文字」みたいなイメージで使っているので、
もしXとかYまでにするのだったら、「最後はX」みたいに全桁同じフォーマットにする必要がある。
もしくは、エリアコードの１桁目なんて、実際にはほとんど使わないし、桁上がりには(日付変更線越え以外は)関係ないので、一桁目だけXまでとするのが直感的な使いやすさとのバランスかもしれない。
つまり、
[A-X][A-Z][0-9].[A-X][A-Z][0-9].[A-Z][A-Z][0-9].[A-Z][A-Z][0-9]
にするのがいいのかも。これだと、0度超えは
***.LZ9.***.ZZ8
***.LZ9.***.ZZ9
***.MA0.***.AA0 <--0度
***.MA0.***.AA1
***.MA0.***.AA2
となる。
まだ検討は足りないが、ここギコ！さんに頂いたアイデアからいいものを取り入れるとすると
・エリアコードの先頭だけ24進法
・あとは現状のロカポのまま
とするのが一番スマートなのかもしれない。
直感的な時差把握という点は非常に気に入ったので、導入を検討してみます。
みなさんのご意見をお待ちしています。
# posted by Nao : 14:56
