I noticed when trying to troubleshoot some GCP positions this afternoon that EmlidStudio doesn’t update the Base position in the CSV file once the collected points have been corrected. I’d expected to see the Base position I’d used for the Stop & Go base file (especially if it had been overruled by a manual entry or by dragging and dropping a .POS file).
I see from https://community.emlid.com/t/emlid-studio-rinex-base-coordinates/32599 that this is expected behaviour at present rather than a bug.
At the minute it would be possible to return to re-use the csv file and mistakenly think that the file hadn’t been processed, or had been processed with the wrong base position.
Would it be possible for the Stop & Go process to update the Base position in the final corrected csv file? That way the correct base location is kept with the points data .
Hi Nick!
Thanks for bringing this up! I am checking to discuss this and will get back to you.
Hi Nick! I’d like to understand your workflow better. Could you share why you will also need the corrected base position when you want to check the GCPs? Understanding this will help me to pass the request to the team.
Hi Merryana,
I’ve been reworking several sets of survey results to try and refine the positional data. The surveys were a mixture of Drone flights coupled with Ground Control Points - all recorded and logged using Local RTK/NTRIP from a Local RS3 base, and then Postprocessed using Emlid Studio and RINEX data from a local OSNet CORS station to correct everything.
I’d found that some of the processing had different settings for SNR/Elevation/Constellations etc, and that had muddled results in the 3D modelling with the GCP’s not aligning fully.
So, I reprocessed everything using the same settings in EmlidStudio. However, when i came to input the GCP locations, i couldn’t remember if I had reprocessed the file, or if I was looking at the one from the first processing try.
I thought I’d be able to tell which of the csv files i was using by looking at the base location recorded in the csv results file, and was a bit surprised to find all the csv files had the same Base location recorded - ie the very original uncorrected one. I’d expected that when the Stop & Go updated the LLH values, it would also have updated the Base LLH values to the value used in the correction processing.
It would be helpful if it did that for two reasons:
- a user would be able to see if a csv had been updated from the original base location.
- someone looking at the csv file in the future would reasonably expect that the base location shown in the file was the one used to record the results. If they were to try and process the data again, they may accidentally use already processed (corrected) data thinking it was the original (uncorrected) point data.
Hope that helps (I’m not at my best today after spending seven hours late last night trying to recover my Wife’s laptop after an Autoupdate to it’s firmware failed and triggered various lock-outs. Corporate IT is a pain when they turn on Bitlocker and Bios passwords, then don’t trust the user with the codes.)
1 Like
Hi Nick!
Thank you for explaining the request in a very detail way. Now I understand this request much better! Just a little question here:
After processing the CSV, Emlid Studio saves the new file as file name_corrected. Does this help differentiate the original and corrected file?
Once again, I appreciate the time you took to explain after a long 7 hours fixing the computer!
Hi Merryna,
While the filename may denote the corrected & original csv files, it doesn’t tell us anything about the location of the base position used.
In the case of making several different sets of corrections (eg if one or more are found to be in error), all the corrected results files are named the same and there is no indication of which base location was used to calculate the corrected points - The point positions change in each file, but the base position never changes from the uncorrected position. That makes it impossible to work out which base position was used to generate the csv file.
Also, in archiving the data files (logs, csv etc) for future users of the data, the base location is never updated in the csv file. In the hypothetical case of the data being reprocessed for something which also needed the base position, then it could end up being reprocessed using the incorrect data.
I guess all this comes back to a suggestion I made last year, that there is currently no processing summary report produced by EmlidStudio i.e. one that details the processing settings, Base locations, fix/floatt/single status for drone markers etc. All that info has to be collated piecemeal into a report to document the measurements. At present I’m having to do screen captures of the processing screens to record all that sort of info. The base position is another facet of that data collection and documentation.
It seems strange that we go to all the lengths to get the positional and point data correct to 1-2cm, then fail to also record the correct base location - it’s not as if it’s difficult to record as it’s already either been manually entered (or via a .pos file), or it’s from the rinex header.
Got it, @ElectroNick. I noted this request and passed it as a feature request. Thank you for sharing this feedback!
