• 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.

seasons.bgl?? which forum?

M

Mace

Messages
997
Country
us-missouri
My first post here! Some of you might recognize my handle from AVSIM as I hang out there some. I am a lifetime FS tweaker so all things scenery design always interest me.

Anyway, my question is, which subforum here, is appropriate to ask a question about the 'seasons.bgl' file? This subforum?

I would like to be able to mod seasons.bgl, but the SDK only tells how to view the monthly overlays using TMFViewer. That's nice, but not exactly what I want to do. :) I do not think BGLAnalyze in all its forms is the correct tool to use for this. It seems to be aimed toward airport modding.

Essentially, if seasons.bgl is arranged in tiles, (and it appears to be) then all I need to do is alter some seasonal numeric values. I guess i could use a hex editor. ??
 
I think this would fit best in the mesh subforum, as the season.bgl file is part of the mesh system. So moved your post over there.
 
I have not made any FSX season changes, except a quick test for proof of concept. I have done FS9 seasons, and it appears that FSX is the same. except that resample now samples at LOD5, where in FS9 it was only LOD2. Thus, it is possible to have much better resolution in FSX.

For FS9 I used only raw files aligned to LOD boundaries, but I think in FSX it is no longer required to have LOD alignment.
The key is that the valid data in the raw file is integers
0=winter
1=hard winter (snow)
2=spring
3=summer
4=fall

As a test I took some of my FS9 source data and saved it as a grayscale geotiff (my plan is to use geotiff as much as possible in FSX, though raw should still work fine) with gray values 0-4 used. In FS9 you had to resample all 12 months as source files into intermediate tmf files, and then merge the 12 tmfs into a bgl. It appears in FSX you can change one or more months as desired.

Here is the test inf I used:

[Source]
Type = GeoTIFF
Layer = Season
SourceDir = "SourceData"
SourceFile = "testseasongsgeo.Tif"
Month = 1,2,3,4,5,6,7,8,9,10,11,12

[Destination]
DestDir = "Output"
DestBaseFileName = "testseason"
DestFileType = BGL
LOD = Auto

In this test of course the season coverage would never change since the same source is reapeated for all 12 months.

scott s.
.
 
I've been trying 'proof of concept' but cannot get it working.

I can't get .bmp's working with this. I have Photoshop. What program does a person use to create/save a GeoTIFF format file?

I thought you had to specify Lat/Long boundaries, such as the NW corner of your data area. But I see you did not have to do that in your .inf. Very interesting...

What does your testseasongsgeo.Tif file look like? The bmp I made, had separate layers of opaque season colors. I think I am overcomplicating things.
 
Tiff I think is a fairly mainstream file format for images. For whatever reason, the format has become widely accepted in the geographic community. Geographeres have deveoped a set of "tags" -- metadata embedded in the tiff file header, that simplify displaying tiff images as raster layers in GIS. The new resample tool is able to read these tags and extract the NW corner position, scale, and number of data rows and columns that otherwise would be placed in the inf directive file. So there is nothing you can do with the geotiff that you can't do with other formats such as bmp or tga.

If using a bmp, you would need to determine the NW corner and x/y dimension. The bmp would have to be 8 bit (grayscale). The only legal grays would have values of 0-4. I have not worked with the bmp format for resample, though, so I can't say for sure. If you have multiple layers in your source data, you would have to flatten the image and convert the colors to gray then convert to 8 bit.

scott s.
.
 
If I knew that, I would pay someone.

My main effort so far, is to take data that is provided by the US NOAA National Snow and Ice Data Center. This is gridded ascii data for the northern hemisphere only. It is published daily with resolution of 4km or 25km. Thanks to Holger, I also have gotten some climate data in "Koppen" category system. I also foudnd some "fall foliage peak week" data for the US. I might try to correlate that with some mean daily temp data. You can get US data from National Climate Data Center in shapefle format for 3 bucks a pop. Might be something like that from WMO for world-wide data.

The bottom line is none of this is in a ready-to-use format. I've also used screenshot of tmfviewer to get the default season data (worked pretty good in FS9 since it wasn't that high resolution. FSX might be more of a challenge).

I use the payware Global Mapper GIS software to load most any format, and convert as required to geo projection / WGS84 datum. GM allows a save as Geotiff. I also save the position data (world file) because most image editors destroy the geotiff tags.

In the image editor, I load various tiff files as layers, with the end goal of getting just the 5 color regions (I work in 24 bit just so I can see the seasons as color easily. I use the same colors as tmfviewer.

When I get everything set the way I want, I convert the colors to gray, with values 00 00 00, 01 01 01, 02 02 02, 03 03 03, 04 04 04. Then convert into 8 bit (grayscale) so the values are jsut converted to 00, 01, 02, 03, 04. Note that at least my eyes can't visually determine the difference between these gray values; that's why I try to do all the editing in the 24 bit color mode first.

Once I have the data in a grayscale, I import back into GM a final time to reapply the geotiff data. An alternative is to just use the file as a tiff or bmp, and use the data from the positino (world) file to update the inf file.
Or what I did in FS9 was to save the file as a binary "raw" format and strip off the header bytes (all my software has available for this is pgm format, which is raw a header).

Here is an example of my source data after I have converted it to color and projected (white = snow, yellow = ice), and after I convert the ice and snow to "hard winter" and merge in the default layer from tmfviewer.

scott s.
.
 
Last edited:
Hi Scott,

that's a great description. And thanks for uploading the nam_seasons.zip and its well-made documentation to Avsim; I'll have a closer look at that soon.

I've since used the MODIS monthly North America files (1-km res) to extract snow cover information but have to say that it's quite the undertaking to download those massive data sets for twelve months. Still, the processing in GM and Photoshop is pretty straightforward and the results seem reasonable (I've only worked on the West Coast thus far).

My processing in Photoshop is pretty similar to yours. What I do differently is that I work in Indexed Color format. By setting up two different color tables I can easily switch back and forth between the color representation and the equivalent 0-4 grayscale values without having to do any manual conversions.

My next step will be to feed Slartibartfast with digital elevation data and use the option for elevation-dependent land class generation to develop raster files I can translate into elevation dependent snow cover. I'm not sure yet whether this can be combined with the MODIS output in a reasonable manner but it might offer a more detailed alternative to depict seasonal advancements or retractions of snow "lines" in mountainous areas.

Cheers, Holger
 
Holger -- using Slarti for this sounds like a good approach. I've kind of avoided playing with MODIS data so far. I guess I should dig into it.

On that seasons file, I actually started on that last Feb when someone was complaining about not enough snow cover. At first it took me a while to figure out how to get a process. Once I got things set for a single month I started working on other months. But by the time I started, all the source data for 2005 had been archived into a single file, and it was really large so I didn't feel up to downloading it all. Instead I just progressively updated the monthly data in more or less real time. I think now that I got the process down I could go back and do the whole globe, or at least the whole northern hemisphere, but I am more interested in FSX as a target for new efforts.

scott s.
.
 
got it working

I must report, after much thought and research, I got a seasons.bgl working tonight.

My method was less-than-ideal but it has been the only way I have been able to successfully do this.

I used EZ-Landclass by Russel Dirks. :eek:

How, you ask? (or maybe, "why?" heh.) What I did was start a typical EZ-Landclass project. Defined it as WaterClass to start with. Then, in the cells, I put the value of 0,1,2,3,or 4 depending on the season I wanted for that particular cell. Then had EZ-Landclass make the bgl.

What I got, was, of course, a Waterclass bgl. So I deleted the bgl, but I am left with a nice handy .inf file, and a nice handy 8-bit grayscale .raw file. How nice of EZ-Landclass to prepare these for me. xCell and yCell already filled in and figured. So...I proceeded to edit the .inf file, changing Layer=WaterClass to Layer=Season, and adding Month=10 (to fix October).

Resample the resultant .inf/.raw and bingo.

No more autumn leaf colors in Nicaragua.

Now, if I can *ever* figure out how to use Photoshop to paint using colors, then convert these color vals to 0,1,2,3,4 then I will really have something going. Because as of right now, I'm stuck to LOD13(?) size areas at a single time.
 
Mace said:
Now, if I can *ever* figure out how to use Photoshop to paint using colors, then convert these color vals to 0,1,2,3,4 then I will really have something going. Because as of right now, I'm stuck to LOD13(?) size areas at a single time.
Click to expand...

Hi Mace.

You found a very tidy solution. :)

Painting landclass, waterclass, seasons, regions:

They are all 8-bit, and you can use the index ( or palette ) to determine values. Greyscale will do it, but then you are painting very similar colors. So make a palette, assign it to your painting, and color away using the index number of the color ( should be 0-255 ).

Seasons are 0-4
Regions are 0-23 ( according to the SDK )
Waterclass are 1-60 ( according to the SDK )
Landclass are varied numbers found in the SDK.

Save the resulting painting as RAW 8-bit. I've taken GeoTiff files, loaded them into PSP, converted to 8 bit, painted away, and exported as 8-bit tiff. I then compiled the tiff with resample ( Using the bounds and spans as we normally do with resample. Works great.

You could paint 8-bit over a Landsat image, for example, save the layer as an image, and compile that.

We even can specify "weighting" and give resampling preference to specific values... such as city textures in landclass, or HardWinter in month's season... this allows you to use source data with much finer resolution than 1-km/pixel, and specify your preference for the final resample. This would be useful for using a landsat image or an Olson landcover datasource.

In your INF, under source, you can assign a NULL number:

NullValue = 254

254 was the older ( traditional ) number for a null value, so no need to change tradition here. That allows you to paint 254 as a background that doesn't show in the sim. This allows you to blend your resampled image into the default, or leave some areas untouched.


Dick
 
rhumbaflappy said:
They are all 8-bit, and you can use the index ( or palette ) to determine values. Greyscale will do it, but then you are painting very similar colors. So make a palette, assign it to your painting, and color away using the index number of the color ( should be 0-255 ).
Click to expand...

Ah, but that is the trouble. I do not know how to assign value 1 to the white color for hard winter, the 2 value to assign to yellow for spring, the 3 value to green for summer, and 4 to orange/red for autumn.

When I attempt to set the (hex) value to 1, for example, I get a deep blue color. The hex value, such as 0FFFFFF, is the only thing I see that remotely looks like assigning a value to a color.

Perhaps it is a more straightforward process with PSP?
 
Hi Mace.

I think you need to set your image -> mode to "indexed color"... and make sure it's 8 bit.

Dick
 
I do indeed have an 8-bit indexed color image. I screencap'ed image_globe_00.bgl and then converted it to 8-bit/indexed color as a background guide image.

The problem is, I can paint a nice opaque green as a separate layer over my background image all day, but I do not know how to tell resample.exe that my green color is to represent the value '3' = summer. That is the magical piece of information that I am somehow missing here.
 
Hi Rhett,

once you're ready to process your season file the first step to do is to get rid of the underlying layer (don't forget to save the project first as a Photoshop psd file in case you need to do edits later on) and retain your season image in RGB color format.

