適当に乱数で作った8地点と、UTM/MGRS的にヤバそうな地点のフチの部分。数が少ないのであんまりテストデータには向かないかも。
データは以下の構造体に入ってる。
typedef struct Position_data
{
struct
{
double latitude;
double longitude;
double height;
} LLH;
struct
{
double x;
double y;
double z;
} ECEF;
const char *const MGRS;
// if MGRS is null, UTM is invalid
struct
{
uint8_t zone_lon;
bool is_north_side;
double east;
double north;
} UTM;
} Position_data;
LLHはLatLonが度単位、heightがメートル単位、ECEFはすべてメートル、MGRSはdigit10(5:5)でゾーンはゼロ埋め、UTMは1メートル分解能。
MGRSは文字リテラルへのポインタだが、UTM/MGRSに変換できない地域(北緯84度以上の北極周辺と南緯80度以上の南極周辺)の場合はMGRSにヌルポインタがセットされる。
LLHとECEFの変換には以下のサイトを使った。
Latitude/Longitude/Height <--> ECEF via J-Script BLH
LLHとUTM/MGRSの変換には以下のサイトを使った。
Convert between Latitude/Longitude & UTM coordinates
とりあえずLLHとECEFは「GPSのための実用プログラミング」という本のソースコードを参考にしたプログラムでチェックしている。LLHとUTMはwikipediaの式を参考にしたプログラムでチェックしている。UTMとMGRSは上記リンクのJavaScriptコードを参考にしたプログラムでチェックしている。
この本のプログラムでは、ECEF→LLHで、sqrt(x*x+y*y)<1の条件の際にheightの値が不正になる不具合がある(正確には、sqrtが数十cmを下回ると急速にheightのエラーが大きくなる)。某F氏が作者の承諾を得てC++に移植したコードでもそのまま残ってる気がする(未確認)。
上記LLH-ECEF変換のサイトのJavaScriptコードを見てみると、sqrt(x*x+y*y)が一定以下の場合は特殊な処理を行っているらしい。とりあえずsqrt(x*x+y*y)<1e0の場合はheight = fabs(z) - a * (1 - f)で対応した。
データセットでは(0オリジンで)2番めがx=1程度になるようにしている。3番目と4番目は地軸直上のそれぞれ北極側、南極側にしている。データセット2をPASSして3でFAILするならこの部分の問題がある。
UTM/MGRSではノルウェー南西付近とノルウェー領スヴァールバル諸島の付近に特殊な処理をしている。データセットの内10セットはこの地域の経度方向の区切り付近のデータになっている。
日本で位置情報を扱う国土地理院としては、災害時の地図情報としてMGRSを使いたいらしい。ただし、なぜかMGRSとは言わず、UTMと言っている。「昔はUTMを使っていたから、MGRSもUTMと言い張る」みたいな理論らしい。ミリタリーと名の付くものを嫌ったのか? とにかく、諸外国のUTMと地理院のUTMは別物なので要注意。
地理院が防災・災害時にMGRSを使いたがっている割には、MGRSの計算方法とかの情報が極めて少ない。今回一番参考になったのはwikipediaの計算式と先のリンクのJavaScriptコードだった。大丈夫か国土地理院(地理院のWebサイトにあるPDFにUTM変換のJavaScriptコードが有るんだけど、非常にわかりずらい)。
/***
最近、何もやる気でないけど、何もしないには暇すぎる、という状況。ということで暇つぶしに位置座標関係のソースコードを書いたりしてる。
JSF++のコーディングルールを意識したコードを書いて、CppUnitでテストしている。TDDという程じゃないが。
CppUnitはかなり使いづらい。基本的にCPPUNIT_ASSERT_EQUALを使って、多重定義で各種の型に対応しているようだが、例えばuint8_tを渡すと文字として処理される。結果、FAILすると期待値や結果がASCIIで表示される。期待値や結果が2とか8だったりすると、文字としては何も表示されない。わけがわからない。
他にも、const char*と別のconst char*を渡すと、常にFAILする。これは「ポインタが渡されたんだな！よし、ポインタを比較するぞ！。別のアドレスを指しているな？FAILだ!!」みたいなことらしい。文字リテラルと文字リテラル同士の比較なら文字列として比較されるが、そんなもんはテストする意味ない。結局、trueと0 == strcmp(expected, actual)の比較を行うしか無い。ただし、boolの比較の場合、trueとfalseの表示ではなく、0と1で表示される。わけがわからないよ。
テストと並行して開発していくと、コーディングよりもテストケースを作るほうがはるかに時間がかかる。コーディングのほうが時間がかかる場合は、そもそもコード規模が大きすぎる(あるいはテストが少なすぎる)ので、プログラムとして不適切。
結果、コードの品質を保証するにはテストをするべきだが、テストケースを作る行為に非常にコストがかかる。テストをしたからと言って、テストした点以外の場所にでかい虫が隠れてる可能性もあるし。
そりゃF-35も納期伸びてコスト上がるわけだ、みたいな感想。
F-35はEO-DASで敵機や見方機の追跡、EOTSで地上目標の探知・識別、AESAで空中/地上目標の探知・識別ができるらしい。ということは、様々なデータを処理するためのソースコードが有るわけで、それについてもちゃんとテストが行われている。はず。テストデータだけでもいったいどれだけ有るのか。
F-35のソフトウェアは開発中だから、「値下げしろ」と言われれば、ソースコード開発のどこかを切るしか無い(ハードウェアの設計は大体終わってるはずで、そこでコストカットは厳しいはず)。となると、「値下げしろ」と言われて以降のソースコードは、結構ヤバイのかも知れない。
JSF++を読んでると、コード例で<LM_string.h>というヘッダがインクルードされてる。おそらくロッキード・マーティンが作成した文字列処理に関するライブラリなのだろう。こういうレベルから作っていくんだから、防衛装備品は大変だなぁ、と思う次第。
例えばJSF++ではstdio.hは使用が禁止されている。他にも時間処理系のライブラリも使用禁止。そういうのを全部作らなきゃいけないんだから、大変だよなぁ。
***/
データセットは500行くらい有るので以下。
