Tha ability to import XML file into the custom navigation profiles is
great, I was not aware of it until recently.
Dne 28. března 2020 11:46:11 Harry van der Wolf napsal:
Like I have stated before: Use a different profile with a different
heuristic coefficient(See .xmls attached).
In another
Sorry
In the past this was "turn on screen before turn".
"Turn on screen" is a very bad sentence to describe what it means.
And it is not sufficient. If "time" = 0 then this feature is not enabled !
"Time" and other features are hidden.
"Time" describes very badly what it means. It would be
Op zo 29 mrt. 2020 om 19:15 schreef Episteme PROMENEUR <
episteme.promen...@gmail.com>:
> >> feature to turn the screen on (for a few seconds only) when there is a
> bifurcation ahead
>
> this one disappeared or what ? i can't find it.
>
Profile (walk/bicycle/car/other)
Navigation Settings ->
>> feature to turn the screen on (for a few seconds only) when there is a
bifurcation ahead
this one disappeared or what ? i can't find it.
--
You received this message because you are subscribed to the Google Groups
"OsmAnd" group.
To unsubscribe from this group and stop receiving emails
Op zo 29 mrt. 2020 om 12:46 schreef Helmut Jarausch :
> With OSMAnds (relatively) new feature to turn the screen on (for a few
> seconds only) when there is a bifurcation ahead, I have observed quite
> moderate battery consumption - about a few percents per hour.
>
>
And with the functionality of
Similarly, Voice only bicycle BRouter navigation is great. I use it in
Locus, but it is applicable for OSMAnd as well if following GPX route
generated by BRouter/BRouter Web for OSMand.
Dne 29. března 2020 12:46:14 Helmut Jarausch napsal:
With OSMAnds (relatively) new feature to turn the
With OSMAnds (relatively) new feature to turn the screen on (for a few
seconds only) when there is a bifurcation ahead, I have observed quite
moderate battery consumption - about a few percents per hour.
'Xavier' via OsmAnd schrieb am So., 29. März
2020, 05:05:
> On Sat, Mar 28, 2020 at
On Sat, Mar 28, 2020 at 05:42:26PM -0400, Stefan Monnier wrote:
With power usage, do you believe that
osmand running gps receiver, displaying where you are and navigating
along an already calculated route
takes significantly more power than
osmand running gps receiver and displaying
> With power usage, do you believe that
>
> osmand running gps receiver, displaying where you are and navigating
> along an already calculated route
>
> takes significantly more power than
>
> osmand running gps receiver and displaying where you are
I don't know. Putting my software
Stefan Monnier writes:
>> I realize this is preference, but as someone who knows how to read maps,
>> I very strongly dislike 3D view. I want to see a plan view, with angles
>> preserved and scale preserved. I know that it does not match visually
>> what I see out the window, but I am able to
> I realize this is preference, but as someone who knows how to read maps,
> I very strongly dislike 3D view. I want to see a plan view, with angles
> preserved and scale preserved. I know that it does not match visually
> what I see out the window, but I am able to know relative distances in
>
Harry van der Wolf writes:
> And indeed 3D (or 2.5D or birdview, etc) is nicer for navigation, but
> actually I do not care much. I drive a lot of rental cars for my work, and
> some also have 2D only or "some other renter" put it back to 2D and/or
> "North up". I don't care much. Once in
HC=1.0 is the only value that guarantee finding the optimal route by A*
algorithm, according given criteria. Higher values can provide for short
distances a/o trivial road network geometry
surprisingly wrong results.
By statistical evaluation, length of long enough routes is typically
1.2-1.3
Op vr 27 mrt. 2020 om 19:30 schreef Episteme PROMENEUR <
episteme.promen...@gmail.com>:
>
> Osmand advises cutting in several routes of 250 km our itinerary, Right ?
>
> Then I asked for Osmand to include their advice in their algorithm.
>
>
I might be wrong, but I guess this will never work.
The OsmAnd development team mentioned many years ago that an hc=1.0 would
deliver the only really "correct" route, as all "paths" will be checked in
the "shortest path" algorithm. Therefore, the only correct route would be
chosen.
So it was not a bd algorithm or bad implementation: it was a design
Thanks for the PDF summary, very explicative.
A couple of questions from my side (I apologise if those have been asked
and answered somewhere else already).
1) why is hc=1 the standard parameter? in 5 of 7 cases the results (in
terms of distance and travel time) is the same as hc=1.5. And in the
Op za 28 mrt. 2020 om 11:45 schreef Harry van der Wolf :
>
> Trying to prove that OsmAnd is "bad" mail after mail, only leads to one
> conclusion: Use another app and stop wasting your time on such a "bad" app.
>
> Harry
>
>
Sorry, this last statement sounds really harsh when reading it again. It
There are bicycle and foot routes longer than 1000 km, when OSMand or
BRouter is used to calculate the route.
Personally, for trips shorter then 400 km I use intermediate viapoints for
true viapoints, or for route shaping, not to make things easy for the
algorithm. There is also much more
i made some tests using 3 apps into the same device.
1. osmand+ v3.6.3
one route of 936km. first with tolls ON, the time results are >10secs.
After i choose tolls OFF, the time results are >100secs. I repeat tolls
ON-OFF some times, with the same time results.
2. Here WeGO v2.0.14125
same
If that were so simple, there would the following extremely fast overall
algorithm:
Select a point in the "middle" and solve the two problems separately.
Now continue to do that recursively.
Episteme PROMENEUR schrieb am Fr., 27. März
2020, 19:30:
>
>
>
>>
>>
> After reading all posts I was a
>
>
After reading all posts I was a bit puzzled and disappointed then i had an
idea.
Osmand advises cutting in several routes of 250 km our itinerary, Right ?
Then I asked for Osmand to include their advice in their algorithm.
See
https://github.com/osmandapp/Osmand/issues/8721
--
You
OK - as a very minor correction.
Actually, the mainpage of the website links to google play, amazon and
apple app store (at the moment all with -50%).
So, as a matter of fact, the app is first put on the market to be sold, but
also on f droid (nightly builds are available as well, for the sake
On Fri, Mar 27, 2020 at 08:12:37AM -0700, zanny wrote:
Last point - since Osmand is a sold product, users have the right to hardly
complain. "Implement your own solution" is a good answer only for
free-of-charge app
Minor correction. OsmAnd is free of charge in general, the "sale"
aspect on
P.S.: OSMand algorithm obviously can be optimized wrt speed, I and Harry
would agree on that, but it was chosen by purpose
and will never have the speed of contraction hierarchy ( or like )
algorithm speed.
And contraction hierarchy definitely is not for BRouter, as it's high
priority is
Hello gentlemen,
I am also a long time (and hence, satisfied) user of Osmand, since back in
2011.
Speed is (and has always been) an issue (you can check old discussion as
well) - I believe there full consensus on this.
I had never thought it is a matter of computational power: any 100$ mobile
In many areas, not limited to routing, speed can be also a weakness. Not
necessarily the speed itself, but things leading to high speed.
It is like a half-joke about software usability:
It can be free, easy, but not powerful.
It can be free, powerful, but not easy.
It can be powerful, easy, but
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?!?!
--
You received this message because
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
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 napsal:
1. when we visit this page
https://play.google.com/store/apps/details?id=net.osmand=en
we can found " Additional Information "
1. when we visit this page
https://play.google.com/store/apps/details?id=net.osmand=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
>
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.
Lodro Gyamtso schrieb am Do., 26. März 2020, 11:03:
> when we
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
*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
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
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
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
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.
@Bart Eisenberg
I can say the same for you.
On Wednesday, March 25, 2020 at 10:49:16 PM UTC+2, Bart Eisenberg wrote:
>
> @Lodro This forum has been that rare corner of the web where civility is
> the norm. Please follow suit or find another forum.
>
> On Wednesday, March 25, 2020 at 12:15:19
@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
On Wednesday, March 25, 2020 at 8:21:10
@Lodro This forum has been that rare corner of the web where civility is
the norm. Please follow suit or find another forum.
On Wednesday, March 25, 2020 at 12:15:19 AM UTC-7, Lodro Gyamtso wrote:
>
> this post is special for user "Harry van der Wolf"
>
> who do you think that you are ? who
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"
# #
# ## #
# #
@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.
On Wednesday, March
@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
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
Op wo 25 mrt. 2020 om 08:15 schreef 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
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
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
> 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
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
Op di 24 mrt. 2020 om 07:32 schreef 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
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
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
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
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 :
>
>
> Op wo 11 mrt. 2020 om 19:47 schreef 'ra' via OsmAnd <
> osmand@googlegroups.com>:
>
>> up to 1
Op wo 11 mrt. 2020 om 19:47 schreef 'ra' via OsmAnd :
> 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 >
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
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
Op wo 11 mrt. 2020 om 14:25 schreef 'ra' via OsmAnd :
> 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
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
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
Op di 10 mrt. 2020 om 12:23 schreef 'Arndt' via OsmAnd <
osmand@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
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
Op di 10 mrt. 2020 om 01:03 schreef 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
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
Harry van der Wolf 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
I remember pretty well that 3 or more years ago osmand even showed that
procedure of a second calculation in the progress-line.
Am Montag, 9. März 2020 20:03:14 UTC+1 schrieb Harry van der Wolf:
>
>
> Also: As fas as I know (I read it somewhere), OsmAnd is using a 2-step
> approach. It first
Op ma 9 mrt. 2020 om 19:56 schreef Greg Troxel :
> "'Arndt' via OsmAnd" 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
Op ma 9 mrt. 2020 om 19:02 schreef 'Arndt' via OsmAnd <
osmand@googlegroups.com>:
> 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
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.
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
Op zo 8 mrt. 2020 om 14:57 schreef 'ra' via OsmAnd :
> 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
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
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
Data: 07/03/20 18:52 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow for long
Op za 7 mrt. 2020 om 18:42 schreef danilo.baggini :
> 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
.excuse me 8549-0EE7 ..not ..8549-QEE7...
Danilo
Messaggio originale Da: Harry van der Wolf
Data: 07/03/20 18:37 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow for long distance for many years
sdcard is often internal memory.
In OsmAnd
My sd card as the following
storage/8549-QEE7/android/data/net.osmand/files/routing
Danilo
Messaggio originale Da: Harry van der Wolf
Data: 07/03/20 18:37 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow for long distance for many years
sdcard is
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
and no file also in internal memory
Danilo
Messaggio originale Da: Harry van der Wolf
Data: 07/03/20 18:27 (GMT+01:00) A: osmand 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
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
Data: 07/03/20 18:27 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow for long distance for many years
If you use a
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
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
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)
-
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
Data: 07/03/20 07:43 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow
Op za 7 mrt. 2020 om 07:23 schreef danilo.baggini :
> 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
I tried but no file in ..data/net.osmand/files/routingEither in memory nor in
sdcard
Danilo
Messaggio originale Da: Harry van der Wolf
Data: 06/03/20 15:25 (GMT+01:00) A: osmand Oggetto:
Re: Osmand routing calculation is very slow for long distance for many years
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
--
You received this message because you are subscribed to the Google Groups
"OsmAnd" group.
To unsubscribe from this group and stop receiving emails from
Op vr 6 mrt. 2020 om 15:16 schreef Episteme PROMENEUR <
episteme.promen...@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
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 ...
--
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
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
Op vr 6 mrt. 2020 om 11:29 schreef Florian Lohoff :
> 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
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
Op vr 6 mrt. 2020 om 08:20 schreef 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
Op vr 6 mrt. 2020 om 01:41 schreef 'Arndt' via OsmAnd <
osmand@googlegroups.com>:
>
>
> 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,
>
>
On Thu, Mar 05, 2020 at 06:57:53AM -0800, Episteme PROMENEUR wrote:
> Same answer. You don't answer to the question.
>
> No improvement since many years, where is the problem ?
> What is the problem ? No expert in Osmand team ? Not enough devs ?
> Something else ?
Because the growth of OSM
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
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
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.
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.
On Thu, Mar 5, 2020 at 8:57 AM Episteme PROMENEUR <
episteme.promen...@gmail.com> wrote:
> Same answer. You don't answer to
Same answer. You don't answer to the question.
No improvement since many years, where is the problem ?
What is the problem ? No expert in Osmand team ? Not enough devs ?
Something else ?
--
You received this message because you are subscribed to the Google Groups
"OsmAnd" group.
To
Same answer. There's only so much computing power you can pack into the
phone. Brouter's running on a separate computer.
On Thu, Mar 5, 2020 at 8:34 AM Episteme PROMENEUR <
episteme.promen...@gmail.com> wrote:
> "waze" is just an example. Forget it. Just reply to my question. No
> improvement
1 - 100 of 103 matches
Mail list logo
