Osmand+ is great, but its routing algorithm buggy and extremely slow

[Marek Luthardt]

Hi,

I bought Osmand+ to support a great idea: using OSM maps and building a feature-rich navigation app on top. I was quite satisfied with Osmand+ at first, but currently I am disappointed more and more. With every new version the routing algorithm is getting worse in terms of performance and correct routing results. The Osmand UI is great, the other functions besides routing are really helpful - but the routing makes me nuts every time I give it a try. I use Osmand offline routing engine and tried different settings - all with the same result: the calculated route is mostly completely wrong or extremely slow. Some examples:

• Driving a long way on the highway Osmand suggests to take an exit and go back on the highway on the next ramp just 500 meters down the road. This is neither a shorter way nor a faster. It's just nonsense and did not happen in older versions than 1.9. It's a known problem as I learned from this forum. But why did it work in earlier routing engines and is defect now?
• I use Osmand on my daily route from home to the office to check its routing engine advancement ... with disappointing results: The calculated route differs between home-to-office and office-to-home directions, but there are no one-way roads which could explain this difference. Osmand tells me to leave a fast road through the city (B2R in Munich) and take some side roads. If I ignore this and stay just on the fast road, the recalculated route is then some kilometers shorter and estimated time of arrival is also some minutes earlier - so why was the initial route suggesting this extra-turns? On my 23-km-route this happens 3 to 4 times!
• Recalculation got extremely slow and so unusable. In one of the first versions I used the recalculation started just 3 or 4 seconds after leaving the original route and within 1 or 2 seconds I had an alternative to follow. Now it takes 15 to 20 seconds before the recalculation starts and then another 15 to 30 seconds to offer the alternative route - the destination is only 10 to 20 kilometers away! Driving one minute in an urban environment without routing hints makes Osmand just unusable as I do not want to stop every time and wait. I tried also Scout (formerly known as Skobbler), which uses also Osmand maps. Scout instantly recognizes me leaving the calculated route and offers the alternative route within 1 or 2 seconds. This is the proof that my requirement is not unrealistic and it does not depend on special maps material.
• As I now drive the home-office-route for years already, I have tried different routes and currently I think I am using the really best one. Scout calculates the route nearly the same way I would do and shows realistic ETA and length. Osmand did this also in earlier versions, but now fails to even come close to the ideal route. Combined with the lousy calculation performance (on Samsung Galaxy S2 as well as on the 2013 Nexus 7) I am not convinced I can use Osmand for routing purposes in unknown territory.

I know Osmand is not a commercial product as TomTom or Navigon, but I understood the project aim is to provide a comparable product. In my opinion Osmand clearly fails to compete and Scout proves that this is not caused by OSM maps being used or the hardware being used, but it's just a software problem - algorithm or architecture. It would be great Osmand developers could take some effort to fix bugs and improve quality before implementing such features as Osmo, which look fancy, but are not really important to have in a maps and navigation app.

Best regards,

Marek

[Harry van der Wolf]

I fully agree. I used to be very enthusiastic about OsmAnd and I also have OsmAnd+.

However, ever since 1.6 the main purposes (for me that is) got worse:

