Hi there,
I was hoping for some help. This isn’t an issue with Emlid but I’m currently having issues with the map in civil 3D not aligning with the points I gathered in the field.
On the Emlid flow app the points are in the correct position but when I import to Civil 3D and set the map to the same coordinate system they are a few metres out.
Has anyone had a similar issue?
My current workflow is
-set coordinate system to Australia GDA2020 MGA Zone 55
add in known point from Benchmark Australia app
Set base station up, collect known point and set base offset with the known point against collected point
I then continue my survey and on the emlid app the points match the satellite image
The issue then happens with civil 3D not matching.
Any help would be appreciated at the Autodesk forums have been unhelpful so far
When you use an EPSG Co-ordinate system (say 7855) in Civil 3D, it basically calculates your drawing grid Co-Ordinates on the fly. The only point that is identical (assuming you are using a Scale Factor other than “Unity” in the Drawing Settings) is the Base Point. Prismoidal is a good one to use if you aren’t using a Combined Factor that incorporates height. Everything from there is then calculated Grid Co-ordinates.
In this scenario, your CAD X & Y (Easting & Northing) in the drawing are basically Ground Distances. If you insert a COGO point (choose manual and snap it to a point you are interested in), then click on the COGO point, open Properties and you will see toward the bottom two different sets of Co-Ordinates. Easting/Northing and Grid Easting/Grid Northing. It is the latter you are interested in.
But it doesn’t stop there. You need to make sure you have the right scale factor (and base point) FIRST before importing your points. When you import or export your points, you need to make sure you change (edit or copy and change) the PENZD from using “Easting” or “Northing” to use “Grid Easting” and “Grid Northing”, otherwise the points won’t get inserted correctly.
Another note, make sure to use known points (and their Co-Ordinates) from the Benchmark App if the mark is GDA Datum, or very least, GDA Derived; GDA Scaled is unreliable. You are looking for published PU’s (uncertainty) for Horizontal around 0.020 or less for a good mark and maybe 0.050 or less for a not so good one. GDA Scaled normally does not have any PU’s. If height is important, it is likely only a GDA Datum will have similar Vertical PU’s.
I’ve done surveys up to 4km using this method and I’ve at the very least always been able to find a peg or reference mark with these methods. If you get enough marks, you can then adjust your scaling to suit, but I find doing a localisation on true ground distances then gets me more than close enough for everything.
Thankyou so much for taking the time to respond with such a detailed response!
I will try all your steps and see if I can fix my issue and let you know how I go.
I mean, things don’t have to be complicated, but I find most of the information out there is just garbage anyway. At the very least, maybe people don’t actually understand the problem they are trying to help solve.
Scenario like this where I use it every day, makes sense to share.
Exactly. Once you get it (i.e. grid to ground and scale factors) then use it everyday, it’s no issue. The issue is when you don’t use it everyday where the confidence falls apart. Some aspects just require more research and continued experience more than others.
Unfortunately, I fall into the category of a ‘newb’ with the map underlay in civil 3D.
I’m struggling to get my head around the scaling factors.
I thought the workflow would be as simple as
Insert points from CSV file
Then set location using one of these points and select the correct coordinate system
I thought that Civil 3D would then scale the map to suit my project underneath.
I’ve uploaded the CSV file (sorry had to upload as a PDF as CSV is not permitted) if anyone could try a workflow to get it to work correctly at least then I would know it’s an error with my civil 3D workflow and not my actual survey.
I am using point 2 to set the location and it’s about 2km away from the job site.
Where I set the known point up on the map is exactly the correct position but due to this scaling issue once you get to the jobsite the points are in the wrong spot on the map (the points are in the correct spot just the map is not scaling correctly I should add)
If someone was able to make it work, I’d then ask if they would be interested in showing me how to do so via video at their chosen hourly rate.
Hello Jack,
I think your upfront survey looks ok and the issue is related to whatever is happening downstream with the Civil 3D
The EMLID side is good, I mostly use GDA2020 MGA Zone 55 here and there are no implementation issues, it works fine.
Your survey mark and the coordinates you entered check out OK, and it’s a reasonably high order horizontal.
And in any event the horizontal offset you are seeing appears huge, from what I can see here it’s roughly 35m east and about 10’ish m south.
I loaded your CSV points into Global Mapper transformed to epoch 2024.4 for a quick view in Google Earth and the alignment looks really good (well at least for Google Earth anyway):
Is it a regional thing that you are stressing co-ordinate while discussing a 2D X,Y shift? Typically that is used when Z is introduced where I am from. The correct 2D reference would be coordinate.
Thanks for confirming this wombo,
The picture you show is the exact positions of the survey so hopefully I can work out the issue in Civil 3D.
I also use a program called CDS4 from foresoft and put the survey into it and overlayed its map and it all worked fine. Why oh why does Civil 3D have so many extra steps, its unfortunately far superior in producing printable maps in my opinion though hence the perseverance with it
Hi Michael,
Yes, I am using Z as my work requires 3D models for quantity reports and machine control files.
Up to this point I’ve had no issues and the map underneath the drawings is a ‘Luxury’ I’m hoping to eventually offer on my Topo maps but its currently not necessary. Moving forward though I can see more clients wanting it as some move away from printed maps too PDF’s where a satellite image underlay becomes more viable cost wise
I’ve left an artefact in there at Point 84 (being the furthest away from Point 2) which basically shows the difference scaling does in AutoCAD. One end is where the point would have gone, the other is where it should be (755mm away). I am worried though as you said you were a few meters out, was the base offset actually applied?
When you click this point, you will see both the Traditional Easting/Northing and Grid Easting/Northing. The latter matches up with what Flow has collected.
What does this mean? Well, assuming the scale used is correct, the CAD distances should match what you could measure on a tape (with margin of error). The scale used was 0.999722 (From the PSM info, it appears to me to be a Combined Scale so incorporates deviation due to height).
If you go digging through the Drawing Settings, you will see what has been done to set it up before importing (and exporting) the points. When you Import or Export your points, you need to use this File Format.
BE WARNED! If you decide to export this as a DXF to keep any new points, lines or surfaces that you may draw and import it into Flow, you will have the same problem but in reverse. The only way around it with this method is to export the points (Grid Co-Ordinates) and put the new ones into Flow, then manually join them up in Flow. There is another way, but it then involves performing a localisation on some form of local control network so that you can import your ground distances from AutoCAD into flow and basically create a pseudo MGA Co-Ordinate System in Flow for the project.
Believe me I get that. I’ve been doing 3D modeling for about 20 years and machine control for almost that long. My question was solely related to the use of coordinate versus co-ordinate. The problem you are experiencing has nothing to do with Z-axis and is simply a Civil 3D background issue. This is why there is a point localization feature. You can switch from background to background and they don’t align. It’s not meant to be a sub-meter accurate representation. You can have everything set perfectly correct and it will work in one area and not 10 miles down the road.
Thanks Joel that’s awesome work! I just had a quick glance at your file and its very close to the mark so I will try your workflow tomorrow and see how I go as from what Michael said if I can get it as close as you have I will be happy with that.
But also, thanks Michael you may have saved me a whole lot of frustration with trying to get it cm perfect.
But most importantly well done to the Emlid community as the Autodesk community/Forums was not nearly as helpful as you guys were here
Happy Mapping all
Kind Regards Jack
Step one: Is it a scaling issue?
Draw a p-line from 0,0 to a point in question. If the other solution for the point is on that line (or a projection thereof), it’s probably a scaling issue.
If you’re working in metric, you won’t need to verify Survey Feet or International Feet. That’s something we deal with a lot in the States. That causes an error factor of 1.000002.
With Civil 3D, you need to verify that the projection details are correct in both the drawing file and the Survey Database (if you’re using it.) If you leave the Survey Database settings blank, you could easily get an error of a few meters.
It is important to make sure the origin of the scale factor is correct. Just scaling from 0,0 might get you lucky but most Surveyors that I have worked with over the years either pick a boundary point of a centroid of the tract. Rarely do construction contract documents clarify this. I only see it because I ask.
Also, don’t forget localizations. You can take any of the factors mentioned in this entire thread and throw a localization on top of it and be out of tolerance if if the localization was done on true grid with acceptable accuracy tolerances.
Michael,
You are correct. If someone set up a system with a local scale point, this won’t work. The method I lined out only works with systems scaled from origin. Thanks for pointing that out.
