suggestion: airport repository

[lomar]

well, thinking about the shutdown of google code and the need of a new hosting for terrasync today, i've had an idea: what if there is a repository for the airports apart from a scenery one?

Let me explain: even in the new WS2.0, there are tons of airports using the old .810 layout,and even with only the runway. And i know that even in the next scenery build it will remain some of these. So, my suggestion is, for creating(i could not think about the "where" yet) a repository containing all the airports of FG, apart of the main terrasync server. these airports could be downloaded individually(just like the livery database), and used as custom scenery, so would be much easier to have an updated airport layout, without having to wait until the next scenery build. the airport package downloded could have the ICAO.stg file for scenery use, aswel as the .wed file for the case the user wants to generate the airport himself or update it by his own. Also, the data from the x-plane gateway could also help in this.
I hope you enjoy this idea...

[Thorsten]

If they're not built with the surrounding terrain, they won't fit - they may come out below the terrain in which case you don't see them, they may cut holes into the terrain mesh, they may float above the terrain...

Airports are very much part of the scenery, which is why they're generated by the scenery toolchain.

[pommesschranke]

lomar, I like your idea.
I already offer ICAO.btg.gz for > 2000 airports.
I can offer all airports like this, but that's 1.2GB

@Thorsten:
wrong elevation is not a big issue anymore, just a cosmetic one. genapts850 uses the global elevation data that I downloaded from viewfinderpanoramas. If the little gap would be green instead of sky-blue, nobody would notice it.

If the outside shape of the airport changed, then the old terrain might food important parts of the airport. Then the surrounding tile has to be made. That is less work than making tiles for the whole world.

https://github.com/mherweg/AirportObj
http://media.lug-marl.de/flightgear/Terrain/

[Hooray]

If they're not built with the surrounding terrain, they won't fit - they may come out below the terrain in which case you don't see them, they may cut holes into the terrain mesh, they may float above the terrain...

Airports are very much part of the scenery, which is why they're generated by the scenery toolchain.

Thorsten is right about airports vs. scenery tiles - however, psadro_gm, Zakalawe and others have been wanting to change this for years, i.e. so that airports can be "baked" into terrain mesh at runtime (to be fair, this is basically how X-Plane and osgEarth work behind the scenes):

Subject: Scenery Draping

My idea is to generate a seamless terrain, and drape the airport data on top of it at runtime. (I believe this is similar to how x-plane works). What this means is that whatever LOD the terrain is, the airport will be draped on top of it, and follow the terrain underneath, much like placing a cloth on top of a 3d object.
[...]
Next, I'll need to save the airport polygons into a new 2d file, and then add the capability to load and drape the polys to simgear. I've described how I plan to do this here:

http://wiki.flightgear.org/TerraGear_su ... or_Draping

Subject: Scenery Draping

The reason is, we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).

The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG.

Subject: Scenery Draping

I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.

Pete

Subject: Scenery Draping

I'd love to fully generate the apts at runtime.

Just so that you know, fully dynamically created airports is another really long-standing scenery related idea, that's been discussed among core developer on and off for over a decade already, including David Megginson and Andy Ross:
http://www.mail-archive.com/flightgear- ... 35539.html

What about a purely symbolic representation? Store just centerline
and width for each taxiway, and keep the existing polygonal
representation for "tarmac" areas. Throw out the "pre-cut" airport

This means that the tile loader will be forced to do some
computational geometry at load time to decide on the actual polygons
to be rendered by OpenGL. But that's not likely to be too much --
even the biggest airpots have no more than 30 taxiways with no more
than ~4 curves on each. Figure an individual curve has no more than
10 segments, with 6 polygons for each segment (two yellow paint, four
pavement). So that's a few thousand polygons generated and intersect
per airport loaded. Not so bad, really -- note that because it can
happen in the loader thread, and therefore make good use of the
multi-dispatch multi-core CPUs that are becoming so popular these
days.

The biggest advantage is that (if you do it with the runways too) it
means that the airports can be generated at runtime and edited by the
user without doing a terragear scenery regeneration.

Andy

http://www.mail-archive.com/flightgear- ... 03349.html

I think that it would be possible to generate airports dynamically at
runtime by cutting a hole in the mesh, but it would be a lot of work
and no one's volunteering yet. It's something we'll want to get to
eventually.


All the best,


David

http://www.mail-archive.com/flightgear- ... 09043.html

How about doing the light generation at tile load time, instead of
generation time? This would have big payoffs for maintenance --
someone could fix lighting configurations without regenerating the
whole tile.

My assumption would be that this process is pretty quick -- one
hitlist computation per light -- and wouldn't impact performance
noticeably.

As was said previously, X-Plane has been doing that for years - and meanwhile we may have the computing power (and idle cores!) to actually sonsider doing that in FG, too. So it would be a great addition and would quite certainly lower the entry barrier for people doing scenery development if airport changes became directly visible without having to go through the hassle of running TG tools.

[Thorsten]

wrong elevation is not a big issue anymore, just a cosmetic one. genapts850 uses the global elevation data that I downloaded from viewfinderpanoramas. If the little gap would be green instead of sky-blue, nobody would notice it.

... except for the people who still run the old scenery who find their airports sunk or floating...

Or, if you use (literally) the same elevation data, you'll going to get z-fighting when you place the airport over the terrain without cutting a hole.

Which means you have to rebuild the tile. Which means unless you build the surrounding tiles consistently, you'll get seams. You have to do it like Pete suggested - drape it.

[f-ojac]

There already were somes debates on this, with pros and cons.

My opinion (c) is that maintaining a separate repository for airports will lead users into confusion. They already are with some aspects of FG respositories, we really need to make it easy.
The Terragear/Terrasync toolchain has shown its strength and weaknesses. We'd all love to see the airport we've just sent to XPlane gateway appear updated in FG for a flight.
Since there's - for the moment - no solution to draw scenery at startup, let's not go waste resources :
1. Help Pete, James and others working on making scenery build at startup a reality without having to buy myself a Cray.
2. Let's continue to contribue upwards to XPlane community scenery gateway (avoid maintaining different apt.dat data as we've been doing in the past).
3. Continue enhancing the Terragear/Terrasync infrastructure. Especially, let's shorten the delay between the update of a .dat on XPlane scenery infrastructure and its broadcast via Terrasync. Once the terrasync, terragear and mapserver toolchains are back again, this should be on our top list.