Photoscenery?

[benih]

perl create_bbox.pl --latLL 47.1967 --lonLL 11.1984 --latUR 47.5321 --lonUR 11.7682 -- --cols 2 --scenery_folder C:\Users\Win7\Documents\FlightGear\Orthophotos

So, does that line of code work on your system benih?

Looks good, files do appear:

Code: Select all

beni@segin:~/Dokumente/FGFS/work/fgbuild/flightgear-photoscenery$ perl create_bbox.pl --latLL 47.1967 --lonLL 11.1984 --latUR 47.5321 --lonUR 11.7682 -- --cols 2 --scenery_folder /tmp/test/

WARNING: Only do this for providers whose TOS allow this!
WARNING: This may really strain remote ressources and cost the provider
         real $$$, so use with care and if in doubt, ask before using!

cmd=python3 creator.py --lat "47.1967" --lon "11.1984" --info_only
Tile 3138120 needs download
cmd=python3 creator.py --index 3138120 --cols 2 --scenery_folder /tmp/test/
INFO:root:Downloading tile=/tmp/tmpkla2c93i from url=http://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/export?bbox=11.0,47.125,11.125,47.1875&bboxSR=4326&size=4096,2048&imageSR=4326&format=png24&f=image
INFO:root:Downloading tile=/tmp/tmp9y5a6b3g from url=http://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/export?bbox=11.125,47.125,11.25,47.1875&bboxSR=4326&size=4096,2048&imageSR=4326&format=png24&f=image
INFO:root:Downloading tile=/tmp/tmp0aj_jao6 from url=http://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/export?bbox=11.0,47.1875,11.125,47.25&bboxSR=4326&size=4096,2048&imageSR=4326&format=png24&f=image
INFO:root:Downloading tile=/tmp/tmpxmylbm7d from url=http://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/export?bbox=11.125,47.1875,11.25,47.25&bboxSR=4326&size=4096,2048&imageSR=4326&format=png24&f=image

OTOH i am an linux.

Code: Select all

beni@segin:~/Dokumente/FGFS/work/fgbuild/flightgear-photoscenery$ python3 --version
Python 3.9.1+
beni@segin:~/Dokumente/FGFS/work/fgbuild/flightgear-photoscenery$ perl --version

This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-linux-gnu-thread-multi
(with 45 registered patches, see perl -V for more detail)


Which versions do you have?

[Volador]

I have Perl v5.32.1 built for MSWin32-x64-multithread and Python 3.8.7

[Volador]

SOLVED: I managed to get it working, I had the incorrect version of create_bbox.pl for some reason - I also figured out I had to edit the create_bbox.pl script to change three instances of "python3 ... " to "python ... "

Nathaniel, what a clever piece of code, I'm constantly impressed with the work that you and the community does on the project. Thank you

[Warty]

Try this

https://wms.geo.admin.ch/?SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&REQUEST=GetMap&LAYERS=ch.swisstopo.swissimage&STYLES=&SRS=EPSG:21781&WIDTH=1024&HEIGHT=1024&BBOX=660233.9755383213,253323.21199625108,660443.243759355,253531.8497040167

Code: Select all

https://wms.geo.admin.ch/?SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&REQUEST=GetMap&LAYERS=ch.swisstopo.swissimage&STYLES=&SRS=EPSG:21781&WIDTH=1024&HEIGHT=1024&BBOX=660233.9755383213,253323.21199625108,660443.243759355,253531.8497040167

[DeltaSVEN]

Hey all,

I implemented photoscenery on my homebase Frankfurt am Main (EDDF). The airport tile crosses two scenery tile borders (blue lines)
e000n50/e008n50/3089154 - e000n40/e008n49/3089146
e000n50/e008n50/3089154 - e000n50/e008n50/3089153



With photoscenery, the airport tile is texturized incorrectly and the threshold of RWY36 is missing:



However, if I remove e000n50/e008n50/3089153.dds (top left tile) , the airport tile looks perfect (apart from threshold 07L, where 3089153.dds borders):




The same problem occurs in Berlin Brandenburg (EDDB), which is located on 4 scenery tiles:



Again, scenery looks right, however the airport tile is a complete mess:



Is there a way to correct this? Thanks in advance,


Sven

[benih]

This is a known issue.
To resolve with a workaround: do use DXT1 compression, or the raw png for the affected tile if dxt1 does not work.

[DeltaSVEN]

Thanks for the quick reply! I'll try that then...


Cheers,

Sven

[oracle]

Hi.

I'm trying to understand this discussion but I'm missing a lot. This is a multi-year project, so I'm not sure what is still relevant and what's outdated.

How is the current scenery (v 2.01) built? What is the source of the terrain images? For example, I'm looking at a big city which in FG looks nothing like what it appears on Google Earth but the mountains around are relatively similar to reality.

Then there are roads and railways etc. which appear almost exactly where they are, just in unrealistic colours (like they are drawn from a model on top of the terrain).

Is none of this photographic data?

On the topic of free satellite scenery: I understand there are sources of free images but the images are not free to redistribute. So they cannot be used to create tiles like the ones currently available (e000n10, e000n20, etc)?

What about asking for permission to use the free images of a big provider like the USGS? I mean permission to take data and store it separately from the USGS servers, so it can be optimized for FG users?

[Hooray]

This is the posting where the most recent progress is starting to be announced/discussed - you will see that your idea/suggestion is already implemented by using a wrapper tool (Python script) to fetch/download necessary imagery on demand, and that there also plans being discussed to further automate that portion (if in doubt, click the github link): Photoscenery?

