Nl/Terrasync

Kees (talk) 15:01, 12 December 2017 (EST)

TerraSync moet niet worden verward met TerraGear, een gereedschap om Scenery (landschap) te genereren.

Om het terrein onder je vliegtuig te kunnen zien, moet je het betreffende scenery/landschap installeren. Dit kan gebeuren door bepaalde stukken "landschap" te downloaden voordat je gaat vliegen zoals beschreven in het artikel scenery installeren.

Als je een stabiele en redelijk snelle internetverbinding hebt, kun je TerraSync gebruiken. Het is een hulpprogramma dat automatisch de nieuwste versie van het benodigde FlightGear-landschap downloadt terwijl de simulator draait. TerraSync draait op de achtergrond (optioneel als een afzonderlijk proces), bewaakt jouw positie en downloadt (of actualiseert) het nieuwste landschap van de master scenery server "just in time". TerraSync is al geruime tijd geïntegreerd in het FlightGear-kernproces, zodat de doorsnee gebruiker TerraSync niet meer apart hoeft te starten.

De master repository voor TerraSync, de online bron van waaruit TerraSync zijn bestanden downloadt, wordt één keer per dag gesynchroniseerd met de FlightGear Scenery Database. Dus als je TerraSync gebruikt, zul je altijd beschikken over

1. de nieuwste .stg-files, die FlightGear vertellen waar een object moet worden geplaatst.
2. de nieuwste statische modellen voor objecten. (Statische modellen geven unieke objecten weer die slechts op één plaats bestaan, zoals beroemde gebouwen of monumenten.)
3. de nieuwste gemeenschappelijke modellen voor objecten. (Generieke modellen die meer dan eens op verschillende plaatsen worden gebruikt, kunnen verschillende objecten vertegenwoordigen, zoals generieke huizen of schepen)

Aankondiging

In het verlengde van FSweekend gaan we een aantal ideeën testen hoe we osm2city landschap met terrasync kunnen verspreiden. Als eerste stap heb ik net een map toegevoegd met als titel Objects_1 waarin ik de met osm2city gecreëerde gebouwen voor e005n46 tot e010n48 heb geplaatst. Mensen die de in fgfs geïntegreerde terrasync gebruiken zullen (nog) geen verschil opmerken. Bij het gebruik van terrasync.py moet je merken dat bestanden naar die mappen worden gedownload, maar ze verschijnen (nog) niet in het landschap. Waarschijnlijk gooien we sommige of alle bestanden in die directory weg zonder voorafgaande kennisgeving, dus vertrouw er niet op en maak geen back-upkopieën. Torsten

Nieuws

Terrasync is begonnen als een op zichzelf staand rsync-gebaseerd hulpprogramma. Er lijken echter geen goede/robuuste multiplatform bibliotheken beschikbaar te zijn voor ons gebruik. We wilden terrasync direct in de kerncode inbouwen, zodat we het downloaden van tegels (Engels=tiles) beter konden sturen en deze vervolgens direct in de sim laden (versus een beperkte of geen opvulling van "tegels" wanneer een extern gereedschap rsync draaide).

Zoals sommigen van jullie waarschijnlijk hebben gemerkt, zijn er ontwikkelingen in terrasync gaande op het gebied van codering, meestal door James en soms door Torsten. De belangrijkste reden is het protocol om landschap te distribueren niet meer via SVN te laten plaatsvinden, maar eenvoudiger te implementeren protocollen in te zetten. Het idee is om HTTP te gebruiken als middel om die bestanden te downloaden die terrasync nodig heeft. Dit zou het veel gemakkelijker moeten maken voor "hosts" om een "mirror" in te zetten, het maakt het waarschijnlijk ook mogelijk om een CDN te gebruiken voor load balancing met positieve gevolgen voor de "client".

