Responding to Richard

[IAHM-COL]

whereas I'm genuinely not sure about what's going to happen with git when it comes to a merge with a newly generated V3 database

Can you clarify and take this statement away of the "FUD" realm.

How can V3 affect git (or terraGIT) for this matter.

[IAHM-COL]

Obviously I'd hope it went well and git managed to sort out any conflicts or merges; but until it's been done we just don't know what will happen

Well.. How will terrasync take this content? Terrasync is a svn repository.
If terrasync can take that content; how is this becoming an impossibly unmanageable content for terraGIT?

Furthermore, if you are going to keep V1 and V2 scenery forward compatibility, even more logic to me that terraGIT is just fine when V3 comes.

I just don't foresee how is the scenery going to change in a way that can be ported and used in a svn repository but will become unsolvable, unporteable, unshippeable in terraGIT.

I dont see a reasonable posture of that fear. And on the contrary, it seems to me unreasonable to veto terraGIT just on the Fear of Scenery V3....

[IAHM-COL]

and the worst case is that it is entirely incompatible and TG becomes locked with V2

TG is terraGIT or terragear?

Assuming that it is terraGIT, once again, how is V3 incompatible with Git? or terraGIT? I mean, further of "I am panicking", what is exactly the incompatibility?

Will it produce scenery for Flightgear in the form of files?

[IAHM-COL]

Finally everything that is in the scenery should as close as possible to the real world and nothing fictional;

Mmm. That could be a problem.
Cause terraGIT would not be restricting content to "reality mimicry" only.

So that could be very well a reason why terrasync would be better never syncing the content from terraGIT.

Well... that would be their lose. and It would be a shame to miss the opportunity.

In particular, I dont think many of the models you'll find in terrasync are so wonderfully close to the real deal... anyways. But here, we are talking aesthetics, and beauty is in the eye of the beholder.

[IAHM-COL]

It looks to me as though XPlane uses a similar source -> target database for submissions to the WED

It is actually the other way around, Richard.

One uses WED to build the aiport -> Submit to the database.

The gateway, indeed, if that is your point, is a gateway for entry of content. And it is actually well designed to serve the purpose.

In a way ---too many---, I feel the Xplane community is much better put together than FG's. And it is, for me a real sad thing.
(since I am a pure FGer)

[KL-666]

My take on this discussion is that you guys endanger yourselves to not understanding eachother, because you talk in solutions (current terrasync and terragit) instead of discussing requirements first. Take a step back and start with the requirements.

- What material are we dealing with? Data? Software?
- What is a good way to work with that material? (developing and delivering it to users)

Only after such questions are answered, you can go forward and decide what satisfies the requirements best. Maybe a database, maybe git, maybe xml files, who knows.

I have my answers to such requirements ready:

- The material is a 100% data, because it does nothing, does not interact with users. It is sort of static. But that does not mean one must jump to conclusions that it must be in a database. That depends on the nature of the data and could as well be xml files if that fits the data better.

- For a workflow i find it best practice to have a separate development environment and a production environment. In the development environment you hold data as raw and detailed as possible, to keep all options open. For production you generate out of development a new dataset that emphasises on performance. e.g. In development you have every building separate, but for production you may generate aggregated groups out of that for performance reasons.

How to save both environments, can be different. Say development can be a database while production is in xml files or so. These decisions are secondery to the requirements.

Now it is not clear to me Israel, whether what you propose distinguishes between data in a development form and data generated from that for performance in production.

Kind regards, Vincent

[IAHM-COL]

- What material are we dealing with? Data? Software?
- What is a good way to work with that material? (developing and delivering it to users)

1. The material we are dealing with is 100% data. This is, terraGIT/terrasync content is Not a source code. It is presented in a form that is ready to be interpreted/rendered as Scenery for FlightGear.

2. TerraGIT and terrasync are both ready for delivering to users.
* terraGIT must be cloned in a local hard drive, and world scenery to be used must be initialized per tiles or other manner (see install script) to get partly or wholy world scenery ready in a local disk. TerraGIT also serves as development repository of this content, in the sense that you can submit updates to it, directly and with no intermediates (exemple, pushing a new airport layout, or a new terminal for Sao Paolo)

* terrasync is a content 100% similar is nature to that of terraGIT but it is distributed differently. Either on the fly, or via terrafs/terramaster or subversion.
Terrasync could also serve as a repository for pushing updates to this content, but no-one uses this as such.

The sources are located elsewhere, and the content is created, outside of the distribution ready sandboxes, such as terrasync/terraGIT.
Examples:
The "Scenery projects such as India or Philippines"
https://github.com/ProjectPhilippines
https://github.com/projectindia-FGFS
https://github.com/NorwayProject

or, the Scenery stand alone projects in FGMEMBERS-SCENERY
https://github.com/FGMEMBERS-SCENERY

Where to maintain sources content and to specifically have the "development" content of the ready-to-be-rendered scenerios in terrasync/terraGIT is a completely different bulk.

[IAHM-COL]

Let's try the one pic is worth thousand words approach

I made a diagram that shows how it all could play together, and how terraGIT can be used to cleanly facilitate FG scenery development neatly just by accomodating it upstream.



IH-COL

[Richard]

1. Is the numeric ID in the STG guaranteed never to change?

No numeric Index ID present. The STG database is parsed by FG one line at a time, and it draws the specified object in that one line in the lat, lon, elevation, heading, pitch coordinates presented.

I meant the ID in the file name, sorry for being ambiguous.

[Richard]

What I think of as the scenery database is the sources that are used to build the run time scenery database which I think of (and might refer to) as the visual database.

Do you refer to https://scenery.flightgear.org/?
...
So, trying to sell the Website database as a "sources database" is a bit of an over-sellout.

Sources as in data sources: i.e.: http://wiki.flightgear.org/FlightGear_W ... ource_data

When I say "database" I just mean a collection of data; this could be in XML files, flat files, ac3d models or a RDBMS (which might be PostGIS, MySQL, etc), etc.