Now convert the RGB to Indexed Color (choose Palette = Exact). Then select "Image > Mode > Color Table" and you should see the colors you painted in the color palette, usually the first few cells; all unused colors are in shades of gray.

Next step is to set all unused colors to a value of 254. Highlight those (gray) cells by clicking on the first and dragging the mouse to the last, then type "254" in the "R", "G", and "B" cells and click OK twice.

Now you can click on each of your colored cells in turn and give them their appropriate values, e.g. "3".

Once you've done that you convert the indexed color to grayscale and save the file as tif or raw. Double-check for "stray" values by zooming to 100% and "Image > Histogram". The histogram should only show pixel counts for your season levels and level 254.

This file is ready for compiling via resample.exe. Use the row/column data and georeferencing information to create the inf file (don't forget the "NullValue = 254" line) and compile.

The process sounds involved but once you get the hang of the Indexed color options it's quick and easy.

Good luck.

Cheers, Holger
 
Application?

Hi all - sorry I'm late!

I was considering writing an application that would take the ASCII snow/ice cover data from NOAA and write a real-time seasons BGL. The issue is getting a good source of base data (snow and ice free) over which to superimpose the snow/ice data. I envision the program taking the current date/time or a specified one, downloading snow/ice data or using a local file, merging the base snow-free data for that date with the snow/ice data and creating a bmp/tif which would be automatically passed to resample. All data would be gridded ASCII, and will be of high enough geographic resolution to support FSX.

Some pros:
* Higher temporal resolution (essentially real-time snow, and though impractical, base data could be daily).
* Higher resolution source data easily ported to either FS9 or FSX.
* Re-regionalization could be accomplished simultaneously.

Some questions:
* Is reliable data for snow/ice globally available, or is the high-quality data restricted to north america?
* Is there a good source of similar ASCII data for average climatological seasons globally?
* Is anyone interested in working on this?

Thanks!
sg
 
I think this could be done.

If you have a scenery folder dedicated to the seasons, you would then need to have a new world 'NoSnowSeasons.bgl' that would not include any hard winter for each month.

Then you could daily overwrite a new snowcover.bgl with only hardwinter ( with a transparent null value of 254? ) to place on top of it. This is your daily file.

There might be a problem with scenery priority if 2 season BGLs are located in the same folder. But a naming convention might solve this.

An exterior program might download and resample the data using the current day's monthly info, and copy the bgl to the right folder before FSX is started.

Dick
 
Exactly what I'm thinking, Dick. If there's a problem with two seasons.bgls coexisting, they can be merged, otherwise, snow-only with transparent. The issue still becomes making a good set of snowless seasons bgls which are at least as good as the default, hopefully better. Thoughts on obtaining/creating the latter?
 
Hi Scott,

the MODIS satellite data cover most of the globe and are collected at 500m or1km res on a daily basis. NASA processes the raw data into a number of products including snow cover and sea ice.

The issue with the daily images is that many areas will be cloud covered and thus end up being not classified as snow/no snow. Thus, NASA also generates composite files that combine data from 8 or 16 days or entire months. In other words, you end up with an average snow cover snapshot of that period that is essentially cloud free.

I used the MOD10C2 / MYD10C2 snow products for a custom seasons file (FSX) of parts of North America. The raw data still need a bit of cleaning up though most of it could be done in an automated process. The product website is http://modis-snow-ice.gsfc.nasa.gov/MOD10C2.html and I used the EOS data pool to order the files: http://n0dps01u.ecs.nasa.gov:22000/OPS/home

Cheers, Holger
 
Hi Holger!

Thanks for that link - I was thinking that I would overcome the cloud cover issue with a user-definable parameter that would set the number of days of data to download and merge. The monthly composites would be a good alternative, but the user could also simply choose to download one days worth of data, and live with the inaccuracy, or download 2-10 days worth of data, the program will superimpose the data, which should be more accurate unless snow cover is changing rapidly.

The issue I'm grappling with currently is whether resample will handle a single bmp/tiff that will span a large lat/lon range (basically global), or if I should split the images into pieces and use multi-source. Any experience there?

THANKS!
sg
 
You must log in or register to reply here.
Back
Top