De bedoeling is om, zodra 2016.1 is uitgebracht, over te stappen op HTTP voor TerraSync (in plaats van SVN), ervan uitgaande dat dit ook veel meer mogelijkheden geeft om de code te verspreiden. De cache bestanden zijn klein en weerspiegelen de revisie van elk bestand in de lokale map; ze zijn vergelijkbaar met de gegevens die een echte SVN client opslaat in zijn svn' directory in de root-file. Ik verwacht dat de zuivere HTTP-oplossing enkele gelijkaardige bestanden nodig heeft om de HTTP cache-blokken van bestanden die het downloadt op te slaan - één bestand in de hoofdmap van de structuur of per directory. (Er zijn voordelen en nadelen voor beide.)

• ondersteuning van verschillende downloadprotocollen in de code zou heel lastig worden, dus de intentie is om alleen de HTTP-methode direct in FlightGear te ondersteunen, ook bekend als 'ingebouwde terrasync'
• een van de belangrijkste voordelen van het HTTP-systeem is dat het SHA1 hashes gebruikt in plaats van SVN revisies om bestanden te identificeren, en er wordt geen (server) URL opgeslagen in de gedownloade directories. Dit betekent dat je een terrasync directory kunt opzetten met bestanden die worden geïnstalleerd door iedere beschikbare methode (DVD, BitTorrent, kopiëren vanuit een andere computer) en zolang de SHA1 hashes overeenkomen, zullen de bestanden niet opnieuw worden gedownload. Bestanden die verouderd zijn, worden wel vernieuwd, maar alleen die bestanden. Dit betekent dat overschakelen van SVN -> HTTP ervoor zorgt dat niet alles weer opnieuw wordt gedownload.

Het overschakelen naar een andere server, zelfs binnen dezelfde FG-sessie, is ook mogelijk en zorgt er ook nu voor dat niet alle eerdere bestanden opnieuw worden gedownload, in tegenstelling tot de SVN-opzet waarbij de server-URL deel uitmaakt van de repositorystructuur.

• het terrasync/netwerkprotocol/ zal blijven bestaan, wat betekent dat ieder zijn eigen externe terrasync systeem kan schrijven (met gebruik van een breed scala van computertalen, waaronder Python) met behulp van rsync of elk ander mechanisme dat je maar wilt. Mijn hoop is dat dit een goed en beheersbaar uitgangspunt biedt voor zeer gevorderde gebruikers, terwijl het ingebouwde HTTP mechanisme eenvoudig en robuust zal zijn (dankzij het feit dat het op hash gebaseerd is) voor 95% van de gebruikers.

We hebben al drie kopieen van het complete landschap online, één bij sourceforge en twee bij private servers. De sourceforge computer ontvangt dagelijks updates van de belangrijkste scenery van http://scenery.flightgear.org/ en alle andere mirrors (computers) halen hun gegevens van de sourceforge server. We besloten de vorige methode, om de klant te vertellen over de dichtstbijzijnde mirror, te laten vallen en in plaats daarvan een webservice (http://scenery.flightgear.org/svn-server) te bevragen ten gunste van het gebruik van een stabielere serviceprovider van het internet: het domeinnaamservice (DNS) systeem. De fgfs client zal een resource record (RR) type NAPTR (network authority pointer, https://en.wikipedia.org/wiki/NAPTR_record) bevragen voor de dns naam terrasync.flightgear.org en de gegevens analyseren om de beste terrasync mirror te vinden. Deze gegevens zijn al geconfigureerd en kunnen hier worden bekeken: https://toolbox.googleapps.com/apps/dig/#ANY/terrasync.flightgear.org. Deze techniek zou ons in staat moeten stellen om veschillende scenery's aan te bieden, uiteindelijk zelfs voor delen van de wereld en dat op een manier die beduidend eenvoudiger zal zijn dan bij SVN het geval zou zijn geweest. Het bespaart ook vele gigabytes op de scenery mirror, omdat niet alle 50.000+ beschikbare revisies continue beschikbaar hoeven te zijn. Ik zal de komende dagen beginnen met het toevoegen van de vereiste code zodat de nieuwe opzet hopelijk voor de 2016.2 release gereed zal zijn. Ik zal een bericht zenden wanneer ik besluit om de nieuwe versie van terrasync in te schakelen. In de tussentijd zie je mogelijk een aantal "build" fouten of andere hickups van het systeem. Ik beloof dat ik die fouten zo snel mogelijk op zal lossen. Trouwens, als je terrafs gebruikt, ontvangt je al je gegevens al van de nieuwe http mirror, hoewel je geen gebruik maakt van de DNS service resolver.

