IfcProjectedCRSの欠落が3D図面AR表示に与える影響
絶対座標を持つ3D図面を現場でAR表示する場合、モデルの形状が正しく作られているだけでは十分ではありません。モデル内の一点が、現実空間のどの座標に対応するのかを受け渡せる状態にしておく必要があります。この座標参照系の情報をIFCデータ内で表現するために用いられる要素の一つがIfcProjectedCRSです。
IfcProjectedCRSは、ローカルな工学座標系を関連付ける先となる地図側の座標参照系を表します。IFC4.3系の仕様では、地図側の座標系は右手系の2次元または3次元直交座標系として扱われ、MapUnitによって地図座標軸の長さ単位を示せます。また、IfcProjectedCRSと地図変換の仕組みはIFC4で導入されたため、IFC2x3のファイルには同じエンティティ構成は存在しません。IFC 4.3.2 Documentation+1
建設、土木、測量の実務では、設計図面、測量成果、点群、施工管理データなどを同じ絶対座標で重ねる必要があります。IfcProjectedCRSが欠落していると、モデルを受け取った側は、記録された数値がどの地域、どの測地基準、どの投影法、どの単位を表しているのか判断しにくくなります。座標値が数十万や数百万であっても、その値だけから正しい座標参照系を一意に推定することはできません。
一方、IfcProjectedCRSが存在していても、それだけで正しいAR表示が保証されるわけではありません。IfcProjectedCRSは座標参照系を定義する役割を持ちますが、モデルのローカル工学座標系を地図座標系へ変換するには、IfcMapConversionなどの座標変換情報が必要です。座標参照系の識別情報、変換元と変換先の関連、移動量、回転方向、単位変換が一体として成立して初めて、モデルの絶対位置を復元できます。
3D図面をAR表示した際に、モデルが現場から大きく離れた場所に出る、一定角度だけ回転する、高さだけがずれる、モデル原点から離れるほど差が増えるといった問題は、GNSSの測位誤差だけが原因とは限りません。IFCデータの座標参照系、モデル原点、WorldCoordinateSystem、単位、回転、高さ基準のいずれかが欠落または不整合になっている可能性があります。
したがって、IfcProjectedCRSの確認では、エンティティの有無だけを見るのではなく、対象IFCの版、属性、MapUnit、IfcMapConversionとの関連、変換値、現地既知点との整合を順番に検証することが重要です。ここからは、3D図面を絶対座標でAR表示する前に確認したい六つの項目を解説します。
確認項目1：IFCの版と書き出し条件が対応しているか
最初に確認したいのは、対象となるIFCデータの版です。IfcProjectedCRSとIfcMapConversionはIFC4で追加されたエンティティであり、IFC2x3を指定して書き出したファイルには格納できません。したがって、作成元の3D図面に共有座標や測量座標が設定されていても、IFC2x3へ書き出した時点でIfcProjectedCRSを使った受け渡しは成立しません。IFC 4.3.2 Documentation+1
IFC4またはIFC4.3を選択していても、交換用途、モデルビュー、書き出し機能の実装、座標関連のオプションによって、地理参照情報が出力されない場合があります。作成元の画面上で正しい位置に見えていることと、書き出されたIFCファイルに座標参照系と座標変換が保存されていることは別の問題です。
特に注意したいのは、作成環境が内部的に管理している共有座標や測量座標が、自動的にIfcProjectedCRSとIfcMapConversionへ変換されるとは限らない点です。座標情報を書き出す設定が無効になっている場合や、形状互換性を優先した設定を使用した場合は、形状は正常でも絶対座標に必要な情報が省略される可能性があります。
確認時には、拡張子だけで判断せず、IFCファイルのヘッダーに記録されたFILE_SCHEMAを確認し、IFC2X3、IFC4、IFC4X3などのスキーマ識別を特定します。そのうえで、書き出し時に地理参照情報を含める設定が選択されていたか、どのモデル原点や測量基準が変換元として使われたかを確認します。
また、IFC4とIFC4.3では、座標参照系に関連する表現能力や推奨される識別方法に差があります。たとえば、現行のIFC4.3系では、EPSGコードで一意に表せない座標参照系をWKTで関連付ける仕組みがありますが、すべての旧版や読み込み環境が同じ方法に対応するとは限りません。送出側と受入側の双方が対応するスキーマと実装範囲を確認する必要があります。
データ作成者とAR表示担当者の間では、絶対座標の受け渡し方法を明確にします。IFC内にIfcProjectedCRSとIfcMapConversionを格納するのか、別途座標定義書を添付するのか、既知点を使って現場で位置合わせを行うのかによって、必要な確認項目が変わります。
同じ現場で建築、土木、設備など複数の3D図面を扱う場合は、IFCの版と書き出し条件を統一します。一部のモデルだけIFC2x3であったり、地理参照情報を出力しない設定であったりすると、形状は読めても絶対座標では重ならない状態が生じます。
まず対象ファイルがIfcProjectedCRSを格納できるスキーマで作成されているかを確認し、その条件を満たしていない場合は、以降の属性確認に進む前に再書き出しの可否を検討します。
確認項目2：IfcProjectedCRSエンティティが存在するか
次に、IFCファイル内にIfcProjectedCRSが実際に存在するかを確認します。モデル作成画面に座標参照系の名称が表示されていても、書き出されたファイルにエンティティが含まれているとは限りません。
確認には、IFCのエンティティと参照関係を参照できる解析機能を使用します。画面上でモデルを表示するだけでは、形状がローカル座標で正常に見えてしまい、IfcProjectedCRSの欠落を見落とすことがあります。エンティティ一覧やSTEP形式の記述を確認し、対象ファイルにIFCPROJECTEDCRSが存在するかを調べます。
IfcProjectedCRSが一件も存在しない場合、IFC4以降のファイルであっても、投影または複合座標参照系の定義が格納されていない可能性があります。ただし、欠落しているからといって、モデルが必ずローカル座標だけで作成されているとは限りません。形状座標に大きな値が直接入っている場合や、別資料によって座標関係を管理している場合もあります。
そのため、IfcProjectedCRSが存在しないときは、モデルの代表点、IfcGeometricRepresentationContextのWorldCoordinateSystem、主要オブジェクトの配置、IfcSiteの位置情報なども確認します。ただし、これらの値が存在しても、投影座標参照系を一意に識別できなければ、IfcProjectedCRSとIfcMapConversionを用いた地理参照と同等とは判断できません。
建物や構造物の近くに原点があり、座標値が数十メートルから数百メートル程度であれば、ローカル工学座標系で作成されている可能性があります。反対に、東西方向と南北方向に大きな値が入っている場合は、形状座標やWorldCoordinateSystemに絶対座標相当の値が直接使われている可能性があります。
ただし、大きな座標値だけを根拠に正しい絶対座標データだと判断してはいけません。座標参照系、軸方向、単位、鉛直基準が不明なままでは、AR表示側で正確に変換できないからです。また、大きな座標値を形状へ直接持たせる方法は、処理系によって数値精度や描画安定性へ影響することがあります。
IfcProjectedCRSが複数存在する場合は、どのIfcMapConversionから参照されているかを追跡します。未使用の定義が残っている場合や、統合前の異なる座標参照系が混在している場合があります。複数存在することだけで異常とは断定せず、実際に3D形状を担う表現コンテキストから到達する座標変換を確認します。
IfcProjectedCRSが存在していても、AR表示に使用するIfcGeometricRepresentationContextをSourceCRSとする座標変換のTargetCRSになっていなければ、モデル座標との関係を復元できません。存在確認は入口であり、関連付けと変換値まで確認して初めて、絶対座標で利用できる状態か判断できます。
確認項目3：座標参照系を識別できる属性が設定されているか
IfcProjectedCRSが存在していることを確認したら、内部の属性を調べます。重要なのは、受け取った担当者や処理機能が、どの座標参照系を表しているのか一意に識別できる状態になっているかです。
IfcProjectedCRSでは、継承したName、Description、GeodeticDatumに加え、VerticalDatum、MapProjection、MapZone、MapUnitを扱えます。ただし、現行のIFC4.3系では、Nameに一つのEPSGコードを名前空間付きで記録することが推奨され、複数のEPSGコードを一つのName文字列へ並べる方法は認められていません。EPSGコードだけで座標参照系を一意に表せない場合は、対象スキーマが対応していればWKTによる定義を使用します。IFC 4.3.2 Documentation+1
したがって、「現場座標」「測量座標」「共有座標」といった社内名称だけをNameへ設定する運用は避けます。第三者が参照できる一意な識別子をNameへ設定し、人が読む補足説明はDescriptionや座標定義書へ分ける方が安全です。名称と複数コードを自由形式で併記すると、読み込み側が正しく解釈できない可能性があります。
水平位置だけでなく高さも絶対座標として扱う場合は、鉛直基準を確認します。IFC4.3系で3次元のIfcGeometricRepresentationContextを地理参照する場合、IfcProjectedCRSは水平と鉛直の基準を一意に判別できる複合座標参照系として扱うことが求められます。単独のEPSGコードで水平と鉛直をまとめて識別できる場合は、GeodeticDatumやVerticalDatumなどの補助属性を省略できることがありますが、コードが水平座標系だけを示す場合は高さ基準を別途確定する必要があります。IFC 4.3.2 Documentation
GNSSで得られる高さ、測量成果の標高、設計モデルの高さは同じ基準とは限りません。平面位置が合っているのにモデルだけが地面から浮く、または地中へ沈む場合は、IfcMapConversionのOrthogonalHeightだけでなく、IfcProjectedCRSが示す鉛直基準と現場で採用する標高基準の関係を確認します。
MapProjectionやMapZoneを使用する場合は、Nameが示す座標参照系と矛盾していないかを確認します。過去案件の設定を複製し、Nameだけ変更してMapZoneが残った場合などは、属性間で不整合が生じます。現行仕様では一意なNameが投影法、地域区分、測地基準、鉛直基準まで特定できる場合、補助属性を省略できるため、空欄であることだけを直ちに欠落と判断しません。
反対に、Nameが曖昧であるにもかかわらず、GeodeticDatum、VerticalDatum、MapProjection、MapZoneも空欄であれば、座標参照系を特定できない可能性が高くなります。属性の件数ではなく、受け側が水平位置と高さの基準を一意に復元できるかという観点で判定します。
読み込み側がEPSGやWKTをどこまで解釈できるかも確認します。IFCファイルが仕様上正しくても、AR表示環境が対象スキーマや識別方法に未対応であれば、自動変換できないことがあります。その場合は、IFCを改変して曖昧な文字列へ置き換えるのではなく、対応する交換方法へ再出力するか、検証済みの座標変換を別管理します。
確認項目4：MapUnitとモデルの長さ単位が整合しているか
四つ目の確認項目は単位です。IfcProjectedCRSに正しい座標参照系が設定されていても、地図座標の単位と3Dモデルの長さ単位の関係が正しく表現されていなければ、AR表示時に大きな位置や縮尺の異常が発生します。
IFCデータには、IfcProject.UnitsInContextで定義されるプロジェクトの長さ単位があります。それとは別に、IfcProjectedCRSのMapUnitで地図座標軸の長さ単位を示せます。MapUnitは任意属性ですが、現行のIFC4.3系仕様では、MapUnitが省略された場合、地図座標軸にはIfcProject.UnitsInContextの既定の長さ単位が適用されます。したがって、欠落時に必ずメートルと解釈されるわけではありません。IFC 4.3.2 Documentation
モデル形状がミリメートルで、地図座標がメートルである場合は、IfcMapConversionのScaleによって三軸を同じ比率で単位変換できます。現行仕様では、Scaleが省略された場合は1.0とみなされます。Scaleは単位差を表すための一様な係数として確認し、現地で見つかった残差を場当たり的に吸収する補正値として扱わないことが重要です。IFC 4.3.2 Documentation
たとえば、プロジェクト単位がミリメートル、MapUnitがメートルであるのにScaleが1.0のままであれば、ローカル座標の寸法を地図座標へ変換する際に千倍の不整合が生じる可能性があります。反対に、プロジェクト単位とMapUnitがともにメートルであるのにScaleへ0.001を設定すると、モデル全体が千分の一で変換されます。
Eastings、Northings、OrthogonalHeightはTargetCRS側の位置を表す値として扱われるため、MapUnitが示す単位と整合しているかを確認します。既知点の東座標、北座標、標高とIFC内の変換値を比較し、桁数、小数位置、符号が一致しているかを調べます。
MapUnitが省略されている場合は、仕様上の既定単位を確認したうえで、読み込み側がその規則を正しく実装しているかも検証します。仕様上の解釈と実装上の挙動が一致しない場合があるため、既知点を使った実データ確認が必要です。
モデル寸法についても、柱間隔、道路幅、構造物の全長など、現実の寸法が分かる部分を測定します。原点位置が合っていても、単位変換が誤っていれば、モデル原点から離れるほど現物との位置差が大きくなります。
単位の不整合は、AR表示上ではGNSS精度の問題に見えることがあります。しかし、測位値が安定しているのにモデルの大きさが不自然である場合や、端部ほど差が増える場合は、MapUnit、UnitsInContext、Scaleの関係を優先的に確認します。
確認項目5：IfcMapConversionとの関連付けが成立しているか
五つ目は、IfcProjectedCRSと座標変換情報の関連付けです。IfcProjectedCRSは地図側の座標参照系を表しますが、3Dモデルのローカル工学座標系を絶対座標へ移すためには、変換元、変換先、移動量、回転、単位変換の情報が必要です。
IfcMapConversionは、ローカル工学座標系を地図座標参照系へ変換するためのエンティティです。SourceCRSには通常、3D形状を担うIfcGeometricRepresentationContextが入り、TargetCRSにはIfcProjectedCRSが入ります。変換は、三軸への一様なScale、Z軸回りの反時計回り回転、Eastings、Northings、OrthogonalHeightによる平行移動の順で定義されます。IFC 4.3.2 Documentation
IfcProjectedCRSがファイル内に存在していても、IfcMapConversionのTargetCRSとして参照されていなければ、モデル座標との関係を復元できません。反対に、IfcMapConversionが存在していても、TargetCRSが意図したIfcProjectedCRSでない場合や、SourceCRSが実際の3D形状に使われる表現コンテキストでない場合は、AR表示へ正しく利用できません。
確認では、AR表示に使用するIfcShapeRepresentationがどのIfcGeometricRepresentationContextまたはSubContextへ属しているかをたどり、その親コンテキストがIfcMapConversionのSourceCRSになっているかを確認します。SubContextだけを見て判断せず、ParentContextまで追跡することが重要です。
IFC4.3系では、一つのIfcProjectに複数のIfcGeometricRepresentationContextがある場合、それらは同一の座標変換と同一の座標参照系を共有することが求められます。異なるコンテキストが別々の座標変換を指している場合は、統合や書き出しの過程で不整合が生じていないか確認します。IFC 4.3.2 Documentation
WorldCoordinateSystemも見落とせません。IfcMapConversionを使用する場合、WorldCoordinateSystemはローカル工学座標系のゼロ点と、IfcMapConversionのオフセットが対応する地理参照点との間のオフセットを表すことがあります。WorldCoordinateSystemが原点以外に設定されているファイルでは、IfcMapConversionのEastingsとNorthingsだけを抜き出して解釈すると、二重移動や不足移動を起こす可能性があります。IFC 4.3.2 Documentation
真北方向については、IfcGeometricRepresentationContext.TrueNorthとIfcMapConversionのXAxisAbscissa、XAxisOrdinateの整合を確認します。仕様上、IfcMapConversionが存在する場合、TrueNorthは情報目的であり、不一致時にはIfcMapConversionが優先されます。読み込み側が両方を単純に加算して回転させないか、実装確認も必要です。IFC 4.3.2 Documentation
現場でモデルの一点は合うものの、離れた場所ほど横方向にずれる場合は、回転方向や単位変換を疑います。モデル全体が一定角度だけ回っている場合は、ローカルX軸と地図座標系の東軸、北軸の関係を確認します。
IfcProjectedCRSとIfcMapConversionは、どちらか一方だけを確認するのでは不十分です。変換元コンテキスト、変換先座標参照系、WorldCoordinateSystem、TrueNorth、移動量、方向成分、Scaleを一つの連続した関係として検証します。
確認項目6：原点移動量、高さ、回転、縮尺が正しいか
最後の確認項目は、IfcMapConversionに記録された変換値の内容です。関連付けが正しくても、数値が誤っていればAR表示位置は合いません。
代表的な変換要素は、Eastings、Northings、OrthogonalHeight、XAxisAbscissa、XAxisOrdinate、Scaleです。Eastings、Northings、OrthogonalHeightは、ローカル工学座標系の基準位置をTargetCRS上のどこへ配置するかを定めます。
東西方向と南北方向の移動量は、モデル原点または地理参照点に対応する既知座標と照合します。東座標と北座標を逆に入力していないか、負号が誤っていないか、別の系番号や地域区分を使っていないか、小数点位置が正しいかを確認します。
ただし、IfcMapConversionの移動量が必ずモデル幾何の単純な原点座標と一致するとは限りません。WorldCoordinateSystemが原点以外に設定されている場合は、そのオフセットを含めた座標関係を確認する必要があります。作成元の基準点、プロジェクト原点、測量点という名称だけで判断せず、IFC内の参照関係と数値を追跡します。
高さ方向のOrthogonalHeightは、TargetCRSで定義された鉛直基準に対する高さを表します。モデル内のゼロ高さが設計基準階、現場の仮基準点、測量標高のどれに対応するかを確認します。平面位置だけが合い、高さが一定量ずれる場合は、OrthogonalHeight、WorldCoordinateSystemのZ成分、モデル配置のZ成分、現場で使用する高さ基準を分けて検証します。
高さの差を単純なオフセットとして補正してよいかは、座標参照系と対象範囲によって異なります。水平位置の座標参照系だけが定義され、鉛直基準が不明な場合は、OrthogonalHeightの数値だけを合わせても再現性を確保できません。測量成果や座標定義書へ戻り、正しい鉛直基準を確定します。
回転は、XAxisAbscissaとXAxisOrdinateの組み合わせによって、ローカルX軸が地図座標系の水平面内で向く方向を表します。これらは角度値そのものではなく方向ベクトルの成分です。度やラジアンの角度をそのまま入力する方法ではないため、書き出し前の角度管理値が正しく方向成分へ変換されているか確認します。
両方の方向成分が省略された場合の既定方向や、片方だけが設定された不完全な状態を読み込み側がどう扱うかも確認します。現行仕様の数式と実装が一致しているかを、既知方向を持つ二点で検証することが安全です。
Scaleは、ローカル工学座標系と地図座標系の長さ単位が異なる場合に、X、Y、Zへ同じ比率で適用される係数です。省略時は1.0です。メートルとミリメートル、フィートとメートルなどの単位関係を確認し、モデル端部の残差を小さくする目的で根拠なく微調整しないようにします。
実際の座標に単位変換以外の尺度補正が必要な場合は、採用するIFCスキーマが対応する座標操作、作成元の測量変換、または外部の検証済み変換手順で扱います。IfcMapConversion.Scaleの意味を超えて数値を調整すると、他のソフトウェアで異なる解釈をされるおそれがあります。
変換値の検証には、一点だけでなく離れた複数の既知点を使用します。一点目で平行移動を確認し、二点目で回転を確認し、さらに距離のある点で単位と全体整合を確認します。一点だけを合わせる方法では、回転、単位、軸の取り違えを発見できません。
IfcProjectedCRSが欠落していた場合の修正手順
IfcProjectedCRSの欠落が確認された場合は、AR表示側で推測して補う前に、可能であれば3D図面の作成元へ戻って修正します。作成元には、座標参照系、モデル原点の絶対座標、ローカル軸と地図座標軸の関係、高さ基準、長さ単位がそろっている可能性が高いからです。
最初に、正しい水平座標参照系と鉛直基準を確定します。名称が似た座標参照系や隣接する地域区分を誤って選ばないように、測量成果、設計条件、基準点成果、座標一覧を照合します。大きな座標値や現場所在地だけから座標参照系を推定して確定することは避けます。
次に、IFCの出力スキーマを決めます。IfcProjectedCRSとIfcMapConversionを使用するならIFC4以降が必要です。受入側がIFC4.3のWKTや追加された座標操作へ対応していない場合は、双方で利用できる範囲へ合わせ、識別情報を曖昧な独自文字列へ置き換えないようにします。
3Dモデル内では、地理参照に用いる基準点を確定します。モデル原点、WorldCoordinateSystemの原点、作成環境の測量点が一致しているとは限りません。どの点がIfcMapConversionのEastings、Northings、OrthogonalHeightに対応するのかを、作成元の設定と書き出し結果の双方で確認します。
方位については、モデル内の二点を結ぶ方向と、絶対座標上の同じ二点を結ぶ方向を比較します。これにより、ローカルX軸と地図座標軸の回転関係を確認できます。短い基線では点の指定誤差が角度へ大きく影響するため、可能な範囲で離れた既知点を使います。
単位については、IfcProject.UnitsInContext、IfcProjectedCRS.MapUnit、IfcMapConversion.Scaleの組み合わせを決めます。MapUnitを省略する場合はプロジェクトの長さ単位が地図座標軸へ適用されるため、意図せずミリメートル扱いになることがないか確認します。
高さは、モデル内の基準高さと現場で使用する鉛直基準を対応させます。モデルのゼロ高さがどこに設定されているか、OrthogonalHeightがどの点の高さを表すか、WorldCoordinateSystemや各配置で追加のZ移動がないかを整理します。
必要な情報を確定したら、IfcProjectedCRSとIfcMapConversionを含む条件でIFCを再出力します。再出力後は作成画面だけで確認を終えず、書き出されたIFCファイルを解析し、エンティティ、属性、参照先、単位、変換値を改めて確認します。
再出力が難しく、既存のIFCへ座標情報を追加する場合は、スキーマ整合性を検証できる方法で編集し、編集履歴と根拠を残します。どの座標参照系を採用し、どの既知点から移動量と方向を求め、単位をどう扱い、誰が確認したかを記録します。
修正後は、少なくとも複数の既知点で座標を再計算し、AR表示前に水平位置、高さ、方位、モデル寸法が許容範囲にあることを確認します。
AR表示前に実施したい現地確認
IFC内の座標情報を確認した後は、実際の現場でAR表示を検証します。データ上の整合性が取れていても、GNSSの測位状態、端末の姿勢推定、周辺の遮へいと反射、基準点の選定、表示基準点の高さによって表示差が生じるためです。
現地確認では、最初から構造物全体の見た目だけで判断せず、モデルと現場の双方で同一点を特定できる既知点を使います。測量鋲、基準杭、構造物の角、中心線の交点などが候補になりますが、現物の損傷や施工変更がないことも確認します。
まず、既知点付近で平面位置を確認します。東西方向と南北方向のどちらへ、どの程度ずれているかを記録します。次に、別の既知点へ移動し、ずれの方向と大きさが変化するかを確認します。
すべての確認点でほぼ同じ方向と距離だけずれている場合は、Eastings、Northings、WorldCoordinateSystem、表示基準点のオフセットに問題がある可能性があります。離れた点で横方向の差が変化する場合は、XAxisAbscissa、XAxisOrdinate、軸の取り違え、単位の不整合を疑います。
平面位置が合っていて高さだけ一定量ずれる場合は、IfcProjectedCRSの鉛直基準、OrthogonalHeight、モデル内の高さ原点、GNSSで使用する高さ、アンテナ位置からAR表示基準点までの高さ設定を確認します。
モデルが時間とともに揺れる、瞬間的に移動する、同じ場所でも表示が安定しない場合は、IFCの座標設定だけでなく、GNSSの測位状態やARの姿勢推定を確認します。座標変換の誤りは比較的一定した傾向として現れやすい一方、測位や姿勢の不安定さは時間や端末の向きによって変化しやすい傾向があります。
現地確認では、IFC由来の差と測位由来の変動を分けて記録します。測位が安定していない状態でIfcMapConversionの値を調整すると、本来正しかったモデル座標を誤って変更するおそれがあります。
AR表示は施工位置を直感的に確認するために有効ですが、画面上で重なって見えることだけをもって、出来形や施工精度を確定するものではありません。要求精度に応じて、基準点測量、出来形計測、設計照査などの確認方法と組み合わせて使用します。
絶対座標を保ちながら3D図面を軽快に表示する考え方
絶対座標を持つ3D図面では、東西方向や南北方向の数値が大きくなることがあります。この大きな値を形状座標へ直接持たせると、処理系によっては内部計算の精度や描画の安定性に影響する場合があります。
IfcGeometricRepresentationContextのWorldCoordinateSystemは、形状をローカル原点付近で扱って数値安定性を確保しながら、地理参照点とのオフセットを表現するためにも利用できます。IfcMapConversionと併用する場合は、WorldCoordinateSystemと地図変換の関係を保持し、どちらか一方の移動量だけを削除しないことが重要です。IFC 4.3.2 Documentation
実務では、元の絶対座標情報を失わないように管理しながら、表示時には端末周辺を基準としたローカル座標へ変換する方法が有効です。IFC内のIfcProjectedCRS、IfcMapConversion、WorldCoordinateSystemを基準情報として保持し、表示処理では現場付近の基準点を一時的な原点として扱います。
この方法では、モデルの各点から大きな座標値を単純に削除するのではなく、絶対座標と表示用ローカル座標の変換関係を維持します。原点を移動した後のモデルだけを保存し、変換量を記録しなければ、元の絶対位置を復元できません。
モデル軽量化を行う場合も同様です。不要な部材や細かな形状を削除しても、基準点、モデル原点、座標軸、UnitsInContext、IfcProjectedCRS、IfcMapConversion、WorldCoordinateSystemの関係は維持する必要があります。軽量化後の再書き出しで座標参照系や座標変換が欠落することがあるため、処理前後で同じ六項目を確認します。
複数の3D図面をAR表示する場合は、すべてのモデルが同じ水平座標参照系と鉛直基準を使用しているかを確認し、各モデルのローカル工学座標系から地図座標系への変換を個別に管理します。モデルごとにローカル原点が異なっていても、正しい変換情報があれば同じ現場座標上へ重ねられます。
点群と3D図面を重ねる場合も、両方の座標参照系、軸順序、長さ単位、鉛直基準を確認します。両方が絶対座標であっても、異なる座標参照系や高さ基準を使用していれば位置差が生じます。
データを受け渡す際は、IFCファイルだけに依存せず、座標参照系の識別子、単位、基準点、地理参照点、鉛直基準、方位、確認結果を記録した管理情報を用意すると安全です。IFC内の情報と管理情報を照合できれば、書き出し時の欠落や誤変換を早期に発見できます。
まとめ
3D図面を絶対座標でAR表示するためには、IfcProjectedCRSが存在するかだけでなく、その内容と周辺の座標変換情報を一体で確認する必要があります。
最初にIFCの版と書き出し条件を確認します。IfcProjectedCRSとIfcMapConversionはIFC4で導入されたため、IFC2x3では同じ方法を使用できません。IFC4以降であっても、書き出し設定や実装によって地理参照情報が省略される可能性があります。
次に、IfcProjectedCRSの存在、座標参照系を一意に識別するNameまたは対応する定義、鉛直基準、MapUnitとプロジェクト単位の整合を確認します。現行のIFC4.3系では、MapUnitが省略された場合にUnitsInContextの長さ単位が適用されるため、欠落時にメートルと決めつけてはいけません。
さらに、IfcMapConversionのSourceCRSとTargetCRSを追跡し、Eastings、Northings、OrthogonalHeight、XAxisAbscissa、XAxisOrdinate、Scaleを検証します。WorldCoordinateSystemとTrueNorthも合わせて確認し、移動や回転を二重に適用しないようにします。
Scaleは主にローカル工学座標系と地図座標系の単位差を三軸一様に変換する値であり、省略時は1.0です。現地で見つかった残差を減らす目的で根拠なく調整せず、単位、軸方向、座標参照系、既知点の対応を先に確認します。
IfcProjectedCRSが欠落している場合は、座標値から座標参照系を推定して確定するのではなく、設計条件や測量成果へ戻って正しい情報を確認します。可能であれば作成元から再出力し、再出力後のIFCファイルを改めて解析します。
また、絶対座標情報が正しくても、AR表示ではGNSSの測位状態、端末の姿勢推定、周辺環境、表示用ローカル原点が結果へ影響します。データ上の座標検証と現地での既知点確認を分けて行い、一定した座標変換の差と時間的に変動する測位の差を混同しないことが大切です。
LRTK Phoneを活用して絶対座標付きの3D図面を現場でAR表示する際も、表示前にIfcProjectedCRS、IfcMapConversion、WorldCoordinateSystem、単位、高さ基準を確認しておくことで、位置ずれの原因を整理しやすくなります。設計データ、測量座標、点群、現地位置を一つの座標基準で扱える状態を整え、3D図面を施工位置の確認や関係者間の情報共有へつなげていきましょう。