thx for the info. Both OsmAnd and the map I created using usa-south-latest-osm.pbf (which avoids merging) Are working fine. So I will stop using the other method of map creation. No real problem to report at this time. Not quite sure why I am even pursuing this other than to learn a little about OsmAnd and its tools. And I guess also a desire to get OsmAnd running fast on a some old low end phones that I still have. As a 61 year old retired electrical engineer I'm kind of blown away at how much power I can hold in my hands. When I join the work force a CRAY 1 ran at 100Mhz and had 64MB of memory. My cell phone is 10 times that. Jeez. Kevin
On Saturday, November 24, 2018 at 9:56:36 AM UTC-5, Greg Troxel wrote: > > [email protected] <javascript:> writes: > > > Sorry if this seems like am beating a dead horse on a boring topic. > > But it seems my flow has problems. Using osmconvert and osmfilter and > > create a final merge southeast_usa.obf that allows fast routing has > > serious problems. > > > > At state boundaries I am getting severed interstate highways. Found by > > a refusal route down a single section of highway. If I just filter > > each state to keep only the high level roads and then bring in each > > state separately and let osmand manage the routing across each states > > .obf file, it all looks good. So I can not create single merged > > version of a filtered .obf file. I apologize if I am lost in the > > woods here. But it has been an useful learning experiment for me. > > This sort of problem has cropped up in multiple places (in the osm > database itself, in garmin maps). The basic issue is that the routing > program has to view the roads as connected in order to route across > them. > > That means, more or less, that there is a node that is a member of the > way coming from one state and also a member of the way going into the > other state. It is critical that this be the same node, not a second > node with the same coordinates! > > In the osm case, roads were imported from the state of Massachusetts per > town, and each road that reached a boundary had its own node on the > boundary, which matched exactly the node from the next town -- but was a > distinct node. So the map *looked* perfect. But you could not route > across boundaries. People hand-fixed the big roads and routing got > better but was odd, and then there was a bot edit to fix this. (Despite > this trouble, it left Massachusetts in great shape because the > underlying road data was very high quality.) > > In the garmin case, I built maps with mkgmap from geofabrik extracts of > states, using splitter on the union of the maps. I ma not really clear > on what was wrong exactly, but it really felt like the same thing. > > To avoid this, there are two key techniques. One is to have an extended > polygon around the state one is cutting to, so that every way that > crosses the line will have at least one node on the other side of the > boundary. Usually nodes are frequent enough that say 500m is enough. > > The second is to make sure that the process that joins things back is > able to see nodes with the same coordinates and merge them to be the > same node. > > So it sounds like from your description that osmand is used to the > concept of having a node at a boundary and matching that itself with a > different node with the same coordinates on the boundary -- that came > from the other side. Probably these nodes have some special code. > > But if you are doing this splitting/merging into one obf, that special > processing should not be necessary -- because it should have been done > at merge time. > > Probably if you fix that, you will get routing ok. > -- 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.
