Anyone has positive experience with OsmAnd on 512 MB RAM?

[Michael Cat]

Hi all,
I have permanent troubles with OsmAnd installed on old car navigator with 512 MB RAM and Android 4.0. Program crashes or freezes or displays "not enough memory" almost every time I run it. I want to buy another navigator with newer Android 4.4 and faster CPU, but I noticed that all nonexpensive navigators have only 512 Mbytes of RAM. Can anyone tell me how OsmAnd works on devices with Android 4.4 and 512 MB?

[Poutnik]

I suppose unless A4.4 uses some RAM content compression, what I strongly
doubt,
the experience determined by RAM size and not OS level.

I use Sony Xperia M Dual with A4.3 and 1 GB RAM.
Even 1 GB is not much, 512 MB is very small.

Personally I consider OSMAnd as quite RAM demanding.
I often use listening mp3 podcasts in PodcastAddict on background,
when navigating as a hiker of on bike on car-less tracks.

While it works quite well with LocusMap,
wit OSMAnd it seems PodcastAddict to get killed often,
probably to free the RAM.

Dne 22/12/2015 v 12:47 Michael Cat napsal(a):

> --

[Richard Goodwin]

Is the Roads-only map available for your location? 

These contain much less detail, so may render on a device with limited memory?

If you are just using Osmand for car navigation, this may be sufficiently-detailed for your requirement?

I believe you will have to delete the normal, detailed map, or both will be displayed.

Richard

[Harry van der Wolf]

I used to have a dual core 1.2 GHz 512 MB 800x480 phone and OsmAnd was too slow on it. Calculation of distances above 300 km were not possible. Calculation was dead slow. Rendering of the map in car navigation in towns was way too slow.

I changed the heuristiccoefficient in the Routing.xml to 1.3, which improved speed of routing and length of routing enormously. Calculations are up to 3-4 times as fast and routes up to 800-1000 km could be calculated. There is absolutely no reason to keep it at the default 1.0 as OsmAnd is doing, but you shouldn't go above the 1.3 either as you might get inaccuracies in routing. There are lots of (scientific) articles to find on the web dealing about shortest path algorithms, the A* algorithm (used by OsmAnd) and the influence, accuracy and speed of calculcation of the heuristic coefficient on those calculations.

In short: a heuristic coefficient of 1.2, 1.25 or 1.3 works miracles on your route calculations. This is the same for recalculations where OsmAndcan be (too) slow in cities.

The new roads only maps contain the full addresses and POIs of the normal maps, but not the landscape details. In the few occasions I still use OsmAnd for car navigation I use the roads-only maps even though I'm now on a much faster phone. 

I know that xmd5a2 mentioned earlier that the amount of rendering objects only influenced the rendering by only 10-15%.

My personal experience with roads only maps versus full maps is a factor 3! in rural areas. On highways outside cities the influence is much smaller, like up to 1.5x.

I did navigations in cities with logging and screen debugging on and full screen rendering changed from an average of 300 milliseconds for roads-only maps to a 800-1000 milliseconds for full maps. At that moment I changed to roads-only maps for car navigation.

I currently use another app for car navigation.

For cycle and hiking I still think OsmAnd is the best, also on older phones (slow changing maps when hiking or cycling do not require much performance).

And like Richard mentions: Never use 2 maps at the same time. The maps are overlayed in OsmAnd which calculation times as all roads in all maps are used for a specific route calculation. Same for rendering: both maps will be rendered and overlayed.

This is valid for full map and roads-only map, but also for a regional map used in a full country map.

So in short: Use a heuristic coefficient of 1.2-1.3 and use roads-only maps without at the same time mixing with other maps on older phones.

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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Harry van der Wolf]

Hi,

Something went wrong in the one but last paragraph:

And like Richard mentions: Never use 2 maps at the same time. The maps are overlayed in OsmAnd where calculation times will really double as all roads in all maps are used for a specific route calculation. Same for rendering: both maps will be rendered and overlayed.

This is valid for full map and roads-only map, but also for a regional map used in a full country map.

Harry

[OA]

On Sunday, December 27, 2015 at 1:47:02 AM UTC-8, Harry van der Wolf wrote:

I changed the heuristiccoefficient in the Routing.xml to 1.3, which improved speed of routing and length of routing enormously. Calculations are up to 3-4 times as fast and routes up to 800-1000 km could be calculated. There is absolutely no reason to keep it at the default 1.0 as OsmAnd is doing...

@Harry,

