Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - captain paranoia

Pages: [1] 2
1
Maps / eDofE mapping
« on: June 27, 2014, 01:49:03 PM »
I know there are a few DofE types here, so I'll ask for help...

I'm hoping to have a play with the DofE's eDofE mapping, with a view to getting our groups to start using it to enter and share their routes (and maybe plan them).  Now I've got an eDofE account, but, for the life of me, I can't find the mapping app on the eDofE website.  I can find at least four different PDFs saying how wonderful it is, and how to enter routes, etc, but not one of these documents gives URL for the program, or says clearly where it can be found.  And I've searched high and low on the DofE website, and in my eDofE portal, but with no joy.

So, if anyone out there can point me in the right direction, I'd be grateful.  As it stands, I'm getting rather frustrated...

2
New Techniques & Learning / Approximating microleg timings
« on: May 20, 2014, 06:02:15 PM »
Whilst supervising DofE bronze practice at the weekend, I was dismayed by the inability of participants to do simple mental arithmetic.  They're taught to estimate their speed at about 3kmh (yes, it's slow, but it's about right for these groups...), so they're told to allow 20 minutes per kilometre.

We tell them to measure the length of the microleg with the appropriate compass romer (and it's a challenge to get them to use the right one...), and then convert that into the number of minutes they should have to walk until they get to their next decision point or navigation feature.  But they all struggled to do even the simplest of mental arithmetic; 0.3 times 20 proved very difficult, and even 0.2 times 20 produced a variety of results before they finally settled on 4.

I guess this is a consequence of over-reliance on a calculator, and the deprecation of the use of rote learning of the times table, but it's a problem.

So, whilst trying to explain this, it suddenly struck me that, if they stick to their 3kmh, 20 minutes per km estimate, each tick of the romer scale is 2 minutes.  This they could cope with...

I know it's a pathetically simple technique, and would have to be scaled for faster walkers, but it actually seemed to work for the groups I was with.  I'm sure it's been used before, but I don't recall reading about it.

Oh, and the other problem is them not wearing watches; again, technology means they use their phones to tell the time...

ps. the first time I encounter the groups is during supervision; I don't get to do any instruction prior to their expedition...

3
A friend recently asked my advice following an experience with an MRT call-out in the mountains.

The team members are equipped with radios that add a GPS fix to each transmission, allowing the users to be tracked.  In the event in question, the radio wasn't used until the team member arrived at the casualty.  The fix placed the incident on one side of a mountain ridge, and a helicopter was called in to this location.

As it happens, the GPS fix was wrong, and the incident was actually on the other side of the ridge.

Since I'd discussed the effect of multipath and reflections on a UKC thread, the question to me was "was this a multipath incident?"  And my conclusion, looking at the traces of the incident, was that it almost certainly was (strictly, it was a shadowing & reflection problem).  Quite where the reflections were coming from that fooled the GPS receivers is hard to determine, but the incident occurred in a gully that gave at least 270 degree blockage, and in some parts, formed an almost complete bowl.

The problem is associated with canyons, and occurs in mountainous and urban environments, where the direct path between satellite and receiver is blocked (or 'shadowed'), but a signal is received from a reflecting surface, such as a cliff face or tower block. These reflections add additional path lengths to the measured pseudoranges, and so fool the triangulation calculations, pulling the fix away from the actual position. The problem is exacerbated by the increasing sensitivity of modern receiver chipsets, which can lock onto, and track the (generally) weaker reflected signals.  As the satellite constellation moves about, the reflections come and go, so a static user can appear to jump about.  If a satellite moves into direct view, this will often cause the position fix to jump back to the 'real position'.

The next obvious question was: "how can we tell when this effect is happening?"

Sadly, the answer to that is "tricky..."  Here are a few things that should start to ring alarm bells, and let you consider the possibility that the fix may be in error:

You're in a gulley, or a steep-sided valley.  There are slab-sided rock faces around you (although even more rounded or broken-up surfaces will cause problems).

If you're tracking users, and have regular updates*, then look out for sudden, large changes of position, which will look like long, straight track sections (you need to consider the time interval between fixes, too, as lack of intermediate position updates will also look like this).  Also watch out for zig-zagging paths, since these are often caused by changing reflections.  Of course, they can also be caused by zig-zagging up a steep face...  It might be possible to provide a graphical indication of large jumps, by colour-coding the traces with apparent velocity, so that jumps are highlighted in red, for instance, and 'normal progress' in green.

* that might be another recommendation: make sure users report their positions regularly, and don't simply wait until they're 'in position'; that way, you can track their progress, and probably detect large position jumps.  If you're using radios that prepend a GNSS fix to all voice transmissions, instigate a regular 'comms check' procedure (this might simply be a pressel/PTT, rather than an actual voice message), or, if the radio supports it, enable a regular, autonomous position transmission.  You'd need to consider the effect on battery life, of course.

Keep an eye on the receiver's accuracy estimate, since the receiver computation should be able to determine that the signals "don't add up"; the longer reflected path length is likely to cause a large error circle (cf a conventional 2D resection on a map; think about the size of the 'cocked hat' if you deliberately include a bearing error).  A poor accuracy estimate should warn you that something may be amiss.

If you can display the satellite constellation and C/No values for the receiver, you might be able to see if the geomorphology is blocking a number of satellites.  If your control station is fairly close to the incident (say 50km), then, if it has a clear view of the sky, you should be able to know what satellites should be visible, and compare them to the satellites received by a team member.  Since the satellite orbits are known to the system by almanac and ephemeris, it ought to be possible to display the predicted satellites (although I cannot tell you a system that will do this; GPS Test, perhaps?).

For a receiver equipped with mapping of some sort, and a user who can navigate without GPS, it should be obvious that the receiver is giving an incorrect fix (e.g. in this case, obviously on the wrong side of the ridge), and this might be reported to control.  Assuming voice comms is available...

Oh, and SBAS (WAAS/EGNOS etc) won't help, since it corrects (mostly) for clock and ionospheric errors, and knows nothing about the local multipath & reflection environment, so cannot correct these errors.

For the future, one might envisage a system that used ephemeris and a terrain map to predict possible reflection hot-spots, and provide a warning to users and control that GNSS fixes might be being distorted, either in real time (using a constellation model), or statically (using only the terrain map).  There is quite a lot of work going on at the moment addressing this problem of shadowing and reflections in urban environments (since urban users now dominate GNSS use).  There are a couple of interesting figures in the following paper that illustrate the sort of problems that occur, and the kind of traces that result from reflections distorting position fixes:

http://www.cs.bgu.ac.il/~eranfrie/gnss_signals_in_urban_canyons.pdf

The yellow trace is the actual path, and the red trace is the GNSS computed path.

My understanding is that SARLOC retrieves more data from the receiver than a simple position fix, and that data might usefully be displayed to a control operator to help identify possible reflection issues (estimated error radius, visible constellation, C/No).  The coloured trace & error radius ideas would be applicable to MRMap.  If any of the MRT/SAR types on here have contacts with SARLOC or MRMap developers, feel free to pass the suggestions on.  I'm also more than happy to hear feedback on the discussion above; it was pointed out that my naïve, laboratory-based suggestion of a way to reduce reflection effects might be the last thing on the mind of an MRT member on a steep, wet, scree slope...

4
Satnav (GPS GLONASS COMPASS Galileo) / Tesco Hudl tablet
« on: January 30, 2014, 12:55:45 PM »
Having bought one of Tesco's Hudl tablets a couple of months ago, I've been using OruxMaps and Locus for mapping and navigation.

I had noticed that it managed to find a lot of satellites, and I put that down to it using a receiver chip set which must feature more than the 12 channels of my SiRFStar III equipped PDA.  However, playing with another app, GPS Status, last night, I noticed it was reporting Satellite Vehicle IDs greater than 32.  I guessed that it must be receiving GLONASS too, so I checked the GPS Status user manual this morning, and yes, that's exactly what it's doing.

I shouldn't really be surprised, since multi-system chipsets have been around for some time, but it was a nice surprise to find that my cheap Hudl included GLONASS; Tesco's spec doesn't mention it, but then it just says 'GPS receiver', with no further details.

5
Apps / Skiing apps
« on: January 28, 2014, 06:08:46 PM »
During a recent skiing trip, we played with a couple of ski tracking apps:

Ski Tracks

https://itunes.apple.com/gb/app/ski-tracks-gps-track-recorder/id365724094?mt=8
https://play.google.com/store/apps/details?id=com.corecoders.skitracks&hl=en_GB

Ski Pursuit

https://itunes.apple.com/gb/app/ski-pursuit/id484556768?mt=8
https://play.google.com/store/apps/details?id=com.rossignol.android&hl=en_GB

Both record where you've been, and spit out loads of stats on speed, height, no. of runs, etc. and will display on GoogleMaps or upload to Facebook (if that's your thing...).  Skit Tracks is 69p or 79p, and Ski Pursuit is free (it's a Rossignol-sponsored app).

6
General navigational Kit / Romers and other measuring tools
« on: August 20, 2013, 07:31:52 PM »
I posted threads on a few little tools I've developed over the years, but I was reminded by a recent thread that I ought to upload the PDFs for people to play with.

So, we have:

contour_ang for measuring slope angles from contour spacing
unm_grt a grid measuring tool for Editorial Alpina 1:50k 5km grid maps
map_grid_publish a 1:25k vernier romer
plotter_grids a combined vernier romer/portland plotter
navtool a combined vernier romer/portland plotter/ruler/slope tool

These are all written in PostScript, and designed to be configurable, so if you have any special requirements, they can be met.  They generally include multiple copies for efficient use of a transparency, or include multiple different versions to show the sort of options that can be selected.

They're all intended to be printed onto transparency (ideally with a colour laser printer).

7
Apps / iPad/iOS mapping apps
« on: August 16, 2013, 03:32:45 PM »
A thread for posting mapping apps for the iPad/iPhone.

I'll start with

http://galileo-app.com/

Feel free to post other suggestions.

8
Having been given a new PC at work, I've been trying to get all my old software tools re-installed, and one of them is http://www.soi.city.ac.uk/~jwo/landserf/.

Since my new PC is supposed to be faster than the old one (it has 8 cores now...), I thought I'd throw some more difficult tasks at LandSerf, so I got it to generate contours for my local area, from the Space Shuttle Radar Telemetry elevation data.  And it still takes quite a long time, because it only uses one core to do the processing.

However, having generated the contours, I thought how useful they might be for helping to teach contour interpretation and use of contours for navigation.  You could generate a pure contour map for an area, and give it to students to get them to navigate with it.  This would remove the 'unnecessary clutter', and force them to look at the contours.  There are other tools to do this contour generation, or you could use the topo data generated from the SRTM data and available for Garmin units (on the SMC website)

LandSerf is a rather nice little tool for geomorphological analysis, but I've hardly touched its capabilities.  I've used it to take the 1 degree SRTM tiles and re-project them to OSGB projection, to add elevation colouring and solar relief shading, and to generate contours, but it can do all sorts of other clever analysis, like slope, slope aspect, profile curvature, etc. most of which I don't understand... the 'feature analysis' can be made to find valleys, ridges, peaks and troughs in terrain.

9
Variations of Existing Techniques / Sunrise, Sunset and Solar Azimuth
« on: July 09, 2013, 12:44:14 PM »
Some time ago, whilst looking at solar relief shading, I thought about where the sun's azimuth, and decided that the sun never appears above the W-E meridian in the UK.  Of course, that's completely wrong, as I realised when looking out of the bathroom window early one morning, to see the sun rising well to the north of east...

So, I started to think a little more clearly, and looked at the maths for calculating sunrise and sunset times.  Whilst searching to see if I'd got it right (I hadn't...), I found the following NOAA website, which has a nice integration with GoogleMaps, and will calculate sunrise, sunset & local solar noon times,  and draw sunrise/sunset and current solar azimuth lines over GoogleMaps, calculating for any specified time and date.  It's nice to check that the solar azimuth shown for the local solar noon is actually due south...

