Osmand routing calculation is very slow for long distance for many years

[Episteme PROMENEUR]

Osmand routing calculation is very slow for long distance for many years.

If you use for other app then no problem for example "waze"

What is the problem ? No expert in Osmand team ? Not enough devs ? Something else ?

If you use other app then no problem for example "waze"

[Paul Johnson]

Osmand is doing all the calculations on your phone.  Waze is using Google's datacenters.  One has more computing power than the other.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/ec80f605-678f-4c66-ae52-a0a5e04efb8e%40googlegroups.com.

[Episteme PROMENEUR]

"waze" is just an example. Forget it. Just reply to my question. No improvement since many years, where is the problem ? Brouter is fast why not Osmand ?

Le jeudi 5 mars 2020 15:20:20 UTC+1, Paul Johnson a écrit :

Osmand is doing all the calculations on your phone.  Waze is using Google's datacenters.  One has more computing power than the other.

On Thu, Mar 5, 2020 at 7:02 AM Episteme PROMENEUR <episteme...@gmail.com> wrote:

Osmand routing calculation is very slow for long distance for many years.

If you use for other app then no problem for example "waze"

What is the problem ? No expert in Osmand team ? Not enough devs ? Something else ?

If you use other app then no problem for example "waze"

--
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 osm...@googlegroups.com.

[Paul Johnson]

Same answer.  There's only so much computing power you can pack into the phone.  Brouter's running on a separate computer.

To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/36863f4d-c0c1-4a8e-89a0-512b0e055697%40googlegroups.com.

[Episteme PROMENEUR]

Same answer. You don't answer to the question.

No improvement since many years, where is the problem ?

[Paul Johnson]

Eliminating the correct answer as an answer you're willing to accept doesn't change the correctness of it.  Remote servers have more processing power than cellphones do.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/86746d7f-f827-485f-bb9c-9af57f413c2c%40googlegroups.com.

[John Whelan]

Brouter is fast and can be run on a smartphone.  It is dedicated to routing.  However it does take up resources so on a slower phone or one without so much memory OSMAND will still run without Brouter.

OSMAND gets the routing job done.  It might not be the fastest on the planet but it works.

Just because something has not changed for many years does not mean it needs to.

If you feel the devs are lacking in expertise then feel free to develop your own app.

Cheerio John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/86746d7f-f827-485f-bb9c-9af57f413c2c%40googlegroups.com.

--

Sent from Postbox

[Harry van der Wolf]

Almost all navigation apps are faster than OsmAnd (at least all I know and I know a lot). Also on a phone. Mapfactor Navigator is extremely fast. Magic Earth is also very fast. Etcetera, etcetera.

The computing power of the phone is not the issue. Of course it is less than the dataventers of Google and Waze.

The issue is OsmAnd and its heuristic coefficient of 1.0. Not any other application is doing that.

If I calculate a route in OsmAnd of 217 km with the default routing profile (routing.xml), it takes 1m and 6~8 seconds.

If I calculate the exact same route with my routing profile with a heuristic coefficient of 1.5, it takes 6~7 seconds to calculate

When calculating a route of 394 km, it was at 30% after 3 minutes with the original routing.xml

With my routing.xml it took 15~16 seconds.

I used to need to do some "tweaking" to make this work.

Since version 3.5.4, with a very buggy 3.5.5, and now a stable 3.6.2 you can define profiles.

Now it is a piece of cake to use another routing.xml on top of the default.

I have already written many mails about this in the past 6 years, and lately another series when profiles were introduced in OsmAnd and shared my several profiles.

So much for phone computing power and a way over the top calculation algorithm (my point ov view).

Harry

Op do 5 mrt. 2020 om 16:10 schreef John Whelan <jwhel...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/77405db7-b42e-9a47-1a63-ece742ccf644%40gmail.com.

[Arndt]

On Thursday, March 5, 2020 at 5:44:36 PM UTC+1, Harry van der Wolf wrote:

The issue is OsmAnd and its heuristic coefficient of 1.0. Not any other application is doing that.

Hi Harry,

it's not that easy. BRouter is operating at heuristic coefficient = 1.0. Going heuristic is "unconditional surrender" and leads to artefacts that can be easily detected.

I think what mapactor, waze and the like are doing are "hierachical constraints",which is about as bad, but not so easy to detect.

For BRouter I worked on 2 aspects:

- the raw "node crunching power", which is about 1 Million nodes/seconds on a server-processor-core, or 100k/second on a smartphone. This is just engeneering and tuning. You cannot compare the osmand-router with BRouter here: BRouter is working on specilized data files which are 8% in size of usual OSM data and contain the street network only, while OSMAND data are 170% of usual OSM data size.

- the other aspect is the "averge cost factor", so the ratio of average versus minimal cost, which should be close to 1 and is e.g. about 1.05 for the "car eco" profile, 1.16 for "car fast". It's important to be close to 1 here to keep the search area small.

regards, Arndt

[Florian Lohoff]

Because the growth of OSM data has been faster than Moores law. So your
CPU <> Memory interface did not improve as fast as the OSM Data grew.

If you want to calculate a route you need to consider a LOT of data
and it grows exponentially by distance.

Other routers take short-cuts like OSRM with contracted hierarchies
etc. OSMAnd OTOH uses a more conservative approach which works pretty
well and i still like the amount of tags it supports and takes into
account for routing.

So - your memory in your phone is smaller than your working set,
your CPU caches have not grown like the OSM data did so the amount
of data overflows your Phones resources. The best thing you can
do is to get slow. Swap data in and out of your main memory from
SDCard or internal flash. The alternative would be to reject the route
as being too far for your available resources and the given method
and algorithm.

The alternative to reject the route and not calculate it would be even worse.

Yes - i guess there is a lot of room for improvement but then we
talk about development resources you are overflowing.

And comparing it to other routers using probabalistic approaches is
comparing apples to peaches.

One can calculate pi to 1 Mio digits in a second as long as it does not
need to be correct.

Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

[Harry van der Wolf]

Op vr 6 mrt. 2020 om 01:41 schreef 'Arndt' via OsmAnd <osm...@googlegroups.com>:

