I am using the reach for GIS type surveying, logging both points and tracks, and I was wondering what workflow some of the people are using to do similar work. In particular how to you quickly log a point, are you stopping logging and then starting a new log file?
Currently my workflow is I setup my base station and rover and let them acquire a fix and then head off to Well #1 now I want to dwell at Well #1 for a minute or two to get points there but I am unclear how to notate in the program that I am at Well #1. Usually, I set a waypoint in RTKplot but that does not seem to give me a timestamp with the location. So, after I set the waypoint I then write in my field book the time I get to the point so I can pull it out of the log later. This keeps me from starting and stopping logging but is a little cumbersome.
TL:DR - What is your workflow to log survey points or tracks?
We do postprocessing, quite a different approach …
getting a ca 1 minute log at every point: We wrote a custom app to talk to the reachview backend, allowing us to click once to start, collect for 60s and stop.
scripts to automise post processing with RTKLIB…
That is a good approach and gives me some ideas. For post processing, I could have a log stream going to a TCP port and then have a script that gets activated and logs the TCP port for a set amount of time that I can then name something with a time stamp. That way I am not doing start and stop of the rtknavi stream itself.
I guess I can also set it up so that the output also streams to a different port so I can log both the solution from the field and the UBX stream for post processing in case I cannot reach a fixed solution in the field.
Well, I pounded away at the keyboard with my fat fingers and came up with a batch file that I can use.
For right now I am logging points with a windows tablet so I put together a batch file that uses ncat.exe to read the raw data from the log stream of RTKNAVI and it also reads the solution stream from rtknavi. I have both being sent out to different ports.
This provides a pop up for choosing a folder to save the files to, then everything else is on the command line. You can select the IP address and ports to listen to and then how long you will wait at each point and the point name along with a timestamp on the point name. Once a point is logged the solution file unix2dos is run on it to modify the line feeds.
Right now it is not logging the base stream since I already have that going to a file that I can post process against.
It is not elegant but it will get me through a couple days of collecting random points out in the field. Sorry, I am not a programmer that can make something fancy but this is workable if you are logging data on a windows machine. I am sure it would have been easier if I was using Linux but I am not.
So feel free to have at it.
Also, you will need to download ntcat, and unix2dos if you want to use this as is, I am not sure what the licenses are on those programs so they are not included but easy to get a hold of on your own.
pointlog.pdf (113.9 KB)
I hope this is ok to post here.
Thanbks for sharing…
we’re on android though.
We have some problems right now with the rover not stopping and starting when we send the command, so logging a stream could indeed be an option.
(else our approach is also quite comfortable to programm, since the ReachView backend is all open source on github )
I was going through the source on github, but then I realized I am not a programmer, I am more of a script kiddie so I switched over to scripting. If my data loggers were android/linux the scripts would have been much easier to implement since I could have used more native tools to just put the streams into a file.
i also use reach in a GIS way. After some fails i ended with the following setup:
base at a fix pos with correction link over 3rd V2 radio
rover on a stick with a 3dr v2 radio to receive the correction link from base. The solution is output over a TCP server over wifi.
I have windows tablet in my hand running QGIS software. This pro GIS software is directly connected to the tcpserver from reach and showing the pos on the map at a very high zoom level in real time.
What I do is: I go to a landmark and have QGIS zoomed in. after some seconds or a minute i click on the screen in QGIS to add a point in the center of the point “cloud” typically this is below 20 to 50cm accuracy.
–> very fast and very easy, no copy of files oder other boring taks
@igor.vereninov, @egor.fedorov
A function like that would be great to have in ReachView.
Just a button with the function to log a point for 1 minute, add a name and save it in away suitable for processing & in a csv/gpx file for quick use.
Is there anything like that planned?
Yes, definitely! Right after we release the new ReachView we are going to start working on this feature. It is a little complicated as it should allow to both log raw data and position, but we will figure it out. Feel free to share more about how you would like to see this feature implemented. At the moment the plan is to have a button that will place “new site occupation” flags in Rinex and also store the best position available during the observation time in a separate file.
Igor, that is great and will really help the GIS surveying folks who are using the Reach.
@Franz, I also like your solution for quickly logging points and putting them directly into a shape file. I am going to play around with it. Are you setting up a point shapefile with certain fields and then place it in edit mode as you walk around from point to point?
Thank you for updates on you workflow process.
Ryan
For us it makes more sense to store separate rinex/raw files, since we need to transfer them over slow internet. (so a long log with flags is less handy). The single solution could then be stored in the approx position field of the rinex.
Saving the single position estimate is less important, since we use the stream output anyway. What do you mean by “best position available”? based on Sat view?
There should be an option to set occupation time? Also a countdown/total rover running time in the app status would be great. (Generally, having this button and the start/stop button on the status page makes more sense I think, maybe with a the name of the current config).
Also, we now face the problem that we don’t want logs for the walking between points, but Bluetooth single-solution always.
So we would have to use two seperate configs, or discard all the longs from within points…
One more thing: Currently it’s not clear to us when the rover starts on power on, and when it will first be in “stopped”. Is this the last status before power down, and where is this stored?
Yes, I setup up a shape file, setup field, go to edit. I am zoomed in so i click on the clouds of point that is coming from the reach. Then QGIS is opening a window a add a name (and if needed the other tags) and press enter. that’s it.
Thanks for the reply. I set up your workflow process yesterday and tried it out and it works really well. I am doing a bit of a two-fold process. I walk from point to point. At each point, I trigger the stream logging script I posted earlier. While this is logging the raw stream I have some down time so I switch to QGIS and watch the points bounce around. Once I hear a beep that my point logging is finished I tap in the middle of the points I just watched and add a new point to the shapefile with the same name I gave it in my script.
This way I have a quick gis file I can use, or I also have the raw log of the points that I can post process if I need a little more accuracy, particularly with elevation.
So far it seems to be a good way to collect some pretty accurate field data that can be used for advancing the design decision process back in the office.
)