"To FDO Connection" Oracle Curves and Arcs

[gluckett]

When using the To FDO Connection, any polylines with Arcs fail when writing to Oracle. 

However, the same feature shows up in SQL Server as a COMPOUNDCURVE:

COMPOUNDCURVE ((47915.403598722136 940083.xxx-xxxxxxxx, 48462.338874613582 940434.xxx-xxxxxxxx), (48462.338874613582 940434.xxx-xxxxxxxx, 52187.489386499517 942886.xxx-xxxxxxxx), CIRCULARSTRING (52187.489386499517 942886.xxx-xxxxxxxx, 52341.825855027433 942961.xxx-xxxxxxxx, 52510.xxx-xxxxxxxx 942996.xxx-xxxxxxxx), (52510.xxx-xxxxxxxx 942996.xxx-xxxxxxxx, 52579.096044102065 943003.xxx-xxxxxxxx), (52579.096044102065 943003.xxx-xxxxxxxx, 52650.931333811124 943009.03807021))

But when writing to Oracle, these features fail using the "To FDO Connection"

Anyone run into this issue?

thanks

gordon

[gluckett]

Ok the issue is with the State Plane (feet) coorindate system.  If you use UTM (meters) everything is great in Oracle.

Yay metric system!

[gluckett]

That actually didn't do it.  I had FLATTENed all the arcs...

Even in AutoCAD Map 3D 2021, the mapexportfdo does not work with Arcs combined with plines to Oracle.

Workaround:

1. Export to SHP and use BULKCOPY

2. Use FME to read the DWG and use "ARCSTROKER" Transformer and then into Oracle

Both workarounds work fine, but it would be better if the mapexportfdo would work...it's fine in SQL Server...

[ChicagoLooper]

Turn the arcs into polylines. Even circles, turn them into polylines.

.

[gluckett]

Yes, if you do that, oracle treats that as a "mixed" feature or Collection - also there is a risk of losing Object Data.

I think the oracle FDO export is not handling as well as the SQL Server FDO export..

[ChicagoLooper]

Why??

Two lines with an arc is three entities, not one like a continuous polyline. As far as the object data, if you started with two lines and arcs instead of a continuous polyline, you're too late. The arc issue is done. You'll need to redraw using a polyline to get this resolved. And the object data, you'll need to re-establish the data with the objects.

[gluckett]

Yes, a redraw would be good, if there was not thousands of entities and 20 years of object data.

For example, I have a line that is line-arc-line that has been p-edited together.  It is a compound object.  SQL Server handles this fine, so does SDF and SHP.  It's just the FDO for Oracle export that is the issue.  There are thousands like this.  So the re-draw is not an option.

The best-case scenario is to have the Oracle FDO Export honor the "FME_ARC_DEGREES_PER_EDGE" in the mapexport.ini 

[ChicagoLooper]

OK. In that case try the MAPCLEAN command. this command (actually more like a utility rather than a command) can 'convert' arcs and circles to plines.

[gluckett]

Unfortunately Oracle still does not like arcs converted to plines using that method..  same issue with the embedded arc inside of the pline...

[ChicagoLooper]

Due to the original author, looks like you're out of luck. Wish I could help you.

[gluckett]

Yep. Just a bug in the FDO Export for Oracle.

[ChicagoLooper]

Whether Oracle or not, FDO connections, e.g. shapefiles, don't like circles, arcs or ellipses. Polylines and lines, yes. Circles, arcs and ellipses, no.

[gluckett]

Yes, but the mapexport.ini can "stroke" the arc and circles when exporting to shapefiles or to SQL Server...but the Oracle connector is not being honoured.  That is a bug.

[Christopher.Fugitt]

I'm using the API and it I'm trying to get the data from an Oracle Database and it looks like the issue is in the Autodesk AGF. 

 [1] = "CIRCULARSTRING (6246175.67043032 1958353.63540768, 6246197.37498668 1958377.64330385, 6246202.61267866 1958409.58126604)"
The AGF text is invalid because it failed to parse into a valid geometry object.

 Since it appears Autodesk has mostly abandoned Map 3D, maybe the AGF hasn't been updated to include changes to the WKT.

Representation of Geometry | Search | Autodesk Knowledge Network

var wktReaderWriter = new MgWktReaderWriter();
var geometry = wktReaderWriter.Read(wktGeometry);

Looks like its time to abandon Autodesk products and try to find a company that cares about their products. 

[gluckett · Accepted solution]

No other product on the market can 'Bridge'  CAD and GIS (a Trillion dollar market) like AutoCAD Map.

This has always been a lost opportunity to branch out to a massive vertical and fill one of the biggest pain-points on the market.

Just search the web for the term 'GIS and DWG' and the whole GIS world resents receiving a DWG. 

Of course with AutoCAD Map 3D (and Civil 3D since Map's built in) this stress go away.

(how many people ask 'what coordinate system is the DWG in - but not with Map 3D since you can set that).

In the meantime, the best workaround right now is this lisp routine that Decurves all the plines:

(defun C:FIXPLINE ( / i ssl ss e)
 (setq ss (ssget "_X" '((0 . "LWPOLYLINE"))))
 (setq i 0  ssl (sslength ss))
 (while (< i ssl)
  (setq e (ssname ss i))
  (command "_PEDIT" e "_De" "")
  (setq i (1+ i))
 )
 (princ)
)

[Gary_Braun]

Thanks for this thread Gordon.

I've been using FDO forever, along with MAPIMPORT/EXPORT, but have no idea how the MAPIMPORTFDO has escaped me until now. I've used various methods to update our esri SDE data, but this has the potential to allow me to bypass the geodatabase altogether and just use plain SQL Server Spatial.

I've created the table and am able to MAPEXPORTFDO all of my polygons (most really, some didn't go so I need to figure out why). But the problem is that the curves on the closed polylines are being stroked. I can use MAPUpdateFeatureGeometry to update them to match the original shape - and it seems to work, but there are 17000 of them and I don't want to have to work through that manually. Do you have any thoughts or suggestions as to why my initial export to SQL Server might have stroked the curves and how I might fix that? I already edited my mapimport.ini and set SegmentationDegrees=0.

Thanks, Gary

[gluckett]

Hi Gary,

yes the little lisp routine fixes that issue, so that the export to Oracle does not miss those features.

It is a pain, but once it's done, you don't have to worry about updating your data again.

Maintaining your data is better, but sometimes you will find "adding a new feature from geometry" will fail if the feature is not already converted...

[Gary_Braun]

I'm exporting to SQL Server though and thought it would "just work" without the LISP. I can update geometry from feature, or add feature from geometry, and the curves are fine. It was just my initial export to FDO where they got stroked. Do I still need to use the LISP when that first FDO export is going to SQL Server?

Thanks.

[gluckett]

No, once will do it.