On January 13, 2006 08:04 pm, Ampere K. Hardraade wrote:
> The process is trivial.
>
> In each file, there are lines that represent latitude and longitude.
> http://204.108.4.16/d-tpp/0513/00375AD.PDF
>
> The user would first use a program like Inkscape to rename at least four of
> those lines to t
Thought I might be... the thought was there though
signed
"Keen to help but a little quick on the trigger"
(Dene)
From: Paul Surgeon <[EMAIL PROTECTED]>
Reply-To: flightgear-devel@lists.sourceforge.net
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear
On Saturday 14 January 2006 03:25, dene maxwell wrote:
> Hi,
> Is the lat and long for the vertices concerned known?
>
> if so I have the great circle formula for shortest distance between known
> points, presently coded in VB but the level of commenting is such that a
> c++ newbie could convert it
From: "Ampere K. Hardraade" <[EMAIL PROTECTED]>
On January 13, 2006 07:21 pm, Paul Surgeon wrote:
> How do you plan to make sure the airport layout is rotated and
positioned
> accurately so that things like ILS equipment isn't off to one side or at
> the wrong angle to runways?
> If you're 10
On January 13, 2006 07:21 pm, Paul Surgeon wrote:
> How do you plan to make sure the airport layout is rotated and positioned
> accurately so that things like ILS equipment isn't off to one side or at
> the wrong angle to runways?
> If you're 10 meters off you're not going to be landing on the cent
On Saturday 14 January 2006 01:47, Ampere K. Hardraade wrote:
> On January 13, 2006 06:03 pm, Curtis L. Olson wrote:
> > Can you get a plausible airport boundary out of this process? I can't
> > remember if that is displayed on the charts ...
> >
> > Curt.
>
> No, at least not on those FAA diagram
On January 13, 2006 06:47 pm, Ampere K. Hardraade wrote:
> > Can you get a plausible airport boundary out of this process? I can't
> > remember if that is displayed on the charts ...
> >
> > Curt.
>
> No, at least not on those FAA diagrams.
Well, not automatically, but we could manually define a
On January 13, 2006 06:03 pm, Curtis L. Olson wrote:
> Can you get a plausible airport boundary out of this process? I can't
> remember if that is displayed on the charts ...
>
> Curt.
No, at least not on those FAA diagrams.
Would it be possible to literally paint the airport over the terrain?
Ampere K. Hardraade wrote:
On January 13, 2006 01:25 pm, Steve Knoblock wrote:
This is a good development. I like working with SVG and my Firefox 1.5
browser can natively display the SVG images Ampere posted. The images
can be worked with in Inkscape if necessary, which is a truly
excellent
On January 13, 2006 01:25 pm, Steve Knoblock wrote:
> This is a good development. I like working with SVG and my Firefox 1.5
> browser can natively display the SVG images Ampere posted. The images
> can be worked with in Inkscape if necessary, which is a truly
> excellent and easy to use editor for
On Friday 13 January 2006 20:25, Steve Knoblock wrote:
> I would be happy to have accurate sized and located buildings, even if
> they are unattractive in appearance without their textures. The visual
> improvement we could see is a very exciting prospect.
I really don't see why the buildings can'
On Thu, 12 Jan 2006 20:06:39 -0800, you wrote:
>Since my last post, I have found what I think is a better method at extracting
>taxiways data from an airport diagram. Instead of converting the file to
>DXF, I have converted it to SVG. Since SVG is in XML format, I was able to
>do some greppin
Ampere K. Hardraade wrote:
To import the data into FG, we could create some sort of converter to convert
the SVG file into 3D geometries usable in FG.
Or add our own SVG loader for plib. I believe there is a way to tie or
own loaders into plib (using a callback function or something similar).
On January 12, 2006 11:53 pm, Curtis L. Olson wrote:
> Adding one more thought ...
>
> It might be worth thinking about formating this taxiway/building data in
> a way that will allow us to integrate it with the current airport
> database. X-Plane couldn't use the data at the moment, but if
> flig
> The polygon-outline is available -- those SVG files are it. The
> only problem
> with them is that they are not scaled or orientated properly.
>
> Ampere
SVG has its own scaling and orientation capabilities. You might simply be
able to add a couple of lines at the beginning (or end?) of the .sv
On January 12, 2006 11:47 pm, Curtis L. Olson wrote:
> There are a lot of ways we could go with this.
>
> If you could give me a set of polygon outlines for taxiways, I don't
> think that would be too hard to integrate with the current airport
> generator code. Taxiways are just simple polygons, a
On January 12, 2006 11:13 pm, Curtis L. Olson wrote:
> What really got my attention was the 3d building/hangar models. I know
> they aren't textured, but if we could populate a lot of otherwise flat
> airports with accurate hangars and terminals, that would be extremely cool!
>
> Curt.
If anyone
Curtis L. Olson wrote:
There are a lot of ways we could go with this.
If you could give me a set of polygon outlines for taxiways, I don't
think that would be too hard to integrate with the current airport
generator code. Taxiways are just simple polygons, and the underlying
code can handle
Ampere K. Hardraade wrote:
>
> The intent is to have another application (which doesn't exist right now) to
> scale and orientate the airport properly, output a AC3D file, then match each
> vertex in the model to the ground elevation. Then, it should be a simple
> matter of placing the airpor
Ampere K. Hardraade wrote:
The intent is to have another application (which doesn't exist right now) to
scale and orientate the airport properly, output a AC3D file, then match each
vertex in the model to the ground elevation. Then, it should be a simple
matter of placing the airport on top o
On January 12, 2006 11:02 pm, [EMAIL PROTECTED] wrote:
> This looks very cool. Is the intent to then have some other app that
> then extracts the info from these .svg files and converts it to app.dat
> format, or allows it to be imported into TaxiDraw (so that the user can
> set properties for the
[EMAIL PROTECTED] wrote:
This looks very cool. Is the intent to then have some other app that
then extracts the info from these .svg files and converts it to app.dat
format, or allows it to be imported into TaxiDraw (so that the user can
set properties for them -- type of surface, markings, etc
Hi Ampere,
> Since my last post, I have found what I think is a better method at
> extracting
> taxiways data from an airport diagram. Instead of converting the file to
> DXF, I have converted it to SVG. Since SVG is in XML format, I was able to
> do some grepping, and produce each of the
> In anycase, this new method cuts down the work by half. I also
> think that SVG
> is an excellent format to work with. So, I will continue my
> experiment using this format.
SVG is nice. I'm going to be using it with XSLT to display JSBSim config
file tables - I hope.
Jon
-
Since my last post, I have found what I think is a better method at extracting
taxiways data from an airport diagram. Instead of converting the file to
DXF, I have converted it to SVG. Since SVG is in XML format, I was able to
do some grepping, and produce each of the followings in less than a
On January 8, 2006 11:23 pm, Curtis L. Olson wrote:
> Wow! Can that be automated for other airports?
Absolutely. But the process that I went through is still far from being
called "automated". Also, this model lacks any sort of ground-elevation
data, so it can't be used in FlightGear, yet.
Id
Ampere K. Hardraade wrote:
This is a little experiment that I have conducted with an airport diagram --
to show that my idea does work. It was done under half an hour. Not bad for
a model that only has 3064 polygons huh? :)
http://www.students.yorku.ca/~ampere/ksfo.jpg
http://www.students.y
27 matches
Mail list logo
