Re: Funding by DOD for TerraGear related challenge

Alex Perry wrote:
> Ok, I interpreted it in a very specific way.

I believe you, and most of what you are saying makes sense after going back 
and reading their request, but still ...

When they say topographic features, I don't see anything that even slightly 
implies satellite or photo imagery ... although that would make perfect 
sense if they had.

> Everything starts with a nice photo (aka texture map, aka colorization
> on a lat-long grid) and contour lines (aka elevation map, polygons, etc).

Ok ...

> The current method consists of painstaking aligning these until the result
> looks reasonable, which is really hard to do.  TerraGear PhotoScenery is
> a classic example of why this is hard.  They've noticed it's hard too.
> 
> They're proposing that the other way around is to find topographic features
> that occur in both the photo and in the elevation map and register them.
> Therefore, anything where the pilot could _tell_ that there is a mismatch
> between photo and contour is automatically tweaked to get them aligned.
> This looks at a ridgeline, the coast, the edge of a runway or whatever.

Assuming topographic features == photo imagery, ok.  But they seem to be 
talking more about the elevations of known topographic features.  To me 
that would mean the elevation of a peak, the elevation of an airport, or 
anything else of interest that has been accurately surveyed.  But if they 
just want to correct the terrain so it matches at the known points, I've 
got a good algorithm for them.

Why do they say that the ideal algorithm would do this at run-time though?

Why do they assert that this will significantly reduce database development 
time?  Maybe they have seen some really stupid approaches?  But it still 
leaves me uncomfortable that either they have something entirely different 
in mind, or else I'm just not the guy with the proper subset of knowledge 
for thier project.

If they are talking about shifting/stretching/rotating a photo 
automatically to fit terrain, or go the other way and tweak the terrain 
elevations to match a photo, that's fine, but they never mention photo 
anything as far as I can tell.

I suppose you just have to make your best interpretation, write a proposal 
and see what happens.  If someone does want to push forward with this, is 
there a contact who could clarify some of the ambiguities or their actual 
underlying intentions?  Or do we just have to go from the published request 
to keep the playing field "level?"

These things are often full of "code" as I'm sure you know.  And you 
obviously are better at cracking the secret code than I am. :-)

> I thought that some of the TerraGear people could have a real shot at this,
> notwithstanding the deadline, because we've got all the infrastructure for
> doing the other parts of the processing - including the "current method".
> If they succeed in getting funded, it could revolutionize FGFS's scenery.

Perhaps we can get a better idea of what they are after by looking at their 
list of references rather than what they actually say in their request? 
 From that it sounds like they want someone to do CLOD/ROAM type stuff on a 
global scale?

Or perhaps look at their dual use commercialization suggested applications. 
  But there they are talking about a variety of things that may or may not 
be well served by a single approach.  Stealth UAV navigation planning would 
probably be best served by a high resolution and high accuracy database. 
But the computation and path finding could all be done off line with the 
visualization aspect needing much less accuracy and could be done more as 
an after thought.

> Did that make sense ?

Yes, what you say makes great sense, but I'm still having trouble 
"correlating" it to their request.  I probably just need to deform 
something in my brain, because it's not currently fitting very well. :-)

> 
> Another point they seem to be making is that specific features have known
> altitudes that are much more accurate than those in the contour line maps.
> Towers, runways, mountain peaks, lakes and the like have precision data
> which is readily available in public databases and should be incorporated.

To me, that seemed like their primary point????

For construction project visualization you probably would want to do a very 
accurate survey of a smallish area (maybe with a LIDAR fly over?)  But then 
  you would just use that new data rather than using it to fix/deform some 
existing less accurate database.

I don't know, I think this all sounds too vague for me to want to bite. 
But maybe someone else on the terra-gear list would be interested, or know 
of someone who's interested.

> PS.  I'd use TG to prototype non-realtime algorithms in Phase I.

I think we could definitely use terragear to prototype a good solution to 
their problem, but I'm still scratching my head wondering why they assert 
that a run-time solution is superior and more cost effective.

And especially if they are interested in deforming a height field to match 
features on a photo (as you suggest) ... that doesn't sound like a real 
time process to me.

Alex, when you say revolutionize the FG terrain, what are you envisioning 
that we would be revolutionized to?  Are you thinking along the lines of 
large scale photo scenery?  Something else?  No matter how good our 
algorithms, we are ultimately limited by the quality and type of data we 
have access to (assuming the most accurate representation possible of the 
real world is the primary goal here.)

Regards,

Curt.
-- 
Curtis Olson   Intelligent Vehicles Lab         FlightGear Project
Twin Cities    [email protected]                  [email protected]
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org