Free Flight, Free Speech

Hi All.

Some airports in the philipines are updated in terraGIT



Airports


RPLI


Terrasync

TerraGIT




RPLC



Terrasync

TerraGIT



RPVM


Terrasync

TerraGIT


RPUL



[b]Terrasunk

TerraGIT

:O
Nice job.

I am sure TheFilipinoPilot will be happy.

I AM VERY DAMN HAPPY! RPVM will have its models within next week, I am very busy at school on the weekends.

Thank you! Thank you and thank you sir Israel! you are a Genie!

I also made some textures to better simulate the Philippine terrains, I will give that by nextweek,

See this is why the core-clowns are doing a mistake with their stupid terrasync methods!

Look how much more development would happen if its done the way terraGit does it.

Enjoy FilipinoPilot

SHM wrote:See this is why the core-clowns are doing a mistake with their stupid terrasync methods!
Look how much more development would happen if its done the way terraGit does it.

This is indeed a good point and would be better without the insults. The work that is going on here and in other places to improve airports is a very good thing in terms of the content.

I'm probably going to go off topic now and bear with me if I'm wrong because scenery isn't my area of expertise.

TerraSync is not a scenery storage method it is a distribution method. It would be very nice if terraGit supported the Terrasync protocol (via HTTP); as that would avoid having to download the whole lot and the changes could be picked up as you're flying along.

The standard FlightGear scenery database is stored in a PostGIS database; which was used to generate the data that TerraSync serves and that was the start point for terraGit.

I believe changes submitted to the scenery website (except airports) will be picked up and added to TerraSync - I'm not sure if these will get pulled through into terraGit - Israel can advise us about this.

However what doesn't currently work is airport changes; and this is because this bit was never automated. There is a method for manual updates but it's quite complex to prepare the data in the right format.

Lots of this will change when Pete gets V3 finished and the entire world is regenerated from the PostGIS database - which is why it's important to submit the airport buildings (and possibly other things) to the scenery models website - there are rules for inclusion which affect the objects and texture sizes that need to be followed - which may exclude certain custom models or textures that cannot be made to fit within the rules.

Ideally to future proof any scenery development most things need to go into the scenery database as otherwise they'll be lost when the world is regenerated for V3.

Richard wrote:This is indeed a good point and would be better without the insults. The work that is going on here and in other places to improve airports is a very good thing in terms of the content.

Thanks.

TerraSync is not a scenery storage method it is a distribution method.

I know that very well, but the problem is that only a very small group/a single person only has the keys to push into it. And they just don't update the scenery as fast as terraGit is doing.

It would be very nice if terraGit supported the Terrasync protocol (via HTTP); as that would avoid having to download the whole lot and the changes could be picked up as you're flying along.

terraGit already supports it. Only problem is that we are low on resources (a server). Then it is only matter of changing the server details of the official one with ours. And that means it could download the scenery on the fly just like terrasync does.

I believe changes submitted to the scenery website (except airports) will be picked up and added to TerraSync - I'm not sure if these will get pulled through into terraGit - Israel can advise us about this.

I didn't understand that.
But if you are talking about the objects that is added to the scenery database, a merge happens every month so terraGit remains gets all of it.

However what doesn't currently work is airport changes; and this is because this bit was never automated. There is a method for manual updates but it's quite complex to prepare the data in the right format.

As you can see all the scenery is generated by terraGit, it is just the matter of pushing it into terrasync.

Lots of this will change when Pete gets V3 finished and the entire world is regenerated from the PostGIS database - which is why it's important to submit the airport buildings (and possibly other things) to the scenery models website - there are rules for inclusion which affect the objects and texture sizes that need to be followed - which may exclude certain custom models or textures that cannot be made to fit within the rules.

I have been hearing about V3 a lot, but its not here and for now terraGit is better.

Ideally to future proof any scenery development most things need to go into the scenery database as otherwise they'll be lost when the world is regenerated for V3.

Even after V3 comes, terraGit is here to stay


SHM

The thing with a terrasync like service is that it is quite heavy on resources, and thus relatively expensive. The server itself is the least of your worries. For a good experience you need a high speed connection. And you may expect a high volume of bytes to be sent, for which you may have to pay for extra. A simple cable connection from home will not do.

Over here you can get something good in a data center for around 1000 euro per year. Expect a few hundred more if the data volume is really high. I do not think anyone is going to put up for that all by himself. So unless we think of a funding system, i do not think a terrasync like service will happen any time soon.

Kind regards, Vincent

@IAHM-COL, it seems like the coastline is still not so good, is there any reason why osm_landmass can't be used?
Looking very good, btw