De http download methode zal goeddeels op dezelfde manier werken als voorheen, maar nu worden alleen de (eventuele) gewijzigde bestanden gedownload. De svn methode vereist 2x de werkelijke ruimte op de harde schijf als gevolg van de manier waarop svn werkt. Gewoonlijk vereist Git dat je elke versie die ooit is gemaakt downloadt om de nieuwste kopie te krijgen (er zijn wel omwegen voor het geval je gewoon de alleen meest recente versie wilt.) Dus het eindresultaat voor de gemiddelde gebruiker die gewoon de scenery voor gebruik wil downloaden, is dat de http methode in het algemeen sneller zal zijn. Het vereenvoudigt ook de programmeercode voor FlightGear behoorlijk en zou de synchronisatie ook beduidend robuuster moeten maken. Zoals al eerder gezegd zou het, voor degenen die dat willen, veel vereenvoudigen moeten worden om een scenery mirror op te zetten. Net als voorheen hebben power users meerdere opties voor het updaten van scenery en, indien ze dat zouden willen, deze eventueel vanuit verschillende bronnen te combineren.

De techniek van de http repository is veel eenvoudiger dan die van de svn repository en het zal vrij eenvoudig zijn om een lokale mirror op te zetten of om blokken data te downloaden. Met enige nog te ontwikkelen scripts (in combinatie met bijvoorbeeld python) is het niet nodig om bestaande data opnieuw te downloaden. Ik weet niet hoe terramaster werkt, maar ik ben er zeker van dat het eenvoudig zal zijn aan te passen aan de nieuwe http-opzet.

Het doel is om SVN volledig af te stoten en alleen nog de HTTP repository te gebruiken. Ik zou dat doel het liefst z.s.m. willen bereiken, omdat we op dit moment twee mogelijke bronnen voor problemen hebben wat betreft de SVN-service. De eerste is de webdienst http://scenery.flightgear.org/svn-service (die draait op een private webserver) en de tweede is de enige SVN-server die beschikbaar is voor publieke toegang en die ook gehost wordt op een private server. Als een van beide wegvalt, is de SVN-terrasync onbereikbaar. Ik heb in het verleden ondervonden dat het een slecht idee is om niet te voorzien in een terugvalmechanisme.

Torsten zond een patch naar SimGear, inclusief een aantal debugberichten. (deze zijn echter alleen zichtbaar bij gebruik van de optie --log-level=debug - eventueel --log-class=terrasync om de output enigszins beperkt te houden)

We hebben nu C++ en Python referentievoorbeelden die beide hopelijk makkelijk te gebruiken zijn. Trouwens, de C++ tool vind je hier: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/io/http_repo_sync.cxx Ook hier zijn voorstellen voor verbeteringen welkom.

Referenties

terrasync.py

Eerst en vooral: je kunt het hier vinden: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/scripts/python/terrasync.py

Het script is nu in staat om een complete mirror van de scenery data, ook wel bekend als terrasync scenery of gewoon terrascenery, te voorzien.

Let op  Voor de ongeduldigen, voordat je het uitprobeert: Als je dit script voor het eerst uitvoert, downloadt het meer dan 90 GB aan gegevens en meer dan 1.800.000 bestanden in 40.000 mappen naar jouw harde schijf. Het zal uren duren, waarschijnlijk dagen (afhankelijk van de internetverbinding).

Als je al een deel van de scenery data hebt via flightgear's ingebouwde terrasync of misschien zelfs een volledige SVN checkout, dan worden bestaande bestanden die up-to-date zijn hergebruikt en niet nog een tweede keer gedownload.

Hoe werkt het