NOAA Solar Calculator

10
Apps / Android Mapping Apps
« on: June 28, 2013, 03:06:00 PM »
Prompted by another thread, here are some mapping apps for Android devices:

http://www.oruxmaps.com/index_en.html

http://www.locusmap.eu/

http://codesector.com/maverick

A useful (PC) utility for making map sets for these apps is

http://mobac.sourceforge.net/


Feel free to chip in with any other apps you've found.

11
Maps / Online Definitive Mapping (GB)
« on: June 28, 2013, 02:48:52 PM »
In Great Britain*, local councils are responsible for maintaining the Definitive Mapping of Public Rights of Way.  Historically, this was often a copy of the 6" to the mile OS mapping, annotated with the rights of way.  And it was usually stored in a locked filing cabinet, in a dark room with a sign on the door saying 'Beware of the Leopard".

However, more enlightened councils have started to digitise this definitive mapping, and even make it publicly available.  A list of such councils may be found at http://www.geograph.org.uk/article/Definitive-maps-online

Some councils go even further than this, and provide very nice Geographical Information Systems to allow you to see the mapping, and the PRoWs, and any 'incident reports'.  One very nice example is provided by Dorset County Council, and covers not only Dorset PRoWs, but those of neighbouring counties (where data is available):

http://explorer.geowessex.com/

Use the right-hand menu 2nd item to select OS base mapping (single monitor icon) Use the right hand menu 3rd item to select overlays 'Countryside/RoW + Other Counties RoW'

This PRoW data is now starting to find its way into route-planning tools; my colleague Bill Chadwick working to incorporate it into his WheresThePath website.  This makes creating paths quite a lot simpler, and with the knowledge that your route should follow the definitive path.  However, the old computer adage 'garbage in, garbage out' still applies; there are, of course, errors to be found in the data...

* I'm sure Hugh will be along soon to explain chapter and verse on where Definitive Mapping applies, and who is responsible for it...

12
New Techniques & Learning / Macronavigation
« on: March 13, 2013, 06:29:34 PM »
I seem to find that my navigational errors are usually at the macro, rather than the micro level.

For instance, I was walking in the Roybridge area last week, and we set off for Creag Pitrie.  We got to the car park, and I headed off along an obvious 'track'.  And stopped about 20m later and turned around.  Then we wandered along the road for about 200m, looking for the bridge we knew should cross the River Spean.  Then figured we were going the wrong way, starting from the wrong car park...

At this point, I decided I should probably look at the map, and figure out where I actually was, where I was actually going, and work out a plan to get there...

This is not the first such macronavigation incident; there's the infamous 'this is the wrong reservoir' (Blackwater vs Loch Eilde Mor) incident, where effects of previous night's celebrations, use of Harvey's map in urban environment, and the fact that we were all bimbling along chatting meant we didn't even look at a map until we got to the 'wrong reservoir'.  Still, it was interesting, with such high winds that waves were blowing over the top and we turned back rather than even think about walking across the dam.

