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=100&url=/ ___ 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)
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=100&url=/ ___ 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)
Hi Curt! The World Custom Scenery Team has decided - already some time ago - that the scenery release intended for shipping with the planned FlightGear release in December will be the _last_ scenery release produced by the World Custom Scenery Team that is synchronized with the Base Package apt.dat. This step is taken for reasons we had already explained and which are otherwise will be seriously obstructing the advancement of the World Scenery. Therefore we designed and proposed an alternative scheme suitable for proper inclusion with the scenery itself, allowing fast lookup of airport data both by geographic location and by airport-ID. This scheme was presented to the concerned developers long ahead of time, including Curt. If anyone of you has a proposal that fits the mentioned purpose better, then come forward _and_ implement that concept. We uphold our proposal and will provide the data in that form. Curtis Olson wrote: > Is there a reason that we split up each airport's data into at least 5 > different files? There is reason to separate the pure airport geometry data from the AI-network. Those come from different sources and are maintained differently: one part automatically generated from apt.dat, the other is manually created using TaxiDraw. My _personal_ view is that the data coming from the apt.dat could be merged into one XML-file. This point was already discussed. There is also reason to split the data up into one airport per file to allow fast lookup by airport-ID. > Right now, Martin's proposal uses path/file extension > another extension. That is the main thing that jumps out at me as being > unappealing. I have already provided the arguments in favour of the three-level hierarchy. > One issue to consider is that on windows file systems, the minimum block > size is usually really big, so tons of little files really burns up and > wasted disk space. Due to the splitting, each user only downloads those airport-data files that are related to the scenery area downloaded. So in fact only those people will see an notable increase in disk size who already accept the disk usage of larger scenery areas. Others will probably only notice being spared the load of apt.dat.gz In a similar way, this applies to the .stg-files as well. Still I don't see anyone having objected to this aspect of scenery organisation _for years_ and having provided and implemented a different concept. Again: If anyone has a better proposal than the one provided by us, present and implement it. 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=100&url=/ ___ 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)
autiful. Again: Not that beauty would mean anything in this context and not that the naming is actually relevant for the structure. To conclude: Part of your proposal does contradict the intent of the structure. In the places where it doesn't - only the names of the XML-files -, your proposal is not superior to ours and the arguments for a change are therefore not sufficient. Therefore no change towards your proposal in your "final comparison" is warranted. I also see no further benefit or reason in letting myself being mocked or talked down upon by you, so the discussion 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=100&url=/ ___ 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! Melchior FRANZ wrote: > * Ralf Gerlich -- 11/1/2008 7:35 PM: >> Melchior FRANZ wrote: >> 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. > > Err ... everything, even the ugly: Airports/K/S/F/KSFO.whatever.xml? > I *hate* that! So may I subsume that you have no _technical_ argument against the proposal? This was not a "take it or leave it" proposal, but rather I expected technical arguments. You did not provide any, but instead asked for cosmetical changes. 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=5&t=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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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 Curt! Curtis Olson wrote: > As far as I know, terragear doesn't do extra edge splitting before handing > data to TriangleJRS. Sorry to correct you, but in Triangle::build() the segment lists are built using TGTriSegments::unique_divide_and_add(), which does segment splitting if TerraGear thinks that one of the end-nodes lies on an already known edge. These checks seem to be less exact than the predicates used by TriangleJRS ;-) 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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 Curt! Curtis Olson wrote: > It's been a long time but I believe the original intent of the code is that > precision and non-precision runways should have threshold markings, while > visual runways should not have them. By my best recollection, this is how > the code was designed and by my reading of the code, that is the way it > still works. OK, maybe I misread the code. Wouldn't lines 216-236 in rwy_visual.cxx generate a small threshold marking? Would that be 14ft in length (from 14/length)? I haven't checked this on any specific airport, but I looked into the code due to Martin's question (top of this thread) about the markings included in the "Visual" marking type. 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=100&url=/ ___ 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 Curt! Curtis Olson wrote: > On Wed, Jul 16, 2008 at 10:52 AM, Ralf Gerlich wrote: >> Curt, did I miss anything, or why are the threshold markings included in >> visual markings for genapts? > I'm not familiar with taxidraw myself, so I'm not sure I understand your > question. No, the question is not really about taxidraw, but about genapts. It seems like genapts adds threshold markings (e.g. pa_threshold.rgb) to runways, which according apt.dat should have only visual markings. According to FAA AC 150/5340-1H (which is mentioned in rwy_visual.cxx), visual markings do not include threshold markings. According to that same sourcefile, you are the author of these functions. Did I miss something about that AC or is there a specific reason why threshold markings are included nevertheless in gen_visual_rwy? 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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"
Hi! LeeE wrote: > I would argue that we need to keep track of copyright issues because > all of the FG aircraft and their colour schemes, perhaps with the > exclusion of Oleg, are copyrighted and FG has no clear rights to > use them (Oleg's 'components' i.e. the bricks are copyrighted but > the design made out of them isn't). Actually, Oleg's design is > copyrighted but the copyright holder is the person who submitted it > to FG:) I agree. > _We_ are discussing it because _you_ posted a reply to it:) > Otherwise it would have just been me, and I would have probably > soon shut up about it:) So if you don't want to discuss it - > don't post about it:) I asked why we are discussing about the "exhibition" issue instead of the distribution issue. I originally did not reply about "exhibition" stuff, but rather about the "for profit" vs. "in a regular manner" distinction. In general, a discussion about the legal aspects is not very satisfying, except if there would be two lawyers on this list discussing it - which would not be very satisfying as well (two lawyers, three opinions). If I unterstood the text linked by Melchior in his original post correctly, the EFF mainly focuses on the trademark issues of the designs, but not on the copyright issues. Trademark issues might - independently of the problems the EFF is focusing on - be applicable to the liveries. Copyright issues might be applicable to the designs. The best solution would be if we had the written agreement of the respective rights owners. That could clear us from legal issues, independent of whether such issues would arise or not. However, one would have to clarify, who "we" is or who needs the written agreement. To be reasonably sure of what we have to do and what we can do, we'd need a copyright expert (read: an actual lawyer). I am no such expert - although I'd say that I know a good part or two about copyright - and I suspect those taking part in the discussion so far aren't, either. Discussing this among legal laymen is probably no good idea. 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] FYI: "EFF fights for the rights of 3D modellers against bogus trademark claims"
Hi! LeeE wrote: > [...], there should be nothing to prevent a photographer from taking > a photograph of the Eiffel Tower lights and exhibiting it to > others, as long as they don't do so for profit, because it's their > personal view and artistic expression of something they've seen in > the public domain. Typically copyright does not distinguish between "for profit" and "not for profit". The main distinction is what in Germany is called "geschäftsmäßig", which is something like "in a regular manner". Distributing the models in a package for general availability probably falls in this category, whether for profit or not. IANAL. 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
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
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
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
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
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
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
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
Hi Curt! Curtis Olson wrote: > The decision was made to go with vmap0 entirely. We gave up accuracy > around the coast lines, but we gained a much more consistent picture of > the world ... with no major missing bits and no overlapping sections. Thanks for jumping in with that explanation. Anybody interested in details is invited to look at the data available on mapserver.flightgear.org. The database includes both the VMAP0 data and the GSHHS data. You may notice that at some points VMAP0 waterways supposed to flow into the ocean or a lake do not reach the shore as defined by GSHHS. I can imagine the disappointed comments coming up with if we used that set with the next scenery build... ;-) The database gives us the possibility to adjust these points, but it will be a whole lot of work and we first want to get the most current version of GSHHS into the database. 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. To make the long story short: Don't expect GSHHS shorelines consistent with the rest of our data with the next scenery release. 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
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
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
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] trees
Hi there! Today I finally had a chance to try your trees patch. All I can say: Holy s..., this is awesome! 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] 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] 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
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
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
[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 = " << diff << " span = " << 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! 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
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)=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] 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] 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] FlightGear prerelease
Let's see... Durk Talsma wrote: > data/Aircraft/c172 \ data/Aircraft/c172p \ Definitely to be kept, as it is probably _the_ basic plane used in tutorials, also due to it being a pretty well-behaved single piston craft. > data/Aircraft/c310 \ > data/Aircraft/c310u3a \ Can't remember having tried that one, but I could see the Seneca here as well. > data/Aircraft/Citation-Bravo \ Really nice plane, which I use for IFR "training". However, the B1900 might fit here as well, though a different category (prop vs. jet). > data/Aircraft/f16 \ Can't really say much about that one, not my category of aircraft. > data/Aircraft/j3cub \ Definitely keep. It's a good example for a very simple light aircraft and it's lack/shortage of instruments really teaches you to look outside to determine your attitude. It being a light _taildragger_ is also a special in the hangar, AFAIK. > data/Aircraft/Hunter \ > data/Aircraft/p51d \ Same as f16: Can't say much about this one. Although the P51 is a good example for a high performance piston prop warplane (from a historic and technical point of view). Can't say much about the quality though. > data/Aircraft/pa28-161 \ I once tried a well made "pa" from the hangar, but can't remember whether it was the pa28 or the pa24. Also from the "standard light single engine props" category, but probably a bit more complex than the c172. > data/Aircraft/Rascal \ Erm...not really sure about this one. It's pretty much out of the row and I'd rather add the Dragonfly as an example for a microlight. Unfortunately, the latter has only an incomplete panel, so I don't know what to do about that. > data/Aircraft/T38 \ See f16... > data/Aircraft/ufo \ I'd keep that. It doesn't take much space, allows roaming around a bit and provides an easy way to place scenery objects - which of course we want people to do, don't we? ;-) > data/Aircraft/wrightFlyer1903 \ Tried once. Nice from a historic point of view, but not very useful for users. If we had a Ryan NYP, I'd replace it with that for the "history" category, but as we have no NYP, I'd drop it. As was said, we lack a glider with towing capabilities. Although the bocian seems to be popular among fgfs glider pilots, it's pretty large as well (14MB, mostly detailed textures). The ASK21 model looks nice, is towing capable and takes only 3.4MB, so maybe we could include that? 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
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] FlightGear Prerelease 0.9.11 some testresults
AnMaster wrote: > No comments but I think that would be silly, it depends on your date order > anyway... With the Swedish format for date (dd/mm -) it is the other way > around... No one would comment on a possible future 0.11.9 I bet... I pretty much hope we're at 1.x before it comes to that ;-) 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] 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
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] 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] 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] 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
[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] 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/li
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, 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] Linux in real-world aviation
Hi! Durk Talsma wrote: > On Monday 17 September 2007 18:41, Curtis Olson wrote: >> My best guess is a debian derivative, probably stripped down for this >> specific application. I saw the debian penguin come up at the head of the >> console boot messages ... only one penguin so it looks like a single >> processor. I don't know what the actual hardware really is ... I'd be >> surprised if they had one CPU per seat ... maybe they were doing some sort >> of virtualization? Interesting to see. Apparently my seat neighbors were >> not nearly as excited as I was to find out the entertainment system was >> running linux ... :-) > > Funny, I had actually the same experience, on the same aircraft type / > airliner on my last flight back from the US (Detroit - Amsterdam, May 17, > Northwest, A330). The entertainment system crashed midway during a movie, and > spontaneously rebooted, showing the penguin. I don't know whether this should be termed a good thing. Or why should Linux-advocates be proud of their operating system being seen rebooting on two independent instances? ;-) 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] 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] 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] 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%2Fplain&view=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
