DGN coordinates not matching chosen coordinate system

I'm experiencing some issues with the coordinate system in my DGN file where the coordinates in the file itself don't match the coordinates of the chosen system.

I'm doing work in Hernando County, FL, and for this job, the coordinate system needs to be NAD83 Florida State Plane West, EPSG:2237 with the units in US Survey Feet. I've set my DGN's coordinate system to that one, and I've verified that my working units are in US Survey Feet.

I've attached a WMS by way of an xwms file that shows the county, and then I've also attached a number of shapefiles which all use WGS84 (EPSG:4326) with units in degrees. When I reproject the shapefiles, they line up perfectly with the WMS background. However, the coordinates of the DGN file do not match those which come from the files.

For example, one particular point from the shapefile is located at 28.500596726°, -82.247924429°, which should reproject to Northing=1514789.17067016, Easting=576536.581210096 (I've verified this using two different coordinate conversion tools as well as checking the output in Google Earth and on the EPSG's web map). However, it is actually located at X=175728.7014, Y=461708.6624 in the drawing. That puts the point in the Gulf, about 22 miles East-Northeast of the Dry Tortugas, under a hundred feet of water.

This is a problem, because I need to call out the Northing/Easting on multiple points, as well as at the intersection of lines from a polyline shapefile.

So my question is twofold: why don't my DGN coordinates match my coordinate system, and what can I do to correct it?

Well, I was going to attach a couple files showing the problem, but only the .prj and DGN files will attach. Both are useless without the rest of the files, so apologies for not being able to share.

Parents
  • Darin, were able to resolve this issue?  If not let us know where you are in the process, attach the files (DGN, Shapefile, etc) and we can take a look to see what the problem may be.  You can use the secure folder to upload the files: https://bentley.sharefile.com/r-r4759d26dfb14766b.  Make sure to zip them all into one file prior to attaching them.

    As I understand it, the issue is "the coordinates of the DGN file do not match those which come from the files.".  You can review the map projection coordinates of the EPSG system on the Spatial Reference website: https://spatialreference.org/ref/epsg/nad83-florida-west-ftus/html/. They are the source for EPSG coordinate systems. 

    The DGN Units can be set to your desired units (Storage and Working).  You can alter the Running Coordinate Readout using the Alternate Coordinate System settings.  Those provide a lot of flexibility in-terms of reviewing coordinates. The DGN's Storage Units determine the size of elements in the file.  Once those are set, they should not be changed.  The Working Units are flexible, and can be adjusted for data input and readout.  The Shapefile units are set in the application that created the file, the .prj file indicates those units.



  • I tried a number of things, including creating a new DGN file and attaching the references without reprojecting. That caused the units on display in the Element Information dialogue to sync up with the units in the reference files.

    However, when I wrote a VBA script to create note elements containing the coordinates of the note origin point, the coordinates it displayed were the same, wrong coordinates. I tried a couple other things before I ran the VBA script in my original file. It produced the correct coordinates, despite the displayed coordinates in the Element Information dialogue being incorrect.

    So now I know that the problem was a disconnect between the units by which elements are stored in the DGN (presumably my Storage Units), and the units which were displayed in everything except the Element Information dialogue. I then googled how to set the storage units as well as reviewing all the physical documentation I have access to, but was unable to determine how to do that.

    At the end of the day, the problem preventing me from finishing the job was resolved, but the underlying cause (the discrepancy between storage units and "actual" units of the project) remains.

  • I can't imagine what it's doing. I did create a new file (imperial seed), attached that coordinate system, checked the reproject/change working units box. I then exported to a KMZ file, all seems fine. (left the Working Units Advanced Settings alone). I do notice Working Units shows feet not US Survey feet as it should, just another bug in Connect I guess.

     FloridaW2.zip

    Connect r17 10.17.2.61 self-employed-Unpaid Beta tester for Bentley

  • As of right now, the only issue is that the Element Information dialog is displaying the coordinates using meters. I'm the one who set up our seed files, and I know I set them to the best of my ability to use US Survey Feet in every case (I did create a metric, DD and DMS seed file for the rare cases where we need to use those, but they're rarely used).

    I tried creating a new drawing using the metric seed, and I found that the coordinates in the Element Information dialog and the working units were the same.

    Honestly, it just seems at this point like a rather blatant oversight, either in choosing a defined unit and then performing conversions in (almost) every HIO operation unless the user specifies the same unit, rather than going the AutoCAD route of using an undefined unit and then simply defining it as whatever the user specifies.

  • I tried a couple different variations using GCS, could not duplicate that, I am using Connect. You've pointed out one of the few basic differences between the Autodesk software and the Bentley software. Bentley is still like a giant etch-a-sketch, Autodesk will store info on how the thing is positioned, rather than the actual position. Both have there drawbacks, neither is likely to change.

    I've been doing exactly what you describe for a long time, mixing different format files using published coordinate systems. Certainly had to work thru some shortcomings, bugs and especially operator ignorance. But it all works great when it works.

    Sorry for the no help. I do not see where you uploaded the DGN, I could at least see if I get the same anomaly you're seeing.

    Connect r17 10.17.2.61 self-employed-Unpaid Beta tester for Bentley

Reply
  • I tried a couple different variations using GCS, could not duplicate that, I am using Connect. You've pointed out one of the few basic differences between the Autodesk software and the Bentley software. Bentley is still like a giant etch-a-sketch, Autodesk will store info on how the thing is positioned, rather than the actual position. Both have there drawbacks, neither is likely to change.

    I've been doing exactly what you describe for a long time, mixing different format files using published coordinate systems. Certainly had to work thru some shortcomings, bugs and especially operator ignorance. But it all works great when it works.

    Sorry for the no help. I do not see where you uploaded the DGN, I could at least see if I get the same anomaly you're seeing.

    Connect r17 10.17.2.61 self-employed-Unpaid Beta tester for Bentley

Children
No Data