I know there is a lot more behind the shortest path algorithms then only the heuristic coefficient. And indeed Mapfactor is using hierarchical constraints (I don't know about the others).

And yes: file size does matter but that's < 10%. (And it also matters for screen rendering. I use OsmAnds "roads-only" maps for car navigation on my Android car head unit which give 30%-300% better rendering performance as well.)

I also know that an hc=1.0 "theoretically" always leads to the fastest (sometimes shortest) route. Like mentioned: already since 2011 when OsmAnd switched from 1.5 to 1.0, I do these tests: so actually about 9 years now (like you are doing as well for Brouter, I suppose).

But the 100% theoretical "hc=1.0" route is on long distances over 150 km very often (>98%) exactly the same as the "hc=1.3~1.5" route.

For OsmAnd car (!) navigation I have tested with many hc values.

I don't believe at all in "unconditional surrender" when going away from 1.0. (And obviously neither do all those other navigation app builders.)

It all depends on the number of paths you can choose and speed difference they force on you (which is completely different for walking or cycling where the average speed is fairly constant, unless there are big elevation differences)

For cycling and hiking I always just use an hc=1.0. Simply because the distances are very often below < 50 km.

For car navigation in a big city with lots of possibilities and OsmAnds use of penalties for traffic lights and speed reducing measures, it is indeed important to stay close to 1.0.  (driving thorugh Den Haag (quite often) or Rotterdam, an hc<=1.2 does give better results, than an hc=1.5. I immediately admit)

When driving > 150 km, it is most probably some 3~8 km in town in the beginning and the end, and the rest over motorways/highways. At that moment an hc >= 1.3 and <= 1.5 works really excellent and almost always gives the exact same route as an hc=1.0

What's more: I did see that Osmand had artefacts when using 1.0 on longer routes (when I had the patience to wait 8+ minutes for the calculation to finish).

It calculated routes with longer travel times and travle distance compared to using an hc of 1.3~1.5. And other apps calculated the exact same route as my 1.3~1.5 did. Obviously because they also use a different hc, but the OsmAnd hc=1.0 route was longer and taking longer. As such I don't care whether that is a bug or not, or a memory issue (although I did file an issue for that some years ago and so did other users): The 100% theoretical calculation was simply not correct!

Again: Using the exact same OsmAnd with 1.0 and 1.3~1.5 routing profile.

And with 1.5 for example, the route might not be 100% perfect, but it is nearly perfect.

If I have to drive 800 km, and in the last 3 kilometers the 1.0 takes 2 other city roads, thereby being 10 seconds faster, I don't care at all. If I have one "wrong" red traffic light, this time reduction is already gone. Especially when having some traffic jam completely ruining this 10 seconds time reduction of an journey of 8+ hours. There are so many real world parameters influencing your real travel time. Slow trucks which on a busy day reduce your average speed drastically, a 5 minutes shorter/longer resting period after 2~3 hours drive, a calm or or very busy petrol station along the route, etcetera, etcetera.

And when there is some deviation (or you just took the wrong exit or street in a city), the 1.3~1.5 almost instantly gives you a new route. OsmAnd with 1.0 does not and is painfully slow at times.

Again: Speaking for car (!) navigation, the hc=1.0 "approach" is from my point of view for the theorists who want to be 100% theoretically correct. It is not an approach 95% (or so) of all other navigation apps programmers/companies choose having experience with what the real world does to your 100% theoretical route. (and sorry: I really don't want to offend you for using 1.0 in BRouter. I have used it quite long for cycling and I think it is excellent.)

So in short:

- I live in the Netherlands and do quite some cycling. With the dense cycle network in the Netherlands I do use the standard hc=1.0, but distances are always below 50 km (I'm a lazy cyclist)

- For driving in a big city, I use an hc=1.2

- For driving outside the city and everyday use, I almost always use hc=1.5

best regards,

Harry

 

[Harry van der Wolf]

Op vr 6 mrt. 2020 om 08:20 schreef Florian Lohoff <f...@zz.de>:

Because the growth of OSM data has been faster than Moores law. So your
CPU <> Memory interface did not improve as fast as the OSM Data grew.

If you want to calculate a route you need to consider a LOT of data
and it grows exponentially by distance.

Other routers take short-cuts like OSRM with contracted hierarchies
etc. OSMAnd OTOH uses a more conservative approach which works pretty
well and i still like the amount of tags it supports and takes into
account for routing.

Lots of data? I have created maps only consisisting of roads. They are minimal compared to OsmAnds full maps. The growth of data is in "all the rest": more detailed forests, lakes, ponds, POIs, etcetera. Also the growing addresses in OSM create a lot of data, but there there it is not applicable for the calculation. You select an address, which is then "converted" to a coordinate. From that moment you don't need the address data anymore for your calculation.

Growing data? Yes, more roads get added every day. But this data is indexed and is not really adding to the calculation time.

Longer distances? Yes, you are absolutely right. This is really the "killing" factor when using an hc=1.0. If you really need to explore every "path" in your bidirectional A* route calculation, bigger distances exponentially increase calculation time and necessary memory. That is why other nav apps do use an hc>1.

Harry

 

[Florian Lohoff]

On Fri, Mar 06, 2020 at 10:11:41AM +0100, Harry van der Wolf wrote:
> Lots of data? I have created maps only consisisting of roads. They are
> minimal compared to OsmAnds full maps. The growth of data is in "all the
> rest": more detailed forests, lakes, ponds, POIs, etcetera. Also the
> growing addresses in OSM create a lot of data, but there there it is not
> applicable for the calculation. You select an address, which is then
> "converted" to a coordinate. From that moment you don't need the address
> data anymore for your calculation.

Comparing apples to peaches. You may integrated data for display and
routing, or you only consider routing. I use OSMAnd because it displays
lots of OSM data as i can visually verify completeness.

> Growing data? Yes, more roads get added every day. But this data is indexed
> and is not really adding to the calculation time.

This data is spatially indexed and you search from A to B through
a graph. Adding more streets increases the amount of graph edges you
may need to consider and thus the size of your working set.

> Longer distances? Yes, you are absolutely right. This is really the
> "killing" factor when using an hc=1.0. If you really need to explore every
> "path" in your bidirectional A* route calculation, bigger distances
> exponentially increase calculation time and necessary memory. That is why
> other nav apps do use an hc>1.

So use a different application - Where is the problem?

[Harry van der Wolf]

Op vr 6 mrt. 2020 om 11:29 schreef Florian Lohoff <f...@zz.de>:

On Fri, Mar 06, 2020 at 10:11:41AM +0100, Harry van der Wolf wrote:


Comparing apples to peaches. You may integrated data for display and
routing, or you only consider routing. I use OSMAnd because it displays
lots of OSM data as i can visually verify completeness.

Sorry. My stupid mistake. I said roads, but I meant routing (of course).

When I said that the data is not so big, I meant the routing data.

Netherlands full map (March 2020) is 1.8GB. "Only" 125 MB of that is routing data. The rest is addresses (628MB), POI data (63MB),  some transport data (10MB) and 1+ GB of map data.

For the roads_only map the numbers are the same, apart from the map data which is only 55 MB (total obf size 709MB)

So in the these maps, the routing data is only 125 MB, which is 6~7% of the full map. (Netherlands is one of the 4 countries with complete address data. Hence the relatively large percentage)

I use OsmAnd for the exact same reason you do: because it has the most complete and detailed maps. And that is how I use it on my phone for walking and cycling.

For car navigation on my car head unit, I need all roads, POIs and addresses. That's in the roads-only maps with the added benefit of (much) better screen rendering performance and no additional "clutter" on the map that only distracts, as map data to be displayed is only 5~6% of the full map.

 

So use a different application - Where is the problem?

Exactly :).

I still use OsmAnd occasionally for car navigation as it has the best gpx-routing and "make your own route with multiple waypoints" functionality. Also for the latter an hc>1 is very beneficial.

Despite my comments and critics, I still consider OsmAnd the best, complete, allround navigation app available (and why I participate quite frequently in this mailing list). That's why I use OsmAnd with some "improvements", which can now so easily be added. Those "extras"  is what I am promoting. I am not demoting OsmAnd as such, but I give arguments  (with some bias) why OsmAnds calculation is so slow. I am already many years (11+) a big supporter of OsmAnd, but that doesn't mean I'm blind to its shortcomings (or personal different view, if you prefer)

And indeed: for all other car navigation I almost completely switched to Magic Earth, also because of the free traffic info.

But on the other hand: Because of the profiles now giving you the flexibility in routing, I now also started to use OsmAnd more often again for car navigation.

Harry

 

[Episteme PROMENEUR]

Thank you very much Florian, Arndt and specially Harry for this enlightening, complete explanation,

I like Osmand very much. Osmand is the Swiss army knife of the bike trekker tourist.

But there are 3 issues :

- the UI which is a dish of spaghettis, a labyrinth. That's one of the reasons why the learning access ramp is steep.

- the address search tool which is not very smart compared to others. I must take an anxiolitic to keep calm.

- the long distance itinerary computing. But now I know there is a hope because Harry found a solution.

About long distance itinerary computing,for bike trekking what value for hc ?

How to assign this value ?

Thanks

[ra]

me too I would like to know how to apply different HC when on the road! as there is no simple setting for that within the app ...

[Harry van der Wolf]

Op vr 6 mrt. 2020 om 15:16 schreef Episteme PROMENEUR <episteme....@gmail.com>:

About long distance itinerary computing,for bike trekking what value for hc ?

How to assign this value ?

The heuristic coefficient is always 1.4 for bike trekking, unless you make your own profile.

(So there the hc is not 1.0, like for car navigation. For pedestrian it is 1.2)

I therefore do not know if it is interesting to play with this for cycling.

See the blog post describing new features: https://osmand.net/blog

You can easily play with the profiles. The original routing.xml can be found on and downloaded from: https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml

Copy attached mycar15.xml to Android/data/net.osmand(.plus)/files/routing. Same for mycar12.xml

Make sure that they are saved as .xml. Some file managers save xml files as .xml.txt

Simply open the xml in a text editor and you see that it is only a subset for car navigation (but this can be done the same way for other like the mentioned bike trekking).

The only changes are the name of the derived profile and  the heuristic coefficient which are added in the header of the routing profile.

You can also easily modify that yourself to play with other values.

Open OsmAnd

- Settings -> Scroll down and create new profile

- Select Profile car

- Give it a name (mycar 1.5?)

- Select color and icons and save.

You are now still in your freshly created profile.

- Got to navigation settings (2nd option)

- Select Navigation type (1op one)

- Now scroll down and select the mycar15 navigation type

- Go back until your are out of the profile and you can now use it.

- Adapt it further to your liking.

Attached also a mycar12.xml. I use this one in big towns. 

[Harry van der Wolf]

hmm,

My reply between the posts of Episteme and ra is a bit obscure. Click the triple dot to open the rest (if you are in gmail).

Harry

[danilo.baggini]

I tried but no file in ..data/net.osmand/files/routing

Either in memory nor in sdcard....

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 06/03/20 15:25 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpua81CTc9h63ofzYuPqcAGO0jdY9CzayBa9E%3DWVtiF5oQ%40mail.gmail.com.

[Harry van der Wolf]

Op za 7 mrt. 2020 om 07:23 schreef danilo.baggini <danilo....@gmail.com>:

I tried but no file in ..data/net.osmand/files/routing

Either in memory nor in sdcard....

By default there are no files in that folder. You have to save the .xml files into that folder /Android/data/net.osmand(.plus)/files/routing 

Harry

 

[danilo.baggini]

I repeat:

I tried following your intruction ....

I create a new profile

but the new profile is not present in the directory....

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 07:43 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPptk%2BSUwCtyXCLwran459wve8OFcf6%2BBYRQK3NKmmdPxsQ%40mail.gmail.com.

[Harry van der Wolf]

Did you really copy the attached xml files and do the :

Open OsmAnd
- Settings -> Scroll down and create new profile
- Select Profile car
- Give it a name (mycar 1.5?)
- Select color and icons and save.

You are now still in your freshly created profile.
- Got to navigation settings (2nd option)
- Select Navigation type (1op one)
- Now scroll down and select the mycar15 navigation type
- Go back until your are out of the profile and you can now use it.
- Adapt it further to your liking.

I have done this now at least 25 times with all intermediate test builds and I never had a problem.

And what is your OsmAnd version? Are you at 3.6.x?

[danilo.baggini]

Version 3.6.2

If I copy your .xml files in the ditectory I can see them from Osmand menu but if there is no xml file in the directory and I do all yours instructions to create a new one the new xml file is not present in the directory.

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 15:40 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpuhCH2WwPYumS19Km5ostBT2HMUiHbCGPgXo3bQ1rJc4Q%40mail.gmail.com.

[Harry van der Wolf]

If you use a file manager, do you see the files?

Are the files really like mycar15.xml, or are they actually mycar15.xml.txt?  Some file managers and texteditors do change the extension.

Do you have Osmand on internal memory? or on external memory?

[danilo.baggini]

Osmand sd card.

With file manager I cannot see any file.

No .xml and no .xml.txt

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 18:27 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

If you use a file manager, do you see the files?

Are the files really like mycar15.xml, or are they actually mycar15.xml.txt?  Some file managers and texteditors do change the extension.

Do you have Osmand on internal memory? or on external memory?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpvpd06-m-OH3ACV3iUuCHCaEJpbdEXkuXtffnxiNJ0SOQ%40mail.gmail.com.

[danilo.baggini]

....and no file also in internal memory

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 18:27 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

If you use a file manager, do you see the files?

Are the files really like mycar15.xml, or are they actually mycar15.xml.txt?  Some file managers and texteditors do change the extension.

Do you have Osmand on internal memory? or on external memory?

[Harry van der Wolf]

sdcard is often internal memory.

In OsmAnd -> Settings -> OsmAnd Settings (top one); "Data storage folder" 

Where is your data folder?  In the selected option it shows a path like   "/storage/emulated/o/Android/data/net.osmand.plus/files".

What does your setting say?

Op za 7 mrt. 2020 om 18:32 schreef danilo.baggini <danilo....@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/5e63daa0.1c69fb81.273fd.8022%40mx.google.com.

[danilo.baggini]

My sd card as the following

storage/8549-QEE7/android/data/net.osmand/files/routing

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 18:37 (GMT+01:00)

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpt052S9bbdEJtOOeuJFEz4hhvD9kx6CGPvLwm6HCaU9vA%40mail.gmail.com.

[danilo.baggini]

.....excuse me ....8549-0EE7 ..not ..8549-QEE7...

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 18:37 (GMT+01:00)

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpt052S9bbdEJtOOeuJFEz4hhvD9kx6CGPvLwm6HCaU9vA%40mail.gmail.com.

[Harry van der Wolf]

Op za 7 mrt. 2020 om 18:42 schreef danilo.baggini <danilo....@gmail.com>:

My sd card as the following

storage/8549-0EE7/android/data/net.osmand/files/routing

That is External memory really on your sdcard. That identifier is the UUID or PARTUUID of your sdcard.

I do not understand why you do not see the files.

And I do not know how to help you further. It seems more an issue with the file manager.

[danilo.baggini]

Thankyou in any case.

I will copy .kml in the routing directory without trying to create it with Osmand.

Best regards

Danilo

-------- Messaggio originale --------

Da: Harry van der Wolf <hvd...@gmail.com>

Data: 07/03/20 18:52 (GMT+01:00)

A: osmand <osm...@googlegroups.com>

Oggetto: Re: Osmand routing calculation is very slow for long distance for many years

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpv%3D9axBc6yTA-iRNRbqbdefs%3Di%2BmnYQXQFMZGSXTmFEVA%40mail.gmail.com.

[ra]

dear harry, I followed your kind advice but am afraid to need more.

I installed all smoothly and tested now with a few destinations of about 100 and 200 km distance. you are right: the only difference really is the time taken: with the standard profile you say to have HC1,0 it takes more time to calculate. which is most annoying when in need of a fast recalculation because of a deviation. I remember well sitting on the roadside for minutes after minutes sometimes (in former times) waiting for osmand to help me find my way (great when it's dark and raining!). that is over after I switched for your 1,2 or 1,5. what I do not understand: I would expect the 1,5 to give the fastest route also, due to smaller rates of choice. but although the differences are close to non-existence that is not the case.

when I drive by car I am mostly not in a hurry and would like to be lead to small unknown roads that even shorten my way - so I mostly choose gas saving (in fact, that is what I love osmand the most for!). one problem here still remains: the time calculations become completely wrong the moment I switch for gas saving. they are more than 50% to high (while without they are pretty much exact). a trip which takes about 3hours20 may be displayed with 5hours10. that shure helps not starting too late - but arriving way too early doesn't help either ;-) how can I change that without getting into even bigger problems? thank you!

Am Freitag, 6. März 2020 15:25:39 UTC+1 schrieb Harry van der Wolf:

Op vr 6 mrt. 2020 om 15:16 schreef Episteme PROMENEUR <episteme...@gmail.com>:

[Harry van der Wolf]

Op zo 8 mrt. 2020 om 14:57 schreef 'ra' via OsmAnd <osm...@googlegroups.com>:

what I do not understand: I would expect the 1,5 to give the fastest route also, due to smaller rates of choice. but although the differences are close to non-existence that is not the case.

That is not necessarily true. When using a higher hc, the  "search for alternatives" (my terminology) is stopped earlier. It does not follow all roads (paths according the mathemathical wording) until it finds another that, when adding it to the route, leads to an even faster route in total, where in this case faster=shorter => shortest path.

Please read this (very high overview) article in wikipedia: https://en.wikipedia.org/wiki/A*_search_algorithm

Use in Google for example the search term "shortest path A* algorithm" and look for the images and videos, which to some are more explanatory than reading a page of text.

 

when I drive by car I am mostly not in a hurry and would like to be lead to small unknown roads that even shorten my way - so I mostly choose gas saving (in fact, that is what I love osmand the most for!). one problem here still remains: the time calculations become completely wrong the moment I switch for gas saving. they are more than 50% to high (while without they are pretty much exact). a trip which takes about 3hours20 may be displayed with 5hours10. that shure helps not starting too late - but arriving way too early doesn't help either ;-) how can I change that without getting into even bigger problems? thank you!

I did read your questions/remarks/issues related to this earlier. When looking at the routing.xml it is "just" a different setting of the parameters.

Therefore I think it is a bug in the calculation: the route may be correct, but OsmAnd does something strange with the route time calculation.

 

Harry

[Arndt]

On Friday, March 6, 2020 at 9:47:39 AM UTC+1, Harry van der Wolf wrote:

Op vr 6 mrt. 2020 om 01:41 schreef 'Arndt' via OsmAnd <osm...@googlegroups.com>:

 

- the other aspect is the "averge cost factor", so the ratio of average versus minimal cost, which should be close to 1 and is e.g. about 1.05 for the "car eco" profile, 1.16 for "car fast". It's important to be close to 1 here to keep the search area small.

 

I don't believe at all in "unconditional surrender" when going away from 1.0. (And obviously neither do all those other navigation app builders.)

Hi Harry,

I guess we are close to a consensus, but let me explain some more background why hc>1 is not yet "unconditional surrender" but hc > x is, and how you can find out what x is.

The heuristic cost used in A* is the "minimum remaining cost" and is calculated by assuming there's an "optimal" road along the bee-line. "Optimal" in OsmAnds sense is a road where you can travel at 130kmh.

The real-life remaining cost will be higher as this bee-line cost  by a factor "x" for two reasons: 1) roads are not bee-lines 2) some roads have lower speeds due to classification or speed-limits.

So if you increase the heuristic cost by a heuristic coefficient hc < x, it is still a good estimate for the remaining cost. The elliptic A*-search area is stil an elipitic area, it just narrows. Computing times still go quadratic with distance. I would agree to call that "pragmatic tuning", not "unconditional surrender"

Things change if you are going for hc > x. There will be no elipitic search-area, but the search quickly follows roads pointing in the right direction. This is a linear search. Computing time goes linear with distance, not quadratic. Very fast, but also very bad results. You cannot find an optimal solution simply because you are not searching for it.

So yes, if you know you "x" and are pretty sure the your hc stays well below, fine.

But why not lower the "x" itself? Same effect on computing times, but correct results.

You can easily do that by lowering the "maxSpeed" in the routing.xml from 130kmh to 100kmh.

regards, Arndt

[CP]

Hi Arndt,

I've been following this thread for a while now. I also did some reading up on the A* algorithm. But my non-academic brain cells got short circuit pretty quick. But your explanation is hugely helpful and is super easy to follow. So thanks for that! I makes much more sense now.

Still, if I could bribe you with a beer (or two) maybe then you would be able to provide some additional easy to follow links? Even easier to follow then Wikipedia? Even better, post something of this quality (but a bit more elaborate) on your personal web space? That would make you king of the hill of A* !!! :-D

Thanks a million!
Ceaus.

Op 09-03-2020 om 19:02 schreef 'Arndt' via OsmAnd:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/a624e0fa-fa7f-4faa-a302-90653a33ae7a%40googlegroups.com.

[Greg Troxel]

"'Arndt' via OsmAnd" <osm...@googlegroups.com> writes:

> I guess we are close to a consensus, but let me explain some more
> background why hc>1 is not yet "unconditional surrender" but hc > x is, and
> how you can find out what x is.
>
> The heuristic cost used in A* is the "minimum remaining cost" and is
> calculated by assuming there's an "optimal" road along the bee-line.
> "Optimal" in OsmAnds sense is a road where you can travel at 130kmh.
>
> The real-life remaining cost will be higher as this bee-line cost by a
> factor "x" for two reasons: 1) roads are not bee-lines 2) some roads have
> lower speeds due to classification or speed-limits.
>
> So if you increase the heuristic cost by a heuristic coefficient hc < x, it
> is still a good estimate for the remaining cost. The elliptic A*-search
> area is stil an elipitic area, it just narrows. Computing times still go
> quadratic with distance. I would agree to call that "pragmatic tuning", not
> "unconditional surrender"
>
> Things change if you are going for hc > x. There will be no elipitic
> search-area, but the search quickly follows roads pointing in the right
> direction. This is a linear search. Computing time goes linear with
> distance, not quadratic. Very fast, but also very bad results. You cannot
> find an optimal solution simply because you are not searching for it.

