Re: RFC: Taxiway/Apron heuristics

"Curtis L. Olson" writes:

> Jon Stockill wrote:
> 
> >Does this work? When you generate the airports it generates the terrain
> >holes for them to go in too - if you overwrite the airport then then
> >airport object is fine, but what happens to the hole polygon? Presumably
> >as long as the new airport is bigger than the old one there won't be any
> >problem, but in the case where a runway is repositioned I can see this
> >causing problems.
> >  
> >
> 
> If the airport perimeter changes, then if it grows there will be 
> overlaps with the existing scenery, if it shrinks there will be gaps; 
> neither is desireable.
> 

I think I see the problem - each time an airport is generated it adds a hole polyon to the appropriate file, so if all airports followed by a subset of airports are generated the hole will be generated twice, and may be different if the airport has changed?

If my understanding of that is correct, then as far as I can tell it would be a reasonably simple matter to test for the hole polygon overlapping with an existing hole polygon, and removing the first one if so.  This would assume that no two airport's perimeters overlap.  This assumption could be tested by generating the entire default airport set with a big warning emitted if a hole was removed for this reason.

Feasable?

> I believe Robin is pretty forthcoming if the data is submitted in 
> X-Plane format, but he doesn't have an import converter for the FG format.
> 

I suppose I should add an X-Plane format export to TaxiDraw.  Do we loose any data in this case, or is it simply a different format of the same data?

Cheers - Dave