Hi Stefan,
> in the archive (september 2009) I saw that there were some discussion about
> inter tile routing problems. I use version 1445 and have the same problem
> when doing a routing in Mapsource over 4 interceptions. 3 interceptions
> working fine.
>
> Are there some news about that issue?
Hello,
in the archive (september 2009) I saw that there were some discussion about
inter tile routing problems. I use version 1445 and have the same problem
when doing a routing in Mapsource over 4 interceptions. 3 interceptions
working fine.
Are there some news about that issue?
Another questio
Hi Michael,
> --ignore-osm-bounds
If you ignore the bounds, the ways don't end at the same coordinates.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
MB> I haven't the faintest clue what could be the issue here so until we
MB> get some hint as to what the problem could be, I'm ignoring it.
MB> I simply don't have spare time to dream up possible reasons why
MB> this problem exists.
Can't say I blame you, doesn't sound like an easy one to get to
Hi Chris,
> Sorry to say I too have tried to find a problem with the Garmin maps and
> failed. No matter what combination of tile crossings, it always seems to do
> the right thing. I probably tried 20-30 combinations of routes across various
> tile borders. Is that a big enough sample size to
Hey Mark,
MB> Is that using mapsource and if so, what version is that?
Yes MapSource, v6.15.6
MB> The picture was corrupted, I could not see it.
Damn, probably something to do with this NNTP client of mine :(
Try here: http://redyeti.net/routing.png
Chris
__
Hi Chris,
> Sorry to say I too have tried to find a problem with the Garmin maps and
> failed. No matter what combination of tile crossings, it always seems to do
> the right thing. I probably tried 20-30 combinations of routes across various
> tile borders. Is that a big enough sample size to
Apollinaris Schoell wrote:
> did some experiments in Mapsource and Garmin maps don't suffer from this
> problem.found a place where the direction of the route defines which way
> is chosen. makes perfect sense because right turns are faster and easier
> than left turns.
> Mapsource will even choose
did some experiments in Mapsource and Garmin maps don't suffer from this
problem.found a place where the direction of the route defines which way
is chosen. makes perfect sense because right turns are faster and easier
than left turns.
Mapsource will even choose the longer way across the tile bound
Using a recent GB tiled map on my eTrex, I have found that it performs
differently (better?) to mapsource with regard to the problem of not
routing across a boundary and back to the source tile.
An example route I tried used a road that snaked across a boundary.
Mapsource failed miserably in the
Hi Mark,
MB> The bug can easily be reproduced by finding a road on tile A that
MB> forks on one side of a boundary and both of the forkees? cross the
MB> boundary to tile B. You then try and route between the ways on tile
MB> B. Sometimes it works OK and sometimes not. Another example is
MB> simpl
Hi Chris,
> When I get a chance in the next couple of days, I'll have a play around with
> some of the official Garmin maps and see if they can be made to exhibit the
> same problem. If so then the limitation is most likely in the routing
> algorithm
> in MapSource and/or on the device. If th
MB> There is a particular failure of inter-tile routing that we have
MB> seen quite often which is that it fails to find a route when the
MB> source and destination are in the same tile and the only (sensible)
MB> route is via another tile. (If a sub-optimal route that only uses
MB> the source tile
Mark Burton schreef:
> There is a particular failure of inter-tile routing that we have seen
> quite often which is that it fails to find a route when the source and
> destination are in the same tile and the only (sensible) route is via
> another tile. (If a sub-optimal route that only uses the so
There is a particular failure of inter-tile routing that we have seen
quite often which is that it fails to find a route when the source and
destination are in the same tile and the only (sensible) route is via
another tile. (If a sub-optimal route that only uses the source tile is
available that
Felix Hartmann escribió:
> I bet you used --ignore-osm-bounds option on compiling!
>
You win. That was the origin of the problem. I remember having read
something about --ignore-osm-bounds affecting routing in the list or
somewhere else some time ago, but I didn't take care of it :-[ .
Cheer
I bet you used --ignore-osm-bounds option on compiling!
Carlos Dávila wrote:
> Yesterday I realized I can no longer calculate routes involving more
> than one tile in Mapsource using my Spain map. I compile it daily using
> latest svn and I don't know when the problem was introduced (it worked
Yesterday I realized I can no longer calculate routes involving more
than one tile in Mapsource using my Spain map. I compile it daily using
latest svn and I don't know when the problem was introduced (it worked
fine last time I checked it). I have tried splitting the map with latest
splitter from
18 matches
Mail list logo