Thanks; that's a very useful explanation.

> So yes, if you know you "x" and are pretty sure the your hc stays well
> below, fine.

We don't know x, it seems.

I wonder if an algorithm that starts with hc sort of too high, but high
enough to be known to be adequately fast, perhaps 1.5, and then if the
computation finishes in a reasonable period of time, recompute with 1.4,
and so on. Perhaps this could be done more aggressively when on
external power, and less so on battery. (IMHO, navigating 500 km routes
on the phone's internal battery makes little sense anyway.)

For bonus points, there could be a page that explains the overall
minimized metric and computing time for each hc, so you can understand
where the breakpoint was.

> But why not lower the "x" itself? Same effect on computing times, but
> correct results.

I don't see how you can change x. x is basically a property of the map
graph, which is about the typical shortest actual path between places.

> You can easily do that by lowering the "maxSpeed" in the routing.xml from
> 130kmh to 100kmh.

I don't follow how that's correct, if there really are roads you can
drive 130 km/h on. (Around me, there are definitely roads with that as
the normal speed, despite posted limits.)

[Harry van der Wolf]

Op ma 9 mrt. 2020 om 19:02 schreef 'Arndt' via OsmAnd <osm...@googlegroups.com>:

Thanks for educating me. 

I must admit that your explanation of x was unknown to me. 

And indeed: Simply copying the default profile and lowering the max speed to 100 (what it will be in the Netherlands anyway after 16.03), does indeed result in shorter computation times.

Question:  Is there some mathemitcal approach to calculate or estimate the x for a certain route?

Harry

[Harry van der Wolf]

Op ma 9 mrt. 2020 om 19:56 schreef Greg Troxel <g...@lexort.com>:

"'Arndt' via OsmAnd" <osm...@googlegroups.com> writes:

> So yes, if you know you "x" and are pretty sure the your hc stays well
> below, fine.

We don't know x, it seems.

I wonder if an algorithm that starts with hc sort of too high, but high
enough to be known to be adequately fast, perhaps 1.5, and then if the
computation finishes in a reasonable period of time, recompute with 1.4,
and so on.  Perhaps this could be done more aggressively when on
external power, and less so on battery.  (IMHO, navigating 500 km routes
on the phone's internal battery makes little sense anyway.)

Also: As fas as I know (I read it somewhere), OsmAnd is using a 2-step approach. It first calculates the route with an hc=1.6 and then recomputes this route?? with hc=1.0.

I have no idea how that should work, but this topic brings that part of my memory to life again. Unfortunately not good enough to remember where it was said and how it was explained.

Harry

 

[ra]

I remember pretty well that 3 or more years ago osmand even showed that procedure of a second calculation in the progress-line.

[Greg Troxel]

Harry van der Wolf <hvd...@gmail.com> writes:

> And indeed: Simply copying the default profile and lowering the max speed
> to 100 (what it will be in the Netherlands anyway after 16.03), does indeed
> result in shorter computation times.

Yes, but does it compute the same routes?

> Question: Is there some mathemitcal approach to calculate or estimate the
> x for a certain route?

It seems to me that one has to compute the route with hc=1, and then for
each pair of route points, ask the question what the actual cost is
divided by the assume straigtline cost, and take the min of those
values.

This has to be in the cost function being minimized, I think.

[Alexander]

Hi,

Am Freitag, 6. März 2020 13:05:12 UTC+1 schrieb Harry van der Wolf:

Sorry. My stupid mistake. I said roads, but I meant routing (of course).

When I said that the data is not so big, I meant the routing data.

I don't see like that. Routing data may include at least every way which is marked with keyword "highway". These are not only streets for cars, but includes footpaths and all other variations of "highways". In the early times of OSM there was only a street for cars. Pedestrian ways were mostly "assumed" to exist as well. Then they were eventually excluded, then seperate pedestrian paths were implemented, also separate cycle ways may have been created. And see what happened to routing in forests, routing of trekking paths and so on. While calculating the route even for cars, everything on its way has to be considered to see if it fits or not. I find this a quite enormous amount of data, growing massively.

Best regards, Alexander.

[Harry van der Wolf]

Op di 10 mrt. 2020 om 01:03 schreef Alexander <teuf...@gmail.com>:

I meant comparing to the rest of the data. I gave the 125MB for the Netherlands on a total of a 1.8GB map file, where 1+GB is map data. Also becasue the maps that are used within Brouter are by (big) regions, but are much smaller because they do not contain all that additional map and address data (and are compressed?).

Of course 125MB is a lot of data.

And yes, it contains all "highway" tagged lines in OSM.

However, highways have additional tags like footway, bridleway, steps, etc. These are not used for car routing.

Another tag can be "designated" being only for cyclists, pedestrians, cars (or combinations like pedestrians and cyclists), etc.

So for car navigation this 125MB (for the Netherlands) is entirely queried, but filtered, and therefore not entirely used for car navigation.

Additional filters inside OsmAnd is to block unpaved roads, or ice roads or ferries, etc. further reducing the amount of "to be used" data.

Hoi,

Harry

[Arndt]

On Monday, March 9, 2020 at 7:53:52 PM UTC+1, CP wrote:

Even better, post something of this quality (but a bit more elaborate) on your personal web space? That would make you king of the hill of A* !!! :-D

I have something here since years: http://brouter.de/brouter/algorithm.html

but I do not think it is better then WikiPedia....

But indeed, watching the open-set animation of the brouter-app and playing with the coefficients (as explained in this article) is a good way to get a feeling how A* works depending on the heuristic coefficient.

On Tuesday, March 10, 2020 at 12:13:28 AM UTC+1, Greg Troxel wrote:

    >> And indeed: Simply copying the default profile and lowering the max speed
    >> to 100 (what it will be in the Netherlands anyway after 16.03), does indeed
    >> result in shorter computation times.

    > Yes, but does it compute the same routes?

No, if you set maxspeed=130 because you want to prefer the unlimited motorways AND if they actually exist, then you really need o keep maxspeed=130.

With maxspeed=100 the unlimited highways will no longer be prefered.

[Harry van der Wolf]

Op di 10 mrt. 2020 om 12:23 schreef 'Arndt' via OsmAnd <osm...@googlegroups.com>:

On Tuesday, March 10, 2020 at 12:13:28 AM UTC+1, Greg Troxel wrote:

    >> And indeed: Simply copying the default profile and lowering the max speed
    >> to 100 (what it will be in the Netherlands anyway after 16.03), does indeed
    >> result in shorter computation times.

    > Yes, but does it compute the same routes?

No, if you set maxspeed=130 because you want to prefer the unlimited motorways AND if they actually exist, then you really need o keep maxspeed=130.

With maxspeed=100 the unlimited highways will no longer be prefered.

Indeed. I already wrote earlier in other posts (with a.o. RA and pegobuf) about a "caravan" profile with a limit of 95 km/hr. This also leads to other routes as the faster, but sometimes longer motorways/highways, are no longer faster.

Harry

[Harry van der Wolf]

This is a spin-off of the original topic.

I just did a number of route calculations for the different heuristic coefficients being hc=1.0 (default OsmAnd), hc=1.2 and hc=1.5

I took the routing.xml, copied the car routing profile out of it and made my own routing.xml (the earlier mentioned mycar15.xml and mycar2.xml)

Done with OsmAnd+ 3.6.3, maps: mixture of February and March on Motorola G6-plus  (4GB) on Android 9

Starting point Zwolle was my home address, which I did not specify further ;)

No mathematics, 100% empirically; just real-life testing with stopwatch.

Distances in kilometer, except UK where it is in miles.

heuristic coefficient	distance (calculated)	time (hours minutes)	calculation time minutes/seconds)	Remarks
Zwolle, Nl - Puttgarden ferry, Ge				lot of motorway/highway
hc=1.0	487km	4h57m	1m58s
hc=1.2	487km	4h57m	19s
hc=1.5	487km	4h57m	7s
Zwolle - Machiel Vrijenhoeklaan 354, The Hague, Nl				first and last part quite some "in city" route
hc=1.0	169km	2h4m	1m21s
hc=1.2	169km	2h4m	11s
hc=1.5	169km	2h4m	5s
Zwolle, Nl - Valkenburg, Nl				last part smaller roads
hc=1.0	239km	2h24m	36s
hc=1.2	239km	2h24m	8s
hc=1.5	234km	2h26m	4s
Zwolle, Nl - Holiday park, De Haan, Be				lot of motorway/highway
hc=1.0	333km	3h25m	52s
hc=1.2	333km	3h25m	24s
hc=1.5	333km	3h25m	10s
Zwolle, Nl - Camping Birkelt, Larochette, Lu				Last part lot of smaller roads
hc=1.0	390km	4h15m	*
hc=1.2	390km	4h10m	3m35
hc=1.5	401km	4h15m	11s
Zwolle, Nl - Bridge Le Havre North - Sohth, Fr				lot of motorway/highway
hc=1.0	646km	6h6m	*
hc=1.2	646km	6h6m	1m41s
hc=1.5	646km	6h7m	8s
Harwich port, UK - Sandy Lane, Woolacombe Beach, Uk				first and last part smaller roads
hc=1.0	320mi	5h20m	35s
hc=1.2	320mi	5h20m	31s
hc=1.5	320mi	5h20m	7s

