Closed n8ur closed 1 year ago
Actually Google Maps is also supported. The code (gmview.*) can be found in appcmn_qt/ directory as it is also used by srctblbrows_qt.
BTW: I just found another bug in the code that was introduced while adapting it to support API keys for google maps.
Hi Jens -- I'm not getting anything to happen when I hit the Google Maps button in rtkplot_qt. I've entered my key in the options dialog. When I press the button I don't see an error -- nothing seems to happen at all. Is there some other configuration I need to do to get it working?
Thanks!
Strange... for Google Maps and Google Earth there are buttons and menu entries. Please have a look if the menu entries is enabled (a.k.a. not greyed). Both - maps and earth - are only available if a html engine (qwebkit or qwebengine) is installed on your machine (incl. header/development files).
I didn't have either of those installed. Have done so now and am rebuilding. Should there be a dependency for webkitengine (which seems to be the new preferred one)?
It depends on you Qt version you're using. Since version 5.6 only qwebengine is available. Probably you won't have any choice.
There is some logic to decide whether to use qwebkit or qwebengine or to use neither. Still rtklib_qt will work, just having these features disabled.
Got it rebuilt with qwebengine and now the Earth and Map buttons open a window. But the window is just white and rtkplot_qt puts this message on the console: js: Uncaught ReferenceError: jstProcess is not defined
I'm guessing means there's some missing javascript package. I have node.js and its prereqs installed, so I'm not sure what might be missing.
Making progress. The map is now displaying but javascript is throwing a bunch of warnings to the console, stuff I think will be straight-forward to clean up. A slightly nastier problem is where to install the .htm files. The code currently looks for them in the execution directory. One problem is that they need to be somewhere that's user-writable because the API key gets written into one of the files. I'll send you patches when I finish slogging through this.
Please have a look at my latest commit. No additional file is created any more. This should solve the issue. The remaining warning might be due to the missing Google Earth plugin. I think it's no longer available. I just kept the code of Tomoji untouched.
Great minds work alike -- I was working on something similar last night but you beat me to it!
The only difference is that I was getting rid of the .htm file entirely by putting its contents into a const QString in rtklib_gm.h then copy that into an html_page variable, and run Qstring::replace("APIKEY", ApiKey) over it (though your insert_line would work just as well).
I'll build your code and play with it. I might then still try to add my idea as I am just happier having fewer files floating around -- though on Debian you could put the htm files in /usr/share/rtklib/ .
Thanks again for your work on this! I'm part of a group of time-nuts who are looking at using the clock offsets that come along with PPP results for measuring and disciplining frequency standards. Having a clean Linux version makes some of us a lot happier. :-)
My solution was quick and simple. I really like the idea to store the whole html code in a string and get rid to the extra file. If you come up with some code, I'm happy to merge it. I wrote the qt version of the GUIs also for PPP. But my focus was originally highly precise position retrieval and ionospheric monitoring. I just had a quick look on your web site and was impressed by your work on frequency standards. What uncertainties on time/frequency do you expect your PPP?
I've spent today working on ways to embed the html within the executable. It's not as easy as it ought to be! But I think I found a workable solution that I will try tomorrow.
Regarding the time uncertainties, we use a statistic called Allan Deviation to express stability at given measuring intervals. It's like standard deviation but adapted to the non-gaussian noise in clock systems. You can think of the ADEV as how much the frequency is likely to change between readings taken x seconds apart (called "tau"). So if you have 1 microsecond of jitter on a pulse-per-second signal, if you look every second, you'll see 1e6/1, or ADEV of 1e-6. At ten seconds, it's 1e6/10, or 1e-9. etc., etc. Atomic frequency standards (rubidium, cesium, hydrogen maser) have noise floors at long averaging intervals in the 1e-13 to 1e-15 range (recent optical standards are better than that).
The time offsets that come out of a PPP solution have resolution of 1 picosecond (e.g., you'll see the offset shown as maybe 145.125 nanoseconds) relative to the GPS system time. There's a certain amount of noise in the measurement system itself, and that's what we're testing now. Attached is a very preliminary plot showing the stability of a hydrogen maser located in Brussels, Belgium (BRUX00BEL0), showing uncorrected, real-time corrections, ultra-rapid corrections, and a traditional single-frequency GPS system (CNS-2) for comparison. (I'm also going to get plots from the rapid and final corrections.) Those are some pretty impressive numbers considering they don't require any measurement instrumentation beyond the GPS receiver itself -- normally you need very sophisticated time interval counters to get this kind of resolution.
National standards labs have been using GPS to do common-view time measurements, but they have tended to use the GPS time as a transfer standard between say NIST in the US and NPL in the UK. What we're doing instead is directly comparing to GPS time. There are some next steps beyond that, but I've probably told you more than you wanted to know!
Just a point of vue : When I started to use rtklib through wine I wasn't very happy to see this Google earth icon in gui software. I know this qt is based from original and use same behaviour. So why not by passing these Google things and use openstreetmap inside an opensource software ?!
Hi Jens --
OK, the deed is done. It took a while to figure out the best way, but I've created a new file in app/appcmn_qt called "gm_template.h" that is the htm file wrapped up in a raw literal QString. I put in a placeholder called underscoreAPIKEYunderscore, Then I do a QString.replace("underscoreAPIKEYunderscore", ApiKey) and feed that to the WebBrowserView object. In the code, "underscore" is a real underscore, but the github editor interpets it as italics.)
It seems to work just fine. I'm attaching a zip file that includes the new gm_template.h file and the modified gmview.cpp file. gm.zip
@kikislater: Google Maps & Google Earth was used by the original rtklib version by Tomoji. I just ported the GUI to Qt, not the logic to be able to apply patches from the original version to my code. A feq days ago, Tomoji announced on his blog that he'd like to replace this non-functional code with new code based on leaflet project. This would also support several map providers beside google. Unfortunately, I don't know about the time frame of this project.
@n8ur : I further simplified your code and applied it. Thanks a lot.
I know a bit about time and frequency measurements and their stability. Allan deviation is nothing new for me. That's why I was asking about the expected uncertainty. Normally we use normal VCXOs for frequency reference. But they are stable only in short time. For long-term stability referencing it to GNSS would be nice.
Trying to build nowadays, I have this error :
./appcmn_qt/gmview.cpp
../appcmn_qt/gmview.cpp: In member function 'int GoogleMapView::setApiKey(QString)':
../appcmn_qt/gmview.cpp:61:42: error: 'dir' was not declared in this scope; did you mean 'div'?
61 | WebBrowser->load(QUrl::fromLocalFile(dir));
| ^~~
| div
make[2]: *** [Makefile:1359: gmview.o] Error 1
make[2]: Leaving directory '/home/sylvain/build/rtkj/app/rtkplot_qt'
make[1]: *** [Makefile:106: sub-rtkplot_qt-make_first] Error 2
make[1]: Leaving directory '/home/sylvain/build/rtkj/app'
make: *** [Makefile:73: sub-app-make_first] Error 2
Any hints to solve it ! ?
I see that the Google Earth support files (geview.cpp etc.) are in the rtkplot_qt directory, but the ones for Google Maps don't appear to have been ported. I'm willing to dig into that but first wanted to make sure there wasn't some underlying reason why it wasn't ported, or some incompatibility that makes it difficult to do.
Would it be feasible to use the geview files as a template for the maps interface?
Thanks, John