Unpredictable data usage Map

Bugs and Other Issues
#18

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.

#19

Thanks, I just edited my response to Steve.

#20

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.

#21

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.

#22

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.

#23

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!

#24

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.

#25

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

#26

@ewpatton Any perspective of a cure yet?
(Very curious...)

#27

@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.

#28

Current status 11/28:

#29

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!

#30

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:

#31

Just re-built my Map-App to see if the tile-reload issue has been resolved, but no found improvement whatsoever.
Don't know if I should be hopeful or dissapointed...

#32

Hi @ all,

i tested my app today without wifi and ran into the same problem.
Is there any progress in that topic?

Or is the only recommendation to use the OSM through webview?
That would be really bad for me, need to change all my runtime Marker stuff...

Greetings, Rudi from Germany

#33

Welcome Rudi.

Explain the problem? No problem using WIFI; using Data an issue?

You can read the issue ticket

Evan at MIT believes the problem Wil describes is an unsolved OSM api issue. Sorry, MIT can only work with the api; they can't fix it.

  • OSM through a WebViewer is a possibility . Since the issue is an OSM problem that use of OSM might not solve your issue, whatever that is. An example showing how to use OSM without the Map Component. If this 'solution' works for you, please let us know and provide an example. Thank you.

  • A way to ameliorate tile reload issues might be to use cached tiles with WIFI and Data turned off Offline osm Map - #2 by SteveJG .

  • An possibly better alternative to OSM tile issues is not to use the Map component. Instead use the Google Map API using a Static Map or a Java Map, the Web component and structure your code by constructing a url as described in numerous posts in the community and original App Inventor Google Forum.

#34

If you can send us an example AIA with the map set to replicate the issue this is most helpful, since we can compare it to known tiles that cause or don't cause issues.

#35

Moving to OSM or Google maps throuh a webviewer is not an option for my application.
I was charmed by the all the features the MIT Map component offers and I used a lot of them in my Radio Direction Finding app 1.5 years ago when I stumbled over this problem that the app sometimes uses more than 1Mb per second(!) of my mobile data bundle.
And when I dropped the problem here it turned out that the issue was already reported by Eutill a year earlier .
I realize and respect that this may be a tricky problem, but I think it's about time MIT provides some form of clarity:
1, They can and will solve the problem soon, or:
2, They simply can't solve the problem in which case I think a warning should be issued to all students/users that -in all ignorance- might use the Map Component and discover the problem only after their data bundle has evaporated.

1 Like
#36

Thanks for your fast answers :slight_smile:

I think the Problem is shown and explained already a lot. If someone didn´t believe here is the simply AIA witch also have the Problem (maybe related to the Centre area). Start the app, and check mobile or Wifi data usage after a minute. Its downloading the whole time without moving the map.
map_issue.aia (1.1 KB)

The main issue is that your mobile data bundle will evaporated after some hours.
Of course it doesn't matter if you are connected to wifi. But i think the most time you need the map component is in some mobile (not Wifi) environment.

The Map Component has really nice features. But it is not applicable for mobile use.
I also understand that the Problem comes from OSM not from MIT.

So in my Case i have to switch to some alternative Map component.
I need to checkout the possibility of markers and map features for the Webview options. But i think i will use some Paid extension. like this: GmapsPro

And i agree with pa8w:

2, They simply can't solve the problem in which case I think a warning should be issued to all students/users that -in all ignorance- might use the Map Component and discover the problem only after their data bundle has evaporated.

Greetings, Rudi

#37

Still unsolved unfortunately.
@ewpatton : Did you dive into the link I posted here:

They seem to have solved a similar issue.

Thanks,
Wil