DXF図面をJavaプログラムにインポートし、この「単純な」形式のすべての熊手を踏む

AutoCADおよび類似のCADシステムは、設計の分野で長い間標準になっており、広く使用されているDWG / DXFファイル形式が同じ標準になったことは驚くことではありません。 そのため、建築家やデザイナー向けの何らかのソリューションを開発している場合、これらの形式（または少なくとも1つの形式）で作業できることは、製品の必須機能です。







私のWebサービスの一部として、 歩行者の動きをシミュレートするために 、これらの形式のマスタープランをインポートすることも心配しなければなりませんでした。 私は以前にCADとビジネスをしていなかったので、「そこに何があるのか​​、考えてみてください-図面、線、多角形の別の形式、そこで何が複雑になるのでしょうか？」 しかし、その過程で、そこには十分な複雑さがあり、いくつかのニュアンスは数世紀の深さから伸びる古代の松葉杖に非常に似ていますが、多くのことは形式自体の仕様に実際には文書化されていません（たとえば、ブロックや曲線での作業）。 どうやら、それらはどの製図工にとっても明らかであると考えられていますが、別の分野から来て、そのような知識がない場合はどうですか？



一般的に、カットの下には、グーグルで検索できなかったレーキと解決策のリストがあり、真夜中までに図面を採掘する必要がありました。





解決すべき課題



Javaアプリケーションでは、地区マスタープランのインポートを構成し、それを内部の単純化されたGeoJSON表現に変換する必要がありました。 同時に、完全な情報やあらゆる種類のエンティティは必要ありませんでした。シミュレーションで使用されるのはそれらの一部のみです。 そのため、この資料では、DXFのすべての機能と重要な技術ソリューションを網羅しているわけではありません。 そして、なぜDWGではなくDXFなのか？ そして、それについて以下。



フォーマット選択



それでは、主に「AutoCAD」および「ファイル形式」という言葉に関連付けられているものは何ですか？ そして、これはDWGです。 もともとAutoDeskによって作成されたバイナリクローズ形式とその仕様は公開されていませんでしたが、一時はOpen Design Allianceによって元に戻されました。

そして、失望の1つ目は次のとおりです。この形式の現在の無料実装はありません。 一般的に。

AutoDeskからそれを操作するためのライブラリがあります。 ODAによって作成された人気のあるTeighaライブラリがあります。 そして...それだけです。 両方とも支払われており、十分に支払われています（私たちは数百および数千ドルについて話しています）。 ふさわしくない。

無料のオープンソースソリューションとして標準を実装しようとする試みがいくつかあります。 たとえば、 jdwglibです。 しかし、それらはすべて5〜10年前に最後に更新され、長い間死んでいます。 そして、進歩はまだ止まっておらず、AutoCADの新しいバージョンはDWGに新しい機能を追加します。その結果、最新バージョンのファイルを読むという夢と、修正されたバグのサポートと希望に別れを告げることができます。



代替手段はDXFです。 人気はやや劣りますが、同時にすべてのCADシステムでサポートされており、当初はオープンであるため、理論的にはより一般的です。

最初にライブラリを検索するのもがっかりします-特にJavaでは、5年前の最新リリース、捨てられたリポジトリ、永遠を見る悲しいニュース、不当な楽観主義と約束に満ちた単一のライブプロジェクトはありません。 ただし、DWGとは異なり、フォーマット自体はそれほど積極的に開発されていないため、かなり古いライブラリでも最新の図面を開くことができます。



その結果、Kabejaライブラリが選択され、その最後のリリースは2011年でした。 付属のサンプル（DXFからSVGへの変換）を使用して、現在のすべての図面ファイルが正しく開くことを確認し、その後インポートを開始しました。 StackoverflowのCADの第一人者からのDXFの解析に関する質問について、「DXFはシンプルに見えますが、実際には作業にうんざりしている」というコメントが少しありました。



レイヤー



DXF図面には、一連のレイヤー（レイヤー）とブロック（ブロック）が含まれています。 そこには他のエンティティがありますが、最も単純な場合にジオメトリの座標を引き裂くために、それらは必要ありません。







レイヤーのすべては明らかで、Photoshopの場合と同じように機能します。 レイヤーのオンとオフを切り替えたり、レイヤーのデフォルトのグラフィックスパラメーターを設定したりできます（つまり、たとえば、このレイヤーのデフォルトではすべての線にそのような太さを設定できます）。 私のタスクは座標を絞るだけなので、表示の問題には対処しませんでした。



