MAP3D export to shape file - attribute value decimal place corruption

[Setsquare]

When exporting CAD entities to Esri shape file utilising MAPEXPORT, any associated object data attributes are extented to 15 decimal places regardless of the original att value within AutoCAD. For example, a coordinate value of 1000.123 [actual value] is exported as 1000.129999999999923 or similar. This is the same if the X1/Y1 attributes are selected from the properties for points which have been drawn to specific coordinate locations.

Q1 - why is this (I assume it is a number handling anomaly or a legacy issue which hasnt been addressed)

Q2 - can the export be forced to report to the original number of decimal places?

[Pointdump]

Hi Clark,
More details please. What CAD entities: points, lines, polygons? Can you post your drawing and a MAPEXPORT'ed shapefile?
Dave

[Setsquare]

Hi Dave

Thanks for the prompt reply.

Attached v simple sample dwg with both points (att blocks) and polyline entities, along with the exported shp files

For information, the "target" blocks were inserted using coordinates no greater than 3dp into the dwg file. The "KP" blocks are inserted along the polyline at fixed distances.

It may be a software computation / number handling issue but its a pain as it is in effect corrupting data.

Cheers

[Pointdump]

Clark,
Thanks for posting your drawing and shapefiles.
I might be wrong, but I think this is an import display problem, not an export problem. When I drag-n-drop your points back into your C3D drawing the "X_OBJECT" and "Y_OBJECT" fields are showing only 2 or 3 decimal places. When I drag-n-drop your points into QGIS all the fields are showing 15 decimal places.
Dave

[ChicagoLooper]

Hi @Setsquare 

You need to understand the difference between the displayed value vs. the geometric value.

Displayed Value:

This is the number of decimal places displayed in the Properties Palette and, when applicable, in Block Attributes.

Geometric Value:

This is the northing/easting value used for positioning in modelspace.

----------------------------------------------------------------------------------

NOTES:

1. When you use MapExport to create a shapefile, you are exporting the geometric values, which of course, are 'tied to' the units of coordinate system assigned to modelspace. <<If projected coordinates then units will be either feet or meters. If geographic coordinates then units will be Degrees.>> AutoCAD will not, and should not, ROUND OFF the X/Y coordinates during the MapExport procedure.
2. If the coordinates in the newly created shapefile show 1000.1230000000, then the actual position is 1000.123. However, if 1000.129999999999923, then that's the geospatial position despite what some users claim the 'actual' coordinates to be.
3. If your drawing has a SPCS assigned to modelspace and you input points with LAT/LONGS you should let AutoCAD convert from DEGREES to FEET without rounding so high precision can be maintained.* Keep in mind if your LAT/LONGS are low precision to begin with, then the DEGREE to FEET conversion will be low precision too. <<Low precision is also common when Lat/Longs have decimal degrees with LESS than 6 significant digits.>>
4. If you use MAPIMPORT to convert ESRI points to plain vanilla AutoCAD points, you should maintain all the decimals in the imported results. If a user rounds off the coordinates, then any shift in the points are due to the user who rounds off, not to AutoCAD.
5. You can use UNITS command to reduce or increase the precision displayed in coordinates. UNITS does not affect the geospatial position of a point, it only affects how the coordinates are displayed.
6. You can use an EXPRESSION to round off the display of an attribute in a shapefile. Using an expression does not change the geospatial position, it only affects how the coordinates are displayed
7. The Position X and Position Y of a point or the insertion point of a block that's displayed in the Properties Palette is DYNAMIC, meaning if you move the point or block, the Position X and Position Y in Prop Palette will change immediately, on the fly. The coordinates stored in Object Data (OD) however, are static and won't change unless the user edits the OD. 
8. If a shapefile's database file (dbf) has easting and northing values stored as attributes, the attributes are static and won't change unless a user edits the shapefile database. This is true even if the shapefile point is physically moved to a new location. The dbf values are STATIC, not dynamic. 

*Yes, you can input Lat/Longs points into a drawing that uses a State Plane coordinate system because Map3D can transform from Lat/Long degrees to State Plane feet.

[Setsquare]

Thanks ChicagoLooper

I believe that I fully understand the difference between what is displayed (in ACAD the values displayed in the properties against OD values is controlled by the "units" setting) and the REAL/actual co-ords of a point.

However, points are specifically placed to a set location in grid co-ords within ACAD (ie a point drawn at 10000.125E, 636400.256N). MAPEXPORT is used to create a shape file. When that shape file is imported into GIS, then those co-ord values are subsequently reported to 15 dec places when the att table is exported from GIS (GM, QGIS,ESRI) (for example 10000.124999999998745, 636400.254999999999999).

NO CRS is assigned to the CAD drawing, nor is one stipulated in MAPEXPORT.

That is why I was leaning to the problem being an issue in the encoding of the shape file at the Autodesk end, else it is on the importation into GIS.

If the grid co-ords are subsequently converted to geographical lat/long for the shape file export, then that is a different matter, and can explain the "corruption" of the value. Not knowing the format/content of a shape file, I can only guess!

The issue is - absolute positions of points & linear entities are defined in CAD, and are subsequently corrupted in the process of exporting to a shape file from CAD & subsequent import of shape file to GIS.

Simply setting the attribute table display in GIS so that the values are displayed correctly will not resolve that issue, as the end user will export the attribute table to text/csv file.

[Setsquare]

Thanks Dave - that is exactly what I have been encountering