Hi Igor,
What processing parameters did you used for your processing, it looks fairly good!
Thanks
Isaac
Hi Igor,
What processing parameters did you used for your processing, it looks fairly good!
Thanks
Isaac
Hi Pazus,
On your point number 1 I happen to have a “strong” personal opinion, to me Emlid, if they decide to go for it, should only implement a single geoid undulation grid and that is NGA Geomatics - WGS 84 (provably as a separated download) and allow the end user to manually input constant vertical offsets in addition to that geoid.
My point is that EGM2008 is the best global geoid to date both in therms of quality and density that means that you can easily and accurately track the undulations of the equipotential surface only requiring constant vertical offsets to adapt EGM2008 to the local vertical datums.
On your point number 2, well it is a bit of a gray area, the “new” trend is to use crustal dynamics based datum variations (which makes perfect sense given the accuracies of the GNSS systems) unfortunately those datums require complex transformations and require annual speeds for the stations … Altamimi made some nice work for ETRS89 http://etrs89.ensg.ign.fr/memo-V8.pdf the problem with that is that I see that most cartographic institutions use the coordinates of their base stations to force a transformed solution in the coordinate solution of the rover… I can see people applying twice the same transformation becuase they though that the base station coordinates were not transformed. I would say that nowadays datum transformations only play a crucial role in SBAS (loose understanding of the term including OmniSTAR TerrraStar and the like)…
My two cents
Isaac
Thanks alot TB!
Isaac
It should be separate thread.
Ad.1
I totally agree with you that EGM2008 should be implemented as the only one at the beginning. Hence the suggestion to use geoid undulation with a resolution of 1x1 minutes. It may turn out that this completely solves the problem for all users, including surveyers. It’s going to take 933MB of memory but it’s worth it to give users to. Treating it as “internal” will make it very easy to introduce by EMLID.
So a polite appeal to the EMLID team
As a curiosity, I point out that in Poland, this model has been changed to adapt to local needs (a few cm differences, see fig.4 last page).
@igor.vereninov and @TB_RTK sorry guys to bother you again with more raw data to process but would you be so kind to try to achieve another of your beautiful “almost all fixed” solutions again? If so you can download the raw data from https://drive.google.com/file/d/1Ai91XRn7IjNLGl5jc7Irq06BFr8-tVxB/view?usp=sharing
Whenever you are finished please post the .con (Configuration file) used in RTKconv so that I can see what parameters are you using (and hopefully avoid bothering you ever again with this type of questions)
Many thanks
Isaac
Do you have this article in English?
Could be interesting to read
Something funky happend at 00:00 , not sure what.
So i removed this section and got nice a fix before and after with the config psted below. No RTKconv was used this time.
You also had hole, not sure what that was. I leave the rest up to you
This article (only in Polish) is to show the differences of such a simplification - the height differences are not large, just a few cm.
Hi Ryszard,
The Catalan local cartographic institution (ICGC) also reach the same conclusion as our Polish collages, the undulations from EGM2008 are great, there is just a constant offset (against local geometric levelling) of 595 millimetres, see catalan document at: http://www.icgc.cat/content/download/19840/63794/version/1/file/EGM08D595_v2.pdf (no english version, sorry).
If you want the coordinates of CatNet GNSS base stations (covering Catalunya) you can get them at: http://catnet-ip.icc.cat/spiderweb/frmSiteOverviewMap.aspx the three stations I used are surrounding Barcelona.
Thanks for your time processing my files, it is very much appreciated.
Isaac
This topic was automatically closed after 100 days. New replies are no longer allowed.