headers
David Luff | 4 Apr 2004 20:59

RFC: Taxiway/Apron heuristics

Looking at the CVS log entries, I see that the taxiway/apron heuristics were modified late last year:

====================

Get a little smarter about guessing what's an apron:

Before:

- if it's a concrete taxiway over 150 ft wide, assume it's an apron
  (confusingly called "tiedown")

After:

- if it's an asphalt or concrete taxiway over 150 ft wide, *or* if
  it has no blue taxiway lights, assume it's an apron

====================

This has certainly cut down on aprons with taxiway markings that looked horrible, but at smaller airports
without taxiway lighting everything is coming out as apron - there's no taxiway lines.

I'd like to modify it to the following:

- if it's an asphalt or concrete taxiway over 150 ft wide, *or* if
  it's wider than it's long, assume it's an apron.

I'd then make it clear in the TaxiDraw tutorial that the best way to make a small segment of apron come out as
apron is to orientate it so that the longer axis is the width, not the length.  This is easy to do as
centrelines can be displayed.  The TaxiDraw tutorial is almost finished - it was whilst generating the
example airport in the scenery that I noticed the lack of taxiway markings.
(Continue reading)

Permalink | Reply | 21 comments |
headers
David Megginson | 4 Apr 2004 23:59

Re: RFC: Taxiway/Apron heuristics

David Luff wrote:

> This has certainly cut down on aprons with taxiway markings that looked
> horrible, but at smaller airports without taxiway lighting everything is
> coming out as apron - there's no taxiway lines.

That's not a bad match for real life -- small airports without taxiway 
lighting often don't have lines painted on the taxiways either.  Of course, 
we do need to make it selectable somehow.

> I'd like to modify it to the following:
> 
> - if it's an asphalt or concrete taxiway over 150 ft wide, *or* if it's
> wider than it's long, assume it's an apron.

A much better solution is for us to add a field to the runway format 
distinguishing taxiway from apron.  We have hundreds or thousands of 
existing aprons, and they'd have stripes all over them.  In the meantime, 
the lack of a taxiway centreline is not all that noticeable (at least not 
compared to stripey aprons).

All the best,

David
Permalink | Reply | 20 comments |
headers
Jonathan Richards | 5 Apr 2004 00:50
Picon
Favicon
Gravatar

Segmentation fault in genapts

Hello
I am trying to build 3 arcsecond scenery for the UK, and am getting a 
consistent segfault from genapts.  Here is a gdb listing:
[jonathan <at> localhost airports]$ gdb /usr/local/bin/genapts
GNU gdb 5.3-22mdk (Mandrake Linux)
(gdb) set args --input=runways.dat.gz --work=../../work --min-lon=-11 
--max-lon=+2 --min-lat=49 --max-lat=60
(gdb) run
...[# Builds 49 airports, then]...
Skipping airport EG13
Building EG13
e000n50/e000n52/2958266
This runway is not long enough for visual markings!

Program received signal SIGSEGV, Segmentation fault.
0x080efa55 in gpc_polygon_clip (op=GPC_DIFF, subj=0x859bdc0,
    clip=0x859bdc0, result=0x858d988) at gpc.c:1658
1658    gpc.c: No such file or directory.
        in gpc.c
Current language:  auto; currently c
(gdb) where
#0  0x080efa55 in gpc_polygon_clip (op=GPC_DIFF, subj=0x859bdc0,
    clip=0x859bdc0, result=0x858d988) at gpc.c:1658
#1  0x080b074a in polygon_clip(clip_op, TGPolygon const&, TGPolygon const&)
    (poly_op=POLY_DIFF, subject= <at> 0xbfffd3b0, clip= <at> 0xbfffe6e0)
    at polygon.cxx:381
#2  0x080b0a18 in polygon_diff(TGPolygon const&, TGPolygon const&) (
    subject= <at> 0xbfffd3b0, clip= <at> 0xbfffe6e0) at polygon.cxx:420
#3  0x0809e763 in gen_runway_section(TGRunway const&, TGPolygon const&, 
double, double, double, double, double, double, double, double, double,
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Luff | 5 Apr 2004 00:20

Re: RFC: Taxiway/Apron heuristics

David Megginson writes:

> David Luff wrote:
> 
> > This has certainly cut down on aprons with taxiway markings that looked
> > horrible, but at smaller airports without taxiway lighting everything is
> > coming out as apron - there's no taxiway lines.
> 
> That's not a bad match for real life -- small airports without taxiway 
> lighting often don't have lines painted on the taxiways either.  Of course, 
> we do need to make it selectable somehow.
> 
> > I'd like to modify it to the following:
> > 
> > - if it's an asphalt or concrete taxiway over 150 ft wide, *or* if it's
> > wider than it's long, assume it's an apron.
> 
> A much better solution is for us to add a field to the runway format 
> distinguishing taxiway from apron.  We have hundreds or thousands of 
> existing aprons, and they'd have stripes all over them.  In the meantime, 
> the lack of a taxiway centreline is not all that noticeable (at least not 
> compared to stripey aprons).
> 

