Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2012 |
Jan
|
Feb
(3) |
Mar
(33) |
Apr
(5) |
May
(18) |
Jun
(6) |
Jul
(3) |
Aug
(3) |
Sep
(15) |
Oct
(1) |
Nov
(2) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
From: Geoff McLane <ubuntu@ge...> - 2016-11-03 19:36:38
|
Thanks for the links... The first is a great list of VMAP0 (I think) shape files, world coverage... Can you remind me what terragear tools should be used to chop this shp data into buckets? TG used to have VPF tools to directly extract, and chop the raw VMAP0 data files... I have the eur, noa, sas, and soa libraries... and could bring back these VPF tools... And WOW, the OSM link seems to show **lots** of options... ;=)) Will explore this... do you have a specific suggestion within these to get land use, road, rivers, rail stuff, by say bounding box, or...? Thanks, Geoff. On 03/11/16 08:55, m.herweg@... wrote: > Am 03.11.2016 um 01:36 schrieb Geoff McLane: >> Where to get the land usage information, and the >> roads, rivers, railways, ... data... to reconstruct, in >> this case, an island tile... > ftp://ftp.ihg.uni-duisburg.de/FlightGear/TGShapes/ > > http://wiki.openstreetmap.org/wiki/Shapefiles#Obtaining_shapefiles_from_OSM_data > > |
From: Fernando Hauscarriaga <fernandoph@gm...> - 2016-11-03 13:10:42
|
Hello Geoff, I've improved landmarks of Buenos Aires (roads, trains, trees, etc) by accessing our national geographic institute (that data is free and open) and I've noticed that, that kind of information is usually present in the municipality web sites of your area of interest, I may be a good idea to start explore that possibility and eventually try to find a contact in the area of interest that may give you the files. Cheers, Fer./ On Wed, Nov 2, 2016 at 9:36 PM, Geoff McLane <ubuntu@...> wrote: > Hi all, > > It has been quite a while since I built the > terragear suite of tools, and used them to > generate scenery tiles... > > Have successfully used 'gdalchop' to divide up, > say DEM 3 S18W150.hgt, and used 'terrafit' to > create the equivalent 'fit' files, in the 'SRTM-3' > dir... > > And successfully re-generated NTTM.btg.gz... looks > good, and seems equivalent to current terrasync, but ... > need some help... > > Where to get the land usage information, and the > roads, rivers, railways, ... data... to reconstruct, in > this case, an island tile... > > Any help appreciated... > > Regards, > Geoff > > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > -- Fernando P. Hauscarriaga |
From: Geoff McLane <ubuntu@ge...> - 2016-11-03 01:01:09
|
Hi all, It has been quite a while since I built the terragear suite of tools, and used them to generate scenery tiles... Have successfully used 'gdalchop' to divide up, say DEM 3 S18W150.hgt, and used 'terrafit' to create the equivalent 'fit' files, in the 'SRTM-3' dir... And successfully re-generated NTTM.btg.gz... looks good, and seems equivalent to current terrasync, but ... need some help... Where to get the land usage information, and the roads, rivers, railways, ... data... to reconstruct, in this case, an island tile... Any help appreciated... Regards, Geoff |
From: Kirill Popov <kirill.s.popov@gm...> - 2014-06-26 22:10:57
|
Thank you for the reply, Peter! After switching to scenery/ws2.0 I was able to build a working genapts850 and generate .apt -- Best regards, Kirill Popov. ---- Other ways to contact me: Gtalk: kirill.s.popov@... Cell phone: +79052062619 LinkedIn: http://ru.linkedin.com/in/kspopov On Fri, Jun 27, 2014 at 1:27 AM, Peter Sadrozinski <psadrozinski@...> wrote: > Sorry - this is my fault. terragear/master has some code for allowing the > tools to add vertex attributes. The vertex attribute code in the simgear > btg writer is not complete. > > Please move terragear to scenery/ws2.0 branch and build that - that should > be stable. > > Pete > > > On 06/26/2014 05:22 PM, Kirill Popov wrote: > > Hello, everyone! > > Today I've built a fresh simgear/terragear suite from sources > (simgear's repo at "next", terragear's one at "master"). Building is > done with download_and_compile.sh script (modified for Debug build > mode). > > When I start genapts850 like "./genapts850 --input=tiny_ULSG.dat > --work=. --threads=1 --airport=ULSG --verbose" I'm getting > Segmentation fault and partial results written into directory. Source > file tiny_ULSG.dat is attached. Compilation and running done in > VirtualBox under Ubuntu Trusty x64. > > Here are some details from gdb: > ============ Segfault message ================= > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffe81fa700 (LWP 5177)] > 0x00000000005bd200 in write_indices<unsigned short> > (fp=0x7fffe05f3c70, indexMask=27 '\033', vaMask=4294967295, > vertices=..., normals=..., colors=..., texCoords=..., vas=...) > at /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 > 341 write_indice(fp, static_cast<T>(vas[1][i])); > ========== end of Segfault message =============== > Backtrace is also attached. > > If I set a breakpoint at simgear/simgear/io/sg_binobj.cxx:341 I get > the following: > ============= Variables at breakpoint ================== > Breakpoint 1, write_indices<unsigned short> (fp=0x7fffe05edab0, > indexMask=27 '\033', vaMask=4294967295, vertices=..., > normals=..., colors=..., texCoords=..., vas=...) at > /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 > 341 write_indice(fp, static_cast<T>(vas[1][i])); > (gdb) print i > $1 = 0 > (gdb) print vas[1].size() > $4 = 0 > (gdb) print vaMask > $1 = 4294967295 > ================== End of variables at breakpoint =============== > So, the code part actually failing is: > 340 if (vaMask & SG_VA_INTEGER_1) { > 341 write_indice(fp, static_cast<T>(vas[1][i])); > 342 } > At the time crash happens, i == 0 and vaMask == 4294967295 ("1" in all > bits). But if we look at vas[1] size, it will be zero. And as in the > next line we're trying to call write_indice() with non-existing > vas[1][i], we're getting segfault. > > this is how I see the situation, correct me if I'm wrong. > Unfortunately, I did not manage to understand the code and fix the > issue myself, so I'm asking for help from SG/TG developers. > > Thank you in advance! > -- > Best regards, > Kirill Popov. > > ---- > Other ways to contact me: > Gtalk: kirill.s.popov@... > Cell phone: +79052062619 > LinkedIn: http://ru.linkedin.com/in/kspopov > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > > > > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > |
From: Peter Sadrozinski <psadrozinski@gm...> - 2014-06-26 21:27:25
|
Sorry - this is my fault. terragear/master has some code for allowing the tools to add vertex attributes. The vertex attribute code in the simgear btg writer is not complete. Please move terragear to scenery/ws2.0 branch and build that - that should be stable. Pete On 06/26/2014 05:22 PM, Kirill Popov wrote: > Hello, everyone! > > Today I've built a fresh simgear/terragear suite from sources > (simgear's repo at "next", terragear's one at "master"). Building is > done with download_and_compile.sh script (modified for Debug build > mode). > > When I start genapts850 like "./genapts850 --input=tiny_ULSG.dat > --work=. --threads=1 --airport=ULSG --verbose" I'm getting > Segmentation fault and partial results written into directory. Source > file tiny_ULSG.dat is attached. Compilation and running done in > VirtualBox under Ubuntu Trusty x64. > > Here are some details from gdb: > ============ Segfault message ================= > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffe81fa700 (LWP 5177)] > 0x00000000005bd200 in write_indices<unsigned short> > (fp=0x7fffe05f3c70, indexMask=27 '\033', vaMask=4294967295, > vertices=..., normals=..., colors=..., texCoords=..., vas=...) > at /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 > 341 write_indice(fp, static_cast<T>(vas[1][i])); > ========== end of Segfault message =============== > Backtrace is also attached. > > If I set a breakpoint at simgear/simgear/io/sg_binobj.cxx:341 I get > the following: > ============= Variables at breakpoint ================== > Breakpoint 1, write_indices<unsigned short> (fp=0x7fffe05edab0, > indexMask=27 '\033', vaMask=4294967295, vertices=..., > normals=..., colors=..., texCoords=..., vas=...) at > /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 > 341 write_indice(fp, static_cast<T>(vas[1][i])); > (gdb) print i > $1 = 0 > (gdb) print vas[1].size() > $4 = 0 > (gdb) print vaMask > $1 = 4294967295 > ================== End of variables at breakpoint =============== > So, the code part actually failing is: > 340 if (vaMask & SG_VA_INTEGER_1) { > 341 write_indice(fp, static_cast<T>(vas[1][i])); > 342 } > At the time crash happens, i == 0 and vaMask == 4294967295 ("1" in all > bits). But if we look at vas[1] size, it will be zero. And as in the > next line we're trying to call write_indice() with non-existing > vas[1][i], we're getting segfault. > > this is how I see the situation, correct me if I'm wrong. > Unfortunately, I did not manage to understand the code and fix the > issue myself, so I'm asking for help from SG/TG developers. > > Thank you in advance! > -- > Best regards, > Kirill Popov. > > ---- > Other ways to contact me: > Gtalk: kirill.s.popov@... > Cell phone: +79052062619 > LinkedIn: http://ru.linkedin.com/in/kspopov > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > > > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery |
From: Kirill Popov <kirill.s.popov@gm...> - 2014-06-26 21:22:32
|
Hello, everyone! Today I've built a fresh simgear/terragear suite from sources (simgear's repo at "next", terragear's one at "master"). Building is done with download_and_compile.sh script (modified for Debug build mode). When I start genapts850 like "./genapts850 --input=tiny_ULSG.dat --work=. --threads=1 --airport=ULSG --verbose" I'm getting Segmentation fault and partial results written into directory. Source file tiny_ULSG.dat is attached. Compilation and running done in VirtualBox under Ubuntu Trusty x64. Here are some details from gdb: ============ Segfault message ================= Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe81fa700 (LWP 5177)] 0x00000000005bd200 in write_indices<unsigned short> (fp=0x7fffe05f3c70, indexMask=27 '\033', vaMask=4294967295, vertices=..., normals=..., colors=..., texCoords=..., vas=...) at /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 341 write_indice(fp, static_cast<T>(vas[1][i])); ========== end of Segfault message =============== Backtrace is also attached. If I set a breakpoint at simgear/simgear/io/sg_binobj.cxx:341 I get the following: ============= Variables at breakpoint ================== Breakpoint 1, write_indices<unsigned short> (fp=0x7fffe05edab0, indexMask=27 '\033', vaMask=4294967295, vertices=..., normals=..., colors=..., texCoords=..., vas=...) at /root/fgfs/stable/simgear/simgear/io/sg_binobj.cxx:341 341 write_indice(fp, static_cast<T>(vas[1][i])); (gdb) print i $1 = 0 (gdb) print vas[1].size() $4 = 0 (gdb) print vaMask $1 = 4294967295 ================== End of variables at breakpoint =============== So, the code part actually failing is: 340 if (vaMask & SG_VA_INTEGER_1) { 341 write_indice(fp, static_cast<T>(vas[1][i])); 342 } At the time crash happens, i == 0 and vaMask == 4294967295 ("1" in all bits). But if we look at vas[1] size, it will be zero. And as in the next line we're trying to call write_indice() with non-existing vas[1][i], we're getting segfault. this is how I see the situation, correct me if I'm wrong. Unfortunately, I did not manage to understand the code and fix the issue myself, so I'm asking for help from SG/TG developers. Thank you in advance! -- Best regards, Kirill Popov. ---- Other ways to contact me: Gtalk: kirill.s.popov@... Cell phone: +79052062619 LinkedIn: http://ru.linkedin.com/in/kspopov |
From: Scott Hamilton <scott.fgfs@pl...> - 2014-02-03 09:14:39
|
For my fellow Australian scenery folk, If you're wondering what the view from YBBN tower is like, AirServices have snapped this nice pic... https://twitter.com/AirservicesNews/status/429012151504625664/photo/1 S. |
From: Scott Hamilton <scott.fgfs@pl...> - 2013-03-09 07:32:19
|
Greetings all, I've been making some custom scenery around Sydney, and the YSSY airport using the latest terragear code from http://gitorious.org/fg/terragear.git However I just sent a draft copy to someone else, and they are running FG V2.4, and they can't see any terrain at all. So I'm wondering if the tile format changed from V2.4 and that is why they can't see it, or if there is another problem. I'm running FG V2.11 (Git next) and it seems fine to me. A copy of the scenery tiles is available at https://docs.google.com/file/d/0B-sIKXDCw9CIR0NVZTE3OXBmYm8/edit?usp=sharing if anyone wants to try it out. cheers Scott. |
From: Vic Marriott <vic165@bt...> - 2013-03-04 17:15:57
|
Hi Hans, In FG there is only the main runway shown, plus a windsock at EGTD. I have thought of making the airport buildings before, but was unable to find any images of them. If you have some, or can arrange for some to be taken, I could make it a project. I would be interested to see your drive simulator. Cheers, Vic |
From: Gijs de Rooy <gijsrooy@ho...> - 2013-03-04 17:13:41
|
Hi Hans (and welcome!), nice to see PAL-V using FlightGear! As prospective Dutch aerospace engineer (I'm in the 2nd year at TU Delft) I've remotely followed PAL-V's progress. I would be more than happy to support you where possible/needed. I'll have a look at your layout this evening and if all is well I hope to send you a scenery build today. Cheers, Gijs Date: Mon, 4 Mar 2013 16:47:27 +0100 From: joore@... To: flightgear-scenery@... Subject: [Flightgear-scenery] Top Gear Test Track scenery! Dear developers, I am a fan of the show Top Gear, and I have made a realistic drive/flight MATLAB Simulator (PAL-V Simulator) that works with FlightGear 2.10.It would be fantastic if someone would model the little airport of Dunsfold, EGTD, home of the Top Gear tv program! This way I and many other enthousiasts can race around the track like the big stars. I have made a layout of the track in TaxiDraw (EGTD.dat) and World Editor (EGTD_wed.dat), but am not skilled enough to export it to the FlightGear scenery myself. Could any of you put the track in This track/airport would be very popular I can imagine. With kind regards, Hans Joore |
From: Hans Joore <joore@pa...> - 2013-03-04 15:59:52
|
From: Adrian Musceac <kantooon@gm...> - 2012-12-16 11:44:11
|
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote: > Hi Adrian, > > On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: > > I am presenting an experimental (WIP) method to reduce memory consumption > > by scenery with 30%, while increasing the visibility distance 4 times. > > This method relies on some kind of LOD system, without mesh > > simplification. People smarter than me can come up with a safe algorithm > > to do that, but I'm afraid it requires changes to Terragear. Right now > > mesh simplification was not > > Could you explain how your system works? > > Presumably you are making some change to the tiles for the low > resolution version? > > -Stuart Hi Stuart, It' basically very simple. Far tiles no longer compute anything other than it's own geometry, and also use a very low resolution texture set, obtained by running a batch resize on the regular texture set. This allows me to have 2.5 times larger view distance in high detail (SRTM) terrain with same memory consumption. There is of course a slight increase in disk IO, but I have only tested this with multithreading enabled on a dual core CPU. Load times for far tiles are actually smaller, since no calculations other than geometry and effects are performed on them. Inner tiles close to the viewer position are normal tiles, nothing changed. That's basically it. I need to refactor the code a bit before I can show it, I wrote it fast and while half asleep. Now, the really big stuff would be load-time mesh simplification, and I have read a couple of papers that seem to suggest that's possibile, but would require some changes to the BTG format. I leave that up to the Terragear guys, I am not very familiar with the way their mesh construction works. Cheers, Adrian |
From: HB-GRAL <flightgear@sa...> - 2012-12-11 23:03:07
|
Hi Adrian I had some mail exchange with Jonathan Ferranti/Viewfinderpanorama two years ago and he wrote me that he has no objection to my use of this data for terragear purposes (I planned a small and personal scenery project with this data two years ago and was sending a lot of requests around the world, always asking if this could be used for a GPL project). Generally Viewfinderpanorama needs credits for this of course, but it looks like the data is available for FlightGear/TerraGear projects, indeed. To say it in words of Jonathan Ferranti: "I hope that you find the data useful and that they will contribute to the quality of your scenery." Later I realised in discussion with Martin Spott that the World Scenery Project is "well known" at Viewfinderpanorama and that I just replicated what was already organized/prepared by Martin. It looks like the World Scenery Project already made use of this data and that parts of the data are also available via mapserver (not sure about, that has Martin Spott to point out probably, we had some exchange about this data because of my recent HGT-work some days/weeks ago, but I’m not sure about the recent status of such directories). Plans are (or should be) to have 1-2 servers where all this data is available as a "data central" with some consistency like Martin Spott always intended to have, and the flightgear mapserver with its infrastructur will be primary, even when I plan to make it available also here on my swiss servers (the fgx server, which has a good or at least sufficent backbone too). The origin reliefs will probably not be available on other servers. The problem here is that it takes ~ 300 GB space at the end, and maybe it’s also fairly experimental. But the tilecache produced with this data will be available, so when someone wants to use that relief service for a map it will show up in near future (hopefully!). Ehrm, this kind of work and data has "Slow Food"-Labeling ;-) -Yves Am 11.12.12 20:29, schrieb Adrian Musceac: > >> >> Hi Christian >> >> Nice to hear that there are some plans (?) with extending gdalchop. As I >> mentioned earlier I’m preparing 5x5 degree tiles of all the SRTM data in >> geotiff format to use with terragear (just in case someone wants to give >> it a try once, I use it for my reliefs and this 5x5 tiles are a side >> effect of processing this data). A 5x5 degree geotiff uncompressed will >> have around 72 MB. >> >> When it’s useful and gdalchop can handle this I can prepare the data >> with LZW compression, which makes it a bit faster, at least for the >> download ;-) Recently the compressed geotiff files will take about 25-30 >> GB for the "HGT-SRTM-World" coverage. >> >> The tiles have 6001 x 6001 pixels in EPSG:4326 projection. For the >> reliefs I needed to reproject the data to other projections (EPSG:3857 >> or i.e. 3112) and I used gdalwarp for this with lanczos interpolation, >> which gives me the best results for reliefs. Iin a graphical sense of >> course, I don’t know if it would be also the case for other purpose with >> lanczos. >> >> -Yves >> > > > Hi Yves, > > Having SRTM data available without the "normal but slightly restrictive" CGIAR > license would be a nice plus. > I do remember from FS2004 that there was a guy who had very detailed data > based on local topo maps and DEM's, his name was Jonathan de Ferranti and the > FS terrain was compiled by Holger Sandmann. > http://www.viewfinderpanoramas.org/dem3.html was the URL. > Can we get ahold of such detailed elevation maps, which far surpass SRTM, > especially for the Alps but other mountainous areas too? And could we use > this? > > Cheers, > Adrian > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > |
From: Adrian Musceac <kantooon@gm...> - 2012-12-11 19:28:45
|
> > Hi Christian > > Nice to hear that there are some plans (?) with extending gdalchop. As I > mentioned earlier I’m preparing 5x5 degree tiles of all the SRTM data in > geotiff format to use with terragear (just in case someone wants to give > it a try once, I use it for my reliefs and this 5x5 tiles are a side > effect of processing this data). A 5x5 degree geotiff uncompressed will > have around 72 MB. > > When it’s useful and gdalchop can handle this I can prepare the data > with LZW compression, which makes it a bit faster, at least for the > download ;-) Recently the compressed geotiff files will take about 25-30 > GB for the "HGT-SRTM-World" coverage. > > The tiles have 6001 x 6001 pixels in EPSG:4326 projection. For the > reliefs I needed to reproject the data to other projections (EPSG:3857 > or i.e. 3112) and I used gdalwarp for this with lanczos interpolation, > which gives me the best results for reliefs. Iin a graphical sense of > course, I don’t know if it would be also the case for other purpose with > lanczos. > > -Yves > Hi Yves, Having SRTM data available without the "normal but slightly restrictive" CGIAR license would be a nice plus. I do remember from FS2004 that there was a guy who had very detailed data based on local topo maps and DEM's, his name was Jonathan de Ferranti and the FS terrain was compiled by Holger Sandmann. http://www.viewfinderpanoramas.org/dem3.html was the URL. Can we get ahold of such detailed elevation maps, which far surpass SRTM, especially for the Alps but other mountainous areas too? And could we use this? Cheers, Adrian |
From: HB-GRAL <flightgear@sa...> - 2012-12-11 18:57:23
|
Am 11.12.12 19:42, schrieb HB-GRAL: > > When it’s useful and gdalchop can handle this I can prepare the data > with LZW compression, which makes it a bit faster, at least for the > download ;-) Recently the compressed geotiff files will take about 25-30 > GB for the "HGT-SRTM-World" coverage. Have to correct myself, it’s "only" around 16 or 17 GB of data, compressed. The coverage of SRTM data is +- 60 degrees latitude, but I will be able to add some other sources soon I hope, with same 5x5 merged tiling. btw. I didn’t change the naming convention of tiles like CGIAR data does, so the tif names are i.e. "N40W010.tif" or "S10E135.tif" etc. (lower left corner when I’m not wrong ;-) -Yves |
From: HB-GRAL <flightgear@sa...> - 2012-12-11 18:42:16
|
Am 11.12.12 14:51, schrieb Christian Schmitt: > Adrian Musceac wrote: > >> I really hope my toolchain will work on the next issue of terragear :) >> Do we still have terrafit which outputs .fit.gz, and ogr-decode does >> function the same way? Right now I'm on the right path, but it's bumpy. >> I think there's a real need for a LOD system, or another system which >> would allow loading terrain as far as 300 km away, perhaps without adding >> at load time random elements, lights, and stuff. Unfortunately I'm not >> very familiar with OSG database pagers and the underlyings in simgear. >> > > Hi Adrian, > > generally, yes a LOD system would be nice, but it would need considerable > changes on the btg format or a switch to something new. > I'm currently investigating how to make elevation calculation for the > terrain easier and more versatile. I want to use gdalchop for general > processing as gdal reads almost all kinds of raster formats. So we would no > longer have to rely on hgtchop, srtmchop and demchop (yes, it's mad). Hi Christian Nice to hear that there are some plans (?) with extending gdalchop. As I mentioned earlier I’m preparing 5x5 degree tiles of all the SRTM data in geotiff format to use with terragear (just in case someone wants to give it a try once, I use it for my reliefs and this 5x5 tiles are a side effect of processing this data). A 5x5 degree geotiff uncompressed will have around 72 MB. When it’s useful and gdalchop can handle this I can prepare the data with LZW compression, which makes it a bit faster, at least for the download ;-) Recently the compressed geotiff files will take about 25-30 GB for the "HGT-SRTM-World" coverage. The tiles have 6001 x 6001 pixels in EPSG:4326 projection. For the reliefs I needed to reproject the data to other projections (EPSG:3857 or i.e. 3112) and I used gdalwarp for this with lanczos interpolation, which gives me the best results for reliefs. Iin a graphical sense of course, I don’t know if it would be also the case for other purpose with lanczos. -Yves |
From: Adrian Musceac <kantooon@gm...> - 2012-12-11 15:08:06
|
On Tuesday, December 11, 2012 15:51:06 Christian Schmitt wrote: > Hi Adrian, > > generally, yes a LOD system would be nice, but it would need considerable > changes on the btg format or a switch to something new. > I'm currently investigating how to make elevation calculation for the > terrain easier and more versatile. I want to use gdalchop for general > processing as gdal reads almost all kinds of raster formats. So we would no > longer have to rely on hgtchop, srtmchop and demchop (yes, it's mad). > Also, depending on what is possible, i would like to get rid of terrafit. > We have great SRTM data, reduce the amount of points and then have to > interpolate like mad when we need the elevation of a certain point. GDAL > has interpolation routines included (beyond linear interpolation) and I'd > like to make use of that. I noticed yesterday, that there is already > gdallocationinfo which reads the elevation on the fly for a given lat/lon. > This might be worth investigating. > > Cheers > Chris Hi Chris, You are correct about SRTM and GDAL, but I'd like to add that my greatest problem now is not reading the elevation (this is already done, albeit innacurately), but reading and placing the material information in the same table as the elevaton info. And this I can currently do only by using polygon output from ogr-decode. Also, I'm relying on text files generated by terrafit, because I have a simple python script to get that into the database. I'll see how to adapt in the future. The wonders of using sqlite is that you can attach and detach on the fly databases to the main connection, and if you have unique tables, the amount of code needed is really small to handle transition from one area to another. I already have elevation sampling working in Flightgear with 10x10 degree tiles (for whatever distance that allows), the very nasty trick is obtaining that material information for each point and I'm currently working on a fast method to get that info. Right now I take polygons as generated by ogr-decode, and apply the GEOS routine Within test for each elevation point. Considering 12,000,000 elevation points for a 10x10 tile, and lots of polygons generated by ogr-decode, it's literally taking days or weeks to complete this. I will dedicate some time in the future to think about terrain LOD without significant changes to the BTG format. The current system is definetly inferior to most every other simulator out there. Cheers, Adrian |
From: Christian Schmitt <chris@il...> - 2012-12-11 13:51:09
|
Adrian Musceac wrote: > I really hope my toolchain will work on the next issue of terragear :) > Do we still have terrafit which outputs .fit.gz, and ogr-decode does > function the same way? Right now I'm on the right path, but it's bumpy. > I think there's a real need for a LOD system, or another system which > would allow loading terrain as far as 300 km away, perhaps without adding > at load time random elements, lights, and stuff. Unfortunately I'm not > very familiar with OSG database pagers and the underlyings in simgear. > Hi Adrian, generally, yes a LOD system would be nice, but it would need considerable changes on the btg format or a switch to something new. I'm currently investigating how to make elevation calculation for the terrain easier and more versatile. I want to use gdalchop for general processing as gdal reads almost all kinds of raster formats. So we would no longer have to rely on hgtchop, srtmchop and demchop (yes, it's mad). Also, depending on what is possible, i would like to get rid of terrafit. We have great SRTM data, reduce the amount of points and then have to interpolate like mad when we need the elevation of a certain point. GDAL has interpolation routines included (beyond linear interpolation) and I'd like to make use of that. I noticed yesterday, that there is already gdallocationinfo which reads the elevation on the fly for a given lat/lon. This might be worth investigating. Cheers Chris |
From: Peter Sadrozinski <psadrozinski@gm...> - 2012-12-11 12:40:09
|
Actually, we are in the process of modifying quite a few of these intermediate files. But the changes should make it easier for you long term. Hgtfit should now be saving binary data instead of text to the .gz file I'm in the 'thinking' stage for ogr-decode. I'll probably change the output polygon format quite a bit. But the new terragear polygon class (TGPolygon is being refactored to tgPolygon) has the capability to load and save themselves to a gz stream. You will most likely be able to do this. I'm working on this now. Should be ready in a couple weeks. Ogr-decode appears io bound on my computer. I'm going to try to limit the shear number of files created by ogr-decode. Pete On Dec 11, 2012 7:28 AM, "Adrian Musceac" <kantooon@...> wrote: > On Tuesday, December 11, 2012 14:18:37 Peter Sadrozinski wrote: > > Possibly more difficult to set up, but I'm adding more and more CGAL > > routines to terragear. > > > > I just commited a find points within bounding box which improved my > lookup > > times by 20%. > > > > To find points within, what you really want is to create a CGAL > > arrangement, then you can query a point and it should be really quick. > > > > See > > > http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Arrangement_2/Chapter_m > > ain.html > > > > Pete > > > > Hi Pete, > I really hope my toolchain will work on the next issue of terragear :) > Do we still have terrafit which outputs .fit.gz, and ogr-decode does > function > the same way? Right now I'm on the right path, but it's bumpy. > I think there's a real need for a LOD system, or another system which would > allow loading terrain as far as 300 km away, perhaps without adding at load > time random elements, lights, and stuff. Unfortunately I'm not very > familiar > with OSG database pagers and the underlyings in simgear. > > I'm off to research CGAL now. > > Cheers, > Adrian > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > |
From: Adrian Musceac <kantooon@gm...> - 2012-12-11 12:28:01
|
On Tuesday, December 11, 2012 14:18:37 Peter Sadrozinski wrote: > Possibly more difficult to set up, but I'm adding more and more CGAL > routines to terragear. > > I just commited a find points within bounding box which improved my lookup > times by 20%. > > To find points within, what you really want is to create a CGAL > arrangement, then you can query a point and it should be really quick. > > See > http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Arrangement_2/Chapter_m > ain.html > > Pete > Hi Pete, I really hope my toolchain will work on the next issue of terragear :) Do we still have terrafit which outputs .fit.gz, and ogr-decode does function the same way? Right now I'm on the right path, but it's bumpy. I think there's a real need for a LOD system, or another system which would allow loading terrain as far as 300 km away, perhaps without adding at load time random elements, lights, and stuff. Unfortunately I'm not very familiar with OSG database pagers and the underlyings in simgear. I'm off to research CGAL now. Cheers, Adrian |
From: Peter Sadrozinski <psadrozinski@gm...> - 2012-12-11 12:18:48
|
Possibly more difficult to set up, but I'm adding more and more CGAL routines to terragear. I just commited a find points within bounding box which improved my lookup times by 20%. To find points within, what you really want is to create a CGAL arrangement, then you can query a point and it should be really quick. See http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Arrangement_2/Chapter_main.html Pete On Dec 11, 2012 6:02 AM, "Adrian Musceac" <kantooon@...> wrote: > On Tuesday, December 11, 2012 11:03:41 HB-GRAL wrote: > > > > > Hi Adrian > > > > Maybe this link could contain some useful information for you, I don’t > > know ... > > http://trac.osgeo.org/postgis/wiki/WKTRasterTutorial01 > > > > As far as I understand you're working with sqlite. I don’t know if this > > is the best dbms for what you’re doing (problems with indexing, filelock > > etc.). Here is a postgres alternative which extends sqlite core for GIS: > > https://www.gaia-gis.it/fossil/libspatialite/index > > > > -Yves > > > > Hi Yves, > I have to work with sqlite as it is an embeddable database (like you can > take > the file and use it anywhere). For my purposes it's the only solution. > But the bottleneck is not in sqlite anymore. > Meanwhile I've identified a bug which made my code incredibly slow. > Right now I'm looking at 10 full days to fill a 10x10 degree elevation > database with material info. I will try to optimize even further, I > believe I > can. I'm using output from ogr-decode, srtmchop and terrafit. I will try to > keep the wiki article updated too. > > I tried using GEOS directly but it segfaults quite often with latest > version, > so I abandoned it. Right now I'm using GDAL/OGR with GEOS bindings. > > With this, terrain sampling 100-1000 km away will be possible, as long as > one > keeps the number of sampled points reasonable. Size of the database > remains a > problem, as well as time to get it. > > Cheers, > Adrian > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > |
From: Adrian Musceac <kantooon@gm...> - 2012-12-11 11:02:15
|
On Tuesday, December 11, 2012 11:03:41 HB-GRAL wrote: > > Hi Adrian > > Maybe this link could contain some useful information for you, I don’t > know ... > http://trac.osgeo.org/postgis/wiki/WKTRasterTutorial01 > > As far as I understand you're working with sqlite. I don’t know if this > is the best dbms for what you’re doing (problems with indexing, filelock > etc.). Here is a postgres alternative which extends sqlite core for GIS: > https://www.gaia-gis.it/fossil/libspatialite/index > > -Yves > Hi Yves, I have to work with sqlite as it is an embeddable database (like you can take the file and use it anywhere). For my purposes it's the only solution. But the bottleneck is not in sqlite anymore. Meanwhile I've identified a bug which made my code incredibly slow. Right now I'm looking at 10 full days to fill a 10x10 degree elevation database with material info. I will try to optimize even further, I believe I can. I'm using output from ogr-decode, srtmchop and terrafit. I will try to keep the wiki article updated too. I tried using GEOS directly but it segfaults quite often with latest version, so I abandoned it. Right now I'm using GDAL/OGR with GEOS bindings. With this, terrain sampling 100-1000 km away will be possible, as long as one keeps the number of sampled points reasonable. Size of the database remains a problem, as well as time to get it. Cheers, Adrian |
From: HB-GRAL <flightgear@sa...> - 2012-12-11 10:21:14
|
Am 10.12.12 20:20, schrieb Adrian Musceac: > On Monday, December 10, 2012 19:15:49 you wrote: >> Am 10.12.12 16:41, schrieb Adrian Musceac: > >> >> Hi Adrian >> >> Maybe you can try postgis (which uses GEOS too) and compare performance >> with your tool/own bindings? >> >> -Yves > > Hi Yves, > It's actually not the database format but rather gdal/ogr with GEOS that's > slow. I'll try more research in postgis, but aren't they using as a backend > OGR/GDAL too? > > Cheers, > Adrian > Hi Adrian Maybe this link could contain some useful information for you, I don’t know ... http://trac.osgeo.org/postgis/wiki/WKTRasterTutorial01 As far as I understand you're working with sqlite. I don’t know if this is the best dbms for what you’re doing (problems with indexing, filelock etc.). Here is a postgres alternative which extends sqlite core for GIS: https://www.gaia-gis.it/fossil/libspatialite/index -Yves |
From: Adrian Musceac <kantooon@gm...> - 2012-12-10 15:41:41
|
Hi guys, I know there's not much activity on this list, but I have a question directed at the terragear developers especially. I have a list of coordinates, namely elevation points, and a list of polygons, obtained by ogr-decode (lots of polygons, obtained through Corine). Now, I've written my own tool which uses gdal/ogr with GEOS bindings, in order to perform the OGRGeometry::Within() test for each point. (Actually I'm using a very small line because points tend to give me an exception). So far so good, except for the fact that I have about 900 tables each with 12000 + coordinate points. The Within test performed by GEOS takes too long. I've calculated that I would need 40 days to fill my database which is unacceptable. I wonder if anybody has a better solution to my problem rather than using the point-in-poly routine of GEOS. I've not tried shapefiles, because ogr-decode gives me exactly the name/type of terrain used by Flightgear. I'm considering writing a program using an OSG intersect visitor on each small btg tile, but I don't know whether that would be any faster at all. Thanks for any answers. Cheers, Adrian |
From: HB-GRAL <flightgear@sa...> - 2012-12-02 11:21:09
|
Thanks to Martin Spott the filled SRTM data I produced is now also available from the mapserver: http://scenery.flightgear.org/geodata/fgx/ There will come a link for merged 5x5 tiles too the next days, weeks or months ;-) -Yves Am 12.11.12 01:26, schrieb HB-GRAL: > Hi all > > Some time ago I published "no-data-hole-filled" and interpolated SRTM-3 > data (SRTM/HGT) that can be used for flightgear scenery generation. > Actually I merged this data to 5x5 degree tiles like used i.e. with > CGIAR data (so called SRTM 4 ff). > > Now my data follows SRTM file name specification and not CGIAR renaming. > There is a tool in terragear toolchain, gdalchop, which obviously can > handle 5x5 DEM chunks, but it deals with CGIAR file names when I’m not > wrong. Can someone help me to improve gdalchop to read the newly created > 5x5 elevation data files named in "SRTM convention" (means i.e. > N40W005.tif for lat 40 to 44 and lon -5 to 0 ) to fit flightgear license > also with this merged data ? > > I will make that data available on flightgear mapserver the next weeks. > It will be public domain like the origin, and not in a restricted > non-commercial license like CGIAR provides. Of course, the interpolation > is not that sophisticated and partially reworked like CGIAR data, but > just with common interpolation it will be much better than bare SRTM > data anyway. Any help with terragear elevation tools is much appreciated > here. > > -Yves > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Flightgear-scenery mailing list > Flightgear-scenery@... > https://lists.sourceforge.net/lists/listinfo/flightgear-scenery > |