Once on the mountain itself, navigation was brainless, as you follow a landrover/quad bike track all the way up to the col between Creag Pitrie and Geal Charn (my mountain-biking friends loved it).  At which point, micronavigation kicked in, combined with my usual terrain association/looking at the ground in front of me and deciding which way is the best up/down...  Despite snow cover, freezing fog/low cloud giving about 50m visibility and howling winds, we headed off from a vaguish-point on a vague-ish bearing, only to encounter an obvious path as we worked our way to the summit, leaving the path where it became icy, and re-finding it again on our way.

Then, having got to the summit cairn and decided to retreat immediately, since Liz was having to crawl on hands and knees to stop being blown over, we fought our way back over the summit ridge and back down, again, on a vague-ish bearing, following likely-looking terrain.  Only to encounter our outward footprints...

Now, if someone asked me how I'd done that, I wouldn't have a clue.  There's something going on in my brain that is able to find 'the path', despite poor visibility and foul conditions that made it impossible to look at map or GPS.  But I don't know what it is, or what terrain clues I use to do this.

So, the macronavigation lesson here is obvious; look at the map when you start, find out where you are, where you're going, and how to get there...

The micronavigation lesson?  I have no idea...

13
If you've ever wondered why a compass points North, and why it doesn't always, and why 'North' moves about, you might find the BBC Horizon programme 'The Core' quite interesting.

