Hi,
When loading a KMZ as an OperationalLayer the bitmap (PNG) inside gets rendered way more pixelated as it actually is.
This only happens on real hardware (Android devices). I was not able to reproduce it on any emulator yet.
Here is the KMZ loaded on an emulator:
Here it is on an "Oneplus 7 Pro" (also happens on a Samsung A52):
The KMZ has only two files in it:
The kml looks like this:
<?xml version="1.0" encoding="utf-8"?>
<kml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns="http://www.opengis.net/kml/2.2">
<GroundOverlay>
<name>Lageplan_EbsL 2270 15 Bph 3</name>
<color>ffffffff</color>
<drawOrder>1</drawOrder>
<Icon>
<href>Lageplan_EbsL 2270 15 Bph 3.png</href>
</Icon>
<gx:LatLonQuad>
<coordinates>6.476503675883501,51.7606388044081 6.467556177491324,51.76654569164255 6.464917693895138,51.76500669726339 6.473865235003178,51.75910000921075</coordinates>
</gx:LatLonQuad>
</GroundOverlay>
</kml>
The .NET Maui Source which loads the kmz looks like this:
using Esri.ArcGISRuntime.Geometry;
using Esri.ArcGISRuntime.Mapping;
using Esri.ArcGISRuntime.Ogc;
using Map = Esri.ArcGISRuntime.Mapping.Map;
namespace ArcGISTry1;
public partial class MainPage : ContentPage
{
public MainPage()
{
InitializeComponent();
// Create the UI, setup the control references and execute initialization
_ = Initialize();
}
private async Task Initialize()
{
// Set map to mapview
MyMapView.Map = new Map(BasemapStyle.OSMLightGray)
{
InitialViewpoint = new Viewpoint(new MapPoint(719870.63885198254, 6757789.5101162922, SpatialReferences.WebMercator), 600)
};
MyMapView.Loaded += OnLoaded;
}
private async void OnLoaded(object sender, EventArgs e)
{
for (var i = 0; i <= 7; i++) {
// ArcGIS Runtime ist hier so "super", dass es die Daten für dieselbe URL kein zweites Mal vom Server lädt!
var dataset = new KmlDataset(new Uri($"http://soko.yourweb.de/kmz/PixelBug/0{i}.kmz"));
await dataset.LoadAsync();
var kmlLayer = new KmlLayer(dataset);
MyMapView.Map!.OperationalLayers.Add(kmlLayer);
}
}
}
I have tried for hours now to change the source, the way I load the dataset or when I'm doing it. Also I've tried to look at all the variables (public and private) of the dataset, kmlLayer, etc. via the debugger to find out whats going wrong here...no luck.
Also changing the image file from PNG to JPG does not help (JPGs are also highly pixelated)
Find the full example Solution attached as well.
Some weird details:
The KMZ you see in the screenshot is the one with index 4. It seems only every other KMZ is rendered pixelated. But if I only load index 4 its also pixelated... so it cannot be the order or index in the layers...
If you scroll a little to the north-west you get a black broken line which shows the border to the next KMZ. That one is rendered properly (purple circle) compared to the pixelated one (pink circle)
I hope you can help here as my customer is not happy at all with this.
Thanks
Soko
EDIT1:
I've just found out this issue is not related to a full/whole image! Here is the KMZ with the Index 00 opened on my PC via IrfanView at 200%:
On Android the pic is upside down and looks like this:
You see "40-27" is way more pixelated than on Windows... AND... "40-30" is way more pixelated than "40-27" even both are from the same file (PNG/KML/KMZ)
EDIT2:
Even when using a LatLonBox in the KML (not the gx: extension) and placing the PNG with no rotation the pixelation is happening.
Use "00LatLonBox.kmz" file so you can see. It's located at the same spot/folder as the other examples (see source code).
Here it is:
<?xml version="1.0" encoding="utf-8"?>
<kml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns="http://www.opengis.net/kml/2.2">
<GroundOverlay>
<name>img</name>
<color>ffffffff</color>
<drawOrder>1</drawOrder>
<Icon>
<href>img.png</href>
</Icon>
<LatLonBox>
<north>51.7127439517942261</north>
<south>51.7</south>
<east>6.4</east>
<west>6.4742745211839814</west>
<rotation>0</rotation>
</LatLonBox>
</GroundOverlay>
</kml>
EDIT3:
I've made some example images/PNGs and tried different file sizes, content, aspect ratios, pixel sizes and dpi...
It seems that each pixel which is beyond x=2000 and y=2000 gets highly pixelated.
That is the only criteria of all the ones mentioned above...
Hi! I was able to reproduce the problem on Android. We are investigating the cause.
By the way, if you ever need to temporarily disable HTTP caching in ArcGIS Runtime, it can be done with HttpConfiguration:
builder.UseArcGISRuntime(config => {
config.ConfigureHttp(httpConfig => {
httpConfig.UseResponseCache(false);
});
});
Hi,
Thanks for letting me know and your tip. I'm curious about the cause of this issue.
Soko
@MatveiStefarov : Any news here? My customer really needs a solution for this! thanks.
Unfortunately, no news yet. But the team just wrapped up work on the next release (200.2.0) and this will be one of the first issues we look at for the next release cycle.
@MatveiStefarov I've just re-tested this issue with .NET MAUI 8 and 200.3.0 and the bug still exists. Can you please update me on a progress here as you mentioned above it will be addressed after 200.2.0...
So I was confident it would be fixed in 200.3.0 😞
I highly appreciate you providing feedback and finding bugs. As @MatveiStefarov mentioned we logged this bug in our system but unfortunately was not prioritized for a near future release due to many other factors. We try our best to help the community and our users and triage issues as soon as possible but we cannot commit a fix until a bug is prioritized.
If the bug is super critical for your workflow, blocks further development or affects lot of customers, I highly recommend contacting esri Technical Support and log a bug through them. That way you can request to escalate it, if needed.
Thanks for understanding 🙂
Preeti
Hi Preeti,
I just wanted to check in as @MatveiStefarov said "...will be one of the first issues we look at...".
It is a bummer this won't be fixed in th near future, but as a seasoned developer myself I understand your reasoning.
Being very long in the business I knew I cannot wait for you guys to fix the issue (no offence) so I've implemented a workaround after creating this ticket:
I make sure no picture is bigger than 2000x2000px in the KML. Which is tricky as the pics my end-users supply are bigger most of the time. So I have to split them in pieces and calculate the new positions of those pieces.
This is not performant though (when creating and viewing the KMLs as there are way more than needed) so I was hoping for a solution here.
Anyhow... I appreciate all your support and trying to help us guys here.
Soko