GDA2020/BCG2020 Global Coordinates discrepancy

[gareth.davies558 (Gareth Davies)]

Hi all,
I am an extreme newbie (3 days experience!) with the Emlid ecosystem so please excuse me if i am being stupid here. I am evaluating an RS2+ for a client and need to set up a test for staking out.
I have created a simple set of 4 points in QGIS and have exported this data in various formats and then imported them into Emlid Flow. Once imported the Local coordinates for each point appearsto be correct but the Global coordinates place my point somewhere in Southern China so at the very least the fact that I am in the Southern hemisphere is being ignored. Are the Global Coords derived from the Local Coords? Is this a known problem? Does Flow have some particular non standard requirements for file layouts?

I am in Australia, a bit to the NNW of Brisbane. I am using QGIS 3.30.3, my QGIS and Flow projects are both set to GDA2020/BCG2020. I have exported the point data from QGIS in Shp, dxf and csv formats with the result described above. I have seen this occur on both Flow 360 on Windows 11 and Emlid Flow 8.10 on Android 13. I have looked at the contents of the exported files where possible and they appear correct at least at a cursory glance. The CSV file was edited to match the required layout specified in the documentation. I am using GDA2020 as I will be taking correction data from AUSCORS in GDA2020 format.

Thanks in advance for any advice that you may be able to offer.

[gareth.davies558 (Gareth Davies)]

Further to the above I have now created new QGIS and Emlid Flow projects this time using WGS84/UTM 56S. This works perfectly when exporting/importing a shp file, have not tried other formats yet. Therefore I am not certain whether the original behaviour was due to the CRS selected or is due to a constraint that I am not aware of. Any opinions would be most welcome. I don’t have time to investigate this further will return to it later.

[brentonholmes1984 (Brenton Holmes)]

Hmm Northings and Eastings aren’t the wrong way around hey?

[gareth.davies558 (Gareth Davies)]

That was my initial thought, however if that were the case I’d expect to see the same result when I changed to WGS84/UTM 56S. That did not happen. I will try to find time this weekend to investigate further. Thanks for the response.

[zoltan.biber]

Hi Gareth,

Welcome to our community!

Could you share your exported points from QGIS in CSV format? If there is no sensitive data in it, you can post it here. I’d look into it to see what can cause such difficulty.

[gareth.davies558 (Gareth Davies)]

Hi Zoltan,

thanks for looking at this. I’ve been having a look at EPSG.io and can’t do a succesful transform there either. Meanwhile I have come to the conclusion that EPSG 20047 is not the most appropriate CRS for me to use anyway, so will use 7856 instead.

I have attached a shape file exported from QGIS 3. It contains a single point marking a power pole across the road from our office. If you import it into a FLOW project with CRS 20047 you will see that the identified location is somewhere in Fujian province.

regards

Gareth

Woodford single point EPSG 20047.zip (620 Bytes)

[vkbellis (Kelly Bellis)]

Hi Gareth,

FWIW - loading your provided shapefile into Global Mapper, it is immediately being recognized as being EPSG:26915, NAD_83_UTM_Zone_15N

Kind regards,

Kelly

[vkbellis (Kelly Bellis)]

When I began a new workspace without first defining the coordinate system, GM first interpreted the x and y as being in UTM and in a completely wrong zone.

When I began a new GM workspace, and explicitly set its coordinate system to EPSG:7857 before importing your shapefile, things look okay.

This makes me wonder if your QGIS should also be exporting a .prj file since there’s insufficient information given in the 3 files that you shared.

I’m not sure if this helps you since it isn’t related to Emlid Flow, just your shared .shp.

[gareth.davies558 (Gareth Davies)]

Hi Kelly,

thanks so much for your assistance. I have repeated my test including the .PRJ file in the zip. This does not appear to make any difference. The Flow documentation says the zip should contain 3 files: .SHP,.SHX and .DBF. Perhaps any additional files are ignored even if supplied?
For Zoltan’s benefit I have attached a copy of the new zip with all 4 files.
Thanks once again

Gareth
Woodford single point EPSG 20047.zip (1.0 KB)

[vkbellis (Kelly Bellis)]

Hi Gareth,

This morning I attempted to create a new survey project in Emlid Flow; however, I was unable to find GDA2020 / MGA Zone 56 / EPSG:7856 in its offered coordinate systems.

Maybe later, this coordinate system will be added to EF’s list, so you can roll your own.

Start a new survey project in EF, and tap Project Coordinate System, then the + symbol in the upper right corner

Note - the following behavior was seen the first time I went through this procedure; keep reading if it makes sense; otherwise skip down to

New CS
Name: epsg7856 (you can call it anything you like, but this was how I named the New CS)
Datum: Geocentric Datum of Australia 2020
Ellipsoid: GRS 1980

NOTE! EF doesn’t appear (at first) to support GDA2020 - suggest you reach out to Alistair Hart at: Mangoesmapping Pty Ltd, 1 Jack St, Atherton QLD 4883, Australia; https://www.mangoesmapping.com.au

Projection: Transverse Mercator
Latitude of origin: 0.0
Central Meridian: 153.0
Scale Factor: 0.9996
False Easting m: 500000
False Northing: 10000000

Tap Save until you’re able to choose your geoid model, and if it’s not listed, that’s okay, go ahead and download it.

Save

Notice there’s a plus symbol appended to the newly manually created CS

When I imported the point feature from your initially shared file above, everything looked fine.

After running through this once, I went back and started to run through it again while writing this post, beginning with looking for Australia

I was able to find GDA2020 / MGA Zone 56 (!?)

I may have overlooked this the first go around (I’m a terrible speller) and must have given up to early in my search for onboard CS in EF, but decided to keep this windy post anyway as it sketches through manually created a new coordinate system.

Kind regards,

Kelly

[gareth.davies558 (Gareth Davies)]

Hi Kelly,

thanks for the very detailed instructions that you supplied, I will keep them for future reference. It looks like EPSG 7856 works fine for me.

EPSG 20047 only applies to a fairly small sliver of the extreme east coast of Australia. Perhaps I am the first to try to use it in EF? I still dont know whether the issue with that CRS is due to my ignorance or whether it is not being handled correctly by the software, no doubt Emlid will come to a conclusion. I am definitely not a surveyor and would be the first to admit that I find CRS and the associated mathematics confusing,

cheers

Gareth

[vkbellis (Kelly Bellis)]

GDA2020 / BCG2020 (EPSG:20047) is shown on Emlid Flow’s list of available coordinate systems for Australia.

[zoltan.biber]

Sorry for the late reply. I’ve checked your file and it seems like its coordinate system is GDA2020 / BCSG2020 (EPSG:20047). I suggest you use GDA2020/BCG2020 (EPSG: 8016). Here you can see a short workflow that should work:

• Transform your shapefile to GDA2020/BCG2020 (EPSG: 8016) in QGIS
• Export it to shapefile
• Compress these files: shp, shx, dbf
• Create a project in Emlid Flow and set the coordinate system to GDA2020/BCG2020 (EPSG: 8016)
• Import the compressed file as a shapefile

You don’t need the prj file since your project will define the coordinate system.
If it’s suits you better, you can also find GDA2020 / MGA zone 58 (EPSG: 7858) in the app.