[email protected] 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.
