Hi Dave (and anyone else interested in this),

There's one other request I'd make of TaxiDraw at this point.  Is it
possible to revisit fetch.cpp, the routines that fetch background
images from terraserver-usa.com, and tweak it to enable fetching of
better images when terraserver-usa has them available (which, for
large city airports, is almost always)?

Here's the problem I'm running into.  I brought up the raw data for
KSDF, an airport with which I'm very familiar, and sent TaxiDraw off
to get a background image from terraserver-usa.  It returned with an
image that's at least eight years old, with an incorrect number of
runways, wrong apron location and runway/taxiway layout and so forth.

http://www.speakeasy.net/~cmetzler/KSDF_t1fetch.jpg

It's not merely a misalignment problem -- our data for 11/29 is
aligned correctly with the image, but the two 17/35 runways aren't
present in the image at all.  It's an old image, predating a lot
of changes and improvement, and it's no surprise that the runway
and taxiway layouts are way off.

So I went off to terraserver-usa's website and clicked through
Advanced Find --> Place --> "Louisville, KY, USA".  I then find that
they have a direct link to aerial images of the airport, from two
separate datasets.  One, a dataset labelled "Aerial Photo 6/6/1996",
is clearly where TaxiDraw got its info.  But another dataset present,
labelled "Urban Areas 4/7/2002", is not only more current but goes
down to much higher resolution.

I picked a point feature at the airport, zoomed down to the same
resolution using each of the two datasets, and looked at the URLs
for the two images I got.  I found that they were exactly the same
except for "t1" in the old image, and "t4" in the newer image.
Looking in fetch.cpp, I see this:

}    string urlroot = "\"http://terraserver-usa.com/tile.ashx?";;
}        string scale = "S=10";
}        string scale2 = "S10";
}        string type = "T=1";    // Not actually sure what this is - type is a guess
}        string amper = "&";

I don't know C++ at all, but on a hunch I changed that to "T=4",
and bingo:  TaxiDraw fetched and built an image from the newer
dataset.

http://www.speakeasy.org/~cmetzler/KSDF_t4fetch.jpg

I suspect that the "T" in the image URLs refers to dataset.  And
what I'm wondering is whether fetch.cpp can do a test to see if
"T=4" data is present and use it if so, or drop to "T=1" data and
use that if not.

The URL change seems to be stable.  Here's what I got for KDTW,
with "T=1" -- it fetched old data, missing an entire runway as
well as a ton of apron/taxiway that's now present:

http://www.speakeasy.org/~cmetzler/KDTW_t1fetch.jpg

hacking fetch.cpp to "T=4" fetched a newer image, showing the
new runway, its taxiways, the completed new terminal and its apron,
and so on.

http://www.speakeasy.org/~cmetzler/KDTW_t4fetch.jpg

The "Urban Areas"/"T=4" dataset is fabulous, btw -- it goes down to
25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears).
I'd recommend just changing fetch.cpp to "T=4", and getting the highest
resolution images available; but not all areas are covered by the
better dataset.  That's why I'm recommending tests -- try to fetch from
the higher resolution dataset, and drop down to the lower-res one if
the first fetch fails.

Would it be possible to implement something like this?  The
complicated airports are much easier to handle with more current,
higher-resolution imaging; and since the complicated airports tend
to be in/near big cities, those are just the ones for which the
better images will likely be available.

Anyway, just an idea . . .

-c

-- 
Chris Metzler                   [EMAIL PROTECTED]
                (remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear

Attachment: pgpkc6uxJEYSc.pgp
Description: PGP signature

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to