Re: [Flightgear-devel] Recent YASim problems...
On Thu, 19 Jul 2007 02:28:35 +0200 Georg Vollnhals <[EMAIL PROTECTED]> wrote: > Syd&Sandy schrieb: > > Me again . > > Ive been trying to get Bravo more up to date recently , and decided to > > check on the CitationX and Citation-II , and neither one will load anymore > > ... So far it's baffling me , because the Citation-II FDM is almost > > identical to the Bravo , just lighter and with less powerful engines , and > > the command line yasim utility reports "Drag factor beyond reasonable > > bounds" after 5 or 6 iterations... It could be something simple thats > > staring me in the face so has anyone else had problems loading either > > aircraft recently ? > > Thanks > > > Citation X and II are working fine here (OSG CVS, compilation 4 days > old, CVS data from today). > > Georg EDDW > > BTW, not your question: Citation II: retracted gear stucks through upper > wing Thanks Georg , I'll try removing them and re installing ... -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent YASim problems...
Syd&Sandy schrieb: > Me again . > Ive been trying to get Bravo more up to date recently , and decided to check > on the CitationX and Citation-II , and neither one will load anymore ... So > far it's baffling me , because the Citation-II FDM is almost identical to the > Bravo , just lighter and with less powerful engines , and the command line > yasim utility reports "Drag factor beyond reasonable bounds" after 5 or 6 > iterations... It could be something simple thats staring me in the face > so has anyone else had problems loading either aircraft recently ? > Thanks > Citation X and II are working fine here (OSG CVS, compilation 4 days old, CVS data from today). Georg EDDW BTW, not your question: Citation II: retracted gear stucks through upper wing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Recent YASim problems...
Me again . Ive been trying to get Bravo more up to date recently , and decided to check on the CitationX and Citation-II , and neither one will load anymore ... So far it's baffling me , because the Citation-II FDM is almost identical to the Bravo , just lighter and with less powerful engines , and the command line yasim utility reports "Drag factor beyond reasonable bounds" after 5 or 6 iterations... It could be something simple thats staring me in the face so has anyone else had problems loading either aircraft recently ? Thanks -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] README document
Thanks for the input guys , sounds like a definite NO to me :) whew ! Stuart , I used Open Office to combined all the files into one then exported it as PDF ... so it definately would be work to keep up to date but it really was just a project to minimize the amount of applications I have running at one time . but I was asked on IRC to do a Blender tutorial for modelling aircraft , maybe I'll direct my efforts there when I get tired of updating , though I'm terrible at teaching :) Cheers Syd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] SimGear segfault fix on OSG image load failure
Hans Ulrich Niedermann wrote: > The segfault is triggered when OSG connot find a plugin which can load > the image, such as because of a wrong or unset OSG_LIBRARY_PATH > environment variable. > > In that case, res.getImage() is NULL and dereferencing NULL gives the > segfault. BTW... fgfs will still segfault - but at least one gets to see an error message which gives a hint as to what the problem is. signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] README document
Am Mittwoch 18 Juli 2007 21:56 schrieb AnMaster: > I'm strongly against using PDF, loading a pdf viewer takes much longer time > and it is harder to edit *.pdf than text files. At least I got no program > to edit *.pdf Same here. Automatically creating PDF as an alternative nicer representation is OK. Using it as the raw data format is a no go... Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] README document
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm strongly against using PDF, loading a pdf viewer takes much longer time and it is harder to edit *.pdf than text files. At least I got no program to edit *.pdf Regards AnMaster Syd&Sandy wrote: > Hi all , > I've been consolidating all the README.xxx files in the Docs folder > into a single PDF file, because I prefer to be able to open ONE file and > search for what I need , and I like the word search and thumbnail views... I > haven't updated or changed any information , at the moment just transfering > them into aa single document. This was for my personal use , but thought I'd > ask if this is something that could be added to the Docs folder... there > appears to be a fair amount of information already in Docs, so it probably > isn't neccesary, but I generally don't read them because the organization and > layout is sometimes hard to follow or understand . I dont want to read a > through a lot of info to get to the section I want , so I decided this little > project would force me go through it all... > If anyone thinks this should be added , I'll do my best to keep it updated , > but would like input from others on what needs updating , what is obsolete , > etc... as long as doesn't interfere too much with my aircraft updating ;) . > Cheers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGnnBeWmK6ng/aMNkRCkkxAKCxtmgjd86Y4bh2i66iWIvT+prLHACgnMDa fjKIRcP0NG6/duRR4342eR8= =ybVM -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] README document
--- Curtis Olson wrote: > Be aware that the master copies of all the README.xxx files come from > the > source tree, not the data tree. They are only replicated in the data > tree > for convenience. > > Here's my view. The README.xxx are there to collect tidbits of > information > not documented elsewhere or that didn't really fit elsewhere or that > wasn't > really formally written up in an official way. If someone were to > update > and move all the information from a README.xxx file over to the official > manual, then I wouldn't have a problem with that particular README.xxx > file > going away. > > I personally would not be in favor of just dumping them all as they > exist > into a single large file. I like the division and the easy ability to > edit/update them. But at some point, if something is deamed important > enough to go into the official manual, then that's great, let's do it. Personally, I'd prefer not to put too much developer-level content into The FlightGear Manual (TFM). It's already pretty huge, and is really aimed at newbie users. Hence its original title - The Gettings Started Guide. I think most of README files are more aimed at power users, aircraft developers and coders. I know that the original authors of TFM envisaged a second manual aimed at aircraft developers and coders. It sounds like this would be a good first step towards this. However, there are one or two hurdles I can see:- - The README files are currently very easy for developers to edit and update. I doubt people will be as keen to keep them up to date if they are Latex files, especially if they need to learn a whole new set of escape characters! - We currently have a separate CVS Module for documentation, and developers are even less likely to update a .tex file in another CVS location, which may require a different reviewer/committer. Given that the README files have fairly straightforward layout, one way around this might be to have a script that grabs all the files for the src module, converts them to .tex and then generates a PDF file. Syd - you've already been through this process, do you reckon this could be scripted into something worthwhile, or was it a pretty manual process? -Stuart ___ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick conf help
> > > Hmm, I'm toying with an idea to use one of these converters to make a > throttle quadrant... Either of you using them under Linux? > > Ron > > If a gameport to usb-converter is meant with this, I am using the Rockfire converter with my pedals together with an usb-joystick/throttle. No problem with OpenSUSE (10.1 - 10.2), works great. Georg EDDW - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick conf help
Ron Jensen wrote: > Hmm, I'm toying with an idea to use one of these converters to make a > throttle quadrant... Either of you using them under Linux? Yes - and for exactly that. I'll be using one for a throttle quadrant, and one for rudder pedals. Jon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] README document
Be aware that the master copies of all the README.xxx files come from the source tree, not the data tree. They are only replicated in the data tree for convenience. Here's my view. The README.xxx are there to collect tidbits of information not documented elsewhere or that didn't really fit elsewhere or that wasn't really formally written up in an official way. If someone were to update and move all the information from a README.xxx file over to the official manual, then I wouldn't have a problem with that particular README.xxx file going away. I personally would not be in favor of just dumping them all as they exist into a single large file. I like the division and the easy ability to edit/update them. But at some point, if something is deamed important enough to go into the official manual, then that's great, let's do it. Regards, Curt. On 7/18/07, Syd&Sandy <[EMAIL PROTECTED]> wrote: Hi all , I've been consolidating all the README.xxx files in the Docs folder into a single PDF file, because I prefer to be able to open ONE file and search for what I need , and I like the word search and thumbnail views... I haven't updated or changed any information , at the moment just transfering them into aa single document. This was for my personal use , but thought I'd ask if this is something that could be added to the Docs folder... there appears to be a fair amount of information already in Docs, so it probably isn't neccesary, but I generally don't read them because the organization and layout is sometimes hard to follow or understand . I dont want to read a through a lot of info to get to the section I want , so I decided this little project would force me go through it all... If anyone thinks this should be added , I'll do my best to keep it updated , but would like input from others on what needs updating , what is obsolete , etc... as long as doesn't interfere too much with my aircraft updating ;) . Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] README document
Hi all , I've been consolidating all the README.xxx files in the Docs folder into a single PDF file, because I prefer to be able to open ONE file and search for what I need , and I like the word search and thumbnail views... I haven't updated or changed any information , at the moment just transfering them into aa single document. This was for my personal use , but thought I'd ask if this is something that could be added to the Docs folder... there appears to be a fair amount of information already in Docs, so it probably isn't neccesary, but I generally don't read them because the organization and layout is sometimes hard to follow or understand . I dont want to read a through a lot of info to get to the section I want , so I decided this little project would force me go through it all... If anyone thinks this should be added , I'll do my best to keep it updated , but would like input from others on what needs updating , what is obsolete , etc... as long as doesn't interfere too much with my aircraft updating ;) . Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound Observations
On 7/17/07, Maik Justus <[EMAIL PROTECTED]> wrote: > > If it _is_ a doppler > > effect, it's wrong. > Absolutely! What is interesting, that not all aircrafts have this effect. > Maybe this is only with aircrafts with more than one sound source and > what we hear is just the position dependence of the sound mixing? > While moving the external-view camera we get real Doppler effects; > realistic, but maybe confusing. This could confuse our ears, too. I didn't think of the mixing of two sound sources, that's a possibility. I think the doppler effect while moving the camera is fine, of course. > I think, that after moving the external camera I sometimes hear "wrong" > pitch. Switching then between external views, the "wrong" pitch is > constant. But moving to cockpit view and back to external view "resets" > the pitch to normal. Strange. Could this be the phase shift between the > two engine sounds? Switching to cockpit view switches the external > sounds off and switching form cockpit view to external view switches > them on without phase shift. Moving the external camera causes some > Doppler Effects (resulting in a phase shift of the two identical jet > sounds played with identical pitch). I think 787 and Bravo uses the > jet.wav sound. I tried to play this sound twice with some phase shift > and I think I get the same. That sounds like the best theory to me. Incidentally I observed a similar effect in real life the other day while watching my brother in law doing some patterns at the airport. I had my really-cheap one-speaker handheld static-spewing airband radio tuned to ATC, and as I walked away from the radio the obvserved pitch of the static (white noise) rose. I'm attributing it to the lowpass nature of sound traveling through air, or maybe some sort of positional effect from the acoustic properties of the speaker projection. It was an odd coincidence to observe that on the same day as reporting this though. :) > > The second observation is in flyby mode, and has to do with > > directional sound. I notice that when the plane is flying almost > > directly toward the observation point, the sound still comes full from > > one side, and when the plane passes and heads almost directly away > > >from the observer the sound comes full from the other side. I have > > even observed the plane coming at a significant angle with the sound > > coming from the opposite side from what it should. It seems like the > > stereo effect is being applied in a simplistic way, rather than based > > on the angle between straight-ahead and where the plane is. > > > No, that should be correct/realistic, but maybe there is a bug. But I > was not able, to reproduce this bug here. Which aircraft you are using? > This could be the cause, if the aircraft is using a stereo sound file. > Which operating system you are running? There are some OS-dependencies > in the sound, but the stereo calculation is always done by OpenAL > itself. Can you check, if you have this effect with the A6M2, too? I can't figure out how to start the engines in the A6M2, or I'd tell you. (Oh, I just realized it was the spacebar/s switch. *tries again*) My computer can't keep up with this plane, so it's hard to say for sure, but I don't think I notice it. The plane I was using was the c172p. I'm on OSX. Listening again to the c172p with different (better) headphones, I'm not as sure now. It still seems like it but it's not cut and dry and might be a psychoacoustic effect (i.e. in my head). - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air refueling JSBSim code versus Nasal code
On Tue 17 July 2007 15:27, gh.robin wrote: > Hello, > > I notice a huge conflict, about Air Refueling. > > With Aircraft which use JSBSim FDM, we had first, in the past (at least > from FG 0.9.8 and earlyer) the advantage to use the AAR JSBsim code, > before anything else it was developed. It was a great progress. > > Now if we want to have a customized aar code with nasal, or only to use the > existing aar.nas recently developed and situated in Aircraft/Geberic > directory, we cannot. > In order to be free to use that JSBSim feature only is we want, will it be > possible to include a JSBSim specific property , for instance > fcs/refueling "false" or "true" which authorize or not that automatic > feature > > Thanks > > Regards Hello, With T38 we get that error Nasal Message Nasal runtime error: No such member: getValue at FlightGear/data/Aircraft/T38/aar.nas, line 58 Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-11 distribution for Windoze?
Csaba Halász wrote: >On 7/16/07, Bill Galbraith <[EMAIL PROTECTED]> wrote: > > >>Is there a recently compiled distribution package of the Flight Gear >>0.9.pre11 package available, say something built within the last month? >> >> > >Yes, the pre11 is actually the current plib branch. As such, you can >find windows binaries at the usual place, namely >ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. Recently also Reagan >Thomas is providing builds at >http://139.78.95.188/flightgear/builds/plib/. > >Note that you still have to get the data package from cvs, preferably >corresponding to the build date of the binary. > > > My plan is to put up a new Win32 build for both plib and OSG versions at least every week, so it's probably better to offer this URL: http://139.78.95.188/flightgear/builds/ For the record, neither mine nor the other builds are complete distribution packages for Windows, just binaries... no installer, no data (and in my OSG case, maybe not even all the correct DLLs to make it run :( working on that). -- Reagan Thomas CEAT Labs 323 Engineering North Oklahoma State University (405) 744-5735 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Harald JOHNSEN schrieb: > Ralf Gerlich wrote: > > >> This is currently a local project. I am manually fetching the respective >> Landsat tiles (ETM+, 8 channels) and do manual training by marking some >> representative areas of different types. The goal is - as I said - to >> integrate this with OSGeo, who are also interested in the resulting >> data, and to use such data for the whole world to replace the polygonal >> features of VMAP0. >> >> >> >> > The thread is mainly about land use classification, but what about roads > and rivers ? vmap0 is really inacurate and it's a pain to fly vfr > (following road). Not only a lot of features are missing but most of > those visible are off by a great distance. And then it's also difficult > to add landmarks to the scenary because there is no accurate reference > point to help positioning objects. Will we use osm in the future ? And > since osm is far from being exhaustif how to make a choice of wich one > between osm and vmap to use to generate a tile ? > > HJ. > > > Hi Harald, OSM is a very fast developing project in Europe, Great Britain is leading, in the Netherlands and Germany there are nice activities, all surrounding countries need some more volunteers. No big activity in the US. So for Europe it seems to be good source for FlightGear data in the medium. This was my special interest that made me buy a Garmin 12 GPS some months ago at eBay and make some contributions to the project. JOSM is a really nice product to edit your data loggings before uploading. Especially the background Landsat 7 option is very nice to digitize data you otherwise never would have gotten. Only, as Martin reported, the cooperation between the group and interested FG developers is a little difficult. But solutions can be found, I am sure. I am a big fan of the OSM idea. Regards Georg EDDW - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] SimGear segfault fix on OSG image load failure
The segfault is triggered when OSG connot find a plugin which can load
the image, such as because of a wrong or unset OSG_LIBRARY_PATH
environment variable.
In that case, res.getImage() is NULL and dereferencing NULL gives the
segfault.
Index: simgear/scene/model/model.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/model/model.cxx,v
retrieving revision 1.55
diff -u -p -r1.55 model.cxx
--- simgear/scene/model/model.cxx 3 Jun 2007 18:21:04 - 1.55
+++ simgear/scene/model/model.cxx 18 Jul 2007 12:12:26 -
@@ -193,12 +193,17 @@ public:
osgDB::Registry* registry = osgDB::Registry::instance();
osgDB::ReaderWriter::ReadResult res;
res = registry->readImageImplementation(absFileName, opt);
-if (res.loadedFromCache())
- SG_LOG(SG_IO, SG_INFO, "Returning cached image \""
- << res.getImage()->getFileName() << "\"");
-else
- SG_LOG(SG_IO, SG_INFO, "Reading image \""
- << res.getImage()->getFileName() << "\"");
+if (res.getImage()) {
+ if (res.loadedFromCache())
+ SG_LOG(SG_IO, SG_INFO, "Returning cached image \""
+ << res.getImage()->getFileName() << "\"");
+ else
+ SG_LOG(SG_IO, SG_INFO, "Reading image \""
+ << res.getImage()->getFileName() << "\"");
+} else {
+ SG_LOG(SG_IO, SG_INFO, "Reading image \"" << fileName
+ << "\" failed");
+}
return res;
}
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Hi! Harald JOHNSEN wrote: > The thread is mainly about land use classification, but what about roads > and rivers ? vmap0 is really inacurate and it's a pain to fly vfr > (following road). Not only a lot of features are missing but most of > those visible are off by a great distance. And then it's also difficult > to add landmarks to the scenary because there is no accurate reference > point to help positioning objects. Will we use osm in the future ? And > since osm is far from being exhaustif how to make a choice of wich one > between osm and vmap to use to generate a tile ? Martin has investigated cooperation with OSM and IIRC the results were not satisfying, specifically regarding the willingness to cooperate, which would be necessary to feasibly integrate the data into scenery. I will have to talk to him once more what the details were. For major roads and railroads it might be possible to classify data from the imagery, but smaller roads are outside scope. Some smaller features which are hard to detect by classification but can be seen by human eye might be digitizable manually using Landsat or similar free imagery as background. It might be possible to correct parts of VMAP0. I was contacted a while ago by a researcher working on using ASTER data to determine linear features, but I haven't heard yet of their progress. The intent was to integrate OSM data as well, but also automatic detection of linear features. The concept is similar to OSM in that training data and corrections shall be supplied by webusers. Finally, VMAP level 1 is much more accurate than VMAP0 but available only for parts of the world. This is just an example of the VMAP1 _landmass_ available for the Mississippi Delta (Attention! long URL): http://mapserver.flightgear.org/cgi-bin/landcover?layer=v1_landmass&zoomdir=0&zoomsize=2&imgxy=300.0+300.0&imgext=-90.00+28.70+-88.74+29.96&root=&savequery=true&program=%2Fcgi-bin%2Flandcover&map_web_template=main.html For the Berlin scenery we have used the VMAP0-data as basis and adjusted this according to what we could see on the Landsat image. This exercise also showed, how seriously inaccurate VMAP0 is in various places: displacements by several 100m, streets which never existed, existing major roads missing or misclassified, ... Currently, there is no silver bullet regarding line features. We have different data available for different parts of the world. Actually, the scenery database is there to integrate the different data sources and we're still working on how to properly organise the processes involved. One has to connect different datasources at their borders so that the transition is as seamless as possible. On the TerraGear side I have created additions, gdalchop and ogrdecode, to enable access to all GDAL- and OGR-supported input formats. gdalchop is not yet finished (I will probably have a deeper look at that next week), but ogrdecode already has done a pretty good job for my local South Germany stuff as well as for Berlin and Oshkosh, which were built completely based on hgtchop and ogrdecode. Unfortunately, there is no OSM driver available for OGR, as a example, and the way the OSM project constantly modifies its infrastructure and data format, maintaining such a driver would be a pain in the ass. Some very dedicated guy at OSM obviously maintains an OSM-to-PostgreSQL-bridge which Martin wanted to apply to import OSM data into the scenery database. I'm not sure how usable that will be. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Ralf Gerlich wrote: >This is currently a local project. I am manually fetching the respective >Landsat tiles (ETM+, 8 channels) and do manual training by marking some >representative areas of different types. The goal is - as I said - to >integrate this with OSGeo, who are also interested in the resulting >data, and to use such data for the whole world to replace the polygonal >features of VMAP0. > > > The thread is mainly about land use classification, but what about roads and rivers ? vmap0 is really inacurate and it's a pain to fly vfr (following road). Not only a lot of features are missing but most of those visible are off by a great distance. And then it's also difficult to add landmarks to the scenary because there is no accurate reference point to help positioning objects. Will we use osm in the future ? And since osm is far from being exhaustif how to make a choice of wich one between osm and vmap to use to generate a tile ? HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Hi Curt! Curtis Olson wrote: > Part of the data is based on a "new" method of automatic landcover > classification from Landsat satellite imagery. The method is not "new" > in that it is well-known in other areas. The method is "new" in the > sense, that it was not yet applied to FlightGear scenery generation. > > > Hi Ralf, this sounds very exciting. Is it something you are running > locally, or part of a larger external project somewhere? Can this > process locate lakes and rivers with any level of accuracy? What image > resolution is available. At some point it would be fun to experiment > with drawing the textures directly over the terrain ... as an option for > people that like blurry airports and taxiways that disappear into mush > when you get close to them. :-) This is currently a local project. I am manually fetching the respective Landsat tiles (ETM+, 8 channels) and do manual training by marking some representative areas of different types. The goal is - as I said - to integrate this with OSGeo, who are also interested in the resulting data, and to use such data for the whole world to replace the polygonal features of VMAP0. There is a European project called CORINE, and they were obviously able to distinguish over 40 different classes of landuse from Landsat imagery by automatic classification. See http://terrestrial.eionet.europa.eu/CLC2000 for more information. The actual accuracy is still an open question, as we are currently focusing more on recognition value for navigation and performance. The latter part requires sometimes heavy simplification of the vectorised classification results in order to limit the number of triangles per tile. IIRC the maximum triangle count for the Oshkosh scenery is somewhere around 18.000 for some single tile (the others are around 10.000, but most are lower). Accuracy is obviously also dependent on the resolution of the imagery, which is 57m/pixel (one of the infrared bands, IIRC) via 28.5m/pixel (most bands, inclunding the visible light ones) to 14.5m/pixel (the panchromatic band). The panchromatic band can be used to enhance the visible light bands to double the resolution, but in the area of airports I don't think the result would be satisfying. This also means that some smaller regions such as tiny lakes or thin rivers may not be recognised or present in the final dataset, either because their shores blend too much with the surrounding terrain in the imagery or because they are removed on simplification (or both). Some of this may be an issue of more sophisticated training, but we are also investigating into how we could improve the simplification, e.g. by introducing weights so that a border between evergreen and deciduous forest could be simplified stronger than e.g. a border between lake and non-lake areas. We presented an experiment in the Berlin area with this approach on LinuxTag and I was told (as I wasn't able to go there myself) that we got very positive feedback. The Berlin scenery can be found here: http://www.custom-scenery.org/Berlin-Scenery.329.0.html > What we could also improve on the scenery in a much more simple step > would be to improve the textures. The current textures are much too > contrast-poor. At least that's my impression when I compare what I see > from above and what I see in FlightGear. Unfortunately, I'm not good at > knowing in advance what will look good, I just see when it doesn't look > good. > > > The current texture set is a huge improvement over what we had before, > which was a huge improvement over what we had before that, etc. etc. but > yes, there is still plenty of room for additional improvements in the > textures. Also, we really need to figure out a mechanism to blend the > transition between textures so we don't have the hard edges we have now. I very much favour the use of generic textures over the draping of satellite or aerial imagery, as generic textures can still provide almost arbitrary detail without using much space on disk and in RAM. When flying and navigating the important part is that a road, a forest or a city border is in approximately the right position. It is not important whether a specific tree is at the actual position it is in in reality. Furthermore, satellite or aerial imagery is only available freely for some regions of the world (parts of the U.S., for example) or only in low resolution or both. Still, by using generic textures and automatic classification, we can make much better use e.g. of the freely available Landsat imagery, even though the original data is only of a low resolution. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ __
