OsmAnd rendering speed (or lack of)

[Michał Musiałowicz]

Being a driver I use OsmAnd+ on a daily basis and in my opinion it is the most versatile and reach in useful features application from those which are based on offline OSM maps. I use it also as a hill-walker, a cyclist or a pedestrian wanting to find a specific place in a unknown area. I generally like the idea behind OSM maps, i.e. they are free to use and free to contribute what I modestly do from time to time.
Unfortunately rendering speed is, being polite, only satisfactory. Or maybe slightly below. I hoped that things will improve on a new phone but disappointingly despite three times better benchmark results it's even worse. This can be in part explained by bigger number of pixels in the new phone's screen.
I installed some other OSM apps to compare speed and sadly I found that they render and zoom in and out quicker, pan more smoothly while driving, even in 3D mode. I tried Magic Earth, MAPS.ME, MapFactor Navigator, Sygic GPS Navigation, Galileo and few others which I deleted too quickly to memorize their names.
It would be great to see improvements in this area some day but for now could someone advise any solutions? Am I missing something? Or is OsmAnd simply slow-ish?
Regards,
Michal

[Majka]

The rendering speed is ... slow-ish, but usually usable for me.

Few tips:

Check that Mapillary is switched off - this part can block rendering completely. THIS is a bug, IMHO.

Use map overlay / underlay / height data only when needed.

Install only maps you really need and archive what you don't need - you can "unarchive" easily.

Do not use road map and detailed map for the same area - for example road map of Germany and detailed map of Bavaria for driving in Bavaria - Osmand should render only one of the maps (the selected one), but will try to search in all of them. An exception would be a very long distance drive, where the better speed through having only a road map for most of the distance would be preferable to slower speed caused by the much bigger maps with details.

All this will slow the rendering unnecessarily.

I suspect one problem is that the map is so detailed - there is simply more data to sift through and to discard when not needed at the moment. Other apps use much smaller part of OSM data, Osmand has probably the complete set.
It is a trade-off - slower but detailed map or faster map without all the additional usability.

The rendering could be faster, but I can live with the current speed.

[Harry van der Wolf]

For me this is exactly the reason why I don't use OsmAnd anymore for car navigation: rendering is way too slow!  I'm still very enthusiastic using it in cycling and hiking, where rendering can be much slower due to the lower speeds and therefore lower map/screen refresh rate.

It has been confirmed by Victor already a couple of times in the past, and it is one of the improvements we are all waiting for.

One of the reasons is also that OsmAnd is single-threaded. I have a quad-core android head-unit in my car and an 8-core relatively fast phone, but if OsmAnd is only using one core there is not much use of quad-core or 8-core.

Note that it is also part due to the fact that OsmAnd has really by far the most detailed maps, containing the most map "items" of all nav apps. These huge amount of detailed  "items" take some time to render as well.

If you use a roads-only map for driving, rendering is much faster (factor 1,5-3. I tested that many times with debug frame refresh info). But I don't like switching back and forth between full and roads-only maps, and having a double set of maps.

Roads only maps contain roads, some large map"scenery" polygons (woods, large lakes,  big fields, etc), addresses and POIs.

Finally: OsmAnd maps are uncompressed binary files, also containing 3 layers of details for the different map zoom levels.

With regard to compressed/uncompressed: Having small, fast to read compressed files and using multi-threading to decompress and interpret maps, like some other apps are doing, might also give a performance benefit.

Having only one full layer and make the software decide what to show during which zoom-level might give a performance enhancement as well. Note that the 2 low zoom level sections are much smaller, even together, than the full detail high-zoom section, but still not necessary if you ask me.

Harry

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mikolaj Machowski]

I wll put my own .02 c here. What is most... awkward for me is no caching. OSMand doesn't cache nearest neighboring[1] screens and not even areas viewed several seconds ago.

Try moving half a screen with your digit and moment later move back. Displayed back areas are rendered from null. It would make sense with constantly updated on-line maps but with offline data?

