RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > After tweaking the Makefile to use the right compiler and flags, and point > to glut running make gives: > > g++ -I/usr/X11R6/include -O2 -g -DSAFETY -DIOSTREAMH -c terra.cc > In file included from Geom.h:24, > from Heap.h:4, > from GreedyInsert.h:4, > from terra.h:4, > from terra.cc:1: > Vec2.h:43: ISO C++ forbids declaration of `ostream' with no type > Vec2.h:43: `ostream' is neither function nor member function; cannot be >declared friend > Vec2.h:43: syntax error before `&' token Are you trying to compile Terra from its standalone tarball, or are you compiling the version inside TerraGear? I fixed the TerraGear version (src/Prep/Terra) a couple of days ago so that it now builds normally and installs with the rest of TerraGear. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Richard Bytheway writes: > > Or could it actually use make? maybe but see http://www.scons.org/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
> From: Curtis L. Olson [mailto:[EMAIL PROTECTED] > > Jon Stockill writes: > > On Thu, 28 Aug 2003, Curtis L. Olson wrote: > > > > > Actually you will want to run terrafit.py ... it will > recurse through > > > the specified directory and produce .fit files for any > .arr files it > > > finds. > > > > I'd already overcome that problem with a combination of > "for" and "find" > > to make arrayfit process it all, but terrafit.py seems like > a much nicer > > solution :-) > > I don't know enough python to pull this off (and don't have time to > investigate it right now anyway) but it would be handy perhaps to make > terrafit.py check if the .fit file is newer than the .arr file and > if so skip it (kind of like the make utility.) > > Then you could restart a long run (that died or was killed for any > reason) and not have to redo a lot of work. > > Curt. Or could it actually use make? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Norman Vine wrote: Curtis L. Olson writes: I don't know enough python to pull this off (and don't have time to investigate it right now anyway) but it would be handy perhaps to make terrafit.py check if the .fit file is newer than the .arr file and if so skip it (kind of like the make utility.) Hmm.. this is easy enough todo Note this patch includes my earlier fix for paramater passing I've put it in CVS. Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Curtis L. Olson writes: > > Jon Stockill writes: > > On Thu, 28 Aug 2003, Curtis L. Olson wrote: > > > > > Actually you will want to run terrafit.py ... it will recurse through > > > the specified directory and produce .fit files for any .arr files it > > > finds. > > > > I'd already overcome that problem with a combination of "for" and "find" > > to make arrayfit process it all, but terrafit.py seems like a much nicer > > solution :-) > > I don't know enough python to pull this off (and don't have time to > investigate it right now anyway) but it would be handy perhaps to make > terrafit.py check if the .fit file is newer than the .arr file and > if so skip it (kind of like the make utility.) Hmm.. this is easy enough todo Note this patch includes my earlier fix for paramater passing HTH Norman $ cvs diff -u terrafit.py Index: terrafit.py === RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Prep/TerraFit/terrafit.py,v retrieving revision 1.4 diff -u -r1.4 terrafit.py --- terrafit.py 19 Aug 2003 02:27:08 - 1.4 +++ terrafit.py 28 Aug 2003 14:16:56 - @@ -106,6 +106,18 @@ raise IOError, (2, 'No such file or directory: ' + fname) return +# need to do this twice to get basename 'XXX.arr.gz' +basename,ext = os.path.splitext(fname) +basename,ext = os.path.splitext(basename) +gzName = basename+".fit.gz" + +try: +if path.getmtime(gzName) > path.getmtime(fname): +print "Skipping: %s is newer then %s"%(gzName,fname) +return +except: +pass + gzin = GzipFile(fname, 'rb') data = gzin.readline() @@ -130,17 +142,12 @@ max_z = max(max_z,max(data[i])) min_z = min(min_z,min(data[i])) -# need to do this twice to get basename 'XXX.arr.gz' -basename,ext = os.path.splitext(fname) -basename,ext = os.path.splitext(basename) - pgmName = basename+'.pgm' pre_terra(pgmName, data, span_x, span_y, max_z, min_z) objName = basename+'.obj' npts = run_terra(thresh, minnodes, count, factor, objName, pgmName) -gzName = basename+".fit.gz" post_terra(objName, gzName, step_x, step_y, min_x, min_y, min_z) if CLEAN_TEMP_FILES: @@ -209,9 +216,9 @@ sys.stderr.write('%s version %s\n' % (sys.argv[0],VERSION,)) sys.exit(0) if o in ('--minnodes','-m'): minnodes = string.atoi(v) -if o == ('--maxnodes','-x'): maxnodes = string.atoi(v) -if o == ('--maxerror','-e'): maxerror = string.atof(v) -if o == ('--factor','-f'): factor = string.atof(v) +if o in ('--maxnodes','-x'): maxnodes = string.atoi(v) +if o in ('--maxerror','-e'): maxerror = string.atof(v) +if o in ('--factor','-f'): factor = string.atof(v) if len(args) == 0 and len(opts) == 0: usage() sys.exit(1) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Curtis L. Olson writes: > > > > The factor value is the only one which is required to be as above < it > > > sets the scaling for vertical scale vs horizontal scale of the input > > > data > > > As far as I can tell the factor value is only used by xterra to scale > the visualization. It's not used at all by terra (so we could > probalby drop it safely.) Yes, I think that is correct Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: > more than I had brain capacity for at the moment. It still is, but if > someone wants to generate and collect the .arr.gz and .fit.gz files > for this data set and put them someplace where I can drop them into my > build tree, then I could probably handle doing that. I'll have all that once terrafit finishes running. > If others want to build scenery, that is great, the more testers, > debuggers, data collectors, idea generators, bug fixers, code writers, > etc. the better. But I don't have time at the moment to offer a lot > of direction. Not a problem. I'm not really a programmer - I'm a sysadmin, but I'm happy to contribute to data collection, and I'm sure there's more data sets we can pull out of the vmap0 data. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > > On Thu, 28 Aug 2003, Jon Stockill wrote: > > > Well it's running with the settings as above, I'll see what it spits out. > > I've noticed a little bit of weirdness already: > > 1621 pts/2S 0:01 python /usr/local/bin/terrafit.py -m 50 -x 1200 > -e 2 -f 0.03 work/DEM-30/ > > 1714 pts/2R 0:00 terra -e 50.00 -n 50 -p 600 -h 0.03 -o > work/DEM-30/e000n00/e000n06/2955316.obj obj work/DEM-30/e0 > > It looks like none of the parameters aren't being passed through to terra > properly. Arghh.. I never really tested this and what I had is just wrong.. :-( What was I thinking !! HTH Norman $ cvs diff -u terrafit.py Index: terrafit.py === RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Prep/TerraFit/terrafit.py,v retrieving revision 1.4 diff -u -r1.4 terrafit.py --- terrafit.py 19 Aug 2003 02:27:08 - 1.4 +++ terrafit.py 28 Aug 2003 13:55:09 - @@ -209,9 +209,9 @@ sys.stderr.write('%s version %s\n' % (sys.argv[0],VERSION,)) sys.exit(0) if o in ('--minnodes','-m'): minnodes = string.atoi(v) -if o == ('--maxnodes','-x'): maxnodes = string.atoi(v) -if o == ('--maxerror','-e'): maxerror = string.atof(v) -if o == ('--factor','-f'): factor = string.atof(v) +if o in ('--maxnodes','-x'): maxnodes = string.atoi(v) +if o in ('--maxerror','-e'): maxerror = string.atof(v) +if o in ('--factor','-f'): factor = string.atof(v) if len(args) == 0 and len(opts) == 0: usage() sys.exit(1) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > On Thu, 28 Aug 2003, Curtis L. Olson wrote: > > > Erik Hofman writes: > > > It would be nice if somebody could step up (Curtis?) to get this data > > > into the next scenery build. > > > > My brain is full, I was just hoping someone else could coordinate this > > until one of my nuerons becomes free. > > I'm happy to do the complete scenery build - just let me know what you > want including, and tell me where to upload it. Well, I'm working through the process of a world scenery build trying to identify and fix issues as I go. Erik thought it would be nice to slip the new GLOBE 30arcsec terrain data in there, but that was just more than I had brain capacity for at the moment. It still is, but if someone wants to generate and collect the .arr.gz and .fit.gz files for this data set and put them someplace where I can drop them into my build tree, then I could probably handle doing that. If others want to build scenery, that is great, the more testers, debuggers, data collectors, idea generators, bug fixers, code writers, etc. the better. But I don't have time at the moment to offer a lot of direction. Best regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: > Erik Hofman writes: > > It would be nice if somebody could step up (Curtis?) to get this data > > into the next scenery build. > > My brain is full, I was just hoping someone else could coordinate this > until one of my nuerons becomes free. I'm happy to do the complete scenery build - just let me know what you want including, and tell me where to upload it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman writes: > It would be nice if somebody could step up (Curtis?) to get this data > into the next scenery build. My brain is full, I was just hoping someone else could coordinate this until one of my nuerons becomes free. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > On Thu, 28 Aug 2003, Curtis L. Olson wrote: > > > Actually you will want to run terrafit.py ... it will recurse through > > the specified directory and produce .fit files for any .arr files it > > finds. > > I'd already overcome that problem with a combination of "for" and "find" > to make arrayfit process it all, but terrafit.py seems like a much nicer > solution :-) I don't know enough python to pull this off (and don't have time to investigate it right now anyway) but it would be handy perhaps to make terrafit.py check if the .fit file is newer than the .arr file and if so skip it (kind of like the make utility.) Then you could restart a long run (that died or was killed for any reason) and not have to redo a lot of work. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > > The factor value is the only one which is required to be as above < it > > sets the scaling for vertical scale vs horizontal scale of the input > > data > As far as I can tell the factor value is only used by xterra to scale the visualization. It's not used at all by terra (so we could probalby drop it safely.) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Jon Stockill wrote: > Well it's running with the settings as above, I'll see what it spits out. I've noticed a little bit of weirdness already: 1621 pts/2S 0:01 python /usr/local/bin/terrafit.py -m 50 -x 1200 -e 2 -f 0.03 work/DEM-30/ 1714 pts/2R 0:00 terra -e 50.00 -n 50 -p 600 -h 0.03 -o work/DEM-30/e000n00/e000n06/2955316.obj obj work/DEM-30/e0 It looks like none of the parameters aren't being passed through to terra properly. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: > Actually you will want to run terrafit.py ... it will recurse through > the specified directory and produce .fit files for any .arr files it > finds. I'd already overcome that problem with a combination of "for" and "find" to make arrayfit process it all, but terrafit.py seems like a much nicer solution :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Norman Vine wrote: > This is a recnt change, perhaps you need to do a CVS up Yup, that sorted it - looks like I was running quite an old cvs snapshot, I think I downloaded it when there were some problems with the cvs server. A fresh checkout compiled much easier, with no fiddling required to get terra to build. > < aside > > Ah now we are leaving science and getting into art :-) > < /aside > Oh dear - I never was much of an artist :-) > The factor value is the only one which is required to be as above < it > sets the scaling for vertical scale vs horizontal scale of the input > data > OK > AFAIK these values are the ones that Curt was using as I just copied them > from his 'C' driver program for the arrayfit process Yes - the values shown by both progs when run without parameters are the same. > FWIW > I would decrease the maxerror considerably < perhaps to 2 at least to 5> as > AFAICT Terra will always insert nodes ordered by 'max error' and will always > quit when maxnodes is reached. > > As to what to use for maxnodes, I am not sure. Right, I've got: terrafit.py -f 0.03 -m 50 -x 1200 -e 2 $work/DEM-30 I'll see what that creates, and tweak it as necessary. > I wouldn't worry to much about run time as Terra is 'remarkably' quick. > i.e using Terra even when driven with a Python script should be substantially > more then an order of magnitude quicker then using arrayfit > > It's worth getting Terra running before starting the global decimation :-) Well it's running with the settings as above, I'll see what it spits out. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > On Thu, 28 Aug 2003, Erik Hofman wrote: > > > It would be nice if somebody could step up (Curtis?) to get this data > > into the next scenery build. > > Well I'm just clearing some disk space at the moment, unless someone says > otherwise I'll just run: > > arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file > > on all the .arr data as terra doesn't seem to want to compile. Actually you will want to run terrafit.py ... it will recurse through the specified directory and produce .fit files for any .arr files it finds. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > > On Thu, 28 Aug 2003, Norman Vine wrote: > > > What errors are you getting from the Terra build ?? > > After tweaking the Makefile to use the right compiler and flags, and point > to glut running make gives: > > g++ -I/usr/X11R6/include -O2 -g -DSAFETY -DIOSTREAMH -c terra.cc > In file included from Geom.h:24, > from Heap.h:4, > from GreedyInsert.h:4, > from terra.h:4, > from terra.cc:1: > Vec2.h:43: ISO C++ forbids declaration of `ostream' with no type > Vec2.h:43: `ostream' is neither function nor member function; cannot be >declared friend > Vec2.h:43: syntax error before `&' token Jon This is the top of my Terra/Vec2.h #ifndef VEC2_INCLUDED // -*- C++ -*- #define VEC2_INCLUDED #include using std::ostream; using std::istream; This is a recnt change, perhaps you need to do a CVS up If you have this change then AFAIK you can probably work around this by explicitly calling the fully decorated object i.e. line 43 Vec2.h // Input/Output methods friend std::ostream& operator<<(std::ostream&, const Vec2&); friend std::istream& operator>>(std::istream&, Vec2&); > > AFAICT we want to use the Python script which if called with no arguments > > should print some help i.e. > > > > $ python src/Prep/TerraFit/terrafit.py > > AIUI this is just a script which drives terra though, not a standalone > solution? Correct but you can't call terra directly as the data needs to be massaged both on input and output > > Usage: src/Prep/TerraFit/terrafit.py > > -h | --help > > -m | --minnodes 50 > > -x | --maxnodes 600 > > -e | --maxerror 50 > > -f | --factor 0.03 > > -v | --version > > [file] | [path to walk] > > > > Algorithm will produce at least 50 fitted nodes, but no > > more than 600. Within that range, the algorithm will stop > > if the maximum elevation error for any remaining point > > drops below 50 meters. > > Are these sensible values, or should we be pushing maxnodes up, and > maxerror down (and if so, how far) - I'm guessing that fitting a better > surface will take longer, I'm not particularly worried about this, as long > as we get a good result for the finished scenery - also more points=more > triangles, and we need to ensure we have scenery that's going to be usable > on a wide range of hardware. < aside > Ah now we are leaving science and getting into art :-) < /aside > The factor value is the only one which is required to be as above < it sets the scaling for vertical scale vs horizontal scale of the input data > AFAIK these values are the ones that Curt was using as I just copied them from his 'C' driver program for the arrayfit process FWIW I would decrease the maxerror considerably < perhaps to 2 at least to 5> as AFAICT Terra will always insert nodes ordered by 'max error' and will always quit when maxnodes is reached. As to what to use for maxnodes, I am not sure. I wouldn't worry to much about run time as Terra is 'remarkably' quick. i.e using Terra even when driven with a Python script should be substantially more then an order of magnitude quicker then using arrayfit It's worth getting Terra running before starting the global decimation :-) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Norman Vine wrote: > What errors are you getting from the Terra build ?? After tweaking the Makefile to use the right compiler and flags, and point to glut running make gives: g++ -I/usr/X11R6/include -O2 -g -DSAFETY -DIOSTREAMH -c terra.cc In file included from Geom.h:24, from Heap.h:4, from GreedyInsert.h:4, from terra.h:4, from terra.cc:1: Vec2.h:43: ISO C++ forbids declaration of `ostream' with no type Vec2.h:43: `ostream' is neither function nor member function; cannot be declared friend Vec2.h:43: syntax error before `&' token > What OS are you running ? Slackware Linux current, which uses gcc 3.2.3. Is that the source of the problem? > AFAICT we want to use the Python script which if caled with no arguments > should print some help i.e. > > $ python src/Prep/TerraFit/terrafit.py AIUI this is just a script which drives terra though, not a standalone solution? > Usage: src/Prep/TerraFit/terrafit.py > -h | --help > -m | --minnodes 50 > -x | --maxnodes 600 > -e | --maxerror 50 > -f | --factor 0.03 > -v | --version > [file] | [path to walk] > > Algorithm will produce at least 50 fitted nodes, but no > more than 600. Within that range, the algorithm will stop > if the maximum elevation error for any remaining point > drops below 50 meters. Are these sensible values, or should we be pushing maxnodes up, and maxerror down (and if so, how far) - I'm guessing that fitting a better surface will take longer, I'm not particularly worried about this, as long as we get a good result for the finished scenery - also more points=more triangles, and we need to ensure we have scenery that's going to be usable on a wide range of hardware. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: > > On Thu, 28 Aug 2003, Erik Hofman wrote: > > > It would be nice if somebody could step up (Curtis?) to get this data > > into the next scenery build. > > Well I'm just clearing some disk space at the moment, unless someone says > otherwise I'll just run: > > arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file > > on all the .arr data as terra doesn't seem to want to compile. Jon What errors are you getting from the Terra build ?? What OS are you running ? AFAICT we want to use the Python script which if caled with no arguments should print some help i.e. $ python src/Prep/TerraFit/terrafit.py Usage: src/Prep/TerraFit/terrafit.py -h | --help -m | --minnodes 50 -x | --maxnodes 600 -e | --maxerror 50 -f | --factor 0.03 -v | --version [file] | [path to walk] Algorithm will produce at least 50 fitted nodes, but no more than 600. Within that range, the algorithm will stop if the maximum elevation error for any remaining point drops below 50 meters. Increasing the maxnodes value and/or decreasing maxerror will produce a better surface approximation. The input file must be a .arr.gz file such as that produced by demchop or hgtchop utils. NOTE : If a directory is input all .arr files in directory will be processed recursively. The output file(s) is called .fit.gz and is simply a list of from the resulting fitted surface nodes. The user of the .fit file will need to retriangulate the surface. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Erik Hofman wrote: > It would be nice if somebody could step up (Curtis?) to get this data > into the next scenery build. Well I'm just clearing some disk space at the moment, unless someone says otherwise I'll just run: arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file on all the .arr data as terra doesn't seem to want to compile. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill wrote: On Thu, 28 Aug 2003, Frederic Bouvier wrote: Erik Hofman wrote: Curtis need the resulting *.arr.gz and *.fit.gz files. They should probably be generated by ArrayFit or Terra, but I haven't found a manual for that. Is there somebody willing to collect the data ? I have *.arr.gz files for the whole planet now. If someone wants to let me know how I should go about running arrayfit or terrafit on this lot then I'll get it processed. It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Frederic Bouvier wrote: > Erik Hofman wrote: > > > Curtis need the resulting *.arr.gz and *.fit.gz files. > > They should probably be generated by ArrayFit or Terra, but I haven't > > found a manual for that. > > Is there somebody willing to collect the data ? I have *.arr.gz files for the whole planet now. If someone wants to let me know how I should go about running arrayfit or terrafit on this lot then I'll get it processed. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: > Frederic Bouvier wrote: > > >>You are now done preparing the elevation data. To build scenery, > >>TerraGear needs only the files and directories under the work/DEM-30/; > >>if you are tight for space, you can delete all of your working files > >>under data/ now, before going any further (if you have a lot of space, > >>it doesn't hurt to keep them around). > > > > > > That's all ? or do you want us to generate the scenery ? > > > > I have the whole w020n90 dem done now. > > Curtis need the resulting *.arr.gz and *.fit.gz files. > They should probably be generated by ArrayFit or Terra, but I haven't > found a manual for that. Is there somebody willing to collect the data ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Anyone have a static copy of terragear for linux? Ryan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: > Frederic Bouvier wrote: > > >>You are now done preparing the elevation data. To build scenery, > >>TerraGear needs only the files and directories under the work/DEM-30/; > >>if you are tight for space, you can delete all of your working files > >>under data/ now, before going any further (if you have a lot of space, > >>it doesn't hurt to keep them around). > > > > > > That's all ? or do you want us to generate the scenery ? > > > > I have the whole w020n90 dem done now. > > Curtis need the resulting *.arr.gz and *.fit.gz files. > They should probably be generated by ArrayFit or Terra, but I haven't > found a manual for that. > > Do you have actually any files after demchop? > > For me most tiles don't even pass raw2ascii and the ones that do don't > generate any files when processed by demchop. I started terrafit.py with the default options and it is done. Is it correct ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Wed, 27 Aug 2003, Frederic Bouvier wrote: > That's all ? or do you want us to generate the scenery ? > > I have the whole w020n90 dem done now. If we're generating it too then we need to ensure that everyone's generating the polys from vmap0 with the same info - can I assume we're going with the settings in the "howto" doc? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: > Frederic Bouvier wrote: > > >>You are now done preparing the elevation data. To build scenery, > >>TerraGear needs only the files and directories under the work/DEM-30/; > >>if you are tight for space, you can delete all of your working files > >>under data/ now, before going any further (if you have a lot of space, > >>it doesn't hurt to keep them around). > > > > > > That's all ? or do you want us to generate the scenery ? > > > > I have the whole w020n90 dem done now. > > Curtis need the resulting *.arr.gz and *.fit.gz files. > They should probably be generated by ArrayFit or Terra, but I haven't > found a manual for that. > > Do you have actually any files after demchop? > > For me most tiles don't even pass raw2ascii and the ones that do don't > generate any files when processed by demchop. I have 12Mb of .arr.gz files. Now I am updating Cygwin because I realized I don't have Python installed. What is the procedure to obtain .fit.gz files ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Frederic Bouvier wrote: You are now done preparing the elevation data. To build scenery, TerraGear needs only the files and directories under the work/DEM-30/; if you are tight for space, you can delete all of your working files under data/ now, before going any further (if you have a lot of space, it doesn't hurt to keep them around). That's all ? or do you want us to generate the scenery ? I have the whole w020n90 dem done now. Curtis need the resulting *.arr.gz and *.fit.gz files. They should probably be generated by ArrayFit or Terra, but I haven't found a manual for that. Do you have actually any files after demchop? For me most tiles don't even pass raw2ascii and the ones that do don't generate any files when processed by demchop. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: > Jon S Berndt wrote: > > > What are the steps involved? I can help out, I think. > > Download one or more DEM files from here (this needs to be coordinated): > http://edcsgs9.cr.usgs.gov/pub/data/srtm/SRTM30 > > Get TerraGear working: > http://www.terragear.org > > And follow these steps (unless I'm mistaken): > > 3. Preparing the Datasets snip > You are now done preparing the elevation data. To build scenery, > TerraGear needs only the files and directories under the work/DEM-30/; > if you are tight for space, you can delete all of your working files > under data/ now, before going any further (if you have a lot of space, > it doesn't hurt to keep them around). That's all ? or do you want us to generate the scenery ? I have the whole w020n90 dem done now. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: > Jim Wilson wrote: > > Erik Hofman <[EMAIL PROTECTED]> said: > > > > > >>After the code churns away for a couple of minutes, you should find a > >>w080n40/ directory in work/DEM-30/, containing 100 subdirectories named > >>w071n40 to w080n49, using about 12MB of disk space. > >> > >>You are now done preparing the elevation data. To build scenery, > >>TerraGear needs only the files and directories under the work/DEM-30/; > >>if you are tight for space, you can delete all of your working files > >>under data/ now, before going any further (if you have a lot of space, > >>it doesn't hurt to keep them around). > > > > > > Maybe folks could claim chunks here on the list so that there isn't duplication? > > Since the full SRTM data is available these chunck could be skipped. > I am currently working on: > > e020n40 I am processing w020n90 now with a cygwin build. Running raw2ascii now... > Could somebody who had linux binaries post a .tar.gz archive somehwere? I have a Cygwin build. The files to pack are : - arrayfit - demchop - hgtchop - deminfo - raw2ascii - e00lines - gshhs - debug - photo - wgs84offset - findcorners - shape-decode - noaa-decode - tgvpf - xterra - terra - tguserdef - genapts - fgfs-tools-server - fgfs-tools-client - fgfs-construct - fgfs-master Correct ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: Since the full SRTM data is available these chunck could be skipped. I am currently working on: e020n40 AS much as I would like to help,so far a bug in raw2ascii prevents me from doing any work because it to bails out with them message "Latitude ranges from 0 to 0" on several of these files! I have tried in on both Linux and IRIX machines so it's not an endian issue. :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Martin Spott wrote: Erik Hofman <[EMAIL PROTECTED]> wrote: nurbs++ isn't needed for this handling this data. SO you should be safe. Great ! GTS should be taken from CVS. Right ? I am not sure ... I guess it won't hurt either. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman <[EMAIL PROTECTED]> wrote: > nurbs++ isn't needed for this handling this data. SO you should be safe. Great ! GTS should be taken from CVS. Right ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jim Wilson wrote: Erik Hofman <[EMAIL PROTECTED]> said: After the code churns away for a couple of minutes, you should find a w080n40/ directory in work/DEM-30/, containing 100 subdirectories named w071n40 to w080n49, using about 12MB of disk space. You are now done preparing the elevation data. To build scenery, TerraGear needs only the files and directories under the work/DEM-30/; if you are tight for space, you can delete all of your working files under data/ now, before going any further (if you have a lot of space, it doesn't hurt to keep them around). Maybe folks could claim chunks here on the list so that there isn't duplication? Since the full SRTM data is available these chunck could be skipped. I am currently working on: e020n40 Could somebody who had linux binaries post a .tar.gz archive somehwere? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Martin Spott wrote: Erik Hofman <[EMAIL PROTECTED]> wrote: Get TerraGear working: http://www.terragear.org Currently this appears to be the biggest part for me. TerraGear depends on gpc, nurbs++ and gts, gts depends on glib. Right ? So you have to build these four libraries _before_. nurbs++-3.0.11 fails to compile with GCC-3.3 on Linux and on Solaris (different errors). I'll have to figure this out. Can anyone recommend a nurbs++ release that is known to work out of the box ? nurbs++ isn't needed for this handling this data. SO you should be safe. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman <[EMAIL PROTECTED]> said: > After the code churns away for a couple of minutes, you should find a > w080n40/ directory in work/DEM-30/, containing 100 subdirectories named > w071n40 to w080n49, using about 12MB of disk space. > > You are now done preparing the elevation data. To build scenery, > TerraGear needs only the files and directories under the work/DEM-30/; > if you are tight for space, you can delete all of your working files > under data/ now, before going any further (if you have a lot of space, > it doesn't hurt to keep them around). Maybe folks could claim chunks here on the list so that there isn't duplication? I've got at least one 1GHZ test machine here that can churn away 24/7. Not sure how much diskspace is avaialble, but probably a few gb. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
I've got a few machines free. Linux: P3-800Mhz 512MB Dual CPU 1GHz 512MB Windows 2000: 1GHz P3 512MB 1800+XP 512MB Windows XP: 1GHz P3 256MB Trouble is I don't have terragear built as yet for linux or windows and I have satellite internet so the uplink is only at a poor 28Kbps. But if I can be of help don't hesitate to shout for me. Cheers, Al > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Erik Hofman > Sent: 26 August 2003 22:37 > To: FlightGear developers discussions > Subject: [Flightgear-devel] Any Volunteers? > > > > Hi, > > Curtis is going to do a new scenery release but is unable to get the > SRTM30 data include due to time restrictions (they should be > generated > within a day or two). > > We might be able to get it going for him if there are enough > volunteers > to create the data for him. > > This require quite some dedicated CPU time, so could > everybody who wants > to participate step forward please? > > I am volunteering for a good part with a dual processor O200. > > Erik > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/fl> ightgear-devel > > > --- > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman <[EMAIL PROTECTED]> wrote: > Jon S Berndt wrote: >> What are the steps involved? I can help out, I think. > Download one or more DEM files from here (this needs to be coordinated): > http://edcsgs9.cr.usgs.gov/pub/data/srtm/SRTM30 > Get TerraGear working: > http://www.terragear.org Currently this appears to be the biggest part for me. TerraGear depends on gpc, nurbs++ and gts, gts depends on glib. Right ? So you have to build these four libraries _before_. nurbs++-3.0.11 fails to compile with GCC-3.3 on Linux and on Solaris (different errors). I'll have to figure this out. Can anyone recommend a nurbs++ release that is known to work out of the box ? Damn, this is about two weeks too early for me My IBM RS6k server is not usuable at the moment because the SSA host interface appears to be broken so I don't have the required disk space. I'll try do add an UltraSparcII to the job. Is TerraGear 64bit safe ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
[EMAIL PROTECTED] wrote: I might be able to use a few (10-15) dual 2.8GHZ Xeon P4 machines.. They are all running linux. Now we're talking :-D Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
I might be able to use a few (10-15) dual 2.8GHZ Xeon P4 machines.. They are all running linux. Let me know. Ryan > -Original Message- > From: Erik Hofman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 26, 2003 09:37 PM > To: 'FlightGear developers discussions' > Subject: [Flightgear-devel] Any Volunteers? > > > Hi, > > Curtis is going to do a new scenery release but is unable to get the > SRTM30 data include due to time restrictions (they should be generated > within a day or two). > > We might be able to get it going for him if there are enough volunteers > to create the data for him. > > This require quite some dedicated CPU time, so could everybody who wants > to participate step forward please? > > I am volunteering for a good part with a dual processor O200. > > Erik > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Tue, 26 Aug 2003 23:37:25 +0200 Erik Hofman <[EMAIL PROTECTED]> wrote: Hi, Curtis is going to do a new scenery release but is unable to get the SRTM30 data include due to time restrictions (they should be generated within a day or two). We might be able to get it going for him if there are enough volunteers to create the data for him. This require quite some dedicated CPU time, so could everybody who wants to participate step forward please? I am volunteering for a good part with a dual processor O200. Erik What are the steps involved? I can help out, I think. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Tue, 26 Aug 2003, Erik Hofman wrote: > I am volunteering for a good part with a dual processor O200. I can throw 2 or 3 machines at it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon S Berndt wrote: What are the steps involved? I can help out, I think. Download one or more DEM files from here (this needs to be coordinated): http://edcsgs9.cr.usgs.gov/pub/data/srtm/SRTM30 Get TerraGear working: http://www.terragear.org And follow these steps (unless I'm mistaken): 3. Preparing the Datasets After following the instructions in the previous section, you should have the following three data files downloaded onto your computer: * w100n90.tar.gz (approx. 15MB) * default.apt.gz (approx. 1MB) * v0noa.tar.gz (approx. 145MB) Before you go any further, you need to create a root directory for scenery building. Personally, I use /usr/local/src/Scenery/, but you can set things up any way you like. Inside your root scenery directory, create two subdirectories, ./work/ and ./data/: $ cd /usr/local/src/Scenery/ $ mkdir work $ mkdir data 3.1. Preparing the Elevation Data Change into the data directory, and create a dem30 subdirectory to hold the DEM data, then change to the dem30 subdirectory and unpack the : $ cd data $ mkdir dem30 $ cd dem30 $ tar xvzf ../../w100n90.tar.gz You should end up something like this: -rw-r--r--1 daviddavid5760 Jan 21 1997 W100N90.DEM -rw-r--r--1 daviddavid 222 Jan 21 1997 W100N90.DMW -rw-r--r--1 daviddavid 114634 Jan 22 1997 W100N90.GIF -rw-r--r--1 daviddavid 327 Jan 23 1997 W100N90.HDR -rw-r--r--1 daviddavid 648 Jan 21 1997 W100N90.PRJ -rw-r--r--1 daviddavid 326 Jan 23 1997 W100N90.SCH -rw-r--r--1 daviddavid2880 Jan 21 1997 W100N90.SRC -rw-r--r--1 daviddavid 28 Jan 21 1997 W100N90.STX First, we need to convert the DEM from the current binary format to an ASCII format that TerraGear can handle, using TerraGear's raw2ascii command (we'll put the output in an ascii subdirectory). You can skip this step if you're using the US 3arcsec DEMs, since they're already in ASCII format: $ mkdir ascii $ raw2ascii W100N90 ascii Ouch! The command runs for a while and ends up creating 2,000 files in the ascii/ subdirectory, using up over 200MB of disk space; the good news is that you'll be able to delete these soon. In fact, you can already delete the original 57MB DEM files, since you won't be needing them anymore (you might want to back up the original tarball somewhere, though): $ rm -v W100N90* Now, if you know for certain (really for certain) that you're not going to build any scenery outside of the w080n40 chunk, you can also delete all of the extra DEM files that you won't be needing. For w080n40, you need w071n40.dem to w080n49.dem inclusive: $ # Are you SURE you want to do this? $ rm ascii/*n[5678]* $ rm ascii/w06* $ rm ascii/w070* $ rm ascii/w08[1-9]* $ rm ascii/w09* $ rm ascii/w10* Now, instead of 2,000 files using over 200MB, we have only 100 files using a little over 10MB. Note again that you shouldn't do this if you're planning on building scenery for the surrounding tiles as well. OK, now it's time to chop up the DEM files into segments for TerraGear. Change back to the root of your scenery source tree (such as /usr/local/src/Scenery/, then create a work/DEM-30/ directory for the predigested DEM data to live in (US 3-arcsec DEM data, if you're using it instead, should go to work/DEM-3): $ mkdir work/DEM-30 Now, the next part is even more OS-dependent than usual. You need to run the command demchop on each of the *.dem files in data/dem30/ascii separately. With the bash shell, I use the following (again, from the root of the scenery source tree): $ for file in data/dem30/ascii/*.dem; do > demchop $file work/DEM-30 > done After the code churns away for a couple of minutes, you should find a w080n40/ directory in work/DEM-30/, containing 100 subdirectories named w071n40 to w080n49, using about 12MB of disk space. You are now done preparing the elevation data. To build scenery, TerraGear needs only the files and directories under the work/DEM-30/; if you are tight for space, you can delete all of your working files under data/ now, before going any further (if you have a lot of space, it doesn't hurt to keep them around). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel