Hi Chris
(Sorry for my quick writings and mispelling and other mistakes)
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 terrasync. Maybe it is
time that apt.dat updates coming from flightgear gets a new conception
now. Someone or a team has to establish a heard connection to Robin
Peel. I could imagine that Robin Peel didn’t follow our updates
anymore because it hooked on old 810 data, 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, 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
worth to
> "commit" this to Robin Peels database first. Some airports have
probably
> better or more improvements in flightgear apt.dat version (i.e.
taxiways).
> There are ~250 airports to check (see the link posted in my former
post).
I'm already doing the checks (and modifications) for the german
airports on
the list. Those will be sent to Robin.
>>
>> In this case it would make sense to unpack apt.dat, too, as many
changes
>> need to be done to the two files (ILS changes i.e.)
>
> Chris, you mean nav.dat here, do you?
I mean both files here. EDDF recently got a new runway and as such
the namig
scheme has changed completely. So I would like to change the runway
names in
apt.dat and the ILS data in nav.dat :)
Is it more recent than what shows up in current 850 xplane data? Maybe
this is a good point to show xplane data contributors that our updates
have some value too :-)
>
> Isnt it possible to commit flightgear apt.dat/nav.dat changes
directly to
> Robin Peel/xplane database, without serving an own apt.dat and
spreading
> derivatives? This caused a lot of problems the last years I guess.
I.e.
> there was never a proper solution what happens to changes made by
> flightgear contributors. It would be so much easier to have ONE
> apt.dat/nav.dat source, maybe someone can contact Robin Peel to get
a
> shared flightgear/xplane repository?
It IS generally (almost always) the best, to send changes directly to
Robin.
As I stated above, I didn’t see any change in our scenery work
coming to Robin Peels database. I don’t know the reason exactly.
Outdated data as base might be one, but that’s probably only my
personal assumption.
Our problem here is that we can't just update our apt.dat file with a
newer
version from Robin, as long as our scenery does not get rebuilt. What
Torsten probably envisions with his proposal is the possibility of
easier
hotfixes for our files.
For my point of view that’s exactly the path we have to leave. No
more hotfixes which gives us imperative to a own apt.dat version.
Instead of such fixes it would be nice to improve flightgear to read
single custom airports like xplane does. With xplane you can load one
improved airport from a custom data location and you go with this
data.
Again, we can't just update our apt.dat file with the latest version
from
xplane, as our scenery was created with a certain apt.dat file and
thus
"depends" on the corresponding file. Otherwise we'd have
inconsistencies
between i.e. FG's apt database and the runways showing up in our
scenery.
Xplane in contrast creates all airports on the fly, when loading the
scenery, so they can switch apt.dat files without bigger problems.
I don’t understand this concept: FlightGear distributes a static
data file and on the other hand dynamically updated (scenery) data via
terrasync or trough other sources. This will never be in sync unless
flightgear has capability to read custom airport data or to update
apt.dat via sync process too. For my point of view it’s anyway an
overhauled concept of distributing static "world data".
Maybe someone can explain me more here, sorry for all my
misunderstandment. I aplogize in advance, but I’m trying to follow
this apt.dat and scenery process since many years but I definitely
don’t get it probably ...
Cheers, Yves
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
