(I) New SDO_GEOMETRY <-> Autodesk Map3d 2010

Author: Jonio, Dennis

Howdy all.
Well, it has really been awhile since that last post. By the way, I have no idea what happened to Maksim Sestic. Anyone willing to let me know?

Anyway a lot has transpired over the months not the least of which is that some time ago I built a shiny new Autodesk 2010/Map3d <-> SDO_GEOMETRY translator.

The learning example I have posted here was/is OK and served its purpose. However, like most software it had to be fixed and/or enhanced (and in this case just thrown away!)
The new converter supports everything that is in keeping with the Oracle Locator’s - Right To Use license. Obviously then there is no 3D object support. Curves are still fully supported and now ALL of the MULT types are supported. I do include support for the Z axis in this generation. In order to support the MULTI types I forced myself into building some “intermediate” objects. This also lays some of the groundwork for a different geometry object generator in the future. No, we are not having any problems or issues with Autodesk but maybe something else will come along. My NetSdoGeometry.sdogeometry object had to be tweaked a little so that it fully supported the Z axis. Beyond that it is good to go.

Three(3) primary objectives drove this iteration of the translator.
I) I wished to support a Z axis value
II) I wished to support the Oracle MULTI types
III) A more flexible overall design in general.
I had to modify my sdogeometry AsText property/ToString method to support the Z axis. If you recall I go out of my way to NOT utilize the "optimized point". I am sure it is a fine thing. For me, logically and programmatically, it is more trouble than its worth. In my way of thinking there is nothing wrong with an SDO_ELEM_INFO_ARRAY(1,1,1) and it is somewhat more consistent with the rest of the standard. I do of course read them in but I never output a SDO_POINT.
Source code (C#):

   public string AsText
 {
  get
  {
   StringBuilder sb = new StringBuilder();
   sb.Append("MDSYS.SDO_GEOMETRY(");
   sb.Append((sdo_gtype != null) ? sdo_gtype.ToString() : "null");
   sb.Append(",");
   sb.Append((sdo_srid != null) ? sdo_srid.ToString() : "null");
   sb.Append(",");
   // begin point
   if (sdo_point != null)
   {
    sb.Append("MDSYS.SDO_POINT_TYPE(");
    string _tmp = string.Format("{0:0.0#####},{1:0.0#####}{2}{3:#.######}",
            sdo_point.X,
            sdo_point.Y,
            (sdo_point.Z == null) ? null : ",",
            sdo_point.Z);
    
    sb.Append(_tmp.Trim());
    sb.Append(")");
   }
   else
   {
    sb.Append("null");
   }
   sb.Append(",");
   // begin element array
   if (elemArray != null)
   {
    sb.Append("MDSYS.SDO_ELEM_INFO_ARRAY(");
    for (int i = 0; i < elemArray.Length; i++)
    {
     string _tmp = string.Format("{0}", elemArray[i]);
     sb.Append(_tmp);
     if (i < (elemArray.Length - 1))
      sb.Append(",");
    }
    sb.Append(")");
   }
   else
   {
    sb.Append("null");
   }
   sb.Append(",");
   // begin ordinates array
   if (ordinatesArray != null)
   {
    sb.Append("MDSYS.SDO_ORDINATE_ARRAY(");
    for (int i = 0; i < ordinatesArray.Length; i++)
    {
     string _tmp = string.Format("{0:0.0######}", ordinatesArray[i]);
     sb.Append(_tmp);
     if (i < (ordinatesArray.Length - 1))
      sb.Append(",");
    }
    sb.Append(")");
   }
   else
   {
    sb.Append("null");
   }
   sb.Append(")");
   return sb.ToString();
  }
 }
 public override string ToString()
 {
  return this.AsText;
 }

Here is the conceptual paradigm that I chose for this iteration:
An Autodesk drawable entity decomposes into one or more SDO_ELEM_INFO_ARRAY triplet(s) with corresponding ordinates. An Autodesk drawable entity may be composed of one or more SDO_ELEM_INFO_ARRAY triplet(s) with corresponding ordinates.
With this mental shift from my original tool which is based upon a one-to-one/entity-to-sdogeometry relationship things flowed pretty well. Frankly this was a necessary shift in thinking to support the MULTI types.
So a class "DrawAble" is composed of "DrawAbleSubComponent"(s) and DrawAbleSubComponents equate to SDO_ELEM_INFO_ARRAY triplet(s) and their corresponding ordinates.
Source code (C#):

    [Serializable]
    public class DrawAbleSubComponent
    {
        public int[] Elem;
        public decimal[] Ords;
        public DrawAbleSubComponentEType Etype;
    }//eoc DrawAbleSubComponent
 
    [Serializable]
    public class DrawAble
    {
        private DrawAbleType m_drawtype;
        public DrawAbleType DrawEtype 
        { get{return m_drawtype;} set { m_drawtype = value; }}
        
        private int m_dimensionality = 2;
        public int Dimensionality
        { get { return m_dimensionality; } set { m_dimensionality = value; } }

        public List SubComponents = new List();
        public DrawAble(DrawAbleType _type, int _dimensionality)
        {
            DrawEtype = _type;
            Dimensionality = _dimensionality;
        }
    }//eoc DrawAble 

To be continued ...