Even with plethora of data in OSM building cache on even middle grade phones/tablets shouldn't be problem.

[1]
in below example assume '5' is your current screen. As soon as possible OSMand should load 1-4, 6-9 to memory and prepare for instantanous display.

123
456
789

Strategy could  be modified in certain situations, eg. when in navigaton  mode 'current screen' could be '8'.

m.

[Stefan Monnier]

> Try moving half a screen with your digit and moment later move back.
> Displayed back areas are rendered from null.

Yes, there's a lost optimization opportunity here, indeed.

> It would make sense with constantly updated on-line maps but with
> offline data?

Note that labels (like street names) can more or appear/disappear
depending on lots of things beside the resolution: it often happens that
I temporarily see a label (or part thereof) on a building or a street
only to see it disappear when I slide the map (same resolution) to try
and see it better.

So I think that's one of the reasons why maps aren't cached. But I think
it would be good to fix this "label movement" issue, and not only
because it would make caching easier.


Stefan

[MAx1234 Ita]

I agree with Harry and Mikolaj: multi-thread would speed up the rendering. One or more threads might be used to implement caching, which would also help a lot.
Unfortunately I'm not a developer and I don't know how these features would impact on the code, but if they could be done it would be very appreciated by most of the users... I think.

Best regards,
Max - Italy

[Peter B]

Fully agree!
Peter - Germany :-)

[JeCh]

This issue is brought up basically every few months but no improvement was done over last couple of years. There is still no HW rendering and no multithreading.

Osmand is now at least in Europe disqualified as a car navigation since id doesn't have any information about traffic and other navigations (such as Google, HERE or Waze) can guide you much better. Still Osmand is great for bike or hiking. But not usable for cars because the very slow rendering and the lack of traffic information.

[Stefan Monnier]

> Osmand is now at least in Europe disqualified as a car navigation since id
> doesn't have any information about traffic and other navigations (such as
> Google, HERE or Waze) can guide you much better. Still Osmand is great for
> bike or hiking. But not usable for cars because the very slow rendering and
> the lack of traffic information.

FWIW, here in Montreal my experience (with my wife giving me Google's
route recommendations while I rely on Osmand and local knowledge of the
usual traffic patterns) is that traffic info is overrated.

It might be helpful when you know how to combine it with your own
knowledge of the usual traffic patterns, or if you're in an area you're
not familiar with, or when there's something really unusual going on,
but in most cases I find Google's route is between worse and no-better
than the one I ended up taking or that I would have taken.


Stefan

[Jack Burke]

With respect to routing and traffic, my experience has been that, absent a traffic incident, OsmAnd usually gives me the same route as Waze or Google. I've run them side by side for comparison on several occasions. There will sometimes be some slight variations, but those seem mostly due to a difference in road classification.

I do hope that the OsmAnd devs will work in traffic at some point, like Maps.me has done, but when then it would be of limited use to me, since I usually run OsmAnd on my old SGS 4, which doesn't have cellular service any more.

Getting multicore support in OsmAnd would be a great improvement, not just for rendering, but also for route calculation.

-jack

[Harry van der Wolf]

With regard to traffic, but not as in traffic information: 

If you look at routing inside bigger cities, there is no navapp better than OsmAnd when it comes to calculating the right travel time.

OsmAnd is the only one with speed penalties for traffic lights, cross roads, pedestrian crossing and so on. It is the only one who gives correct travel time, but unfortunately it does indeed not include traffic congestion.

And unfortunately: the rendering in cities with much details, is then again too slow.

[Mikolaj Machowski]

Agree with Stefan that traffic info is overrated - at least with free services like Google. Whatever I could have gained with traffic info was lost due to worse overall route suggested by Google Maps.

[JeCh]

I don't have much experiences with Google maps but I use Waze all the time. It gives far better results then any offline navigation. The big advantage is that it knows how fast you can really go on each road. It also has statistics how it usually differs during the day and it also takes into account current situation.