*: Stopped paying attention to the stopwatch after 5 minutes. Just let it calculate and check later for the results.

When it comes to motorways/highways there is almost no difference in the route itself.

When it comes to small roads or in city routing, the hc=1.5 sometimes deviates from the others, but the overall traveling time or calculated distance does not vary much. 

Like I (stubbornly) mentioned before: dense traffic, traffic lights, refueling/toilet pauses, etc. have much bigger impact on travelling time.

I could have tested with hc=1.3 and hc=1.5 too, but didn't feel motivated too (after all: it is not a paid job with the chance of winning the Nobel prize)

This again strenghtens my personal view to use hc=1.5 for long travles and hc=1.2 for city travels.

But of course: You all decide yourself.

Harry

[ra]

superb, harry! was that done with setting FASTEST route or ENERGY SAVING? without being able to award you ANY price (besides a beer to be picked up here ;-) I would so very much like to see THESE very interesting differences. and to the above with the added setting AVOID HIGHWAYS - we all could learn so much! already your statement of HC1.0 being wrong seems undoubtably proven.

[Harry van der Wolf]

Op wo 11 mrt. 2020 om 14:25 schreef 'ra' via OsmAnd <osm...@googlegroups.com>:

superb, harry! was that done with setting FASTEST route or ENERGY SAVING? without being able to award you ANY price (besides a beer to be picked up here ;-) I would so very much like to see THESE very interesting differences. and to the above with the added setting AVOID HIGHWAYS - we all could learn so much!

It was default settings, so: prefer highways, fastest route. I will do some more calculations.

 

already your statement of HC1.0 being wrong seems undoubtably proven.

Ho, stop. I didn't say it was wrong. I said it was over the top calculating a "theoretically" 100% correct route.

In earlier days Victor also participated in some of these discussions where he defended the hc=1.0.

The big problem (as I see it) is that OsmAnd can't calculate long routes.

The answer is: "You have to add waypoints", and that is also what OsmAnd suggests.

That immediately and completely ruins the hc=1.0 model. If you have to add waypoints, how do you know you choose the optimal waypoint for the total route? Maybe you should have chosen another waypoint.

Anyway: This discussion will never end. Users have to choose for themselves what they want. I only want to give examples in how OsmAnd can also be used.

Harry

[Stefan Monnier]

> The big problem (as I see it) is that OsmAnd can't calculate long routes.
> The answer is: "You have to add waypoints", and that is also what OsmAnd
> suggests.

Reminds me that I wonder if OsmAnd (or other routers) use some form of
"planning": rather than do a recursive search from start to end, they
first pick some intermediate waypoints.

E.g. I imagine that for a long trip you could do:

- Pick the point right in the middle between start and end
- Look for the closest highway (not in the OSM sense but in the sense
of an important road) and use that as a tentative intermediate waypoint.
- Compute the two halves of the trip.
- Since the tentative intermediate waypoint was chosen somewhat
arbitrarily, it's probably not a good choice. So: remove that
tentative waypoint and instead take the two middle points of the two
halves as new non-tentative waypoints (which are presumably
approximately 25% and 75% along the way, so we only need to recompute
the middle portion).

This way we have to compute 3 half-trips, which is good if computing the
total trip is much longer than computing half of it. Of course, it's
bad if computing the total trip is not much more than twice as long as
computing half the trip.

