Re: RFC: Taxiway/Apron heuristics

On 4/5/04 at 8:10 PM Curtis L. Olson wrote:

>David Luff wrote:
>
>>The problem is that I was proposing generating the entire default airport
>dataset first, followed by a small set of (duplicate) hand-modified
>airports without blowing away the original AirportAreas and AirportObjs. 
>I.e. generating the scenery following *two* passes of genapts on
>overlapping data.  See my other post for what I think is a reasonable
>workaround for this.
>>  
>>
>
>I'd prefer to see this problem solved on the data input side rather than 
>coding around it in terragear and making terragear that much more complex.
>

I certainly see your point, and admire your resolve as the guardian of
TerraGear's code integrity and elegance against the hordes of band-aiding
invaders ;-), but I'd think of it more as adding a feature / robustness to
TerraGear than just band-aiding round a problem.  It seems to me that being
able to use more than one input data file is a feature.  You're looking at
it from a whole-world automatic-generation point of view, but put your user
hat on for a minute.  Imagine the following - user generates some scenery
using the default airports.  User then edits one airport, possibly reducing
the hole size, and then wants to just regenerate that airport + scenery
tile, either from a new .twy file or even from the main file using the
--airport option (if it exists).  At the moment TerraGear simply isn't
robust to this - the user needs to remove the poly file at at least tile
scope (if [s]he can figure out the tile numbering and knows that all the
airports in that tile don't extend over the tile boundary), and needs to
remove a 3x3 degree chunk to be absolutey sure of getting rid of any poly
segments that might have strayed over a tile boundary at the corner of a
1x1 degree chunk!  However - all the airports and scenery then need to be
regenerated in the 3x3 chunk, so the adjoining chunks to this need
removing.  Until eventually, the user must remove the entire area to be
regenerated, plus a 1 degree (or one tile if [s]he can decipher the tile
numbers) wide 'skirt' around the area.  At the moment this problem isn't
obvious since virtually no-one reduces the size of airports.

On the other hand - those degenerate cases would indeed make the code very
messy.  I had naively assumed last night that a simple polygon overlapping
check would do, but in fact the degenerate tile-spanning cases would
require common-edge checking of all possible cases with the overlapped poly
before it could be said definitively that no extraneous holes exist.  And
then of course there's the really degenerate case where a wrongly
positioned airport has been moved so far that it no longer overlaps at all!
 Maybe we could add an airport-id tag to the airport polys?

Anyway, talk is cheap, if I get some actual working code that seems to be
robust to the most degenerate cases and isn't too messy then I'll put my
best flame-proof vest on and try to convince you of it's merits ;-)

Cheers - Dave