AVIATIONTOOLBOX: automatic route selection

Kyler Laird wrote:

It's not clear to me that this is a terrible burden. A student
sitting in front of enroute charts can figure out reasonable solutions
so I assume I can program a computer to do the same in short order.

I always got stuck at trying to find a reasonable choice for the node at which
the enroute structure should be entered and exited. Once you pick the end points
(where to enter and leave) the choice of routes is just an OR optimization
problem, as others have noted.


I think that learning to disregard edges that aren't of interest is
the key. This seems fairly simple at first but in mountainous regions
with low altitude restrictions it could get difficult because you might
need to go far away from a direct route.

Perhaps altitude requirements need to be included in the costs.

Dave

I like the idea of running the script once a month, but for 20.00
airports this would be a quite database.

Another idea is when we have found preferred routes, also store use
routes (routes that user knows he/she will get from atc after filin
different route)... mainly for busy areas NY etc... atc's ow
prefferred routing as previously mentioned.

We will be using mapserver with this project and use mysql for db.
Php or cgi script for this would be nice


http://www.v1rotate.com
View this thread: http://www.v1rotate.com/portal/forum...?threadid=9334

In article ,
Julian Scarfe wrote:
Repeat for other departure airports of interest. Processing time for one
departure airport for my network was about 30s on a fairly typical desktop
machine. YMMV, literally. ;-)

I think you can do better than that by ordering your edges better. You
know more than just edge costs, you also have coordinates for each node.
You can choose to explore edges that move you closer to the destination
first.

IIRC, the key to making Dijkstra fast is to find a solution as early as
possible. That establishes a baseline cost that allows massive pruning
of the search space.

least-cost routes. But now we're doing that for *every* flight, which means
that we wait for both steps of the processing (edge costs + Dijkstra)
instead of doing a database lookup on stuff that's run once a month.

Right. But if I'm going to do the work then I want it to calculate all
of the factors that I would, given infinite time and patience on my part.

--
Ben Jackson

http://www.ben.com/

http://rfinder.asalink.net/free/

I found that for simmers, but this is as close as I hope for.

Would be a nice to see a source for that .cgi

Hank

In article ,
Julian Scarfe wrote:
Repeat for other departure airports of interest. Processing time for one
departure airport for my network was about 30s on a fairly typical
desktop
machine. YMMV, literally. ;-)

"Ben Jackson" wrote in message
news:rTzbd.249118$D%.142632@attbi_s51...

I think you can do better than that by ordering your edges better. You
know more than just edge costs, you also have coordinates for each node.
You can choose to explore edges that move you closer to the destination
first.

IIRC, the key to making Dijkstra fast is to find a solution as early as
possible. That establishes a baseline cost that allows massive pruning
of the search space.

That may be the case. I should have said that what I was trying to do was
create a server-based system for large numbers of users with different
dep-dest pairs. In that case, I'm looking at all potential destinations in
parallel. The strategy for a client-based system starting from scratch for
every single flight might be rather different.

Julian

"Julian Scarfe" wrote in message ...
"Ben Jackson" wrote in message
news:tCmbd.121529$He1.75934@attbi_s01...

I keep meaning to apply Dijkstra's algorithm to airway routing.
The key will be choosing edge costs.

I tried something similar for Western Europe. Thinking aloud... My
algorithm was basically:

a) load the entire airway network as a graph using distances as costs

*** I would modify that to use a combination of distance and MEA as
the cost.
I've found that in my personal flight planning, lower MEAs often
translate into a better flight, even if they involve a bit of a
dogleg.

- Jerry Kaidor ( )

Y'all,
My IFR is usually in the SF Bay Area. I have found that the preferred
routes take me miles out of my way. I have also found that a brief
negotiated change of route suc as direct to a fix that
cuts 30-40 miles off the preferred airways is justified.

Consider IFR to Las Vegas. MEA 16K or above. Even 13K
takes you all the way around Edwards. Negotiated changes work
if known and used.

I would suggest that at some point an indicator on the system would
tell the pilot that it is time to negotiate a change.

Gene Whitt

I always understand better with pictures

This is how I understand how this thingy works.

http://www.v1rotate.com/images/navmap.gif

basically draw 3 boxes and do all the calculations inside within these
boxes. This will limit the fixes to calculate.
Limit area #1 for your origin, area #2 for your destination (allow fixes to
be within these boxes so they can join to airways.)
Limit area #3 for route (Only vor's within airways)

KBWI
EMI
J211
JERES
J211
BUSTR
J211
LEONI
J211
JST
J152
AVERE
KPIT

jeres bustr and leoni could be dropped, since they are on same airways

KBWI
EMI
J211
JST
J152
AVERE
KPIT


Here is another link that might interest or help us within this project.
http://gis.vegcrew.net/cgi-bin/viewc....1&view=markup

Hank

"v1rotate dot com" writes:

basically draw 3 boxes and do all the calculations inside within these
boxes. This will limit the fixes to calculate.

It's not clear to me that these regions can be adequately chosen from the
start (especially for long flights) but it certainly would simplify things.

Limit area #1 for your origin, area #2 for your destination (allow fixes to
be within these boxes so they can join to airways.)

I think these will need to extend well beyond the endpoints. As a worst
case example, consider a trip to an airport just on the other side of a
mountain that is too high to traverse directly.

jeres bustr and leoni could be dropped, since they are on same airways

Dropping seems dangerous. What if one of those dropped waypoints is close
to your destination? Will you pick that up later?

--kyler

Dropping I mean could be dropped from processing, since they are on the
airways db...
No need to process fixes, if they are already in the airways list. They are
still listed, but not processed.
Only start and end of the airways are processed.

Extend as far as needed. (ie 250 miles from centerline... no need to
calculate fixes beyond this unless you wanted to.)

Just wanted to spark up the discussion

Hank