3D図面を絶対座標に合わせてAR表示したとき、建物全体が敷地の外へ移動する、モデルの向きが合わない、階ごとに高さがずれる、同じファイルでも読み込み環境によって位置が変わるといった問題が起こることがあります。これらの現象は、測位状態やAR表示機能だけが原因とは限りません。IFCデータに含まれる空間構造、相対配置、地理参照の解釈に不整合がある可能性があります。
IFCでは、柱や梁などの部材がすべて一つの絶対座標を直接持つとは限りません。敷地、建物、階、部材などがそれぞれローカルな位置と向きを持ち、親側の配置と子側の配置を順番に合成して、プロジェクトの工学座標系における最終位置を求める構成が一般的です。そのうえで、必要に応じて地理参照変換を用い、工学座標系を公共座標や投影座標へ対応させます。
このため、IfcSiteに不要な移動や回転が入っている、IfcBuildingやIfcBuildingStoreyで同じ変換が繰り返されている、空間分解の関係とObjectPlacementの参照先が一致していない、地理参照変換と外部オフセットが重複しているといった問題があると、下位の部材全体へずれが波及します。
ただし、IfcSiteが存在しないことや、IfcBuildingがIfcProjectの直下にあることだけで、直ちに配置階層ミスとは判断できません。IFCの版やモデルの用途によってはIfcSiteを省略した空間構造も成立します。確認すべきなのは、対象モデルが採用した階層と配置経路が一貫し、受け渡し先のソフトウェアがその表現を正しく解釈できるかという点です。
モデル単体の画面では、部材同士の位置関係が保たれているため、配置ミスに気づけないことがあります。画面中央へ自動表示する閲覧環境では、モデル全体が遠方へ移動していても形状だけは正常に見えます。しかし、現地の基準点や構造物と重ねる3D図面のAR表示では、平面位置、方位、高さの違いが表面化します。
位置ずれを端末上の手動調整だけで吸収すると、その場では合っても、別の端末、再読み込み後、更新後のモデルで同じ位置を再現できないことがあります。絶対座標を利用する目的は、毎回見た目で合わせることではなく、同じ座標条件から同じ現場位置を再現できる状態を作ることです。
この記事では、「3D図面 AR 表示 絶対座標」で情報を探している建設、測量、設計、施工管理などの実務担当者に向けて、IfcSite周辺の配置階層ミスを発見し、修正するための6つのチェックを解説します。単一の座標値だけを見るのではなく、IFCの版、空間分解、ObjectPlacement、地理参照、方位、高さ、現場検証を一つの流れとして確認することが重要です。
IfcSiteの配置階層ミスが3D図面のAR表示に与える影響
IFCデータには、形状、属性、分類だけでなく、プロジェクト内の空間構造が含まれます。建築モデルでは、IfcProjectの下にIfcSite、IfcBuilding、IfcBuildingStoreyが続く構成がよく使われます。柱、梁、壁、床、設備などの要素は、IfcRelContainedInSpatialStructureなどを通じて、特定の空間構造要素へ格納されます。
一方で、IfcSiteは常に必須の階層ではありません。採用するIFCの版や空間構造によっては、IfcProjectがIfcBuildingを直接集約する構成も考えられます。そのため、チェックの目的は「必ずProject、Site、Building、Storeyの四段階に直すこと」ではなく、モデルで意図した階層を確認し、空間分解と配置参照の関係をそろえることです。
IfcSiteは敷地を表す空間要素であり、ObjectPlacementを持つ場合があります。下位のIfcBuildingがその配置を参照し、さらにIfcBuildingStoreyや部材が親側の配置を参照していれば、IfcSiteの平行移動や回転は下位要素の最終位置へ影響します。IfcSiteが東へ5メートル移動し、建物がその配置を基準としていれば、建物も同じ変換を受けます。
ただし、IfcSiteの位置情報と地理参照情報は同じものではありません。ObjectPlacementはプロジェクトの工学座標系内における配置を表し、IfcMapConversionなどの座標操作は、その工学座標系を対象の投影座標参照系へ変換する役割を持ちます。IfcSiteの緯度、経度、参照高さに相当する属性もありますが、それだけで投影座標への完全な変換条件が表現されるとは限りません。
この構造で同じ移動や回転を複数の場所へ重ねて設定すると、下位の部材まで影響が伝わります。IfcSiteとIfcBuildingへ同じオフセットを入れ、さらに外部変換でも同じオフセットを加えれば、最終位置は意図した場所から大きく離れます。反対に、どの階層にも必要な変換がなく、地理参照も欠落していれば、モデルはローカル原点付近に残ります。
通常の3D表示では、モデル全体が同じ方向へ移動していても、壁と柱、床と設備といった部材同士の相対関係は変わりません。そのため、形状が整って見えることと、絶対座標が正しいことは別の問題です。特に、表示開始時にモデルへ自動ズームするソフトウェアでは、大きな座標ずれを見落としやすくなります。
現地で3D図面をAR表示すると、建物角が現況の基礎と重ならない、埋設物モデルが道路外へ出る、柱芯が実物から離れる、モデルが地面へ沈む、上階だけ高く表示されるといった形で不整合が表面化します。AR表示の見た目には測位精度や姿勢推定も影響するため、モデル側の固定的なずれと、表示中の一時的な揺れを分けて評価する必要があります。
ずれ方には原因を絞り込む手掛かりがあります。全地点でほぼ同じ方向へ同じ量だけずれるなら平行移動、原点から離れるほど横ずれが増えるなら回転、距離そのものが合わないなら単位や尺度、特定棟だけがずれるなら建物ごとの配置、上階ほど高さ差が増えるなら階配置や部材配置の重複が疑われます。
IfcSite周辺を確認するときは、一つの数値を書き換えて見た目を合わせるのではなく、IfcProjectから対象部材までの空間分解と配置参照を追います。どの階層が敷地内の相対位置を担当し、どの情報が公共座標への変換を担当するかを明確にすることが修正の出発点です。
チェック1 IFCの版と空間分解の関係を確認する
最初のチェックは、対象ファイルのIFCスキーマ版、想定するモデルビュー、IfcProjectから下位の空間要素へ続く分解関係です。座標値を修正する前に、どの仕様と受け渡し条件を前提にしたファイルなのかを確認します。IFC2x3、IFC4、IFC4.3では、利用できる地理参照の表現や推奨される扱いが同一ではありません。
建築モデルでは、IfcProject、IfcSite、IfcBuilding、IfcBuildingStoreyという順序がよく使われます。しかし、IfcSiteは省略可能な階層であり、IfcProjectがIfcBuildingを直接集約しているだけで不正とはいえません。元本文のように「IfcBuildingがIfcSiteを経由しなければ、IfcSiteの変換が伝わらないため誤り」と一律に扱うのではなく、そもそもIfcSiteを配置基準として使う設計なのかを確認します。
IfcSiteを配置基準として使う設計なら、IfcBuildingがIfcSiteの下位に集約され、建物のObjectPlacementが意図した親配置を参照しているかを確認します。IfcSiteを省略する設計なら、IfcBuildingがプロジェクトの最上位空間要素として成立し、そのObjectPlacementと地理参照が必要な位置を表せているかを確認します。
空間要素同士の階層は、IfcRelAggregatesによる空間分解として確認します。画面上のツリー名だけではなく、実際のエンティティ種別、RelatingObject、RelatedObjects、各要素の識別情報を追います。名称が「敷地」「建物」「一階」でも、実体の型や親要素が想定どおりとは限りません。
部材の所属は、空間要素の分解とは別に確認します。柱、梁、壁、床などは、通常、IfcRelContainedInSpatialStructureによって一つの空間構造レベルへ格納されます。部材が階へ格納されていても、そのObjectPlacementが別の建物や独立した原点を参照していれば、空間所属と配置経路が一致しない状態になります。
同じ空間要素が複数の親から分解されている状態は、正しい階層木として扱えません。モデル内で同じIfcBuildingが二つのIfcSiteの子になっているように見える場合は、実際に重複したIfcRelAggregatesがあるのか、同じ形状を別要素として複製しているのか、単なる空間参照関係なのかを区別します。
IFCには、主たる格納とは別に空間要素から参照する関係もあります。たとえば、複数階にまたがる要素を主たる階へ格納し、別の階から参照する表現が考えられます。この参照関係を、複数の親へ格納された状態と混同しないことが重要です。
複数棟を含むモデルでは、各IfcBuildingが同じ座標方針を採用しているかを確認します。建物AはIfcSiteからの相対配置、建物Bはプロジェクト座標系での独立配置、建物Cは外部変換後の座標を直接保持するといった混在があると、統合後の挙動を予測しにくくなります。
複数の敷地を一つのプロジェクトで管理する構成もあり得ます。その場合は、各IfcSiteの対象範囲、ObjectPlacement、地理参照方法、座標参照系、高さ基準を区別します。名称だけを変えて同じ配置情報を複製すると、異なる敷地のモデルが同じ場所へ表示される原因になります。
修正作業では、先に正しい空間構造を決め、その後で配置値を見直します。座標だけを合わせてから親子関係を変更すると、新しい親の変換が追加され、モデル位置が再び変わることがあります。IFCの版、空間分解、部材の格納、配置参照、地理参照の順で整理すると、変更の影響を追いやすくなります。
チェック2 IfcSiteのObjectPlacementと参照先を確認する
二つ目のチェックは、IfcSiteのObjectPlacementと、その具体的な配置型です。IfcSiteがIfcLocalPlacementを使用している場合、RelativePlacementによって原点と軸方向を定義し、PlacementRelToによって親側の配置を参照できます。
PlacementRelToが設定されていれば、その参照先のObjectPlacementからIfcSiteへの相対変換として解釈します。PlacementRelToが省略されている場合、IfcLocalPlacementはプロジェクトの幾何表現コンテキストが定めるワールド座標系を基準とします。参照先がないこと自体を欠落と判断せず、最上位の絶対配置として意図されたものかを確認します。
まず、IfcSiteの配置原点がどこに設定されているかを確認します。原点座標がゼロに近いから正しい、大きな値だから誤り、と単純には判断できません。モデルをローカル原点付近で管理し、IfcMapConversionなどで投影座標へ対応させる方式なら、IfcSiteの配置値が小さいことは自然です。
一方で、既存の受け渡し仕様によっては、プロジェクトの工学座標系自体へ大きな座標値を持たせる場合もあります。大きな座標値があるだけで不正とはいえませんが、形状計算の数値安定性や、読み込み側が地理参照変換を追加適用する可能性を確認する必要があります。
位置と同時に軸方向を確認します。IfcAxis2Placement3Dでは、AxisがローカルZ方向、RefDirectionがローカルX方向を定め、Y方向はそこから導かれます。AxisとRefDirectionを省略した場合の既定方向も仕様で定められているため、「ソフトウェアごとに既定値が違うことを前提にする」のは適切ではありません。
ただし、書き出し側や読み込み側が仕様どおりに扱わない場合や、変換工程で方向ベクトルが書き換わる場合はあります。検証では、方向属性が両方省略されて既定軸を使うのか、両方が明示されているのか、ベクトルが平行または反平行になっていないかを確認します。
IfcSiteとIfcBuildingの両方へ同じ回転を入れると、建物側の最終方位は意図より大きく変わります。たとえば、座標北へ合わせる回転をIfcSiteへ設定し、書き出し時にIfcBuildingへ同じ回転を追加すれば、AR表示では回転が重複します。想定角度のほぼ二倍に見える場合は、各階層の回転成分を追います。
一方、IfcSiteの回転が正しくても、IfcBuildingがIfcSiteのObjectPlacementを参照せず、独立した配置になっていれば、敷地側の変換は建物へ継承されません。空間分解上の親子関係と、PlacementRelToの参照先が食い違っていないかを確認します。
ObjectPlacementの参照をたどった先で循環が起きる状態は、正しい配置連鎖として解釈できません。循環や自己参照を検出した場合は、表示環境ごとの挙動を比較する前にデータ構造を修正します。循環の一部を無視して偶然表示できても、再現可能な絶対配置とはいえません。
修正後は、IfcSite、IfcBuilding、代表的なIfcBuildingStorey、基準となる部材の順に変換を追います。各段階で追加される平行移動と回転を記録し、最終的な工学座標が意図した値へ到達するかを確認します。結果だけが偶然合う状態ではなく、各階層の役割を説明できる状態に整えることが重要です。
チェック3 建物と階で移動量が二重加算されていないか確認する
三つ目のチェックは、IfcBuilding、IfcBuildingStorey、部材の配置で同じ移動量が繰り返されていないかという点です。IfcSiteが正しくても、建物、階、部材に同じ位置情報が重複していれば、3D図面のAR表示は現場と一致しません。
たとえば、IfcSiteからIfcBuildingへの配置で東へ10メートル移動し、建物に属する部材のローカル座標にも同じ10メートルが含まれていれば、最終位置は東へ20メートル移動します。元の作成環境では独自の内部補正によって正しく見えていても、IFCとして受け渡した際にその補正関係が再現されず、重複が表面化することがあります。
高さ方向でも同じ問題が起こります。IfcBuildingStoreyのObjectPlacementに階の相対高さが設定され、階へ格納された床や壁のObjectPlacementにも同じ階高が含まれていれば、部材が本来より高い位置へ表示されます。一階は合っているのに、二階、三階と上がるほど高さ差が増える場合は、階配置と部材配置の重複を疑います。
ここで注意したいのがIfcBuildingStoreyのElevationです。少なくともIFC4.3では、階の実際の配置はObjectPlacementによって決まり、Elevationは情報用途の属性であり、配置値として加算するものではありません。IFC4.3ではこの属性自体が非推奨とされています。
したがって、ElevationとObjectPlacementのZ値が同じだから二重加算になる、という判断も、読み込み時に両方を加算してよいという判断も適切ではありません。標準的な配置計算ではObjectPlacementを使用し、Elevationは参考情報として整合性を確認します。読み込みソフトウェアがElevationを位置決定へ使う場合は、その製品固有の挙動として切り分けます。
確認時には、IfcSiteの配置、IfcBuildingの配置、IfcBuildingStoreyの配置、部材の配置を順番に合成します。同じ数値が複数階層へ現れていても、それぞれが異なるローカル基準を表す場合があります。数値が同じという理由だけで削除せず、最終変換へ何回寄与しているかを確認します。
複数棟のモデルでは、建物ごとに座標方式が混在していないかを確認します。建物AはIfcSiteからの相対位置、建物Bは工学座標系での独立配置、建物Cは部材へ大きな座標を持たせる方式であれば、同じ変換処理を一律に適用できません。
建物Aだけが正しく、建物Bが大きく離れ、建物Cが回転して表示される場合は、各IfcBuildingのObjectPlacement、PlacementRelTo、RelativePlacement、下位部材の座標値を比較します。建物ごとの平行移動量、回転方向、配置参照、部材座標の大きさを並べると、方式の違いを発見しやすくなります。
修正するときは、どの階層でどの変換を持たせるかを決めます。IfcSiteを使うモデルなら、IfcSiteはプロジェクト内における敷地の配置、IfcBuildingは敷地内の建物位置、IfcBuildingStoreyは建物内の階位置、部材は格納先空間から見たローカル位置という役割に整理すると追跡しやすくなります。
ただし、絶対座標への変換を必ずIfcSiteへ集約する必要はありません。IfcMapConversionなどを使う場合、プロジェクトの工学座標系から投影座標系への変換は座標操作側が担当します。IfcSiteのObjectPlacementへ公共座標オフセットを重ねて入れるかどうかは、採用した座標設計に基づいて判断します。
既存データの子要素座標を単純にゼロへ戻してはいけません。親の変換と子の変換が組み合わさって正しい位置になっている部分まで失う可能性があります。修正前に複数の代表点の最終座標を記録し、親子の変換を組み替えた後も、意図した点が同じ工学座標へ到達することを確認します。
ずれ方から原因を推定することもできます。モデル全体が同じ量だけ移動している場合は、上位の平行移動や外部オフセットが疑われます。階ごとに一定の倍数で高さ差が増える場合は、階高の重複が考えられます。建物ごとに異なる方向へずれる場合は、各建物の配置方式が統一されていない可能性があります。
回転中心にも注目します。敷地原点を中心にモデル全体が回転しているなら上位配置または地理参照の方向成分、特定棟の原点を中心に回転しているならIfcBuilding、階ごとに異なる向きならIfcBuildingStorey以下の配置を確認します。
チェック4 絶対座標と地理参照変換の役割を確認する
四つ目のチェックは、IfcSiteの配置、IfcSiteの地理的位置属性、IfcMapConversionなどの座標操作、AR表示前の外部変換が、それぞれ何を担当しているかという点です。これらは似た数値を持つことがありますが、同じ意味ではありません。
IFCの形状とObjectPlacementは、まずプロジェクトの工学座標系で解釈されます。ローカル原点付近でモデルを作成し、IfcMapConversionによって工学座標系を対象の投影座標参照系へ対応させる構成では、大きなEastingsやNorthingsを各部材へ直接持たせる必要はありません。
IfcMapConversionでは、対象座標参照系に対するEastings、Northings、OrthogonalHeight、ローカルX軸の方向成分、Scaleなどを用いて変換します。現在のIFC4.3仕様では、Scaleは主としてプロジェクトの長さ単位と対象座標参照系の単位が異なる場合の換算に使われます。一般的な投影補正値を無条件に入れる項目として扱わないことが重要です。
また、IfcMapConversionは地理座標から投影座標を算出する投影処理そのものを担うものではありません。対象のIfcProjectedCRSを特定し、すでに定義されたローカル工学座標系と投影座標系の対応を表します。座標参照系の名称、測地基準、鉛直基準、単位を受け渡し先で識別できる状態にします。
IfcSiteにはRefLatitude、RefLongitude、RefElevationに相当する属性があり、敷地のローカル配置原点を実世界の参照位置へ結び付けるために使われることがあります。しかし、緯度、経度、参照高さだけでは、対象の投影座標系における東西座標、南北座標、軸方向、単位などを一意に再現できない場合があります。
そのため、IfcSiteの地理的位置属性があるからIfcMapConversionは不要、または両方があるから必ず二重変換になる、と一律には判断できません。採用したIFCの版と受け渡し仕様を確認し、どの情報を最終的な地理参照として使用するかを決めます。
問題になるのは、同じ意味の平行移動、回転、高さ補正を複数の経路で実際に適用することです。IfcSiteのObjectPlacementへ公共座標相当のオフセットを入れ、IfcMapConversionにも同じオフセットを入れ、さらにAR表示前に外部オフセットを追加すれば、同じ変換が重複する可能性があります。
反対に、IfcSiteのObjectPlacementがローカル配置で、座標操作もなく、外部設定もない場合は、絶対座標への対応が不足します。ファイル内に情報がないのか、別ファイルやクラウド設定で管理しているのか、読み込み側が独自の基準点設定を必要とするのかを確認します。
座標変換を調べるには、現場座標が分かっている代表点を一つ選び、段階ごとの値を追います。部材のローカル座標、階と建物と敷地のObjectPlacementを合成した工学座標、座標操作後の投影座標、AR表示へ渡す座標を並べます。
各段階の差分を見ることで、同じオフセットが二回加わった場所、回転が欠落した場所、高さ基準が切り替わった場所を特定できます。最終表示だけを手動調整するより、原因に基づいた修正ができます。
単位も確認します。IFCプロジェクトの長さ単位、対象座標参照系の単位、変換後データの単位、AR表示側の受け入れ単位が一致しているかを見ます。メートルとミリメートルの混在では、モデル寸法と座標オフセットの両方が大きく変わる可能性があります。
原点から離れるほど差が広がる場合は、水平回転、方向成分、単位換算、尺度設定を確認します。ただし、単純な平行移動でも大きな固定差は生じます。複数地点の差を比較し、差が一定か、距離に比例して変化するかを見分けます。
読み込み環境がIfcMapConversionや対象の座標参照系を利用できない場合もあります。その場合は、対応していない情報を残したまま正しい表示を期待するのではなく、事前変換したAR表示用データを用意するなど、受け渡し方法を決めます。変換済みデータと未変換データが混在しないよう、識別と版管理が必要です。
チェック5 方位と高さの基準を確認する
五つ目のチェックは、方位と高さです。平面上の一つの基準点が合っていても、モデルの方向や鉛直基準が異なれば、現場全体のAR表示は一致しません。
方位には、モデル作成時のローカル軸、図面上の北、真北、投影座標系の北、現場で採用した基準線などがあります。これらを区別せずに扱うと、基準点では重なるものの、敷地端へ行くほど横方向へずれます。
IfcAxis2Placement3Dでは、AxisがローカルZ軸、RefDirectionがローカルX軸を定めます。さらに、幾何表現コンテキストのTrueNorthや、IfcMapConversionのローカルX軸方向成分が方位の解釈に関係する場合があります。同じ北合わせの回転を複数の場所へ重ねて設定していないかを確認します。
元モデルがすでに投影座標系の軸へ合わせられているのに、IfcSite、IfcBuilding、座標操作、AR表示前変換のそれぞれで北合わせを行えば、回転が重複します。反対に、モデルをローカル方向のまま保持して方向情報だけを付加しても、表示側がその情報へ対応していなければ、モデルは意図した方位になりません。
方位の検証には、できるだけ長い基準線を使います。道路中心線、敷地境界、通り芯、長い外壁など、離れた二点の座標が分かる線を選びます。短い壁や近接する二点だけでは、小さな角度差を見落としやすくなります。
基準線の始点が合い、終点だけが横へずれる場合は、平行移動よりも方位を疑います。始点から終点までの距離が長いほど差が増えるなら、回転角の誤りが考えられます。点間距離そのものも変わるなら、単位や尺度も確認します。
高さでは、楕円体高、標高、投影座標参照系の鉛直基準、現場基準高、建物の設計基準高さなどが混在しやすくなります。GNSS測位で得られる高さと、設計図面に記載された標高が同じ基準とは限りません。東西方向と南北方向が一致していても、高さ基準が異なればモデルは地面へ沈んだり宙に浮いたりします。
IfcMapConversionのOrthogonalHeightを使う場合は、対象の座標参照系で想定する鉛直基準と整合しているかを確認します。IfcSiteのRefElevation、IfcBuildingのElevationOfRefHeightなどの情報属性、IfcBuildingStoreyのElevation、各ObjectPlacementのZ値を同じ配置値として一律に加算してはいけません。
特にIfcBuildingStoreyのElevationは、IFC4.3では配置計算用ではありません。実際の階位置はObjectPlacementから求めます。情報属性と配置値が一致しているかは検査できますが、両方を足して高さを決める処理は避けます。
確認時には、現場の既知点から対象部材までの高さ経路を追います。工学座標系の基準高さ、IfcSiteやIfcBuildingのObjectPlacement、IfcBuildingStoreyのObjectPlacement、部材のローカル高さ、座標操作のOrthogonalHeight、AR表示側の機器オフセットを分けて記録します。
モデル全体が一定量だけ高い、または低い場合は、上位の高さオフセット、鉛直基準、機器オフセットを疑います。上階へ進むほど差が増える場合は、階配置や部材配置の重複が考えられます。敷地内の場所によって高さ差が変化する場合は、モデルの傾きや鉛直軸の方向も確認します。
AR表示では、測位アンテナの基準位置とカメラ位置の違い、機器に設定されたアンテナ高やレバーアーム、端末の姿勢推定なども見え方へ影響します。ただし、モデル側の高さ基準が不明なまま表示機器だけを調整すると、原因を区別できません。先にモデル座標を既知点で検証し、その後に機器側の補正を確認します。
方位や高さを修正した後は、平面位置も再確認します。回転中心、ローカル軸、鉛直方向を変更すると、東西方向や南北方向の座標にも影響する場合があります。平面、方位、高さを別々に完了させず、三次元座標として最終確認します。
チェック6 複数の基準点でAR表示まで通して検証する
六つ目のチェックは、修正したIFCデータを最終的なAR表示工程まで通して検証することです。モデル閲覧画面で正しく見えるだけでは、絶対座標で正しく配置されることを保証できません。
IFCデータは、書き出し、変換、統合、登録、読み込み、AR描画など複数の工程を通ります。各工程で座標の解釈、単位、原点、方位、高さが変わる可能性があります。そのため、IfcSite周辺を修正した後は、実際に使用するデータ形式と表示環境で確認します。
検証には、現場座標とモデル座標の両方で識別できる基準点を使います。建物角、通り芯の交点、測量標、杭位置、構造物中心、設備中心など、位置を明確に判定できる点が適しています。形状の端が曖昧な点や、施工誤差が大きい仮設物だけを基準にしないことが重要です。
一点だけの確認では、モデルを平行移動すれば一致させられるため、方位、単位、尺度の誤りを発見できません。少なくとも離れた複数地点を使い、東西差、南北差、高さ差、点間距離、方向を確認します。
最初の基準点では三方向の差を記録します。二点目では、二点間の距離と方位が一致するかを確認します。三点目を加えると、一つの直線だけでは分からない軸の取り違え、反転、局所的な配置ミスを発見しやすくなります。
広い現場では、モデル原点の近くだけでなく、敷地の端や離れた建物にも基準点を設定します。原点付近では小さく見える回転誤差も、数十メートル離れると無視できない位置差になります。複数棟がある場合は、各棟に少なくとも一つの確認点を設けます。
AR画面上の見た目だけで合否を判断しないことも重要です。測位解の状態、衛星配置、補正情報の受信、周囲の遮蔽や反射、端末の姿勢推定、カメラ映像の視差などによって、モデルが一時的に揺れて見える場合があります。
基準点での数値差、測位状態、表示が安定するまでの時間、端末を移動した後の再現性、再読み込み後の位置を記録すると、モデル側と表示側の問題を切り分けやすくなります。毎回同じ方向へ同じ量だけずれるなら、モデル側の固定変換や機器の固定オフセットが疑われます。
原点から離れるほどずれが大きくなるなら、方位、方向成分、単位、尺度を確認します。高さだけが一定量異なるなら、鉛直基準、OrthogonalHeight、アンテナ高などを確認します。端末の向きや移動によって差が変動するなら、モデル座標だけでなく姿勢推定や測位環境も確認します。
複数端末で同じモデルを利用する場合は、同じモデル版、同じ座標設定、同じ基準点、同じ検証手順を使います。端末ごとに個別の手動位置合わせを行うと、絶対座標が正しいのか、手動補正によって偶然合っているのかを判断できません。
修正前後の記録も残します。IFCの版、IfcSiteの有無、空間分解、ObjectPlacementの参照先、座標操作、対象座標参照系、単位、使用した基準点、AR表示で確認した差、データの作成日時や改訂情報を記録します。
一度表示が合っただけで完了としないことも大切です。モデルを閉じて再読み込みしたとき、表示履歴を消したとき、別の日に同じ場所で表示したとき、異なる方向から現場へ入ったときにも、同じ位置へ再現されるかを確認します。
一時的な手動調整や前回の表示状態が保存された結果として合っている可能性があるためです。絶対座標を利用する目的は、同じ条件から再現可能な位置を得ることにあります。
中間変換を行っている場合は、元のIFCデータとAR表示用データを区別します。変換時に原点移動、軸変換、単位変更、高さ補正を行ったなら、その条件を管理します。元データを更新したときにも同じ変換を再現できなければ、版ごとにAR表示位置が変わります。
IfcSiteの配置階層ミスを再発させない運用
IfcSite周辺の配置ミスは、一度修正しても、モデルの更新や再出力で再発する可能性があります。修正内容が担当者の作業環境にだけ残り、プロジェクトのデータ作成ルールへ反映されていないことが主な原因です。
再発を防ぐには、最初にIFCの版と受け渡し要件を固定します。IfcSiteを空間構造に含めるのか、最上位のIfcBuildingを使うのか、地理参照にIfcMapConversionを使うのか、外部変換を使うのかを明文化します。
絶対座標への対応をどの工程が担当するかも決めます。設計担当者がIfcSiteへオフセットを設定し、変換担当者が同じ座標を追加し、現場担当者がさらに手動補正する運用では、データを更新するたびに位置が変わる危険があります。
プロジェクト共通の基準点を定めます。基準点には、識別できる名称、東西座標、南北座標、高さ、座標参照系、鉛直基準、単位、確認日を持たせます。モデル更新時には、複数の基準点が同じ位置を維持しているか確認します。
大きな絶対座標を避けるためにローカル原点を設定する場合は、ローカル原点と投影座標の対応を失わないようにします。ローカル原点が公共座標上のどこにあるか、ローカルX軸がどの方向を向くか、どの高さをゼロとするかを一組で管理します。
書き出し条件も統一します。同じ元モデルでも、IFCの版、モデルビュー、共有座標の出力方法、サイト位置の扱い、真北の扱い、単位設定によって結果が変わることがあります。担当者ごとに異なる設定を使わず、AR表示まで検証できた条件を共通化します。
外部から受け取ったIFCデータは、全体モデルへ統合する前に単独で確認します。スキーマ版、IfcSiteの数、最上位空間要素、IfcRelAggregates、部材の空間格納、ObjectPlacementの参照先、座標操作、単位、方位、高さ基準を確認します。
見た目を合わせるためにモデル全体を手動移動するだけでは、次回の更新データで同じ作業が必要になります。受け取ったデータの座標方式を確認し、プロジェクト側の基準へ変換する工程を定めることが重要です。
版管理では、ファイル名だけでなく、座標修正の内容と検証結果を対応させます。どの版で空間分解を変更したか、どのObjectPlacementを修正したか、どの座標操作を使用したか、どの基準点で確認したか、どのAR表示用データを作成したかを追跡できるようにします。
旧版と新版が混在すると、現場担当者が同じ名称だと思って開いたモデルでも、異なる位置へ表示される可能性があります。公開中のモデル版を明確にし、更新時には旧版との基準点差を確認します。
データ検査では、形状欠落、属性欠落、干渉だけでなく、空間階層と座標も確認対象にします。空間分解が一つの階層木になっているか、部材の格納先が一意か、ObjectPlacementに循環がないか、配置参照が空間構造と整合するか、地理参照と単位が明示されているかを点検します。
IfcBuildingStoreyについては、配置をObjectPlacementで確認し、Elevationを配置値として加算しないルールを共有します。情報属性と実配置の不一致は検査対象にできますが、属性値を使って独自に位置を再計算すると、読み込み環境による差が生じやすくなります。
現場から「モデルがずれている」という報告があったときは、すぐに手動で表示位置を動かすのではなく、差の方向と量を記録します。全地点で同じ差なのか、距離に応じて広がるのか、高さだけが異なるのか、特定棟だけがずれるのかを分類します。
差の特徴を記録すれば、平行移動、回転、単位、階高、建物別配置、測位状態など、確認すべき範囲を絞り込めます。症状を数値として共有することで、設計担当者、測量担当者、データ変換担当者、AR表示担当者の間でも原因を検討しやすくなります。
関係者間で用語をそろえることも欠かせません。「原点」「基準点」「北」「標高」「絶対座標」「ローカル座標」という言葉が、担当者ごとに違う意味で使われることがあります。座標参照系、鉛直基準、工学座標系、地理参照変換、機器オフセットの役割を含めて定義します。
最終的には、モデル作成から現場でのAR表示までを一つの座標管理工程として設計します。IFC出力時、データ変換時、登録時、AR表示時に別々の補正を場当たり的に行うのではなく、どの段階で何を変換するかを固定します。
この運用が整えば、モデルを更新しても同じ絶対座標を維持しやすくなります。複数端末での共有、施工段階ごとのモデル更新、別担当者による再表示でも、手動位置合わせに依存しない運用へ近づけられます。
まとめ
3D図面を絶対座標でAR表示した際に起こる位置ずれは、測位や表示機能だけでなく、IfcSite周辺の空間分解、ObjectPlacement、地理参照の不整合に原因がある場合があります。
最初に確認すべきなのは、IFCの版と空間構造です。IfcProject、IfcSite、IfcBuilding、IfcBuildingStoreyという構成は一般的ですが、IfcSiteは常に必須ではありません。IfcBuildingがIfcProjectの直下にあることだけで誤りと判断せず、意図した空間分解と配置参照が一貫しているかを確認します。
次に、IfcSiteのObjectPlacementと参照先を調べます。PlacementRelToが省略されたIfcLocalPlacementは、幾何表現コンテキストのワールド座標系を基準とする配置として成立します。AxisとRefDirectionの既定方向も仕様で定められているため、欠落と既定値を区別します。
建物、階、部材の移動量が重複していないかも重要です。IfcBuildingStoreyの実配置はObjectPlacementから求め、Elevationを配置値として加算しません。上階ほど高さ差が拡大する場合は、階配置と部材配置の重複を確認します。
さらに、IfcSiteの配置、IfcSiteの地理的位置属性、IfcMapConversion、外部変換の役割を区別します。同じ平行移動、回転、高さ補正を複数の経路で適用すると、モデルが遠方へ移動する、方向が合わない、原点から離れるほどずれるといった問題が起こります。
方位と高さについては、ローカル軸、真北、投影座標系の北、楕円体高、標高、現場基準高を区別します。平面上の一点だけを合わせても、方位や高さが違えば現場全体では一致しません。
修正後は、複数の基準点を使い、実際のAR表示まで通して検証します。一点だけでなく離れた複数地点を確認することで、平行移動、回転、単位、尺度、高さの問題を切り分けられます。再読み込みや別端末でも同じ位置が再現されることを確認します。
モデル閲覧画面で正しく見えることは、絶対座標が正しいことを意味しません。現場の既知点と照合し、空間分解、配置参照、地理参照、方位、高さを一つの流れとして確認することが、安定した3D図面のAR表示につながります。
IfcSiteを含むモデル側の座標構造を整えたうえで、絶対座標に基づく現場確認へ進めば、施工位置の照合、完成イメージの確認、埋設物の可視化、関係者間の位置共有などへ活用しやすくなります。LRTK PhoneでAR表示する場合も、モデル側の座標設計と基準点検証を先に整え、端末ごとの手動位置合わせに依存しない運用を目指すことが重要です。