さて、すべてがシンプルに思えます。各レイヤーについて、レイヤーのリストを実行します。オブジェクトのリストを使用して、座標を変換します。 ただし、すでにここで最初のレーキを踏んでいます。CADに表示され、ファイルに含まれている一連のレイヤーは同じものではありません 。 突然道路の一部を失った理由を頭を痛めた。 それらはNanoCADにありますが、私のエクスポートにはありません。 デバッガーに入りました-Kabejaが返す構造体にもありません。 ただし、サンプルとともにファイル全体をエクスポートする場合はそうです。 一般に、ファイル内のエディターの1つのレイヤーは、「layerName」、「layerName @ 1」などの名前を持つ複数のレイヤーで表すことができることが判明しました。 なぜこれが行われ、どこから来たのか-悪魔はそれを知っていますが、事実-レイヤーの名前と完全に一致するものを検索する（ライブラリコード構造でさえ、名前キーでMapにレイヤーを保存することを示唆します）ヒント。



ブロック



ブロックは、一度描画すると複数回挿入できるテンプレートです。 この場合、ベースユニットを変更すると、すべての挿入が変更されます。 便利に。 さらにクールなのは、ブロックに複数のレイヤーのオブジェクトを含めることができることです。 この場合、挿入はいくつかのレイヤーにも属します。 この場合、ブロックには他のブロックの挿入が含まれる場合があります。 つまり、「ハウスセクション」ブロックを作成し、それらから「ハウス」ブロックを作成して、カードに数回挿入することができます。 この場合、最終オブジェクトには、元のブロックだけでなく、いくつかのレイヤー（個別の塗りつぶし、個別の輪郭、個別の特殊マーク）が含まれます。 これらはすべてユーザーの観点から見ると非常にクールですが、プログラマーに作業が追加されます。

さらに、ブロックは1回だけでなく、長方形のマトリックスの形で繰り返し挿入できます。 これを行うために、挿入オブジェクトには、行数、列数、およびそれらの間の距離を持つパラメーターがあります。



その結果、これまでの挿入処理コードは次のようになります。

