This seems like a perfect location (example) to see that Asobo does not take the highest res sat image … and “down scales” from there to get a consistent LOD layering … but that they actually are using (totally?) independent sat images LOD image sets.
Ok, the effect could originate from the Bing side … but I think that Asobo should reconsider the strategy.
I fear that this might be a cost issue … if Asobo takes the “official” Bing data, then they only need to pay for the traffic but not for the storage. But then again … I seem to remember that initially the explanation was that Asobo does its own post procesing and that they have their own set of sat images. If that is the case, then the example from @thalixte is hard to explain (understand)
I checked these coordinates. In fact it is the same. bing maps has different images per zoom level, it loads a new image. it does not zoom in on an image. Yes bing it’s zooming to show more details, but uniquely it’s a different image.
The question now is, did Asobo got old pictures on that level, or are the pictures not “refreshed” on that level.
Yes, which means the above question needs to be answered before we know what happened.
Do we know that bing did not had this problem when the new world region for wu6 was build from imagery? (not talking assets, only talking sat images (which are of course also assets, but you know what i mean, hopefully)
If bing had the same issue at that moment, it’s garbage in, garbage out ;). If it’s a bug that the highest detail layer is build incorrectly. it probably should have been on the whole wu6 scenery the case.
Borkum in the Frisian islands is the same. With the cache preloaded at Ultra, everything loads in ahead except ground texture, and the ground texture pops in like a checkerboard when you get close. I’ve flown over Germany the last three days, and this is the only area where it has happened.
I can confirm the issue. It occurred to me when doing FS Academy Voyager - Alps bush trip in the last segments. A circle below the aircraft had different coloring and texture of the ground tiles.
same issue at and near of EDVY Porta Westfalica / Weser Mountainarea. Checkerboard Groundtextures at lower altitudes and lack of trees on the Mountains nearby. Also the groundtextures seems to show different seasons (lower altitude seems like autumn/winter). I hope they have other datasources in Bing. Otherwise it would be a huge problem…
I have a strong suspicion that this issue is related to the scenery issues around Edinburgh and in other parts of the UK that seem, somehow, to have conflicts with autogen and WU3 (in that case).
See this thread (and others with similar issues raised):
Remember that the sim is a Microsoft software, and uses the Microsoft’s infrastructures. Bing data are Microsoft’s data, and the sim streams them to deliver the world in real time in your PC. What is strange here is that, until the most detailed LOD, the bing data are correct and match the one you can find in the Bing maps website.
But it is not the case anymore for the most detailed LOD.
The main question here is: why does the sim delivers correct Bing data until a specific altitude, and incorrect ones under this altitude ?
We can make some asumptions here: maybe MSFS uses some specific Bing data servers that are different from the ones that deliver Bing data in the website (so it is a data replication problem). Maybe the bing data servers that deliver the maximum LOD tiles are different than the ones that deliver the other LODs.
Maybe the sim applies a specific treatment in the most detailed LOD tiles, and for some reason, this treatment does not refer to the good uri to retrieve the up to date tile.
Well, i could be wrong but it looks like the static bing data is delivered by amazon and/or akamai. When loading the sim you can see mfs bashing these servers to receive data. Most of it from amazon, up to 20 to 50 mbit if no data is cached. So even though it’s bing data, it looks like not to be delivered from ms.
The only data I’m seeing coming and sending from/to ms is volatile real time data (multiplayer etc…)
I would suspect this data looks to be a snapshot (when a new world or region is build). It’s not real time bing data. This data could already be 1,2,3 or more months old. When Asobo took/got a snapshot, and bing had issues. It will get malformed data. Like now when a new high resolution image is cut into 16/32 regions, but the “zoom” level which uses the 32 cut parts, is not updated with these new cuts.
Why does Asobo uses snapshots (as it looks that way)? Well they can’t afford modified satalite images which alters the world in an unexpected way. Because if they did, you can end up like the current situation. This because satalite images are of more then not, taken in different hours/days/weeks/seasons/etc… This is the reason that different images can be shown on different zoom levels. Satalite images, yes are quite static, but also dangerously volatile when used as content.
So, i think:
They create/get a snapshot of different altitudes,
They build a new world/regions on azure (spatial data/blackshark),
Publish to Amazon/Akamai and mfs region (like wu5) download location
These networks dispatch internally to regions (eu-west for example)
Mfs uses this data.
So to fix this they probably need to rebuild.
But again, it’s all speculation. But it definitely looks like a snapshot and imagery is coming from Akamai and Amazon.
Yes, that’s seems accurate. But there are data streamed from microsoft servers. Maybe metadata are streamed from them, then big data (models, textures) are brought by AWS.
Problem still present after SU6.
On the bing tile on the right sight 3d forests are drawn correctly, On the left side unfortunately not.
Location is Wuerzburg
You are probably more right in a way than i imagined.