Making ppk paths available for gis software

Hey everyone, I’m having a great time familiarizing myself with my new set of rs+ units!

I’ve successfully been able to export my surveyed points from the app and am very satisfied with how that is going and the correlation I’m seeing between my points and other known data sets.

I tried to take a swing and doing some ppk to be able to use the log files to generate a path I walked around other objects (sides of roads…other landscaped features) and have followed this tutorial:

https://docs.emlid.com/reach/common/tutorials/gps-post-processing/

I’m now seeing the trace of the path I walked and again am very happy with what I’m seeing. I’m not seeing anywhere that discusses how to take this path and export it as a format that gis programs can ingest. I’m currently using qgis and have a postgres database server in the background for archiving data and making it available to everyone else in the organization.

What is recommended? The POS file doesn’t seem to be readable by qgis directly but it seems to contain a bunch of data that is in excess of what should be necessary for a pure export of points. Is there an option in the librtk tools that allows and export of shp, csv or dwg files?

You should be able to create a KML files in RTKPOST and then,

  1. Open QGIS and click LAYER > ADD LAYER > ADD VECTOR LAYER.
  2. Select the KML file.
  3. Click on OPEN.

As far as I know, it should be possible to import a .pos file directly from the CSV data opening tab in QGIS. You should be able to specify X/Y/Z fields, and also truncate the required number of lines corresponding to the header.

I don’t have any details on hand, but I don’t see why it wouldn’t work although there might be issues with what delimiter is used.

The difference with the POS is that you are just going to get the points and not the actual track. You should get both with the KML and can turn the track into a DXF if you want. You can also use the GPX export, but KML is easier to deal with.

That’s true, but an actual path is only one tool away: Points to Path. You should be able to link the points by ordering them with the GPS time field.

1 Like

I’ll have to check out the POS workflow. Seems like there’s more editing of the import to get everything mapped correctly and the KML can also be used in many more different applications, but it may work better for some of the things we do. Thanks!

To be honest, I’ve never tried it, it’s just that I import text data and turn points into lines very often in QGIS. In my case, I’d definitely try cutting a step in another software if I could and don’t really have a use for KML. But if you already use KML for other things, it’s probably the best method.

This looks like the route to take…I’ve only been through these rtklib programs once to date so I’ve obviously got a lot to learn.

The KML tool in RTKPOST is saying the pos is an invalid input so I need to do some reading on that tool.

Thanks for the pointer!

I’ve seen that before, but don’t recall what it was. I’ll let you know if it hits me. You doublechecked that the POS has a solution and that the KML tool is pulling the right one? You can share the POS if you like.

I just tried importing in QGIS directly from the .pos file (base off a random test observation I had, I think I got it on this forum) and it works well. Delimiter specified as Space, 7 lines discarded from header, first record used as field names, and empty fields discarded. Everything gets aligned properly and the data table is super clean.

I can also see one advantage of doing it like this: the points will be imported as 3D entities and by using the points to path tool, the resulting line will also have a Z dimension for each vertice. That could be interesting for some applications.



2 Likes

That did it! So it does look like the POS file can be dumped into QGIS

I think this is the end of this thread officially…not just to play a mega dot-to-dot and create some polylines from this. :smiley:

3 Likes

Follow up question, again for mostly my education. The POS file has the correctional info applied to it already, does it not? After dropping my path and RTK points (that I measured through the survey tool on the rs+ when logged into it via wifi) into QGIS I noticed the following where it seems either my path or POI are displaced.

It seems like a few other spots where I can see the path near to a POI it seems to be a very similar displacement…north-east-north by about 80cm.

Could this be related to the wrong projection being used somewhere? I’m very sure the units were in full FIX through this section of the measurements and the base unit hadn’t been moved (it was also in manual mode over a known point).

If it isn’t something to do with the absolute position being shifted on your base, I would assume it’s a projection issue. Normally, you would simply need to make sure during import that the CRS is set to the correct value, most probably WGS84.

How did you determine the base position? Is it over a known marker or from averaging over time? If the former, verify in what system that marker is published. Here in Canada for example, it would be NAD83. For the most part it is compatible with WGS84 but with Emlid receivers, if your base used that NAD83 value, it would be logical to use the same CRS when importing the data in QGIS.

I was able to test a bit more. The first plots I did (for the screenshot above) were with the base location done with a 30min average single then copied to manual mode. The tripod was firmly planted on a concrete base with little holes drilled so the tripod could be accurately re-placed at the same spot so I don’t think there was any movement.

The day before yesterday I did another setup in a new location. 20min average single on the base and then copied to manual. This time I was set up over a survey monument but I’m not sure what it’s recorded location was but thought if I set up there I could see if the 20-30min single average locked in at the same spot or not. After getting the base’s position converted to manual I fired up the roamer, got a ‘fix’ and measured a few spots nearby. Here’s what I’m seeing with the comparison between the measured points and the ppk path:

The monument is just a few meters away, about where the help button is in the screenshot. Seeing a pretty consistent offset between the point clusters in the ppk showing where I held the roamer vs where the recorded point is seems to point that I’m still goofing something up.

Ah, I had actually misunderstood the problem. I thought you were having absolute accuracy issues but you’re saying that there is a difference between the survey in reachview and the track in the .pos file.

Since there’s no outside input and the positions are all coming from your receivers, we can rule out the CRS from a base station being the problem. If it isn’t a bug in Reachview, then it has to happen in RTKLib when you generate the .pos file. I don’t have enough experience with that to have an answer, but at least it gives us a clue as to where the issue is probably coming from.

My saved points are the most important and I can do point-to-path to generate paths that aren’t offset then use those to generate our one-call buffer polygons

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.