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.


On Dec 11, 2012 7:28 AM, "Adrian Musceac" <> 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
> 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.


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
Flightgear-scenery mailing list