In reply to F6ENO:
There could be lots of reasons;
KML coordinates entered incorrectly.
Google Earth & KML editor use a different datum (don’t pull me about grammar, it makes more sense this way).
Google Earth aerial photos not geo-referenced exactly.
If you look at a hill in 3d on Google Earth, you will see that the elevation data & photos do not register accurately (at least they don’t on G/NW-001 Snowdon/Yr Wyddfa). That error is within the application, so external errors are likely too.
At the end of the day, Google Earth does not claim to be extremely accurate, so I wouldn’t expect it, or any add ons, to be.
As an activator, I can tell when I’m at the summit…usually
Chasers only need to point a beam within 5 degrees or so.
It might be nice if it was all 100% accurate…but I can’t see any real benefit to the effort that would be involved.
As an activator, I can tell when I’m at the summit…usually
Chasers only need to point a beam within 5 degrees or so.
Yes of course, but my problem is not about positionning SOTA summits exactly
It might be nice if it was all 100% accurate…but I can’t see any
real benefit to the effort that would be involved.
Well, have a look there http://pagesperso-orange.fr/f6eno/Sommets/preparation/preparation.htm
you will find a short track (yellow) for a future SOTA expedition (and its file “test.kml”)
This track was drawn with a navigation program, and we can see the error (only in latitude). I’m rather sure that the soft (Carto Explorer) is accurate. It seems also that this latitude error is constant.
In reply to F6ENO:
I assume you are using the summits.kml file which I produce.
The coordinates in this file are derived from the SOTA database, which in turn are supposed to correspond to the respective ARMs. I do any necessary conversions as accurately as I can, and round the final result to 4 decimal places of degrees. However the accuracy is in general nowhere near as good as that precision might lead you to expect.
First of all, ARM coordinates are normally for identification purposes only, and there is no claim that they represent precisely surveyed positions. The inherent precision of the raw data may not be very good; in the UK for example the coordinates are based on 6 figure grid references, so a coordinate represents a 100m square.
Even though all of my processing is automated, it is clear that there has been a lot of manual processing of this data, and it would be surprising if some errors had not crept in. A few of the more blatant ones have been corrected.
On top of all of this, there is often a very real difficulty in knowing where the summit actually is. A map will not tell you accurately; contours are not normally accurately surveyed but are usually drawn from aerial photography data. Different countries are likely to survey to different standards. Accurate determination of the highest point on a flattish top can be extraordinarily difficult.
You cannot rely on Google Earth to tell you where the summit is. The 3D model that you see is made by combining the satellite and aerial photography data with an entirely separate data set of height data based on radar measurements. The height data is recorded on a much coarser grid than the images. What you see is the result of wrapping those images onto a 3D surface which is largely the result of interpolation. It works very well to give you an idea of the terrain, but there is no way that it can be used to determine the highest point.
Taking all of these factors into account, I think we have to regard the Google Earth file as just a convenient indication of the approximate location of a summit. It would be good to have more accurate data, but to do it consistently would be a lot of work.
with terrain view and zoomed to maximum. The reported altitude 2159 m is close to the 2156 m in the reference manual, but the position is a little off from the summit on the Google map.
Last time on Mont Vorassay August 24 I reconfigured the tracker so that it would send also the GPS uncertainity of the position, but then no packets were relayed to the internet anymore. I was also testing tracker profile switching, so that I could send the activation frequencies from the summit. Need to take a few steps back to see why it did not work anymore.
I assume you are using the summits.kml file which I produce.
Yes Martyn, and I know you used SOTA database ie ARMS for your kml file.
My problem is not abt positionning accuratly SOTA summits on Google Earth. Coordinates found in ARMS are good of course.
I am writing a conversion soft for Google Earth and my datas are comming from a Carto Explorer file (rather accurate). When I see the result, it seems not very good as seen on the above example http://pagesperso-orange.fr/f6eno/Sommets/preparation/preparation.htm
have a look to the “test.kml” file
I tried many examples and some areas are good, other not. I suppose it is due to 3D and the drift varies with altitude.
Even though all of my processing is automated, it is clear that there has been a lot of manual processing of this data, and it would be surprising if some errors had not crept in.
Your work is perfect Martyn. No doubt in my mind.
Do you know how to launch Google Earth when clicking on a kml file on line (ie on a web server) ? It does’nt work on my computer and I have to download the file first on my disk, then it works…
When I see the
result, it seems not very good as seen on the above example
This offset could be caused by using the wrong datum, as somebody else mentioned. Most countries have their own national datum which predates the WGS84 system used by GPS. This document has some information about this for France:
Google Earth is referenced to WGS84; are you sure your coordinates are?
Do you know how to launch Google Earth when clicking on a kml file on
line (ie on a web server) ? It does’nt work on my computer and I have
to download the file first on my disk, then it works…
The server is supposed to tell the Web browser the type of the file as a MIME type, which more often than not it infers from the filename extension. Then the browser has a table which tells it what program to launch for each MIME type. So both server and browser have to be set up right for this to work. If the server is just delivering the file as something generic like application/octet-stream, there may not be much you can do at the client end.
Google Earth is referenced to WGS84; are you sure your coordinates
are?
The present IGN maps have quite good WGS84 UTM coordinates. Also my GPS WGS84 coordinates agree well with these coordinates on the new IGN 1:25 000 maps. I think the problem is with the Google Earth. Since it is not open source as far as I know, it is impossible to say if the uncertainty is deliberate or not.
it is impossible to say if the uncertainty is deliberate or not.
I suspect it is not deliberate. Georeferencing all of those images and other datasets accurately must be a daunting task.
There are cases in which Google Earth is not self-consistent. In some countries the road overlay does not always match up with the images of the roads, so at least one of them must be in error by a noticeable amount.
Using software from the Land Survey of Sweden at home or even better, professional software at my work (using to design and planning radio-relay networks), I can get coordinates down to ONE centimeter resolution with RT90 Swedish grid - Wikipedia of where a certain leg of an mast is located. It is extremly important to know where exactly a antenna carrier is to be placed… Two hundred meters away, there might be another carrier owned by a different operator, and I dont want to put my equipment in wrong position…
Transform to WGS 84 or any other, for google maps or google earth, the result I get is that it is not the exactly same spot, but you are quite near by 2-300 meters or so…
