Frederic Bouvier writes: > I am playing with SRTM-1 too. I started terrafit with --error=2 and > --maxnodes=2000 ( after the patch to terrafit.py ) and I must say > it is very impressive to see in action. > > But I found glitches that are quite obvious, and that do not appear > in the scenery made by Alex Romosan ( certainly with default options, > before the patch ) : it seems that the buildings are buried in the > terrain, with small pikes. > > Very visible in downtown SF, between the buildings : > http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sf-1arcsec.jpg > but also visible in Oakland. > > In this one, > http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-ksfo-1arcsec.jpg > the maintenance hangar created a hill around it. San Bruno mountains > are quite impressive though.
I think what you are seeing is the down side to fully automated data scaning/remote sensing. As I understand it (which I don't) as the shuttle orbited the earth, it beamed a radar signal down to the earth and then recorded the interference patterns in the signal reflection, then did some sort of fancy math to figure out actual terrain elevation (plus lots of other crazy stuff to compensate for sensor error.) It could cover a swath of about 250 miles if I recall correctly. They picked an orbit height that gave them the right coverage for the beam width + a little overlap. This orbit also gave them the right spacing between each path. The math worked out rather perfectly which is one of the reasons they flew this mission in the first place. But when you do this over a city or over building, you can't necessarily expect to get back the elevation of what the ground would have been if the buildings weren't there. Even over forests you can get a primary reflection off the top of the trees, a secondary reflection off the underlaying scrub, and maybe a third very faint reflection off the ground. I've seen data sets that were nice and smooth over grassy areas, but got all bumpy and rough over treed areas. If you want to calculate flood coverage for instance, you don't really care about the tops of the trees, you really want the ground level. For us too, we would have liked to have had the elevation of the surface of the ground, but we can't expect that is what we always get. Especially since SRTM was fully automated collection and post processing system. Other people might actually want the top of the folliage (in MN for instance you could perhaps use this to calculate which portions of road get sunlight in the winter and for how long. Excessively shaded portions of the roadway might build up icey spots so this could give you (in advance) a list of potential problem areas to concetrate extra salt/sand/chemicals. You will also see other areas around KSFO where there are hills / spikes that shouldn't be there. If you want to try to automatically smooth the data, you then sacrifice quality (kind of like bluring a picture.) We might need to have the ability to go in and hand edit data but if we do that we will probably toss accuracy out the window -- maybe -- unless someone has a higher standard they can reference against. It's a *hard* problem ... but I don't want to be the one to go tell NASA/NIMA their data sucks :-) because it's the best thing going right now by a long shot. Maybe the data would have come out better if the astronauts hadn't emailed it back to earth as executable attachments using MS Outlook. Ok, cough, sorry, I should not have included this last paragraph. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