for (int row = 0; row < insert.getRows(); ++row) { for (int col = 0; col < insert.getColumns(); ++col) { //                 ,    . AffineTransform transform = new AffineTransform(); transform.translate( insert.getPoint().getX() - (insert.getColumns() - col) * insert.getColumnSpacing() , insert.getPoint().getY() - (insert.getRows() - row) * insert.getRowSpacing()); transform.rotate(Math.toRadians(insert.getRotate())); transform.scale(insert.getScaleX(), insert.getScaleY()); // Feature    ,    GeoJSON  for (Feature f : block.features) { //   ,  .         Feature inserted = cloneFeatureWithTransform(f, transform); features.add(inserted); } } } return block.features.size();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイル内のブロックとレイヤーが順序付けられていないことを知ることも重要です。 つまり、処理ブロックは、まだ処理されていない別のブロックからの挿入でつまずくことがあります。 正直なところ、私はそれがなんとかサイクルを作ることができるかどうか、そしてその場合に何が起こるかわかりません。



行



私の仕事は、DXFをGeoJSONに変換することです。すべてのタイプのジオメトリは、破線と多角形のみを認識し、円弧と曲線は認識しません。



DXFは、さまざまな回線オプションをサポートしています。

1. すでに2種類の破線-ポリラインとLWPolyline。 私の単純な2D図面の場合、それらの間に違いはありません
2. 円弧、さらには楕円と円形の2つのタイプ。 幸いなことに、Kabejaクラスには既にそれらのポイントの座標を取得するための既製のメソッドがあるため、必要な精度でアークをポリラインに変換することは難しくありません
3. スプライン-繰り返しますが、カベジャ自身はポリラインに変換する方法を知っています
4. ちょうど線形セグメント

すべてがシンプルに思えますが、違います。 一見単純なポリラインタイプでも、2次曲線を表示するために使用できます（破線だけでなく）。 これを行うには、頂点をbulgeに設定できます。 それが示されている場合、2つの頂点は直線ではなく、これらの頂点を通過する円の円弧で接続され、その中心はそれらとこのパラメーターで表現できます。







これは、円の中心を特定できるコードです。

 private Point getCenterByVerticesAndBulge(DXFVertex a, DXFVertex b, double bulge) { double norm = Math.sqrt(Math.pow(b.getX() - a.getX(), 2) + Math.pow(b.getY() - a.getY(), 2)); double s = norm / 2; double d = s * (1 - bulge * bulge) / (bulge * bulge); // "direction" double u = (b.getX() - a.getX()) / norm; double v = (b.getY() - a.getY()) / norm; //"center" double c1 = Math.signum(bulge) * -v * d + (a.getX() + b.getX()) / 2; double c2 = Math.signum(bulge) * u * d + (a.getY() + b.getY()) / 2; return new Point(c1, c2, 0); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は長い間これらの弧をめぐって戦いましたが、最終的に私は吐き出し、それらをオフにして、頂点を直接接続しました。 一般的な計画では、このような円弧は通常、交差点の角を丸くするために使用されるため、それらを完全にスコアリングすることができます-シミュレーションの観点からの違いはわずかです。



塗りつぶし/ハッチ（ハッチ）



これは私のシミュレータが直接動作するものです。 とりあえず、私は建物、道路、発電機を詰め物で正確に指定することを要求します（そうでなければ、個々の線のミッシュマッシュのどこが内側で、どこが外側であるかは明確ではありません）。



そして、ここにもニュアンスがあります：

1. 塗りつぶしの境界線は、線オブジェクトの任意の組み合わせにすることができます。 境界線の一部を壊してから、いくつかの弧を描いてから、さまざまな線分だけのセグメントを壊すことができます
2. 1つの塗りつぶしオブジェクトには、任意の数の切り離された領域（ポリゴンに外部境界が1つしかない他の多くの形式とは異なります）を含めることができます。
3. 塗りつぶしは繰り返しネストすることができます。つまり、穴塗りつぶしの中に別の塗りつぶしがあり、そこに再び穴があり、DXFのすべては複数の境界を持つ1つのHATCHオブジェクトによって指定されます。
4. 塗りつぶしとその境界の関係にはさらにエキゾチックなオプションがあります（写真を参照）が、これまでのところ私には出会っていない、神に感謝

一般に、塗りつぶし用のDXFから「外部または内部」フラグが付いた一連の境界線を取得し、それらが一般的にどのように作成され、GeoJSONのようなポリゴンに沿ってそれらを分散する方法を理解する必要があります。ネストがあります。



私はいくつかの方法で行きましたが、各アルゴリズムについて、このアルゴリズムが機能しない図面をすぐに入手しました。 たとえば、これはここにあります：チタの住宅地の道路と私道の図、それらはすべて文字通り非常に複雑な構造を持つHATCHオブジェクトのペアによって定義され、何らかの理由ですべての境界が外部としてマークされています（カベジャには何らかのバグがあると感じていますDXFが外部と外部の2つの同様のフラグをすぐに定義する方法ですが、ライブラリ自体には1つしかありません）：







その結果、動作する唯一のアルゴリズムは次のようになります。

1. 外側の境界線ごとにポリゴンを作成します
2. 外部または内部のどちらでマークされているかに関係なく、他のすべての境界を減算します
3. 考えられる問題を修正します（ポリゴンが空であることが判明した、穴が外側の輪郭の境界を越えて行く、ポリゴンが切断された領域にクラッシュするなど）

3番目のポイント（および実際に既にシミュレーションアルゴリズム自体の内部にあるジオメトリを操作するため）では、JTSライブラリであるJava Topology Suiteを使用しました。 これには、バッファの構築などの操作から四分木などのデータ構造まで、ジオメトリを操作するために必要なすべてのプリミティブと操作が非常に多く含まれています。



勝利



松葉杖でできることすべてを苦労して支えた後、必要なDXFサブセットのサポートを作成し、図面をシミュレータに直接ロードして、デザイナーの学校を決定するために使用できました。 私は上記の情報のほとんどを戦いで2晩までNanoCADの上に座らなければならなかったため（広告ではありませんが、これは私が見つけた唯一の簡単にアクセスできる無料で高品質のDXFエディターであるため、同じLibreCADは最初の図面を正しく開くことができませんでした）彼に引き渡されました）、私もそれをhabrasocietyと共有することにしました-突然私の経験のすべてが誰かの時間を節約します。



ええ、はい、上記のスクリーンショットからの領域のアルゴリズムの予測のようなものです：







明らかな結論は、正しい角度でトラックを作成する必要はないが、必要のない奇妙な曲線を作成しようとする必要はないということです。 この地域が建設されたときに私の予測が実現するかどうか、数年後に見てみましょう。



提供された地区計画については、包括的な建築および建設設計ワークショップのおかげで