fast routing (sorry for so much on my little experiment)

[k***@gmail.com]

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.

I will stay with a simple filtering of each state to create a fast route
version, and
let osmand manage an .obf file for each state. This means my laptop is
more than up to the job of creating files I need.
Kevin

Kevin

[Greg Troxel]

Post by k***@gmail.com
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.

[k***@gmail.com]

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

Post by Greg Troxel

Post by k***@gmail.com
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.