Yes, I take your point, it would break the majority of existing layouts.  An apron / taxiway field would be
good - I'm not sure how easy that would be to implement given that we rely on a joint database though.

I'll put it in as a commandline switch in my own tree for doing .twy files where I want that behaviour.

Cheers - Dave
(Continue reading)

Permalink | Reply | 19 comments |
headers
Erik Hofman | 5 Apr 2004 10:30

Re: RFC: Taxiway/Apron heuristics

David Luff wrote:

> Yes, I take your point, it would break the majority of existing layouts.  An apron / taxiway field would be
good - I'm not sure how easy that would be to implement given that we rely on a joint database though.

We really should create our own taxiway/airport database.
Robin Peel has proven to be really unreliable and every time you mention 
it's for FlightGear the data gets rejected. I've invested quite some 
time in adding taxiways to Dutch airports, and modifying existing ones 
where I knew they had to change but there have been four months without 
any sign of them getting in his database.

Jon, are you still interested in maintaining our own databases?

The way it is now we could reduce the effort by maintaining changes to 
the X-Plane database, so creating or own database would be:

1. import the Peel database
2. override known entries with our own.

Erik
Permalink | Reply | 18 comments |
headers
Jon Stockill | 5 Apr 2004 16:23
Picon

Re: RFC: Taxiway/Apron heuristics

On Mon, 5 Apr 2004, Erik Hofman wrote:

> Jon, are you still interested in maintaining our own databases?
>
> The way it is now we could reduce the effort by maintaining changes to
> the X-Plane database, so creating or own database would be:
>
> 1. import the Peel database
> 2. override known entries with our own.

I can write something to store the current database - the question then is
how do we manage updates - if details of an airfield in the Peel database
change, and we have a custom version of it too, then which do we go with,
and should we modify anything?

I'm a little bit busy at the moment, and expo preparations are taking up
most of my spare time. Things should be a bit less hectic in a month or
so.

--

-- 
Jon Stockill
jon <at> stockill.org.uk
Permalink | Reply | 17 comments |
headers
Erik Hofman | 5 Apr 2004 16:27

Re: RFC: Taxiway/Apron heuristics

Jon Stockill wrote:
> On Mon, 5 Apr 2004, Erik Hofman wrote:
> 
> 
>>Jon, are you still interested in maintaining our own databases?
>>
>>The way it is now we could reduce the effort by maintaining changes to
>>the X-Plane database, so creating or own database would be:
>>
>>1. import the Peel database
>>2. override known entries with our own.
> 
> 
> I can write something to store the current database - the question then is
> how do we manage updates - if details of an airfield in the Peel database
> change, and we have a custom version of it too, then which do we go with,
> and should we modify anything?

The parts of the Peel database that come from DAFIF(T) take precedence 
over any other data, the information of our own database takes 
precedence over the Peel data otherwise.
> 
> I'm a little bit busy at the moment, and expo preparations are taking up
> most of my spare time. Things should be a bit less hectic in a month or
> so.

There is no rush, it can take a couple of months if needed.

Erik
(Continue reading)

Permalink | Reply | 13 comments |
headers
David Megginson | 5 Apr 2004 16:39

Re: RFC: Taxiway/Apron heuristics

Jon Stockill wrote:

> I can write something to store the current database - the question then is
> how do we manage updates - if details of an airfield in the Peel database
> change, and we have a custom version of it too, then which do we go with,
> and should we modify anything?

We need a source field for every entry (i.e. "Peel", "DAFIF", "FAA").  We 
should have both in the database, and allow a way to set preferences when 
exporting a config file.

All the best,

David
Permalink | Reply | 2 comments |
headers
Curtis L. Olson | 5 Apr 2004 17:22

SRTM 30 arcsec data

A while back, one of the 30 arcsec world terrain data sets was redone 
based on SRTM data and became much more accurate.  Does anyone remember 
the details of where this data came from.  Was in the "globe" project, 
"gnis"?  Something else?  Anyone have a url to the data?

Thanks,

Curt.

--

-- 
Curtis Olson   HumanFIRST Program               FlightGear Project
Twin Cities    curt 'at' me.umn.edu             curt 'at' flightgear.org
Minnesota      http://www.flightgear.org/~curt  http://www.flightgear.org
Permalink | Reply | 2 comments |
headers
Curtis L. Olson | 5 Apr 2004 17:23

30 arcsec terrain

(In my last message I meant to say gtopo30, not gnis ...)

Curt.

--

-- 
Curtis Olson   HumanFIRST Program               FlightGear Project
Twin Cities    curt 'at' me.umn.edu             curt 'at' flightgear.org
Minnesota      http://www.flightgear.org/~curt  http://www.flightgear.org
Permalink | Reply | 0 comments |

Gmane