Change coordinate system

Libitron · November 1, 2022, 8:48pm

Hello

I am a noob. I created my second project yesterday using my newly acquired Emlid equipment. I fear I have made a mistake that will be costly to me, but have hope for recovery.

I took my two M2’s out of town with me. One is configured as a base and the other as a rover. I configured the corrections to the rover using Emlid Caster. I understood someone to tell me at one point to just use Global CS as the coordinate system. So this is what I did. I set out and measured 14 GCP’s. Reachview app said Fix during the entire survey.

So now I have tried to process the survey. I get an error in Emlid studio saying that only one GCP has a Fix location. The resulting corrected CSV only produced a single coordinate. This is an issue that I still have to deal with, however, I still had my survey coordinates within my survey project to work with. So I created a CGP.txt file to use with Pix4D. I got an error saying the coordinates could not be used. Pix4D had populated fields with WGS 84 /UTM zone 13n (which I now understand to be the correct choice locally). I looked through the options in Pix4D and could not find a Global CS option. This is where I am stuck. Can I recover and get these converted from Global to WGS 84 /UTM zone 13n?

I tried using the GCP tool in WebODM. It did a conversion, but something is very wrong with the elevation. I used the file for P4D and the GCP’s are literally in space.

Florian · November 2, 2022, 8:42am

Hi,

The fact that you used Global CS instead of UTM zone 13 is not a big issue as you can easily convert geographic coordinates to plane coordinates with a tool such as this one

About the overall workflow, you don’t have to reprocess the whole survey in Emlid Studio because you already have points collected in FIX status, so the relative accuracy is fine for Pix4D process. You probably just have to process your base raw data, but that is just in case you need absolute accuracy. Have you read this thread ? You may find very useful information that apply to what you did.

kseniia.suzdaltseva · November 2, 2022, 6:44pm

Hi Scott,

As Florian said, if you collect GCPs in RTK with a Fix solution, there’s no need to post-process them in Stop&Go. But I’d still look into the logs – it can help understand why there are only 14% Fix solutions. Also, we can try to obtain a better result with your data by adjusting the settings. Would you mind sharing the logs and the CSV file?

Can I recover and get these converted from Global to WGS 84 /UTM zone 13n?

Sure! But to do it properly, we need to find out the base’s datum first.

If you averaged the M2 base’s position with a Single solution, it’s already in WGS 84. So, you can just upload your CSV file from the Global CS project to a new project in WGS 84 / UTM zone 13N. ReachView 3 will apply the projection automatically. In this setup, the base position has a shift from the global coordinates. It means that you obtain only relative accuracy. You can find more info about relative and absolute accuracy in our docs.
If you placed the M2 base at a known point and entered the coordinates manually, please check the datum of these coordinates. It’s not always WGS84 – for instance, it can be NAD83(2011) or ETRS89, depending on your location. If so, you need to transform the data from your local datum to WGS84 before applying the projection. Using known coordinates for the base station gives you absolute accuracy.

It did a conversion, but something is very wrong with the elevation. I used the file for P4D and the GCP’s are literally in space.

That’s a huge shift, indeed. I’d suggest double-checking CRS settings in Pix4D and testing the conversion to WGS 84 / UTM zone 13N with another software. If the conversion works fine, you can also reach out to the Pix4D support to check the possible reasons and solutions.

Libitron · November 3, 2022, 3:44pm

Thank, you everyone. I managed the import to a new project for the conversion @kseniia.suzdaltseva. It seems to have worked.

I know that in the end we will likely discover that I am making an error in some way. That is fine as long as you have the patience for that.

@Florian, Yes, I see that now, thank you. Even so, shouldn’t it be possible? The reason I ask is because I wonder why I get the errors that I do when trying to run the process in Reachview3. If you have a look at the shared files, only 1 of the 14 marked locations returns a location. The rest are #name.

A couple more questions to help me tidy up. First, is it fair to say that pretty much any map processing software will want meters/yards for elevation? The csv returns feet for elevation. I see that the corrected csv is converted. Since as I was taught here that I may usually not require corrections, then it would be great if the export csv was in meters.

I created my GCP file manually from the csv data. Is there a method to produce a .txt file to use with map processing software?

*** Edit

I imported the original project csv into a new project for which I had set the coordinate system to WGS 84 / UTM zone 13n
I exported the resulting csv created with new project.
-I see that the elevation is now in meters. The original csv was in ft. The number has not changed. For example, the GCP labeled “Control Point close to home base” is now an elevation of 2080.486 m when in the original project file it was 2080.486 ft. The csv is also reporting my antenna height as 5.906m and not ft.
I have added this csv to the shared folder. It is named “Upload Pit Convert to WGS 84 UTM zone 13n” The orignal version is also there named “BSL Pit Oct 31 2022”.

kseniia.suzdaltseva · November 11, 2022, 5:35pm

Hi Scott,

Sorry it took so long to write back!

Even so, shouldn’t it be possible? The reason I ask is because I wonder why I get the errors that I do when trying to run the process in Reachview3. If you have a look at the shared files, only 1 of the 14 marked locations returns a location. The rest are #name.

Sure, it’s possible. As I see from the screenshots, you have the Fix data quality filter enabled. That’s why only 1 point was averaged. I’ve checked that when the Float and Single solutions are checked too, all the positions are calculated fine.

As I know, you’re in contact with my colleague Julia via email. She has already shared some tips on how to get more Fix in PPK by adjusting the settings. If you have further questions about the post-processing results, I’d suggest looking into them with her. It’ll help keep all the details in one place and prevent confusion.

The csv returns feet for elevation. I see that the corrected csv is converted. Since as I was taught here that I may usually not require corrections, then it would be great if the export csv was in meters.

As a result of Stop&Go, Emlid Studio outputs Longitude, Latitude, and Ellipsoidal height in meters. It doesn’t depend on the coordinate system of the initial CSV file. If you’ve entered the base’s coordinates in WGS 84, you can upload the corrected file to a WGS 84 / UTM zone 13N project in meters. It’ll give you precise projected coordinates.

I created my GCP file manually from the csv data. Is there a method to produce a .txt file to use with map processing software?

The only text file format available in Emlid Studio and ReachView 3 is CSV. But it’s an industry-standard format, so it’s usually supported in 3rd-party processing software. Can you specify which software requires the TXT format?

I see that the elevation is now in meters. The original csv was in ft. The number has not changed. For example, the GCP labeled “Control Point close to home base” is now an elevation of 2080.486 m when in the original project file it was 2080.486 ft.

When you upload a CSV file to a ReachView 3 project, it assumes that the coordinates are in the project’s datum or coordinate system. There’s no additional conversion. So, when you upload a file with geographic coordinates to a WGS 84 / UTM zone 13N project in meters, ReachView 3 treats the coordinates as WGS84 coordinates with heights in meters.