Hepos/GGRS87/TM87 added in ReachView3 v. 6.3

Dear Tatiana, I intend to post some photos from the field in the near future, and also share data from my projects


Hi @vgo195, @e_kroustalis,

Oh, sounds like something we should look into. We haven’t experienced it during testing on our devices here, so if you share the screencast of such behavior, it would be of great help.

@vgo195, on which device have you faced the issue with lagging? Is it an Android or iOS device? We have to know the exact model to investigate.

We would like to investigate it, too. To look into these misplacements, we need at least 3 points with known coordinates collected in ReachView 3 in this coordinate system. It helps us to compare the difference and check why it happens.

1 Like

Samsung J5 Android device here.
It is a bit old device but hadn’t issues before.


OK, thanks for the info! @kseniia.suzdaltseva will continue troubleshooting it with you and get back to you once we have any updates or additional questions.

I believe that trying to solve issues related to GGRS87 (EPSG 2100) would be a waste of time, given that this datum tends to be obsolete. It was superseded since 2009 by Hepos/GGRS87, which produces more accurate and consistent results. The realization of Hepos/GGRS87 is much more delicate, since it is based on a two-steps proccess (1. Application of the Helmert 7 parameters transformation for the whole of Greece. 2. Application of further 2D corrections according to the Hepos grid to cope with local movements of the earth surface due to tectonic activity). However, if you still want some measurements in GGRS87 (EPSG 2100) juxtaposed to measurements of the same points in Hepos/GGRS87, I can post them in the near future.

Hi Evangelos,

Thanks for the clarifications!

Each country has its own rules on the coordinate systems, and it’s always big detective work to get down to them.

I’ve just discussed this case with our GIS developers, as it seemed suspicious to me. And it’s indeed happened to be a tricky one — and consistent with your comment.

At the moment, we have 2 different GGRS87 datums in ReachView 3: GGRS87 and GGRS87 Approx.

  • GGRS87 Approx datum is the target datum we got after 7-parameters Helmert transformation
  • GGRS87 datum is the target datum on which both Helmert transformation and HEPOS horizontal grid applied

We initially thought that, in most cases, our users would need to work with the datum after the grid application. So, to work with the target datum without the HEPOS grid, you can choose GGRS87 Approx in ReachView 3.

Looks like the current naming is misleading. We’ll work on making it more precise.


Dear Tatiana,
leaving the matter of terminology aside, with the recent additions that you have done in version 6.3 of ReachView3 app, you have solved the major issues of coordinates transformations in Greece. I can verify that Hepos/GGRS87/TM87 (= Helmert 7 parameters transformation + Hepos Grid 2D corrections) is the datum that is used by NTRIP correction services, like HEPOS and HxGN Smartnet (I have bought a subscription in SmartNet).

Besides, perhaps the following image, which I have extracted from the Coordinates Section of Mobile Topographer, is of interest to you.

The following options are offered:

  1. GGRS87 (Greece 7 Parameters) = ReachView3 GGRS87 Approx.
  2. GGRS87 (H) (Greece Hepos, Kastelorizo excluded) = ReachView3 GGRS87/HEPOS.
  3. GGRS87 (H-Kas) (Greece HEPOS – Kastelorizo).
    Note: Kastelorizo is a remote island to the SE of Mainland Greece, in whose area different transformation parameters are applied.

Apart from the above, GGRS87 (EPSG 2100) is to be found in ReachView3 App (for details see: https://epsg.io/2100). This is the datum that was commonly used between 1990 and 2009. Its realization was based on three parameters, but its use is no more recommended in modern practice.

Let me again thank you and your collaborators for the great job you have done with the Emlid products and ReachView3 app!


Hi Evangelos,

Yeah, since the new-added CS works properly, the terminology is not that important. But we want everything to be consistent and straightforward, so we’d either change naming or remove the obsolete CS from the list at all.

You owe us the photos now! :joy:

1 Like

Please, do not remove anything from the list; some people may still want to use the old system

1 Like

I agree, some projects still require the old system bound with the official benchmarks.
So it is better to have 3 systems, the old GGSR87 the new HEPOS/GGRS87 with the grid files and it would be nice to add the HTRS07/TM07 which is the latest system.

Hi guys,

I created a project in GGRS87 / Hepos with the Greece GREEKGEOID2010 height and noticed some lagging on our Android devices as well. I’ve passed all the information to the team for further investigation. If there’s any news or we need additional details from you, I’ll write back.


Dear vgo195, HTRS07/TM07 is already included in v. 6.3 of the ReachView 3 app :greece:

Thank you very much,


your contribution is very important for many people working in Greece, who are already using or are interested in using ReachRs2 receivers

1 Like

Hey there,

We fixed the naming in the last ReachView 3 update.

The GGRS87 datum is now the target datum we got after the 7-parameters Helmert transformation (as was suggested by @e_kroustalis), and the GGRS87 Approx datum no longer exists to not mislead anyone.

1 Like

I tested the latest RV3 with the GGRS87/HEPOS projections and the app froze while pressing the (+) button to record a point. I tried various combinations with and without the greek hepos geoid file. Sometimes it didn’t froze but certainly there is a bug. The coordinates are correct though compared to other apps like SurPad.

Hi @vgo195,

Thanks for sharing your observations! We are in the process of testing GGRS87/HEPOS as well. I’ll describe our results here.

Hi guys,

We’ve changed the transformation algorithm in one of the previous updates and made additional tests to check the freezing issue. Overall, everything looked well.

For now, we only faced short freezing during the project creation. If there’s a more serious lagging in your case, please check the background processes on your mobile device to ensure it’s not the root. If there are many opened apps, it can slow down the work with the CS.

Dear Kseniia,

thank you and your team for all your efforts!

I will test the app in the field tomorrow using my Samsung Tablet as a receiver (I had no problems with my Xiaomi Mi-8 Lite smartphone) and I will let you know about the results.

All the best

Vangelis Kroustalis

1 Like

Hi Vangelis,

I’m curious about how your test went! Have you collected points with GGRS87/HEPOS and the latest ReachView 3 version?


My apologies for my delayed answer, but I wanted to test the app thoroughly before writing anything more here.

Here is the thing: when I first tested the new firmware I was dissaponted. I worked with the following configuration:

  1. I used a Xiaomi Mi-8 Lite smartphone with a sim card in it as a hotspot. Through this device I connected to a CORS network via NTRIP protocol, RTK.
  2. I connected a Samsung Galaxy Tablet T295 as a receiver. This device communicated with the ReachRS 2 unit via bluetooth, and with the Miaomi device through Wi-fi.
  3. The ReachView 3 app was configured to survey in Hepos/GGRS87/TM87 with orthometric heights in Greek Geoid 2010.

After having recorded the coordinates of a couple of points in the field, the receiver started disconecting all the time. I switched the sim card and I used the Samsung T295 as a hotspot and the Xiaomi M-8 Lite as a receiver, but the situation did not improve. However, I didn’t want to draw any hasty conclusions. As it turned out later, this malfunction had nothing to do with the ReachView3 app. It was rather due to the very high temperatures of that day (I live in Athens).

Meanwhile, I have tested again three more times the app according to the above configuration, in NTRIP and Base-Rover, and it has worked flawlessly.

So, congratulations!! You have made it!

I am only missing one minor functionality: when surveying in RTK with a Base-Rover configuration the positions of the Base and the Rover do not appear on the screen. I don’t have this problem when surveying in NTRIP