Board index FlightGear Development Scenery

Terrasync Help (surprinsingly!) :)  Topic is solved

Questions and discussion about enhancing and populating the FlightGear world.

Terrasync Help (surprinsingly!) :)  

Postby IAHM-COL » Sun Nov 23, 2014 9:13 pm

@ALL

I had been working in editing an airport Layout (WED). apt850 already exists but I am trying to increase details, plus add a few missing elements.

I am succesfully using terragear and all its accesories to build the airport and its surrounding terrain, which is all great. But I am facing a little problem.

Apparently the SRTM data (both SRTM-1 and SRTM-3), as I can get from here: http://dds.cr.usgs.gov/srtm/version2_1/
Is different to that data (elevation profiles) used to build the Current terrasync Scenery.

That is causing an interesting problem. For those versed, the buildings sitting in terrasync are on the elevation provided by terrasync, while my layout is in the elevation provided by the SRTM as I've built. The visual consequence is that these buildings now are showing sunk in the ground by about 12-15 feet (short of 3 meters). I don't want to mess with the objects offset, because one day the terrasync layout will be updated creating a whole new problem. I must confess it drives me "nuts" to see the buildings partly or fully underground (depending on their height), so "just waiting" for the long-future terrasync will be updated doesnt sound like an appealing option. [I am going to be submitting the updated 850 when I got all clean up.]


In the meantime, I know what will solve my short-term problem. Basically I need the SRTM (hgt) file pertinent, that is exact to the one used to build the current terrasync scenery, so when I sync my layout with terrasyncs, we are at the same elevation. Hence my layout will not be sitting like 12 feet higher.

My problem is: Who has these files? Who is to contact to get hands on the SRTM (htg) file used for the current terrasync version?

It will be great to hear someone pointing a finger, or better yet, saying "That'll be me!, here's the htg" :oops:

(please dont take me for rude... I am just a little anxious with this ATM)

***************

So what exactly would I'd love to have?
This one: N37W116.hgt.zip
(version used to build the current terrasync scenery)
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Terrasync Help (surprinsingly!) :)

Postby wlbragg » Mon Nov 24, 2014 1:01 am

Please someone correct me if I am wrong, but I think the FG scenery used panoramas.org for the elevation data.

You might want to try and generate small chunk and see if it matches.

The main site is http://www.viewfinderpanoramas.org/dem3.html
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Terrasync Help (surprinsingly!) :)

Postby ludomotico » Mon Nov 24, 2014 1:16 am

IAHM-COL, some weeks ago I wrote a post trying to explain how elevation works in FlightGear, for general terrain and airport areas. Look for this post, I'm using a mobile phone and can't search for it.

Long story short: the SRTM you have is the same than the one used in terrasync. Actually, FG uses the corrected version pointed out by wlbragg, which fixes some small errors but it should be exactly the same data 99% of the time. Elevation in FlightGear is not real, it is simplified and approximated and each time you generate the terrain it may change! To prevent this, calculate elevation only once and save the elevation temporal files forever. There are some parameters you can modify during the generation of the elevation. They can get more accurate results at the cost of more disk space. The exact parameters used during the generation of the scenery in terrasync were never made public, but it doesn't matter because each time you run terrafit you can get different results and differences of several meters.

Hence, do not expect having the same elevation than terrasync in your custom scenery. In fact, if you rebuild the elevation in terragear again, do not expect the same elevation than before. You have to take this info account when managing custom scenery and submitting models to terrasync. I have my own scripts to deal with this issue in my custom scenery.

To submit models to the webpage, if you enter -9999 as the elevation, your model will be set on ground now and in the future, if the terrain changes. Your custom scenery will use absolute elevations, but always input -9999 in the webpage.

In fact, if I recall correctly, -9999 (=on ground) is the only accepted value for the webpage and any elevation you set is currently ignored.
User avatar
ludomotico
 
Posts: 1018
Joined: Tue Apr 24, 2012 1:01 pm
Version: git
OS: Debian GNU/Linux

Re: Terrasync Help (surprinsingly!) :)

Postby wlbragg » Mon Nov 24, 2014 1:42 am

if I recall correctly, -9999 (=on ground) is the only accepted value for the webpage

That is my understanding also.

I think the parameters ludomotico is referring to are

Min. nodes
Max. nodes
Max. error ______ meter

on the elevation tab of the GUI.

I don't remember if they have a default value or not.
I have used values of

