Thursday, November 19, 2009

(VII) New SDO_GEOMETRY <-> Autodesk Map3d 2010

Author: Jonio, Dennis

The next and last items on the list ...
  • Given one or more Autodesk/Map3d objects decompose it(them) into “Drawable(s)”.
  • Given a “DrawAble” compose a Autodesk/Map3d object.

    This is the class that interacts with Autodesk Map3d. (I have removed a few things that are not importtant to the discussion here.)
    First, as time has gone on I have grown weary of parseing out Autodesk/Map3d objects and manipulating them. I gravitated toward AppendLoopFromBoundary() and BalanceTree() for MPolygon construction. Just a lot less code on my part. If it isn't a Point type I force just about everything to a Polyline at one time or the other. If you really need true 3D objects you shouldn't be reading this anyway.
    Just some things of note:
  • I never output an Oracle Circle
  • I never output an Oracle Rectangle
  • I never output an Oracle SDO_POINT
    I will read them and write them as Autdesk objects but after this they loose their identity as such.

    This is the last post on this topic. I have decided NOT to post the working source and project. If you are interested in the final work leave a comment with your email address.

    Since I produce only VALIDATED geometry I will be working on the post of my latest iteration of my IO class for doing validation against the database.
    Source code (C#):
  • Tuesday, November 17, 2009

    (VI) New SDO_GEOMETRY <-> Autodesk Map3d 2010

    Author: Jonio, Dennis

    The next on the list ...
  • Given some “DrawAble(s)” compose a NetSdoGeometry.sdogeometry.
    The method signature:
    public static sdogeometry SdoGeometryFromDrawAble(List _drawables, int _lrs, int _srid)
    If you recall the DrawAble holds the dimensionality so the Measure and the SRID had to be injected somewhere.
    Frankly the simplest of all the methods. Very straight forward implementaion.
    Maybe somewhat unusual here is that I made this a static method within the static utility class.

    Source code (C#):
  • Sunday, November 15, 2009

    (V) New SDO_GEOMETRY <-> Autodesk Map3d 2010

    Author: Jonio, Dennis

    As I stated in the last post:
  • Given a NetSdoGeometry.sdogeometry decompose it into a “DrawAble(s)”.
    As you would suspect this is mostly code. This is the actor that gets invoked every time DrawAbleSdoGeometry gets instantiated via DrawAbleSdoGeometry(sdogeometry aSDO_GEOMETRY) or the Geometry within an existing DrawAbleSdoGeometry gets changed.

    The todo here is to breakdown and pair SDO_ELEM_INFO elements with SDO_ORDINATES elements. The end result will be at least one DrawAble(s).
    Source code (C#):
  • Friday, November 13, 2009

    (IV) New SDO_GEOMETRY <-> Autodesk Map3d 2010

    Author: Jonio, Dennis

    Before I begin to discuss additional detail I will briefly illustrate what it looks like to materialize an Autodesk/Map3d object from a NetSdoGeometry.sdogeometry with this approach. The other class DrawAbleDwg shown below has not been discussed at all to this point. This is in fact the simplest pattern that can be used when dealing with the MULTI type.
    Source code (C#):

    The following illustrates just the opposite, a NetSdoGeometry.sdogeometry from multiple Autodesk/Map3d objects. The three(3) in this case will capture the Z axis. Actually I don't know what I am going to do with it but I have it if it is necessary.
    Source code (C#):

    DrawAbleSdoGeometryUtil.SdoGeometryFromDrawAble(drawList, 0, 2236); Passing in the DrawAble, the LRS, and the SRID produces a sdogeometry!

    Here is the list of things that remain to be shown:
  • Given a NetSdoGeometry.sdogeometry decompose it into a “DrawAble(s)”.
  • Given some “DrawAble(s)” compose a NetSdoGeometry.sdogeometry.
  • Given one or more Autodesk/Map3d objects decompose it(them) into “Drawable(s)”.
  • Given a “DrawAble” compose a Autodesk/Map3d object.
    To be continued ...
  • Thursday, November 12, 2009

    (III) New SDO_GEOMETRY <-> Autodesk Map3d 2010

    Author: Jonio, Dennis

    Before I forget I did put together a simple class to aid in manipulating the three(3) element array structures that comprise SDO_ELEM_INFO_ARRAY.
    Source code (C#):

    So now we get to the primary actor DrawAbleSdoGeometry. The container class for the NetSdoGeometry.sdogeometry type and the supporting cast of players to break sdogeometry down into DrawAble(s) and build a sdogeometry from DrawAble(s). Again the paradigm is all about this intermediate drawable construct so Autodesk/Map3d doesn’t come into play here. That is all handled in a separate class!
    Source code (C#):

    I set a default Dimensionality, LRS and SRID but have left them totally accessible. I am not one to hide things away in some private corner somewhere unless it just is nonsensical to do otherwise. Like DrawAblesFromGeometry(), the player that decomposes a sdogeometry/SDO_GEOMETRY object into DrawAble(s). It only made sense to me to invoke this directly from the “setter” for the class’ Geometry object.
    Note also that within the “setter” I deal with that Optimized Point issue.
    Source code (C#):

    As regards catching and eating any errors at this level I am ambivilant. I really do assume VALID geometry coming in because I produce VALID geometry on the other end. You may see it differently.

    To be continued …

    (II) New SDO_GEOMETRY <-> Autodesk Map3d 2010

    Author: Jonio, Dennis

    The DrawAbleType enums were easy. I just had to give them values that could be distinguised via “OR”ing them together.

  • Point = 1,
  • Line = 2,
  • Surface = 4


    Source code (C#):

    I really wrestled with these DrawAbleSubComponentEType enums. I tried to be really clever with these values and somehow take advantage of the relationship between ETYPE and INTERPRETATION. Tried is the operative word.

  • Point = 1, //1
  • PointCluster = 10, //1 + n
  • PointOriented = 19, //Not supported OrientedPoint
  • SimpleLine = 3, //2 + 1
  • SimpleLineAllCurves = 4, //2 + 2
  • CompoundLine = 40, //4 + n
  • SimpleSurfaceOuterRingLine = 1004, //1003 + 1
  • SimpleSurfaceOuterRingAllCurves = 1005, //1003 + 2
  • SimpleSurfaceOuterRingRectangle = 1006, //1003 + 3
  • SimpleSurfaceOuterRingCircle = 1007, //1003 + 4
  • SimpleSurfaceInnerRingLine = 2004, //2003 + 1
  • SimpleSurfaceInnerRingAllCurves = 2005, //2003 + 2
  • SimpleSurfaceInnerRingRectangle = 2006, //2003 + 3
  • SimpleSurfaceInnerRingCircle = 2007, //2003 + 4
  • CompoundSurfaceOuterRingLine = 10050, //1005 + n
  • CompoundSurfaceInnerRingLine = 20050 //2005 + n
    The specification has to many exceptions for this to work but at least I have my unique values.


    I do wonder alot as to why Oracle set up the unique combinations for Circle, Rectangle and instances of all Curves. I did read the spec on “Oriented Point” and just arbitrarily decided NOT to support it. I will never use it and I guess I am the boss. So if you need that you will have to do it yourself. It should be a straight forward job for someone with the motivation.


    When it gets time to resolve these into the “real” ETYPE and INTERPRETATION values I just set up a couple static methods in a static utility class.
    Source code (C#):

    To be continued ...
  • Monday, November 9, 2009

    (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#):


    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#):

    To be continued ...