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 c
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
> 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,
>
> 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 t
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 fri
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 bee
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 ar
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
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).
W
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 cr
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?
Share
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). An
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 p
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 wor
> 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
allev
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 aro
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, b
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
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,
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 achi
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:
>
>> 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 terras
, 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...@sablon
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
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
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 "make dist"?
>
> Torst
ct: Re: [Flightgear-devel] updates to nav.dat.gz
> To: "FlightGear developers discussions"
>
> 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,
> >>
&g
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 u
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 u
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
> releas
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
-
32 matches
Mail list logo
