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
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
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
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
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 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.
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?
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
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
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
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
Ralf Gerlich wrote:
Hi,
I hope I don't say too much if I say that there is work planned on
defining taxiways by means of polylines in TaxiDraw.
Excellent!
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Paul Surgeon wrote:
On Saturday 15 October 2005 20:54, [EMAIL PROTECTED] wrote:
I thought about the taxiway structure/format a while back.
I came to the conclusion that a raw polygon editor is about the only way
you're going to be able to create taxiways properly.
You mean, ac3d or
Harald JOHNSEN wrote:
The best way I found to counter the z-buffer fighting is simply to
disable z-buffer testing.
Remember, we are painting the ground, why would we want any z tests
(you can find situation where
this add artifacts of course).
Exactly, if you disable the z-buffer, you lose
On Saturday 15 October 2005 23:44, Ralf Gerlich wrote:
Hi,
I hope I don't say too much if I say that there is work planned on
defining taxiways by means of polylines in TaxiDraw.
That's still very restrictive. It's a step in the right direction but is still
far from what is needed. We need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Surgeon schrieb:
On Saturday 15 October 2005 23:44, Ralf Gerlich wrote:
Hi,
I hope I don't say too much if I say that there is work planned on
defining taxiways by means of polylines in TaxiDraw.
That's still very restrictive. It's a
Dave writes:
I certainly sympathise with this point of view. The current format is
certainly crude. However, the problems with it only become apparent close
up, when either close to or on the ground, and trying to follow taxiways
at intersections. The taxiway layouts done in the current
[EMAIL PROTECTED] wrote:
If editing taxiways becomes as easy as importing the image data, a lot
more people will do it and we'll all wind up with more airports (and a
better user experience.)
I don't find creating an airport and taxiways in TaxiDraw that
challenging. As with all manual work
Hi,
Christian Mayer schrieb:
Paul Surgeon schrieb:
On Saturday 15 October 2005 23:44, Ralf Gerlich wrote:
Hi,
I hope I don't say too much if I say that there is work planned on
defining taxiways by means of polylines in TaxiDraw.
That's still very restrictive. It's a step in the right
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Gerlich schrieb:
I'm not sure how important giving back to Robin's DB is for the
FlightGear community but in the OpenSource manner I'd say we should try
to find a way of not doing things twice in two communities.
We should try to scratch
Christian Mayer wrote:
Ralf Gerlich schrieb:
I'm not sure how important giving back to Robin's DB is for the
FlightGear community but in the OpenSource manner I'd say we should try
to find a way of not doing things twice in two communities.
We should try to scratch only our own itch.
On October 15, 2005 08:51 pm, David Luff wrote:
I know there was some talk of extracting taxiways from the FAA's PDFs,
I can't realistically see that happening!
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
On October 16, 2005 03:43 am, Harald JOHNSEN wrote:
I thought about the taxiway structure/format a while back.
I came to the conclusion that a raw polygon editor is about the only way
you're going to be able to create taxiways properly.
You mean, ac3d or blender ? No need to use a special
Regarding Robin's DB: having accurate taxiways is not the only concern. Some
other items that we should take notice of include:
- buildings placement
- gates' position
- tower/ILS frequencies
- runway/taxiway signs
- airport animations
- runway/taxiway conditions due to weather
- ground pathways
You know, I'd be happy to help do some of the taxiway work if a new format
becomes available. I've been trying to work with Taxidraw, but it's kind
of difficult to work in because of the underlying format (I have no
problems with Taxidraw itself.) I find I spend a lot of time making sure
the
On Saturday 15 October 2005 20:54, [EMAIL PROTECTED] wrote:
You know, I'd be happy to help do some of the taxiway work if a new format
becomes available. I've been trying to work with Taxidraw, but it's kind
of difficult to work in because of the underlying format (I have no
problems with
Hi,
I hope I don't say too much if I say that there is work planned on
defining taxiways by means of polylines in TaxiDraw.
For starters I intended to create rectangles from that polyline data as
appropriate, keeping the old format.
Best regards,
Ralf
ojoe writes:
You know, I'd be happy to help do some of the taxiway work if a new format
becomes available. I've been trying to work with Taxidraw, but it's kind
of difficult to work in because of the underlying format (I have no
problems with Taxidraw itself.) I find I spend a lot of time
44 matches
Mail list logo