Osmand has none of these information. It has no idea if the road it sends me to has a terrible surface and I can not go faster then 50km/h ot if the same type of road is nice with low traffic, perfect surface and I can go 100 km/h without any problems. The routing of Osmand gives pretty bad results. It is not that bad in cities but on longer distances, it is not a good idea to follow it.

The current traffic situation might be useless in places with good traffic infrastructure. But in my country it is very bad and there are traffic jams all the time. I really need to know if there are any problems in front of me. I use Waze daily even if I go to/from work because it can save me some time even on the way I perfectly know.

[Tijmen Stam]

On Tuesday, December 19, 2017 at 12:24:28 AM UTC+1, Michał Musiałowicz wrote:

Unfortunately rendering speed is, being polite, only satisfactory. Or maybe slightly below.

I have noticed this too, but only when manually browsing the map (or first opening OsmAnd).

While driving, it slowly follows where I am (I have autozoom on) and I almost never see the map move and have an area not rendered yet in view.

What Mikolaj Machowski was suggesting is, I think, already happening, but only about 1/3 outside the viewable area.

As to the rendering speed, I am a very heavy user (usually have the "more details" and most of "public transport" options on, + altitude lines and hillshade over/underlays.) At times, the rendering is annoying, but the detail advantage over tomtom or Google more than compensates that.

[Eugene Muzychenko]

On Tuesday, December 19, 2017 at 6:24:28 AM UTC+7, Michał Musiałowicz wrote:

Unfortunately rendering speed is, being polite, only satisfactory.

I don't want to be polite and say that rendering speed is terrible. Last OsmAnd+ versions on my 6-core 1.8 GHz Qualcomm phone work much slower than versions from 2012-2013 on my old 4-core 1.2 GHz MTK one.

In big cities like Paris, Roma, Milano etc., OsmAnd+ is almost unusable in real time because rendering delays (occuring after scale changes and similar events) are incredibly long.

And the rendering consumes very much CPU resources, draining the battery and raising phone's temperature to a dangerous level. After two months of everyday driving with OsmAnd+, the battery in my phone became inflated.

As correctly mentioned, OsmAnd+ draws much more details than really needed.

In most cases, detailed map is needed only near a current point (or near center of the screen). The more far from the "focus", the less details should be drawn. Google Maps utilizes such technique and works fast and not CPU-intensive. But it cannot be fine-tuned.

[Lennert Bakker]

Op dinsdag 19 december 2017 00:24:28 UTC+1 schreef Michał Musiałowicz:

I tried Magic Earth, MAPS.ME, MapFactor Navigator, Sygic GPS Navigation, Galileo and few others which I deleted too quickly to memorize their names.
It would be great to see improvements in this area some day but for now could someone advise any solutions? Am I missing something? Or is OsmAnd simply slow-ish?
Regards,
Michal

I also tried a few apps and I found that Osmand maps have more of the original OSM information in their maps. So that's what's slowing it down. As suggested by Majka you could deactivate maps you don't use it will speed up things. I would hate if the maps would be symplified to a TomTom level.

[JeCh]

The amount of details is only one of the many reasons why rendering in Osmand is so slow. The other reasons are that the engine uses only one core of today's standard 8 core CPUs. The second even more important reason is that the rendering is SW only. It doesn't use the extremely powerful GPU of our phones at all. The rendering speed could probably be many times faster without loosing any details if these 2 features will get implemented.

Other optimizations like displaying lees details when using car navigation would help too.

Best regards,
Vladimir

Dne pátek 27. dubna 2018 13:39:04 UTC+2 Lennert Bakker napsal(a):

[Adrian Molloy]

I am not a techie, I used Osmand to tour Portugal and Spain on my motorcycle last year using an old Samsung Tablet as my SatNav running  Kit-Kat 4.4.2 and 2gb of Ram, rendering was slow but acceptable, often Osmand lagged 100m behind my actual position,  I was following a trail loaded into favourites.  Every couple of hours the Tablet would freeze and I had to perform a reset, probably filled up the cache.

