On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and still is the normal behaviour, since
On 24 Apr 2012, at 08:28, ThorstenB wrote:
If data needs to be loaded anyway (airport codes/positions), then
distributing it to tons of individual files may not help with start-up
delays either.
James really needs to comment on nav data things though, since I never
touched this area.
Hi Thorsten,
ThorstenB wrote:
On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and
Martin Spott wrote:
Indeed, the XML structure was primarily meant to override incorrect
values of pre-existing airfields.
BTW, here's the initial announcement:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html
Cheers,
Martin.
--
Unix _IS_ user
On 24 Apr 2012, at 08:28, ThorstenB wrote:
If data needs to be loaded anyway (airport codes/positions), then
distributing it to tons of individual files may not help with start-up
delays either.
James really needs to comment on nav data things though, since I never
touched this area.
Hi Thorsten,
ThorstenB wrote:
On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways
that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and
flightg...@sablonier.ch wrote:
Is the code/the queries to produce the xml output from the postgres
apt/nav.dat database available for public somewhere?
It's a simple Bash/PostgreSQL proof of concept which has seen
'evolutionary' development, looping through the list of ICAO codes,
collecting
Now this is really interesting..
http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh
I'm kinda moving into django land after lots of screaming and whining to
myself.. but it does seem to be a platform of sorts.. and sql alchemy
compat etc..
So can
ThorstenB wrote:
But to be honest, it neither works with central terrasync scenery. We
could never push any updates (such as introducing terrasync scenery with
the new EDDF runway) without immediately breaking consistency with all
previously released FG versions (= their base packages).
We
On Wed, 11 Apr 2012 10:48:46 +0200, Christian wrote in message
20120411084846.02ffa1456...@mail.sigmos.de:
Xplane's WorldEditor (WED), an opensource program,
..under the GPL like FlightGear? In that case we can simply
shanghai it into the FG tool suite. :o)
BTW, is perfectly
able to create
On Tue 10 Apr 2012 10:23:23 PM CEST, ThorstenB wrote:
Am 10.04.2012 21:08, schrieb Martin Spott:
And there's still one thing to consider: Having one central set of
apt./nav.dat files in the Base Package still doesn't address the trend
of the FlightGear project and Scenery development
ThorstenB wrote:
But to be honest, it neither works with central terrasync scenery. We
could never push any updates (such as introducing terrasync scenery with
the new EDDF runway) without immediately breaking consistency with all
previously released FG versions (= their base packages). And
The same applies to shipping modified apt.dat files with the Base
Package as long as use-custom-scenery-data flag wasn't established as
default.
Noticed yesterday that the preferences.xml in fgdata does not contain the
use-custom-scenery-data part anymore?
Is that intentional?
Shared
Hi Crhis, Torsten
What is really needed at the moment is someone starting to verify if some
changes to our apt.dat from the past have to come to recent apt.dat
shipped with FlightGear. Martin Spott prepared an updated apt.dat on the
mapserver, but the changes in there have to be verified if its
flightg...@sablonier.ch wrote:
Hi Crhis, Torsten
What is really needed at the moment is someone starting to verify if some
changes to our apt.dat from the past have to come to recent apt.dat
shipped with FlightGear. Martin Spott prepared an updated apt.dat on the
mapserver, but the changes
, which is not updated for
xplane anymore.
- Ursprüngliche Nachricht -
Von: FlightGear developers discussions
An:FlightGear developers discussions
Cc:
Gesendet:Tue, 10 Apr 2012 10:15:03 +0200
Betreff:Re: [Flightgear-devel] updates to nav.dat.gz
flightg...@sablonier.ch wrote:
Hi Crhis
flightg...@sablonier.ch wrote:
Maybe it???s time to establish a new contact to Robin Peel. I sent him
data too but never got any answer, I sent my data to Martin Spott and
the airports have never been updated, nore in apt.dat shipped with
flightgear nore in scenery files derived via
flightg...@sablonier.ch wrote:
Maybe it???s time to establish a new contact to Robin Peel. I sent him
data too but never got any answer, I sent my data to Martin Spott and
the airports have never been updated, nore in apt.dat shipped with
flightgear nore in scenery files derived via
Hi Yves,
flightg...@sablonier.ch wrote:
update in general? Why is it possible to update apt. and nav.dat in xplane
every months without (?) inconsistencies and not for FlightGear? Is there
something that could be changed in the concept of scenery and data
distribution for FlightGear?
Did
flightg...@sablonier.ch wrote:
I know about this inconsistencies, and this of course the core of the
problem. When flightgear reads from one updated scenery source and from
one corresponding data source we wont run into the same problems anymore,
I think that's true, but really hard to
On Mon, 9 Apr 2012, Michael Sgier wrote:
Traffic and parking etc. are handled via xml files in Flightgear different to
X-Plane.
But to make changes to the opensource apt.dat forward them to Robin:
http://forums.x-plane.org/index.php?showtopic=58356
Right, but if you use the v10 format, all
Am 10.04.12 14:24, schrieb Christian Schmitt:
Hi Yves,
flightg...@sablonier.ch wrote:
update in general? Why is it possible to update apt. and nav.dat in xplane
every months without (?) inconsistencies and not for FlightGear? Is there
something that could be changed in the concept of
Gene Buckle wrote:
On Mon, 9 Apr 2012, Michael Sgier wrote:
Traffic and parking etc. are handled via xml files in Flightgear different
to X-Plane.
But to make changes to the opensource apt.dat forward them to Robin:
http://forums.x-plane.org/index.php?showtopic=58356
Right, but if you
On Tue, 10 Apr 2012, Martin Spott wrote:
Gene, as you know, FlightGear's XML structure for taxiway routing and
other scenery-related airport info predates the capabilities of the v10
You're assuming knowledge not in evidence. :) I knew nothing of this xml
format, nor how long it had been
And there's still one thing to consider: Having one central set of
apt./nav.dat files in the Base Package still doesn't address the trend
of the FlightGear project and Scenery development proceeding
asynchronously.
Wouldn't a simple If custom data is present, use custom data switch
alleviate
Am 10.04.2012 21:08, schrieb Martin Spott:
And there's still one thing to consider: Having one central set of
apt./nav.dat files in the Base Package still doesn't address the trend
of the FlightGear project and Scenery development proceeding
asynchronously.
But to be honest, it neither works
Hi,
what is our current policy for updates to nav.dat? Do we commit changes
to the binary gzip'ed file or do we have a central repository for the data?
Would it make sense to have the unzip'ed file in git and zip it for the
release in make dist?
Torsten
On Monday 09 April 2012 15:05:58 Torsten Dreyer wrote:
Hi,
what is our current policy for updates to nav.dat? Do we commit changes
to the binary gzip'ed file or do we have a central repository for the data?
Would it make sense to have the unzip'ed file in git and zip it for the
release in
Am 09.04.12 23:31, schrieb Ron Jensen:
On Monday 09 April 2012 15:05:58 Torsten Dreyer wrote:
Hi,
what is our current policy for updates to nav.dat? Do we commit changes
to the binary gzip'ed file or do we have a central repository for the data?
Would it make sense to have the unzip'ed file
On Mon, 9 Apr 2012, Ron Jensen wrote:
On Monday 09 April 2012 15:05:58 Torsten Dreyer wrote:
Hi,
what is our current policy for updates to nav.dat? Do we commit changes
to the binary gzip'ed file or do we have a central repository for the data?
Would it make sense to have the unzip'ed file
...@deltasoft.com
Subject: Re: [Flightgear-devel] updates to nav.dat.gz
To: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Date: Tuesday, April 10, 2012, 3:00 AM
On Mon, 9 Apr 2012, Ron Jensen
wrote:
On Monday 09 April 2012 15:05:58 Torsten Dreyer wrote:
Hi
31 matches
Mail list logo
