[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

In response and relation to feedback arising and quoted, regarding 'slow down' to the extent of appearing to 'freeze' busy state , which is essentially just symptoms of known issues and feedback already reported:

And:

It has long been established the content of the users Map folder absolutely affects GCC on a device in a number of different ways, in turn creating a number of primary and secondary effects, and that this primarily stems from the 'infill missing tiles with nearest available lower zoom level tile' feature.

Microsoft .Net Compact Framework Remote Performance Monitor, shows in real time 'Exceptions Thrown'.

4.11 beta 15, when tiles at a given zoom level are missing, 'Exceptions Thrown' are observed. Where tiles are missing at a given zoom level, and those that would infill from the level below are also missing, and those that would infill from the level below that are also missing, and so on, 'Exceptions Thrown' increase rapidly.

4.11 beta 16, when tiles at a given zoom level are missing, missing tiles no longer in and of themselves cause 'Exception Thrown', nor do primary effects. Secondary effects do however still produce 'Exceptions Thrown'.

'Exceptions Thrown' whilst related are however separate and not to be conflated. It is established these primary and secondary effects arise from the 'infill missing tiles with nearest available lower zoom level tile' feature present in 4.10 Final and 4.11 beta 3 to 4.11 beta 16. The effects are not observed in 4.11 beta 1 and 4.11 beta 2 that did not have the feature present / working, creating a different effect (missing tiles being blank, the background colour selected) not to be conflated or confused by those with missing tiles and / or non standard maps in a manner never intended.

The 'slow down' to the extent of appearing to 'freeze' busy state when zooming is simply another secondary effect, established by that it does not occur in 4.11 beta 1 and 4.11 beta 2. It can be observed to occur whether or not Track2Follow is loaded, and whether or not a .gcc log is loaded, i.e. with either or neither.

When it is observed however depends largely on the device, its resources, the processing burden GCC is placing on it, and that of anything else running on the device, all of which exacerbate the issue and the difficulty of recovering from a 'slow down' to the extent of appearing to 'freeze' busy state.

On the HTC HD2 running 4.11 beta 16 with complete maps for the area up to level 16, with a large T2F or .gcc loaded, map can be zoomed to '1E-06' '23-7' before 'slow down' to the extent of appearing to 'freeze' occurs. Without T2F or .gcc loaded it will go higher before becoming symptomatic. This high specification device running little but Windows Mobile 6.5, Microsoft .Net Compact Framework 3.5 (within the device ROM, not installed separate) and GCC, the bare essentials, recovers fully from the condition and becomes responsive fairly quickly shortly afterwards. More burdened and or less capable devices will perform less favourably, exhibiting symptoms sooner and / or taking a longer time to recover, and may also become unstable and erratic with other functionality such as GPS and sound when in a busy condition. Some devices may take many minutes, some longer, some may respond to a busy condition with a press of the hardware power button and recover sooner than it would have otherwise. Some that seem to recover may not do so fully, some aspects not working or working properly until the application and or device is restarted. Other devices may restart themselves or remain unrecoverable indefinitely without a battery pull. The exact behaviour of the device essentially is dependent on multiple variables, at least some of which, if not all, have been outlined.

Symptoms can be observed to occur at a higher zoom level with 4.11 beta 16, due to better handling of 'Exceptions Thrown', i.e. no longer creating them, having some effect but not addressing the underlying issues, just mitigating that symptom somewhat.

4.11 beta 1 and 4.11 beta 2 simply 'client zoom', i.e. magnify the highest available level tile on device, when zooming further. No limit could be reached where 'slow down' to the extent of appearing to 'freeze' would occur.

4.10 Final and 4.11 beta 3 to 4.11 beta 16 use 'client zoom' (magnification) in conjunction with 'infill missing tiles with nearest available lower zoom level tile' increasing the processing burden. At each level of zoom where tiles are unavailable, the feature looks to the preceding lower level and so on, until a tile is found. Up to 4.11 beta 15, via the 'Exceptions Thrown' this could be seen to be occurring repeatedly with each retry approximately every second, rapidly increasing the rate of 'Exceptions Thrown' that also increase again with each press of zoom in.

There are a number of measures available:

Better handling of 'Exceptions Thrown' as in 4.11 beta 16 is a good start mitigating issues with any devices Garbage Collection facility. Further measures to address underlying issues are however required, as outlined briefly below:

'infill missing tiles with nearest available lower zoom level tile'

Option to disable 'infill' entirely. It is not required for 'client zoom' (magnification). It is not required when tiles are not missing on all zoom levels of the area the user requires, i.e. when the user has a complete map. It would eliminate entirely primary and secondary effects. It would not use resources unnecessarily. It would provide useful ability for users with missing tiles to be able to readily identify those and ideally obtain them so as to not need to infill, especially if instead of a blank tile, there was information to identify the tile. There are no issues with additional options being implemented that cannot be overcome.

When not downloading maps:

i.e. Maps on Memory Card or on Device: Zoom levels and tiles not present already are not going to become available.

- Limit 'infill' retries, do not then try again. This will still infill missing tiles where possible.

- Disable 'infill' entirely when zooming beyond upper level folder available, i.e just 'client zoom' magnification.

- Prevent zoom out below lower level folder available, has no practical purpose as no maps are displayed.

- These last two are essentially a zoom limit, to zoom levels actually available.

When downloading maps:

- Limit 'infill' retries, and possibly number of tiles being tried, wait for a period, then retry again.

- Disable 'infill' entirely when zooming beyond level zoom limits, i.e just 'client zoom' magnification.

- Zoom Limits: Not all users require mapping down to level zero, the entire planet. Not all users require mapping up to beyond that available from their chosen source of mapping, up to that of level 23 *. Lower zoom limit can be user selectable. Upper zoom limit can user selectable up to level 23 *, or intelligently up to the actual limit of the map sever. Mobile Atlas Creator for instance intelligently knows the zoom limit of the map server, so can GPS Cycle Computer, it being stored in the osm_servers.txt configuration file for instance.

Client Zoom (Magnification) Limit:

Current restriction to within the capabilities of the device and or no restriction at all, essentially the same thing, should actually be restricted within the realms of sensible, proportionate and usable practicality because if anything is seen at all, image resolution does not allow anything to be usefully discerned beyond the point of usable practicality serving no useful purpose whatsoever.

Zooming in, the current extremes of infinitesimal zoom in, should be addressed as above. For example, level 16 tiles are essentially only good zoomed up to the first stage of level 19 magnification. By level 23 they have long since passed the point of being useless. If level 23 tiles were actually available, the practical usefulness of zooming further is questionable. Certainly by the stage the scale information changes to from 0.0001 miles / km (0.1609344 meters, 16cm approximately) to 'xE-xx' , where x are numbers, the point of uselessness has long since passed.

Zooming out, the current extremes of infinity zoom out should obviously be limited to that user selected or available, which will be level zero, the entire planet, at most which few if any users have any genuine need for.

Zoom limits have merit now as they did when I originally proposed them, previously detailed.

* GCC Support for tile levels 20, 21, 22 and 23: (0.15, 0.7, 0.4, 0.2 meters per pixel (m/px) respectively approximately)

Level 19 (0.30 m/px) is the Open Street Map current format limit. Typically map servers support up to level 18 although by no means all, few support level 19 yet. It is entirely possible for users to create their own correct level 20 - 23 tiles, in correct OSM format, or some may even be able to obtain it ready made, but that is neither usual or typical.

GCC should detect and reject tiles in folder levels 20, 21, 22 and 23 that are not actual 20, 21, 22 and 23 tiles. Within OSM format, folder structure and folder name, and file (tile) name, are integral and represent coordinates. Therefore if not produced correctly, further issues arise. It is insufficient to simply place tiles of a particular level at anything other than that intended level, for example, level 18 tiles should not be placed other than in a level 18 folder, otherwise the OSM format and OSM mapping is broken.

There is a difference between using correct level tiles, in the correct level folder, but with differing mapping sources / aerial / satellite imagery tiles for each level, and using incorrect tiles in an incorrect level folder. Using differing mapping sources / aerial / satellite imagery tiles of the same level actually requires separate map folders for each. If in attempt to avoid this the tiles are simply just placed incorrectly in additional higher zoom levels, this breaks OSM format, does not work properly, and creates further issues in addition to exacerbating those aforementioned. It that functionality is required, it needs to be properly implemented and developed accordingly. How this can be done is straightforward, but nonetheless outside the scope of this response.

The information is there for a purpose and should remain. It can however be improved: For example instead of 23-3 intended to represent level 20 with 3 levels of zoom, it could be as follows:

15+3 representing 'Actual level+Client Zoom' where level 15 is highest available, client zoomed (magnified) 3 additional (the + (plus) symbol, being intuitively additional) levels. The existing scale information can also be retained. This is far more intuitive and self explanatory.

There is nothing fundamentally wrong with any of the above, or anything that cannot be implemented when any challenges arising are overcome. Clearly good for the GCC project and in the best interests of all users, there is little if any genuine basis for any user objection to this, nor would any user be genuinely inconvenienced by anything proposed.

low.flying.pigs