De HTTP terrascenery server bevat alle bestanden die nodig zijn voor scenery, georganiseerd in de bekende directory-structuur (/Modellen/Objects/Terrain en /Airports) met al hun subdirectories. De inhoud van de map /Models bijvoorbeeld vind je hier: http://flightgear.sourceforge.net/scenery/Models/. Iedere map bevat een (verborgen) bestand genaamd .dirindex (bijv. http://flightgear.sourceforge.net/scenery/Models/.dirindex) dat de inhoud van die map beschrijft door het overzicht van alle bestanden, submappen en checksums van de de bestanden en hun submappen' .dirindex files. Het terrasync.py script doet (vereenvoudigd) het volgende:

• a) download het bestand bij de root (hoogste niveau) van de scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
• b) gaat een submap in die in de .dirindex is opgenomen
• c) vergelijkt de sha1sum van de in de lijst opgenomen bestanden met de lokale kopie en downloadt bestanden indien ze niet overeenkomen
• d) met de in de lijst opgenomen subdirectories en herhaalt deze stappen voor de volgende mappen als bedoeld in b).

Zelfs als alle scenerybestanden op de server aanwezig zijn, ontbreken nog zo'n 40.000 .dirindexbestanden op jouw harde schijf en het downloaden ervan zal meerdere uren duren. Om de procedure te versnellen, nadat je alle .dirindex bestanden lokaal hebt, kun je terrasync. py uitvoeren met de optie --quick. Dit zal terrasync. py opdragen om de berekende sha1sum van elk .dirindex bestand op jouw harde schijf te vergelijken met het overzicht in de bovenliggende directories .dirindex. Als je een bijgewerkte mirror hebt zal dit vrij snel gaan omdat alleen de root. dirindex gedownload moet worden. Latere updates met de optie --quick zullen ook zeer snel gaan, omdat alleen de bijgewerkte bestanden worden gedownload evenals de .dirindex bestanden van de bovenliggende mappen tot aan de hoofdmap.

Tot nu toe hebben we alleen bestanden aan jouw harde schijf toegevoegd, maar hoe zit het met bestanden die van de server zijn verwijderd? Het script doet daar over het algemeen niets mee, tenzij je aan de opdrachtregel de optie --remove-orphan toevoegt. Door dit te doen, vraag je terrasync.py om alle bestanden (geen mappen) te verwijderen die in een subdirectory staan maar niet in het corresponderende .dirindex worden genoemd.

Als je niet alles naar jouw huidige werkdirectory wilt downloaden, voeg dan --target=/map/bestand toe aan jouw opdrachtregel. Dit beschrijft vrijwel alles wat terrasync. py doet. Hieronder volgen enkele voorbeelden voor het gebruik:

# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file 
terrasync.py --target=/home/joe/fg/scenery 

# just pull in changes, quick and lean for subsequent updates 
terrasync.py --target=/home/joe/fg/scenery --quick 

# run a mirror, only keep those files listed on the server 
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan 

# use another server to pull the data, not the sourceforge master 
terrasync.py --target=/home/joe/fg/scenery --url= http://someserver.org/otherscenery

Schakelen tussen SVN en HTTP terrasync is slechts een kwestie van het instellen van een opstart-eigenschap. De opdracht --prop:string:/sim/terrasync/http-server=automatic maakt een keuze voor HTTP, het niet opnemen van deze opdracht zal leiden tot het gebruik van de SVN-methode. De code lijkt robuust genoeg om heen en terug te kunnen schakelen tussen zonder verlies van data.

Enjoy, feedback welcome.

TerraSync inschakelen

FlightGear 3.0 en latere versies

Vanaf FlightGear 3.0 is TerraSync aanzienlijk veranderd. Standaard, wanneer het is ingeschakeld met --enable-terrasync downloadt TerraSync nu naar download_dir/TerraSync, waarbij download_dir de downloadmap van FlightGear is.

De downloadmap van FlightGear kan expliciet worden ingesteld met behulp van de optie FlightGear's --download-dir op de Command_line_options, anders wordt de standaardoptie gebruikt:

• $FG_HOME op niet-Windows systemen;
• Zoiets als C:\Users\username\Documents\FlightGear op Windows-systemen.

Optioneel kan de TerraSync directory expliciet worden ingesteld met de optie --terrasync-dir via de Command_line_options in FlightGear, of via het dialoogvenster Geavanceerd > Algemeen van FGRun. TerraSync zal die directory vervolgens gebruiken voor de downloads. Die directory krijgt dan automatisch de hoogste prioriteit, tenzij anders aangegeven in $FG_SCENERY. Er is geen andere configuratie nodig.

Samengevat, als je FlightGear niet instelt op --terrasync-dir of --download-dir, dan is de standaard TerraSync directory :

• $FG_HOME/TerraSync op niet-Windows systemen;
• Zoiets als C:\Users\username\Documents\FlightGear\TerraSync op Windows-systemen.

FlightGear 2.4 t/m versie 2.12

Vanaf FlightGear 2.4 is TerraSync geïntegreerd in het normale FlightGear menu, onder Omgeving > Scenery Download > Downloaden. Je kunt ook kiezen voor "Download scenery on the fly" in de GUI. Wees er wel op attent dat als je jouw vliegtuig wil laten starten in een nieuw gebied, waar je nog geen landschap van hebt gedownload, jouw vliegtuig bij de start in het water kan lijken te staan totdat er voldoende landschap is gedownload. Via menu Omgeving > Scenery Download en "Manual Refresh" (Handmatig vernieuwen) kun je kiezen voor scenery-updates.

POSIX (Portable Operating-System Interface) -conforme commandoregel

Start TerraSync:

% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"

De -S optie maakt dat terrasync het SVN-protocol zal gebruiken om gegevens op te halen. Als je die optie weglaat zal terrasync in plaats daarvan het programma rsync gebruiken (maar dat moet dan wel op jouw systeem geïnstalleerd zijn).

Start FlightGear:

% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="$FG_ROOT/Scenery/:$HOME/fgfsScenery"

De volledige documentatie voor TerraSync kun je vinden in de broncode van FlightGear (in utils/TerraSync/).

FGRun in FlightGear 2.2.0

1. Controleer na het starten van FGRun of je je in het eerste scherm bevindt waar je directories kunt instellen. Eén keer "Terug" vanaf de vliegtuigkeuzepagina. Je bent nu op de "Path" -pagina.
2. Naast FG_SCENERY kun je een lijst met scenery directories aanmaken. Selecteer de lijn die TerraSync zal gebruiken en druk rechts op de knop "TerraSync directory". Op de geselecteerde regel verschijnt een kleine "T" die aangeeft dat deze is ingesteld als TerraSync-directory.
   • De directories worden van boven naar beneden geladen, dus zorg ervoor dat TerraSync bovenaan staat (tenzij je terrasync gegevens uit een andere directory wil laten prevaleren). Wanneer twee directories landschappen bevatten voor dezelfde regio, zal FlightGear de scenery uit de directory halen die hoger in de lijst staat.
3. Ga tenslotte naar het laatste scherm. Daar moet je TerraSync activeren zoals in de volgende screenshot wordt getoond. Nu moet TerraSync werken.
   

Opmerking: Houd er rekening mee dat de firewall dit kan blokkeren zodra je het de eerste keer gebruikt; sta de firewall toe dat TerraSync de getoonde poort gebruikt.

FGRun in FlightGear 1.9.1

1. Controleer na het starten van FGRun of je je in het eerste scherm bevindt, waar je de directories kunt instellen. Eén keer "Terug" vanaf de vliegtuigkeuzepagina. Je bent nu hier:
   

1. Selecteer de bestemmingsmap voor alle bestanden die door terrasync worden gedownload. Meestal bestaat de map $FG_ROOT\terrasync al en hoef je deze alleen aan de lijst toe te voegen (zoals in het bovenstaande voorbeeld). Zorg ervoor dat het boven uw standaard scenery map zit (hier is dat FlightGear191\scenery) en alle andere mappen waarop de map terrasync voorrang moet hebben. Wanneer twee directories informatie bevatten voor dezelfde regio, zal FlightGear de informatie uit de directory kiezen die hoger in de lijst staat. Zorg er onder Linux voor dat de directory niet alleen een T heeft, maar dat het ook de bovenste map is.
2. Om TerraSync te laten weten waar de gedownloade bestanden moeten worden opgeslagen, moet je het programma aangeven welke map de doelmap is. In bovenstaand voorbeeld is het de 3e regel in de lijst.
3. Ga tenslotte naar het laatste scherm. Daar moet je TerraSync activeren zoals in het volgende screenshot. Nu zou TerraSync moeten werken.
   

