Thx for your info. "Conclusion" was probably not my best choice of word. The only conclusion I have is OsmAnd and it's tool set is very powerful and flexible. My strange tangent of experimentation( and I knew I was not the first to think of this) came from my thought that I could use multiple phones in my RV for navigating. For example I could set up one of my old smart phones to have of all of north America (usa and canada), but with only major roads(no residential), to keep the file small, and not burden the old phone with computational difficulties. And a second phone with all the state maps as published on the web. I would have both phones up and running in my RV.
I also have experimented with the roads only maps. Makes it much easier to load up a a lot of maps to prepare for a trip. Although I always have my laptop with me so I could just load maps on the phone as needed. This helps for phones with limited storage but still would be difficult to put all of the USA/Canada on some of my older phones. Also even the roads only maps give the low end phone computational difficulties. Just too many nodes in the route network. Also even though I suspect you are doing a lot of clever stuff to look at the road network from a top-down route problem, direct indexing into the map file to locate data (processed off line during map preparation) as apposed to searching through a file and presorting data based on geographic location for fast access of data near current position, still, there must a penalty of me using OsmAnd with the florida.obf map( that is 419MegByte) on a old phone that has 100MegByte of free ram, a single cpu core, and almost no java heap space. How can my old phone access the data quickly with so little RAM. Isn't linux doing some kind of swap/virtual memory thing on my old phone when processing the large florida map. So I pre-process the 419MB florida map down to 20MB and it runs very smooth on my very old phones. Anyway, for most of my trip, I don't need the residential anyway. Not sure why I'm so hung up on long route calculation. I really don't need to calculate a route more than a few hours into the future. Maybe 200 miles. So I tend to have a lot of favorites/waypoints and just cancel route and calculate a new route every 200 miles. I typically buy low end phones. Very low end. I was motivated to see if it was possible to strip everything to a minimum to get the OsmAnd extremely fast, smooth and interactive even on my $29 phone from 5 years ago. I experimented using the BBBike web site to create much smaller maps. This helped a lot and allowed even my really old phones to run smooth. Of course I'm doing much shorter routes with these smaller maps so that also helped. I was making maps 200km x 200km. And would load each map into OsmAnd as needed(using the OsmAnd map switch needed). But this was to much work. Creating a bunch of very small maps for the US was just too much work. Thanks for the info about the routing.xml. You've just exposed me to a whole new area to explore. I've assumed people a lot smarter than me have spent time optimizing that file to work across a broad range of test cases. But I will explore this area. Yes I did have an issue with a "broken motorway". It was near a state boundary. I investigated very briefly. I looked at the data with iD ( the in browser editor). Involved two long ways (highway=motorway) joined together with a very short way also of type highway=motorway. These ways were part of a "relation", which was unusual compared to most other highway ways. Not sure is this is part of why the osm merge might have had a problem. I got around this by downloading us-south-latest.pbf, convert this to osm, filter this to keep only the major highway stuff (no residential/service). So I no longer needed to merge all the states. Now the routing if working fine. So I suspect the map data is fine. And OsmAnd is fine. Might be an issue with my use of osmconvert64 to merge the all the US states (.osm) into a single large (.osm) Tired of typing now. Thx for your good info. You've give food for thought. OsmAnd rocks! On Saturday, November 24, 2018 at 2:52:17 AM UTC-5, Harry van der Wolf wrote: > > Hi, > > After reading this mail you might consider your end conclusion perhaps too > premature :) > > I have done these kind of things as well somehwere in the past 8 years > where I created for example a "main roads for europe". > I also created maps with all "car" roads also adding "=residential > =living_street". > So like "osmfilter -v <some_file.o5m> --keep="highway=motorway =trunk > =primary =secondary =tertiary =unclassified =road =residential > =living_street =*_link" > <something.o5m> > *(Note that I use the o5m format, not the osm format when possible. It is > binary and therefore smaller and faster)* > *(Note also that I was the writer > of > https://code.google.com/archive/p/osmand/wikis/CreateOfflineMapsForYourself.wiki > > <https://code.google.com/archive/p/osmand/wikis/CreateOfflineMapsForYourself.wiki> > in > 2010 or 2011. It should be updated though as OsmAndMapCreator changed a > little. I wrote more articles at that time about creating/altering/merging > maps*). > And then I started changing the routing.xml which is so much easier and > doesn't require you to create/change all those maps. > > > So after quite some experimenting, I moved away from creating the maps > myself and simply use the roads_only maps in my car. They do of course > contain all(!) roads and cycle/pedestrian paths and the like, but I don't > care. Note that I have full maps on my phone for hiking/walking and cycling. > In my car I have a full android head unit from Joying ( > https://www.joyingauto.com/), where I use OsmAnd with the road_only maps, > but I also use Magic Earth. *(Note also that next to Joying there is > another load of Chinese android head unit brands)* > > Like said: I use a different routing.xml. You can download it from here: > https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml > I changed line 381 ( > https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L381 > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fosmandapp%2FOsmAnd-resources%2Fblob%2Fmaster%2Frouting%2Frouting.xml%23L381&sa=D&sntz=1&usg=AFQjCNE1hFuRkl83NfNayfTlqFUg435jaw>) > > to: > <routingProfile name="car" baseProfile="car" restrictionsAware="true" > minDefaultSpeed="45.0" maxDefaultSpeed="130.0" > leftTurn="5" rightTurn="5" roundaboutTurn="10" onewayAware="true" > heuristicCoefficient="1.4"> > > Now if you do this, the routing becomes aggressively faster. Doing this > makes the routing slighlty less exact, but on short distances (<25 km) that > leads to differences in seconds and who cares. One red traffic light or > busy cross roads and an alternative road is already a few seconds faster. > On long trips of >200 km it doesn't make a difference at all. This also > allows me to create routes of 1400-2000 km. > I experimented with a "heuristicCoefficient" of 1.2, 1.2, 1.3, 1.4 and > 1.5. I even tried some intermediate values. > I used 1.2 and then 1.3 for quite some time but eventually switched to > 1.4. Values of 1.5 become too sloppy and even higher values even become > erroneous, although you still get from A to B. > Note that the routing.xml also gets updated some times, so then you need > to download again and edit again. Place this routing.xml in your OsmAnd > files folder, so between your (normal) maps. > (My first mail about this already in Dec 2014: > https://groups.google.com/forum/#!msg/osmand/nypUdYCW3BI/WnULlAvYOh0J;context-place=topic/osmand/ZXX-nuBpQSc > ) > > > So, now with a heuristicCoefficient=1.4 and roads_only maps in my car I > have exactly what I want. Fast routing from start to end with POIs and > addresses. I do not need all those map details when navigating from A to B. > > Another benefit of using roads_only maps (in the car) is that the > rendering of the maps is much faster: a factor 2x to 3x. I also did > extensive testing on that over the past years and spend quite some mails on > that in the google group. > (You can test this yourself by enabling the OsmAmd development plugin (the > "bottom" one) and then switch on "rendering debug info". Of course that > takes performance as well so switch it off after you are done testing). > For walking and cycling using my phone I do use the full maps as I > like/want those details, but due to the low speeds, rendering performance > is never an issue. > > ===== > You mention the issue with highways going wrong on state sections. This is > an issue in OsmAnd. See > https://github.com/osmandapp/Osmand/issues/4013, and it was not solved > yet in 3.0.4. Don't know about the current 3.2.6 > So that might improve in (short?) time. > > 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]. For more options, visit https://groups.google.com/d/optout.
