Free Flight, Free Speech

IAHM-COL--

For those of us who aren't as fluent in the more technical side of FG, could you do a quick executive summary of the issues? It would help me understand in more plain language the seriousness you appear to be trying to communicate--that the replies above haven't quite fully appeared to pick up on.

Thanks,

Dr. David

BTW Israel it is Torsten not Thorsten

Thanks MiG29 pilot
good catch
Corrected

Hi Dr. David

PART I

The issue at hand is very simple.
Terrasync is massive. It contains as we speak a growing collection of 140+ GB of scenery data for the whole world.
It used to be hosted in Google codes; which closed Midway this year.

As a solution, other series of servers or mirrors where established to host it.

For some undeclared reason, these laters will no longer serve FG, so terrasync needs a new home. Without a new home we loose our ability to access the scenery via terrasync.

PART II

The issue becomes more heated when we get to realize that Terrasync scenery is the icon of "centralization".
This translates to the fact that I would believe no one but the terrasync hostess servers contain the information there hosted (completely).
It is actually a fact, that being a SVN server it means the "repository" complete data exists nowhere else. But I mean on the simplest term that locally you only have partial copies of the data respective to where you had flown. Not the whole world!

If terrasync becomes unavailable it may be rather all that information become unaccesible for its own good.

So Torsten request is: Can somebody help? Meaning: Is there any FGer capable and willing to privately host the scenery databases, supportive landclases and scenery content?

That is clearly a solution. We loose a home. We find a home

PART III

I propose something that is now 1) way more technical and 2) requires code core changes into how FG understand scenery. It basically attempts at making it more modular. (with each 10x10 degree tile being a module). This would allow hosting the complete scenery (the whole 140+ and growing data) in a collection of public repositories. Thus, instead of handing the data to another private FGer, it will go to Github, Gitlab or whatever.

Becoming git it will become distributed. In pieces (modules).... but distributed anyway. Meaning anyone can have the whole information for any tile of choice. Meaning also anyone can fork any tile of choice as we do with airplanes, and be able to modify it to suit his/her own scenery needs, and provide an alternative distribution for such tile.

Pull request as done for aircraft will become also doable. So scenery submission does not mean only add a new building. It could mean restructuring the scenery. Creating new layouts, and or modifying existing, and share them on the fly. It also means that we could submit patches for xml files that control per example, animated jetways, or groundnets. All with ease and transparency. --with the same ease that nowadays aircraft patches can come via FGEMEMBERS

PART IV

Furthermore, if the tiles were to exist like that, as we do with aircraft, we can devise "tile branches". This enable us to have alternative versions of the same patch of scenery that are easily switchable (as modules are), by just changing one directory for another, or checking out a different git branch.
The posibilities would be endless. Think, per example, having a 1914-branch that allows you to easily switch your scnery to an old-days version of a tile located in Europe. Think, per example having a branch that contains a reduced triangles for heavy areas (triangles in the scenery make the scenery with mountains more heavy and kill performance in slow computers), or switching a branch that contains XT KXTA as oppose to RL KXTA.

The end becomes your imagination.

As we are right now, having alternatives for the Scenery just works by having scenery packages.

I hope that clarifies.

IH-COL

IAHM-COL wrote:Thanks MiG29 pilot
good catch
Corrected

It can be confusing
Torstein, Thorsten R., Thorsten B.
Stuart, StuartC
Jonathan S, Jonathan R.