Where the "routing.xml" is located? Is it in "./osmand/routing" folder? I don't see it in my setup...

Should making this small "routing.xml" file be enough to test that?

<?xml version="1.0" encoding="utf-8" ?>
<osmand_routing_config defaultProfile="car">
 <routingProfile name="car" baseProfile="car" restrictionsAware="true" minDefaultSpeed="45.0" maxDefaultSpeed="130.0"
 leftTurn="5" rightTurn="5" roundaboutTurn="5" onewayAware="true">
 <attribute name="heuristicCoefficient" value="1.3" />
 </routingProfile>
</osmand_routing_config>

I'd appreciate some details how to check it. Also, are the "..Speed" attributes there in "km/h"? What if I use "mi/h"? How to set it properly?

Thank you in advance :)

[Harry van der Wolf]

The routing.xml is located in the /Android/data/net.osmand.plus/files folder.

net.osmand in case of Osmand Free, net.osmand.plus in case of a paid version of OsmAnd.

Please find attached my routing.xml

It is best to reboot your phone after copying the file into the folder.

Harry

--

[Harry van der Wolf]

And this time with the routing.xml really attached.

Harry

[Harry van der Wolf]

I don't seem to be able to do anything right the first time in this mail thread.

I reread my earlier mail and see another mistake. I mentioned "My personal experience with roads only maps versus full maps is a factor 3! in rural areas."

This should of course be "My personal experience with roads only maps versus full maps is a factor 3! in urban areas."

<sigh>

Harry

[Poutnik]

Note that 1.2-1.3 is the typical car-roads stochastical factor** of
ratio of lengths of a route and a straight line. Astar algorithm uses a
closely related heuristic coefficient to make optimistic estimation of
cost of not yet analysed rest of the route. Therefore values 1.0
-1.2(1.3) are more or less safe****. If the coefficient is higher than
partial route segment cost***/straight length ratios, it starts to
prefer suboptimal routes. In such cases it may prefer otherwise worse
partial routes , but with ending point closer to destination.

Good idea about how the heuristic coefficient affects the Astar routing
can gain users of BRouter. If you set the pass1coeeficient in the
Brouter profile you can watch graphical display of the routing progress
in the Brouter 1st pass. Brouter uses usually values 1.5 up to 2.2* to
speed up the 1st pass, as good result is well backed up by the 2nd
pass. The 2nd pass ( can be disabled ) uses Dijkstra with cutting away
all nodes without chance to provide route than 1st pass.

BTW, I use OSMAnd for car navigation, while for bike and hiking I use
other application, more suited for outdoor activities.

* Way classes, surface conditions and elevation differences are often
projected to high ratios of cost/straight-length, so the 1st Brouter
pass can afford higher values of the coefficient.
** for hiking it will be higher, as paths are more winding that motorways.
*** way cost is <= way length, for optimal ways they are usually equal.
**** It can still fail to prefer the route with not yet discovered
longer good road toward desrtination.

Poutnik

[Harry van der Wolf]

2015-12-28 12:00 GMT+01:00 Poutnik <poutni...@gmail.com>:

  Therefore values 1.0
-1.2(1.3) are more or less safe****.  If the coefficient is higher than
partial route segment cost***/straight length ratios, it starts to
prefer suboptimal routes.  In such cases it may prefer otherwise worse
partial routes , but with ending point closer to destination.

I fully agree with you. That's also why I said not to go above 1.3.

I have done numerous tests for short routes, medium routes, long routes, and inside/through small/medium/big cities.

On long trips it doesn't make a difference anyway. The algorithm leads you from your destination (in a city?), over a multitude of motor/primary/secondary roads to your destination (again in a city?).

Inside cities with numerous roads, crossroads, etc. you see sometimes small differences in routing and most of the time the calculated values, in routes of 15-25 minutes, are less than 30-60 seconds. We all know that especially in cities the traffic conditions like traffic lights, number of intersections, crossroads, roundabouts, etc. determine your end time, which sometimes (often) lead to a longer road being much faster (same for fastest versus shortest route).

Also with the first example: city-"long in between section"-city. You calculate a route of 3-8 hours and you see a 30-60 seconds!! difference due to slightly different routes in the beginning and at the end: Who cares about 30-60 seconds on a 4-8 hours trip. Especially as these calculations are done in "optimal circumstances" where we also know that traffic conditions are of bigger influence. Nav apps who incorporate traffic info sometimes calculate other routes as well.

Note that you hardly ever see differences in the long stretches. (And if you have to wait in a long queue before the gas station pumps and then again for the gas station toilets on your holiday trip, these 30-60 seconds don't count anyway :)  )

Next to that: due to the 1.0 coefficient of OsmAnd you sometimes can't even calculate a long(er) route and need to set waypoints. This really completely breaks your "perfect 1.0 algorithm". It forces you to position a waypoint where you think is the best position. That is complete rubbish and makes your "perfect 1.0 algorithm" useless. To me this is an utter design flaw.

Anyway: Everyone should pick the best option for him/her self where he/she feels most comfortable with.

And I must admit that the 2.1 versions show a big improvement in route calculation times.

Harry

[Poutnik]

I think you have not fully understood my comment .... :-) The
intention was to supplement you, not to oppose you.

I do support >1.0 coefficients. Demanding terrains for the bike trekking
routes can afford coefficient 1.7-2.2 ( region and profile dependent )
with cost errors less than 5 percent, if only 1 Brouter pass is used in
quick profiles. I have spoken about algorithm itself, not about its
implementation nor its practical applicability in cities. I am very
well aware that Astar coeff. 1.0 puts high resource demand on
implementation, and that is why BRouter 2nd pass does not use Astar, but
Dijkstra with cutoff trick. The noticeable errors of high
coefficients ( that you do advice to avoid as well ) happen only if
significant part of a route has specific cost higher than coefficient
and if their placement is unlucky to fool the algorithm.

Do the algorithms carry my name ? No, they do not, so stop call them
like mine.. :-)

BTW, driving time is just one of many possible ways ( even if important
to cars ) to calculate route cost.

[Poutnik]

Errata
Dne 28/12/2015 v 14:18 Poutnik napsal(a):

> The noticeable errors of high
> coefficients ( that you do advice to avoid as well ) happen only if

> significant part of a route has specific cost *lower* than coefficient

[Harry van der Wolf]

Hi Poutnik,

I know that you did not "attack" me. My mail was more or less meant for those readers that are less deep into algorithms and who don't care about the algorithm itself and only want to know what the end results are on their routes.

And when I said "your", you understood me wrong :)  I didn't mean you even though you might easily conclude that from my mail (I see that now). I meant "your" as in "we all" using Osmand and therefore that algorithm. In that case "your" algorithm in "your" OsmAnd means everyone using Osmand.

Sorry for causing the confusion.

Harry

[Poutnik]

Hi Harry,

That is OK, the form of your response may have confused me.

For readers: I second to Harry to recommend the raise of the coefficient
he adviced.
Try 1.3, and if you have doubts* lower it to 1.25 or 1.2.
It will lead to faster and less resource demanding routing, especially
for long distances.

* more probable in flatlands with straight good roads, like "Go straight
ahead and on Tuesday turn right."

Poutnik

[OA]

On Sunday, December 27, 2015 at 11:41:25 PM UTC-8, Harry van der Wolf wrote:

The routing.xml is located in the /Android/data/net.osmand.plus/files folder.

net.osmand in case of Osmand Free, net.osmand.plus in case of a paid version of OsmAnd.

Please find attached my routing.xml

 

Harry, thank you for your "routing.xml" file.

I still can not find the place where to put it thought... In my Samsung Note 2, Android 4.4.2 device there is no "net.osmand" folder in "(InternalMemory)/Android/data" folder (I'm using free version). There is no such folder in "(ExtSD)/Android/data" folder either... And, as I mentioned, there is "/data/data/net.osmand" folder, but there is no "routing.xml" file in it or even in its sub-folders. So, I'm puzzled where to put it now...

[poutnik]

If I remember well, by default OSMand uses the file embedded in apk installation file, unless a user provides the external file.

29. prosince 2015 1:01:31 CET, OA <yok...@gmail.com> napsal:

--
Sent from my phone via Android email client K-9.
Please, forgive my brevity.

[OA]

Perhaps you're right. And that's why it's important to know the exact location where to put that file.

[Harry van der Wolf]

Hi,

Probably the data folders do vary on different devices. The place to put the routing.xml is in the folder that also contains the "regions.ocbf", "poi_types.xml", "ind.cache", "exception.log" (in case you had a crash), "world_basemap.obf" and possibily a number of other files as well.

Harry

2015-12-29 9:05 GMT+01:00 OA <yok...@gmail.com>:

Perhaps you're right. And that's why it's important to know the exact location where to put that file.

--

[Poutnik]

When I have reviewed the default routing.xml file within instalation of latest OSMANd 2.2.4,
http://download.osmand.net/releases/?C=M;O=D
\temp\net.osmand-2.2.4-amz.apk\net\osmand\router\

resp. master development version
Github master routing.xml

I have realized the OSMAnd uses heuristic coefficient
1.2 for pedestrian
1.5 for bicycle
1.5 for car, but this is commented out. It may relate to some abandoned routing experiments in 1.9 version.


Dne 29/12/2015 v 09:05 OA napsal(a):

Perhaps you're right. And that's why it's important to know the exact location where to put that file.

[Harry van der Wolf]

Yes, It does indeed use them for pedestrian and bicycle but not for cars.

The 1.5 for bicycles was introduced in 2.0 (as far as I can remember) after very valid arguments and examples by OsmAndtrier.

In the 1.6+ versions, when Victor developed the new routing, the heuristic coefficient was removed for cars.

Harry

[gir...@gmail.com]

         I am new and, if I can ask for your availability, I would like to resume the topic described for the file routing.xml.
     My name is Stefano and from 3 years I use a Note3 (Samsung SM-N9005, android5.0, processor 4core-2265Mz., ram 3Gb, openGL ES 3.0) with OsmaAnd free 2.2.5.
For too long time and today, I can always see the same problem discussed here.
  I have also tried the latest versions but nothing changes ( paid and free ).
Especially in car navigation, is always difficult for routing and in some cases also with very short routes.
       It seems to me that you know very well OsmaAnd and then I will ask suggestion for try to solve the problem.

If I am not in mistaken, if I put in the proper folder the file routing.xml, OsmAnd uses it instead of the internal one.
But, my problem is that I dont have the xml file for insert.

You can help me? Do you have someting to suggest me?


I thank you in advance and I apologize for my bad English.

Stefano (MR).

You can help me? Do you have to suggest somting?


I thank you in advance and I apologize for my bad English.

Stefano (MR).

[Matt Vokes]

Interesting information.  I tried on a Note 4 with standard "internal" routing formula & chose a destination approx 200 miles away.  Navigation calculation was timed at approx 1 minute.  I imported Harry's routing.xml file & this time navigation calculation was around 21 seconds.  Amending it to 1.2 gave a result of around 29 seconds. I was sure to close & kill OsmAnd+ between tests.

Although this thread is from 2015 I guess this is still relevant for current versions of OsMAnd?

Stefano, download the routing.xml file in Harry's post (8th post in the thread).  Assuming you have external SD move the file to External SDCard >Android >Data >net.osmand.plus >Files

If you want to amend the coefficient, search for "heuristicCoefficient" & look for where Harry has amended to 1.3 then adjust to 1.2 or 1.25 as you see fit. 

[gir...@gmail.com]

Hi mr.Vokes,
           you are very kind to answer me, thank you so much.

I try suggestions and quickly refer you how OsmAnd work.
         Now, OsmAnd have 2.8.2 release, after the test in my 2.2.5, I upgrade it to 2.8.2 and refer how it work.
( All releases link: http://download.osmand.net/releases/ )

Stefano
  (I always excuse me for bad English)

_____________________________________________________________

[Poutnik]

It is logical, as it is related to a typical statistical ratio
of lengths of  a route and a straight line to destination.

If the particular route ( or its segment ) has this ratio smaller,
then in some cases of road network topology and road priorities
the routing may not find the optimal route ( or for that segment).

Dne 12/11/2017 v 15:06 gir...@gmail.com napsal(a):
> Hi mr.Vokes,
> I am trying different value for heuristicCoefficient in routing.xml.
> First test result 1.2/1.3 better value as describe from mr.
>

--
Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

[gir...@gmail.com]

good morning mr.Poutnik,

 

            ok, I understand.

  Finally, with the same ROUTING.xml in 2.2.5 and in 2.8.2 nothing change;  path calculation in OsmAnd give same upshot.

As a lot of apps, OsmAnd also can get better. I think each of us has one good idea for get it better.

I have a lot of ideas!

But as is it, I think it is good.

    I can tell to all: SOLVED!

I want to give my thanks to:

  mr. Poutnik and mr. Vokes for taking care of my problem

and

  to mr. van der Wolf for making still available the routing.xml file.

Thanks to all again, all you have me helped to solve one big problem.

[ralph lumen]

I just imported the routing-file to net.osmand.plus > files on my samsung s5mini with osmand 2.9.3 and it works obviously well. thanks!

does anybody here know about the difference between the former "shortest route" and the now implied energysaving route? what should i do to get the really shortest route if i want it, including smallest roads? or where to ask this question?