hey all, i have written some python code to manage processing shapefiles from the reach receivers and i want to share it. Hopefully if someone else needs something like this maybe my code will help you out. This is Python 3 written on windows 10 and calls GDAL OGR libraries.

WARNING this code is designed to work in my semi automated work arrangement so its not going to work for you out of the box. You will need to rework it to fit your situation. furthermore just because this code works for me doesn’t mean it will work for you. for example anything having to do with date, times and latitudes and longitudes may only be set to work for where i am at (California, USA).

first here is my background local library for functions i use across everything i write. it includes code for leveraging my OSGEO4w install.

you save it to :

C:<your python install>\Lib\site-packages

then i have a simple script that takes things like the ‘projected’ field and parses it out into separate fields. there’s a bunch in there you may not need.

then i wrote a processing front end for RTKLIB PPK. the underlying idea here is that i was never able to get everything i wanted out of one configuration set for rtkpost. so i decided i would rather run configuration files in a serial fashion where configurations run from most conservative to least conservative. the code creates a shapefile from the first PPK process (.pos) and then with subsequent config file runs, if there are fixes they overwrite any remaining float values. then if you have a shapefile of points from your rover the resulting kinematic shapefile will be used to improve the points in your rover file records

here are my config files:

numbered 1_.conf where the number represents what i believe to be the most conservative settings and 6_.conf is the least conservative settings.

here is the code

and here is a test set you can use

in an effort to develop better techniques to improve productivity, the team i work with has laid out a testing and training site. the site has a number of OPUS based monuments and using a total station we created a monument in a heavy canopy area. The canopy cover is heavy enough that i have been unable to get a real time fix even with the base station within 50 meters. however, i have been able to get PPK float values within 20cm and all of my PPK results that were fixes, where i have a matching RTK value, also show significant improvement (compare to the OPUS control monuments). The main advantage i am looking for is to not have to fiddle at all with the RTKLIB GUI after each project, (though i still do the UBX conversion there).

so there it is, maybe someone will find it useful, if you write Python it should be fairly straight forward reading to see what it does and how.

and i would like to thank Tim Everett for his work at


well i have done allot of cleaning of the code and added in weighted point averaging (numpy) and calculating the distance each point is adjusted (pyproj).




Thanks for sharing your work and updates on it with us! :heart_eyes:

It’d be great to know what results our users would be able to achieve with it :slight_smile:

May I ask you what you find uncomfortable about RTKLib GUI?

Hey Polina

I am really very new to using rtklib so take what i have to say keeping that in mind. RTKLIB is a great program, i love that its portable and that it uses configuration files. but if your using the reach units allot then theres no reason why not to do some automation to make things smoother. with the GUI it is a pain to perform multiple runs on the same file and integrate them together manually. furthermore, i wanted to be able easily PPK improve my rover survey file without much hassel. now if i loose my RTK fix (which is more often than i like) i just sit on my next point for a while till i figure i have enough data to successfully PPK my point. at least for my workflow, the code i wrote really makes it painless.

Nice compilation right here. I will give it a spin, thanks for sharing!

sure have at it, i just uploaded a new version, chasing down a few more bugs, last set of bugs were due to not testing it on 5hz data. biggest issue left is that it is slow. like run it over night slow on a 30mb raw file. bottle neck is where it goes to integrate each new set of fixes into the composite layer. so the first layer is the product of

the next set of fixes (points not fixed by the conf. above) are then created from

they then have to be integrated into the composite layer

i believe the bottle neck is with
PPKtempFe = outLayer.GetNextFeature()
while PPKtempFe:
daid = PPKtempFe.GetField(“gnss_id”)
combinedPPKlayer.SetAttributeFilter(“gnss_id = '”+daid+"’")

which is a bit odd since with each RTKLIB conf file i run i get progressively diminishing returns. and the bit above is pretty standard for GDAL OGR so not sure how to do it otherwise. overall it works fine the way it is, but with that bottle neck it wont make sense to try to move it all to a QGIS plugin which is what i was thinking of doing.

1 Like