I wonder if we shouldn't change the default for the tile size parameters. Current default is called "Many small map tile files" and the largest tile files I'm seeing are only about 28 kB in size, with an average of maybe 12 kB.
"Average map tile file size and count" seems a better default for me. Files then typically have a maximum size of about 30 kB and an average of about 20 kB and I think that shoule be no problem for the vast majority of platforms that people run GpsMid on.
Changing would mean to not only change the default in the Osm2GpsMid GUI but also what is used if nothing is specified in the bundle.properties files, which would thus affect the creation process of pre-bundled maps also.
Any objections or thoughts about this?
sk750, it would be good if you could comment because I think you have added the possibility to change the parameters.
For today's average mobile phones the option "Average map tile file size and count" probably will work better, so I agree we should make this the default but still leave the option "Many small map tile files" in for devices that require this. To change this if nothing is set it will simply be necessary to put the tile size parameters into build.xml just like every other default property entry.
Actually to the GUI I think we should also add more levels of "Fewer but big map tiles", e.g. divide this to "Fewer but big map tiles level 1" and "Fewer but big map tiles level 2". E.g. in bavaria.properties I use to be able to install it on Nokia 5800 at all:
maxDictDepth = 27
routing.maxTileSize = 25000
maxTileSize = 40000
maxTileWays0 = 2000
maxTileWays1 = 5000
maxTileWays2 = 5000
maxTileWays3 = 5000
These parameters could be added to Configuration.initialiseTileSize() for "Fewer but big map tiles level 2" from the GUI.
thanks for the reply.
So I'll change the default when I get round to do it.
It's no question that no options will be removed, just the default will be changed.
> Actually to the GUI I think we should also add more levels of "Fewer but big map tiles", e.g. divide this to "Fewer but big
> map tiles level 1" and "Fewer but big map tiles level 2". E.g. in bavaria.properties I use to be able to install it on Nokia
> 5800 at all:
I don't know. At least I don't like the wording, because who is supposed to understand the difference between these two proposed options?
Do I understand you correctly, "Fewer but big map tiles" doesn't work on your phone because some parameters need to be increased, e.g. maxDictDepth = 27 instead of 19, right? Then why not change the parameters behind this option?
Without being an expert on this subject, my initial reaction is: If the parameters in this option are problematic then they should be tuned instead of adding another option. (If you have good reasons not to do this then you can certainly convince me though.)
you're right, "Fewer but big map tiles" doesn't work on my phone because some parameters need to be increased, to get fewer files in the midlet. Probably increasing maxDictDepth would be ok for my mobile. The drawback of increasing maxdictDepth is of course that GpsMid will completely load the dict files into the memory which will cause heavy memory load making less available for other purposes like the tiles themselves. But for my mobile at least a maxDictDepth of 27 is ok.
Have you checked / thought about the performance implications of making tiles bigger? I think for performance reasons (which at least on the Android is not so good when compared to other OSM map programs) making tiles bigger by default might not be such a good idea, and we might even consider making tiles smaller.
Seems from code & comments that when drawing the map, GpsMid goes through all tiles many times.
Some days ago I complained about the dual-core 1,4Ghz Galaxy Note not being able to keep up with map drawing. Turned out I had forgotten on a map setting of map tile size 450 000, also with big maptileways. Actually tile sizes where perhaps < 100k. That's admittedly extreme, but the performance penalty was quite big. Back to normal tile sizes (and actually now experimenting with lower max tile sizes) performance is much better.
Not sure if or by how much upping the default tile size will affect on performance, but mentioning in case it does.
I'm wondering if uncompressed zipped map files could be a recommendation, and if needed, their performance could be improved. With quick tests, on Android devices uncompressed zipped map doesn't seem much different from unzipped maps. However disk space consumption with an unzipped map with lots of small files is much worse than with the zipped map. Also would be easier to handle one map file instead of a dir with thousands of files. But this was just with quick tests, a closer look should be taken.
On Nokia S60 J2ME phones on the other hand, I've had trouble & bad performance with zipped maps.
According to my understanding, low Java performance over big archive files in Nokia Symbian ( S60 v3 Nokia E52 in my case ) is not cause by decompression effort.
It is caused by low performance of accessing big files.
E.g. a cousin of GPSMid - Trekbuddy - uses raster maps. Usually as PNGs, or combined in uncompressed TAR archive, which is more or less analog to uncompressed ZIP.
Nokia Trekbuddy low performance over big TARs is disaster,
unless Symbian native helper is used to boost TAR access times to good values.
Low performance is caused by J2ME not being able to start reading from a certain location in big files - it always has to read the large file from the beginning.
Probably the Symbian native helper makes direct access possible for Trekbuddy.
Illustratively, what takes 30-90 seconds for really big TARs without helper, takes 1-3 seconds with helper.
If a helper API is provided to GPSMid developers by TrekBuddy author, it could be great.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.