Also this strategy will likely work poorly when the final trip has to go
around a body of water (so the tentative waypoint may be unreachable,
for example).


Stefan

[Harry van der Wolf]

The two routes (Fastest Route) that did have differences between an hc=1.2 and an hc=1.5 I did again with an hc=1.3

heuristic coefficient

distance (calculated)

time (hours minutes)

calculation time minutes/seconds)

Remarks

Zwolle, Nl - Valkenburg, Nl				last part smaller roads
hc=1.0	239km	2h24m	36s
hc=1.2	239km	2h24m	8s

hc=1.3	239km	2h24m	6s
hc=1.5	234km	2h26m	4s

Zwolle, Nl - Camping Birkelt, Larochette, Lu				Last part lot of smaller roads
hc=1.0	390km	4h15m	*
hc=1.2	390km	4h10m	3m35

hc=1.3	390km	4h10m	1m34s
hc=1.5	401km	4h15m	11s

*: Stopped paying attention to the stopwatch after 5 minutes. Just let it calculate and check later for the results.

And then I did it again for Fastest route and Economic route.

Again:

Done with OsmAnd+ 3.6.3, maps: mixture of February and March on Motorola G6-plus  (4GB) on Android 9

Starting point Zwolle was my home address, which I did not specify further ;)

No mathematics, 100% empirically; just real-life testing with stopwatch.

Distances in kilometer, except UK where it is in miles.

I assume Economic Route is much more an approach of shortest path than Fastest Route. The differences there are quite big and in some cases not to explain. Some calculations I did multiple times, but always giving the same results.

I never use Economic Route, so I never looked at those calculations.

However, for Economic Route the hc=1.5 is definitely too high. I guess you should not go above an hc=1.2 for Economic Route.

Fastest Route

Economic route

heuristic coefficient	distance (calculated)	time (hours minutes)	calculation time minutes/seconds)		distance (calculated)	time (hours minutes)	calculation time minutes/seconds)	Remarks
Zwolle, Nl - Puttgarden ferry, Ge								lot of motorway/highway

hc=1.0	487km	4h57m	1m58s		473km	9h12m	2m49s
hc=1.2	487km	4h57m	19s		473km	9h13m	10s
hc=1.3	skipped				474km	9h11m	10s
hc=1.5	487km	4h57m	7s		480km	9h26m	8s

Zwolle - Machiel Vrijenhoeklaan 354, The Hague, Nl								first and last part quite some "in city" route

hc=1.0	169km	2h4m	1m21s		164km	3h21m	36s
hc=1.2	169km	2h4m	11s		164km	3h21m	6s
	skipped				168km	3h36m	5s
hc=1.5	169km	2h4m	5s		168km	3h41m	5s

Zwolle, Nl - Valkenburg, Nl								last part smaller roads

hc=1.0	239km	2h24m	36s		226km	4h30m	1m35s
hc=1.2	239km	2h24m	8s		224km	4h40m	9s
hc=1.3	239km	2h24m	6s		223km	4h40m	6s
hc=1.5	234km	2h26m	4s		224km	5h10m	6s

Zwolle, Nl - Holiday park, De Haan, Be								lot of motorway/highway

hc=1.0	333km	3h25m	52s		309km	6h30m	1m29s
hc=1.2	333km	3h25m	24s		309km	6h30m	14s
hc=1.3	skipped				309km	6h30m	10s
hc=1.5	333km	3h25m	10s		313km	6h49m	6s

Zwolle, Nl - Camping Birkelt, Larochette, Lu								Last part lot of smaller roads

hc=1.0	390km	4h15m	*		372km	7h28m	4m1s
hc=1.2	390km	4h10m	3m35		374km	7h33m	19s
hc=1.3	390km	4h10m	1m34s		363km	8h10m	8s
hc=1.5	401km	4h15m	11s		371km	8h55m	11s
Zwolle, Nl - Bridge Le Havre North - South, Fr								lot of motorway/highway
hc=1.0	646km	6h6m	*		608km	11h58m	2m15s
hc=1.2	646km	6h6m	1m41s		603km	12h21m	14s
hc=1.3	skipped				609km	12h39m	10s
hc=1.5	646km	6h7m	8s		651km	13h30m	12s

Harwich port, UK - Sandy Lane, Woolacombe Beach, Uk								first and last part smaller roads

hc=1.0	320mi	5h20m	35s		277m	9h33m	3m50s
hc=1.2	320mi	5h20m	31s		280mi	10h29m	2m5s
hc=1.3	skipped				287mi	9h57m	16s
hc=1.5	320mi	5h20m	7s		288mi	10h13m	15s

*: Stopped paying attention to the stopwatch after 5 minutes. Just let it calculate and check later for the results.

So for Fastest Route an hc=1.5 is good. If you want to stay on the safe side, choose an hc=1.3 to stay on the safe side.

For Economic Route an hc=1.2 is the max value you should choose. 

I guess that also  "slow roads" are used in the calculation thereby exponentially increasing driving time.

I also did some recalculations with Magic Earth for the same routes, also on Fastest Route and Shortest Route (as it is called there). 

Fastest Route is fully comparable. For Shortest Route the routes are generally longer. Driving times the same. Also here: I guess that also  "slow roads" are used in the calculation thereby exponential increasing driving time.

Again: This is not a scientific article. Just simple measuring with a stopwatch and doing (redoing) a lot of route calculations. (speaking about dumb activities)

Judge for yourself what you think of this.

Harry

[Greg Troxel]

What I take away is

hc=1.2 does not ever result in any significant routing error (where
error is failure to match 1.0), of course in the cases you tried.

hc=1.3 is almost always non-erroneous, and the time saving from 1.5 to
1.3 is never important


I don't 100% follow the "need 1.2 to be safe for economic route". Those
routes don't necessarily look better than the 1.3, and you don't have
the "economic cost", because osmand doesn't expose it. In the second
example, the 1.2 is 164km and the 1.3 is 168km, but at the cost of 15m.
But the economic cost values could be only a factor of 1.0001 apart. So
I would not be upset with that "error". But I see your point with the
metric of "did the route at 1.3 exactly match the 1.2 route (which is
exactly the 1.0 route) as something you can say definitively.

In ad hoc networks (computers talking over radio), there is an important
paper that proposes a way to evaluate routing algorithms. The basic
problem is that if every node has complete, up-to-date state
information, then you can compute routes that are by definition optimal.
But sending that state information takes up capacity. So the
definition of the best routing algorithm is one that minimizes

total messages sent to maintain routing state

+

extra hops in delivery (in that a message sent 11 hops when perfect
information would have sent it 10 hops gets charged as an extra
message)


This leads to wanting less information if it doesn't hurt accuracy more
than the savings.

So if you think about getting in your car and pushing the calculate
button, and then when there's a route starting to drive (since at least
here you cannot touch the phone to recmopute routes once driving), then
the metrics would be the travel distance and the sum of computation time
and driving time.


From your research, I think I'll just use 1.3, and maybe save a 1.5
profile for really long routes.

Thanks for doing this work!



As an aside:

long ago I started using shortest rather than fastest on a garmin
handheld for driving, and found that mostly the routes were much shorter
and only slightly more time (not in the city, where you have endless
opportunities to make 3 extra turns and save 2m distance; where I am
there just aren't that many extra roads). I'm a bit careful about
these, but I found several good ways to travel that I didn't know about
before, compared to usung the ~motorways.

This makes me want a metric which is partly based on time and partly
based on distance. Essentially, would I want to save 1km in distance at
a cost of 1min in time? Hard call, but for 1m extra I would want to
save 10km, and I would not want to save 100m. I might guess at 2km/min
I'd want to save distance and add time. One could add a blend of fuel
use to this too of course.

[ra]

up to 1 or 2 years ago "gas saving"/"kraftstoffsparend" was called "shortest" - I hope it actually is the same. I love it, not for gas saving, but to go along small roads I would never see else. I once travelled like that venice > berlin, very nice, if you take the time. or you quit the highway and take your way home avoiding highways ... almost impossible without a co-driver else ... on harry's list you see the time-miscalculations that way though ...

[Harry van der Wolf]

Op wo 11 mrt. 2020 om 19:47 schreef 'ra' via OsmAnd <osm...@googlegroups.com>:

up to 1 or 2 years ago "gas saving"/"kraftstoffsparend" was called "shortest" - I hope it actually is the same. I love it, not for gas saving, but to go along small roads I would never see else. I once travelled like that venice > berlin, very nice, if you take the time. or you quit the highway and take your way home avoiding highways ... almost impossible without a co-driver else ... on harry's list you see the time-miscalculations that way though ...

I don't think the travel time calculations are mis-calculations. Like said: I did the same in Magic Earth leading to the same long driving times.

When using shortest path, it is really shortest path. You see that when you zoom in on the map. You go completely through cities which take an enormously long time compared to going around it on some bypass road.

When you drive from Venice to Berlin, you do not drive through every city/town/village either. You try to stay off the motorways to see the scenic routes and the beautiful landscape, not to get stuck in stinking villages with trucks blocking the road and taking too much time.

Harry

[Harry van der Wolf]

And forgot to say:  For that reason I switch off "use motorways" (and toll roads like in France) when planning a touristic route.

Harry

Op wo 11 mrt. 2020 om 20:01 schreef Harry van der Wolf <hvd...@gmail.com>:

[Xavier]

On Wed, Mar 11, 2020 at 01:46:19PM -0400, Greg Troxel wrote:
>What I take away is
>
> hc=1.2 does not ever result in any significant routing error (where
> error is failure to match 1.0), of course in the cases you tried.
>
> hc=1.3 is almost always non-erroneous, and the time saving from 1.5
> to 1.3 is never important
>
>
>I don't 100% follow the "need 1.2 to be safe for economic route".
>Those routes don't necessarily look better than the 1.3, and you don't
>have the "economic cost", because osmand doesn't expose it.

Just to add my 2-cents to the discussion. My use for OsmAnd's routing
(car) falls, primarially, into two major buckets:

1) to determine a route to get to a destination when I do not already
know how to navigate to that destination; and

2) to have an ETA indicator for long trips when I otherwise *do* know
how to navigate to the destination

For #2 I'm not so worried about the exact route OsmAnd picks, as I'm
not using it to navigate the route. And I've found the computed ETA to
be good enough (given that it will change quite considerably due to
food/restroom stops along the trip anyway).

For #1, I'm also not so concerned that OsmAnd find *the most perfect
route*. I do not know how to get to the destination, and as long as
OsmAnd will navigate me to that destination, I'm not so worried if an
'insider' might have known of a shortcut that might have saved 15
minutes. I don't know how to get there, therefore I don't know the
shortcuts, therefore any route (as long as it is not so far off as to
be silly) is fine.

Also, ten plus years ago when I first got a TomTom GPS unit, I
experimented with letting it compute some routes for routes I otherwise
knew (i.e., commute from home to workplace, etc.) just to see how it
did.

What I found was that while it would compute a path to the destination
just fine, the route it picked was not always the route I would have
choosen as an 'insider' for that route. Had I been unfamiliar with the
location, I would have never known that TomTom's route was less
optimal, and it still would have gotten me to my destination. One of
the routes it computed took about a 2 mile due west detour on a road
with a 45mph max-speed to avoid a 3.5 mile segment of the road it had
already picked that is posted at a max of 35mph and 30mph in two
different places. But, what I knew, that TomTom did not, is that the
road it picked to utilize after the 45mph detour was less optimal due
to traffic lights and generally denser (and slower moving) traffic than
simply remaining on the 35mph and 30mph road to the same final
destination. But without "real-time-traffic" info, no GPS unit will
know those little 'insider' details.

Which led me to my opinion I stated above for #1. Yes, the chosen
route might be less optimal than what an 'insider' will pick, but it
will get me to my destination, and if I'm not an 'insider' in that
area, I'll never know the difference. And if I'm 'routing' via OsmAnd
in a location where I do have 'insider' knowledge, I'm simply going to
ignore the GPS's chosen route anyway.

So my feelings are that trying to find the *perfect* route from an hc
of 1.0 is a bit much in that either I won't know enough to tell the
difference or I'll just ignore the navigators suggestions if I do know
enough to tell the difference. But having faster completion of route
computation might be a better benefit (esp. if there is a second
impatient person sitting in the passenger seat whining "come one, can
we get going already" while the lengthy computation is running).

[ra]

I am SHURE many first time users of osmand never use it again just for that simple reason (as they start with HC1.0)

[A Thompson]

As I understand it, the A* algorithm uses a heuristic that estimates the cost of the as-yet unexplored route from a point to the goal. If this function never underestimates the cost, then the optimal route is guaranteed to be found. 

If we only consider distance as the cost, then the bee-line distance never underestimates. But OsmAnd's cost functions take a lot more into account (speed restrictions, turns, road-type preferences, elevation data, etc, etc). Does OsmAnd just take the bee line distance and multiply it by hc to get the heuristic? In which case values of hc larger than 1.0 will still give optimal routes because of all the extra penalties that OsmAnd considers on it's actual routes.

[A Thompson]

Aaargh. I meant overestimates not underestimates. Wouldn't it be better if this were a google group where posts could be edited, rather than a mailing list archived as google group?

[Poutnik Fornntp]

Hmm, AFAIK,  it is a Google group, with optionally used mail list functionality,

like some others, e.g the BRouter group.

The mail list functionality had to be explicitly activated, not sure if on the group or the account level.

Dne 12. března 2020 5:14:34 A Thompson <thomp...@gmail.com> napsal:

Aaargh. I meant overestimates not underestimates. Wouldn't it be better if this were a google group where posts could be edited, rather than a mailing list archived as google group?

On Thursday, March 12, 2020 at 3:57:45 AM UTC, A Thompson wrote:

As I understand it, the A* algorithm uses a heuristic that estimates the cost of the as-yet unexplored route from a point to the goal. If this function never underestimates the cost, then the optimal route is guaranteed to be found. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/3b43ece4-e6dc-47bb-a731-7a4354c6c305%40googlegroups.com.

[Harry van der Wolf]

It is indeed a Google groups mailing list.

Other options (from the help pages) are:

OsmAnd at Facebook, Twitter, and Reddit!

Join us at our groups of Telegram (EN), (IT), (FR), (DE), (RU).

Op do 12 mrt. 2020 om 06:30 schreef Poutnik Fornntp <poutni...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/170cd38d210.2799.a291d67f9894f806060d35c996ca15e9%40gmail.com.

[Harry van der Wolf]

Op wo 11 mrt. 2020 om 20:32 schreef 'Xavier' via OsmAnd <osm...@googlegroups.com>:

Just to add my 2-cents to the discussion.  My use for OsmAnd's routing
(car) falls, primarially, into two major buckets:

1) to determine a route to get to a destination when I do not already
   know how to navigate to that destination; and

2) to have an ETA indicator for long trips when I otherwise *do* know
   how to navigate to the destination

Fully agree. 

And to add a #3: You sometimes know 90% - 98% of the road until you enter a city/area navigating to a new address you have never been to before.

 

Which led me to my opinion I stated above for #1.  Yes, the chosen
route might be less optimal than what an 'insider' will pick, but it
will get me to my destination, and if I'm not an 'insider' in that
area, I'll never know the difference.  And if I'm 'routing' via OsmAnd
in a location where I do have 'insider' knowledge, I'm simply going to
ignore the GPS's chosen route anyway.

And this is sometimes where insiders also go wrong. I have a route which I thought was fastest/shortest and I just drove that one. 

When comparing Osmand and Magic Earth (a year ago?), they both suggested another route. And of course, being an insider "who knows his surroundings", I didn't believe it, until I started using that route. In general it was indeed a few minutes faster.

So inside info, might also bias you to what is really the right route.

(And to conclude this: I drive the "my old" route again as it leads me along a nicer landscape and in kilometers it is less than 2 km difference. It is not always only about being faster/shorter.)

 

Harry

[Greg Troxel]

A Thompson <thomp...@gmail.com> writes:

> Aaargh. I meant overestimates not underestimates. Wouldn't it be better if
> this were a google group where posts could be edited, rather than a mailing
> list archived as google group?

No, that would be terrible!

Seriously, anything that requires a google account to participate is
completely unacceptable.

[ra]

you must know, writing from your google account.

[Poutnik Fornntp]

Aside of that,
requirement of the X account
for participation on X environment
is fully normal, common and generally accepted.

Why should be X=Google an exception ?

Dne 12. března 2020 14:22:29 "'ra' via OsmAnd" <osm...@googlegroups.com>
napsal:

> you must know, writing from your google account.
>

> --
> 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.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/osmand/f31df05f-dcf8-41c3-9bc4-321d34229cad%40googlegroups.com.

[A Thompson]

Apologies - it was stupid of me to question the setup of the mailing list when we were discussing something else. I diluted my own question!

If 

heuristic = bee-line_distance * hc

and the cost function is only distance, then hc can be larger than 1.0 to the extent that it reflects the extra distance of an optimal route to the goal compared to the bee-line, and the optimal route will be found.

But what makes OsmAnd's routing so good is that its cost function reflects map features that slow you down, like traffic signals and turns. So hc can be even higher before much risk of not finding the optimal route. On long car journeys on the motorway/autobahn/whatever, this effect diminishes.

Is this right?

[Poutnik Fornntp]

Yes, it is right, and applies for BRouter routing as well.

The longer the route is, and the more complex the network is, the less is probability of missing the optimal route with HR > 1.

1.2-1.3 is the typical geometry factor

route-distance / bee-line-distance

The critical HR factor is the above ratio, multiplied by the average costfactor, based on the effective length(BRouter) or time/distance of the roads along the route.

If HR crosses this critical HR, the routing has tendency to prefer the partial route variant, that is already closer to destination.

Dne 13. března 2020 2:36:08 A Thompson <thomp...@gmail.com> napsal:

[A Thompson]

Thank you, Poutnik! I'm very grateful to understand this better, and I'm sure others are too.

Interpreting Harry's results, I'm no longer thinking "acceptable routes are found even when the optimum is no longer guaranteed" but (eg. for hc=1.2) "it would take a very unusual route and section of map for the optimal route not to be found" (that is, before the heuristic overestimates the cost function of the optimal route).

These are different. But it remains the case that the only absolute guarantee that the optimal route will be found is hc=1.0. I think I have created car and pedestrian profiles that use a customised routing.xml with hc=1.0 but I have yet to find a route that gives different results to OsmAnd 3.6.3's current values (1.5 for car, 1.2 for pedestrian).

(Harry - had you noticed that the standard values are now this high?)

[Harry van der Wolf]

Op ma 16 mrt. 2020 om 03:43 schreef A Thompson <thomp...@gmail.com>:

These are different. But it remains the case that the only absolute guarantee that the optimal route will be found is hc=1.0. I think I have created car and pedestrian profiles that use a customised routing.xml with hc=1.0 but I have yet to find a route that gives different results to OsmAnd 3.6.3's current values (1.5 for car, 1.2 for pedestrian).

(Harry - had you noticed that the standard values are now this high?)

Sorry, but that is not correct. The value of 1.5 for car navigation is "outcommented" as it is between HTML/XML "remark coding", being the starting  <!-- and closing -->.

<routingProfile name="car" baseProfile="car" restrictionsAware="true" minSpeed="20.0" defaultSpeed="45.0" maxSpeed="130.0" leftTurn="5" rightTurn="5" roundaboutTurn="5" onewayAware="true"> <!--<attribute name="heuristicCoefficient" value="1.5" /> -->

That value is still there from before 2011~2012. 

Before the 2-step calculator, the hc WAS 1.5.

Now it is 1.6 for the first step, and 1.0 for the second step (don't ask me how it works).

 The syntax has also slightly  changed. Now it is (from my mycar13.xml):

<routingProfile name="mycar13" baseProfile="car" restrictionsAware="true" minSpeed="20.0" defaultSpeed="45.0" maxSpeed="130.0" leftTurn="5" rightTurn="5" roundaboutTurn="5" onewayAware="true" heuristicCoefficient="1.3">

Pedestrian and cycling has always been higher than 1, but as far as I remember cycling was 1.2 up till last year. Now it is 1.4

Harry

[Poutnik Fornntp]

The 2 step may work very similarly as the BRouter 2 step routing.

The 1st step may use quite a high HC ( originally 1.5, I use often up to 1.8 ) to get quick rough estimation of the total cost of the optimal route. It can be quite high, until time gain for fast 1st step is paid by slower 2nd step.

The 2nd step uses HC 1.0 to guarantee finding optimal route, but in BRouter case

it means it throws all partial routes that cannot be better than the 1st step rough estimation any more.

It helps a lots to save resources for long route calculation, as the original 1 step A* algorithm keeps all routes in case they turn to be optimal ones.

In case the 1st step uses too high HC, the 2nd step may throw routes slower then necessary,

as the 1st step estimation may be far from optimal route.

Dne 16. března 2020 9:34:33 Harry van der Wolf <hvd...@gmail.com> napsal:

[Harry van der Wolf]

Thanks, but that theorectical description I already knew :)

