Endeavour Drive - Drivability analysis Options

[djellison]

http://www.sciencefriday.com/program/archives/200809191

You can listen via NPR, or via one of the web feeds that are listed on the site, but make sure you do listen if you can.

[imipak]

Bundling up comments on several posts plus my own ramblings; apologies for the length.
It seems support is emerging for two approaches:
1. software automation

Pros:
• Can probably be made to work effectively;
• Spits out normalised data set covering as large an area as you like in two minutes flat. (To a first order of hand-waving anyway )
• Easily testable, reproducible, and improves over time as the author tweaks the algorithms

Cons:
• dev lead time. It may take some time before the first useful two-minute run!
• only a few people here have the code-fu to do it, a single-point-of-failure. FSM forbid James falls under the proverbial bus just before the first release in a month's time, but...
• lots of possible algorithms that could be combined in various ways, with various parameters and feedback loops, make it easy to try lots of variations and select the best.

2. A Mechanical Turk, human-driven distributed process. (several variants on this have been suggested.)

Pros:
• enables lots of people to contribute
• very quick and simple to kick off (a completely manual version could start in 10 minutes time.)
• the raw data could be straightforwardly fed into software (from 10 lines of Perl, to full-blown C++ GUI apps) for further processing and display in various styles.

Cons:
• indeterminate runtime. Might take weeks, or (pessimistic assumptions) five people, managing one grid square per week, works out to roughly 25 years! (OTOH,.. we could prioritise the closest areas of terrain - a bit like a chess algorithm, in fact, selecting and pruning a tree of possible future moves... )
• Once certain parameters are set (e.g., grid square size, the particular archetypal images are used for the classification cheat-sheet, etc) they can't be altered without junking whatever data set's accumulated to date.
• People make mistakes and/or differ in interpretations. (A training stage would take time to build.)

I suggest that we do both. There's no reason we couldn't start on a Mechanical Turk process whilst the bit-twiddlers do their thing; at some point (a week, two, ten,..) the software's results become more useful than the manual ones, and the baton is passed. A purely manual process could start whilst work is underway on a web-based, semi-automated, galaxy-zoo type solution, AND a dedicated program to do the whole thing.

I hate it when people say this in email at work, but as I've already used the word "solution"... ... "thoughts?"

Note for ships we normally find that the height of the waves is of less importance then their wavelength (compared to the ships length), I guess it is more or less similar for oppy: a low but steep ripple will give you far more trouble then a high but 'long' ripple.

Correct me if I'm wrong, but my impression is that all the dunes encountered on the way to Victoria had the same angle of repose, so the visible width has a linear relationship to cross-a-bility.

Stu - Rui! Isn't that a boat?! They've come to rescue us!
Me - Rescue...boat...us...(processing information...)...
My friend...Who are we, Mankind, but the rescue, the boat, the sea, the Onward?...

And then we would battle ourserlves to death with coconuts...

$wine{'cava'}->spray("nose");

So for the time being my problem still is "find the quickest and safest path to Endeavour".

Question: which part of Endeavour? I've been assuming your aim point is the jagged western rim peaks; is that right? Is there a definite aim point, or a defined area to aim at?

[jekbradbury]

There's no reason we couldn't start on a Mechanical Turk process

I've been working for the past two days on trying to get the JP2 into Python (Google App Engine) so help with installing the JasPer plugin for ImageMagick would be greatly appreciated. ImageMagick can automatically split an image into hundreds of named tiles, but it can't read JP2s without JasPer. And JasPer is only available as C source. The JP2 format is evidently quite a processing bottleneck.

Anyway, I can start development on the mechanical turkish front-end without the images (does http://helpoppy.appspot.com sound good?); I just don't want to be redundant, so if anyone else is attempting the same thing please speak up.

[SFJCody]

Anyway, I can start development on the mechanical turkish front-end without the images (does http://helpoppy.appspot.com sound good?); I just don't want to be redundant, so if anyone else is attempting the same thing please speak up.

Not me I'm afraid. I don't have the coding skills for that (and I've fallen at the first hurdle trying to find a good way of slicing up these jp2s).


Re: automation
The one issue I have with Fourier Fast transforms and other automated processes is that they may show different responses to ripple formations over bedrock compared to sand. Even if the ripples are morphologically similar, the increased contrast between the dark drifts and light bedrock will produce a stronger peak (albeit at the same wavelength).