"Ampere K. Hardraade" wrote:
> 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 favour
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
> >
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, a
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 necess
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
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 wh
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
incre
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?
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
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 tax
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 rou
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 loo
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 :-)
Fina
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. Y
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 based
"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. And last but not least, by relying on a fixed sort of
geometries (be it rectangles like now or triangles as you proposed)
we're
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
http://mail.flightgear.org/mai
Martin Spott wrote:
Show me an approach that is flexible enough to describe junctions of
different shapes with quads and I'll believe it ;-)
You could combine two endpoint or two side points to create a triangle.
But at least you know where the centerline would end up.
Erik
__
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 t
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 th
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 i
Erik Hofman wrote:
> p1 ++ p3
> ||
> ||
> ||
> p2 ++ p4
Additionally we need junctions if the plan should make sense. Junctions
like this one:
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 mea
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 t
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 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
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
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 ad
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:
http://x-plane.org/home/robinp/#Futu
"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:
[...]
> t
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
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
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 fil
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 itc
-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 scra
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 d
[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
> 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 curr
-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
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 nee
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
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 blend
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
http://mail.flightgea
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
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
__
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
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 are
47 matches
Mail list logo