I now have a new Samsung phone with 6gb of Ram and Osmand is much faster with smooth scrolling on tight curves and roundabouts.  So performance is related to the hardware of your device.  I have used expensive Garmins that lag 400m behind riding under trees in similar conditions.  Osmand is a great app in my opinion, full detailed Topo maps with loads of options.  

Regards

Adrian

--

You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adrian Molloy

[Germano Massullo]

OsmAnd in crowded areas is un-usuable. I really love OsmAnd features, but it is impossible to use it. Maps.me works very, very much better, real hardware rendering, etc. Since it is opensource, OsmAnd developers could take its rendering engine and use it in OsmAnd...
Maps.me source code: https://github.com/mapsme/omim

[Eugene Muzychenko]

On Friday, April 27, 2018 at 6:39:04 PM UTC+7, Lennert Bakker wrote:

Osmand maps have more of the original OSM information in their maps. So that's what's slowing it down.

Amount of displayed information should me more configurable. To simplify user interface, there might be more deep hierarchy, novice/normal/expert mode etc. And adaptive details density might be used: more details around current position (or center of the screen), less details away from it.

As suggested by Majka you could deactivate maps you don't use it will speed up things.

 It is not possible in some cases. For example, France map consists of 13 regions while only 3-4 are required on a regular basis. But I need to have road-only map of entire country to driver between usual regions through unusual ones.

It should be not hard to add a setting to control rendering of overlapping maps: "local only", "local above common", "common only".

[Pere Pujal i Carabantes]

El 28 d’abril de 2018 9:14:56 CEST, Eugene Muzychenko <emuzy...@gmail.com> ha escrit:
>On Friday, April 27, 2018 at 6:39:04 PM UTC+7, Lennert Bakker wrote:
>
>Osmand maps have more of the original OSM information in their maps. So
>
>> that's what's slowing it down.
>>
>
>Amount of displayed information should me more configurable. To
>simplify
>user interface, there might be more deep hierarchy,
>novice/normal/expert
>mode etc. And adaptive details density might be used: more details
>around
>current position (or center of the screen), less details away from it.
>
>As suggested by Majka you could deactivate maps you don't use it will
>speed
>> up things.
>>
>
>It is not possible in some cases. For example, France map consists of
>13
>regions while only 3-4 are required on a regular basis. But I need to
>have
>road-only map of entire country to driver between usual regions through
>
>unusual ones

This would not be a problem if the world overview map contained enough info as to route over the main roads it displays, don't know how doable is this?

Pere

>
>It should be not hard to add a setting to control rendering of
>overlapping
>maps: "local only", "local above common", "common only".

--
Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la brevetat.

[Eugene Muzychenko]

On Friday, April 27, 2018 at 7:12:03 PM UTC+7, JeCh wrote:

engine uses only one core of today's standard 8 core CPUs.

I have no tool to display load of all six cores in real time, but OsmAnd quickly makes my phone extremely hot. No other app (except of benchmark/stress ones) causes comparable heating. So I'm afraid it loads all (or almost all) cores at the same time.

rendering is SW only.

Rewriting rendering code from SW to HW is obviously a complex work but SW rendering isn't a global problem. Many applications use SW rendering to display dynamic images with comparable complexity but they don't consume so much CPU power. I think the main problem is very high map detailing.

So we need a way to flexibly control map detailing, allowing both easiness for novices and fine-tuning for experts. For experts, there might be individual settings to define POI classes, properties, distance etc., and there might be predefined sets of such settings for novices.

  The rendering speed could probably be many times faster without loosing any details if these 2 features will get implemented.

Even it is possible, advanced map detailing control is needed because it is often too hard to have enough details but clear view. With many details, the map becomes unreadable on any scale except very large ones.

[Eugene Muzychenko]

On Friday, April 27, 2018 at 8:37:22 PM UTC+7, Adrian Molloy wrote:

I now have a new Samsung phone with 6gb of Ram and Osmand is much faster with smooth scrolling on tight curves and roundabouts.  So performance is related to the hardware of your device.

Performance and smoothness themselves are not only problems. Extreme use of CPU power causes extreme CPU heating. Permanently hot CPU means a hot device, hot device means a hot battery, hot battery means a risk of burning/exploding.

[Eugene Muzychenko]

On Saturday, April 28, 2018 at 2:32:02 PM UTC+7, Pere Pujal i Carabantes wrote:

This would not be a problem if the world overview map contained enough info as to route over the main roads it displays

If I understand correctly, OsmAnd does not handle overlapping maps a special way. If a local region map overlaps world/country map, both are rendered simultaneously. So there should be a setting to control rendering of overlapping maps.
 

[Germano Massullo]

Il 28/04/2018 10:02, Eugene Muzychenko ha scritto:
> Permanently hot CPU means a hot device, hot device means a hot
> battery, hot battery means a risk of burning/exploding.

Phone manufactures do heavy tests about overheating, so there is no any
risk of exploding if you just use 100% CPU power

[Harry van der Wolf]

This is not correct.

Below zoomlevel 11 the worldmap is used, meaining that the worldmap is rendered.

Zoomlevel 11 is some  ïntermediate level

If you use inspector on a map you will see the following (note that Bregenz is a map I made myself from a subpart of Austria. I only needed that part and didn't want entire Austria):

Binary index Bregenz.obf version = 2 edition = Tue Jan 23 10:44:28 CET 2018

1 Map data Bregenz - 8086663 bytes

1.1 Map level minZoom = 15, maxZoom = 22, size = 4950445 bytes 

Bounds (left top - right bottom) : 9.5506, 47.5999 NE - 10.2402, 47.2221 NE

1.2 Map level minZoom = 13, maxZoom = 14, size = 1819459 bytes 

Bounds (left top - right bottom) : 9.5506, 47.5999 NE - 10.2402, 47.2221 NE

1.3 Map level minZoom = 12, maxZoom = 12, size = 916619 bytes 

Bounds (left top - right bottom) : 9.5506, 47.5999 NE - 10.2402, 47.2221 NE

1.4 Map level minZoom = 11, maxZoom = 11, size = 377007 bytes 

Bounds (left top - right bottom) : 9.5506, 47.5999 NE - 10.2401, 47.2222 NE

So every zoom level uses its own  of detail.

You can see on the sizes of the several 1.4 to 1.1 levels that the amount of details increases.

Note also that I only showed the map levels here. The routing, POI and Address sections do not come in levels.

W.r.t. to rndering speed (or actually the opposite of it). I no longer use OsmAnd for car navigation. I do use it for cycling and hiking as the level of details in the OsmAnd maps is without compare to others and rendering speeds can be low on cycling or hiking speeds.

I still follow OsmAnd very closely and occasionally I use it in the car. In that case I always use the "roads-only" maps. They contain far less details (are also much smaller) and render 2-4 times as fast. Then the rendering speeds are acceptable (but still not good).

Harry

[Harry van der Wolf]

And what I forgot to mention: Do not use active overlaying maps. Say you have the map of entire Netherlands and a map of a subsection (province). If you have both maps active, so full Netherlands and the region you are currently in, BOTH(!) maps are rendered, giving you another reduction in rendering speed. Same of course when using the France Brittany full map and the France Brittany roads-only map, so having both active.

Having one map active and the other inactive is fine.

Harrt

[Eugene Muzychenko]

On Saturday, April 28, 2018 at 4:10:00 PM UTC+7, Germano Massullo wrote:

Phone manufactures do heavy tests about overheating, so there is no any
risk of exploding if you just use 100% CPU power

I already mentioned that after two months of everyday driving with OsmAnd+ that kept the phone very hot, native battery in my Xiaomi RN3P became inflated. Screen was significantly curved and two plastic clips of back cover were broken. Maybe there was no explosion risk but I had to replace the battery to avoid damaging of entire phone.

[Germano Massullo]

Argh....

[Harry van der Wolf]

Actually this discussion is already years and years old and comes back about every year.

The slow rendering speed was "introduced" somewhere between OsmAnd version 1.5-1.8.

Note:

- Although the number of details have gradually increased over the years, it is not the big issue

- Being single-threaded is NOT the issue

- Having software rendering is NOT the issue.

Somewhere in 1.5-1.8 the personal virtual zoom level has been introduced. Before that time rendering speed was just fine.

This virtual zoom level is in the Settings -> Configure Map -> Map Magnifier.

OSM uses the several zoom levels in the maps ranging from 1-22.

OsmAnd uses auto-zoom depending on the speed, like many other nav apps.

However, some users like to see a 200x200 meters area, whereas others like the overview and want a 5000x5000 meters area on their screen.

That's why OsmAnd introduced the "virtual level", the "Map Magnifier", somewhere in version 1.5-1.8. You see it happen on the map when zooming in/out.

The first number you see is the OSM level, the second number your personal "virtual Map Magnifier" level. You see something like "12 3" for 100% or "12 12" for 400% or "12 0.9" for 33%.

This personal Map Magnifier zoom level, which you can set from the settings, was of course a big enhancement / qualifier / feature compared to other apps which only know one (auto)zoom level.

Unfortunately, this was at the same time the introduction of the slow rendering. Every object needs to be rendered twice.

Even if you select a 1:1 ratio (100%), still every object has to be calculated twice before rendering (although I do not know the exact algorithms/calculations behind it as I'm not a java programmer).

In the previous yearly upcoming mail threads about this object I have repeatedly asked for a "switch off double rendering" setting. It has never been done (which I don't blame the programmers for. I'm only one user and it is open source. If I could write a great piece of code doing this, I had already done it).

This "long story" to give some more background info to users who do not use/know OsmAnd as long as I do.

Harry

[Germano Massullo]

Il 28/04/2018 12:35, Harry van der Wolf ha scritto:
> - Having software rendering is NOT the issue.

More info about this?

[Harry van der Wolf]

What do you mean exactly?

Unless I should have stated it otherwise like:  - The current software rendering is not the issue, although hardware rendering would probably give a smoother experience (not necessarily faster as what most people think).

Hardware rendering is often overrated.

To be able to use hardware render you also need a multi-threading application to be able to split off part of the graphic or calculation work to the GPU. 

Personally I would want, in the following order:

- Get rid of the multi-zoom double layer rendering, or have an option to switch it off.

- Make the app multi-threaded, also to improve the bi-directional A* navigation (re)calculations.

- Add hardware rendering.

Note also: I also use Mapfactor Navigator, which is fast in every aspect and light on memory use, but has low detailed maps when it comes to cycling or hiking. MNF has a setting to choose between hardware or software rendering, but on hardware rendering it even makes the phone (or Joying Android head unit in my car in my case) warmer. MNF on hardware render runs approximately 10 C higher than on software render.

Also note that some phones really run warmer (extremely hot) than others. I have had several phones where some run a lot hotter than other doing the exact same tasks (incl. OsmAnd).

[Eugene Muzychenko]

On Saturday, April 28, 2018 at 4:19:08 PM UTC+7, Harry van der Wolf wrote:

So every zoom level uses its own  of detail.

Now level-to-detailing relations are hardcoded using intuitive, empirical rules not suitable for any map. With the same zoom level, one map looks blank but other one looks overdetailed. So it would be better to have such relations configurable, dependent of personal preferences, device performance, area type etc.

[Eugene Muzychenko]

On Saturday, April 28, 2018 at 4:24:02 PM UTC+7, Harry van der Wolf wrote:

Say you have the map of entire Netherlands and a map of a subsection (province). If you have both maps active, so full Netherlands and the region you are currently in, BOTH(!) maps are rendered, giving you another reduction in rendering speed.

Such behavior is definitely incorrect. Since many regional maps are big, for active travelers it is normal practice to have a world overview map, road-only county map, and full maps for each regularly visited region. Having only some regional maps is inconvenient because there is no map while driving between usual regions through unusual ones.

As I mentioned earlier, there should be a setting to control map preference. By default, it is obvious that only most specific map must be rendered.

[Eugene Muzychenko]

On Saturday, April 28, 2018 at 5:35:28 PM UTC+7, Harry van der Wolf wrote:

The first number you see is the OSM level, the second number your personal "virtual Map Magnifier" level. You see something like "12 3" for 100% or "12 12" for 400% or "12 0.9" for 33%.

Where can I see such numbers?

In the previous yearly upcoming mail threads about this object I have repeatedly asked for a "switch off double rendering" setting. It has never been done

Obviously, developer's attitude is very strange. It may be hard to code some features that require additional logic, calculations, drawing etc. But adding configuration settings instead of hardcoded values/modes is easy for any programming language. So OsmAnd could be much more flexible with no significant work.

I could perform some improvement myself but I never tried Android and/or Java development, having experience in C++/C/Asm only, mainly under Windows. I could pay a reasonable amount to support such improvements but I cannot understand developers' attitude.

[Harry van der Wolf]

2018-04-28 17:06 GMT+02:00 Eugene Muzychenko <emuzy...@gmail.com>:

On Saturday, April 28, 2018 at 4:24:02 PM UTC+7, Harry van der Wolf wrote:

Say you have the map of entire Netherlands and a map of a subsection (province). If you have both maps active, so full Netherlands and the region you are currently in, BOTH(!) maps are rendered, giving you another reduction in rendering speed.

Such behavior is definitely incorrect. Since many regional maps are big, for active travelers it is normal practice to have a world overview map, road-only county map, and full maps for each regularly visited region. Having only some regional maps is inconvenient because there is no map while driving between usual regions through unusual ones.

As I mentioned earlier, there should be a setting to control map preference. By default, it is obvious that only most specific map must be rendered.

-- 

Whether it is corect or not, that is how it works. I don't like it either. When still using only a phone I had several maps. When travelling from the Netherlands to France, Brittany I activated the roads-only maps and deactivated the full maps.

Once arrived in France, Britaany I deactivated the roads-only map and activated the full-detail map.

Note that the world maps contains so limited data it doesn't make a difference and as far as I know it is the only map not being used in zoomlevels over 11.

When you press the plus/minus buttons on the bottom right side in the map, the numbers are shortly displayed in the bottom-left of the map.

I'm not a java programmer(although I know the basics and can read code), so I can't say. Note that by now OsmAnd is the most comprehensive navigation program available. More functionality, details and so on then any other program. So yes: I really do believe that the program contains some real complexity if not only an overwhelming number of lines of codes in both C++ as well as in java.

If you are a C++ coder then please get familiar with the code in https://github.com/osmandapp/OsmAnd-core. That's all C++ and contains the core functionality (hence the name :) ) of both the Android as well as the IOS part. (The rest of IOS is of course C++).

[Eugene Muzychenko]

On Sunday, April 29, 2018 at 12:26:23 AM UTC+7, Harry van der Wolf wrote:

When travelling from the Netherlands to France, Brittany I activated the roads-only maps and deactivated the full maps.

Once arrived in France, Britaany I deactivated the roads-only map and activated the full-detail map.

Of course, it is possible but it is a very ugly solution. Suitable as a last chance way but obviously not as normal usage way.
 

When you press the plus/minus buttons on the bottom right side in the map, the numbers are shortly displayed in the bottom-left of the map.

There are no such numbers in my OsmAnd+ installation, I never saw them on the map. Maybe you have some extensions and/or hidden settings changed.

Note that by now OsmAnd is the most comprehensive navigation program available.

Surely. All the more annoying that there is no way to tune hardcoded defaults. For example, Windows always had many non-optimal defaults too but most of them can be easily changed via the registry.
 

I really do believe that the program contains some real complexity if not only an overwhelming number of lines of codes in both C++ as well as in java.

Surely. But in any language, it is very easy to replace a constant with a variable obtained from the existing database. So making hardcoded values configurable would not need much work.
 

If you are a C++ coder then please get familiar with the code in https://github.com/osmandapp/OsmAnd-core.

Unfortunately, that doesn't make sense. To implement changes we discussed, I first should get familiar with Android development environment, install and configure it, get familiar with source code set, then make the necessary changes, get the code compiled, debug it on different emulated environments and real devices. I never tried programming for Android so the main problem is the "entry price". If OsmAnd was Windows software, things would be much simpler.

[Harry van der Wolf]

2018-04-29 6:53 GMT+02:00 Eugene Muzychenko <emuzy...@gmail.com>:

On Sunday, April 29, 2018 at 12:26:23 AM UTC+7, Harry van der Wolf wrote:

When travelling from the Netherlands to France, Brittany I activated the roads-only maps and deactivated the full maps.

Once arrived in France, Britaany I deactivated the roads-only map and activated the full-detail map.

Of course, it is possible but it is a very ugly solution. Suitable as a last chance way but obviously not as normal usage way.
 

In principle I do agree, but is it really that bad?

In the old days I used my paper BeNeLux (Belgium/Netherlands/Luxemburg) map and my paper France map to drive to my destination in Southern France. No unwanted details, just big fast roads to my destination.

Once there I put those away and used a regional Michelin map to be able to look at the details.

Switching between roads-only maps and one full regional map on my destination is effectively the same and activation/deactivation really takes 20-30 seconds in total. We are simply not used to that anymore, but I actually only want all the OsmAnd details when biking or hiking.

So actually I don't mind that much. And what's more: I don't like the over-detailed full maps for car navigation.

[Peter B]

@Harry, FULLY agree.
Maybe we meet some day in south france.
Maybe we already did :-)
Will be in Languedoc during next german pentecost holydays.
Regards Peter

[Eugene Muzychenko]

On Wednesday, May 2, 2018 at 2:13:02 AM UTC+7, Harry van der Wolf wrote:

In the old days I used my paper BeNeLux (Belgium/Netherlands/Luxemburg) map and my paper France map to drive to my destination in Southern France. No unwanted details, just big fast roads to my destination.

Once there I put those away and used a regional Michelin map to be able to look at the details.

With paper maps, it is quite normal because they cannot change themselves without your help. :) But electronic maps can, and should do.
 

Switching between roads-only maps and one full regional map on my destination is effectively the same and activation/deactivation really takes 20-30 seconds in total.

Of course it is possible. But it is a wrong way by definition. Can be uses as a workaround but never should be used as a normal practice.

BTW, I tried to deactivate World overview and France roads-only maps but Paris map rendering was still terribly slow, almost no difference.

I don't like the over-detailed full maps for car navigation.

 We need to control map detailing to have the best one in each possible situation. For example, if we need to just drive through a town, we need only map of main roads. But if we are traveling by the family and want to eat in a good cafe, purchasing some fuel too, we need to see all cafes and fuel stations on the map.

[Harry van der Wolf]

You are confusing map details with POIs. The Roads-only maps contain the same number of POIs , address data, transport data and routing data as the full maps.

If you look at TomTom, Here, Mapfactor Navigator: They contain far less data. Less data is less objects to be rendered and much smaller files to be read and parsed.

It's a pity that you do not notice a difference between roads-only maps and full maps. It has no use at all to disable the world map by the way as I explained a few posts ago.

If you switch on the developer plugin, you can also enable debug information for the rendering.

 Especially in cities I notice a big difference in "Searching" and "Rendering". I have tested this on at least 10 devices, on several ARM and intel CPU architectures.

The differences get smaller when you drive out of town on a long highway with not much changing details in the surrounding. There full maps and roads-only maps do not differ much. Again the difference gets big when you are on a curvy road with a lot of small details like a lot of small fields, small forests, small lakes and rivers, etcetera.

But as mentioned: especially in cities the difference between full maps and roads-only maps is the greatest.