Primarily visualization and transformation. Static measurement on base for length of survey usually couple hours. PPK rover kinematically to base and extract points with software and bring into QGIS. I generally don’t need a higher accuracy on these points to necessitate individual static measurements/processing and longer occupation times. Was that your question?
But they are static points, yes. (GCPs, controls, benchmarks)
No, although I very much wish there was such a plugin…
As in the above software functionality can be loaded up in same QGIS window and reflect “real-time” processing changes on map canvas. Saves me a few steps and clicks.
I have a Windows computer but little Python skills. Starting to learn for an automated brewery build and Raspberry Pi. I have a little more homework to do…
Add .pos file with csv driver, then filter with copy/paste filter parameter ( Exemple : “Q” = 1 AND “ratio” >= 999) or qml …
We use it like that and I’m not alone !
I m very sorry, guys. I don’t have much time for the posprocessor now. I have to write my master thesis. I will manage to get back to the software somewhere in June.
Yes, this is where I left off in past efforts. I would like a more straightforward way to select my points based on the timestamp (i.e. query by time interval and from selection run mean coordinates) from the GPX/CSV file itself within QGIS. There are multiple ways to do this…
We can write a translator of pos to SQLite database and connect it to QGIS. Then you can write SQL queries in many ways straight in QGIS (as far as I know, it is possible).
i.e. only green for a fix, yellow for a float, red for a single etc. Not coloured means that it hasn’t been processed.
The CSV that it saves doesn’t actually save as a csv, it is using a semi-colon as a delimiter (or at least the version I am using 0.2.1 on windows) and it would be great if it also provided the point statistics in the CSV, specifically the ratio of Q1/Q2/Q5 so I can then filter the resulting CSV for anything that isn’t a fix.
Could you make the application of the time in UTC and GPST? it would help us to process PPK
when it makes the correction from UTC to GPST it does not add up to 18 seconds
Yes, I know about this bugs. Still didn’t have quite much time to solve them and push a new version. I also don’t like the fact, that such simple application is more than 200 Mb! Node.js seems to take a lot of space with the modules.
It is very kind! I wasn’t thinking about it, maybe in the future. It is my pleasure to help our community.
Hi, @jurijs.jeshkins I found a difference in the average it does with the pos file that is not equal to the fixed point. What I do not understand that if I take 20 fixed points with rechview the result of the final coordinate is the arithmetic average? With the extractor point do you average the points Q = 1 of the pos file? instead of an average, the ideal would not be least squares or a weighted average? I know it will be a lot of work. What if I repeat again that there is a coordinate difference when using bach processor. Thank you
The coordinates of a fixed point must be equal to that processed with Point Stractor and it is not. applied correction because the pos file is in GPST and the points file in UTC. You should review this difference or then the rechview does not average
Hi @jurijs.jeshkins RTK measurement of points for 20 seconds not UAV. I do data processing in Rtklib kinematic base and Rover to get the pos file and then read it from Point Stractor. I did the test with fixed points that when using Point Stractor should be the same! That’s why I think that the coordinate of the rechview that you save in the csv is not an average because it should be the same
I don’t quite understand your workflow. Correct me, if I am wrong:
You have 2 units, one as a rover and another one as a base, right? You obtained RINEX from both units and corrected it in RTKlib (rover correction against base RINEX). But, during the measurement, you had also RTK, that was supplied by your base. So, in your CSV file you have points, that are corrected via RTK, but in your pos file, you have PPK. And the averaged solution of PPK point extractor is different from what you see in CSV file (averaged by ReachView). Am I correct?