Hope it’s fixed promptly after just spending $12k for Emlid equipment specifically for this project
Pulled them into Nuwa App. Looks like the Emlid Flow screenshot.
It did not have your old CRS so used what it did have… Australia GDA94 MGA Zone 53 E132-138
Appears there is some discrepancy between CRS’s and versions. May not be Emlid CRS issue? Used Australia GDA94 MGA Zone 53 also (AGD84 would NOT work) for MicroSurvey FieldGenius ANDROID and it showed the same as Nuwa and Emlid screenshots. SurveyMaster seems to be the only one that matches.
Probably should be using a more up to date newer CRS anyways.
Good luck!
Back in the day, the shift from AGD84 to GDA94 was some 200m NE (when we started using the Earth as a reference instead of the stars). Without the right shift files, you’d be stuck trying to convert.
Without knowing how you are also getting your corrections, I’m confused why you aren’t using GDA2020? Most CORS providers only provide GDA2020 with some also doing GDA94 for backwards compatibility.
1 Like
We will be using a rs2+ (base) with RS3 (Purchased but not yet delivered). I am using AGD84 because that is the standard used on the site (an old mine site), as outlined in their SOP
If you must use AGD84, I’d recommend a program called AusDatumTool to do the conversion from GDA2020 back to suit. It has the right Grid Shift Files which can do a direct conversion and can use a CSV to batch convert also.
The last AGD conversion I did with this program was only out by a few millimetres compared to a QLD benchmark report, granted it was probably only due to rounding from 84 to 94 to 2020 instead of 84 to 2020.
1 Like
What is odd (or maybe not) is SurveyMaster app showed the points CORRECTLY on the aerial basemap using their CRS of AGD84/AMG Zone 53?
Without having to shift? I think you can apply shift files, but did not have to.
You may want to download several survey apps to compare things… (SurveyMaster, Fieldgenius, SurPro, SurvX, SurPad, Nuwa, X-PAD, etc) or just use Emlid Flow and see what Emlid says about the shift?
If i import the AGD84 coordinates into QGIS, but tell them they are GDA94 i get the same as you, which further proves it is a flow issue…
This isnt really a solution, but a work around, and shouldn’t be needed as it is clearly a bug with Emlid flow. To be honest, it is a classic emlid and emlid user solution. And adds to the workflow of what needs to be a rapid turnaround with going from AGD84 to GDA2020 and back.
Being able to select coordinate system, even deprecated ones, is one of the most basic requirements of survey equipment. The fact they dont even let you upload your own geoid files and make you wait months IF they even decide to add it is also already a joke.
For these points, what was your base? (CORS, Local Base, other?)
If they are giving you GDA2020 corrections, your position should be about 201.6m SW out. Otherwise if GDA1994, about 200m SW out.
If either of the previous paragraph, you’ll need a custom CRS to suit. I do the same for when I use a GDA2020 base to do a GDA94 survey.
1 Like
Somewhat disagree. You are trying to use a system prior to GPS/GNSS. I’m pretty sure Aptella/Position Partners who charge a stupid amount for their system still wouldn’t achieve the same result without some kind of workaround.
1 Like
The points were taken with a Topcon Hiper VR base and rover set. With the base set over a known point entered in AGD84/zone 53
1 Like
Works perfectly fine with the topcon equipment we have hired from position partners
Hiper VR is only in GDA1994 or GDA2020. So I think the issue is that you will need to still apply the translation from either of the above to AGD84, likely meaning a custom/modified CRS.
See Table 7-1 here of the GDA94 Technical Manual for the translation. You use the inverse (multiply by -1) to go from GDA94 to AGD. You’ll need a further calculation to work out a direct GDA2020 to AGD84 translation.
GDA94 Technical Manual
When it comes to the height ellipsoid though, I have no idea. Never had to deal with it. Always used the published AHD.
1 Like
Doing some further looking this morning, it appears when you set up the project in the App, it is actually using Global Co-ordinates for “Local”. So when you import your points, they are being imported to the UTM/WGS84 Datum.
The way I would approach this would be to do everything in GDA2020 (so EPSG 7853 for you) and then do the conversion after as part of your deliverables (or the reverse to get your old information upgraded). Using the AusDatumTool on these points was within 1 or 2mm when you consider the conversions needed in QGIS to go through 2 transforms to get the same result; so close enough.
This way, you can still use a nearby CORS (or run known marks through AUSPOS) to avoid any potential blunders.
1 Like
This is the conclusion i came to, but this would still indicate a bug with the CRS in flow for AGD84, and should still be rectified.
There are no CORS nearby, and all known points are provided in AGD84.
Just came across this and completely understand being handed AGD84 (or AGD66 as is the case here in Vic) but would suggest this also.
1 Like
Hi @Brocxen,
The AGD84 is an older datum and requires a two-step transformation using two grids, which we currently don’t support on Emlid Flow. It cannot transform the coordinates correctly because there is no direct transformation between GDA2020 and AGD84.
However, you can use an online batch converter to transform between GDA94 and AGD84 via the NSW Spatial Services Converter.
Since we don’t support datum transformation or the upload of grid shifts in Emlid Flow, here’s what I recommend:
- Convert the AGD84 known coordinates to GDA94 using the online converter.
- Set up the base over this known point and input the coordinates in GDA94.
- Set up your project to work in GDA94.
- Rover measurements will also be in GDA94 during the process.
- Export the CSV file with the measurements in GDA94, and then use the online transformation tool to convert the measurements as needed.
Alternatively, if you prefer not to use the online tool, you can use Proj (Proj Documentation) and the transformation grid available here: Transformation Grids on GitHub. This will allow you to convert the points between the different datums.
4 Likes
Hi Everyone,
I’m here with some good news. We introduced datum transformation between GDA2020 and AGD84 for Australian coordinate systems, improving compatibility with AGD84-based systems. It is available from the 11.7 version of Emlid Flow.
We hope this update makes your workflows smoother!
1 Like
Thank you for the update,
So how can i create a custom coordinate system with a fixed vertical offset?
I have created a custom coordinate system or GDA94 with a vertical offset of 1.893.
When i try to do the same using the parameters for AGD84, the points are not in the correct location.
And if i create a project in AGD84 and try to do site localisation, its doesn’t allow me.