Background Image Rendering Interface

#1
This outlines some thought I had concerning the interfaces for generating background images for the main workarea (the map).

With background image I basically refers to anything that can't be edited in any way but helps the user to position objects etc. Think for example sattallite photos (when not doing photoreal obviously as they would then be part of the scenery), GIS data, or data read from the FS scenery files directly.

I imagine splitting the task in two parts, where one part is responsible for keeping both the image rendering and the view simple.

Notice this is "notepad" code, it won't run - it is just here to get the basic overview.

First the interface of the service responsible for
public interface IBackgroundImageService : IDisposable
{
void SetView(AreaG area, Size size, BackgroundImageGeneratedDelegate callback);
}

public interface IBackgroundImageGeneratedResult
{
Image BackgroundImage { get; }
AreaG area { get; }
}

AreaG is a struct containing a min/max latitude and longitude. I already have some code we could modify (read: clean up) and use for this. Notice I am missing one method on the first interface used to set the various background image sources used - it can be added later and is not important for the architecture.

Seen from the view, all that is needed is setting the area to show and the size of the view in pixels. It will then receive a number of callbacks with the image to use as background for the specified area. If the view is moved, the view can use the parts it still has visible (might be strectched a bit until the correct image is ready).

Notice a callback is used indstead of the more logical event to avoid sending the bitmap to more than one destination, which would make it unclear who should dispose it.

A background thread will then be used to render the image. Any prefetching, caching (if possible) etc will be done at this level so the view can be kept simple.

The properties of the varipous renderes (see below) will be monitored and if changed a new render operation will be started.

The actual rendering will be done by calling one or more sevices implementing the following interface and then combining the result:

public interface IBackgroundImageRenderService : IDisposable
{
IProperties CreateDefaultProperties();
Image RenderImage(AreaG area, Size size, IProperties Properties);
}

CreateDefaultProperties is not that interesting (and may not be needed) - it is just there to allow us to get default properties we can then let the user modify.

RenderImage befores the actual drawing into a bitmap using the specified properties. It does not have to be multithreaded as this will be delt with from the caller, but it must support being canceled with a ThreadInterrupt exception.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#2
Hi Lars,

One very important thing about backgrond images (and basically all GIS data we use) is the projection. Most developers are not fully aware of that yet, but if we mix data in different projections, the end result is useless. So I think we need some functionality to enter the projection as well and of course some functionality to transform everything to WGS84 (as that is the default projection used in FS).
 
#3
Correct. Personally I display everything in WGS84 (I cheat a bit and use the center of the screen to scale latiture/longitude - as my application always centers on the model you are moving it will be correct.

But unless you plan to support changing projection displayed, the projection will not have any affect on the interfaces - it will be the responsibility of the call rendering the bitmap. If the renderer needs to know the projection of the source then it will be specified in the properties.
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#4
Sounds good to me. I agree that all rendering should be done in WGS84, but we just need to make sure that we can reproject input data if it is using a different projection.
 

rhumbaflappy

Moderator
Staff member
Resource contributor
#5
Hi Arno.

Just a thought... it might be better to leave reprojection out of the program entirely. Much simpler to just have lat-long. A separate reprojection utility would be a significant project in itself.

Dick
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#6
That I like :) given that the area of ground that we generally use when designing scenery is quite small is projection going to matter. Must admit it had not occurred to me as something to worry about.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#7
Just a thought... it might be better to leave reprojection out of the program entirely. Much simpler to just have lat-long. A separate reprojection utility would be a significant project in itself.
I do not really agree here, once you start working with background images the user needs to be aware of the project system he is using. Even if they know the lat/lon values, it will give an error if these lat/lons are not in WGS84.

There are also a few libraries that can help you with such reprojections, I use them at work quite often.

That I like :) given that the area of ground that we generally use when designing scenery is quite small is projection going to matter. Must admit it had not occurred to me as something to worry about.
I surely think it will. For example for the Dutch scneries I am working on we have data in the Dutch RD projection. Basically these are just meters, but when I don't reproject them (which add a rotation as well), the positions are a dozen meters off, even for a small VFR airfield.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#8
I surely think it will. For example for the Dutch sceneries I am working on we have data in the Dutch RD projection. Basically these are just meters, but when I don't reproject them (which add a rotation as well), the positions are a dozen meters off, even for a small VFR airfield.
Ah OK that settles it then.
 

rhumbaflappy

Moderator
Staff member
Resource contributor
#9
Hi Arno.

I'm not implying projection doesn't matter, but that ensuring the proper projection for all data should be done outside the program... first.

This actually enforces the concept that FS deals with Geographic Projection with WGS84 Datum. If reprojection is within the program, not only will it complicate the coding, but it will unleash countless complaints from users that do not understand their images are not alligned perfectly.

The concept of reprojection simply escapes most designers. Most people are so accustomed to dimensional projections ( feet or meters ), that they cannot conceive a world based on angular measurement ( degrees ). The forums have been full of this, and still are, after these many years.

I just think it's better to require the data in the correct format before it is used in the program... and perhaps provide an auxilliary program to accomplish this. Endusers of the program must, in any case, be responsible for the data and images they use.

I only suggest this will simplify the coding, and may prevent useless complaints about the program down the road.

Dick
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#10
Hi Dick

That makes sense to me, if I understand correctly. It is better to sort out projection issues on background images and data before it gets into the scenery program than in it.

Are there programs out there that do this ? - I guess there must be.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#11
Hi Dick,

Agreed on that I guess. As long as we can make the users aware of this, it is fine with me :). I think you are right that adding functionality to help them is not the only way to make them aware.

Jon, I use GDAL for that at work, it has a utility called gdalwarp that can be used to do the reprojection. I used this for example when I wanted to create a GeoTIFF for the FsX resample tool. This for example converts an image from RD to WGS84:

Code:
gdalwarp -s_srs "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +towgs84=565.04,49.91,465.84,-0.409394387,0.35970519561,-1.868491,4.0772  +no_defs"  -t_srs "+proj=latlong +datum=WGS84" ehamtest.tif ehamtest_wgs.tif
As you can see it requires some knowledge of the parameters to use, etc. I guess we should try to get an article about this on the Wiki sometime.
 
#15
While I agree it does not have high priority to get reprojection into the program immideately I do not agree it should not be there. I am aware that many people do not understand it, but that will not be better by leaving it out - it will be a lot worse. If we had the option in the program there is a chance users will try to change it and notice the huge effect.

And as already mentioned - ignoring projection is not a possiblity at all. The difference is huge in some areas.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#16
I think we can then agree that put it on low priority, but add it in the end if possible. The GDAL library I mentioned also has C# bindings, so maybe we can use it. But that is something to see later, as other things are more important at first.
 
Top