Op vr 6 mrt. 2020 om 08:20 schreef Florian Lohoff <[email protected]>:

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

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osmand/CAGARPpvbE2nUVW7470QAiwkBBBsAKBJSxJSpL1rrBfC-emO_Dw%40mail.gmail.com.

Reply via email to