- Navigation is dead-slow and limited to max. 300-350 km on a 512MB device and the calcualted route is getting more and more not optimal (I won't call it wrong).

- Screen rendering is getting slower and slower, also due to the info being displayed and the more and more complex render files (even if they do look good). I don't have the fastest phone but it is not the slowest either (512MB, dual-core 1.3GHz, 4" 800x480). The screen is simply not rendered/redrawn in time. Redrawing simply blocks some time.All other nav apps I tried run fine on my phone, apart from the new Nokia Here which crashes all the time. All other apps calculate the route (much) faster and compared with latest OsmAnd versions even better.

I still follow the developments and I see great functionality being added, but this main two topics (again: for me) has now lead to the fact that I stopped using OsmAnd(+). If I need to buy an expensive phone just to run OsmAnd, when all other nav apps run fine, I can just as well buy a TomTom. I don't game on my phone so why should I need an big, expensive phone.

The app which I loved so much in the 1.1, 1.3 and 1.5 versions simply grew unusable to me.

I hope it gets back on the right track, or as a "light" version.

Again: this is my personal meaning and it actually makes me quite sad.

Harry

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

[Peter B]

Is one of the older and better versions available ?
Which version do you recommend ?
Where can I download  ?
By a mistake I overwrote a older free version which was quite good. :-((
Peter

[Osmandtrier]

Am Mittwoch, 10. Dezember 2014 09:46:33 UTC+1 schrieb Harry van der Wolf:

I fully agree. I used to be very enthusiastic about OsmAnd and I also have OsmAnd+.

I still follow the developments and I see great functionality being added, but this main two topics (again: for me) has now lead to the fact that I stopped using OsmAnd(+). If I need to buy an expensive phone just to run OsmAnd, when all other nav apps run fine, I can just as well buy a TomTom. I don't game on my phone so why should I need an big, expensive phone.

The app which I loved so much in the 1.1, 1.3 and 1.5 versions simply grew unusable to me.

I agree with you. I like to cycle distance longer than 50km. But waiting four minutes for a routesuggestion is nonsense. Carrouting works for such distances in 5 seconds.

But I am not very hopeful that the things will get better  I am using Osmand for two years. Osmand was always the slowest routing app based on OSM-Data. The developers claimed all the time things will get better, but the got more worse. I think they are not clever enough to solve this issue, but they do not realize this fact. So they will not search for better people or deny the help of better people.

[Osmandtrier]

Look at http://osmand.net

[Harry van der Wolf]

I definitely do think the programmers and other contributors are clever enough. I'm really convinced of it.

IMHO they focus too much on other things lately and there is simply not enough (wo)man-power to pick up all the tasks.

There are also other programmers that contribute smaller chunks and bug-fixes to this project so the core programmers don't deny the help either. I also don't have the meaning that they should look for "better" people as I do think they are capable enough. Searching for other programmers, better or not, could also be a task of the community.

I'm really positive about the programmers as such, but to me they focus on the wrong functionalities. And I do know that they spend a lot of their free hours into this program and already for a long time.

As this is an open-source project they do have the full right to choose their goals as long as there are no other programmers that participate and have other goals. I don't blaim them for it.

The result however is an app that has become unusable to me as the memory and CPU requirements are way too high and even then underperform compared to other (3D) apps.

All the "side" functionality works OK and looks nice, but the core functionality (to me) doesn't function correctly and is too slow.

Harry

[Aceman444]

There are several possible explanations for the effects you are seeing:

1. the OSM data along your route could have some bugs, e.g. unconnected roads or wrong speed limits. You could look for those in "OSM Inspector" or "Osmose" web tools.
2. the OsmAnd routing file contains assumes wrong max speeds depending on road type (e.g. it could think a "ramp" where somebody put maxspeed=130 it faster than the real highway (motorway, where assumed maxspeed is 110). See https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L180 . You can make a customized version of this file and put it in your OsmAnd data folder.
3. increasing slowness of OsmAnd may also be caused by actually increasing data being put into OSM (e.g. more minor roads that OsmAnd must judge now). Depends on the coverage quality of the regions you guys are talking about.

Have you tried to exclude these factors?

Yes, I agree new features are going into OsmAnd, but I do like them as I use it not only for routing but also survey and data collecting for OSM.
I also have slow phone and 384MB available RAM, but it does work for me. I have set up OsmAnd so that in "car" mode it does not draw polygons (e.g. buildings), then it is faster and can navigate at bearable speed (yes, initial calculation is slow).

Dňa streda, 10. decembra 2014 9:14:47 UTC+1 Marek Luthardt napísal(-a):

[cgw...@gmail.com]

Yes I agree with Marek, since version 1.8.3, OSMAND has become disappointing, route calculation very slow and I would say unusable. When selecting 'directions' it brings up multiple windows for selecting 'Wayponts' 'From' and 'To', obviously there should only be one. TTS Voice English has ceased to work, although I have since downloaded English analogue, this is OK.

 

I am running Android 2.3.6

 

Hopefully this can be corrected and return to the great product it was.

[Marek Luthardt]

1. the OSM data along your route could have some bugs, e.g. unconnected roads or wrong speed limits. You could look for those in "OSM Inspector" or "Osmose" web tools.

But the bugs should affect all OSM-based navigation maps in the same way.  But Scout (formerly known as Skobbler) uses OSM too and has no problems in finding good routes within a blink of the eye.

 

2. the OsmAnd routing file contains assumes wrong max speeds depending on road type (e.g. it could think a "ramp" where somebody put maxspeed=130 it faster than the real highway (motorway, where assumed maxspeed is 110). See https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L180 . You can make a customized version of this file and put it in your OsmAnd data folder.

I could do this, but why can't the developers define a version with meaningful default settings?

 

3. increasing slowness of OsmAnd may also be caused by actually increasing data being put into OSM (e.g. more minor roads that OsmAnd must judge now). Depends on the coverage quality of the regions you guys are talking about.

The OSM maps are the basis for Osmand as well as for Scout. So the amount of data should be (nearly) the same for the same region. The size of the map files in MB is also quite the same in both apps. so I would exclude major map differences as the root of problems in Osmand. Besides this: initial route calculation may be influenced by the map size and quality, but the time it takes Osmand to draw the recalculated route after the message for this event appears, is also not acceptable - sometimes it takes 10 to 20 seconds. A time, when in urban environment I have already passed some junctions and missed the recommended route again ...

Today in the morning I tried Nokia Here Beta for Android. Its routing calculation is not as good as with the Scout app, but the speed is overwhelming. The 23 km route through Munich is calculated within 2 seconds, any recalculation while driving is done within less than 1 second. So Scout and Nokia prove, that it's not a hardware issue with my phone (Samsung Galaxy S2) and Scout uses OSM maps, so this really seems to be an issue with Osmands algorithm or software architecture.

[Sander Deryckere]

It's not very fair to compare OsmAnd with Scout. Scout uses some extra data that's not available to OsmAnd. See http://stevecoast.com/2014/05/19/why-openstreetmap-is-now-navigation-ready-for-people-like-you/

The legality of that data is questionable (the ODBL requires you to publish data you merge with OSM), but even if they do contribute the data back, this still means that Scout has better data.

About the rendering speed, JOSM has the same issue. It just goes up because the sheer number of nodes is rising. The only solution is to not render most of the nodes (either to filter features out on a previous step, but filtering also takes time, or to not include all nodes of a feature, which is already partially done).

The routing has the same issue. The more crossings there are, the more possibilities it has to consider. Even when streets are split in the middle, f.e. because the maxspeed changes, it causes a slowdown since two segments have to be processed, more tags have to be read, and the driving time calculation is a bit more difficult to calculate. Here, scout has again the advantage of using GPS-gathered data, that just contains the driving time from crossing to crossing. So only a simple data lookup is needed.

I agree that speed is a major problem, but it's not an easy problem to tackle.

--

[Harry van der Wolf]

2014-12-12 11:07 GMT+01:00 Sander Deryckere <sand...@gmail.com>:

It's not very fair to compare OsmAnd with Scout. Scout uses some extra data that's not available to OsmAnd. See http://stevecoast.com/2014/05/19/why-openstreetmap-is-now-navigation-ready-for-people-like-you/

I did my comparisons only with full OSM based apps (apart from nokia Here which is not ready for android anyway).

In route optimalization OsmAnd seems to drop behind where it was before simply the best available.

In calculation speed  OsmAnd has always been last. In quick recalculations when taking a wrong exit or so, that is really annoying. But also in route calculations where others take 5-30 seconds, OsmAnd takes 2 minutes. Longer routes (+1200 km) are possible in all apps except OsmAnd (max 350-400 in 512MB).

And rendering is slow, even with tricks used.

Harry

[Osmandtrier]

It's not very fair to compare OsmAnd with Scout. Scout uses some extra data that's not available to OsmAnd. See http://stevecoast.com/2014/05/19/why-openstreetmap-is-now-navigation-ready-for-people-like-you/

But it is fair to compare with Brouter. I installed yesterday Brouter. And it is quicker to use the Brouter-interface and change to osmand, calling up the gpx-track, than to wait for the result of osmand.

One year ago was this possibility senseless, because Osmand routing was quicker. The difference of the calculating-speed between osmand and brouter was getting very big in one year.

I was thinking about a three week trip with a bicycle in summer  2015 in germany planning every day trip with osmand. I planned this summer three weeks in England with Osmand. This is now impossible. With Brouter it is possible.

The annoying thing is, there was the possibility of using  a quick routing api and the slower new one. But then the old API was cut off. And the trouble started.  I think it is a sign of being bigheaded.

[Harry van der Wolf]

Just for the record: 

Osmand+ 1.9 and nightly calculate up to 350-400 km and terribly slow (on my device).

I just reinstalled 1.3, which also works with the new maps, and it calculates a route of 834 km, and even faster than 1.9 with 350 km.

Also the map is much snappier.

Harry

[Aceman444]

Dňa piatok, 12. decembra 2014 8:25:51 UTC+1 Marek Luthardt napísal(-a):

2. the OsmAnd routing file contains assumes wrong max speeds depending on road type (e.g. it could think a "ramp" where somebody put maxspeed=130 it faster than the real highway (motorway, where assumed maxspeed is 110). See https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L180 . You can make a customized version of this file and put it in your OsmAnd data folder.

I could do this, but why can't the developers define a version with meaningful default settings?

Because OsmAnd has only one set of default speeds for the whole world. And that is bad, because every country has different speeds. So for now concerned users have to edit their own file for their country.

I am not sure now if I already filed the request in the correct tracker that OsmAnd should support and ship per-country defaults. But it has cropped up in this forum already.
 

3. increasing slowness of OsmAnd may also be caused by actually increasing data being put into OSM (e.g. more minor roads that OsmAnd must judge now). Depends on the coverage quality of the regions you guys are talking about.

The OSM maps are the basis for Osmand as well as for Scout. So the amount of data should be (nearly) the same for the same region. The size of the map files in MB is also quite the same in both apps. so I would exclude major map differences as the root of problems in Osmand. Besides this: initial route calculation may be influenced by the map size and quality, but the time it takes Osmand to draw the recalculated route after the message for this event appears, is also not acceptable - sometimes it takes 10 to 20 seconds. A time, when in urban environment I have already passed some junctions and missed the recommended route again ...

I meant that even if you took OsmAnd 1.3 2 years ago and 1.3 today, you would be using different maps, the one today being much bigger with more data. So even an unchanged OsmAnd code would render slower today. So even if OsmAnd 1.9 had the same renderer as 1.3, it would appear slower.

[Harry van der Wolf]

2014-12-12 18:32 GMT+01:00 Aceman444 <acesha...@gmail.com>:

I meant that even if you took OsmAnd 1.3 2 years ago and 1.3 today, you would be using different maps, the one today being much bigger with more data. So even an unchanged OsmAnd code would render slower today. So even if OsmAnd 1.9 had the same renderer as 1.3, it would appear slower.

Didn't you read my post? It was the one before yours, some 4 hours.

I took the 1.3 version with todays maps and it is much faster in route claculations and can calculate routes more then twice as long: with todays maps.

The maps are built up of several parts: routing,address,  maps (display), POIs and transport.

For routing OsmAnd is using the routing part in the maps which is an indexed set of data. It hasn't grown that much in the past 2 years. The map data has (what is being displayed). Compare maps of 2 years ago with the maps of today and the routing part is not that much bigge. 1.3 is using a different calculation and is therefore much faster. It is said to be less accurate then today, but my experience is differently.

And yes :the 1.3 rendering might be slower with todays maps but it is still much faster with todays maps then 1.9 is.

[Harry van der Wolf]

After 2 days I must admit that the 1.3 routing is less accurate then the new 1.9 routing engine.

[Aceman444]

Less accurate in what way?

Dňa nedeľa, 14. decembra 2014 19:43:04 UTC+1 Harry van der Wolf napísal(-a):

[Harry van der Wolf]

The 1.3 version is less accurate in calculating the correct or optimal route. In long routes it is not a problem and neither in short routes. In routes between 80-150 kilometers it sometimes takes strange "decisions" in what should be the correct route.

The 1.3 version also featured the option to select "less optimal route for longer distances". Even with that option switched off the routes do not always makes sense. I can't remember that, but that may be due to the new maps.

Harry

--

[Max]

The 1.3 version is less accurate in calculating the correct or optimal route. In long routes it is not a problem and neither in short routes. In routes between 80-150 kilometers it sometimes takes strange "decisions" in what should be the correct route.

I think this was the reason why the new "precise routing" was introduced.
Old routing was not reliable.
I think it isn't a problem, if the route has a 5% detour, but it should not be illogical, for example turn left on a residential street just to go back to the primary again (even if it would have been shorter to stay on the primary).
Also route recalculation was often very illogical, you get a completely different result, if OsmAnd recalculates the route, even if you stay on the route (the routing result depends on the distance to the destination, even if you are on the same street).

Regards,
Max

[Harry van der Wolf]

I know that the precise routing has been designed to overcome the flaws of the old routing, but in the latest (nightly) versions I had some minor deviations from the optimal route.

And as mentioned: everything is slow. I don't know whether Victor and Alexey and others have some high-end quad-core über CPU with 1+ GB memory, but on my slightly below average phone it is just too slow. 

Screen drawing is of course related to resolution. Mine has a 1.3GHz dual-core with 800x480 screen (384K pixels), my daughter has a 1.0 GHz dualcore with 480x320 (153.6K pixels) which runs not optimal but quite acceptable.

I assume that handling more then twice as much pixels (= twice as much data to calculate and render) requires a lot more CPU (as far as I know the GPU is not being used at all)

Harry

--

[Max]

as far as I know the GPU is not being used at all

Did you try the new Qt builds?
They use OpenGL.

Regards,
Max

[V S]

Hi All,

Unfortunately I joined that topic quite late. Anyway it's time to answer.

As some people noticed 1.9 and 1.3 has very different routing engine. To be honest that engine was developed before 1.3 but was not released because it was slow. At some point we managed to make a breakthrough and it become comparable. Mostly the speed degraded for bicycle and pedestrian, the value was very clear. Finally the routing became precise and optimal, before it was just suboptimal. We did quite a lot of improvements for car navigation and I would say today it is reasonable and it the best OsmAnd ever had.   

I can't say anything about rendering because rendering engine didn't change between 1.3 and 1.9. So saying it was faster maybe a wrong word, snappier possibly. But I guess FPS widget was existing that time and if I'm not mistaken 1.3 was quite slow if turn on POI to display on the map. So to solve that problem we introduced one more layer of pre-image. And that make app impossible to use for old phone with memory limitation, on new system app is allowed to use up to 50MB, on old Android it was just 20MB. Anyway that layer potentially introduced a delay.

To be quite honest 1.3 was released 2 years ago, so if your phone is older than 3 years that was probably right software. The things are changing and even developers change their phones, nowadays S3 is considered as slow phone (please take into account phone really degrades over time, especially with often install/uninstall). 

So, I know these good old days with 0.6 was running blazingly fast even on slow phones! Please don't forget about limitations and of course our rendering style is 3-4 times complex than it used to be. We want to bring the value and on new phones it is harmless, for old phones I would say please old version, it is fine. Fortunately we don't change map data and maps are still working!

 I think it will be good if switch to concrete points, like route from A to B on device takes > 1 minute (to check), in OsmAndMapCreator it takes 5 seconds ....  

Best Regards,

Victor

[V S]

Getting back to origin of the topic.

>> If I ignore this and stay just on the fast road, the recalculated route is then some kilometers shorter and estimated time of arrival is also some minutes earlier - so why was the initial route suggesting this extra-turns? On my 23-km-route this happens 3 to 4 times!

So I think it will be good the know the source of the problem, you can share part of your route in a private message. In my opinion calculation of 23 km should be under < 15 seconds. And I will try to do as much as possible to find the reason. Please also draw a good route, so it will be clear what is your expectation.

Best Regards,

Victor 

[Osmandtrier]

Scince last week I am using Brouter. I know Brouter scince I know Osmand. I tested it all the times. Brouter had always the better results, but was not very friendly in using. In the beginning it Brouter was slower than Osmand. So it was more comfortable to use the osmand routing.

Now Brouter shows still the better results and is much quicker than Osmand. So it is more comfortable to use Brouter. And you probably know the unfriendly using of Brouter.

I am a long distance cyclist, so I am a kind of challenge.

 In this summer I had to plan for three weeks every day a bicycle trip of 100 km. It was possible with an own created routing in version 1.8.3. The calculation need time, but it was okay. Not more than two minutes. Now Osmand+ is chrashing

Let us summarize Version 1.8.3 2 minutes calculation time versus version 1.9.4 appcrash after 7 minutes.

Releasedate 1.8.3 30.July.2014. Releasedate 1.9.4. 28. November 2014.

Three month from status it is okay to status not possible because of appchrash, is a great job.

By the way Brouter calculates a bicycleroute of 500km in 5 minutes.

So Brouter have the better solution and concept for the routing problem than you. Brouter have the same circumstances like you.

Conclusion, What is the problem, You and the other developers. Not the circumstances. Because other developers do not cause such problems to me.

[Victor Shcherb]

Hi 

>> Conclusion, What is the problem, You and the other developers. Not the circumstances. Because other developers do not cause such problems to me.

Shall I take it personally? I'm not sure the discussion goes in the right direction, if you satisfied with 1.8 more than with 1.9, you would better stay with it. If you like the product you have, you use it. If you would like to get it better, you collaborate. 

I don't see any changes between 1.8 and 1.9 in the routing engine, it could be only route configuration change (routing.xml) which was done by another cyclist and may be not tested enough. 

Best Regards,

Victor

--
You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/DbeRACfoWis/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osmand+un...@googlegroups.com.

[Osmandtrier]

Am Donnerstag, 25. Dezember 2014 22:34:41 UTC+1 schrieb V S:

Hi 

>> Conclusion, What is the problem, You and the other developers. Not the circumstances. Because other developers do not cause such problems to me.

Shall I take it personally? I'm not sure the discussion goes in the right direction, if you satisfied with 1.8 more than with 1.9, you would better stay with it. If you like the product you have, you use it. If you would like to get it better, you collaborate. 

Victor I paid two times for osmand+. Downgrading is not possible with osmand+. I know, what I have to do, to get the old version of an app. But I learned this possibilty because of osmand.

I don't see any changes between 1.8 and 1.9 in the routing engine, it could be only route configuration change (routing.xml) which was done by another cyclist and may be not tested enough. 

And that is the annoying thing, not tested enough. It is typical osmand, working things are changed, not really tested, and I try to find out where the problem is. It is a loose of time. How I said, your efforts cause to much efforts to me. And I think it is to much stress to collabrate with you, to get a better product. You should take this sentence personally.

You take money, and I have troubles. Arndt of Brouter takes no money and cause no trouble. Collabration is in other view helping you getting money for poor quality. And I am fed up of this.

[Marko Mäkelä]

Hi Victor,

On Wednesday, December 24, 2014 20.48.04 UTC+2 V S wrote:

But I guess FPS widget was existing that time and if I'm not mistaken 1.3 was quite slow if turn on POI to display on the map. So to solve that problem we introduced one more layer of pre-image. And that make app impossible to use for old phone with memory limitation, on new system app is allowed to use up to 50MB, on old Android it was just 20MB. Anyway that layer potentially introduced a delay.

To be quite honest 1.3 was released 2 years ago, so if your phone is older than 3 years that was probably right software. The things are changing and even developers change their phones, nowadays S3 is considered as slow phone (please take into account phone really degrades over time, especially with often install/uninstall).

It seems to me that there could be an option for reducing the memory usage, so that the software properly works with older hardware or older Android version. Also with newer phones it could sometimes be a welcome trade-off to have less smooth screen updates if it conserves memory for other applications, so that you can quickly switch between apps.

Unfortunately, it is not always feasible to upgrade the operating system. For example, upgrading the SonyEricsson Xperia Active (which entered the shops 3 years and some months ago) from Android 2.3.4 to 4.0 is a one-way operation. The upgrade brings some annoying misfeatures, such as increased memory consumption. Also, each time the phone is restarted, the GSM network has to be reset to 2G mode (it defaults to 3G). Some time after the upgrade, my phone stopped working (even booting). It came back from the warranty service with the old Android 2.3.4. I am going to keep it at that version until the hardware dies.

For me, the smartphone is just a phone, camera, music player, and navigator. No Internet connection.

I would like an easier build system with some compile-time options for choosing the wanted features and plugins. Maybe there could be an OsmAnd- for a really bare-bones version (even maps would have to be installed externally), or maybe there will be a fork that implements this.