I mean: does it keep some matrix in memory with the already determined costs/routes?

And if it finds a better route in the 2nd step, then based on what? Because it will not be available after the first run. And why is that first step then necessary?

etcetera, etcetera.

Op ma 16 mrt. 2020 om 16:16 schreef Poutnik Fornntp <poutni...@gmail.com>:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/170e3eb3700.2799.a291d67f9894f806060d35c996ca15e9%40gmail.com.

[Poutnik Fornntp]

Then you know also the answers to your questions. :), perhaps without realising that.

Yes, it does keep track of already determined costs/routes during routing.

The problem is, the classical A* has enormous memory demand for long routes, growing quadratically with the route distance. 

That is why BRouter comes in the 2nd step with the cut off feature. But you need an estimation of optimal route cost by fast draft run( typically I guess 20% of time of the 2nd run ) , that is very near to optimal route. 

It need not to remember the route found at the first pass, all what is needed is its cost.

What at the 2nd pass the sum of partial cost and remaining distance is bigger than 1st pass cost, the partial route is thrown away.

If it were 1 pass only, you would have no idea 

if the partial route still can be the optimal route or not and you would have to keep many more routes and points.

The cutting off of bad routes progressively increases its rate, while the routing approaches the destination, when A* would have been at the top of its resource hunger.

Dne 16. března 2020 18:57:52 Harry van der Wolf <hvd...@gmail.com> napsal:

[Poutnik Fornntp]

P.S.: In case of BRouter, one can use 1 pass routing as well, but then the HC must be more conservative than for the 1st pass of 2-pass routing. 

Dne 16. března 2020 19:40:19 Poutnik Fornntp <poutni...@gmail.com> napsal:

[Poutnik Fornntp]

I may originally misunderstood your question.

No, it does not keep routes determined in the 1st pass. It goes just for estimation of the optimal route cost, that is supposed after the 1st draft pass with relatively high HC to be somewhat higher than the one of the optimal route.

Then it knows, if a particular partial route in the 2nd pass is worse than that, it cannot be the optimal one and is thrown away.

Dne 16. března 2020 19:40:19 Poutnik Fornntp <poutni...@gmail.com> napsal:

[Poutnik Fornntp]

P.S.: Technically speaking, not sure about the OSMand 2nd pass, but the BRouter 2nd pass is not A* based like the 1st pass, but it is the plain Dijkstra with the cut off feature. 

It is functionally almost equivalent to 1-pass A* with HC=1.0,  with the difference A* uses no route elimination, what often becomes a resource problem.

Dne 16. března 2020 18:57:52 Harry van der Wolf <hvd...@gmail.com> napsal:

[Lodro Gyamtso]

from my experience with navigation, i have some information to share with you

- brouter says ... for every 1Km of travel distance, the time is 1sec to design the route
- the osm maps is one open community and the users "draw" the maps into computers
- maps from big companies like google or Here or tomtom, etc, has special cars to collect data from the field

the results are ...
when the big cartographic companies collect data, they include info like traffic data for 24/7 of time (365days per year). Those data is also embedded into offline maps. The route algorithm use this info and during the calculation rejects probably over the 95% of roads. So, the design time into one trip will be very fast, 2-3 secs.

On Thursday, March 5, 2020 at 3:02:23 PM UTC+2, Episteme PROMENEUR wrote:

Osmand routing calculation is very slow for long distance for many years.

If you use for other app then no problem for example "waze"

What is the problem ? No expert in Osmand team ? Not enough devs ? Something else ?

If you use other app then no problem for example "waze"

[Poutnik Fornntp]

Time needed to calculate the route grows in average quadratically with distance , for both OSMAnd and BRouter. Brouter may use more resource serving algorithm and data.

Online routing services use very different algorithms. 

OSMAnd  and BRouter use modifications of A-star algorithm, which is slow on end device, but resource friendly for creation navigation data. 

Online car routers usually contraction hierarchy or similar algorithm, that is fast for end device, but is extremely demanding for preprocessing of the server navigation data.

Dne 22. března 2020 7:54:19 Lodro Gyamtso <lodrog...@gmail.com> napsal:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/4856016d-04c8-4515-938d-5b4358145e03%40googlegroups.com.

[Lodro Gyamtso]

after the answer of user "Poutnik", we have another proof that the OSMAnd and BRoute use slow (bad) technology.

Software like Here WeGO, Sygic, Tomtom Go, iGO, navigon, navitel, route 66, copilot, mireo, etc , are far away from this low level apps (OSMAnd and BRout). And all of this top companies has offline navigation apps. So, the user "Episteme PROMENEUR" has right into his first post.

My opinion is - don't use osmand, locus, orux, brouter, for city navigation. They are only for mountain use.

To unsubscribe from this group and stop receiving emails from it, send an email to osm...@googlegroups.com.

[Harry van der Wolf]

Op di 24 mrt. 2020 om 07:32 schreef Lodro Gyamtso <lodrog...@gmail.com>:

after the answer of user "Poutnik", we have another proof that the OSMAnd and BRoute use slow (bad) technology.

Software like Here WeGO, Sygic, Tomtom Go, iGO, navigon, navitel, route 66, copilot, mireo, etc , are far away from this low level apps (OSMAnd and BRout). And all of this top companies has offline navigation apps. So, the user "Episteme PROMENEUR" has right into his first post.

My opinion is - don't use osmand, locus, orux, brouter, for city navigation. They are only for mountain use.

That is not true. Both OsmAnd and BRouter are excellent routers. OsmAnd is slower on longer distances, but that can be tweaked.

OsmAnd is even the best in cities due to it's penalty system for traffic lights and  traffic bumps and the like.

If you calculate a route inside a city, the route might be the same, but OsmAnds ETA is by far the most accurate even though TomTom uses their "smart routing" where they collected statistical data on "heavy use" roads.

And sometimes OsmAnds route is different, exactly because it uses these penalties. I personally did many test and especially in cities (!), OsmAnd is by far the best when calculating the route AND the correct ETA. So actually in cities I do use OsmAnd.

Please test yourself before posting these "theories".

I know less about BRouter, although I used it for cycling, and that was excellent. So why "mountain use"?

Here WeGo is currently only a city navigation tool, so useless in my eyes (unless it is builtin into your car navigation set).

Finally: There is not one single navigation app in the world that offers the wide portfolio of functionality that OsmAnd does. Not one!

Harry

[Poutnik Fornntp]

Slow does not mean bad. Open projects with low budget do not have computation power to preprocess the maps of the World.

OSMAnd and BRouter ( not BRoute nor BRout ) are fast enough for city navigation. Plus their maps have superior details.

Advantage of contraction hierarchy comes rather for long distances, but it may be disadvantage in rural areas, as their road network is a subset of OSMAnd/BRouter.

Dne 24. března 2020 7:32:45 Lodro Gyamtso <lodrog...@gmail.com> napsal:

To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/726a6a04-bedf-40dd-b1ec-ef384563f713%40googlegroups.com.

[Stefan Monnier]

> Advantage of contraction hierarchy comes rather for long distances, but it
> may be disadvantage in rural areas, as their road network is a subset of
> OSMAnd/BRouter.

I guess in theory it should be possible to construct auxiliary data from
osm data, just like online routers do, and then make osmand, brouter,
and others take advantage of it when/where available.


Stefan

[Harry van der Wolf]

Note that contraction hierarchies are not tweakable as such. There are no a parameters to tweak without creating another contraction hierarchy and this is for every parameter. So every parameter will need its own profile, and these can become quite big.

If you have a high power server with lots of disk space, you can create multiple sets. On a mobile phone this will never work.

If you want to create them yourselves: one for 130 km/hr, one for 100 km/hr, one for routes without toll roads, one for routes without motorways/highways, and all of these for shortest and fastest, etc. etc., you can have a look at http://project-osrm.org/

Harry

Op di 24 mrt. 2020 om 14:22 schreef Stefan Monnier <mon...@iro.umontreal.ca>:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/jwvsghx99g3.fsf-monnier%2BInbox%40gnu.org.

[Lodro Gyamtso]

this post is special for user "Harry van der Wolf"

who do you think that you are ? who gave you the right to say to other people  - Please test yourself before posting these "theories".
Is your ego and arrogance ? That's why i suggest to you "don't say to other people what to do into their personal lives"

i am writing a post having experience of my devices or reading posts from other users. I did exactly what you made, i write my thoughts as you did, without judging other people. I use only what the others say, just to found answers.

Using my old smartphone for a route inside the city of 60 Km, the results time is over 1 minute for calculation. With my new smartphone for the same route needs less of 20secs to draw the route. With all the navigation apps i have mentions before, the route results is 1sec (instantaneously) for both of my devices.

p.s
sorry for my english

[Harry van der Wolf]

Op wo 25 mrt. 2020 om 08:15 schreef Lodro Gyamtso <lodrog...@gmail.com>:

this post is special for user "Harry van der Wolf"

who do you think that you are ? who gave you the right to say to other people  - Please test yourself before posting these "theories".
Is your ego and arrogance ? That's why i suggest to you "don't say to other people what to do into their personal lives"

i am writing a post having experience of my devices or reading posts from other users. I did exactly what you made, i write my thoughts as you did, without judging other people. I use only what the others say, just to found answers.

Using my old smartphone for a route inside the city of 60 Km, the results time is over 1 minute for calculation. With my new smartphone for the same route needs less of 20secs to draw the route. With all the navigation apps i have mentions before, the route results is 1sec (instantaneously) for both of my devices.

p.s
sorry for my english

-- 

I don't want to start a flame here.

My ego is quite alright, thank you. I dare to say that my arrogance level is quite low apart from the fact that I do consider myself an experienced user. One who did indeed, till approx 2015, contributed with many map and artiicle activiets for OsmAnd.

I started with the fact that OsmAnd is slow on longer routes. If you had followed this htread and the all the posts since 2011, you would have seen that I have very argued against: 1. slowness of route calculation, 2. slowness of screen rendering due to the implementation of the rendering.

Secondly: You obviously only tested the calculation time for a route. I guess you missed my explanation about the route penalties OsmAnd uses and how that relay improves on accuracy and ETA, especially in cities. To add to this: Actually only in cities, because as longer the route gets, the lower the impact of these speed penalties on the route.

Thirdly: Also in the past years I shared multiple times calculation times, route calculations with different parameters for multiple apps, mainly OAM based apps though.

So again: Only giving route calculation times is in my eyes not a good way of testing the several options.

And of course: You are completely free to choose any navigation app you prefer.

Harry

 

[Lodro Gyamtso]

Hi Harry van der Wolf,
so that there are no misunderstandings, i am a paid user of osmand, locus, orux

after the question of post 1, there are 80 posts from users, just like the lawyers trying to "acquit the accused". All the posts understood the problem, but .... there very good reasons why this is happening.

probably after so many years this hasn't change because
1. 99% of users using this app for special needs. Those can't found into apps like here, tomtom, sygic, etc. There are no more complaints
or
2.  users don't like this behavior has left osmand and return to apps like sygic. There are no more complaints

[Helmut Jarausch]

@Lodro

PLEASE STOP to insult anybody on this forum.

I don't understand the fuss about this problem. 

I have no problems on my 5 years old mobile. 

For long distance calculations I set one or two intermediate points to circumvent the problem.

Please give citations on better routing algorithms which are suitable for devices with low memory and restricted CPU power. If there is such an algorithm we should all try to implement it and send it to the developers of OSMAnd.

When hiking I am not aware of any other offline routing app with such detailed maps. 

And installing yet another app requires additional storage on the SD card.

 

So, please stay constructive,

Helmut 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/9455b432-a528-44ab-9949-8b31ba934569%40googlegroups.com.

[Lodro Gyamtso]

@Helmut Jarausch

stop insulting people. If you don't understood the problem, why don't you say something about the user into post 1. I am facing the same issues and agree 100% with post 1. Stop to attack to other posts of users having personal proofs. This is bad behavior.

To unsubscribe from this group and stop receiving emails from it, send an email to osm...@googlegroups.com.

[Pere Pujal i Carabantes]

El dc. 25 de 03 de 2020 a les 00:15 -0700, en/na Lodro Gyamtso va
escriure:

2 posts ago:

"don't use osmand, locus, orux, brouter, for city navigation."

then in the replied post:

> "don't say to other people what to do into their personal lives"

# #### #
# # # #
# # # #
# # # #
# # # #
###### #### ######

[Bart Eisenberg]

@Lodro This forum has been that rare corner of the web where civility is the norm.  Please follow suit or find another forum.  

[Lodro Gyamtso]

@Pere Pujal i Carabantes

those are not 100% what i was wrote, it's a part of my opinion. Also it's not into the same subject. It's very clear that you are you are trying to change the meaning of my words. It'w is very sad for your character as a human

[Lodro Gyamtso]

@Bart Eisenberg
I can say the same for you.

[Poutnik Fornntp]

Well, Lodro, you like arguments. The others  just react on your bait.

OSMAnd, Locus, BRouter serve different purposes

than Google Maps, Waze, TomTom etc.

Each group is superior to the other in what it is focused to. Speed is both strength and weakness.

If your prefer the latter group, use it.

The first group has reasons not to follow.

Dne 25. března 2020 22:06:52 Lodro Gyamtso <lodrog...@gmail.com> napsal:

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/07444c14-65bb-484b-b02e-3d56fac4f4e8%40googlegroups.com.

[Harry van der Wolf]

All,

please stop this.

I forgot to mention that I am also a (long-time) moderator of this mailing group, mostly trying to remove spam as soon as it appears. Like Bart mentions: we normally do not have these kind of arguments.

If this continues I might be tempted to remove the posts, of course including my own posts, and block a user (temporarily?)

We need to be able to have discussions, also fierce discussions, but let's do it in respect for each other, without personal counter-attacks. Misunderstandings can easily arise due to all non-native english speakers here (I am one of them).

But please stop now. Let's leave it at this and stay on topic.

Kind regards,

Harry

Op do 26 mrt. 2020 om 03:32 schreef Poutnik Fornntp <poutni...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/17114aea8b8.2799.a291d67f9894f806060d35c996ca15e9%40gmail.com.

[Lodro Gyamtso]

Hi Poutnik,

all the users has the right to post their view of a product. As long as what they write in the subject is all right. When what we write is personal experience or knowledge from others, there is no problem. But what happens when others tell us "we don't like your opinion - don't write it". Do i have the right to reply to them ???

To unsubscribe from this group and stop receiving emails from it, send an email to osm...@googlegroups.com.

[Poutnik Fornntp]

For speed optimalization of the 2-pass A* star compatible routing algorithms of BRouter and OSMand ( as I understand the latter uses it now too ), it is interesting to evaluate the route calculation time versus heuristic coefficient value for the 1st pass.

At the first the time drops, because the 1st pass time becomes just small fraction of the total time.

But it reaches the minimum and then it start to grow again,  as the 1st pass route becomes less and less optimal. Therefore the 2nd pass cutting outs happens later then with low HR of the 1st pass.

For BRouter  the time-optimal coefficient is quite high,  typically 1.7-1.8, but it depends on region scenario and used profile. Cases having in average higher road costfactors can afford higher coefficient and vice versa.

For OSMAnd 2nd pass, it may depend on how exactly it is implemented, what algorithm is used. 

Dne 26. března 2020 7:35:10 Harry van der Wolf <hvd...@gmail.com> napsal:

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/CAGARPpu5ZS9L7%3DK%3DZR%2B6iqvqk8q9eLiMGrM8n8oTwxuTEMxE1Q%40mail.gmail.com.

[Lodro Gyamtso]

the follow information is official from the original site
http://osmand.net/help-online?id=faq

Route calculation is slow
Please be aware that there are 2 offline routing engines in the app: a Java based approach and a "Native" (C++) routing. The Java based approach is used in 'Safe Mode', it is 10 times slower than native mode and it has strict memory limitations. If you experience it and you see messages 'Not enough memory to compute', please go to Settings — 'General' — 'Safe mode' and make sure the option is disabled.
For native routing there are different limitations for different phones, depending on memory & processor. In general, native routing should handle < 300 km routes nicely. The route calculation should take between 15 sec and 4 minutes. It is prudent to not wait much longer than 4 minutes, because most likely the program will crash.
The only known workaround to compute long routes is to insert intermediate destinations. Two additional intermediate destinations should be enough even for very long routes.

How to calculate routes longer than 250km?
Many long routes (> 200-250km) cannot not be calculated by OsmAnd's offline routing engine today. If the app does not show a route after 7-8 minutes of calculation time, consider placing waypoints (pick e.g. places on motorways). 3-4 waypoints will be enough to calculate even 1000km routes.

i have found this text is from 24-04-2016. This situation is well known to the company.

[Lodro Gyamtso]

when we read the copy-paste text i made into the previous post, from osmand company we can found this

there are different limitations for different phones, depending on memory & processor

when i made some route examples, from 50-150km using one flagship smartphone from year 2012 the time results was 1-3minutes. Into the same tests with one flagship smartphone from year 2017, the time results was from 10-30 seconds. It's very logical to assume if we test a year 2020 model we must found less time results.

As i said "i have found this text is from 24-04-2016". We can understood that the osmand company has made this post (faq) for the customers, maybe months or years earlier. Today (2020), the device hardware year by year is getting mode powerful and the time for the osmand app to route from point a to point b will be faster. So, i don't think osmand company  will change/improve nothing, now or ever.

p.s.
sorry for my english

[Helmut Jarausch]

No insult intended :

OSMAnd is not a company but a user driven project. So, it's up to all of us to improve it. If somebody comes up with the implementation of a better routing algorithm l am sure this will get into OSMAnd very soon. 

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/40b29374-2daf-42b2-8c59-14796c995c71%40googlegroups.com.

[Lodro Gyamtso]

1. when we visit this page
https://play.google.com/store/apps/details?id=net.osmand&hl=en
we can found " Additional Information "

Netherlands, Amstelveen Logger 41, 1186 RM

this is the address of the company

2. when we visit this page
https://osmand.net/help-online/about
we can found

Victor Shcherb - Founder and CEO, Product Lead.
Alexey Kulish - Technical Lead, Android/iOS developer.
Eugene Kizevich - Marketing Lead.
Dmitriy Prodchenko - Product Lead, UI/UX designer.
Dr. Hardy Mueller - Map appearance concept and base renderers, international consistency and testing, usability, app scoping, concepts, documentation, wiki, market research.
Max (Zahnstocher) - Java contributor, active forum participant.
Leonid (xmd5a) - Co-author of main OsmAnd rendering, author of UniRS, LightRS styles.
Pavel Stetsenko - Key Android / IOS developer.
Vitaliy Golinko - Key Android developer.

those titles belongs only to companies

3. when i bought the app, i use my credit card

conclusion
that's why i believe that the osmand is a company, small , but a company
 

[Poutnik Fornntp]

But the point is, the project is open source, maintained on GitHub.

Interested skilled users contribute at will.

Dne 26. března 2020 18:47:06 Lodro Gyamtso <lodrog...@gmail.com> napsal:

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/09bee5c6-3b9e-4b3d-9468-1eb39f2a0aac%40googlegroups.com.

[Pere Pujal i Carabantes]

El dj. 26 de 03 de 2020 a les 19:48 +0100, en/na Poutnik Fornntp va
escriure:

> But the point is, the project is open source, maintained on GitHub.
>
> Interested skilled users contribute at will.

Just to add some links

The github page of the whole project
https://github.com/osmandapp

of the android osmand app
https://github.com/osmandapp/Osmand

a small overview of people contributing to it
https://github.com/osmandapp/Osmand/commits/master

[zanny]

Il giorno giovedì 26 marzo 2020 03:32:13 UTC+1, Poutnik ha scritto:

Each group is superior to the other in what it is focused to. Speed is both strength and weakness.

 Could you please elaborate on this? In which cases is speed a weakness?!?!