I recently started working on patches that add photoscenery support to modern FlightGear. I have instructions here: https://github.com/nathanielwarner/flightgear-photoscenery

Let me know if it works, and if you have suggestions! Right now, you have to provide satellite orthophotos manually, but I'm working on automating this.

[oracle]

Good, so I'm looking at the right place.
Are the developers here?
What needs to be done to automate this download and pre-processing of sat images? Any idea how much effort that would be?

I downloaded Google Earth Pro and tried the built-in flight simulator.
I ran it on a slow laptop with Internet connection via cell phone.
Here's the amazing thing: the sim offers incredible visibility (there's basically no fogging or any clouds). You can take off from Berlin, climb above 40,000 feet and see the mountains behind Munich. Berlin - Munich is 500 km.
When I say "see the mountains" I mean I put a pin in the Alps and I could see the pin in the far distance. I wouldn't know what it was without the pin because it was far on the horizon.
This demonstrates that Google Earth Pro is able to handle images of hundreds of miles without clogging the graphics. How do they do this?

I think as I fly the app is downloading more and more detailed images up close and maybe very coarse images in the distance to create this beautiful illusion of huge visibility.
If I disconnect from the Internet, I continue to enjoy hi-res images around the starting point but if I move away everything becomes more and more blurry.
If I connect again, the surrounding images become clear, but if I disconnect and return to the starting point, detail is lost - so the app has removed hi-res images from the local cache.
Is it because these images take so much disk space that they are impractical to keep? I looked at my network traffic - the hit on my mobile data plan was quite big (hundreds on MB for 20-30 min). I would prefer to keep the cache but there was no such option.

So it is possible to do something similar or that's technology and data only available to Google? Not saying hundreds of miles visibility is realistic but the Google app is a proof it can work on a humble machine.

[wkitty42]

assuming the earth is a smooth ball, at 40000 feet, the horizon is 244miles (392.7km) distant...

adding "bumps" for mountains to that smooth ball, i can see how someone might see the top of one of those mountains that is located physically over the horizon...

in FG, the LOD settings determine how far you can see and at what quality items within those ranges will appear... FG defines three ranges of LOD... bare, rough, and detailed... bare is the furthest from you and shows only the bare terrain with no scenery objects... rough is the next closest and you can make out some scenery objects... detailed is the closest to you where you can see the details of the scenery objects...

google and others (eg: msfs) may define more ranges for the LOD stuff... they also do a lot of ""rough graphics"" (pixelation?) stuff to help hide things in the distance...

[oracle]

Cool.
So how does the current photoscenery logic work? Does it also use tiles with different level of detail (depending on distance)? Are those pre-built or generated runtime?

I looked closer into Google Earth and USGS and found one more riddle. When you start zooming in from very high, you can see how the browser is loading different images in square tiles.
These have different colours. It seems to me like it goes from yellowish broad tiles into greenish smaller detailed tiles. How come this effect doesn't appear in their simulator? From their flight sim, the whole visible terrain has the same tint of green.

[wkitty42]

the photoscenery is nothing more than textures laid over the ground mesh... it works just like all the other ground textures...

[Hooray]

What needs to be done to automate this download and pre-processing of sat images? Any idea how much effort that would be?

Extending the Python script to automate downloading/retrieval and caching/mirroring has been previously discussed.
Another idea was using the Canvas system to fetch images automatically by setting URLs via Nasal scripting.
More recently, Nathaniel mentioned plans to look at supporting WMTS directly.
That way, people could run a caching proxy locally to fetch/cache tiles as needed.

One hugely important consideration here being that we almost certainly don't want hundreds of fgfs users/clients "hammering" those public APIs, because that might reflect badly upon this community and FlightGear as a whole. So as a community, we should work out a scheme that is ideally "lightweight" when it comes to the services providing such imagery, while also being entirely legal.

Technically, that almost certainly means that "we" as a community/project cannot "ship" (distribute) most imagery easily, but will instead need to provide tools/mechanisms to enable end-users to fetch such images. However, we also don't want to cause bandwidth in the form of O(n) - simply because we have too many tiles and end-users that would ultimately end up fetching the same images, possibly concurrently - which would be the equivalent of running an accidental DDoS attack on services providing such imagery for free.

Thus, it it most likely that an open standard (along the lines of WMTS) is going to be supported, and existing tools (caching proxy servers) are going to be supported - that way, end-users could opt to run such a caching proxy locally, and/or use a public caching server - another idea, some folks have been discussing is using torrents to distribute such images.

Doing some/most of this by adapting existing Python scripts would be comparatively straightforward, but not necessarily lightweight on the distributing services, so that their TOS might be violated by dozens/hundreds of fgfs users hammering their web APIs. Which is why we need to walk a fine line and find a viable compromise, without harming the project's reputation accidentally

If in doubt, check back with the developers mailing list, and maybe reach out specifically to Nathaniel himself.

[oracle]

Thanks. Let me recap the constraints:
1) Not allowed to store cached images on separate hosting (btw, even if allowed, this would be costly - looking at how much traffic I generated with Google just testing their sim for 1/2 hour);
2) Accessing provider free images en masse may turn into service abuse;

If you think about it, using any torrent service looks like distributed abuse of image ownership. I.e., instead of having all scenery cached somewhere for FG users, images will be spread on multiple machines and shared between users. This only reduces the problem of maintaining scenery servers (which is not bad per se).

Has anyone actually asked providers if they would agree to allow their images to be used in the flight sim? And if they would, under what conditions?