Select to view content in your preferred language

[.NET MAUI] Map Rendering Issue with AutoPanning and Rotation in ArcGIS Runtime 200.6.0

248
4
4 weeks ago
Labels (4)
RalfSchmidt
Occasional Contributor

We are experiencing an issue with map rendering when using AutoPanning in our .NET MAUI application with ArcGIS Runtime 200.6.0. The problem is especially noticeable when the map is rotated. The map does not update correctly during auto-panning, leading to an incorrect display. For instance, see right upper area in following screenshot:

Screenshot with rending issue in right upper areaScreenshot with rending issue in right upper area

Environment:

  • Framework: .NET MAUI
  • ArcGIS Runtime Version: 200.6.0
  • Map Type: MMPK (Mobile Map Package)

Steps to Reproduce:

  1. Load an MMPK-based map in a MapView.
  2. Enable AutoPanning (e.g., for tracking GPS movement or user interaction).
  3. Rotate the map.
  4. Observe that the map does not render correctly or fails to update as expected during auto-panning.

Additional Information:

  • We would appreciate any guidance on potential workarounds or if this is a known issue.
  • Let us know if further details or logs are required.

Any help or insights would be greatly appreciated!

Thanks in advance!

0 Kudos
4 Replies
PreetiMaske
Esri Regular Contributor

This is most likely an issue with extent of data in published MMPK. Does it correct itself if you pan or zoom slightly?
I am happy to look into more if you can provide the test app and the data.

0 Kudos
RalfSchmidt
Occasional Contributor

Hello Preeti, thanks for your response. 

I forgot to mention that we are in the process of migrating our application from Xamarin with Runtime 100 to MAUI with Runtime 200. With Runtime 100 we did not see the described behavior.

When zooming, a part of the missing map does load, but it seems that due to the rotation, not enough of the map is preloaded or rendered properly. It appears that the extent calculation might not be accounting for the rotated view correctly, leading to missing areas during auto-panning. When the map is panned manually, you can see it loading even when panning slowly. But it basically loads instantly instead of staying grey (or blue) for up to 10 seconds.

Furthermore, the MMPK is created with ArcGIS Pro 2.6.x because all MMPKs created with 2.7 or later suffer from the bug BUG-000157394 "Mobile map packages created in ArcGIS Pro 2.7.0 or newer do not honor the Join symbol layer drawing option when displaying the .mmpk file in ArcGIS Field Maps". This bug lets street crossings appear ugly and unprofessional.

In the video attached we compared the Runtime 200 behavior with an MMPK created with ArcGIS Pro 3.4.2 (left hand side) with an MMPK created with 2.6x (right hand side). With the newer MMPK it seems to be even worse. But this is only by chance. Generally, the behavior of Runtime 200 is similar with both MMPKs. On the start image, you can clearly see the ugly crossing rendered with the 3.3.4 MMPK.

Is there any way to configure how much of the map gets loaded or to adjust the extent calculation to ensure proper rendering even when the map is rotated?

Unfortunately, we cannot provide the MMPK publicly. Do you think it would be a good idea to raise a support issue with this issue?

We appreciate any insights or suggestions you might have!

0 Kudos
PreetiMaske
Esri Regular Contributor

Yeah, Video capture helps, I can see the problem but I can't tell if it is publishing issue or Maps SDK issue yet. What API are you using for auto-panning and rotating? What events are you using to trigger pan and rotate as location is changing? Can you share that piece of code? I will see if I can replicate at my end using your code. You can definitely try connecting with support and raise an issue or if you like you can share the MMPK and test app with me and email directly at pmaske@esri.com.

0 Kudos
RalfSchmidt
Occasional Contributor

We came to the impression that it might take some time to fix this rendering issue. Therefore, we tried alternative approaches. We gained the best results by additionally creating vector tiles ("VTPK") and use them as the basemap instead of rendering the features from the MMPK on the fly. Using this approach the rendering is smooth and looks even better. The drawback is that the MMPK has increased from 2 MB to 6 MB because of the additional vector tiles. But this shouldn't be an issue anymore in 2025.

Nevertheless, Preeti, thank you very much for your support!

0 Kudos