Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Ron Jensen wrote: Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. No management in CVS is planned. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Ralf Gerlich wrote: Ron Jensen wrote: Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. No management in CVS is planned. At least not in this structure. This is a means of data transport, not of data management. Cheers, Ralf -- Ralf Gerlich Diplom-Informatiker Software Engineer and Technical Consultant Dr. Rainer Gerlich System and Software Engineering Auf dem Ruhbühl 181 | Tel:+49 7545 91 12 58 D-88090 Immenstaad | Fax:+49 7545 91 12 40 Germany | Mobile: +49 178 76 06 129 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
of us two about this proposal ends at this point. However, if anyone else has comments or criticism on the proposal, I'd like to hear about them. Or maybe we should use prefixes instead of directories at other occasions as well, if that concept is considered superior. Let's see: $FG_ROOT/Aircraft/bo105.splash.rgb $FG_ROOT/Aircraft/bo105.thumbnail.rgb $FG_ROOT/Aircraft/bo105.fdm.xml $FG_ROOT/Aircraft/b1900d.splash.rgb $FG_ROOT/Aircraft/b1900d.thumbnail.rgb $FG_ROOT/Aircraft/b1900d.fdm.xml $FG_ROOT/Aircraft/concorde.splash.rgb $FG_ROOT/Aircraft/concorde.thumbnail.rgb $FG_ROOT/Aircraft/concorde.fdm.x ml Yummy. :-) Probably not more to add but proposing the following layout instead: $FG_ROOT/Aircraft/b/o/1/0/5/splash.rgb $FG_ROOT/Aircraft/b/o/1/0/5/thumbnail.rgb $FG_ROOT/Aircraft/b/o/1/0/5/fdm.xml $FG_ROOT/Aircraft/b/1/9/0/0/d/splash.rgb $FG_ROOT/Aircraft/b/1/9/0/0/d/thumbnail.rgb $FG_ROOT/Aircraft/b/1/9/0/0/d/fdm.xml $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/splash.rgb $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/thumbnail.rgb $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/fdm.xml Different goals, different solutions ;-) m. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1
Hi Melchior, thanks for your feedback. I am taking this to the developers' list. To everyone else, I am referring to this mail on the users' list: http://sourceforge.net/mailarchive/message.php?msg_name=490C204E.7040405%40aon.at Melchior FRANZ wrote: The question is, however, if we don't want to put all airport data into one file, in which case the fourth dir level would be superfluous. Merging the tower and threshold files would be possible, but I would oppose merging them with the parking files for two reasons. Reason One is organisational: The parking files are based on direct manual work and are created directly by TaxiDraw, while the tower and threshold files are from the apt.dat. Combining them would mix automatically derived and manually generated content, making management of the data much more complex. I see strong arguments in favour of keeping the connection to apt.dat. Although currently the v810 files are not maintained any more by Robin Peel, we will eventually move on to v850 and then be synchronised with the X-Plane Community again. (BTW: There is an open position at the World Custom Scenery Project for implementing v850 in TerraGear ;-) ) I also do not see any chance in general to push an XML format to Robin Peel and the X-Plane-Community. Keep in mind that the files distributed with the scenery contain only a small fraction of the data contained in the apt.dat (which should already lead to an increase in speed). Taxiways, markings and other details are not re-distributed. For this kind of data, the current apt.dat-format is a good compromise between compressing the representation and making it user-editable. Reason Two is technical: The parking files are currently not in PropertyList format. I know that this has been subject of fierce discussion, which I have no interest in repeating. As long as nobody comes up with a patch making the AI code use a PropertyList format, converting the old files and informing me so that I can update TaxiDraw accordingly, we will probably also have a non-PropertyList-format for the AI files in the next FlightGear release. But then Reason One would still exist. Now it all boils down to the tower and threshold files. These are typically pretty small, so that the overhead for parsing two files instead of one file should be negligible. Further there should be very seldomly a case where we need the information from both files at the same time, e.g. when teleporting to another airport, thereby changing the tower view position. Merging them in time for the next release would mean that we'd have to do another scenery release. Such a release - with some further bugfixes regarding the terrain - is planned, but not before end of November due to time constraints on Martin's and my side (preparing to get my Ph.D. thesis submitted). If we were to make a release this year, this would leave not much more than three or two weeks for properly testing this change in the wild. If things go wrong on the scenery side, we might be just in time for the FlightGear release. So if there is a strong argument in favour of the changes you proposed, I'm open to such a last-minute change, but otherwise I'd rather leave the structure as it is. The last time we fixed scenery in the last minute we had a good share of chaos ensue (which happens to have been just about one year ago). I'd also like to add that a sample of the structure as proposed has been in the FlightGear data CVS for quite some time, containing data for the KSFO area, ready to be commented. IIRC this was also explicitly mentioned in the CVS logs. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
Hi Gerard, I suspect I have the same problem as you. My FlightGear instance (CVS/OSG) seemed to take a large hit in framerate (normal: around 25, now 3FPS) due to precipitation yesterday and when I tried to disable it via the Rendering option menu to check whether it really was precipitation, but nothing happened. I can't reproduce this currently due to a consistent crash, probably due to a version incompatibility with a too old OpenAL installation. Cheers, Ralf gerard robin wrote: I can't avoid precipitation with the Rendering option menu , is it just me ? -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] World Scenery 1.0.1
are for example found in Airports/K/S/F/KSFO.*.xml In addition, the Airports directory contains an index.txt-file with three columns: ID, longitude and latitude of the airport, sorted by longitude and latitude. The position is calculated as the center of gravity of all runways specified for the airport. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery 1.0.1 Models name
Hi Gerard! Did you download and unpack the SharedModels.tgz from the static objects database, as noted in the announcement? Cheers, Ralf gerard robin wrote: However on Paris LFPO we get the following errors : Failed to load model: Failed to open file at /usr/local/share/FlightGear/data/Models/Misc/Modulevilletriangl.xml at /usr/local/share/FlightGear/data/Models/Misc/Modulevillerectangl.xml -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Hi Heiko! Heiko Schulz wrote: Look here: http://www.flightgear.org/forums/download/file.php?id=263 http://www.flightgear.org/forums/download/file.php?id=264 http://www.flightgear.org/forums/download/file.php?id=260 http://www.flightgear.org/forums/download/file.php?id=261 Doesn't look this more realistic than the old clouds? And don't we want to make it right, it make it realistic as much as we can? Erm, these are FlightGear pictures? Seems like I have missed a lot. The ambient occlusion effect is obvious, but when did we get reflections (see the windshield in the last picture)? Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Martin Spott wrote: BTW, do you still remember sitting in the aircraft shown on this picture ? I'm pleased to see how close the model gets ! And how does one get close to the model? Seems it isn't included in CVS. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs scenery generation problem
Hi Michael! Michael Smith wrote: I have my lon/lat for Bermuda (N32W065 - N33W064). [SNIP] genapts --input=data/airports/apt.dat --work=./work --min-lon=32 --max-lon=33 --min-lat=-65 --max-lat=-64 Here you should swap lat and lon. Your latitude is 32 (32 deg north) and your longitude is -64 (64 deg west). ran fgfs-construct --work-dir=./work --output-dir=./output --lon=32 --lat=65 --xdist=1 --ydist=1 \ AirportArea DepthContour Landmass Road Sand SRTM-30 Town Similar problem here. Note that the position given by --lon/--lat is actually the center of the area being built and --xdist/--ydist are the half-width/height of the area in degrees. So --lon=-64 --lat=32 --xdist=1 --ydist=1 would build the area with southwest corner N31W065 and northeast corner N33W063. DepthContour is not needed, by the way. It's just a different representation of the SRTM dataset for use in the mapserver display, but currently TerraGear cannot make any use of that. Make sure that you include all the subdirectories of your workdir when calling fgfs-construct. Note that even though that tutorial in the wiki (which I am not the author of) uses SRTM-30 as a target directory for the SRTM data, it seems that SRTM 3arcsec data is actually used. That's not a bad thing at all, but worth noting. SRTM 30arcsec data is only relevant north resp. south of the respective polar circles, as no SRTM 3arcsec data is available in that area. Hope that helps, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs scenery generation problem
Hi Michael, I'd need some more details on the steps you followed to check whether you are missing anything. Cheers, Ralf Michael Smith wrote: Hello all, I have been trying to build scenery with terragear-cs and I have got through everything sucessfully but it is not outputing the scenery sub-tree. Everything went well without errors and I know I have the right vmap0/.hgt data (I checked the shapefiles in osgviewer and used a freeware terrain viewer for the hgt file and confirmed they are my areas files) but it just doesn't put anything in the output directory. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery vs. Base Package; Was: Revision Log / Intended developments
Martin Spott wrote: Durk Talsma wrote: Ralf Gerlich and Martin Spott: Complete scenery rebuild based on improved terragear algorithms / object database updates In the current state, after setting a deadline, we should be able to get an entire Scenery release out from the current datasets within just a few days _plus_ maybe a week of testing in a small circle of people most of the people we asked didn't respond anyway ;-) There's one real show stopper - not to the FlightGear release but, instead, to the Scenery releases, which on the other hand is related to the way FlightGear reads airport data: As mentioned before, the Scenery releases are currently tied to the Base Package because several positions are read from the 'apt.dat', the 'rwyuse.xml' and the 'parking.xml' which is stored in the Base Package. There's another issue. The apt.dat contains more and more heliport definitions. The current genapts tools crashes on these or generates hillarious runways, which obviously are too short for proper normal runway markings. I would have loved to fix that and have genapts generate a proper heliport texture, but that would make the scenery incompatible with the released datapackage. So we might want to include a proper heliport texture (apt.dat knows asphalt, concrete, turf and dirt helipads) in the base package and regenerate the scenery with proper helipads. In the build currently being prepared for release Martin replaced the helipad records by simple taxiway records in order avoid the genapts-trap. He also tried to add a helipad object a few cm above the elevation of the center of the helipad. The additional elevation was necessary to avoid the helipad sinking into the ground. However, either the helicopter now stands above the ground or penetrates the helipad, with hilarious graphical results. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for aircraft nominations
Matthew Tippett wrote: Likewise with scenery. The default location and whatever demo locations should ship with reasonably detailed scenery + other common locations. The 'full' brings in other common scenery, and 'extras' brings in everything else. (Integrating terragear as a thread within the main binary would make autoloading a simple checkbox - hint hint :). I sincerely hope you didn't mean to earnestly suggest that last part. TerraGear is a beast of complex computational geometry algorithms and neither in a shape nor intended to be integrated into FlightGear. Maybe you meant terrasync? ;-) Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading Textures for Photo-Scenery?
Hi Nicolas, if I understand you correctly, you want FlightGear to superimpose a given texture over a whole terrain tile, given that a texture file with the same name as the tile is found. I think that this would require that either a) TerraGear generate appropriate texture coordinates for the tile, mapping the texture continuously over the whole tile, or b) in case of loadPhotoScenery, the texture coordinates contained in the .btg.gz must be ignored and rebuilt on the fly by FlightGear. Variant a) might be possible by creating a copy of the photo tool using a whole texture instead of a chopped texture. However, it is questionable whether such a large texture for a whole tile is well handled by the graphics subsystem. Variant b) might have generate a large amount of processor load when loading a tile, as the generation of the texture coordinates requires transformation of vertex coordinates from cartesian to geodetic, which involves a lot of heavy maths (which is one of the reasons why TerraGear is doing such calculations up-front). I'm not sure why the photo-tool from TerraGear is not applicable for you. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How I spend my spare time
Hi! Heiko Schulz wrote: Ground elevation in sea too? If yes so we could add the sea itself as a planar surface with all features possible, and Arnt Karlsen would have his tides and the outcome of the global warming! :-P I don't know about SRTM4, but I suspect that no new measurements have been made (SRTM=Shuttle Radar Topography Mission) or other data has been added, so SRTM - if at all - will report the elevation of the waterline for water bodies only, no ground elevation, due to the design of the aperture radar used for the measurements. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How I spend my spare time
Hi Gerard! gerard robin wrote: Well, i thought that costline was calculated with the intersection of the sea level (or water level) and the ground altitude. I was wrong, my imagination was (is) out of reality. :) Actually, it is the other way around, IIRC (Martin, correct me if I'm wrong). The water body boundaries are determined from other sources (e.g. Landsat) and are used to remove the spikes in the SRTM data which are often found in the area of water bodies, as the radar reflectivity of water surfaces differs greatly from that of other surfaces. The SWBD (SRTM Water Body D???) contains the boundaries of the water bodies used for this postprocessing of the data. SRTMv2 and onwards are based on the same raw data as captured by the the single Shuttle Radar Topography Mission. The only difference is additional processing of the data, such as the removal of spikes on water bodies as mentioned above. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Materials wrong for San Diego bay?
gerard robin wrote: On dimanche 28 septembre 2008, Alex Perry wrote: Isn't it only a coastline error ? like we have elswhere for instance, Hong Kong bay, NIce and Cannes area (France) Seems like it. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Loading Textures for Photo-Scenery?
Hi all! In the FlightGear forum we came upon the question of how FlightGear locates textures, e.g. used by scenery generated with the TerraGear photo-command. http://www.flightgear.org/forums/viewtopic.php?f=5t=2149 As far as I understand the current OSG loader code, all textures must be defined in the materials.xml. According to Fred Bouvier, in the old PLIB-days textures not defined in the materials.xml where searched for in the same folder the .btg.gz-file was located in. I didn't check the PLIB-code, but from a look into the OSG-code I have seen that currently no such search is performed. Is this even possible with the current architecture? It seems sensible to me to distribute such textures with the scenery instead of the base package. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading Textures for Photo-Scenery?
Hi! Curtis Olson wrote: Sure, just like any aircraft or object model can have it's own textures. There may be some nuances that have disappeared over the years since I doubt this has been heavily tested, but I used to have a KSJC demo with about 1 pixel per foot resolution. And don't forget that you could place an .ac model at ground level and somehow forget to place the .btg file if you really wanted to. Well, I think that photo may be better suited, as it takes the task of taking care of the height-field from the author. Loading a terrain tile differs in quite some way from loading an object model or aircraft, which also involves the use of the material library. The latter currently only loads its materials from materials.xml, but does not search for tile-specific textures in the scenery folders. I was rather hinting that maybe somebody more informed about the architecture of the terrain subsystem might want to implement this type of search. ;-) Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading Textures for Photo-Scenery?
Hi! Frederic Bouvier wrote: in simgear/scene/tgdb/leaf.cxx branch PRE_OSG_PLIB_20061029, there is this code : [SNIP] I didn't test it, but at least, the intention was there ;-) In the OSG-version I didn't find anything similar, so I'd say that it's missing. I am not able to do anything about it - both due to missing knowledge about OSG and due to time constraints - so I hope somebody with the necessary abilities will pick this up as a feature request. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30
Hi James, the CustomScenery-Version of TerraGear was already upgrade to cope with these changes. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30
Jon Stockill wrote: Ralf Gerlich wrote: Hi James, the CustomScenery-Version of TerraGear was already upgrade to cope with these changes. Excellent - does that already include the point in polygon fix too? Unfortunately not... I'm thinking of trying some more horribly detailed scenery and it'd be interesting to see how things have progressed. I'd suggest to just get ahead with your ideas. Maybe the current TerraGear works for your purposes. Remember that that point-in-polygon-problem does only occur in some cases. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30
Curtis Olson wrote: The previous point-in-a-polygon algorithm was perhaps not as clever, but it did seem reasonably robust. Unfortunately it was not. I had several tiles failing because of it... Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30
Hi Curt! Curtis Olson wrote: Fair enough ... maybe my memories have improved with age, but I don't recall having this much trouble with failed tiles when I did the scenery builds. There would always be a handful of them ... maybe a dozen or two over the entire surface of the earth. If that's about what we have now, then I guess it's not that big of a deal. We could always insert replacement tiles that were successfully built in past runs if they are blowing up now. Well, our point essentially is making TerraGear robust for fully automated rebuild. Failing tiles are no option there, and I still have the hope to get a clean solution there. However, I have reverted the calc_point_inside()-changes locally and a rebuild is currently running. I hope that the set of tiles failing and the set of tiles having visual bugs (as in the 1.0.0 scenery) is disjunct, so that we can actually do these replacements without introducing ridges at tile borders (which would be trading one visual bug for another, although less bad). We will see how much trouble will come up. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Hi Fred! Frederic Bouvier wrote: What if I have write access to the CVS repository ? Do I have to maintain a seperate CVS workspace and apply my own patch in that workspace before CVS commiting ? In that case I don't really see a great benefit ? For TaxiDraw, I have git repository and a CVS checkout. To update from CVS I use git-cvsimport (which Martin or Pigeon are doing for us in case of FlightGear). When I have commits ready for CVS, I can do a diff and patch that onto the CVS-repository, or I let git do that using git-cvsexportcommit. The git-to-SVN-integration IMHO is much better than the git-to-CVS-integration, as it has both of this in a single tool, which allows you to export complete paths of history to subversion without any hassle (using git-svn dcommit), while git-cvsexportcommit requires you to export every git commit by an own invocation. However, git-to-git integration is even better ;-) Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Zeppelin NT (ZLT-NT) update
Hi! Martin Spott wrote: I think Ralf Gerlich has quite some expertise on this one - his home airfield is the place where these beasts are being built and he's one of these guys who want to know every detail :-) As far as I remember he also has a nice livery for the Gummiwoosch, yet I don't know wether it's ready for distribution. Ralf !? Yes, the Zeppelins are built at EDNY. Note that they differ from blimps by the fact that Zeppelins have a rigid inner structure while blimps are held in shape by the pressure of the gas. That's one of the tricks the guys at Zeppelin have, so they can attach the engines to the body of the Zeppelin instead of the cabin, which makes flying nearly silent for the passengers. With a hull without rigid structure, there is nothing to attach the engines to. They have space for 12 or 13 passengers. The hull generates dynamic lift and most of the time the ship is actually not lighter-than-air. I was told that typically they have a mass of about 2 tons, but a weight of around 700kg. If empty or with low fuel and payload, they are lighter-than-air. IIRC the rule-of-thumb figure for the transition between dynamic flight and hovering is at about 20kts IAS. They can activate a special system, which directly puts thrust-vector-control of the aft engine on the pilot's sidestick, allowing to control the ship the same way as with elevator and rudder. The side-engines can be rotated upwards and downwards, which is used during take-off and descend. These ships are flying at EDNY all the time. They're doing several roundtrips around the Lake of Constance area each day, given appropriate weather. Just today I had just vacated the runway coming back from a short local flight, and I saw one of them taking off. One is currently doing trips in London, and is bound to be shipped to San Francisco afterwards. IIRC it will take its homebase in Moffett Field. I don't have that livery yet and I had hoped to get some more detailed information on the geometry etc. The livery takes reference to the fact that the ship will be flying in the San Francisco area for tourist attraction. I'm not sure, but somehow I seem to remember that this is our standard scenery area ;-) That's all the info I could come up with at this late time of day ;-) Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
Hi Christian! Christian Mayer wrote: if the triangulation code causes trouble, you could try CGAL (http://www.cgal.org/). They have very robust and well designed computational geometry codes. Thank you for the hint. In the meantime I have found out that it is not TriangleJRS that causes the problems, but rather TerraGear itself in that it does some further processing before triangulation but after calculation of the point-in-polygon. I know that CGAL is used by Frederic Bouvier's FlightGear Scenery Designer and maybe using that is an option in case of a TerraGear rewrite ;-) (Note that I do think that the FGSD is a very good thing (TM), we just need something that can do batches of work on a headless machine - such as regenerating World Scenery on some high-performance machine nearly on the other side of the globe ;-) ) Currently, I am working on a fix that involves doing the point-in-polygon calculations _after_ the creation of the vertex and edge lists. This way the points-in-polygon should be consistent with the constrained edges TriangleJRS sees. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D clouds - progress report·
Hi Stuart! Stuart Buchanan wrote: Just to keep everyone up to date on where I am with porting 3D clouds to FG OSG: http://www.nanjika.co.uk/flightgear/clouds.jpg Obviously there is still a lot of work to be done before they are complete, but progress is being made. Doesn't look bad at all. The main visual problem may be the textures, which are completely opaque. Real clouds tend to increase transparency towards the border. Just my 2ct. Cheers, Ral - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
Hi! Ralf Gerlich wrote: While it seems to me that the workaround should work, due to previous experience with TerraGear and its subtleties I would not want to bet on it. ...and I see that I was right not to bet: The workaround doesn't work. TerraGear failed on the first try building the EDDF-area. The actual problem lies within TriangleJRS, the triangulation code of TerraGear, which - as several checks have shown - is not as robust as advertised regarding computational geometry predicates. The point-in-triangle-detection-code does seem to have problems if the respective point is pretty near to the contour of the triangle. While the point is perfectly inside the triangle, TriangleJRS cannot detect that. Nope, that's not it... I have just checked once more and found that triangles for the extremely small triangle parts simply do not exist. They are not generated by TriangleJRS. This could have one of two reasons: 1) TerraGear does some specific edge-splitting when preparing the list of nodes and constrained edges for TriangleJRS. This is sensible, but may move the nodes of the slivers in a co-linear fashion, i.e. the sliver parts completely vanish. 2) TriangleJRS removes the triangles for these parts as it thinks they are too small. After some checking it seems that 1) is the case. I'm at it and I hope to still be able to do a rebuild as announced with a new solution. However, don't count on it. The call for submissions to the static scenery objects database is left as is ;-) Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HEADS UP: Scenery regeneration
Hi! I have uploaded a picture showing the situation in the example of VHHH to http://www.custom-scenery.org/fileadmin/people/rgerlich/vhhh.png This is an export from QGIS, using shapefiles I generate from test printouts of TerraGear. I forgot to color this properly, but actually the textures and colors don't matter. What we have is a blue polygon, which should be of material type IrrCropPastureCover. This lies inside an Ocean polygon, which extends on the east side of the blue polygon in pink. The blue IrrCropPastureCover is also adjacent to a light-blue GrassCover polygon. What you see at the bottom are two circles, representing the point in polygon for these polygons. They have the material type attached to them. In the small cutout on the right side you see that the blue polygon continues in a very slim sliver to the south, the width of which is about 4 to 8 times SG_EPSILON and which becomes more slim towards the south. The calc_point_inside() algorithm I implemented places the inside point perfectly within this sliver, which I have checked by appropriately scaling the part in QGIS. Unfortunately in preparation to the triangulation step, the vertices of the right border of the sliver are merged onto the left border of the sliver, so that the sliver essentially vanishes. Curtis Olson wrote: As Ralf points out, there is code that attempts to find stray nodes that lie on existing edges and split the edge at that point. When this situation exists, it can lead to degenerate behavior. As I understand it, the terragear check should be more ambitious than the TriangleJRS check in order to prevent problems down stream. Not necessarily _more_ ambitious, but at least as exact. As far as I have understood, Jonathan Shewchuk uses what he calls Adaptive Precision Floating-Point Arithmetic for the geometric predicates, so this is quite different from the epsilon-approach. You can tune the thresholds for detection of this situation, but the looser you make the constraints, the more you are likely to alter the original geometry which will create artifacts in the final result. I have tried, but for some reason TriangleJRS then has problems with colinear edges, which is - as far as I understand - exactly the thing which should be avoided by splitting. And it is curious, as it seems to contradict the adaptive precision idea expressed above... In general, what TerraGear is doing currently - eliminiating the slivers - actually is the right thing performance-wise, as we really do not want these slivers to take up valuable triangles in the scenery files. What we might have to change is the point were the point inside polygon is calculate to after the creation of the edge and vertex lists for triangulation. It should be possible to keep the information about the edges belonging to a polygon resp. contour, so that the point-inside-calculation could use these instead of the original polygons. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] HEADS UP: Scenery regeneration
Hello again! It seems that I finally have a somewhat dependable workaround for the TerraGear coastline bug reported shortly after the release of the 1.0.0 scenery. I have reviewed the algorithm thoroughly - together with Martin - and checked some of the tiles reported as faulty beginning of this year and they seem to be generated correctly now. Martin and I plan to start a new generation job on the weekend of the 16th/17th of August. We would like to include the current state of the static scenery database with this release. In case anybody has any objects intended for submission but not yet submitted, this is the time to submit them to the database, if you want to have your contributions included in the new scenery. As this scenery is to replace the faulty scenery which was released together with FlightGear v1.0.0, we will have to use the airport database included with that release for consistency reasons. Updates as found in the apt.dat in CVS will therefore unfortunately not be included. (As a sidenote: This is one reason why the apt.dat or at least the parts thereof used for airport generation as well as the AI ground networks should reside with the scenery, not with the base package...) We intend to tag the generated scenery unstable for obvious reasons before making it an official release. While it seems to me that the workaround should work, due to previous experience with TerraGear and its subtleties I would not want to bet on it. As it seems, some mirror providers may not be able to carry the load of two scenery releases - the official one and the unstable version -, so we will not publish the alpha release via the normal distribution channels, where mirrors normally pick it up. Possibly, we will publish a location were interested mirror providers can also pick up the unstable version, and we would appreciate any support from mirror providers in that direction. I am not that much thrilled about the kind of solution I found as it doesn't solve the actual problem but rather enhances a perfectly working part of the code with some special cases. The actual problem lies within TriangleJRS, the triangulation code of TerraGear, which - as several checks have shown - is not as robust as advertised regarding computational geometry predicates. The point-in-triangle-detection-code does seem to have problems if the respective point is pretty near to the contour of the triangle. While the point is perfectly inside the triangle, TriangleJRS cannot detect that. The points are used to mark polygons and their associated triangles with associated attributes, including texture. As TriangleJRS does associate some of the points with adjacent triangles, texture attributes spill out into adjacent polygon areas. This is most noticeable in places where sea/ocean area is transferred into land this way. Fixing TriangleJRS was not possible for me as I am clearly not a computational geometry man. I will try to contact Jonathan R. Shewchuk on this issue, after some further analysis. The triangle package should be based on arbitrary precision predicates, as far as the documentation goes, but maybe I misunderstood what is meant by this ... or the predicates don't actually deliver to this promise. I have modified the algorithm to ensure that the selected points are at least a given distance away from the contours. Unfortunately, the new algorithm is less robust than the old one and might outright deny working on some specific valid, but degenerate polygons. Further, the distance used had to be selected arbitrarily according to the results of the scenery generation, but should be a safe estimate. The new algorithm has the advantage that instead of silently delivering points inside the polygon which TriangleJRS cannot handle, it will either deliver a good point or fail completely, resulting in an abnormal exit of the building process for the respective tile. I would appreciate if anybody wants to review my changes. The current version is available via git from http://mapserver.flightgear.org/git/terragear-cs/ Look into src/Lib/Geometry/poly_support.cxx, function calc_point_inside() (around line 447). Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear scenery
Hello Martin, Martin Fenelon wrote: Is the current official FlightGear scenery created with a 'World Custom Scenery Project' patched version of terragear? yes, it is, which is also the reason for some very unfortunate bugs in the scenery itself, which up to now I wasn't able to fix or work around for several reasons. Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet more aerodrome taxiways/aprons questions
Hi Martin! Martin Fenelon wrote: 1. Which version of TaxiDraw should I be using? I've been working with a CVS version from last week. The CVS version should be pretty stable and generates v810. 2. Should I submit apt.dat format 810? AFAIK, TerraGear can handle 810. 3. Runway markings: The runway in question has edge, centreline and threshold (one of which is displaced) markings, plus some arrows pointing to the displaced threshold. Non-precision markings are not appropriate, will visual markings have everything I need? Visual markings should normally consist of the runway number, edge and centreline markings. Displaced threshold is marked using arrows. I have just looked at the genapts sourcecode, which generates additional threshold markings (see Texture/Runway/pa_threshold.rgb texture). However, from a principal point of view using Visual Markings in TaxiDraw would probably be correct. Curt, did I miss anything, or why are the threshold markings included in visual markings for genapts? Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodrome taxiways/aprons and terragear
Hi Martin! Martin Fenelon wrote: Now to another question with regard to hold lines. Let's say I have a bit of concrete apron with a hold line: true 090, length 150, width 15 Where will the yellow line be? along the length EW? and is it in the centre? As far as I know, terragear does not generate hold lines at all. In general, the X-Plane definition says that the yellow line is supposed to be across the long axis[1], but the definition does not say where it will intersect the long axis. Cheers, Ralf [1] http://www.x-plane.org/home/robinp/Apt810.htm#RwySfcCodes - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ver 1 scenery
Hi all! Syd wrote: CYVR has been destroyed ! :) NO island anymore , and the delta has dried up and been converted to farmland ... This looks like the same effect leading to the problems in Nice and elsewhere. I'm still at it, but my schedule was quite unfortunate in past weeks. Note, however, that CYVR (the airport) is displayed correctly. Cheers, Ralf - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: EFF fights for the rights of 3D modellers against bogus trademark claims
LeeE wrote: On Friday 11 April 2008 12:17, Ove Kaaven wrote: LeeE skrev: I was thinking more along the lines of publicly displaying the photo in an exhibition, which I don't think could be regarded as distribution, I suspect the RIAA and MPAA would disagree... Why are we discussing the term exhibition here? I would say that by any reasonable interpretation the term does not apply to what the FlightGear project is doing with its models. Cheers, Ralf - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Ralf Gerlich wrote: Ralf Gerlich wrote: Currently there is no shapefile version of GSHHS 1.5, which was available for 1.3, so we need to get some tool to import the custom binary format of GSHHS into the database, including the handling of shorelines crossing the dateline, etc (e.g. Eurasia continent definition). Yes, this is on my TODO-list, and no, it's not on top. ...volunteers welcome ;-) Not any more. I have implemented this tool on the weekend and the import of GSHHS 1.6 into the database is running. The result will be closed polygon layers. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Floating Airport
Hi! SlickSoft wrote: Hello, I have found a floating Airport in Toronto (CYTZ) Here is a picture: http://img514.imageshack.us/img514/4773/cytzsn8.png This is Toronto island airport, here is a RL pic http://www.thefurnishedstay.com/nucleus/media/1/20061023-toronto_island_airport.jpg Seems like a problem in the base data. Neither GSHHS nor VMAP0 landmass place this airport on the island. Cheers, Ralf -- Ralf Gerlich Diplom-Informatiker Software Engineer and Technical Consultant Dr. Rainer Gerlich System and Software Engineering Auf dem Ruhbühl 181 | Tel:+49 7545 91 12 58 D-88090 Immenstaad | Fax:+49 7545 91 12 40 Germany | Mobile: +49 178 76 06 129 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi! Jocelyn Couetdic wrote: I hope you'll find without too much trouble the bug behind all this. Thank you for your reports. As reported, I have already found the problem and now I am searching for a fix. However, these reports will also help me find out whether my fix - once implemented - is successful, so keep reporting, I am collecting them. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi! Arnt Karlsen wrote: ..an idea out of the blue; if we model sea water, and the sea floor, we could _generate_ the coastline at runtime? It does move with high 'n low tide. The current scenery concept can only support fixed coastlines and we'd have the same problems with the rivers when the sea-level moves. The problem is _not_ the coastline itself, it is the consistency of the quite accurate GSHHS coastline with the quite inaccurate VMAP0 waterways. In addition, as I understood, GSHHS is missing some important waterbodies in full or in part. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi! Tim Moore wrote: Is it practical to use the Landsat classification stuff you guys have demoed on your web pages to generate our own coastline data? Yes, we can extract the coastline data, but it might still require some further editing to eliminate misclassifications. The editing effort might still be less than the effort required for correcting the missing data in GSHHS, given that we have equalized Landsat data for the whole world. We can try using the typically available Landsat mosaics, but these only have RGB data, while the waterbodies are most reliably classified using RGB and infrared. Still, it's not possible to extract waterways automatically in a reliable way from Landsat data, so we will still have to adapt VMAP0 data ourselves. Maybe the OSM data is of help there. Note that Martin has imported OSM data into the database, making it more easily available for TerraGear, as the OSM format itself is a custom format not currently supported by OGR. The guys at OSM also seem to be in the process of changing their format, but there's also a licensing issue. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
S. Andreason wrote: Are you still looking for 1x1 tiles with ocean showing as land? Well, I think I have the reason for the problem, but still I'm interested in bug reports. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Stewart Andreason wrote: Well, I have some! ;) [SNIP - Loads of sightings] OK, I originally intended to do partial rebuilds for the buggy tiles, but if there's so many of them (wonder why I didn't see any of them when checking the scenery myself) that warrants a full rebuild. Thanks! Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi all! gerard robin wrote: [SNIP] You could notice that apt VHHH is now , not an island but on full ground area Thanks for the reports. For your information: From the VHHH-tile I was actually able to identify the actual trigger for the buggy tiles. The trigger does lie in the modifications. Note that I'm talking about the trigger, not about the origin, as the part of the algorithm I modified actually is robust and correct - in contrast to the old version of that algorithm. I was able to verify that the data the modified part of the algorithm delivers is correct even in the case of the buggy tiles, but the rest of the TerraGear build chain cannot handle these correct results. The seemingly obvious fix - reverting to the old algorithm - isn't a fix. The reason for the modification in the first place were tiles consistently failing to build, without a workaround or other fix. Here the old algorithm was not robust enough for the data it got. Reverting to the old algorithm would therefore make these failed tiles reappear. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
One thing to add... Ralf Gerlich wrote: Currently there is no shapefile version of GSHHS 1.5, which was available for 1.3, so we need to get some tool to import the custom binary format of GSHHS into the database, including the handling of shorelines crossing the dateline, etc (e.g. Eurasia continent definition). Yes, this is on my TODO-list, and no, it's not on top. ...volunteers welcome ;-) The goal is to have something like a generic gshhs2ogr-converter that can convert gshhs to any format supported by the OGR library and outputs the data properly clipped to -180=lon=180, -90=lat=90. A tool independent of TerraGear but possibly using gpc would be favoured. One of the OGR-supported formats is PostgreSQL, which is the database software we are using on mapserver.flightgear.org. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
AnMaster wrote: Good question, I guess combining them and manually fixing the problems would be too much work. I got no really good solution. But the current coastlines are very bad in many cases. What about only using GHSSH for those coastlines around continents? With that I mean coast line around, say, North and south America, Europe/Africa/Asia (that, apart from the Suez channel, are connected), Australia and any islands, and simply discard any coastlines inside these blocks and use vmap0 there. That is: don't trust how vmap0/GHSSH classify the data. Would that be feasible? Feasible, as GSHHS explicitly makes the outer coastlines available and differentiates them from inner shorelines, but it wouldn't solve the problems with inconsistent waterways at the coastlines of continents. Even though that is a lot of work, manually adapting our VMAP0-based data to the GSHHS-data is the only solution I currently see. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
LeeE wrote: So it looks like we either live with the problem until someone else creates a new database with all the problems fixed, or bite the bullet and fix it manually ourselves. Yep, that's the spirit ;-) Would it be possible to cobble together a small utility that would allow small parcels of the scenery database e.g. 1x1 deg tiles, to be checked and corrected manually without setting up the full scenery build system? That way, many people could work on it whenever they feel like it. I've had to do this sort of manual data correlation/verification a couple of times over the years, on different projects I've worked on, and while it sounds like an onerous and tedious task it's not too bad if you can just do bits of it, now and then, as a break from your primary tasks. You could use qgis or any other GIS for that. No need to work on scenery files and no need for firing up the scenery generation system at all. It would still be possible to allocate the tasks in 1x1 deg tile portions. Still someone would have to implement that logic in a convenient way for editors to use. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hello all! gerard robin wrote: YES, which could be. however, regarding these Scenery ERRORS it is probably a generic bug , it is not a specific bug (Ralf could answer better than i can), so the list of the area where the coastline is wrong will be very large. I can only say that, the right coastline is given by the tiles extracted from Scenery FG0.9.8. Scenery V1.0.0 has been built using VMAP0 landmass and shoreline data. But: Our data never was accurate and probably never will be. Even the more accurate GSHHS data places LFMN in the ocean - at least in parts. The same goes for treasure island. If you want to, you can have a look at the data in the database at http://mapserver.flightgear.org/ The data used for this build is in the v0_* layers. BTW: We are working on importing current GSHHS data (version 1.5 instead of 1.3 as currently in the DB), but it's not available as Shapefiles anymore. Slowly but surely wins the race... So the inaccuracies in the shoreline are _not_ caused by our algorithmic changes. However, the faulty tiles - tiles which should show only ground where there should be ocean as well - are bugs, not inaccuracies. They are probably specific bugs, as TerraGear does show them from time to time, caused often by subtleties in the input data, relating to floating point accuracy or similar. For example, genapts has a nudge option by which you can nudge the airport layouts by a few centimeters. Often this is enough to make the difference between a failed tile and a successful tile, although it doesn't make much difference in the visual results. This should show you how sensitive TerraGear can be at times. I am tracking these faults down. I have checked the results of the modified code on the tile Gerard reported and it seems that the faults do not originate there. Note that most of my modifications were necessary to get TerraGear to even build some tiles. I replaced some complex algorithms by simpler ones, which should essentially be more robust than their predecessors. I am as disappointed as you are about these faulty tiles, specifically as Martin and I have spent a lot of effort to avoid faulty tiles slipping into the scenery. Yet I hope that we can refrain from yelling and keep the discussion constructive. I am interested in reports about straight ground tiles in the ocean or in lakes, as Gerard reported in his original mail: http://pagesperso-orange.fr/GRTux/Scenery-1.0.jpg It would be great if you could send me an exact position which is _inside_ the faulty tile. But I at least need general instructions on how to find the place. Maybe there's a pattern in these bugs which might help me trace it down, but maybe the Nice area is a singularity. These are actual bugs and therefore are my priority. Once I have tracked them down and fixed TerraGear, I will try to provide replacement tiles for them. The inaccuracies are unfortunate, but I can't do much about them before the next scenery rebuild (see my remark about GSHHS v1.5 above). Cheers, Ralf -- Ralf Gerlich Diplom-Informatiker Software Engineer and Technical Consultant Dr. Rainer Gerlich System and Software Engineering Auf dem Ruhbühl 181 | Tel:+49 7545 91 12 58 D-88090 Immenstaad | Fax:+49 7545 91 12 40 Germany | Mobile: +49 178 76 06 129 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hello Gerard! gerard robin wrote: But you understood i was only talking about the coastline near that place. The nice curved shape of the bay which should be here with the little peninsular ground (the name , Antibes , Juan-les-Pins, and two islands Ste Marguerite and St Honoras). Instead of it there is that huge squared ground tile. Exactly that ground-tile problem is what I'm trying to track down. It would be great if you could send me an exact position which is _inside_ the faulty tile. But I at least need general instructions on how to find the place. Maybe there's a pattern in these bugs which might help me trace it down, but maybe the Nice area is a singularity. Not only NICE area, because i found on VHHH ( which is an other place i use to fly over it) some (similar ??) bug. I will try to give you the difference with Snapshots. No snapshot needed, just a position. I need to fetch the relevant tiles from our build machine in San Diego and don't have the whole scenery available locally, so accurate positions for the bug reports would make my work so much easier. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery 1.0.0 coastline is not processed
Hi Gerard! gerard robin wrote: The coastline process is wrong (or not existing) here two snapshot near LFMN -first, that one with scenery 0.9.10 which was partly wrong (0.9.8 was better) http://pagesperso-orange.fr/GRTux/Scenery0.9.10.jpg -second, the same one with scenery 1.0.0 http://pagesperso-orange.fr/GRTux/Scenery-1.0.jpg Hm, we did check a lot of tiles at random for glitches, but these went through our filters. Thank you for the pointer, I will check were this is coming from. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
Hi! Arnt Karlsen wrote: On Tue, 11 Mar 2008 16:51:16 +0100, gerard wrote in message [EMAIL PROTECTED]: h, AS LONG, we have not sea level consistency with OSG sea tiles and sea coastline which makes the the ships flying over. The carriers and others ships are welcome in the the /AI/AIrcraft directory. ..precisely _how_ do we model the sea level surface of water bodies like lakes, sea and the oceans right now??? Lakes, sea and ocean are quite different things. All areas covered by the Landmasss-theme of VMAP0 are subject to SRTM/USGS elevation data, so that most lake elevations are based on this data. TerraGear adjusts the levels of all lake vertices to the same elevation, which is determined as the mean of the original elevation of the lake vertices. IIRC the slope of streams is specifically limited, leading to the typical cut-ins in some situations.in mountaineous regions. Sea and Ocean all have elevation 0 MSL by default, except that the curvature of the earth is typically less accurately modeled than for non-ocean tiles. Originally we had simple quads for all-ocean tiles, but IIRC that has been changed (Tim?) All-Ocean tiles - with some exceptions in the polar area - are generated on the fly by FlightGear. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] LH A320 near crash during crosswind and heavy gust
Hi! Georg Vollnhals wrote: A Lufthansa A 320 touched! the runway with one winglet (damaged) in the final phase of the landing when not only executing a crosswind landing but getting into a heavy unexpected gust. Looks like a horrible situation I would wish never to get into, neither as a pilot nor as a passenger. BTW: is there any possibility to load a special METAR situation into FlightGear? You can use the metar-tool (included in FlightGear) to determine the command line settings based on a METAR message. Is a METAR file of this time (EDDH, Saturday 01.Febr.2008, 14:00) available anywhere? According to http://adds.aviationweather.gov/metars/index.php these were the METARs for EDDH around that time: EDDH 011450Z 29027G40KT 8000 BKN035 07/01 Q0991 TEMPO 30035G55KT EDDH 011420Z 29029G43KT 8000 -SHRA BKN029 07/02 Q0990 TEMPO 30035G55KT EDDH 011350Z 29030G44KT 8000 BKN029 BKN120 07/02 Q0989 TEMPO 30035G55KT 4000 SHRA BKN008 EDDH 011320Z 29029G44KT 8000 -SHRA BKN023 07/03 Q0987 TEMPO 4000 SHRA BKN008 EDDH 011250Z 30030G49KT 8000 FEW015 BKN020 08/04 Q0986 TEMPO 4000 SHRA BKN008 EDDH 011220Z 29028G48KT 9000 -SHRA FEW011 BKN014 07/05 Q0984 TEMPO 29035G55KT 4000 SHRA BKN008 Temporary gusts up to 55 knots...nothing more to say about that... Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
LeeE wrote: Yup - I downloaded lots of SRTM data to play with in GRASS and above/below +/- 60 lat it isn't there. There doesn't seem to be any alternative source of suitable data either so I don't see how FG can cover the poles. FG can cover the poles - and has been doing so for years -, but only in terms of landcover definition, not in terms of elevation. It's not realistic, but the same could be said of using the SRTM data for deserts, which change their shape all the time. I'm sure there are sources for the pole, just with the problem that we can't use them in a legal sense. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Hi! Frederic Bouvier wrote: Selon Curtis Olson : My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. I was thinking about the parameter we pass to Terra to simplify the initial grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with the same number of vertices. Well, from my experience the elevation grid is not the main driver in terms of triangles. In terms of triangles per area, probably the linear features (roads, rivers, railways, etc.) are much more intensive than the basic elevation grid provided by Terra. Further, the width of the tiles is not necessarily proportionally related to the number of triangles, as vegetation and buildup clearly drop in the latitudes farther north and south. If we really can now afford having tiles of different size in terms of linear measure, I would very much favour a regular grid in the latitude-longitude space. That would leave us with only slight changes in SGBucket with only very small adaptations necessary in the rest of the code (FlightGear, TerraGear), assuming that it uses only the interface of SGBucket as it should and not making any further assumptions about its workings. And it would solve the TerraGear neighbour-problems Curt mentioned earlier in the thread. The problems we have regarding the degeneration of quad-tiles at the pole to actually triangular tiles and the fact that the earth surface is sperical and infinite and not flat and finite would remain, but could be worked around much more easily with such a simple and before all consistent grid definition. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Hi! Curtis Olson wrote: On Jan 8, 2008 1:22 AM, Frederic Bouvier wrote: I was thinking about the parameter we pass to Terra to simplify the initial grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with the same number of vertices. Yes, that's a good point, and something definitely to think about if we made such a tile layout switch. So then we should not use geographical coordinates but rather use a mercator projection, assuming the earth is round, such as: y=dlat x=dlon*cos(dlat) and then impose a grid on that. If I understood it correctly, that is what Fred originally wanted to propose. That would give us a grid in which tile widths vary with their actual linear width. There are some problems with that. What comes to my mind first is that tiles would not be rectangular anymore. They would not be in the geographic coordinate system and at least for the border tiles they would not be in the projected coordinate system. This would lead to clipping problems in TerraGear which - if not solved accurately - could lead to z-fighting-problems or gaps at tile borders, if tiles overlap or underlap (is that a word? probably not). Currently we have tile borders that are representable as polygon - more strictly as rectangles - which makes clipping easy. The new tile borders could not be well-approximated using polygons. We could try creating clipping polygons that approximate the borders down to an error of SG_EPSILON, but I'm not sure if that is practicable. The alternative, of using clat, the center latitude of a tile ring as follows y=dlat x=dlon*cos(clat) would give us rectangular tiles at least in geographic coordinates, but would also lead us to the same problem Curt already mentioned: Curtis Olson wrote: The big problem with the current system is that at every latitude boundary where the number of tile subdivisions changes per degree, we have ugly gaps because the tile edge matching code simply can't account for 2 tiles matching up to 1 tile ... an oversight in the original scheme. The alternative would be to scale the number of vertices passed to TerraFit by cos(lat)... Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Ralf Gerlich wrote: Currently we have tile borders that are representable as polygon - more strictly as rectangles - which makes clipping easy. The new tile borders could not be well-approximated using polygons. We could try creating clipping polygons that approximate the borders down to an error of SG_EPSILON, but I'm not sure if that is practicable. We could also define the tiles to be non-rectangular, but - as Lee mentioned - trapezoidal resp. as triangular. The width of the northern edge would be cos(nlat) and the width of the southern edge would be cos(slat), with nlat being the northern latitude of the tile and slat being the southern latitude of the tile. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Frederic Bouvier wrote: Selon Ralf Gerlich : The alternative would be to scale the number of vertices passed to TerraFit by cos(lat)... I was thinking of this solution : regular lon/lat tile scheme but variable number of resulting vertices per tile. That's what I meant ;-) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi! LeeE wrote: I think I mentioned earlier, but first problem - there's no SRTM data for the poles. Second problem is that calculations that assume a quad (trapezoidal) area fail at the poles because they have to deal with a tri area and not a quad area. The problem is not that tiles are interpreted as rectangular in the latitude-longitude system if interpreted cartesic, but instead that the tile grid is inconsistent even without the problems of representing spherical coordinates in a planar system. While what you describe are problems (e.g. I had to remove an airport located at one of the poles because it gave TerraGear a hard time wrapping it around the world), they do not apply for the specific bug mentioned here. BTW: The .btg.gz-files use geocentric cartesian coordinates, so that the earth is actually round and closed in the scenery. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Hi again!
Thinking a bit more about it, the grid could be made consistent if we
would define that 180W and 180E are tile borders instead of enforcing
the Greenwich Meridian to be a tile border at all ranges of latitude.
Find attached my proposed patch.
That would change the arrangement of tiles between 88 and 89 degrees
latitude, fix the inconsistency above 89 degrees latitude, but would
leave the rest of the tile numbers as they are (due to the fact that
tile widths there are divisors of 180) and give us the following benefits:
1) calculation of base longitude would be much easier:
base_lat=(int)((int)((lat+180)/span)*span)-180
with rounding:
base_lat=(int)((int)((lat+SG_EPSILON+180)/span)*span)-180
2) The tiles at 180W/E between 88 and 89 degrees of latitude would not
overlap with their neighbours anymore and have 8 degrees width, as all
the other tiles at that latitude.
3) The calculation above would always lead to 0 as base longitude for
the tiles above latitudes of 89 degrees instead of the flipping of -180
vs 0 depending on the sign of the longitude.
The fact that people seldomly fly north or south of 88 degrees latitude
might be seen as an argument in favour or against this change.
This is a bug that has not created serious problems in FlightGear
itself, but formally, it is a bug and it _has_ created problems in at
least two scenery-related applications, one of them being TerraGear.
Therefore I would vote in favour of such a change.
Any other comments or votes?
Cheers,
Ralf
From 4462aa3518b65ed76b6fc8a4cabae730fcd160fa Mon Sep 17 00:00:00 2001
From: Ralf Gerlich [EMAIL PROTECTED]
Date: Mon, 7 Jan 2008 12:03:44 +0100
Subject: [PATCH] Make the tile grid consistent.
This changes the actual tile numbering only in the range above 88 degrees latitude and fixes inconsistencies in other areas.
---
simgear/bucket/newbucket.cxx | 46 -
1 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/simgear/bucket/newbucket.cxx b/simgear/bucket/newbucket.cxx
index 71c0ac2..9135f24 100644
--- a/simgear/bucket/newbucket.cxx
+++ b/simgear/bucket/newbucket.cxx
@@ -88,48 +88,12 @@ void SGBucket::set_bucket( double dlon, double dlat ) {
// latitude first
//
double span = sg_bucket_span( dlat );
-double diff = dlon - (double)(int)dlon;
-
-// cout diff = diffspan = span endl;
-
-if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)dlon;
-} else {
- lon = (int)dlon - 1;
-}
-
-// find subdivision or super lon if needed
-if ( span SG_EPSILON ) {
- // polar cap
- lon = 0;
- x = 0;
-} else if ( span = 1.0 ) {
- x = (int)((dlon - lon) / span);
-} else {
- if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)( (int)(lon / span) * span);
- } else {
- // cout lon = lon
- // tmp = (int)((lon-1) / span) endl;
- lon = (int)( (int)((lon + 1) / span) * span - span);
- if ( lon -180 ) {
- lon = -180;
- }
- }
- x = 0;
-}
-
-//
-// then latitude
-//
-diff = dlat - (double)(int)dlat;
+
+lon=(int)((int)((dlon+180+SG_EPSILON)/span)*span)-180;
+x=(int)((dlon-lon)/span);
-if ( (dlat = 0) || (fabs(diff) SG_EPSILON) ) {
- lat = (int)dlat;
-} else {
- lat = (int)dlat - 1;
-}
-y = (int)((dlat - lat) * 8);
+lat=(int)((int)((dlat+90+SG_EPSILON)/SG_BUCKET_SPAN)*SG_BUCKET_SPAN)-90;
+y=(int)((dlat-lat)/SG_BUCKET_SPAN);
}
--
1.5.3.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi Christian! Christian Buchner wrote: I found another slight discrepancy when converting back each tile's geodetic center coordinate to a bucket - this function might be slightly buggy: In a few cases it returns a different bucket number than given by the original file name of the tile. I can work around this problem, but I wonder if other parts of FlightGear might be affected by this bug. I was just about to write a bug report about the same thing when I found and reread your mail. I came across this problem with the current scenery rebuild. Interestingy the first run went without mostly no problem, but the second run - initiated as Curt was missing some settlements - brought up many failing tiles in the pole regions, due to faulty tile indices used for location of shared edge elevation data. I investigated further and there might be a connection to the missing poles problem Torsten reported some time ago. The set_bucket()-function will calculate different tile numbers for the poles - even though the pole (180W,89N to 180E,90N) should be one tile - depending on whether you are on the western or the eastern hemisphere. This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). Also the westmost tile on the tiles between 88 and 89 deg latitude is 8 degrees wide according to sg_bucket_span(), but starts at -180, which is not divisible by 8. This means that e.g. 176W, 88.5N is both on a tile starting at 180W and at 174W. I was able to correct most of the inconsistencies without regression (tested using random testing and 1.000.000 testcases, but verifiable formally as well, I think), and I even introduced special-case handling for the 180W-tile at 88-89 deg latitude. Regression here means that for the positions tested both the old and the new code report the same tile index. The part for the poles (above 89 deg latitude) cannot be fixed without regression, as depending on the longitude (western or eastern) the old code reports different tile numbers, while it should not. This might affect several applications, among them reading of scenery and placement of objects, due to the differing tile numbers. This is grid system has been in existence since at least September 2002, as this is the date when the CVS for SimGear 0.3 started. We will not get rid of that problem without lots of special case handling or some flag day after which the old tile numbers will not be valid anymore. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi again! Ralf Gerlich wrote: This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). The problem only occurs for latitudes north of 83N or south of 83S western longitudes. Only here the longitudinal span of buckets is above 1.0 and always divisible by 2, so that the center of a bucket always lies on an integral longitude. This leads to the fabs(diff)SG_EPSILON condition in newbucket.cxx:109 to evaluate to true and therefore activates the wrong calculation. Casting to (int) always rounds towards zero, which in this case leads to the base longitude being shifted eastwards by one span. In case of latitudes north of 89N or south of 89S non-western longitudes (=0) will lead to a base longitude of 0, while western longitudes will lead to a base longitude of -180. This means that the single tiles surrounding the polar caps (width 360 degree, height 1/8 degree) essentially have different tile numbers depending on whether one is coming from an eastern or a western latitude. This might also explain the missing northpole-problem reported by Torsten Dreyer some time ago. Another possibility would be that Curt's last build failed in a similar way as ours did and there are not northpole tiles ;-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vmap0 Data
Hi Will! will Pink wrote: VPFBASE points to /stage/fgfs01/curt/RawData/Collections/VPF-Extracted You need to point that variable to the place where you extracted your VPF-data. The script expects the parts for the different regions in the subdirectories noamer, eurnasia, soamafr, and sasaus of the VPFBASE-directory. If you do not have all regions, change the REGIONS variable to list the names of the regions you have. Cheers, Ralf - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Airports apt.dat.gz,1.7,1.8
Hi Arvid! AnMaster wrote: Durk Talsma wrote: My understanding is that a full world-wide scenery rebuild is taking place right now, courtesy of the Custom Scenery Project. The purpose of the rebuild is mainly to incorporate the latest apt.dat modifications and the latest commits to the object database. Resolution of the scenery should be approximately the same as the current scenery, but using the latest improvements to terragear, recently made by Ralf Gerlich. Nice. Where can I get this scenery? As I run a terrasync mirror I need to be able to download it to the server before the release to avoid problems. I guess I would need about a day or so to download the new scenery to the server. Martin and I have been working late since Wednesday to get that build going. It's the first time that we're doing this so we have no idea how long it is going to take, but we'll do our best to get it done on time. The process is running now and it's done when it's done. Cheers, Ralf - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
Hi Gerard! gerard robin wrote: Thanks , but NO Catalina and Blackbird are on only under construction. There is a lot of stuff to do , cockpit and FDM (mainly Blackbird which is wrong), My to do list is long like the bible :) Nothing valuable to be released Production Just today I had a (first) closer look at the models of the Catalina, trying to figure out what you are doing differently than me so that your models look so fine. I would be a lucky guy if my modelling skills were so good that I could imagine potential for improvement in these models, implying that _these_ models are not yet Production status ;-) Yes, I saw you were talking about the cockpit and the FDM, not the models, but I just wanted to get this item of well done to Gerard! off my TODO-List ;-) Cheers, Ralf - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
Ralf Gerlich wrote: It's probably a good idea to note here that Mathias Fröhlich's OpenFDM is based on such a multibody concept. http://openfdm.berlios.net/ Sorry, don't know how I got to that URL. That's http://developer.berlios.de/projects/openfdm/ of course. Cheers, Ralf - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
STenyaK (Bruno Gonzalez) wrote: I'm not familiar with the suspension geometry of planes, but i *guess* it can be modelled as a series of bodies, joints, springs and dampers, together with the tire model. [SNIP] You simply simulate a couple of bodies linked together through joints, and the springs and dampers must be present too (depends on the physics engine of choice, the spring rates and dampening values are part of the joints properties, or a separate entity). As for the tires, that's probably the biggest issue i'll have to deal with in my simulator, but i think a simple approximation will be enough for plane landings. It's probably a good idea to note here that Mathias Fröhlich's OpenFDM is based on such a multibody concept. http://openfdm.berlios.net/ Cheers, Ralf - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Preparing the vmap0 Data / TerraGear
Hi Will, I'm sorry, but I have no idea where this may be coming from. Maybe David Megginson can help. AFAIK he's the original author of the tgvpf stuff. Cheers, Ralf When I try prepare the vmap0 data with the following command - tgvpf --chunk=w080n40 --work-dir=LandMass --area=Default /vmaplv0-location/ noamer bnd polbnda It returns the following error - processing failed with VPF exception: failed to open VPF table file /usr/local/src/Scenery/data/vmap0/vmaplv0/noamer/bnd/g/k/fbr - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM gets a discussion page on the wiki
Hello Holger! Holger Wirtz wrote: 3.) as in real life there should be a mechanism for realising crosstalking (e.g. the sender with the maximum of output pushes other senders in the background) crosstalking in real-life more often happens to create interference which punishes those listening for wearing headsets (people tell me these things are there for protecting your ears ;-) Please note -- Im used to hearing ATC chatter in the UK --probably a LOT different in the rest of Europe and the US. I don't know how the ATC chatter we have sounds to the rest of you guys both in terms of content and quality. I tried to follow some web ATC streams and I udnerstand nearly nothing - especially the pilots are very difficult to understand. :-) As a VFR pilot I'm mostly used to German and English VFR chatter and don't typically hang out on radar frequencies or the likes. The FlightGear ATC chatter is almost incomprehensible to me, mainly due to the speed... After all, VFR is typically the domain of leasure time pilots, and most of them don't generally practice their speed or even the coherence of their radio skills daily. For some of them, FGCOM might change this... ;-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANNOUNCEMENT] TerraGear-fork GIT repository
Hello all, I just wanted to let all of you know that a read-only GIT repository of the TerraGear fork is now available unter http://mapserver.flightgear.org/git/terragear/. A gitweb environment for browsing online is to be found at http://mapserver.flightgear.org/git/ Thanks to Martin Spott for setup and maintenance :-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Preparing the vmap0 Data / TerraGear
Hi Will! It's been a long time since I've been working with VMAP0 in VPF. Have you checked whether the file exists at all and whether you can access it directly (permissions)? I can find two places in the sourcecode where a VPF table file named fbr is opened. In both cases it should have a tileref-component in its path, so I'm a bit lost here. will Pink wrote: tgvpf --chunk=w080n40 --work-dir=LandMass --area=Default /vmaplv0-location/ noamer bnd polbnda It returns the following error - processing failed with VPF exception: failed to open VPF table file /usr/local/src/Scenery/data/vmap0/vmaplv0/noamer/bnd/g/k/fbr Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in SGBinObject write_bin() function?
Hi Christian! Christian Buchner wrote: This code loads the largest (non-airport) BTG file from the World scenery disk 1 (mounted on drive S: on Windows) and tries to save it back. I don't have that disk, but I downloaded the respective chunk from the FlightGear scenery download site to try and reproduce the problem. I'll try it with the respective tile from that download and if I can't reproduce it, we'll compare hashes or somebody will have to send me that tile. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
Hi! Melchior FRANZ wrote: (2) I'd say that we want to keep the power of XML defined bindings (with embedded Nasal where appropriate.) But one could think about not having those automatically triggered, but read them into a map, and let the keys trigger such bindings by name. That way one could assign bindings in a dialog. (Personally, I don't like this type of configuration at all. It's not nearly as flexible as editing the XML file, and one doesn't configure the keyboard often, especially if the defaults are sane. This is just a lot of bloat and complexity for a feature that isn't needed at runtime at all.) Hm, wouldn't that - in UNIX manner - call for an external configuration tool to edit the XML bindings? I'm putting this here without ever having thought of who would actually take the effort ;-) It's not unreasonable to assume that such a solution would require more effort than modifying the keyboard binding mechanism as you suggested. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New fgfs-builder release; forking TerraGear
Hello! As there have been commits on TerraGear CVS I had to update the Custom Scenery patches, so therefore there is a new fgfs-builder release. This release is currently only available as a tar-ball from ftp://ftp.uni-duisburg.de/FlightGear/Misc_rag/fgfs-builder Note that this also includes several patches to TerraGear, some of which are build fixes, but also additions of tools such as ogrdecode and modifications to shape-decode. A tool for using DEM data in any GDAL-readable format called gdalchop is currently under development and will serve to allow using e.g. the CGIAR preprocessed SRTM data, which is delivered as GeoTIFF (with some unfortunate properties regarding the tiling). I had already submitted these patches to Curt, but it seems that within about 8 months there hasn't been a single slot of time in which he was able to review them. As I don't have access to TerraGear CVS and probably won't get any in the near future, I have switched to managing my additions locally with git, following the examples of others here on the list (Pigeon, John, Hans Fugal, ...). Keeping the patches up to date to CVS without having access to a proper VCS would become a PITA otherwise. Note that Custom Scenery also wants to go further on development and enhancement of TerraGear. We will synchronise with the official TerraGear CVS regularly and provided that acceptance of our patches is probable we will submit our changes back. However, given the past history of our submissions and the consistent refusal by Curt to give at least one of the team CVS write-access to make use of the VCS facilities (e.g. going out on a development branch), we now plan to actively fork TerraGear. This does not mean that additions and large changes may happen soon, but it just relieves us of an important management burden for bringing TerraGear forward and it should relieve Curt of our constant nagging. ;-) Just to clarify once more, in case it wasn't clear already: There is no bad mood behind this mail at all. We just want to move on. TerraGear is being criticized for its current state and to a large extent that criticism is justified. We would like to try enhancing it and making it more useable. A proper development environment is one requirement for the work that is ahead of us and while we would have liked to have done that within the already pretty sparsely used facilities, time has shown that it will not be possible so we're only creating a proper platform for our work. We are not breaking up with FlightGear, quite to the contrary. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New fgfs-builder release; forking TerraGear
Hi! Heiko Schulz wrote: Nice to hear! So the developement goes on? So it get's more userfriendly, and more independant of the platform? We don't have a development plan yet. There are some things we'd like to adress in the near future such as interfacing to GDAL and OGR, but there are some more things on our mind that we might start working on. Essentially the basic workflow of TerraGear will probably stay the same due to the possibility of parallelisation for automatic scenery building, but we'll probably need some more finetuned interface if we want to implement instantaneous and local scenery rebuilds from mapserver.flightgear.org on submission of new local data. I hope there is will be a healthy competeion between terragear and fgsd! As far as I view the relationship between fgsd they are more complementary than competitors. TerraGear is clearly better suited for automatic rebuilding as we will need it based on the scenery database, while fgsd is more suited for local work. So we will clearly not focus our work on competing with fgsd. I have to stress that there might not be big movement straight ahead, but currently I have some spare time to work on some TerraGear extensions, so it was the time to establish the work environment. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New fgfs-builder release; forking TerraGear
Hi Melchior! Melchior FRANZ wrote: Maybe you don't want CVS access anymore, after you have dived into git, but I think you should have access to TerraGear, and maintain an alternative branch there. The main branch is a sensible area, and I understand why Curt is conservative here. I do understand Curt's point of view. It all started with the notion that git would be a good idea to use for managing my stuff outside CVS... It's not that you aren't trusted or deemed competent -- quite on the contrary --, but not all of your goals might be project goals yet. It looks like you aim for maximum quality and resolution, ...but then we realised exactly that we have possibly different aims. In principle this is a fork of course, but it also is a way to establish a good technical environment for our development. I have grown quite fond of git already. ;-) and I sure would like to have that too. But I tried your Bodensee tiles. Once or twice, and then never again. They made my machine crawl. If that became default fgfs scenery, then I'd have to leave the project (or ask people to donate a good machine). Oh, we know that problem and it's one of our many issues we are working on. But as you might know from 3D-modelling it's often easier to use more triangles than less. Most of that btw comes from the high additional triangles from the line data. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear terrain engine
Hi! Georg Vollnhals wrote: Hi Ralf, you know yourself how much I appreciate your work and like the output - just remember my words about the Berlin terrain in the GFF. The aim of this project is to enhance the local scenery worldwide automatically by scanning the LS7 stuff. This worldwide automatically = press the button I'll do the rest is really far from working as you describe yourself. Actually there is a lot of knowledge necessary to do the work and even if Martin will finish his part you have to go through the training process for every LS7 picture as far as I understood all. Well, if you raise the bar that high, _all_ efforts of improving world scenery are far from working, including e.g. OpenStreetMap - and will be forever. Our job is to enable users to use the methods or synthesis of methods we developed. We will use these ourselves to improve scenery in some areas, but we can't do everything and it is clearly not the intention of our project to get all the data automatically, because this is comprehensibly not possible. submit that to the service again and retrieve automatically classified vector data I doubt that this will help most of the scenery-developers/users as long as you cannot process these data due to that cannot compile, cannot use TerraGear problem. Well, this is something to tackle, but it is not and never was a goal of the Automatic Landcover Classification Project to make a new TerraGear or to improve its handling. It _is_ part of the mission of the Custom Scenery Project, but that clearly doesn't add anything to your claim that the classification concept would be far! from working. I have brought the fgfs-builder to attention multiple times and I have mentioned that it downloads and compiles the problematic dependencies of TerraGear as well. I created the fgfs-builder because I had problems with compiling TerraGear and the required stuff at the beginning myself, and I am using it regularly without many problems. Up to now I haven't received any feedback on that part, so either nobody has tried it, nobody has had any problems compiling TerraGear or nobody bothered to report their problems. I know that it probably won't work out of the box on Cygwin or similar, but I can't do everything at once, similar to everybody else here. BTW: the fgfs-builder SVN repository has moved to http://svn.community.therosconsulting.com/fgfsbuilder/. Many Thanks to Douglas Campos for hosting it! I also prepared a new tarball of the current version at ftp://ftp.uni-duisburg.de/FlightGear/Misc_rag/fgfs-builder Some weeks ago I nearly had a full new tutorial for building scenery with TerraGear done, including current datasources, current preparation tools (e.g. the shape-decoder) etc. An unfortunate slip ruined that work and up to now I didn't have the time to re-establish that part and it will stay that way for at least one further week. The intention of the scenery database is similar to that of the scenery object database: We want to collect customised landcover and linear feature data at a central point, were we can integrate multiple sources (e.g. OSM, TIGER, Canada Road Map) and from which we can automatically, regularly and much more often than currently generate scenery. When you submit a change in the data - e.g. by using Landsat imagery of your region, providing training data, checking the classification results returned to you and submitting them after correction - the change will be visible shortly in the next scenery build. For that we already got TerraGear running on the OSGeo machine that currently hosts the FlightGear mapserver (which makes it possible to get the data out of the database without having to go via possibly errorprone network connections). The problems you mentioned are applicable to _all_ such activities and I would call it unfair to attribute this specifically to a single project. I will now get back to more productive activities so that my schedule won't get any more worse, pushing back any activities for FlightGear further. I hope that I was successful in clarifying that the application of automatic classification is nothing that we will only see in the far future, as you implied, but it _is_ working and is near a stage were users will actually be able to help improving the database, instead of just looking at the results the project people produced. The only limiting factor right now is the free time of the people doing the work. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear terrain engine
Hello! Georg Vollnhals schrieb: 1. Getting better scenery details for wide areas without buying any data - the Landsat7 project http://www.custom-scenery.org/Building-Scener.331.0.html Here a semi-automatic scanning of prepared Landsat 7 pictures can result into a much more detailed scenery. There are two areas available for FlightGear, the Berlin Linuxtag scenery and (as far as I remember) the Bodensee scenery. Although the process of scanning these pictures is not easy due to the low resolution and the software and AI is under development the result was fascinating in my eyes. The aim of this project is to enhance the local scenery worldwide automatically by scanning the LS7 stuff. This is far! from working but a very interesting branch of development. Well, it _is_ working, as you can see from the Custom Scenery examples on http://mapserver.flightgear.org/. The limiting factors currently are the simplification required so the TerraGear and FlightGear don't choke on the load of details we get from the low resolution imagery ;-) , and the second is making the process workable for average Joe User (which is mainly a problem of simplification, as well ;-) ) I have documented the process of classification at http://www.custom-scenery.org/Building-Scener.331.0.html Martin is currently working on trying the process himself and maybe will be able to establish a webservice where users can retrieve parts of the Landsat imagery for their favourite area, produce a training vector map, e.g. using QGIS, submit that to the service again and retrieve automatically classified vector data. He has established close ties with the OSGeo foundation and we are allowed to use some of their topnotch hardware for this task. So, no, this is not far from working. In contrast, we are finally approaching a point where this can be applied generally, and it might be that Seb's work will allow us to use all the detail we can retrieve from Landsat. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery file formats: SRTM elevation data source
Hi David,
TerraGear is really an issue for itself and I up to now have only been
successful building it on Unix systems. AFAIK it is completely missing a
build environment for MS Visual Studio.
David Pérez-Piñar López wrote:
I've been able to successfully build FlightGear without much pain - just
a couple of tweaks, as I'm working on a Windows XP / Visual Studio 2005
Express environment, and everything runs fine.
Great!
However, I've tried also the TerraGear package, a completely different
story. My interest is not just to compile it, but to update my
FlightGear scenery with more accurate data.
I don't think anybody expected you to try compiling TerraGear just for
the fun of it - let alone on a currently unsupported platform. ;-)
I've got elevation data from SRTM Data
(http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp), which gives
you data for a relatively large area into one unique file. It's a very
convenient source, as they have already done the hard work for filling
voids with interpolated elevations. As this is not the same source
TerraGear is programmed for, I was planning to reprogram the file
interface section in order to adapt it to my source.
For importing GeoTIFF'd data I have created a gdalchop utility which
uses GDAL to import elevation data from any format supported by GDAL,
including GeoTIFF. A patch is available from
http://svn.qmx-systems.com/fgfsbuilder/trunk/products/TerraGear/patches/gdal-03gdalchop.patch
It's not yet perfect as it produces artifacts for reasons I do not
understand currently and it's pretty slow due to me doing things a bit
more complicated than necessary (as I found out just recently). I
currently don't have the time and motivation to continue working on it,
but you might find this a good starting point, as an alternative to
Jon's conversion tips.
One of the problems is that the HGT files include data for all the
borders while the CGIAR files only contain data e.g. from 10 deg east to
19 deg 59 min 57 sec east, i.e. the east and north borders are typically
missing. TerraGear, however, requires the tiled elevation files (the
.arr.gz stuff) to include the border data. So merging adjacent CGIAR
tiles might be necessary before conversion.
After several attempts and many hours trying to compile TerraGear,
I have finally made it for the chop utility. However, as the data file
is different from the one used in the original implementation
of hgtchop, I will need to modify the code. For that reason, I ask you
some specific information I'm not able to infere from the code: What is
the size (lat-long) of elevation files generated by the original code?
The elevation files cover exactly one tile. The height of a tile is
always 1/8 degree of latitude and the width in degrees longitude varies
with latitude so that a tile is always about the same width in miles.
See SimGear/simgear/bucket/newbucket.hxx for a definition of
SG_BUCKET_SPAN (height in degrees latitude) and sg_bucket_span() (width
in degrees longitude).
This size must be maintained and the distance of points can be chosen to
be a constant and integral number of arcseconds which is written in the
header of the .arr.gz-file. The code for parsing and writing these files
is in TerraGear/src/Lib/Array/array.{hxx,cxx}
There is no proper documentation that I know of, but the parser and
writer code for the .btg.gz-files can be found in
SimGear/simgear/io/sg_binobj.{hxx,cxx}. However, I suspect that if
you're going for the .btg.gz files directly just because of CGIAR-files,
you might be going a bit over the top.
Cheers,
Ralf
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] And again: VATSIM and FG?
Hi! I have worked previously on a KDE port of the ProController client (now replaced by ASRC) and maybe I'm a bit bitter about my experience at that time. Therefore I'm not trying to give answers here, but just ask some - possibly suggestive ;-) - questions. Holger Wirtz wrote: But they asked me if I want to write something like a VATSIM-proxy for FG to get arround the GPL problem. This proxy has to be closed-source. Hrm, so they are interested in getting FlightGear users into the boat, but they are not willing to open their protocol? How big can that interest in FlightGear users be relative to the interest in keeping their protocol obscured? Might that be some security-by-obscurity thing? Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] And again: VATSIM and FG?
Hi, Jon Stockill wrote: This needs to take into account the platforms that flightgear is used on. If it's closed source then ideally whoever produces the app is going to need the capability to build (at the very minimum) linux, mac, and windows binaries, since handing the source over to someone else to let them build for their own platform isn't an option. Not necessarily. I think, Holger was talking about some kind of proxy server. In terms of server OS, we don't need to be that picky, although I would term it a benefit if the server could be run on all OS' flightgear runs on. Curt, as far as I understood it, VATSIM asked Holger wether he wanted to write such a proxy, which I interpreted as an expression of interest from their side, so I don't think that the interest is single sided. Of course we could benefit from an integration with an already established network with a huge number of participants. My work with the technical staff of the VATSIM network was some time in the past, so maybe something has changed. However, from what I had seen in those days and the fact that the protocol is still closed, I'm a bit suspicious. BTW: I didn't know that VATSIM is commercially dependent on closing down the protocol... I will drop out of the thread here, because this is getting more destructive criticism than I wanted it to become... Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Hi all! Melchior FRANZ wrote: * Vivian Meazza -- 9/3/2007 10:22 AM: That would be 90% of the 10% who aren't Windows users then? Don't forget that by far the majority of our users out there are on Windows, as opposed to the developers for whom the ratio is probably reversed. While I agree with your demand to keep fgfs cross-platform, which is one of its central properties, I don't buy the 90% of the fgfs users are on Windows myth. This is solely based on Curt's download statistics and thus completely flawed. Independent of that it's probably better to have something working for at least one or a few platforms than to have nothing at all. Remember? Don't let the perfect be the enemy of the good. ;-) Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Hi! Melchior FRANZ wrote: * Ralf Gerlich -- 9/3/2007 6:41 PM: Melchior FRANZ wrote: While I agree with your demand to keep fgfs cross-platform, which is one of its central properties, I don't buy the 90% of the fgfs users are on Windows myth. Independent of that it's probably better to have something working for at least one or a few platforms than to have nothing at all. Remember? Huh? I'm actually member of the choir that you are preaching to. As I said: cross-platformness is a major project goal that I fully support. Hrm, I'd probably better kept to my own principles of being exact in e-Mails. Essentially, I only wanted to avoid having a discussion here on what exactly the user-share among the OS's is, because I see it as mostly irrelevant, as long as somebody finally got his/her (Do we have female project members, anyway? ;-) ) guts together and started working. And - of course - the ultimate goal is to be cross-platform, which will make this discussion irrelevant for yet another reason as soon as the module evolves ;-) I'm sorry if I wasn't clear enough on that. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New screen streamer and mpcam
Hi Pigeon, Pigeon wrote: And to just for fun and to show what you can do with the streamer, I've setup an experimental mpcam live camera hooked up with the FGMap. So you can *actually* see them flying side by side to the map. Just goto: http://mpserver02.flightgear.org/?mpcam Then click on the video icon near the top right. You'll need flash support in your web browser. The map will automatically follow whoever the mpcam is targeting. This is great stuff! :-) Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Seasonal AI-Flighplans, AI Dash-8
Hi Durk! Durk Talsma wrote: Currently we don't support for that, but I am currently involved in an offlist discussion on a possible traffic manger version two, which would be a big step toward such flexibility. Currently, a each aircraft has to be assigned a fixed series of flights, whereas the new version flight schedules and aircraft information would be decoupled. This change would probable involve a new input file format, which would be a lot closer to that of actual airline time tables, and would be a lot easier to build than the current ones. Heh, I have built a small Java-Program using the JCHR constraint handling kit which does a similar thing. One can edit schedules in OpenOffice or some other CSV-capable software in a format similar to the actual airline schedules and provide a number of aircraft, which are then scheduled to a series of flights. It's not perfect, but it works. Currently, one has to separate the schedules by aircraft type, but I'll probably get that one fixed as well. With this software we already got the schedule of Intersky complete and EDNY is already busy - if you can say that a regional airport is busy ;-) It just has that unfortunate minor bug that F50s are flying around and noch Dash-8s. ;-) Given a better replacement, I could post the flightplans. Ingrid is working on the Star Alliance Flightplans :-) (no guarantees, however ;-) Sounds good. :-) Yeah, that should provide some more busy skies. But the schedule has I think over 200 pages in small print. We've been searching for a format more suitable for automatic processing, but up to now to no avail. I have just recently received a number of dedicated AI aircraft from Innis Cunningham, which I haven't committed to CVS yet. These include a Bombardier Challenger, a Cessna Citation, a Fairchild Dornier, a Dehavilland Dash-7, an Embaer legacy, an MD80, and an MD90. Sounds great! I'm currently trying to incorporate these aircraft into my test database, and once I have a sufficient number of repaints will commit them to cvs. I'm using some of the businessjets as standins for their regional jet counterparts. As such, I'm currently using the Dash-7 as a stand-in for the Dash-8. Innis indicated working on more aircraft for AI, so hopefully that includes a Dash-8 as well. Go, Innis! ;-) Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Seasonal AI-Flighplans, AI Dash-8
Hi all, is there a possibility to introduce seasonal flightplans for AI aircraft? Most airlines have a winter and a summer schedule, but also some more limited flights which take place only for a few weeks or months. Ingrid is working on the Star Alliance Flightplans :-) (no guarantees, however ;-) BTW: Anybody interested in making an AI-model of a Bombardier Dash 8-300Q (previously DeHavilland Canada)? All aircraft of the InterSky group (stationed at EDNY) are Dash-8. We are currently resorting to a Fokker 50, but that is not a proper replacement in terms of performance. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in JSBSim FGPropeller.cpp
Hans Fugal wrote: Perhaps someone who has flown a counterrotating twin can weigh in. Then Torsten is the right person here. Guess who does fly the real-life counterpart of the Seneca in FlightGear? Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Landsat based scenery requests
Hi there! Harald JOHNSEN wrote: AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm wondering if it is possible to request landsat based scenery of some specific area (like that was done for LinuxTag and EAA Oshkosh), if yes I would like to request such scenery for the area around KSFO. That area looks really bad (with a hill in the middle of the terminal for example. Landsat imagery is used to determine the landclass if I understand well, this won't change the elevation of the terrain. This elevation is allways wrong where you have buildings, the radar that mesures the height can hit the terrain or the roof of a building. I don't know if there are tools to edit this kind of data. The SRTM-data can be imported into GRASS and edited. Export to the HGT format is not available, but I have a tool (which is part of the fgfs-builder) which can process height data in all raster formats supported by GDAL. Alternatively one can convert the current SRTM data to contour lines, which can then be edited using QGIS or similar, and interpolated to a raster height field again. One would need _free_ reference data for appropriately adjusting the elevations, however. Most of all, you need to make sure that the reference data is not just based on SRTM itself (which is true for many modern maps, which again often are not free). Regarding Landsat-based scenery we think that we cannot yet automate the scenery-on-request concept fully, but we could e.g. start with accepting external training data. In the (still incomplete :-/) Landsat scenery-building tutorial[1] I have described how to create training vector maps. Maybe somebody who has a bit of experience with either QGIS or GRASS might want to help us to try and find a workable procedure for generating landsat-based scenery data from externally provided training data. IIRC the default KSFO tiles contain customised scenery in the Alcatraz area. Maybe somebody could tell what exactly was edited there, so we could find out how to integrate that into a possible new landsat-based scenery. Cheers, Ralf [1] http://www.custom-scenery.org/Building-Scener.331.0.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Hi, IIRC you can specify functions (e.g. tables) in JSBSim which are in a first step completely unrelated to lift, drag, sideforce or any of the moments. The files output by DATCOM+ do this for the ground effect by establishing a table of additional coefficients based on the ratio of height AGL and span. These coefficients are then multiplied on the basic lift and drag. Simply place a function outside any of the axis definitions and then use it as a property in your axis functions. An example can be seen in the Seneca-model by Torsten Dreyer: http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/data/Aircraft/SenecaII/SenecaII-jsbsim.xml?content-type=text%2Fplainview=co Search for ground-effect-factor-lift. You could use this to describe the downwash based on the current AoA and whatever is needed in addition. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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/ ___ Flightgear-devel mailing
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Hi! Bohnert Paul wrote: Thanks for rebuilding the Oshkosh tile. This is not only a rebuild, the data is completely different (and more accurate) than what we have in the standard scenery. It also is not only the Oshkosh tile, but it includes 48 tiles around Oshkosh, some of which are not completely covered by new data, though. Also rebuild on the same tile, Appleton, KATW, and Fond du Lac, KFLD. Should be included already. I will try to include the railroads and rivers from TIGER as well. 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
Hi! AnMaster wrote: Very nice, exactly what data is this scenery generated from and why can't it be used for all of flightgear's scenery? In my opinion the current scenery is plain ugly. Some of the information about the data sources can be found on the project homepage: http://www.custom-scenery.org/Oshkosh-Scenery.338.0.html 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. The other part of the data is from the U.S. Census Bureau TIGER dataset, which is highly detailed and accurate, but only available for the US (or even only parts thereof, not sure currently). Also is this scenery being generated for some event (like the linuxtag add on scenery was)? In that case what event exactly? The occasion is that a request was some month ago to rebuild the scenery for the Oshkosh EAA AirVenture, which is to take place next week. We are currently still in a pre-automation stage for the classification methodology. We hope to get series-production running at some point where a set of powerful computers (which will probably be provided by the OSGeo foundation) will perform the classification worldwide, leading to a hopefully complete landuse dataset of the whole world. 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. 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
Hi, AnMaster wrote: So, could scenery be mass generated with this method for all parts of the word it exist for? I understand scenery would be larger but with terrasync I only need to get the part I fly over anyway (for official scenery). The mass generation is our goal, but we are currently still in an experimentation phase. The results, however, seem promising, as can be seen in the Oshkosh scenery and the Berlin scenery. I am also working on a rebirth of the South Germany scenery based on this approach, but as for many contributors here, my time is limited and only sporadically available in the required amounts. ;-) The other part of the data is from the U.S. Census Bureau TIGER dataset, which is highly detailed and accurate, but only available for the US (or even only parts thereof, not sure currently). Ouch, I'm mostly interested in Europe (Sweden mainly). Yeah, that's also our problem... OSGeo? Who are they? http://www.osgeo.org/ It is the Open Source Geospatial Foundation, which organises a lot of different OSS GIS projects as well as efforts to acquire freely available geodata, such as our classification project. Also where can I get the scenery, the link The scenery is available at ftp://ftp.uni-duisburg.de/FlightGear/Misc_rag/scenery/landsat_oshkosh.; redirects to a German page (http://www.uni-duisburg-essen.de/materialtechnik/) that I can't read... :( Ups, sorry, I though I had fixed that. The text gives the correct link and the actual link should be fixed now. 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
[Flightgear-devel] Custom Scenery for EAA Oshkosh
Hi all, I know the AirVenture is less than a week ahead and so I'm probably a bit late, but I have prepared new landcover data for the region around Oshkosh and Lake Winnebago. I hope that Martin will have the TIGER data ready on time so I can integrate that as well, but for now we have only a landcover+airports version available at http://www.custom-scenery.org/Oshkosh-Scenery.338.0.html 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
Hi all! Ralf Gerlich wrote: I hope that Martin will have the TIGER data ready on time The first chunks of that data is available and was integrated into the scenery. Again, available at http://www.custom-scenery.org/Oshkosh-Scenery.338.0.html The result is quite interesting, as obviously highways and similar have actually two separate lanes. Still there are some artefacts obviously introduced by TerraGear's triangle sliver removal code has the surrounding texture leak into the road lines. 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] How to apply different texturing to, the terrain mesh? (addressing especially Tim Moore)
Hello Sebastian! Sebastian Bechtold wrote: Tim Moore wrote: So, I don't mean to be discouraging because I think this is ultimately the right approach in terms of bumping up terrain detail and implementing terrain and texture LOD, but you have a lot of hacking ahead of you. Then it should be so. I'd really like to help making FlightGear better, and of course I want to improve the things which, in my option, need it most. Great to hear that you're so motivated. I hope it stays that way once you have started! ;-) I have to admit that at the moment, I have not the slightest idea about any coordinates and stuff, but I'm willed to learn :). Although I'm a bit skeptical about whether I like the concept at all or not, there's no better way of finding out than trying. ;-) I can assure you that I will provide support to you with everything I learned about scenery design, file formats and coordinate systems in the FlightGear world. I will not be able to assist you much in coding, and specifically not in the area of 3D programming, but I will try to do my very best to help you being successful in the areas I can help with. Sebastian Bechtold wrote: The plan would be to include the raw (meaning not compiled/digested into the .btg files) vector data into a scenery file and auto-generate the textures using this data. The .btg-file-format is not well extensible (and probably will not be needed anymore anyway with your approach), so I wouldn't integrate this data into the btg or stg files. You don't seem to be thinking about something like that anyway, so this is merely a note from my side. 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] How to apply different texturing to, the terrain mesh? (addressing especially Tim Moore)
Hi once more! Ralf Gerlich wrote: I can assure you that I will provide support to you with everything I learned about scenery design, file formats and coordinate systems in the FlightGear world. I will not be able to assist you much in coding, and specifically not in the area of 3D programming, but I will try to do my very best to help you being successful in the areas I can help with. So why not start right now? (forgive me if you already know a lot of the following). So what we have in the database is a logical setup of the terrain data in terms of polygons describing aerial features (forest, town, cities, etc.) in terms of polylines describing linear features (roads, railroads, small streams, etc.) Logical setup means that the data is not yet directly associated with a texture or in case of linear features also with a width, but this is typically done when extracting the data from the database and converting it to a TerraGear-friendly format in the TerraGear working directory. So the actual association of type of landcover and a texture is established by the script that does the conversion. Instead of converting the data to a TerraGear working directory it would be possible to convert it to a file format useable by your scenery engine, in which the polygons and lines would be associated with a display type defining texture and markings, and in case of the lines also with a width. The positions in the database are in WGS84 format, i.e. in geodesic coordinates according to the WGS84 ellipsoid approximation of the earth's surface. You can use the functions in simgear/math/SGGeodesy.hxx to convert these to cartesian coordinates. These functions are, however, a bit computationally expensive - at least when used hundreds or thousands of times per frame - so a pre-calculation of the actual cartesian coordinates used for display would be a good idea. The cartesian coordinates are used to actually model the earth as a round shape instead of a flat shape in display space, which makes things a lot easier (latitude-longitude wrap-around) and also more realistic (ever seen the curvature of the earth from high above?) The other data you will probably need is the elevation data. Most of the elevation data we have is from SRTM, the Shuttle Radar Topography Mission. The data consists of raster files in different formats, a non-standard format named HGT and as GeoTIFF. We can of course make this available in a suitable raw binary format. As I have some experience in working with all that data and the formats, I could write the conversion tools. We'd just have to agree on a format for the files. 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] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Hi! Harald JOHNSEN wrote: The point 1) will give worse ground texture than today if we set the texture size at 4090^2. Not necessarily. Currently we have the same basic texture resolution everywhere. With the approach Sebastian wants to try one could use tiles of different sizes depending on the distance from the viewer. Which may or may not be a good thing but we won't know until somebody tries. The point 2) is better except that this 100 pixel border is arbitrary. Sometimes it will be ok but i'm afraid there is some triangles that will go very far inside adjacent texture (some sea triangles inside the bay are very long for example). There won't be triangles oriented along the bay. If I understood Stefan right, there will be a regular triangle grid depicting the elevation structure and the borders between different regions will be depicted by a change in the master texture. But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). Exactly. The question that comes to mind is whether OpenSceneGraph does not already have support for such a thing. The applications of OSG I have seen seem all to use this concept so maybe it is reasonable to believe s.th. like that has been included in OSG? Mathias? As I said I'm skeptical about the outcome, but I would say it's worth a try. Sebastian seems to be committed, so why not? 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] Today's CVS
Hi! Thomas Förster wrote: The reason is a wrong return type on FGAirport::getId(). Should be const string instead of string (which does a local copy that is then referenced in FGAirportDynamics::getId()) Maybe that's a dumb question (which would be embarassing, because I typically think of myself as a good C++ programmer), but why use a reference in the return type anyway instead of the real thing? If a copy is created anyway, the doesn't have any advantage, or am I missing something? const string would only make sense if a string was returned which is typically stored in the object and should _not_ be copied, e.g. in a getter-method. Am I missing something? 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] How to apply different texturing to the terrain mesh?
Hello Sebastian! Sebastian Bechtold wrote: [...] but my plan would, for example, make it possible to render markings onto them, or draw softly rounded curves. I'm specifically interested in the markings part (although I'm also curious at how you want to implement softly rounded curves without breaking the current concept of texture display). This might require information which is currently not in the scenery files, such as the actual position of the centerline and width of the linear features. The triangles don't represent this information anymore, however it is available from the scenery sources (e.g. the scenery database). In general, making this information available in a suitable format shouldn't be a technical problem (maybe one of available manpower for implementing the stuff required, but that only means that it may take longer). Another possibility - at least for simple roads - would be to add a centerline to the road texture and make TerraGear create an appropriate texture mapping similar to how it is done currently in genapts for the taxiways. Unfortunately, the part of TerraGear which creates the texture coordinates does not know anymore that the polygon it is currently operating on originally was a linear feature (blown up according to its width to a polygon). So this approach might require some reorganisation of the TerraGear architecture. Given that the current architecture is quite complex (mainly due to the fact that the task at hand is complex) I don't think this is feasible without risking to break anything to a larger extent. When we're discussing about runtime creation of textures we might also get into discussing blending of ground textures. In that case, we should keep in mind that in reality not all types of landcovers actually blend into each other. When flying overhead forest areas - especially dense forest - these typically do not blend with surrounding agricultural or greenland areas, at least not in civilised areas where man tends to create sharp corners by land usage. That's actually not related to this specific discussion, but I wanted to note that before I forget. 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] Today's CVS
Ralf Gerlich wrote: const string would only make sense if a string was returned which is typically stored in the object and should _not_ be copied, e.g. in a getter-method. Or rather: I was wondering why a getter method would have to return a reference to a local variable, until I looked at the source code properly and found out that this thing is actually delegating the call to FGAirport, in which getId() returns a simple string. So maybe it would also be a good idea to have that return const string as well. Might save a few copying operations (even though FGAirport::getId is probably inlined anyway in most cases, just not here due to the delegation). I consider this const T thing good practice if all you want is read only access to a member variable via a getter method and the type of the member might otherwise require copies to be created. 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
