Of course:
datatest.aia (2.1 KB)
I ran it on a Samsung tablet as wel as on my Samsung phone: both show the issue as described.
B.t.w.: I use Data Monitor from KF Software House in Playstore.
It looks to me that for some reason AI2 keeps trying to load the same tile(s) over and over again.
The project I shared here is the stripped version of my real application, created to plot bearing lings from a Radio Direction Finder. But also this stripped version shows the same issue.
There is a problem. But is it a problrm on the Appinventor side or on the side of a map supplier, I do not know it anymore. I recorded a movie to show what the problem is.
At the beginning of the movie you can see that the transfer is 0KB / S, when the map moves, the transfer increases and download new tiles, but it does not lower. Later, move the map again and the transfer drops to 0kb / s. This happens with various regions of the world. Blinking different elements of the map also noticed. This happens to the location enabled and disabled.
Exactly, glad you took the time to reproduce and study the issue, thank you.
The funny thing is that direct access to OSM does not show the issue at all, only the implementation in AI2 does.
So how to proceed from here?
Does this thread ensure that it gets the attention of the people that can solve it?
Or do I need to drop it somewhere else to get the attention of the AI2 engineers?
Super, thanks again you both for your input.
How are you doing that OSM access Wil?
Did you do a similar test of data flow using the OSM web page? Did you use your browser to access OSM? Here is a discussion showing how to access [OpenStreetMap without the Map Component] (https://groups.google.com/g/mitappinventortest/c/gGAeQN3r_fg/m/Dc8PY5HrAwAJ ) using App Inventor . As a comparison Wil, can you test data usage using network using access to OSM like this example? Knowing that might help MIT.
The app using Map caches OSM tiles. It is probably saving them to the app and continues to down load after screen movement as a guess. That does not happen when accessing OSM directly and might be part of the issue.
Not familiar with your data flow tool. It may be monitoring ALL data flow and why you get the response you see. You discuss excessive rates of severel Gb in an hour. It has been a while since I tested data usage. In an hour long test I made some time ago with network on for an hour, the usage was only on the order of Mb's based on my cell Provider records. Not excessive. I can't explain your usage.
Another developer expressed similar behavior with respect to Map tile behavior a year ago. He reported to MIT, see Evan's reply Map component: frequent tile re-load
The Map component uses some of the code in the LocationSensor component. It will poll a location change every 60 seconds so, depending on the Map settings. The issue could be related to that behavior.
Thanks for your example.
--Steve
Hi Steve,
The "Map component frequent tile re-load" issue seems to be exactly the same issue.
Evan's suggestion: I can't find any tile in the directory he points out. It's empty.
But my app stores tiles without any problem, because when I cut off any internet is has stored exactly the tiles I visited in the zoom level I used.
The issue absolutely is repeatedly loading the same tile for whatever reason.: If I happen to be on a tile with zero data traffic, swiping the map to the next tile sometimes shows a short burst in data but within a second data usage drops to zero again, like it does in OSM in a browser.
But in a lot of occasions, that data stream won't stop, it stays at 400kB per second or so, until I carefully swipe back to the previous tile. So there seem to be tiles that do load (are stored in my phone) but are still being reloaded. Swapping between 2 zoom levels may sometimes show the same behavior. My app needs the Map component for the features it can offer, like drawing lines etc.
Running my stripped datatest.aia Patryk_F saw the same issue.
And installing/running datatest.aia I don't give GPS permission, nore doe I see any activity of that kind.
Other apps consuming that amount of data is out of the question. It is directly related to what I do with the Map in AI2.
Edit: I just built and run the alternative OSM approach you suggested and found this:
1, Data consumption for loading a fresh tile is considerably lower and drops to zero in less than a second.
2, I wasn't able at all to get the same reload issue, not a single time and believe me... I tried! 
I hope that helps.
Hello fellow developers,
I originally reported the Map component: frequent tile re-load issue some time ago.
Thank you for re-reporting this issue as I can confirm that it hasn't been sorted out yet.
I conducted the same test as one year ago, this time on a new phone (Sony Xperia 10 II) and on Android 11. Unfortunately, the map component still shows the same unwanted behavior.
Sniffing my network traffic on Wireshark, I can observe that the tiles in question are reloaded very often, but only some tiles and some zoom levels are affected by this issue, as you already stated.
For this test, I created an app that only contains the Map component and no blocks (see this aia: maptest.aia (1.0 KB) )
Wireshark tells me that all requested tiles are being loaded from the OSM server with no issues, i.e. with HTTP code 200.
Thanks, I just edited my response to Steve.
Do you mean in the Android Settings, you turned Location off? Map has it's own LocationSensor as part of the component (users cannot control it, it just is. You cannot turn on or off that feature). Perhaps Evan will explain.
I ran your aia Will; I see you do not connect a LS. I looked at Patryks video. Your data toy shows activity indicating something. Did you look and test the non Map component OSM access discussion I provided using your data logger? What are the results?
You might continue using the Map with all its foibles, I expect it will be a while before MIT finds the issue. I don't see a serious issue based on my tests but sympatize with you guys. The issue might be with App Inventor, it might be as Patryk suggests an issue with the OSM api accessing their server. Only MIT can figure this out.
In the meanwhile, you might use the Google Maps api along with a WebViewer and do your dataflow check. Google's map tiles used this way may consume less data. Developers can do the same stuff Map can ... zoom, plot locations, plot traks, determine bearings etc. Google Static Map API
Why not try this and see how data flow compares?
Also, continue to post your theories, they may help Evan debug if necessary.
As you can see I added my findings in my last post Steve.
Well, I can't recommend any designer to use the map module now, as it may burn up a modest data budget within a few hours...
And most people may have no idea what's went wrong.
The data consumption of your alternative OSM approach is peanuts. No issue at all.
So, MIT would do a lot of users a big favor if this bug gets fixed.
I'll arrange a time to look at this today. We use another library for drawing the map on the phone compared to the browser, and it's possible that something is going wrong there if just one tile is causing issues.
Super!
Panning the map you will encounter both tiles that behave normally, dropping data consumption down to zero within a second, and plenty of tiles that keep on consuming up to 500kB per second.
Hope you can fix it, I love Maps features!
Ok. I have been able to replicate this issue using the emulator. I think it may be a bug in osmdroid, but I need to dig a bit deeper into the library to understand what might be happening.
Hello,
sorry to @ you, but maybe the observations I made in my post could help you (Map component: frequent tile re-load), as it is the same problem.
Thank you,
Leo
@ewpatton Sorry to inform you that lately the issue has increased pretty dramatically: Often I notice a very slow build-up of the map (grey tiles that won't load) and at the same time a data consumption of >800kB per second, that's more than 2.8 GB per hour.
Wil.
Current status 11/28:
Thank you Steve, (and Evan)
In the mean time I tested the Map component in Kodular and in Niotron.
Both show exactly the same reload issues, so there must be a common cause.
Good to see that Evan already reported the issue on april 6.
Hope it will be cured soon!
On april 5 Evan suggested that it may be a fault in osmdroid.
I found the following issue in osmdroid dated jan 23,2020 describing similar behavior: