It’s just a module so I would not have expected any correction
for WGS84 but maybe there is? My sample size for measurements is small
I must get out more!
No, I wouldn’t have expected it in a “module” either. But you never know. A Geoid model with an accuracy of a few metres wouldn’t need all that much memory.
The error bounds on a GPS height tend to be quite a bit larger than those of the horizontal position, simply because of the geometry of the satellites. You might reasonably expect to be within 25m 95% of the time.
I was thinking of putting all the sota summits on an SD card for my APRS system to allow automatic activation zone alerts. It’s been a long while since I coded any major sorting system and so I wondered what might be a good approach to finding the nearest summit to the GPS location? Initially it could work in the background sorting the stored data into a useful order perhaps based on distance from the GPS location. Nice simple-to-code algorithms prefered!
Take the summit data and convert the NGR back to lat&long and then form a string out of the decimal lat&long. Put the data for the summit into a list and put the list into a dictionary using the stringified lat&long as the dictionary key. To find the summit get the lat & long from the GPS, convert to a string and look up the data. Using a proper language like Python for this is trivial and the hashing function that the dictionary in the standard library uses is very good, so lookups are fast. Should be straightforward using STL and C++ all though will need much more effort than a Python soloution. I don’t do Perl but it’s probably straightforward in that too. And Ruby, Lua, Java etc.
Doing it in that oddball Propellor language will be “challenging”.
At one time I used to think that if you didn’t write it in assembler and squeeze every last ounce of performance from the CPU you were some sad business software programmer. Then I grew up and realised you should try to use the best tools and languages for the job. There’s no one language that is best, there are some languages that are better than others for some tasks. I gave up writing my own sort routines when I worked out the ones provided in the container classes were likely to be better than I’d need and would work in Tommy Cooper mode ( ‘just like that’ ) for zero effort.
The Propellor is 20MIPS/cog. You should be able to do a simple linear search through all 48000 summits in no time at all. That may be more than good enough.
Take the summit data and convert the NGR back to lat&long
Since the summit list already contains the lat/long for every summit (with just 2 annoying exceptions) that part doesn’t need doing. In any case it would only work for the British Isles.
and then
form a string out of the decimal lat&long. Put the data for the
summit into a list and put the list into a dictionary using the
stringified lat&long as the dictionary key.
I always think it’s a bit dubious to use textual matching on numeric data which is subject to uncertainties and rounding. A string lookup in a table can only do an exact match. It may tell you that you are “at” a summit (for some meaning of “at”) but it won’t tell you the nearest if you are not, which was the problem set. How many decimal places would you round to? Too many and you will only get a match when very close. Too few and you will get multiple matches and still won’t know which is nearest. Remember too that many coordinates are stored to a greater precision than their accuracy truly justifies.
There doesn’t seem any real merit in doing a sort. No general purpose sorting algorithm can scale better than N log N in the number of elements, but would be doing far more work than is needed. A linear scan will scale better, and will be plenty fast enough as long as you don’t do too much work for each one.
The vast majority of summits can be eliminated very quickly - for example if EITHER the lat OR the long differs by more than some threshold there is no point in knowing the exact distance. For any that are plausibly close, you can do a distance calculation (either a proper great circle calculation or a simpler approximation, as you wish) and keep track of the closest. If you assume that you aren’t going to move very far, the first pass can make a “short list” which can be used next time.
I can see whre you are coming from Martyn. In fact I was going to do a rough sort simply by seeing if the lats or longs differ by more than +/- 1 degree from the current one. A comprehensive sort has all sorts of problems, not least being the differing read/write delays which makes some algorithms look pretty poor.
Andy clearly has not looked closely at the data in the database or he would have spotted that the lats/longs are already there!
I haven’t actually measured it, but I think that the extreme eastern point of the enormous AZ for G/SE-013 could be closer to the summit of G/SE-015 than its parent summit.
Looks like I will be out with the EYPs on Saturday. I will have the APRS and will be trying the automatic spot system out. It is untested and there is a lot to go wrong - so apologies in advance for any mayhem that the auto-spotter causes.
I will pre-process the data from Andy’s database by adding 180 to the longitudes and 90 to the latitudes (to make everything positive). I then multiply them by 10,000 to give me a list of integers (floating point = SLOW). I will speed the process further by presorting the list based on my home location. That’s what I will store.
The embedded sort is then a simple matter of doing the same sort of manipulation to the lat and long from the GPS and comparing each to the list, I sum the deviation and sort by that. Simples.
The smart ones will realise that this list is not actually in order of distances - however, I suspect that for my application it does not matter…
The auto spotter is now working. I have found that vdop is badly degraded in a rucksack as the sky view is limited by the wearer. This leads to poor geometry. I will be experimenting with a slightly less restrictive algorithm as at the moment I have to take the rucksack off to get the highest precision - required to send the messages.
Hi Richard, sounds like you’re having fun. I nowadays invariably put my GPS device in a plastic bag in the top pocket of my rucksack where it gets the best possible view of the sky.