50
1000
40

and

1000
4000
40

with the second set being the one that would produce more "accurate" or detailed data, I think.

I don't remember exactly where I picked up these setting but know I got them from the forums somewhere.
I guess you'll just have to play with it and see if you can get it to match Terrasync a little more closely.

That's the extent of my VAST knowledge on this subject... :lol:

If you do find a setting that seems to work better, please share it with us.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Terrasync Help (surprinsingly!) :)

Postby f-ojac » Mon Nov 24, 2014 7:08 am

Read again the World Scenery 2.0 release announcement or wiki page. AFAIR all details about input data is in.
--
If you want to support my Terrasync server, hosted on a private server, you can donate here: http://ns334561.ip-5-196-65.eu/WS2.0/WS ... 2.0.1.html
f-ojac
 
Posts: 1276
Joined: Fri Mar 07, 2008 9:50 am
Version: GIT
OS: GNU/Linux

Re: Terrasync Help (surprinsingly!) :)

Postby ludomotico » Mon Nov 24, 2014 10:28 am

f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.

Anyway, your real issue is not elevation of the terrain but the elevation of your models. Use absolute elevation in your custom scenery (but remember: do not recalculate elevation in TerraguearGUI unless you want to reposition your models!), and -9999 to submit models to terrasync.
User avatar
ludomotico
 
Posts: 1018
Joined: Tue Apr 24, 2012 1:01 pm
Version: git
OS: Debian GNU/Linux

Re: Terrasync Help (surprinsingly!) :)

Postby wlbragg » Mon Nov 24, 2014 11:16 am

Thank you for those details ludomotico/f-ojac.
I don't recall ever seeing its use explained this well.
Added discussion to Terragear CORINE and Using TerraGear
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Terrasync Help (surprinsingly!) :)

Postby psadro_gm » Mon Nov 24, 2014 12:58 pm

Here's a page I started a while ago to document both the design and command line parameters for the terragear toolchain. Sadly, I haven't gotten too far with it.

http://wiki.flightgear.org/TerraGear_Documentation
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Terrasync Help (surprinsingly!) :)

Postby wlbragg » Mon Nov 24, 2014 4:47 pm

Thanks, I added this relation to all the other related pages.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Terrasync Help (surprinsingly!) :)

Postby IAHM-COL » Mon Nov 24, 2014 6:23 pm

Thanks everyone for jumping to help me on this, and the very very helpful information. I am learning a great deal of how things are working under the hood here.

I had been reading the documentation pointed and testing/experimenting here and there to see what helps.

So far no luck. This is what I've tried so far

1. Download the panorama and rebuild scenery . Output was identical regardless of the htg source
2. Use the terrafit instructions above. The scenery comes more detailed, but the elevation profiles are very very alike, and the models are sunk about the same depth
3. Models elevation. I checkd the stg file that is being download'd by terrasync. The elevations dont state -9999. I changed this manually and the objects dont set on ground, but dissapear by sunking that much :S

When I uploaded to terrasync, they did warn me that "elevation" was ignored, and offset the only value to be taken into account. (for massive imports). I input the elevations in my stgs (not -9999). It didnt affect the process and the objects sat in the ground if terrasync scenery is used. But sank in the custom scenery.

When I uploaded a new static, there does not exist a place to state "elevation" per se. Only offset. The statics are also sunk. The stg coming to terrasync DOES NOT have -9999 for elevation, instead some proprer value that has been calculated so far.

These are the things I tested so far.

I am missing something of what you've said before?

Thanks once again,
IHCOL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Terrasync Help (surprinsingly!) :)

Postby ludomotico » Mon Nov 24, 2014 7:28 pm

No, you have everything right. This is how it works :)

You cannot use -9999 in a .stg. It is the webpage who calculates the automatic elevation, not flighgear! In your custom scenery, you use the elevation that better matches your custom scenery. When submitting to the webpage, your custom elevation is ignored because it is, well, custom. If you use a .stg downloaded from terrasync in your custom scenery, it won't work because of these differences in elevation. I have a script that runs fgelev with my custom scenery and repositions objects on ground, but I'm afraid it is not generalised and it will only work on my system.

Nowadays it seems the -9999 elevation is not needed any more in the webpage, it works as if everything was submitted at -9999. Please, ignore this -9999 thing, it is old info.
User avatar
ludomotico
 
