Ampere K. Hardraade wrote:
That was a proposal from me. The idea is to have a program (could be a
modified version of KPDF) to read a vector based PDF file such as this:
http://204.108.4.16/d-tpp/0510/00375AD.PDF and spit out the taxiway outlines.
Ampere K. Hardraade wrote:
[...]
the
Hi,
Ampere K. Hardraade schrieb:
[SNIP]
Time might as well be spent on thinking of how we are going to convince Robin
to use our new format instead of thinking of a way to expand Robin's
database.
I think that Robin could actually be pretty open for this:
Martin Spott wrote:
So: However somebody is going to design a new airports description
format we always should have a method to merge Robin's updates.
Additionally we need someone who tracks these updates on a regular
basis because we don't want to loose a nifty feature that some X-Plane
user
Hi,
Ampere K. Hardraade schrieb:
[SNIP]
One can use rectangular or bent taxiway sections but when you get to all
the weird and wonderful taxiway layouts it's impossible to do with a
generic taxiway structure. This is very apparent where taxiways intersect
other taxiways, runways or aprons.
The
John Wojnaroski wrote:
you might try
http://sourceforge.net/projects/openatc
It died a quiet death when no one showed up for the network field test
Hmm, it looks like it started when the time wasn't right. I think we
have enough momentum right now for a restart.
Erik
Erik Hofman writes:
Martin Spott wrote:
So: However somebody is going to design a new airports description
format we always should have a method to merge Robin's updates.
Additionally we need someone who tracks these updates on a regular
basis because we don't want to loose a nifty
Norman Vine wrote:
Erik Hofman writes:
This can be done by requesting a new designator number as an alternative
taxiway entry. That way it would be possible to have both the old and
new format available in the file.
Doesn't that just create another problem ?
Now the tools will need to check
Am Saturday 15 October 2005 11:30 schrieb Jim Campbell:
Anyone transmitting un-encrypted data across a world wide internet (as
opposed to a private intranet) needs to think ahead a little. Every
hacker will be rubbing their hands with glee before trying to hit you
on these ports you have just
Am Saturday 15 October 2005 23:45 schrieb Arnt Karlsen:
..we're not re-inventing pcproxy, are we?
No, at least I surely won't.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Am Sunday 16 October 2005 19:20 schrieb Andy Ross:
Oliver Schroeder wrote:
So the server has to reread the port from the UDP header
everytime it reseives new data from the client and recreate a
socket for it (and clse the existing one of course).
Er, no. Check the man page of sendto. :)
Erik Hofman wrote:
Norman Vine wrote:
Erik Hofman writes:
This can be done by requesting a new designator number as an
alternative taxiway entry. That way it would be possible to have
both the old and new format available in the file.
Doesn't that just create another problem ?
Now the
On 17/10/2005 at 02:01 George Patterson wrote:
Yes, It's just you :-P
You can stop the replay by select the View menu, select instant replay.
On the Instant Replay dialog check the Disable replay. and click Ok.
Believe me, I've tried that. It simply doesn't work AFAICT. On Linux the
On 16/10/2005 at 18:19 Erik Hofman wrote:
David Luff wrote:
Is it just me, or is it completely impossible to escape from instant
replay once engaged in the current CVS?
You can end the repeating loop by pressing 'p' twice.
Ah, OK, that works. It's not exactly intuitive though! How about I
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model
In directory baron:/tmp/cvs-serv31442
Modified Files:
shadanim.cxx
Log Message:
Harald JOHNSEN:
I have corrected a few bugs with the owner draw gauge, weather radar
code and heat-haze effect.
This is
Curtis L. Olson wrote:
I haven't had a lot of time over the past weeks to contribute here and
I'm going out of town later this week, but we've discussed much of this
before.
I know, but if there's one area where FlightGear can use an eminent
update then it's the airport layout.
In the
Erik Hofman wrote:
p1 ++ p3
||
||
||
p2 ++ p4
Additionally we need junctions if the plan should make sense. Junctions
like this one:
Martin Spott wrote:
Additionally we need junctions if the plan should make sense. Junctions
like this one:
When carefully designed this could be done with the quad approach
(although it would not be easy). So the data should be quad based.
It is up to the taxidraw developers on how to make
Erik Hofman wrote:
Martin Spott wrote:
Additionally we need junctions if the plan should make sense. Junctions
like this one:
When carefully designed this could be done with the quad approach
(although it would not be easy). So the data should be quad based.
Show me an approach that is
Erik Hofman writes:
Martin Spott wrote:
Additionally we need junctions if the plan should make sense. Junctions
like this one:
When carefully designed this could be done with the quad approach
(although it would not be easy). So the data should be quad based.
It is up to the
Hi,
I am having a problem building flightgear on cygwin (cygwin updated
last friday).
I am using cvs from this morning. The GCC is cygming 3.4.4
Any ideas what's wrong or how to fix it? I've googled the error and
seen a variety of 'error: expected unqualified-id before 'some
token'
Norman Vine wrote:
I vote for everything being triangle based like the underlying renderer
But how would one define where the center line is then?
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Norman Vine wrote:
Erik Hofman writes:
Martin Spott wrote:
Additionally we need junctions if the plan should make sense. Junctions
like this one:
When carefully designed this could be done with the quad approach
(although it would not be easy). So the data should be quad
Martin Spott:
Norman Vine wrote:
I vote for everything being triangle based like the underlying renderer
This puts us at risk to run into huge datasets for every taxiway
junction.
What about a purely symbolic representation? Store just centerline
and width for each taxiway, and keep the
Martin Spott schrieb:
[SNIP]
With the layout I've proposed you'll be able to determine everything
that's needed: The taxiway direction and hence the direction of the
centerline are determined by the perpendicular on the face sides of the
junction, where the regular taxiways are being connected.
Hi Ima,
when I tried to build a CVS version of FlightGear I had a *lot* of
trouble and errors. Many developers of this list tried to help me but
the break-through was an advice of *KEVIN JONES* not to use gcc 3.4.4
(what I had done until then).
I followed his detailled instructions as he was
Oliver Schroeder wrote:
Andy Ross wrote:
The server only needs one socket for its whole lifetime.
Of course, but this solves only part of the problem. The main
problem is, that a a NAT router may decide to not accept
(ie. forward to the client) any packets we send back to it.
It may work
Harald JOHNSEN wrote:
O
/
/
O-O--
/
/
O
I vote for everything point and lines ;-)
Well, points and lines and taxiway width is what we have now and people
claim that the result looks terribly :-)
Finally
Martin Spott wrote:
Harald JOHNSEN wrote:
O
/
/
O-O--
/
/
O
I vote for everything point and lines ;-)
Well, points and lines and taxiway width is what we have now and people
claim that the result
On Monday 17 October 2005 06:50, Ampere K. Hardraade wrote:
Regarding Robin's DB: having accurate taxiways is not the only concern.
Some other items that we should take notice of include:
These are valid concerns. Quite a few of these features are already available,
albeit sometimes in a
Harald JOHNSEN wrote:
We don't have points and lines, we have quads. My line is the center
line, my point is an intersection etc.
We currently have a point in the middle of a taxiway, the heading, the
length and the width of that section - which enables us to determine
the endpoints of a
On Monday 17 October 2005 19:50, Martin Spott wrote:
Well, points and lines and taxiway width is what we have now and people
claim that the result looks terribly :-)
Finally with points and lines you won't be able to describe the _shape_
of a junction - as I understood exactly this is what
On Mon, 17 Oct 2005 17:50:00 + (UTC), Martin wrote in message
[EMAIL PROTECTED]:
You won't be able to reverse-engineer the shape of such a junction
because in real live they don't follow geometric perfection.
..maybe use some curve fitting library to generate those shapes at
runtime?
Georg Vollnhals wrote
when I tried to build a CVS version of FlightGear I had a *lot* of
trouble and errors. Many developers of this list tried to help me but
the break-through was an advice of *KEVIN JONES* not to use gcc 3.4.4
(what I had done until then).
I followed his detailled
Something to consider: There're more markings than just the centerline on
taxiways. Edges are defined by double yellow or dashed, double yellow
lines (the boundary between usable runup/apron areas and taxiways.) And
there're the hold short/ILS hold short lines. All of these markings were
Erik Hofman wrote:
John Wojnaroski wrote:
you might try
http://sourceforge.net/projects/openatc
It died a quiet death when no one showed up for the network field
test
Hmm, it looks like it started when the time wasn't right. I think we
have enough momentum right now for a
Harald JOHNSEN wrote:
I am not sure I follow you here, taxiway design have strict rules that
you can find on the FAA site.
I can assure you there are plenty of airfields out there that don't
follow the rules. Many of the ones I've worked on have developed over
the last 60+ years to become
Durk Talsma wrote:
- buildings placement
This can be done through a combination of .stg and xml files, but this has to
be done either by hand editing, or by using a dedicated scenery editor. I'm
not sure if fgsd would be able to do this. This would be the only interactive
application that
The Add Waypoint dialog should now accept a nav name as well.
To make it work, I used a (dead) code that seemed to be assuming
degree-based geodesic points (whereupon the CVS SG docs claim
that geodesic points are in radians).
(I know that in this case it must be radians because if you pass
Please review my patch below in the light of the above caveats
(it works, but I wonder if something needs to be re-written further to
match some uniform usage of geodesic points). It won't hurt applying
AFAIU because the Navaids code I'm touching doesn't seem to be called
at all (according to
hmmm my doxygen didn't find a couple of the calls to findByFreq() that
do assume radians throughout the code! please don't apply, i'll
change the comments to say the arguments are in radians then,
and move the conversion to radians over to the new caller,
and post a new version soon
Here it
On October 17, 2005 02:28 am, Martin Spott wrote:
I' pretty sure it easier to convert the PDF's into some common vector
drawing format than adding editing capabilities to [X,K,G]PDF. Once you
have a nice vector format you can easily load that into your favourite
editor, and group the necessary
Included is a patch that I use here to get rid of trace spewn
driven by short timers. It demotes the relevant sun solver
and ground cache update messages from INFO to DEBUG.
Index: src/FDM/groundcache.cxx
===
RCS file:
On October 17, 2005 02:23 pm, Durk Talsma wrote:
- airport animations
Just wondering what type of animations you were thinking of. We have
support for moving aircraft now, but no ground vehicles yet, although this
could be done using animation scripts.
Bridges' movement, illumination, and so
On Mon, 2005-10-17 at 21:57 -0400, Ampere K. Hardraade wrote:
On October 17, 2005 02:23 pm, Durk Talsma wrote:
- airport animations
Just wondering what type of animations you were thinking of. We have
support for moving aircraft now, but no ground vehicles yet, although this
could be
44 matches
Mail list logo
