Not much progress on inter-tile routing yet
Not much too report after spending quite a few hours on this last night. I am trying to understand why some inter-tile connections are good and a lot are bad. I have tried moving points around and rounding coordinates and stuff like that but with no knowledge gained about from the fact that it appears you can zero the bottom 2 bits of the lat/lon values in the nod3 record and it doesn't stop a good inter-tile connection from working. If you zero 3 bits, that stops it being usable. I have tried limiting the size of the NOD3 section to 16 entries, it made no difference. I shall work some more on it tonight. Cheers, Mark
On Feb 18, 2009, at 15:33, Mark Burton wrote:
Not much too report after spending quite a few hours on this last night.
I am trying to understand why some inter-tile connections are good and a lot are bad. I have tried moving points around and rounding coordinates and stuff like that but with no knowledge gained about from the fact that it appears you can zero the bottom 2 bits of the lat/lon values in the nod3 record and it doesn't stop a good inter-tile connection from working. If you zero 3 bits, that stops it being usable.
I have tried limiting the size of the NOD3 section to 16 entries, it made no difference.
Not sure why I never noticed before, but it seems the NOD3 entries have to be ordered by coordinates! Seems obvious, right? The sample I've just checked seems to have them ordered by increasing longitude, but it doesn't have boundary nodes on all edges, so I'm not quite sure this is right... Combined patch against current trunk attached, feedback welcome. Cheers Robert
Yeeha!
Not sure why I never noticed before, but it seems the NOD3 entries have to be ordered by coordinates! Seems obvious, right? The sample I've just checked seems to have them ordered by increasing longitude, but it doesn't have boundary nodes on all edges, so I'm not quite sure this is right...
Combined patch against current trunk attached, feedback welcome.
Robert, you're a genius - that completely fixes it for my test map. I can route across tile boundaries in all directions I attach a new patch that is the same as what you just posted with the addition of this tweak that stops the RoadDef being attached to a Polyline unless the zoom level is 0. I'm working on the basis that the road info doesn't need to be repeated at higher zoom levels. diff --git a/src/uk/me/parabola/mkgmap/build/MapBuilder.java b/src/uk/me/parabola/mkgmap/build/MapBuilder.java index 5e73ca9..c72b482 100644 --- a/src/uk/me/parabola/mkgmap/build/MapBuilder.java +++ b/src/uk/me/parabola/mkgmap/build/MapBuilder.java @@ -603,7 +603,8 @@ public class MapBuilder implements Configurable { pl.setType(line.getType()); - if (doRoads && line.isRoad()) { + if (doRoads && line.isRoad() && + div.getZoom().getLevel() == 0) { if (log.isDebugEnabled()) log.debug("adding road def: " + line.getName()); RoadDef roaddef = ((MapRoad) line).getRoadDef(); The current patch is good for evaluation but it still requires more work because it won't behave well when boundary nodes are generated that are very close to existing nodes. At the moment it throws the boundary node away which isn't very optimal but should stop other things breaking. Robert, what's the constraints on min distances between nodes and points? Can you have a node very close to the next point in a way? Thanks again for the coordinate sorting breakthrough - you saved me a lot of hours work there! Cheers, Mark
On Feb 18, 2009, at 23:32, Mark Burton wrote:
Robert, you're a genius - that completely fixes it for my test map. I can route across tile boundaries in all directions
Great!
The current patch is good for evaluation but it still requires more work because it won't behave well when boundary nodes are generated that are very close to existing nodes. At the moment it throws the boundary node away which isn't very optimal but should stop other things breaking.
Robert, what's the constraints on min distances between nodes and points?
Can you have a node very close to the next point in a way?
I have no idea, really. There's something in the cGPSmapper documentation that claims a minimum distance between nodes of 5.4m. Alex pointed out that this is the minimal arc distance we can encode. But I don't really see a reason in the data format for any kind of minimal distance (apart from the obvious minimum of 1 map unit (360/2**24 degrees)). Does anything actually break if you disregard close nodes? Do these problems remain if RouteArc.convertMeters returns at least 1? By the way, what I wrote earlier regarding boundary nodes and junctions is probably wrong -- the problems I based that guess on are very likely to have been caused by the unsorted boundary nodes. Cheers Robert
Robert,
But I don't really see a reason in the data format for any kind of minimal distance (apart from the obvious minimum of 1 map unit (360/2**24 degrees)).
Does anything actually break if you disregard close nodes? Do these problems remain if RouteArc.convertMeters returns at least 1?
I haven't seen breakage.
By the way, what I wrote earlier regarding boundary nodes and junctions is probably wrong -- the problems I based that guess on are very likely to have been caused by the unsorted boundary nodes.
OK - I'm going to remove the near node removing code - wait till someone has a problem before doing any more there. I'm tempted to commit this stuff to trunk and let people try it out. If it screws anything, we can revert it quickly. What do you think? Cheers, Mark
participants (2)
-
Mark Burton -
Robert Vollmert