I am well down the path of a building a AutoCAD-Map3d to Oracle SDO_GEOMETRY bidirectional translator. I could use some help.
I am looking for 15 - 20 valid examples of compound polygons with curves. Some with, some without "holes". Linear rings present no problem but I am having difficulty w/compound line-arcs plus it would be nice to validate my work.
No lat/long. Just plain'ol 2D ordinates.
Well, yes and no, i have used these to get as far as i have but they do not cover the varies geometries that i will have to deal with.
Since i am producing the SDO_GEOMERTY with my application from Autodesk-AutoCAD geometry i really need some set of "standard data" from which i can validate my production. And since i will be translating the SDO_GEOMERTY back into AutoCAD objects with this application it really would be nice to know that the application was storing the correct stuff ... and will then render any valid Oracle 2D geometry object. At this point I am not even concerned with the 4,5,6 and 7 gtypes.
I am "validating" the MDSYS.SDO_ELEM_INFO_ARRAY and the MDSYS.SDO_ORDINATE_ARRAY using JGeometry but i am really not sure that that is adaquate.
Does the current Oracle FDO open source provider, created by SL-King, not suffice?
If not, why not? What are some of the features you're looking for that you're not finding in the commercial Autodesk distribution of the Oracle FDO provider or the SL-King version?
Product Manager, AutoCAD Map 3D
Thank you for your response.
Yes, I have Haris' SL-King provider and am for the most part pleased. I really think you are on the correct path with FDO. To be frank, I just do not like the Autodesk Oracle provider. Personal preference mostly. There is just to much "stuff" in it. Looks to me like a committee project gone astray.
The big "hole" in the Map3d product, at least in my case, is the handling of "attribution". (think foriegn keys and business rules) I am convinced the geometry side is sound and robust.
Assume for a moment that the attributes are just as important, and in some cases, more so, as the geometry. The Autodesk toolset for manipulating attributes is, IMHO, less than adaquate.
This "translator" was the last piece in the puzzle of putting together a set of dll's that allow me to use Map3d/AutoCAD as a "COLUMN EDITOR". Think along the lines of a simple "PUT" and a simple "GET".
Believe me, my organization uses Map3d extensively but this piece was missing. So, using asynchronous named pipes, through a generic "DataBridge" between Map3d and whatever application I would like. I can tell MAP3d to PUT a geometry and then tell it to GET ... with native SDO_GEOMETRY!!
I am using a couple of serialized .NET datasets to move huge amounts of data between Map and my application. 11Meg in about 600Milliseconds on average. A "normal" instruction between 0-1 millisecond.
Oracle's support for UDT's in .NET is a game changer when it comes to geometry!!!
There is of course lots more and I am very willing to discuss this with you ouside of this forum. djonio AT miami-airport DOT com.
Well I stopped being lazing and cycled through my objects myself and have resolved all of my issues.
I now have a NATIVE dwg --> SDO_GEOMETRY --> NATIVE dwg set of tools. It supports 2D only but does support GTYPES 1 - 4 including full support for curves. I have no need for the collection types.
No, JGeometry was not adaquate. I had to use sdo_geom.validate_geometry_with_context and everyone is happy now.
Thank you again for your candor and detailed description of your FDO needs - they make quite a bit of sense. As a long time Oracle Spatial champion, and the product manager for a powerful CAD/GIS product, it is my ultimate goal to help make the experience of using enterprise solutions, like Oracle, and end-user solutions, like AutoCAD Map 3D, more seamless and powerful - hopefully enabling the addition of the two to add up to more than the sum of their parts.
With that in mind we are currently doing a lot of work on the FDO and AutoCAD Map 3D side to come out with "interesting" and powerful features that should more closely align with what you have suggested. In fact, one of the reasons we decided to open source the FDO technologies in the first place was to enable real-world users/developers, like yourself, to come up with great solutions to real-world problems without having to answer to a committee or whole product engineering team. That said as the Oracle provider is one of the most used FDO technologies I have forwarded you suggestions and intent to other Autodesk colleagues. If you are still willing we may contact you regarding your thoughts and will do our best - when it makes sense - to implement new features, such as those you have suggested, for the greater good of the entire spatial community.
Thank you again for your thoughts and if you (or others on this list) have other suggestions related to AutoCAD Map 3D, FDO and/or Oracle Locator/Spatial, by all means please feel free to contact me at Justin dot Lokitz at Autodesk dot com.