Thursday, October 23, 2008

Harvesting Autodesk DWG Entities

Author: Jonio, Dennis

This kicks off a series of articles on building SDO_GEOMETRY types from DWG entities. By series end you should have at least one working NETLOADable module for a template. I do not pretend that this is THE solution. Since this was completed, I have, of course, realized better ways to do some things and I am sure you will be able to find more. I strongly recommend that you look over the Oracle OTN forums in particular .NET and Spatial. The heart and soul of these UDT’s came from there. Another indispensable forum is the Autodesk Discussion Groups. Their .NET forum is also indispensable.

Oracle SDO_GEOMETRY and a few others as User Defined Types (UDT’s)

Included below are a couple projects NetSdoGeometry and NetSdoDimArray. These are the fundamental classes and I have posted these in the past. However since that time I have added an AsText property and the ToString() method. It became necessary to actually visualize the objects during development. I must also point out that SDO_GEOMETRY is now marked as [Serializable]. You will see later on that this allows for the inclusion of this type into a native .NET serializable dataset. I have included a fair number of non-essential members and methods. They are for convenience so the purist may wish to strip them.

Triplets and Triplet Management

In order to make any sense of this article you will have to have a copy of Oracle’s SDO_GEOMETRY specification and my implementation of the class NetSdoGeometry.sdogeometry.

Let me clarify, in general terms, what this implementation does and does not do in regards the specification

  1. Is Limited to two(2) dimensional geometries. Points, lines, surfaces(polygons)
  2. Does not include “compound-type” geometries
  3. Does include support for curves/arcs

After reviewing the spec you will realize it is all about “triplets”. The SDO_DIM_ELEM_ARRAY is of course a 1-> n series of 3 element integers groups. OFFSET - ETYPE -INTERPRETATION as the named components.

The manipulation of the ordinates array I found to be rather trivial both in terms of composition and decomposition. It is nothing more than that a left to right series of numbers.

“Triple Management” becomes the focus. Since I was learning the spec and writing code to it as I went along, the first class I created was, of course, “Triplet”. This class helped me visualize and understand the key elements of the specification. It is nothing more than codifying the obvious. The only oddity is my use of a GUID to track external or internal rings. The idea here will be explained later. In most cases a triplet acts as a kind’a sort’a header. A header that explains the ordinate array that is part of the SDO_GEOMETRY class. It would be just that simple if all one wished to do was work with linestrings. It is the support for curves/arcs that really adds a level of complexity by using a series of triplets to denote the transitions from line to arc, arc to line, etc.

Class “Pts” is a simple container for holding the ordinates. Of note here is the BulgeValue member. This acts as the placeholder for the arc information gotten from, in my case Map3d.

Finally class “TripletMgr” or Triplet Manager if you will. Before I discuss this class I will give you a chance to see how it is used. I do not use it for points and simple lines. Really unnecessary in those cases. This code decomposes as MPolygon into an sdogeometry. Frankly if you understand this one the rest is easy.

Here is the basic idea:


The method SetPts is the workhorse. Once again it is the management of the triplets. The concept of “ownership” can from Pro Oracle Spatial for Oracle Database 11g, by Kothuri, Godfrind, Beinat. This really helped me put some of the pieces together. I recommend it highly.

Source code (C#) available for download at:

No comments:

Post a Comment