点群OBJアップロードで座標が崩れるのはなぜか
点群OBJをアップロードした際に、点群が原点付近へ集まる、形状が極端に縮小する、一部の点だけが遠方へ飛ぶ、地形が平らにつぶれるといった現象が起こることがあります。ファイルの登録処理自体は完了しているため、一見すると正常に読み込めたように見えても、座標値の一部が想定どおりに解釈されていない可能性があります。
原因候補の一つが、OBJ内に記録された科学表記です。科学表記は、大きな数値や非常に小さな数値を短く表す形式です。たとえば、123456.789は1.23456789e+05、0.00123は1.23e-03と記述できます。eの代わりに大文字のEが使われることもあります。
科学表記そのものは数値として誤りではなく、多くの数値処理系では通常の小数表記と同じ値として解釈できます。ただし、OBJ読込処理が受け付ける数値の字句形式は実装によって異なります。座標欄には数字、小数点、マイナス記号だけが入るという前提の簡易な処理では、指数を示すeやE、指数の符号を含むトークンを正しく扱えない場合があります。
たとえば、1.2345e+05という座標を指数部分まで解釈せず、eの手前までしか読み取らない実装では、本来123450である値が1.2345として扱われる可能性があります。別の実装では、その行全体を無効として読み飛ばしたり、既定値へ置き換えたりすることも考えられます。どのような崩れ方になるかは読込側の仕様によるため、表示結果だけから指数の符号が反転したなどと断定しないことが重要です。
科学表記を正しく数値化できていても、座標値が大きいことで細部が失われる場合があります。公共座標や広域の測量座標を保持した点群では、XやYが数十万から数百万の値になる一方、隣接点の差が数ミリメートルから数センチメートル程度になることがあります。
読込後の内部処理が単精度浮動小数点数など限られた有効桁数を使う場合、大きな整数部分を表現するために多くの桁が使われ、下位の小数部分が丸められます。その結果、別々の点が同じ座標へ集まり、細かな段差や凹凸が失われる可能性があります。IEEE 754の単精度形式は24ビットの仮数精度で、10進の有効桁数はおおむね6～9桁です。Oracle Docs
座標崩れには、科学表記以外の要因も関係します。OBJ形式自体は座標の標準単位を必須情報として保持しないため、作成側とアップロード先でメートル、ミリメートルなどの前提が食い違うと、点群の縮尺が変わります。単位はファイルの外部情報、コメント、変換記録、読込設定などで管理する必要があります。The Library of Congress+1
小数点記号がピリオドからカンマへ変わっていれば、座標を正しく数値化できない場合があります。半角スペースやタブの代わりに全角スペースが混入すると、頂点行として認識されないこともあります。
そのため、点群OBJアップロードで異常が発生したときは、科学表記だけを原因と決めつけないことが重要です。原本、変換後、アップロード直前、アップロード後という工程ごとに、頂点数、座標範囲、単位の前提、文字形式を確認し、どこで値が変わったのかを切り分けます。
科学表記を含むOBJで起こりやすい症状
科学表記の解釈に失敗しても、必ずエラーが表示されるとは限りません。不正な座標を既定値として扱ったり、読み取れた部分だけを数値として採用したりする実装では、アップロードは完了しても形状だけが崩れる場合があります。
代表的な症状の一つは、点群が極端に小さく見える現象です。たとえば、X座標が3.500123e+05、Y座標が3.950456e+06で記録され、読込側が指数部分を無視した場合、Xは3.500123、Yは3.950456として扱われます。本来は数十万から数百万の値を持つ座標が一桁程度になり、座標範囲が大きく変わります。
点群の一部だけが遠方へ飛ぶ場合もあります。通常の小数表記と科学表記が混在し、片方だけが誤って解釈されると、同じファイル内に異なる縮尺や位置の座標群が生じる可能性があります。
表示機能が全点を画面内へ収めるように自動調整する場合、一つの異常点が遠方にあるだけで表示範囲が大きく広がります。その結果、本体の点群が小さくなり、何も表示されていないように見えることがあります。この場合は、点群が消えたと決めつけず、座標範囲と外れ値を確認します。
高さ方向だけがつぶれる現象もあります。XとYは通常の小数表記で、Zだけ科学表記になっており、その列だけ正しく解釈されなければ、平面形状は保たれていても高さが失われる可能性があります。地形点群が一枚の板のように見えたり、構造物の立ち上がりが消えたりする場合は、側面や断面から確認します。
逆にZ座標だけが過大な値になれば、点群は縦方向へ大きく伸びます。ただし、原因は指数処理だけでなく、単位倍率、列ずれ、軸変換、異常値の混入なども考えられます。
隣接点が重なり、点密度が不均一に見えることもあります。大きな座標値を限られた精度で保持した結果、近接する複数点が同じ座標へ丸められると、点数自体は変わっていなくても画面上では点が減ったように見えます。細い部材の輪郭が消えたり、斜面が階段状になったりする場合もあります。
点群が1000倍または1000分の1程度になる場合は、科学表記だけでなく単位の前提を確認します。OBJに標準単位が埋め込まれているとは限らないため、数値1を1メートルとみなす側と1ミリメートルとみなす側が接続されれば、縮尺が大きく食い違います。
座標軸の並びが変わったときは、点群が横倒しになったり、上下が入れ替わったりします。科学表記を変換する際に列の分割を誤り、X、Y、Zの順序を変えてしまうことが原因になり得ます。元のOBJで空白とタブが混在している場合、半角スペース一つだけを区切りとして処理すると、列ずれが発生する可能性があります。
症状を正しく判定するには、表示結果だけでなく数値を確認します。変換前後のX、Y、Zについて最小値、最大値、最大値と最小値の差を比較します。さらに頂点行数を比較すれば、行の欠落や重複を確認できます。
対処法1 科学表記を固定小数点表記へ変換する
科学表記を受け付けない、または受入可否が不明なアップロード環境では、座標値を指数を使わない小数表記へ変換する方法が有効です。ここでは便宜上、1.234567e+05を123456.7のように書く形式を固定小数点表記と呼びます。
重要なのは、e以降を文字列として削除しないことです。1.234567e+05からe+05を削除すると1.234567になりますが、正しい値は123456.7です。指数部分は付加的な文字ではなく、数値の大きさを決める情報です。
正しい変換では、科学表記の文字列を数値として解釈し、その値を指定した小数桁数の通常の小数表記として書き戻します。指数が正なら小数点が右へ、指数が負なら左へ移動した値になります。
変換対象は、OBJ内の幾何頂点行へ限定するのが基本です。標準的な幾何頂点はv x y zで記述され、仕様上は任意の重みwが続く形式もあります。点群向けのOBJではwを省略した三座標の行が多いものの、4列目以降の意味を確認せずに削除または変換してはいけません。OBJには点、線、面などの要素があり、頂点はそれらから番号で参照されます。The Library of Congress
OBJの一部の運用では、X、Y、Zの後ろへ頂点色を付ける慣例もありますが、これは原仕様の必須機能ではなく、対応状況は実装ごとに異なります。変換処理では最初の三つの位置座標だけを対象とし、wや色などの追加列は、その意味を確認したうえで保持します。The Library of Congress
OBJには頂点以外の数値も含まれます。面や点要素が参照する頂点番号、法線方向、テクスチャ座標、材質に関する値などです。ファイル内のすべての数値を一律に変換すると、位置座標以外の情報まで変わる可能性があります。
科学表記には小文字のeと大文字のEがあり、指数には正負の符号が付く場合があります。書出側によっては正の指数符号を省略する形式もあり得るため、変換処理は実データに現れる形式を数値として安全に解析できる方法を使います。正規表現だけで値を組み替えるより、検証済みの数値解析機能で読み取る方が安全です。
固定小数点表記へ変換する際は、小数点以下の桁数を短くしすぎないようにします。元データをメートル相当として扱い、ミリメートル単位の差を残したい場合は、小数点以下3桁が一つの目安です。ただし、計測精度、処理系の内部精度、利用目的によって必要桁数は変わります。
桁数を過剰に増やしても、元データ以上の精度は得られません。1.23という値を1.230000000000としても、新しい測定情報が加わるわけではありません。元データの精度と用途に応じて出力桁数を決めます。
変換後は、科学表記が消えたことだけでなく、数値として同じ値を保っていることを確認します。変換前の値を数値として読み取り、変換後の値との差を計算します。差が設定した丸め幅の範囲内であれば、少なくとも表記変換による変化は管理できます。
確認には、先頭の数行だけでなく、座標の最大値、最小値、負の値、正負の指数を持つ値を含めます。先頭部分が正常でも、ファイルの途中に異なる形式が含まれている場合があります。
対処法2 大きな座標値をローカル座標化する
科学表記を通常の小数表記へ変えても細かな形状が崩れる場合は、大きな絶対座標を読込後の処理が十分な精度で保持できていない可能性を確認します。この問題には、点群全体から共通の基準値を差し引き、原点付近へ移動するローカル座標化が有効な場合があります。
たとえば、X座標が350000前後、Y座標が3950000前後で、計測範囲が数十メートル程度の点群を考えます。この点群では、座標の上位桁は多くの点で共通し、実際の形状は下位の桁に表れます。
X座標が350012.345と350012.346であれば、二点の差は0.001です。値をメートル相当として扱うなら1ミリメートルの差です。しかし、大きな座標値を十分な有効桁数で保持できない処理では、この差が丸められ、二点が同じ位置になる可能性があります。
Xから350000、Yから3950000、Zから50を差し引けば、元の座標がX350012.345、Y3950025.678、Z52.100である点は、X12.345、Y25.678、Z2.100になります。
wを省略した通常の三次元座標、またはwが1.0として扱われるデータで、すべての点から軸ごとに同じ値を差し引けば、数学上は点同士の距離、角度、形状を保ったまま平行移動できます。ただし、変換時の丸めや読込後の精度によって微小な差が生じる可能性はあります。wが1.0以外の同次座標を使うOBJでは、単純にX、Y、Zだけを変更せず、仕様と出力元の意味を確認します。
座標値を小さくすると、限られた有効桁数の内部処理で下位桁を保持しやすくなる場合があります。また、書出側の数値書式によっては、大きな値より通常の小数表記で出力されやすくなります。ただし、科学表記を使うかどうかは書出設定によるため、ローカル座標化だけで科学表記が必ず消えるわけではありません。
差し引いたオフセット値を記録しなければ、元の座標へ戻せません。X、Y、Zの各軸から何を差し引いたかを明確に残します。座標参照系、水平単位、高さ単位、高さの基準も併せて管理することが重要です。
ローカル原点には、点群の最小座標を使う方法と、切りのよい基準値を使う方法があります。最小Xが349987.432であっても、349900や350000を基準にできます。管理や復元を考えると、説明しやすく、現場内で共通利用できる値を選ぶ方が運用しやすい場合があります。
複数の点群を重ねる場合は、ファイルごとに別のオフセットを使わないようにします。点群ごとの最小値を原点にすると、単体では正常に見えても、複数時期のデータを重ねたときに位置が合いません。同じ現場や工区では共通のローカル原点を使用します。
ローカル座標化後は、変換前後の座標範囲を比較します。Xの最大値から最小値を引いた幅、Yの奥行き、Zの高さは、一定値を差し引くだけなら丸め誤差を除いて変わりません。
点群の幅が大きく変化している場合は、オフセット以外の処理が混入しています。特定の軸だけ範囲が変わっているなら、軸ごとに異なる倍率が適用された可能性があります。
元の絶対座標へ戻す場合は、差し引いたオフセットを同じ軸へ加えます。X用の値をYへ加える、Zだけ符号を反対にするといったミスを防ぐため、変換式を軸名付きで記録します。
対処法3 有効桁数と座標単位を統一する
科学表記を通常の小数表記へ変換する際は、小数点以下の桁数だけでなく、数値全体の有効桁数を考える必要があります。有効桁数が不足すると、アップロードには成功しても、点群の細部が失われます。
たとえば、値をメートル相当として扱う12.345という座標では、小数点以下3桁が1ミリメートルに相当します。12.35へ四捨五入すると、元の値との差は0.005メートル、すなわち5ミリメートルです。用途によっては無視できない差になります。
地形の概略表示であれば影響が小さい場合もありますが、断面比較、変位確認、構造物の位置確認などでは必要な許容差を先に決める必要があります。点群を何に利用するのかを明確にしたうえで、必要な桁数を設定します。
一方、350012.345678のような大きな座標では、整数部分だけで多くの有効桁を使います。テキスト上で小数点以下6桁が残っていても、読込後の内部計算が単精度であれば、そのすべてが保持されるとは限りません。単精度と倍精度では保持できる有効桁数が異なるため、アップロード先の仕様や実測による検証が必要です。Oracle Docs
このため、大きな座標値を扱う場合は、小数点以下の桁数を増やすだけでは不十分なことがあります。ローカル座標化によって整数部分を短くし、必要な小数部分を保持しやすくする方法を組み合わせます。
座標単位も運用上統一します。ただし、OBJ形式自体に標準単位が必ず記録されるわけではありません。元データの作成条件、変換仕様、アップロード先の設定を確認し、数値をメートル相当として扱うのか、ミリメートル相当として扱うのかを記録します。
メートル相当で0.001は1ミリメートルですが、ミリメートル相当で0.001は0.001ミリメートルです。単位の前提を確認せずに小数点以下の桁数だけを決めると、必要以上に長い数値を出力したり、必要な精度を失ったりします。
元データをメートル相当で作成し、アップロード先が数値をミリメートル相当として受け取る仕様で、読込時の倍率設定がない場合は、位置座標を1000倍する変換が必要になることがあります。X、Y、Zのすべてへ同じ倍率を適用しなければ、縦横比が崩れます。
ただし、OBJ内のすべての数値を1000倍してはいけません。面や点要素が参照する頂点番号、法線方向、色、テクスチャ座標などは、位置座標と同じ単位変換の対象ではありません。対象となる行と列を限定します。
丸め方法も統一する必要があります。担当者によって四捨五入、切り捨て、切り上げが異なると、同じ原本から別の座標が生成されます。再現性を保つため、出力桁数と丸め方法を共通ルールとして決めます。
同じOBJを何度も変換することも避けます。科学表記から通常の小数表記への変換、単位変換、ローカル座標化を別々のファイルへ順番に適用すると、そのたびに丸めが入り、誤差が累積する可能性があります。
可能であれば、原本を十分な精度で数値として読み込み、表記変換、単位変更、原点移動を一つの工程で行い、最終的なアップロード用OBJを書き出します。再変換が必要な場合も、前回の変換済みファイルではなく原本から作り直します。
対処法4 区切り文字と文字コードを整える
科学表記を正しく通常の小数表記へ変換しても、区切り文字や文字コードに問題があれば、座標は正しく読み込まれません。OBJは行単位のテキスト形式であり、数値の周辺にある文字も読込結果へ影響します。
一般的な頂点行では、行頭のvとX、Y、ZをASCII互換の空白文字で区切ります。実務では半角スペースやタブが使われます。文書編集や手作業の修正を通じて全角スペースが混入すると、読込側が区切りとして認識できない場合があります。
人の目には同じ空白に見えても、半角スペース、タブ、全角スペースは別の文字です。vとX座標の間が全角スペースになっていると、行全体が頂点として扱われない可能性があります。
変換時には、半角スペースやタブの連続を区切りとして読み取り、出力時には半角スペース一つへ統一すると互換性を高めやすくなります。ただし、コメントや名称の空白まで一律に変更せず、対象を構造化された行へ限定します。
小数点記号にも注意します。OBJの数値はピリオドを小数点として出力するのが一般的です。地域設定の影響を受ける表計算処理や独自変換を経由すると、123.456が123,456へ変更されることがあります。
カンマを小数点として使用した値は、読込側で数値として受理されなかったり、別の意味に解釈されたりする可能性があります。座標値の小数点はピリオドへ統一します。
大きな数値を読みやすくする目的で、123,456.789のような桁区切りを付けることも避けます。OBJの位置座標は123456.789のように、桁区切りなしで記録します。
マイナス記号も確認します。半角のハイフンマイナスに見えても、文書向けの処理を経由すると、長いダッシュや全角記号へ置き換わることがあります。この場合、負の数値として認識されず、座標行が無効になる可能性があります。
固定小数点表記へ統一した後は、正の座標へプラス記号を付ける必要は通常ありません。ただし、既存ファイルの記号を機械的に全削除するのではなく、数値として解釈して再出力します。
UTF-8のBOMがファイル先頭に付くと、対応していない処理では最初のキーワードの前に不可視文字があるように見え、先頭行だけ認識されない可能性があります。BOMはUTF-8では必須ではなく、アプリケーションによって付与や扱いが異なります。W3C
改行形式の混在は多くの読込処理で扱えますが、すべての独自実装が同じとは限りません。先頭、中間、末尾の行数や頂点数が変わる場合は、改行コード、行継続、末尾の欠落を確認し、出力時の改行形式を一つへ統一します。
変換後のOBJは、文字装飾や自動整形を行わないテキスト処理で保存します。文書作成を目的とした編集環境では、引用符、空白、マイナス記号、改行などが自動的に置換されることがあります。
アップロード前には、頂点行の最初の三座標に使用されている文字を確認します。通常の小数表記へ統一した場合、数字、ピリオド、半角マイナス記号、必要に応じた半角プラス記号、半角スペースやタブ以外が混入していないかを確認します。wや頂点色など追加列がある場合は、その列を別の規則で検証します。
対処法5 アップロード前後の検証を標準化する
科学表記による座標崩れを防ぐには、変換処理だけでなく、検証手順を標準化する必要があります。変換前、変換後、アップロード後の三段階で数値と形状を確認します。
最初の確認項目は頂点行数です。OBJではvから始まる行が幾何頂点を定義します。ただし、v行数は頂点数であり、必ずしも画面に表示される点数と同じではありません。OBJには点を表すp、線を表すl、面を表すfなどの要素があり、未参照頂点を点として表示するかどうかは読込側に依存します。The Library of Congress
原本と変換後のv行数を比較し、同じであることを確認します。変換後に頂点数が減っている場合は、科学表記や負の座標を含む行が変換に失敗し、削除された可能性があります。頂点数が増えている場合は、改行や行分割の処理によって一つの頂点が複数行になった可能性があります。
次に、X、Y、Zごとの最小値と最大値を確認します。通常の小数表記へ変更しただけなら、変換前後の値は設定した丸め幅の範囲で一致します。それを超えて大きく変わっていれば、指数の解釈、列位置、単位倍率などに問題があります。
ローカル座標化を行った場合は、絶対値だけでなく座標範囲を比較します。Xの最大値から最小値を引いた幅、Yの奥行き、Zの高さは、一定値を差し引いただけなら丸め誤差を除いて変わりません。
単位変換を行った場合は、予定した倍率になっているかを確認します。メートル相当からミリメートル相当へ数値を変更したなら、各軸の座標範囲は1000倍になります。一つの軸だけ倍率が違う場合は、列の指定を誤っている可能性があります。
通常の小数表記へ統一する方針であれば、頂点行の最初の三座標にeまたはEが残っていないかを確認します。コメント、オブジェクト名、材質名などに含まれる文字まで対象にすると誤判定するため、座標列に限定します。
数値として扱えない値が含まれていないかも確認します。変換に失敗したとき、空欄、NaN、Infinityなどの値が書き込まれる場合があります。一つの異常値でも、表示範囲や後段の点群処理へ影響する可能性があります。
外れ値の確認も重要です。各軸の代表的な範囲から大きく離れた点を抽出すれば、指数の解釈、列ずれ、単位倍率などの問題で遠方へ飛んだ点を発見しやすくなります。ただし、実際の孤立点や測量ノイズもあるため、機械的に削除せず原本と照合します。
大容量のOBJを本番環境へ直接アップロードする前に、代表的な範囲を含む試験用OBJを使用します。正の座標、負の座標、大きな値、小さな値、高低差がある部分、追加列がある行を含めると、変換条件の不足を確認しやすくなります。
試験アップロードでは、表示できるかどうかだけでなく、既知の二点間距離や高さを測ります。見た目が似ていても、単位や軸の解釈が異なれば距離は一致しません。
本番アップロード後も、代表距離、全体寸法、座標値または基準点との位置関係、高低差を確認します。アップロード前のOBJが正常でも、読込側の内部処理で座標が丸められる場合があるためです。
検証結果には、頂点数、各軸の最小値と最大値、座標範囲、単位の前提、オフセット、代表距離を記録します。正常だったという結論だけでなく、どの数値を確認したかを残すことが再発防止につながります。
OBJの構造を確認して座標以外の情報を守る
OBJを安全に変換するには、ファイル内のすべての数値が位置座標ではないことを理解しておく必要があります。
幾何頂点行は、一般にvに続いてX、Y、Zの三つの値が並び、仕様上は任意のwが続くことがあります。点群向けの読込環境ではv行を点として扱う場合がありますが、OBJには点要素を示すp行もあり、未参照頂点の表示可否は実装によって異なります。
OBJには、点、線、面を構成する頂点番号、法線方向、テクスチャ座標、グループ情報、コメントなどが含まれる場合があります。ファイル全体の数値を一括で通常の小数表記へ変えたり、1000倍したりすると、位置座標以外の情報まで変わります。
面や点要素に記録された整数は、多くの場合、座標ではなく頂点への参照番号です。これを単位変換の対象にすると、存在しない頂点を参照するなどして形状が壊れます。OBJの参照番号には正の値だけでなく負の相対参照が使われる場合もあるため、マイナス記号を一律に削除してはいけません。
法線方向を示すvnの値は、位置ではなく方向を表します。位置座標と同じオフセットを差し引く対象ではありません。単位倍率を適用する必要も通常ありません。
頂点行のX、Y、Zの後ろに頂点色が続く慣例もあります。座標だけを想定した変換処理で後ろの列を削除すると、色が失われる可能性があります。反対に、色情報まで単位変換すると、本来の色を表せなくなります。追加列がwなのか色なのか独自属性なのかは、出力元の仕様で確認します。
変換前に、行頭にどのような識別子が存在するかを確認します。位置座標として処理する行と列だけを対象にし、それ以外の行は原則としてそのまま書き出します。
コメント行には、座標系、オフセット、作成日時、単位の前提などが記録されていることがあります。ただし、コメントは構造化された必須メタデータではなく、読込側が利用する保証はありません。復元に必要な情報はコメントだけに依存せず、別の変換記録にも残します。
元のOBJは上書きせず、原本として保存します。変換作業用とアップロード用を分ければ、座標異常が原本にあったのか、変換中に発生したのかを比較できます。
科学表記の一括置換で避けたい失敗
科学表記を見つけた際に、一般的な検索と置換だけで修正しようとすると、座標値を大きく変えてしまう可能性があります。
最も避けたいのは、e以降を削除する処理です。1.5e+05からe+05を削除すると1.5になりますが、本来の値は150000です。
e+05をゼロへ置き換える方法も正しくありません。1.5e+05を1.500000のような文字列にしても、数値は1.5のままです。指数を数値として解釈した結果を書き出す必要があります。
プラス記号だけを削除して1.5e+05を1.5e05にする処理は、多くの数値解析系では同じ値として扱われる場合がありますが、科学表記を残したままなので、科学表記を受け付けない読込側への対策にはなりません。また、ファイル全体のプラス記号を置換すると、コメントや別の属性まで変える可能性があります。
マイナス記号を一括で削除すると、負の座標、負の指数、負の相対参照番号が正の値になります。点群の位置や縮尺だけでなく、面や点要素の参照関係まで壊れる可能性があります。
一般的な表計算ソフトへOBJを読み込んで保存し直す方法にも注意が必要です。大きな数値が自動的に科学表記へ変換されたり、保持される有効桁数が減ったり、地域設定に応じて小数点記号が変わったりする可能性があります。点数が多い場合は、行数上限や読込方法も確認する必要があります。
画面に表示された座標をコピーして戻す方法も避けます。表示欄では桁数が省略されている可能性があります。元の内部値が1.23456789e+05でも、画面には1.23e+05としか表示されない場合があります。この表示値を使うと下位桁を失います。
変換済みOBJをさらに別の形式へ変換し、再びOBJへ戻す工程も増やしすぎないようにします。変換のたびに丸め、単位解釈、軸変換が入ると、どの工程で座標が変わったのか追跡しにくくなります。
大容量の点群OBJを安全に変換する方法
点群OBJは頂点数が多く、ファイル容量が大きくなることがあります。小さなファイルで正常に動く変換方法でも、大容量OBJでは途中停止、行欠落、メモリ不足が起こる可能性があります。
ファイル全体を一度に読み込む方法では、元の文字列、分割後の列、数値化したデータ、出力用の文字列を同時に保持することがあります。そのため、ファイル容量を上回る作業メモリが必要になる場合があります。
大容量OBJを扱う場合は、一行ずつ読み込み、対象となる頂点行だけを変換しながら別のファイルへ書き出すストリーミング処理が適しています。この方法であれば、ファイル全体を同時に保持する必要がありません。
処理途中で停止した場合に、不完全なOBJを完成ファイルと誤認しない仕組みも必要です。変換中は一時的な名称で保存し、すべての行の処理と検証が完了した後に正式なファイル名へ変更します。
ファイル容量だけで変換の成否を判断しないことも重要です。科学表記を通常の小数表記へ変えると、一つの座標値を表す文字数が増え、変換後のファイル容量が大きくなることがあります。
確認すべきなのは、頂点数、各軸の座標範囲、頂点行の列数、入力行数と出力行数、ファイル末尾付近のデータが処理されているかです。可能であれば、原本と変換後のハッシュ値を記録し、どのファイルを処理したかも追跡できるようにします。
本番ファイルを変換する前に、同じ形式の一部を抽出して試験します。ただし、先頭部分だけでは科学表記の種類や座標範囲が偏ることがあります。先頭、中間、末尾、大きな座標、小さな座標、負の値、追加列を含む部分を選びます。
変換時間を短くするために桁数を減らしたり、検証を省いたりすると、後から座標異常を発見した際に再処理が必要になります。大容量であるほど、事前の小規模試験と処理後の数値確認が重要です。
アップロード後に確認すべき形状と数値
アップロード後は、点群が表示されたことだけで正常と判断しないようにします。科学表記や精度の問題は、全点が消えるのではなく、一部の軸や一部の点だけに現れることがあります。
最初に、点群全体の幅、奥行き、高さを確認します。元の計測対象と比べて、極端に大きい、小さい、薄い、細長いといった異常がないかを見ます。
次に、座標値または既知の基準点との位置関係を確認します。画面中央や原点付近に見えるという表示上の印象だけでは判定できません。ビューアーが自動的にモデルを中央へ寄せたり、表示用の原点を変更したりしても、元の座標値が保持されている場合があるためです。座標の読取値、基準点、既知のオフセットを使って確認します。
ローカル座標化した場合は、意図したオフセットが適用され、記録した式で元座標へ復元できることを確認します。ローカル座標化していない場合は、アップロード先が絶対座標を保持する仕様か、表示時だけ中心化する仕様かを区別します。
高さ方向は平面表示だけでは判定できません。側面や断面から確認し、既知の高低差や構造物の高さを測ります。XとYが正常でも、Zだけ誤っている場合があります。
代表距離は複数方向で確認します。X方向を主とする距離、Y方向を主とする距離、高さを含む距離をそれぞれ測ります。一つの距離だけが正常でも、別の軸に異常が残っている可能性があります。
点密度にも注目します。複数の点が丸めによって同じ座標へ集まると、細かな輪郭が消えたり、点が帯状に重なったりします。対象を拡大し、段差や端部が元データと同じ形状を保っているかを確認します。
遠方へ飛んだ点も調べます。一つの異常点があるだけで表示範囲が大きく広がり、本体が小さく見えることがあります。画面上で見つけにくい場合は、各軸の最小値と最大値、外れ値の一覧を確認します。
元データと重ね合わせられる場合は、全体位置だけでなく断面も比較します。全点が一定量だけずれている場合はオフセットの誤りが考えられます。場所によって差が変わる場合は、有効桁数、単位、軸順序、座標変換などの問題を確認します。
確認した内容は、正常または異常という結論だけでなく、点群寸法、代表距離、座標範囲、オフセット、単位の前提とともに記録します。
点群OBJの変換ルールを現場で共有する
科学表記による座標崩れを継続的に防ぐには、担当者ごとの手作業に任せず、変換と検証のルールを共有する必要があります。
まず、受領したOBJの原本を変更しない運用を決めます。原本、変換作業用、アップロード用を分けて保存します。原本には、座標参照系、単位の前提、計測範囲、作成時期などの情報をひも付けます。
次に、アップロード用OBJの数値形式を統一します。科学表記を許容するのか、通常の小数表記へ変換するのかを明確にします。複数の環境へアップロードする場合は、各環境で試験済みの形式を採用します。
通常の小数表記へ変換する場合は、単位の前提ごとの出力桁数を決めます。担当者の判断で小数桁数を変えると、同じ種類の点群でも保持される精度が異なります。
ローカル座標化する場合は、共通原点の決め方を統一します。同じ現場で計測した点群には同じオフセットを使用し、X、Y、Zのオフセット値、座標参照系、高さの基準を明確に記録します。
ファイル名には、原本か変換後か、ローカル座標か絶対座標か、単位の前提、版を判別できる情報を含めます。ただし、重要情報をファイル名だけに依存させず、変換記録にも残します。
検証項目には、頂点数、各軸の最小値と最大値、座標範囲、科学表記の残存、無効値、代表距離を含めます。p、l、f、vn、vt、追加列などを含む場合は、それらが変換前後で保持されていることも確認します。
変換履歴には、使用した原本、変換日時、出力桁数、単位倍率、オフセット、使用した変換手順、確認結果を記録します。座標崩れが発生した際に、どの工程で値が変わったのかを追跡しやすくなります。
変換担当者とは別の担当者が、アップロード後の形状や代表距離を確認する運用も有効です。変換した本人だけで確認すると、想定した形状として見てしまい、異常を見落とす可能性があります。
アップロード環境の更新や変換条件の変更があった場合は、検証用OBJで再確認します。以前は正常だった形式でも、読込実装や内部精度、表示仕様が変われば結果が変わる可能性があります。
まとめ
点群OBJアップロードで科学表記の座標が崩れる場合は、指数表記の読込だけでなく、大きな座標値、有効桁数、単位の前提、区切り文字、文字コード、OBJの構造を総合的に確認する必要があります。
対処法の一つ目は、科学表記を数値として正しく解釈し、指数を使わない通常の小数表記へ変換することです。e以降を単純に削除すると座標値の大きさが変わるため、必ず数値変換を行います。
二つ目は、大きな絶対座標から共通のオフセットを差し引き、ローカル座標化することです。限られた有効桁数の処理で点同士の細かな差を保持しやすくなる場合がありますが、元の位置へ戻すためのオフセットを必ず記録します。
三つ目は、利用目的に合った有効桁数と単位の前提を統一することです。OBJ形式自体は標準単位を必ず保持するわけではないため、作成側、変換側、読込側で数値の意味を共有します。
四つ目は、半角スペース、小数点記号、マイナス記号、文字コード、BOM、改行形式を確認することです。見た目が似ている文字でも、読込処理では別の文字として扱われる場合があります。
五つ目は、変換前後とアップロード後の検証を標準化することです。頂点数、座標範囲、全体寸法、代表距離、基準点との位置関係を比較すれば、表示だけでは分からない異常も発見しやすくなります。
点群OBJは、アップロードが完了しただけでは正常と判断できません。元データと同じ位置関係、縮尺、高低差を保っていることを数値で確認し、原本、変換条件、単位の前提、検証結果を残すことが重要です。
現場で取得した点群を座標情報とともに管理し、計測から確認、共有までの流れを効率化する場合は、LRTK Phoneを活用した点群データの運用も確認してみてください。