http://www.bbc.co.uk/programmes/b0148vph

It's all about the Earth's liquid metal core, and how it moves, and how that movement causes the Earth's magnetic field, and why that field moves about.

As with all modern 'Horizon' programmes, it's a little dumbed down, but not as much as others.

There are currently four days left to watch/download it from BBC iPlayer.

14
Apps / Galileo Offline Maps
« on: August 23, 2012, 06:45:31 PM »
Thought I'd put this suggestion where it belongs, in the 'Apps' forum'...

My WheresThePath colleague has suggested I look at this app for the iPad:

http://galileo-app.com/.

It supports the use of custom maps, made using Mobile Atlas Creator.

15
General navigational Kit / A slope-measuring tool
« on: July 11, 2012, 01:09:02 PM »
Having been reading up on 'formal navigation techniques', having started helping with DofE, I discovered the 'Keayscale' in Wally Keay's DofE Navigation book.  This has scales along the side of the tool that allow you to measure the gradient of a slope by comparing the contour spacing with fixed gaps.  The gap represents a number of contour lines.

As usual, this started me thinking about how I might do it better, and I thought I'd probably draw the contour lines within the gap, rather than simply write on how many lines there should be in the gap.

This then lead on to the thought of using a continuous scale, rather than discrete values.  A bit of simple trigonometry and some PostScript programming later, and I have a script to generate a slope-measuring tool for any map you can think of.  Here's an example (a rather low resolution version):



The tool should be printed onto a transparency, and used by sliding the tool across the amp at the area of interest until you find the point at which the tool and map contours are the same; then you read off the slope.

The script allows the user to enter the parameters for the map in question, and the tool:

map series title
map scale
map vertical contour spacing
map vertical scale factor (for non-metric maps)
map vertical contour units
number of contours between 'index' (thicker) contour
number of index 'series' to show on the tool
minimum slope angle
maximum slope angle
values to display on the axes
physical size of the tool

It will accept a whole series of these map definitions, and print them on a transparency.

Having done all this, and made a few tools, I'm not entirely sure that the tool is that necessary, as it doesn't really tell me anything about the slope than I can already tell just by looking at it.  But other people have made slope-measuring tools, and I thought I'd have a go...  Someone has suggested that a narrow-range tool could be used to identify avalanche-prone slopes.

I have a version which will show the additional 'along slope' distance, too, but, again, I'm not convinced that that's a useful technique; by the time the slope is steep enough to make a significant difference to the distance, the slope is steep enough to change my stride, and slow me down, which will have a much greater effect on pace-counting or timing than the small difference in distance...

I'm also not entirely convinced by the continuous curve, and may go back to a discrete, stepped curve, as it may be easier to use.

If anyone is vaguely interested, send me an email address, and I'll send the PostScript file.  Or, if you're not sure about handling PS, I'll send a PDF, but that loses the ability for the user to specify their map details. [discovers attachment option: PostScript attached]

Comments and suggestions are welcome.

Pages: [1] 2