From: Karl-Heinz Z. <kh...@kd...> - 2001-08-28 12:35:26
|
Hi, just managed to rock our youngest to sleep, which works best when turning on the Beach Boys: If everybody had an ocean Across the U.S.A. Then everybody'd be surfin' Like Californi-a. Back again at FlightGear I asked myself: Where does the water come from? Ok, having that great looking oceans in FlightGear *is* a pleasure and th= e people who developed them made a very good job but nevertheless it would be nice if we had a possibility of defining some rivers transporting the water into the oceans instead of 'only' having oceans. A perfect solutio= n would be having a river module that can read some user defined settings so anybody could add their favourite rivers, streams, brooks... We are living here in Foehren, Germany ( EDRT ) near the river Mosel and my oldest son would *love* to be able to fly through the Mosel valley. :-= ) So please tell me if and how I could help making this idea true: Who is currently working on rivers (or lakes, resp.) and what knowledge is neede= d for me being able to do something usefull on that tasks? Karl-Heinz --=20 Karl-Heinz Zimmer, Senior Software Engineer, Klar=E4lvdalens Datakonsult = AB <mailto:kh...@kl...> <mailto:kh...@kd...> BugCops *** Making Free Software Better *** http://bugcops.org |
From: David M. <da...@me...> - 2001-08-28 13:42:24
|
Karl-Heinz Zimmer <kh...@kd...> writes: > We are living here in Foehren, Germany ( EDRT ) near the river Mosel > and my oldest son would *love* to be able to fly through the Mosel > valley. :-= ) > So please tell me if and how I could help making this idea true: Who > is currently working on rivers (or lakes, resp.) and what knowledge is > needed for me being able to do something usefull on that tasks? There's a README.howto in the root of the TerraGear distro, and I think that someone else was working on a more up-to-date one. I wrote a DCW E00 HOWTO, but I don't think it was ever added to the distro, and I don't know where it is now. Basically, to get started, you have to start collecting GIS data. At a minimum, you'll want the following: 1. Airport database (default.apt.gz from the FlightGear base package, but before you start, remove the following problem airports: KAPN, NM99, KEDW, LFAL, RJFO, KNJM, and KNXP; I think that KEDW might actually be working now). To speed things up, make a new copy with only the airports in your area. 2. DEM30 data from <http://edcdaac.usgs.gov/gtopo30/gtopo30.html>. You'll need to download the w020n90 chunk for Germany. 3. The GSHHS coastline data from <http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html> (the intermediate resolution one may be good enough). You probably want to use the pregenerated polygons for the landmass; someone just posted a new URL to the TerraGear list, but I don't have it with me. You may optionally use the GSHHS stuff to generate lakes, islands, and ponds, or you can use DCW (which, in my opinion, is better for inland water, at least in North America). 4. Land-cover data from http://edcdaac.usgs.gov/glcc/tabgeo_globe.html (the correct file is named gusgs2_0ll.img). 5. Data for roads, railroads, rivers, cities, and towns/villages from http://www.maproom.psu.edu/dcw/ (you can preview the German data before you download). Once you have all that, you can try to hunt down that howto I told you about and build some German scenery. All the best, David -- David Megginson da...@me... |
From: William L. R. <wil...@ca...> - 2001-08-28 15:12:04
|
On Tuesday 28 August 2001 08:39 am, you wrote: > There's a README.howto in the root of the TerraGear distro, and I > think that someone else was working on a more up-to-date one. I wrote > a DCW E00 HOWTO, but I don't think it was ever added to the distro, > and I don't know where it is now. I wrote an updated HOWTO although it could use some polishing up. You can find it here in several formats (KWord, PDF, Postscript, ASCII), the filename is FlightGear_Scenery http://gwmostreetnet.kircpe.cableone.net/fgfs/scenery/ Regards, Wm -- William L. Riley ri...@te... |
From: David M. <da...@me...> - 2001-08-28 15:32:29
|
William L. Riley writes: > I wrote an updated HOWTO although it could use some polishing up. You can > find it here in several formats (KWord, PDF, Postscript, ASCII), the filename > is FlightGear_Scenery > http://gwmostreetnet.kircpe.cableone.net/fgfs/scenery/ OK, I've saved the message this time. Curt: could you add this link to the TerraGear Web page? All the best, David -- David Megginson da...@me... |
From: Cameron M. <li...@to...> - 2001-08-28 16:00:13
|
* da...@me... [2001.08.28 08:46]: > Karl-Heinz Zimmer <kh...@kd...> writes: > > > We are living here in Foehren, Germany ( EDRT ) near the river Mosel > > and my oldest son would *love* to be able to fly through the Mosel > > valley. :-= ) > > > So please tell me if and how I could help making this idea true: Who > > is currently working on rivers (or lakes, resp.) and what knowledge is > > needed for me being able to do something usefull on that tasks? > > There's a README.howto in the root of the TerraGear distro, and I > think that someone else was working on a more up-to-date one. I wrote > a DCW E00 HOWTO, but I don't think it was ever added to the distro, > and I don't know where it is now. BTW, where are you guys as far as incorporating land-use data into the official scenery? The screenshots I've seen from David (with the rivers and roads and such) look spectacular. Thanks -- Cameron Moore |
From: David M. <da...@me...> - 2001-08-28 16:25:39
|
Cameron Moore writes: > BTW, where are you guys as far as incorporating land-use data into the > official scenery? The screenshots I've seen from David (with the rivers > and roads and such) look spectacular. Thanks Land use is in the official scenery, and has been for a generation or two. Roads, rivers, and railroads are not, partly because of the difficulty of assembling the data, and mainly because of problems with the triangle library (it cannot deal with the long, narrow polygons gracefully). All the best, David -- David Megginson da...@me... |
From: Norman V. <nh...@ca...> - 2001-08-28 16:58:56
|
David Megginson writes: > >Land use is in the official scenery, and has been for a generation or >two. Roads, rivers, and railroads are not, partly because of the >difficulty of assembling the data, and mainly because of problems with >the triangle library (it cannot deal with the long, narrow polygons >gracefully). Or put another way Everything in the scenery is composed of polygons which are converted into triangles for OpenGL. Long skinny triangles lead to 'math' problems due to the 'tiny' angle at the pointy end. This causes a problem with both the polygon clipping and OpenGL rendering. The only way to avoid these problems is to make the polygons not so skinny. ie subdivide them, hence less skinny segments. The trick is to do this without overloading the polygon budget. or have have different LOD scenery tiles based on distance from the viewpoint. < but this is another story > Cheers Norman |
From: David M. <da...@me...> - 2001-08-28 17:09:39
|
Norman Vine writes: > Everything in the scenery is composed of polygons > which are converted into triangles for OpenGL. > > Long skinny triangles lead to 'math' problems due to > the 'tiny' angle at the pointy end. This causes a problem > with both the polygon clipping and OpenGL rendering. > > The only way to avoid these problems is to make the > polygons not so skinny. ie subdivide them, hence less > skinny segments. > > The trick is to do this without overloading the polygon budget. > or have have different LOD scenery tiles based on distance from > the viewpoint. < but this is another story > Actually, it should be doable just by using a relatively small minimum angle (i.e. 1.0 deg, or 0.1 deg). Unfortunately, that doesn't work with the current triangle library. Setting the minimum angle to anything other than 0 (even 0.00000001) enables extra quality checks that produce far too many triangles. Perhaps we could selectively disable some of those checks, somehow. All the best, David -- David Megginson da...@me... |
From: Norman V. <nh...@ca...> - 2001-08-28 17:29:40
|
David Megginson writes: > >Norman Vine writes: > > > > Long skinny triangles lead to 'math' problems due to > > the 'tiny' angle at the pointy end. This causes a problem > > with both the polygon clipping and OpenGL rendering. > > > > The only way to avoid these problems is to make the > > polygons not so skinny. ie subdivide them, hence less > > skinny segments. > > > > The trick is to do this without overloading the polygon budget. > > or have have different LOD scenery tiles based on distance from > > the viewpoint. < but this is another story > > >Actually, it should be doable just by using a relatively small minimum >angle (i.e. 1.0 deg, or 0.1 deg). Unfortunately, that doesn't work >with the current triangle library. Setting the minimum angle to >anything other than 0 (even 0.00000001) enables extra quality checks >that produce far too many triangles. Perhaps we could selectively >disable some of those checks, somehow. In the simple case roads etc there is no need to use the triangulator at all, eg the triangulation is given apriori !! Just walk the road and create the triangles from the vertices. The triangulator is only needed for point clouds and polygons more complicated then rectangles :-)) Cheers Norman |
From: David M. <da...@me...> - 2001-08-28 17:41:27
|
Norman Vine writes: > Just walk the road and create the triangles from the vertices. That would work in a 2D world, but not in a 3D one. TerraGear adds nodes from the DEM before building triangles; otherwise, roads would not follow the slope of the terrain. All the best, David -- David Megginson da...@me... |
From: Norman V. <nh...@ca...> - 2001-08-28 19:42:54
|
David Megginson writes: > >Norman Vine writes: > > > Just walk the road and create the triangles from the vertices. > >That would work in a 2D world, but not in a 3D one. TerraGear adds >nodes from the DEM before building triangles; otherwise, roads would >not follow the slope of the terrain. Nope this works, as long as you don''t care about having elevation points in the middle of the road. Remember the scenery construction tools are not true 3D but only 2.5D at tile construction time. ie the triangulator you are using is a 2D tool !!! Turning the points into 3D doesn't happen till after everything is constructed in 2D first, the 2.5D just means that we carry along the elevations roughly here is how I would go about it 1) roads are turned into polygons. 2) for each node in the road polygons determine the elevation same as is done for airport nodes 3) clip all normal LOD elevation nodes from the interior of the road polygons. 4) clip road polygons against the land use data 5) create tri strips of the road polygons 6) rest of normal scenery process Easy part of the problem solved now we just need to write the code :-) Cheers Norman |
From: Curtis L. O. <cu...@fl...> - 2001-08-31 22:00:59
|
Norman Vine writes: > David Megginson writes: > > > >Norman Vine writes: > > > > > Just walk the road and create the triangles from the vertices. > > > >That would work in a 2D world, but not in a 3D one. TerraGear adds > >nodes from the DEM before building triangles; otherwise, roads would > >not follow the slope of the terrain. > > Nope this works, as long as you don''t care about having > elevation points in the middle of the road. We could avoid this by cutting holes out of the terrain where the roads go and pasting them in as separate objects. Regards, Curt. -- Curtis Olson Human Factors Research Lab FlightGear Project Twin Cities cu...@hf... cu...@fl... Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org |
From: David M. <da...@me...> - 2001-08-28 21:00:58
|
Norman Vine writes: > Remember the scenery construction tools are not true 3D but only > 2.5D at tile construction time. ie the triangulator you are using is > a 2D tool !!! Yes, I know -- we simply add the DEM points as extra vertices. > 1) roads are turned into polygons. Do you mean external objects? Fair enough, but there will be lots and lots and lots of them -- perhaps as many as several hundred objects in each tile. > 2) for each node in the road polygons determine the elevation > same as is done for airport nodes Since roads are much longer than runways, they'll have to be segmented fairly frequently, especially for US scenery using the DEM-3 data. Even a 1km segment of straight road might go up and down a couple of hills, and some segments can be 10 or 20km or more. Knowing something about the underlying DEM might help > 3) clip all normal LOD elevation nodes from the interior of > the road polygons. That won't matter anyway. Like airports, roads (etc.) would have to be saved as separate objects, with holes passed to the regular polygon clipping routines. The holes shouldn't get any LOD nodes in the first place. > 4) clip road polygons against the land use data As with the airports, the other polygons would be clipped against the holes left for the roads, while the roads would be loaded from separate files. > 5) create tri strips of the road polygons This would be done earlier, during the prep stage (as with airports), and the objects would simply be copied during the scenery-generation stage. > 6) rest of normal scenery process > > Easy part of the problem solved > now we just need to write the code :-) Thanks for volunteering. The nice part of this approach would be the ability to use aligned textures for roads and railroads (i.e. pavement with a yellow line in the middle and gravel shoulders rather than just grey rectangles). I don't think I want to write the code, though. All the best, David -- David Megginson da...@me... |
From: Norman V. <nh...@ca...> - 2001-08-28 21:30:45
|
David Megginson writes: > >Norman Vine writes: > > > 1) roads are turned into polygons. > >Do you mean external objects? Fair enough, but there will be lots and >lots and lots of them -- perhaps as many as several hundred objects in >each tile. I envision roads are turned into the equivalant of another landuse polygon and the landuse polygons are then clipped to accomadate this ! > > 2) for each node in the road polygons determine the elevation > > same as is done for airport nodes > >Since roads are much longer than runways, they'll have to be segmented >fairly frequently, especially for US scenery using the DEM-3 data. >Even a 1km segment of straight road might go up and down a couple of >hills, and some segments can be 10 or 20km or more. Knowing something >about the underlying DEM might help I guess I am assuming that we already have the dem triangulated then the 'interesting points' < places we want nodes in the road > are the intersections of the road polygon and the edges of the triangulation. We already do something similar for rivers > > 3) clip all normal LOD elevation nodes from the interior of > > the road polygons. > >That won't matter anyway. Like airports, roads (etc.) would have to >be saved as separate objects, with holes passed to the regular polygon >clipping routines. The holes shouldn't get any LOD nodes in the first >place. I don't think they need to be separate objects though this is something that should be disscussed I guess we should continue this discussion when Curt is back on line Cheers Norman |
From: Karl-Heinz Z. <kh...@kd...> - 2001-08-29 12:58:38
|
On Tuesday 28 August 2001 11:32 pm, Norman Vine wrote: > David Megginson writes: =2E. > > Since roads are much longer than runways, they'll have to be segmente= d > > fairly frequently, especially for US scenery using the DEM-3 data. > > Even a 1km segment of straight road might go up and down a couple of > > hills, and some segments can be 10 or 20km or more. Knowing somethin= g > > about the underlying DEM might help > I guess I am assuming that we already have the dem triangulated > then the 'interesting points' < places we want nodes in the road > > are the intersections of the road polygon and the edges of the > triangulation. We already do something similar for rivers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So does that mean there *is* special code for rivers in FlightGear? I thought I was going to implement them on a 'just paint them in the scenery' basis by following the detailed advice I got in the yesterday postings... But if there is special code for rivers perhaps this idea is not perfect and I should rather try to enhance the rivers in another way? Or am I getting thinks the wrong way around? Ciao, Karl-Heinz PS: In case you wonder _why_ I am asking in such a complicated way: The tasks described to add rivers and lakes to the scenery data made to me the impression of being quite time consuming, so I would like to be sure it is the right thing that I am going to do *before* I start.= :) --=20 Karl-Heinz Zimmer, Senior Software Engineer, Klar=E4lvdalens Datakonsult = AB <mailto:kh...@kl...> <mailto:kh...@kd...> BugCops *** Making Free Software Better *** http://bugcops.org |
From: Norman V. <nh...@ca...> - 2001-08-29 14:35:50
|
Karl-Heinz Zimmer writes: > >On Tuesday 28 August 2001 11:32 pm, Norman Vine wrote: >.. >> I guess I am assuming that we already have the dem triangulated >> then the 'interesting points' < places we want nodes in the road > >> are the intersections of the road polygon and the edges of the >> triangulation. We already do something similar for rivers > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >So does that mean there *is* special code for rivers in FlightGear? I was refering to the code in TerraGear that keeps water bodies 'flat' But I can't seem to find the exact spot right now. This is not necessarily what you want to do though < see below > >I thought I was going to implement them on a 'just paint them in the >scenery' basis by following the detailed advice I got in the >yesterday postings... > >But if there is special code for rivers perhaps this idea is not perfect >and I should rather try to enhance the rivers in another way? I believe the best way to enhance the rivers is to edit the GSHHS coastline data directly i.e. splice extended river data into the appropriate spot. We also need to pull the lake data out of the gshhs and replace it with something better but that is another story FYI The gshhs data stops at the first lock, dam, unpassable bridge ect in that it was originally built for the US Navy and that was all they were interested in. The neat thing about editing the GSHHS data is that the normal scenery tools should JUST WORK as is on the updated data. :-)) The only thing making this operation difficult is the size of the data set. This kind of functionality should be built into the 'mythical' scenery editor. FWIW The library I want to build this on is firming up nicely and I expect to start on integrating the FlightGear data structures into it shortly http://www.ossim.org But any vector editing package could be used on the gshhs data All that is needed are translators to and from the package's native format. Please ask away if you have further questions as IMHO gettting 'enhanced' rivers into the base scenery package is a priority item Cheers Norman Vine |
From: Karl-Heinz Z. <kh...@kd...> - 2001-08-29 14:58:28
|
On Wednesday 29 August 2001 04:36 pm, Norman Vine wrote: =2E. > But any vector editing package could be used on the gshhs data > All that is needed are translators to and from the package's native > format. > Please ask away if you have further questions as IMHO gettting > 'enhanced' rivers into the base scenery package is a priority item Yes, I got some questions: * When editing these scenery data we will end by having nice sceneries containing *static* information on rivers and lakes, right? * So there will be no moving water, no ships on the rivers...? * Just some hopefuly nice looking patterns showing that there is water? Ok, I am not critizising (who am I to critizise the creators of the great FlightGear) but want to be sure whether the graphical representation of the water will be static. Coming home by train from Trier this afternoon I crossed the river Mosel and thought it would be great to have ships on the rivers: lots of differ= ent types of ships following different courses at different speed... to make this work, there should be a way how to indicate that a certain part of the river (or lake) can be used by ships of category x, while another part only by small boats of category y and yet another part of the river perhaps might never show ships on them... dozends of ideas and plans - but will this be possible using normal scenery data? Ok, never mind, even if this is not (yet) possible it still will be nice to just see the water down there - no matter if static or dynamic! :-) Ciao Karl-Heinz --=20 Karl-Heinz Zimmer, Senior Software Engineer, Klar=E4lvdalens Datakonsult = AB <mailto:kh...@kl...> <mailto:kh...@kd...> BugCops *** Making Free Software Better *** http://bugcops.org |
From: Norman V. <nh...@ca...> - 2001-08-29 15:20:26
|
Karl-Heinz Zimmer writes: > >On Wednesday 29 August 2001 04:36 pm, Norman Vine wrote: >.. >> But any vector editing package could be used on the gshhs data >> All that is needed are translators to and from the package's native >> format. > >> Please ask away if you have further questions as IMHO gettting >> 'enhanced' rivers into the base scenery package is a priority item > >Yes, I got some questions: :-) >* When editing these scenery data we will end by having nice sceneries > containing *static* information on rivers and lakes, right? yes >* So there will be no moving water, no ships on the rivers...? No moving water - yet :-) You can add ships though >* Just some hopefuly nice looking patterns showing that there is water? The water will be the same texture as the ocean >Coming home by train from Trier this afternoon I crossed the river Mosel >and thought it would be great to have ships on the rivers: lots of different >types of ships following different courses at different speed... to make >this work, there should be a way how to indicate that a certain part of >the river (or lake) can be used by ships of category x, while another >part only by small boats of category y and yet another part of the river >perhaps might never show ships on them... dozends of ideas and plans >- but will this be possible using normal scenery data? Getting depth information into the water areas is doable. But this is a FLight Simulator, although I must confess that I am more interested in using it as a general purpose tool, as I am sure others on this list can testify to. Note To implement the river depths we will need bathymetric data something that is not necessarily easy to come by for all parts of the world. Once we had the bathymetry modeled much as we do the terrain then the depth of a location could be determined the 'same' way as we determine the elevations and then ships could run 'aground' hence limiting them to passage only in 'deep enough' water. Hey I am almost describing one of my FGFS mods :-)) Cheers Norman |
From: David M. <da...@me...> - 2001-08-29 15:37:37
|
Norman Vine writes: > But this is a FLight Simulator, although I must confess that > I am more interested in using it as a general purpose tool, > as I am sure others on this list can testify to. In theory, SimGear is a world simulator, and FlightGear is a program that uses the world simulator for flight. The two are not all that well separated yet, but once they are, I see nothing against using SimGear for nautical simulations as well. All the best, David -- David Megginson da...@me... |
From: Gene B. <ge...@de...> - 2001-08-29 15:42:09
|
> > But this is a FLight Simulator, although I must confess that > > I am more interested in using it as a general purpose tool, > > as I am sure others on this list can testify to. > > In theory, SimGear is a world simulator, and FlightGear is a program > that uses the world simulator for flight. The two are not all that > well separated yet, but once they are, I see nothing against using > SimGear for nautical simulations as well. > My thought was to utilize SimGear as the rendering front end for a simulator called Fly8. It's just a simple vector graphic air combat sim (guns only), but it's a lot of fun. g. |
From: David M. <da...@me...> - 2001-08-29 15:58:09
|
Gene Buckle writes: > My thought was to utilize SimGear as the rendering front end for a > simulator called Fly8. It's just a simple vector graphic air combat sim > (guns only), but it's a lot of fun. Obviously, you could use FlightGear for that, but it will be *very* useful to have a second app using SimGear, to help us smoke out what should be in SimGear and what should stay in FlightGear. All the best, David -- David Megginson da...@me... |
From: Gene B. <ge...@de...> - 2001-08-29 16:20:43
|
> > My thought was to utilize SimGear as the rendering front end for a > > simulator called Fly8. It's just a simple vector graphic air combat sim > > (guns only), but it's a lot of fun. > > Obviously, you could use FlightGear for that, but it will be *very* > useful to have a second app using SimGear, to help us smoke out what > should be in SimGear and what should stay in FlightGear. > FlightGear could do that, but since I can't program (in C++) my way out of a wet paper bag, it would be easier just to leverage what's already been done. Granted, the flight model in Fly8 sucks rocks, but it does the job. It's one of the things on the list to do for my simulator project. I figure I can set Fly8 up as a console only server process that just kicks out data about the current aircraft to set the view and then another data stream to supply the positions of the drone aircraft. Of course it would have to be a two way pipe so SimGear could pass back altitude data to Fly8 for ground impact or landings. BTW, if anyone knows where I can find a 7" color VGA monitor, please let me know. I need one for the MPCD display in the '15. g. |
From: Curtis L. O. <cu...@fl...> - 2001-08-31 17:41:15
|
Gene Buckle writes: > BTW, if anyone knows where I can find a 7" color VGA monitor, please let > me know. I need one for the MPCD display in the '15. You might have better luck these days finding an appropriately sized LCD panel? Curt. -- Curtis Olson Human Factors Research Lab FlightGear Project Twin Cities cu...@hf... cu...@fl... Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org |
From: Norman V. <nh...@ca...> - 2001-08-29 16:11:39
|
David Megginson >Norman Vine writes: > > > But this is a FLight Simulator, although I must confess that > > I am more interested in using it as a general purpose tool, > > as I am sure others on this list can testify to. > >In theory, SimGear is a world simulator, and FlightGear is a program >that uses the world simulator for flight. The two are not all that >well separated yet, but once they are, I see nothing against using >SimGear for nautical simulations as well. Yep, Curt broke them apart with people like me in mind :-)) One of these days we should probably go back to that job and get the scenery stuff out of FlightGear and into SimGear where it 'really' belongs :-) Cheers Norman |
From: David M. <da...@me...> - 2001-08-29 15:35:18
|
Karl-Heinz Zimmer writes: > * When editing these scenery data we will end by having nice sceneries > containing *static* information on rivers and lakes, right? Right. > * So there will be no moving water, no ships on the rivers...? No. I suppose we could jiggle the texture back and forth a bit, but it would probably just look stupid. > * Just some hopefuly nice looking patterns showing that there is water? Yes. For the larger rivers, you'll have an irregular polygon filled with a water texture; for the smaller rivers, you'll have what looks like a 50m-wide road (or whatever you choose) filled with a water texture. Make sure you check out the latest TerraGear from CVS before starting. > Coming home by train from Trier this afternoon I crossed the river Mosel > and thought it would be great to have ships on the rivers: lots of different > types of ships following different courses at different speed... to make > this work, there should be a way how to indicate that a certain part of > the river (or lake) can be used by ships of category x, while another > part only by small boats of category y and yet another part of the river > perhaps might never show ships on them... dozends of ideas and plans > - but will this be possible using normal scenery data? Not yet. You can place objects in the scenery statically if you have 3D models for boats (even that's not simple), but you cannot make them move. We'll probably work on adding other moving planes first, before we worry about boats, trains, or cars (though the Python interpreter might make that easier). That said, if you want to work on this area, go for it! > Ok, never mind, even if this is not (yet) possible it still will be nice > to just see the water down there - no matter if static or dynamic! :-) Yes, it makes an enormous difference for VFR flight. All the best, David -- David Megginson da...@me... |