Opmerking: Houd er rekening mee dat de firewall dit kan blokkeren zodra je het de eerste keer gebruikt; sta de firewall toe dat TerraSync de getoonde poort gebruikt.

probleemoplossing

foutieve en onleesbare bestanden of mappen

Het is mogelijk dat je op de commandline (zwart dialoogvenster) een fout krijgt, vergelijkbaar met het volgende:

Airports/L ... failed:
Can't move 'C:\FlightGear\terrasync\Airports\L\E\.svn\tmp\entries' to 'C:\FlightGear\terrasync\Airports\L\E\.svn\entries': The file or directory is corrupted and unreadable.

terwijl eventueel de volgende popup verschijnt:

Oplossing

Je kunt de fout waarschijnlijk verhelpen door naar Windows 7 Home Premium Service Pack 1 te upgraden.

Onbereikbare vliegveldmappen

Terwijl TerraSync draait kun je een foutmelding krijgen die aangeeft dat de map met vliegvelden onbereikbaar is.

Working copy 'D:\Program Files\FlightGear 2.4.0\terrasync\Airports\K' locked

Ondertussen worden die mappen vaak wel bijgewerkt wat de fout extra vervelend maakt.

Oplossing

Zoek in de TerraSync-map naar bestanden met de naam lock en verwijder deze. Ze zouden automatisch moeten worden verwijderd wanneer TerraSync wordt geupdate, maar soms lukt dat niet.

Kon bestand niet verwijderen

file remove failed: (./.terrasync_cache) reason: Permission denied

TerraSync cachebestanden kunnen niet worden verwijderd. In een terminalvenster zie je fouten zoals hierboven. Je kunt niet veel anders doen dan de .terrasync_cache handmatig te verwijderen en FlightGear opnieuw te starten.

Resolutie

Let op  Niet aanbevolen. Begrijp de gevolgen

Forum Post w/ PowerShell command is here

Intern

De SHA1 (Secure Hash Algorithm 1) hashes zijn de weerslag wat er in de .dirindex bestanden staat, zowel op de server als op jouw computer. Wij synchroniseren time-stamps niet met de serverkopieën, omdat het aan de serverzijde een efficiënte mirroring bemoeilijkt (minder efficiënt). Ik ben er vrij zeker van dat "hasj clashes" geen probleem zijn, als de mensen van Git dat ook denken. We vertrouwen uitdrukkelijk niet op speciale of bepaalde HTTP headers om de kans te maximaliseren dat we in de toekomst 'gewoon' kunnen werken met verschillende HTTP providers en CDN (Content Delivery Network) opties. De structuur van de .dirindex bestanden is tekst-gebaseerd en hopelijk duidelijk genoeg voor iedereen die de moeite neemt om er naar te kijken; ze worden op de server gegenereerd door enkele scripts die Torsten schreef. De code gebruikt in principe dezelfde logica als Git om SHA-hashes voor de gehele repository opnieuw te berekenen; als een van de verschillende stat() velden, vooral sie of mod-time, veranderen, herberekenen we de hash voor dat bestand op schijf. Wanneer de hash van een bestand op de computer verschilt van wat het volgens het .dirindex bestand zou moeten hebben, dan downloaden we het betreffende bestand. Dat is zo ongeveer een complete beschrijving van het synchronisatiemodel. Daarom is het veilig om bestanden naar de directorystructuur te kopiëren met behulp van een stuk gereedschap, of het te wijzigen - dit zorgt ervoor dat de stat() data veranderen, waardoor de programmeercode de SHA-hash opnieuw zal berekenen; waardoor een her-download naar de server wordt gestart als de SHA niet overeenkomt. Let op: er is geen voorziening die voorkomt dat er gewijzigde (beschadigde) bestanden in de directorystruktuur zitten; ze worden altijd overschreven als ze opnieuw worden gecontroleerd.

Gerelateerde inhoud

• Howto: Install scenery
• TerraMaster