Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
* Melchior FRANZ -- Wednesday 05 November 2008: * Curtis Olson -- 11/3/2008 4:46 PM: - If it was me doing this, I would suggest something like: Airports/L/LO/LOX/LOXA.xml (just the one file per airport) As I wrote previously, if we drop the requirement to have separated files per airport, then I'd go with Curt's layout. [...] o merging of PropertyList files from various sources (converted AI files, hand crafted new files etc.): This could easily be done by a little tool that links against libsgprops.a and just does multiple readProperties() followed by a single writeProperties(). Done and committed. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
* Curtis Olson -- 11/3/2008 4:46 PM: - If it was me doing this, I would suggest something like: Airports/L/LO/LOX/LOXA.xml (just the one file per airport) As I wrote previously, if we drop the requirement to have separated files per airport, then I'd go with Curt's layout. Of course, this makes work for the scenery people somewhat harder, but I think we can easily handle that: o conversion of all custom (non-PropertyList-) XML files to PropertyList format. This could easily be done from within FlightGear. A Nasal script (that I would be willing to write) could scan the respective AI/ dirs, suck in each parking.xml etc. file (io.readxml()), do some renaming, and write it out again as PropertyList. (I'd suggest standard property names as much as possible, floating point numbers for coordinates, instead of N48 23.345 format, etc.) If that makes files too big, then we can still consider to use *.xml.gz, though that would make loading slightly slower. The original custom format files would remain and the AI/traffic code would keep using those old files until it has adapted to the new way. Of course, Durk would have a say in that. Finally the old files could be removed. o merging of PropertyList files from various sources (converted AI files, hand crafted new files etc.): This could easily be done by a little tool that links against libsgprops.a and just does multiple readProperties() followed by a single writeProperties(). I would be willing to write that as well (just a few lines -- 30 min job :-). The automated scenery generation process could then do all the merging without much pain. (Maybe a property attribute 'remove=y' would be desirable, so that a PropertyList merge could remove nodes, something that we could also use in 3D animation overlays.) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Hi, * Ralf Gerlich -- 11/3/2008 5:29 PM: why do you take this to the -users list again, where it is obviously off-topic as a development issue and after I had taken the discussion where it belongs: to the -devel list? Sorry, that was an accident. I had intended to stop posting to this fruitless thread and wanted to do that with a final conclusion from my point of view (including technical arguments, which you had totally avoided until then, while demanding them from me). And a conclusion is better on an outer thread level, than nested deeply inside. I don't sort *-devel and *-users to different dirs on this machine, and just thought the duplicate mails would have the usual cause. I responded to the same thread that I had chosen first, and that was the one where others had already posted. So as long as you do not _prove_ us wrong, there is no reason to conclude that our proposal is nonsensical. I will show that what you did is far from proving us wrong. Well, your only argument was too dangerous to change now, which I've debunked later. We just don't use anything of that yet, do we? And who are all those experts, who were also not keen to let us know any of those technical arguments? Sure, I might be wrong in some of mine, and I'm always willing to learn and change my mind. That's what discussion is about. And presenting something as proposal usually means that it's up for debate. It just ended up as a pretty one-sided discussion, with arguments on my side, but none on yours. (Also note that I was fairly friendly at the beginning -- I only became annoyed after my arguments were countered with demanding *more* arguments, rather than dealing with them.) I am full-quoting your mail, so all developers not on the users-list can see what we are talking about. That should be also in your interest, because your and my comments can now be found in additional places, so you and I can occasionally point to it ;-) :-P Airports/L/O/X/LOXA.ils.xml /LOXA.parking.xml /LOXA.rwyuse.xml /LOXA.twr.xml /LOXA.threshold.xml /LOXN.ils.xml /LOXN.parking.xml /LOXN.rwyuse.xml /LOXN.twr.xml /LOXN.threshold.xml Also note that three letters of this prefix are identical and thus redundant, and that there are several files with long names that differ only in one letter somewhere in-between. Add this to my technical arguments. Call it non-technical, if you want. :-) Your personal taste is not in itself a sufficient argument for a change in this context. Yes, that's bad. We should work on that. ;-) Just because it might not cost anything doesn't mean that it's better. It is better. Why do you think we have Sound/, Nasal/ Dialogs/ directories in aircraft dirs, even if there's often only one file in them? It's about abstraction, clear structure and quick finding. From a pure technical point of view there's not much difference. FlightGear wouldn't care, and even thrown together there would often still be fewer files than in your Airports/L/O/X/ directory. But that's not the point, IMHO. Saving space might not be the only argument in favour of twr, and even without such an argument, I can see no important point against our proposal here that would warrant a change. twr kind of hurts. ac may also be a very often used abbreviation for aircraft in aviatics, but I'd still not call the Aircraft/ dir ac/, the Airports/ dir apt/, etc. But this was never my main complaint anyway. This is what I 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. Yes, you demanded more arguments after I had given some already, without bothering to add some of yours, and implying that mine weren't technical. I found this a bit funny and surprising. Abstraction, cleanliness etc. are IMHO very technical. However, easy path creation wasn't the goal of the structure. An even easier path would have been Airports/KSFO/*.xml or Airports/KSFO.xml, but that would have contradicted the intent. I would say that file access (logic and speed) is a rather important point of data storage. And very technical, too. All on one level would be slow and might be too much for some file systems. So this reduces it all to combining the files of one airport into one file, which we already discussed and dismissed for reasons of differing sources of information and which you did not propose in your final comparison anymore. Yes, because the need to have many files per airport was actually your only argument. I based my final suggestion on that requirement. But, ok, let's go with the on-file-per-airport approach. I actually find Curt's Airports/L/LO/LOX/LOXT.xml suggestion the sanest of all. $FG_ROOT/Aircraft/b/o/1/0/5/splash.rgb
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison )
On mardi 04 novembre 2008, Ron Jensen wrote: On Tue, 2008-11-04 at 14:27 +0100, Melchior FRANZ wrote: * Ron Jensen -- 11/4/2008 1:15 PM: I'll shut up now since I've already been told I'm not a real FlightGear developer and I'm not welcome to create scenery. I hope that wasn't me. I don't label people real or non-real something. But it's true that sometimes the opinion of people who will do the actual coding as well counts more than that of mere lurkers, especially when there are no arguments, just the usual we should do this and that. And I don't think you ever belonged to that group. No, Melchior, I was not referring to you. I always value your input highly. Thanks, Ron (jentron) Since i am only a user i can give my opinion. Ron is a real developper, for instance the last FGPiston update within JSBSim is perfect. Cheerrs -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
On Tue, 04 Nov 2008 10:21:30 +0100, Melchior wrote in message [EMAIL PROTECTED]: Yes, because the need to have many files per airport was actually your only argument. I based my final suggestion on that requirement. But, ok, let's go with the on-file-per-airport approach. I actually find Curt's Airports/L/LO/LOX/LOXT.xml suggestion the sanest of all. .._why_ Airports/L/LO/LOX/LOXT.xml and not Airports/L/LO/LOX/LOXT/LOXT.xml etc??? 8o) ..and, why Airports/L/O/X/LOXT.xml and not Airports/L/O/X/T/LOXT.xml etc??? 8o) ..I dunno about you guys, FG, SG or the machines, but both Airports/L/LO/LOX/LOXT/LOXT.xml and Airports/L/O/X/T/LOXT.xml adding that final letter level, looks saner to my eyes. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Ron Jensen wrote: Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. No management in CVS is planned. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
* Ron Jensen -- 11/4/2008 1:15 PM: On Tue, 2008-11-04 at 10:01 +0100, Ralf Gerlich wrote: I have already provided the arguments in favour of the three-level hierarchy. Yes, we were really only arguing over whether a fourth level would be too expensive, and whether organizing files via prefixes rather than directories is a good idea. How often do we assume that files in that structure are accessed? A few dozens at startup, then one every few minutes? Performance considerations about another dir level don't make much sense to me. Especially if you consider that the harddisk has its own read-ahead cache, and that the kernel adds another layer. If you tell it to read one sector, then it will read a few of them and store them in RAM, just in case (AFAIK). The effect of that is hard to estimate, of course. IMHO writing for the machine's preferences is something that kernel and file system designers should do, not usually application designers. Microoptimization often turns out to be counterproductive later on. Having said that, I agree that adding *many* files is still a problem, though. (I've always considered file systems based on fixed numbers of inodes bad design. I'm not using that sort of stuff here. :-) The more I hear, the less I like this idea. So I won't have ILS navaids available if I don't download the scenery tile? I won't be able to look for airports unless I pull the whole world scenery? But some information just doesn't make sense in one huge file that's completely read and parsed every time at startup, then kept in memory. I agree, though, that we have to be careful about it. Under the current scheme anyone and everyone can scan apt.dat for every/any airport using common *nix tools like grep or sed. This scheme breaks that ability. I didn't assume that we are going to drop that single DB with all important info. Just the parts that you don't usually care about, like parking positions, taxiway information or thresholds for VHHH when your are flying in KSFO. I'll shut up now since I've already been told I'm not a real FlightGear developer and I'm not welcome to create scenery. I hope that wasn't me. I don't label people real or non-real something. But it's true that sometimes the opinion of people who will do the actual coding as well counts more than that of mere lurkers, especially when there are no arguments, just the usual we should do this and that. And I don't think you ever belonged to that group. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Ralf Gerlich wrote: Ron Jensen wrote: Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. No management in CVS is planned. At least not in this structure. This is a means of data transport, not of data management. Cheers, Ralf -- Ralf Gerlich Diplom-Informatiker Software Engineer and Technical Consultant Dr. Rainer Gerlich System and Software Engineering Auf dem Ruhbühl 181 | Tel:+49 7545 91 12 58 D-88090 Immenstaad | Fax:+49 7545 91 12 40 Germany | Mobile: +49 178 76 06 129 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison )
Ok my turn :) I found Ron's comment about not being welcome to create scenery a bit disturbing ... why? So I'll ask a dumb , non developer question: What exactly is the purpose of this directory setup ? Will it affect my own attempt to update local scenery ?Is it meant to make scenery additions easier ? I must have missed out on all the discussion about this change , sorry . Now that I have a much better CYVR tile , I'm about to try to finish the airport , so are there any changes in the way they are supposed to be added ? I'm not excited about all those strange directories , but then I'm not sure what the purpose is , so can't give an opinion other than my own gut feeling. As far as Melchoir,s opinion's , ok sometimes he has irritated me in the past , but it was more irritating to discover he was right :). So I respect his opinion , and its comforting to know that someone is doing there level best to keep things sane . Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
On Tue, 2008-11-04 at 14:27 +0100, Melchior FRANZ wrote: * Ron Jensen -- 11/4/2008 1:15 PM: I'll shut up now since I've already been told I'm not a real FlightGear developer and I'm not welcome to create scenery. I hope that wasn't me. I don't label people real or non-real something. But it's true that sometimes the opinion of people who will do the actual coding as well counts more than that of mere lurkers, especially when there are no arguments, just the usual we should do this and that. And I don't think you ever belonged to that group. No, Melchior, I was not referring to you. I always value your input highly. Thanks, Ron (jentron) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
On Tue, 2008-11-04 at 10:01 +0100, Ralf Gerlich wrote: 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 dot extension dot 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. By my count, there are some 21,893 airports in apt.dat. This scheme will require 36 top level directories, 1011 2nd level directories and 8634 3rd level directories. So a full Scenery/Airports/ would contain some 109,465 files and 9,681 directories. Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. So we could conceivably end up with 140,000 files and 20,000 directories? 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. The more I hear, the less I like this idea. So I won't have ILS navaids available if I don't download the scenery tile? I won't be able to look for airports unless I pull the whole world scenery? 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 Under the current scheme anyone and everyone can scan apt.dat for every/any airport using common *nix tools like grep or sed. This scheme breaks that ability. 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. Why not just ship apt.dat and nav.dat with the scenery release instead of the base package? Simple, efficient and it doesn't break all the current code and methods that use these files. I'll shut up now since I've already been told I'm not a real FlightGear developer and I'm not welcome to create scenery. Thanks, Ron - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison )
On Tuesday 04 November 2008 21:26:18 Syd wrote: Hi Syd, Ok my turn :) I found Ron's comment about not being welcome to create scenery a bit disturbing ... why? Just to make a slightly off thread comment: All I can say is that Ron's comments on this list have been courteous and professional and I also don't remember any negative comments in referral to him, so I'm also rather puzzled by this statement. So I'll ask a dumb , non developer question: What exactly is the purpose of this directory setup ? Will it affect my own attempt to update local scenery ?Is it meant to make scenery additions easier ? Basically, this new scheme will serve a number of purposes. First and foremost, coupling airport related data to the scenery makes it a lot easier and more flexible to update the and maintain the scenery. Currently, (almost) all the airport data that is used by FlightGear is read from apt.dat. This not only means that we have to parse 2+ airpport to get the startup location for just one of those, it also means that we are limited in doing updates to the scenery: Suppose you would finetune the runway layout of your favorite airport. If this update were to be included in a new scenery release, you'd find out that FlightGear would place you off the runway, because the original startup position is still calculated based on an apt.dat file, which does not reside in the scenery, but in the base package. By moving this information out of the base package, and including it in the scenery, maintaining the scenery will become much better maintainable. Also, separating this information into separate files, mean less IO at program initialization, and therefore faster startup times. Hope this helps, Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison )
Thanks guys , I think I understand the purpose now. I was referring to adding airport building at CYVR , I haven't tried actually modifying the terrain or airport layout . Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison )
On Tue, 2008-11-04 at 22:19 +0100, Durk Talsma wrote: On Tuesday 04 November 2008 21:26:18 Syd wrote: Hi Syd, Ok my turn :) I found Ron's comment about not being welcome to create scenery a bit disturbing ... why? Just to make a slightly off thread comment: All I can say is that Ron's comments on this list have been courteous and professional and I also don't remember any negative comments in referral to him, so I'm also rather puzzled by this statement. Thanks everyone. I had an e-mail exchange off-list today and I believe there was a misunderstanding of a forum post. Another example of the difficulties of communicating over e-mail and forums. It is too easy to misinterpret the meanings or targets of disparaging remarks. Thank you again and sorry for the thread hijack. Ron - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Hi Melchior, why do you take this to the -users list again, where it is obviously off-topic as a development issue and after I had taken the discussion where it belongs: to the -devel list? The proposal as posted in my announcement was designed by a group of developers, not just Martin and me. I just took the task of proposing and defending it. You might want to consider that the proposal was thoroughly pondered before implementing it on the scenery side and publishing it. Our team has experts on the relevant issues, ranging from databases and operating systems to the concerned parts of FlightGear and the scenery process. So as long as you do not _prove_ us wrong, there is no reason to conclude that our proposal is nonsensical. I will show that what you did is far from proving us wrong. I am open to change the structure and even defend the change in the group of developers who have designed it if the change does not contradict the goal of the proposal and there are sufficient arguments for a change weighing up the cost of additional risk and effort. Not only are your arguments not sufficient, the largest share of your change requests even contradicts the goal of our proposal. For the benefit of discussion with _other_ FlightGear developers I will lay out the arguments for this. I might add that in some rare cases I share your sense of beauty w.r.t. technical aspects of FlightGear, but this is not such a case and even if it was, it would not be a sufficient argument. I am full-quoting your mail, so all developers not on the users-list can see what we are talking about. That should be also in your interest, because your and my comments can now be found in additional places, so you and I can occasionally point to it ;-) Melchior FRANZ wrote: I give up. Let's just have the nonsensical directory layout. It's not the only bad design in fgfs, and I'm the only one who cares about it, anyway. But here's a final comparison for your entertainment (and for the archive, so that I can occasionally point to it ;-): Solution 1 -- proposed and defended by Ralf and Martin: --- Airports/L/O/X/LOXA.ils.xml /LOXA.parking.xml /LOXA.rwyuse.xml /LOXA.twr.xml /LOXA.threshold.xml /LOXN.ils.xml /LOXN.parking.xml /LOXN.rwyuse.xml /LOXN.twr.xml /LOXN.threshold.xml /LOXT.ils.xml /LOXT.parking.xml /LOXT.rwyuse.xml /LOXT.twr.xml /LOXT.threshold.xml /LOXZ.ils.xml /LOXZ.parking.xml /LOXZ.rwyuse.xml /LOXZ.twr.xml /LOXZ.threshold.xml Characteristics: - lots of files per level (messy) lots of files per level is the characteristics. lots is not a quantifiable measurement and messy is your very personal interpretation. Incidentally, messy is the only attribute in this point I can see coming near to an argument against our proposal, again in the realm of personal perception of beauty and therefore without any concrete foundation except your personal taste. Your personal taste is not in itself a sufficient argument for a change in this context. I think we should rather be discussing concrete characteristics such as validity, maintainability, performance and correctness. Wouldn't you agree? - natural grouping done by prefixes, rather than directories (the latter of which were invented for that purpose and come at *no* costs) Just because it might not cost anything doesn't mean that it's better. Window paint was invented for the purpose of painting windows and comes at no recurring cost. Still it does not make any sense to me to paint my windows if I want to have an unobstructed outside view. Also the fourth directory level _does_ cost something. See below. - tower abbreviated as twr (not saving *any* space) Saving space might not be the only argument in favour of twr, and even without such an argument, I can see no important point against our proposal here that would warrant a change. Technical argument: - it's too late, we don't want to change it anymore You might want to check your use of quotes, because they usually indicate word-by-word quotations. Neither can I be quoted that way nor did I say anything that implies the meaning of the phrase attributed to me. This is what I 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. (http://sourceforge.net/mailarchive/message.php?msg_name=490CA168.40004%40custom-scenery.org) This was the very first time I mentioned this constraint and did not represent it differently afterwards. Further what you obvioulsy are referring
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Off topic to Melchior and Ralf's non-technical discussion, but: On Mon, Nov 3, 2008 at 8:29 AM, Ralf Gerlich [EMAIL PROTECTED] wrote: The index concept has some similarity to a B-tree (http://en.wikipedia.org/wiki/B-Tree) in terms of structure, though the balancing aspect and therefore some of the performance estimates do of course not apply. Still, the general intention and the structural aspects are in most points applicable to our index. To truly optimize for load balancing the operating system's directory searches, we should really be reading from the right end of the airport identifier ... which is more uniformly random than the left end. We can drop one level of tree completely, only increase the size of the worst case leaf directory by a factor of two from 58 to 107 files, and reduce the number of organizational directories from 9681 to 1267. The average size of each leaf directory increases from 3 to 21 files which is comparable to the tree directories that now have 36 subdirectories. This naming scheme would cause the example file to become: Airports/A/X/LOXA.ils.xml Having said that, anyone doing non-programmatic access is probably not going to enjoy that hierarchy. So, unless someone wants to assert that Airports/ is going to be under automated maintenance, I continue to think that Ralf (et al) have made a good choice. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
* Alex Perry -- 11/3/2008 11:26 PM: Off topic to Melchior and Ralf's non-technical discussion, but: Better non-technical than technical but wrong. ;-) To truly optimize for load balancing the operating system's directory searches, This isn't about load balancing at all. It's just about avoiding to have 2*n files on one directory level, which would be painful for computer and humans. Sorting from the left is actually better than your suggestion, as the likeliness that all of LO?? ends up in the file cache (- read-ahead) would be an advantage, while having all of ??XA in the cache doesn't buy you anything. Apart from that both are equivalent. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
