GIS 緯度経度 地域メッシュ変換 小数点の計算が合わない

Question

緯度経度から、標準地域メッシュの変換プログラムを書いています。
おおむね正しく判定できるのですが、メッシュ境界にある座標を判定するとき、違うメッシュＩDになることがあります。

何が原因だろうと思ってよく見るとそもそも統計局の説明と、掛け算や剰余の小数部分が合わない…
該当部分が下記です。

lat=Decimal(lat)
lon=Decimal(lon)
p=(latDecimal('60'))/Decimal('40')
a=(latDecimal('60'))/Decimal('40')

手計算でも、pythonでも、35.70078×60=2142.048　になるのですが、
統計局の資料では、2142.04667になっています。

すみません、どなたかGISに詳しい方ご教授いただけないでしょうか。

※私の書いたコードは、下記のツールとは同じ結果が出ます。
https://maps.multisoup.co.jp/exsample/mesh/mesh_search.html

Comments

[退会済みユーザー]

35.7008ってなんですか？ 単位とか。小数点以下が普通に十進数なのか、度分秒なのか。

[Satomi07]

すみません、修正しました35.70078は、日本測地系から十進法に修正した緯度です。
自分で気が付いたのですが、
総務省統計局の計算の一行目、35.7007777になりますよね…
これを丸めないまま35.7007777*60にすると、値が2141.046662となり、丸めると2141.04667になるのかなと…。

[Satomi07]

依頼者と丸め方が違うから、異なるデータが出たと言うことでしょうか…。

[退会済みユーザー]

変なところで丸めると誤差が出やすいので、自前でやらず有名所のライブラリに任せたほうが健全かもしれない。

Answer 1

丸め方だな。

以下、Python知らないんでPHPでさらっと計算してるんだが、

35+(42/60)+(2.8/3600) = 35.700777777778

ってのを念頭に、

(35+(42/60)+(2.8/3600))*60 = 2142.0466666667

((35+(42/60)+(2.8/3600))*60)/40 = 53.551166666667

((35+(42/60)+(2.8/3600))*60)/40 - 53 = 0.55116666666667

(((35+(42/60)+(2.8/3600))*60)/40 - 53)*40 = 22.046666666667

ってことかと。

Comments

[Satomi07]

依頼者からもらう緯度経度が、そもそも世界測地系で小数点5桁ですでに丸められている場合、こちらで合わせるってできるんでしょうか？

先方から精度の高い値をもらうか、正解データをもらうほうが早いでしょうか。

[退会済みユーザー]

667みたいな終わり方なら、計算の過程として6666666667みたいに桁を足してあげてもいいかもしれない。

[Satomi07]

かならずしも循環小数っぽい値ではないのです…。

[退会済みユーザー]

https://ja.wikipedia.org/wiki/%E5%BE%AA%E7%92%B0%E5%B0%8F%E6%95%B0#%E5%BE%AA%E7%92%B0%E7%AF%80%E3%81%AE%E6%B1%82%E3%82%81%E6%96%B9
循環節の求め方を参考にするか、あるいは転記ミスも疑われるなら先方に確認し直すか。

[Satomi07]

ありがとうございます。小数点5桁以下なのでちょっと厳しい気がします…先方に確認します。