Posts: 1018
Joined: Tue Apr 24, 2012 1:01 pm
Version: git
OS: Debian GNU/Linux

Re: Terrasync Help (surprinsingly!) :)

Postby IAHM-COL » Tue Nov 25, 2014 2:16 pm

Ok.
Thanks a lot Ludomo, Wilbragg, f-OJAC for the attention and help.

I learn a good deal about this, and will continue the development knowing that terrasync objects cant be piped into custom scenery, but instead the later will need "custom" locations for all models as well

Seems a lit like double effort, but doable

Once again, Thanks for helping me here,
Best
IHCOL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Terrasync Help (surprinsingly!) :)

Postby ludomotico » Tue Nov 25, 2014 4:37 pm

I have an old version of my script that might help you. It gets a .stg from terrasync (or an old version of your custom scenery) and outputs the same .stg with objects on ground for your custom scenery.

Save as recalculate_elevation.py

Code: Select all
 #!/usr/bin/python

# recalculates all elevations in a .stg file
# Reads the .stg file from standard input, writes to standard output
# Usage: cat 11223344.stg | python recalculate_elevation.py $FG_SCENERY > 11223344.stg.new

import sys
import subprocess
import math

# if an argument exists, use as the scenerydir. If not, use my directories
scenerydir='/home/juanvi/FlightGear/IBE/IBE:/home/juanvi/.fgfs/TerraSync'
if len(sys.argv) == 2:
    scenerydir = sys.argv[1]

# Open communication to fgelev
elev = subprocess.Popen(['fgelev', '--fg-scenery', scenerydir], stdin=subprocess.PIPE, stdout=subprocess.PIPE)

# Information about an object
class Position():
    lat = ''
    lng = ''
    type = ''
    ele = ''
    offset = 0.0
    repos = True
    roll = '0.0'
    pitch = '0.0'

# if this is set, the next object has an abolute elevation that shouldn't be calculated
noreposNext = False
# the offset of the next object
offsetNext = 0.0
# the identifier of the next object
id = 1
for l in sys.stdin.readlines():
    try:
        # if the line is an OBJECT or a commented OBJECT...
        if l.startswith('OBJECT') | l.startswith('#OBJECT'):
            # read the line
            items = l.strip().split()
            o = Position()
            # two types of lines: those that include pitch and rolling and those that don't
            if len(items) == 6:
                o.type, o.model, o.lng, o.lat, o.ele, o.hdg = items
            else:
                o.type, o.model, o.lng, o.lat, o.ele, o.hdg, o.roll, o.pitch = items
            # calculate elevation, if noreposNext is not set
            if noreposNext:
                noreposNext = False
                o.ele = float(o.ele)
            else:
                elev.stdin.write('%s %s %s\n' % (str(id), o.lng, o.lat))
                outs = elev.stdout.readline()
                o.ele = float(outs.strip().split()[1])
                id += 1
            # use offset
            o.offset = offsetNext
            offsetNext = 0.0
            # print the line
            print('{} {} {} {} {} {} {} {}'.format(o.type, o.model, o.lng, o.lat, o.ele + o.offset, o.hdg, o.roll, o.pitch))
        elif l.startswith('# norepos'):
            # if this line is found, the next object won't be recalculated
            noreposNext = True
            print(l.strip())
        elif l.startswith('# offset'):
            # if this line is found, the next object will have this offset
            offsetNext = float(l.strip().split()[2])
            print(l.strip())
        else:
            # any other line: just copy
            print(l.strip())
    except:
        print('Error processing line: {}'.format(l))


Usage: cat 11223344.stg | python recalculate_elevation.py $FG_SCENERY > 11223344.stg.new

I'm afraid this is a Linux command, but I guess there is something similar in Windows.
User avatar
ludomotico
 
Posts: 1018
Joined: Tue Apr 24, 2012 1:01 pm
Version: git
OS: Debian GNU/Linux

Re: Terrasync Help (surprinsingly!) :)

Postby IAHM-COL » Tue Nov 25, 2014 5:18 pm

Im on opensuse
so this is of great help :D
Just my "next" step in solving my problem, but you are always the man with the correct card in the hand!

THANKS A LOT!
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Terrasync Help (surprinsingly!) :)

Postby wlbragg » Tue Nov 25, 2014 11:12 pm

Yes, thank you ludomotico. That is a very handy script to have.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480


Return to Scenery

Who is online

Users browsing this forum: No registered users and 1 guest