• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Photoscenery Orientation

Messages
1,964
Country
unitedkingdom
Using images from USGS, when one writes the .inf, you can only define the NW corner. Hence, the NW and SW, NE AND SE etc. corners are all at the same latitude/longitude. And so the adjacent images in the matrix need to have the same Latitude.

So after a few km, the images start to get pretty out of sync with the terrain mesh.

I have a 4x4 grid of 5x7km images, and they need to have an angle so that the NW to the NE descends slightly.

How does one do this?
 
Last edited:
Say what? If all four corners had the same Lat/Lon there wouldn't be anything showing, would it?

Imagery and mesh are based upon a rectangular (or square) matrix. The INF file tells the compiler where the starting point of that matrix is in Lat/Lon. The xDim and yDim tell the compiler how big each part of the matrix is. The compiler reads from left to right, top to bottom.

If you are having a problem getting things to line up, look at what you are putting in. GIGO would be an appropriate term, maybe?
 
Hi,

What coordinate system does your input imagery use? If it is not geodetic WGS84 you would have to reproject it first. Resample requires input in WGS84.
 
The geotifffs are useless... They all overlap and aren't properly aligned. I had to cut and paste them together into a mosaic, trim them up a bit and write .inf files for them. I know the NW corner and the XDIM/YDIM. But don't know any of the other corner's coordinates.

I've pretty much given up as I don't know the coordinates for the other 3 corners to embed, and using Xdim/Ydim means that the image is out of sync with the terrain after a few km.
 
Did you throw away the GeoTiffs? They really are the best starting point, that will get you to the finish line.

But if you just want to quit, then this thread can be marked as Solved?
 
Hi,

I would also not say geotiffs are useless, they are very valuable and in general make it very easy to create your photo scenery. Once you start to manually cut and paste pieces it will be almost impossible to get it at the correct geographical location.

Did you check which projection is used in the geotiff files?
 
Yeah, it's NAD83. I haven't tried it sing the Geotiffs, due to the overlapping and stuff.... Will it work still?

I'll try to convert them to WGS84 and resample a couple.
 
Last edited:
So if the GEOtiff uses UTM NAD83 10N projection,

The GDALWARP source should be what?


gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -s_srs "+proj=utm +zone=10 +datum=NAD83" -t_srs "+proj=latlong +datum=WGS84" -r cubic 632.tif 632_wgs84.tif


I really don't have much of a clue about all of this! :0)
 
Last edited:
The Gdalwarp has worked fine. however, there are large, black outlines around the image on the _wgs84 file now.

I don't understand why this is the case when the .tifs align up properly prior to being set to wgs_84.
 

Attachments

  • 1.JPG
    1.JPG
    183.3 KB · Views: 513
I have converted the black borders to transparent using

gdalwarp -srcnodata 0 -dstalpha in.tif out.

however, they persist within the .bgl still.

I have resampled them separately and individually.

* I recall that you need to have the images listed in a text file and need to reference this, however, I can't find where this was mentioned.
 
Last edited:
Hi,

In your inf file you can specify which color/value should be ignored by resample. That why you can get rid of them.
 
That's the ticket! Cheers for your help. It's all looking splendid now.

It's a bit laborious though as I am halving the resolution, which wont work with tags it seems. So I'm having to write down the coordinates and gdal_translating them onto the new, smaller images.
 
It's a bit laborious though as I am halving the resolution, ...

You can control the resolution output via the INF file. Under the [Destination] with the line; LOD = Auto. You can change the Auto to reflect a minimum and/or maximum level for LOD.

If file size is a concern, utilize some compression within the BGL file with a line like this under the [Destination]; CompressionQuality = 85. With no line in the INF file for compression, there is none. With some, be that 95 or 90 or 85, the file sizes will go down by a lot.
 
Last edited:
Ah, cheers, that's good to know.

My main issue with size is that I only have 2 gig of ram, and GIMP. I can hardly open the 17000x13000 files, let alone edit them for seasonal variations and night / blend masks. So I have to get them down in size to work with.

0.8m/pix resolution is good enough.... I'm planning on doing a pretty large area.
 
Seeing as you are "over there", but working over here, where is the area of your interest? Sometimes the same source is available without having to go through the USGS and in smaller, more manageable file sizes.
 
Ah it's too late for that! Thanks anyway I've downloaded most of the files and resized them. Plus they're all from a good time of year. Nothing worse than imagery taken in the middle of winter.

It's just a small strip in Washington.
 
I have put null_value= 0,0,0 on the .inf file to stop the black borders from being written into the photoscenery.

But, as the black borders are diagonal on the .tif after I have converted it to wgs_84, there is a dashed-line of dark, non-black pixels I can't get rid of that stay in the image which trace out this outline. Has anyone figured out how to remedy this?
 
I've figured out how to fix this...

I've made a layer above, imported the black borders onto it (via using the image as mask, setting threshold to 1 so only 0,0,0 remains) and then used edge detect to bring in the borders 1 pixel, which cleans it up to perfectly 0,0,0 around the outside.

Now I just have to do thins on the 92 other images that I have compiled for this project also.

:banghead:
 
Back
Top