To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing across tiles is not working...
Gerd,
Complementing the information, the versions used are:- splitter: 421 compiled
2015-01-10T20:01:10+- mkgmap: 3449
2015-02-18 13:09 GMT-02:00 Alexandre Loss alexandre.l...@gmail.com:
Hi Gerd
-jar d:\splitter\dist\splitter.jar --num-tiles=6 --mixed
--keep-complete=false MG.osm splitter.log
Gerd
--
Date: Wed, 18 Feb 2015 13:16:01 -0200
From: alexandre.l...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing across tiles
-complete=false MG.osm splitter.log
Gerd
--
Date: Wed, 18 Feb 2015 13:16:01 -0200
From:
alexandre.loss@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Routing across tiles is not working...
Gerd,
Complementing the information, the versions used
Hi Alexandre,
it seems the problem is in the mg.osm file.
It is not sorted so that all nodes appear before all ways, and ways before
relations, also nodes are not sorted by id.
The tool osmconvert seems to hang when reading it.
Unfortunately, splitter doesn't recognize a problem
when reading the
Hi Gerd,
I'm out of my desk now, but I will provide all information as soon I return
home.
Thanks you for promptly answer my question.
Alexandre
(Enviado via iPad)
Em 18/02/2015, às 10:03, GerdP gpetermann_muenc...@hotmail.com escreveu:
Hi Alexandre,
I assume you use the latest trunk
Hi Alexandre,
I assume you use the latest trunk versions of splitter and mkgmap
and the routing problem occurs only at the tile borders?
It is difficult to say what's going wrong without any hints about the
data you use and the program options for splitter and mkgmap.
Please try to report these
Hi Gerd,
Following more information about my compilation:
1. Splitter command: java -jar ../ferramentas/splitter.jar --num-tiles=6
MG.osm
2. mkgmap command:
java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar
--x-split-name-index
Gerd,
Complementing the information, the versions used are:
- splitter: 421 compiled 2015-01-10T20:01:10+
- mkgmap: 3449
2015-02-18 13:09 GMT-02:00 Alexandre Loss alexandre.l...@gmail.com:
Hi Gerd,
Following more information about my compilation:
1. Splitter command: java -jar
I experienced the same issue with a my new Montana 600... I first realized
it when I miss a turn and magically I gained 5 mins.
Now I guess I know why!
On Tue, Aug 19, 2014 at 6:56 PM, Bernhard Hiller b...@gmx.de wrote:
Cze´sć Andrzej,
thanks for this (bad) information. Looks like the
Cze´sć Andrzej,
thanks for this (bad) information. Looks like the Oregon 600 (an outdoor
device) uses the newer algorithm.
Well, it means, I can now stop optimizing for the correct route, and
perhaps rather try to optimize the calculated time for the selected
route (i.e. get it closer to my
Hi Bernhard,
Garmin has 2 version of routing algorithm, older and newer. Older is
used by Mapsource, older nuvi, probably by outdoor devices. Newer
algorithm is used by BaseCamp and last 2-3 generations of nuvi.
Newer algorithm is designed for speed of calculation rather than quality
of
When selecting Minimize Distance, the result conforms with the
expectations: the shortest route is selected by the Garmin Oregon 600.
But with Minimize Time, things are different. It is not at all the
route with the shortest time.
By setting a Via Point, I can have it calculating my preferred
Chapter 4.6.5 of the style manual shwos a table with road speeds and its
corresponding highest speeds.
I created a small test map with roads of ca. 100 km length of all 5
road_types and added speed limits which translate into the 8 different
road_speed codes with the current (v3310) default
Hi Steve,
thanks. I've corrected one small error with r341.
Gerd
Date: Thu, 16 Jan 2014 19:50:24 +
From: st...@parabola.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing
On 16/01/14 12:51, Gerd Petermann wrote:
please note that nod.txt still claims
Hi Steve,
please note that nod.txt still claims that road class mask is 0x03.
I assume that you still work on it?
Gerd
Date: Wed, 15 Jan 2014 04:55:19 -0800
From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing
Hi Steve,
crossing
On 16/01/14 12:51, Gerd Petermann wrote:
please note that nod.txt still claims that road class mask is 0x03.
I assume that you still work on it?
Thanks. I've fixed it and added made a few other changes.
There is still a bit more to add.
___
Hi Gerd
Attached is a small excerpt of my output file containing the
header and the first lines of NOD1.
That file seems to be in a completely different format, too many zeros
at the beginning. You would have to use NOD2 to get the node addresses
and then work out why there was a gap at the
Date: Wed, 15 Jan 2014 09:38:45 +
From: st...@parabola.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing
Hi Gerd
Attached is a small excerpt of my output file containing the
header and the first lines of NOD1.
That file seems to be in a completely
Hi Gerd
Ahh, I had a look at a basemap, and it has similar problems.
It seems there is only one node with no arcs in a section, verified
from NOD 2. So you are right that the skip on zero is incorrect for
this file, since the 'low' byte really should be zero. But there is
also another case
Hi Steve,
crossing my fingers!
Gerd
Steve Ratcliffe wrote
Hi Gerd
Ahh, I had a look at a basemap, and it has similar problems.
It seems there is only one node with no arcs in a section, verified
from NOD 2. So you are right that the skip on zero is incorrect for
this file, since the
Hi Gerd,
I think that means that my file doesn't help much to learn
what format we should write. I am not even
sure if it is really routable, it's just my only one
that contains a NOD file.
There are many free samples of Garmin maps, that you can use for tests.
For example:
Hi Andrzej,
thanks for the hint, but aren't they all in NT-format or not routable?
Gerd
Date: Wed, 15 Jan 2014 15:10:50 +0100
From: po...@poczta.onet.pl
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing
Hi Gerd,
I think that means that my file doesn't help much
ahh, did not see your remark in the last line. I'll try them.
Gerd
GerdP wrote
Hi Andrzej,
thanks for the hint, but aren't they all in NT-format or not routable?
Gerd
Date: Wed, 15 Jan 2014 15:10:50 +0100
From:
popej@.onet
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev
Hi
I've been looking into routing and I have updated NodDisplay
so that it mostly works on any file.
I've not discovered much that wasn't known before, apart from
a compact way of storing directions that is probably suitable
for short roads. There is a destination road-class field in
the node
From: st...@parabola.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Routing
Hi
I've been looking into routing and I have updated NodDisplay
so that it mostly works on any file.
I've not discovered much that wasn't known before, apart from
a compact way of storing directions
Hi Gerd,
the new NodDisplay tool reports a lot of errors for files
that were created with latest mkgmap .
I see lost sync messages as well as things like
error INVALID node, low=0, tabpos=83f, max=30bf
Thanks for reporting.
If you also see 'unknown alt6 0x4 flag' earlier in the same
node
Hi Steve,
yes, I see 'unknown alt6 0x4 flag' a few lines before the
error message.
Gerd
Date: Tue, 14 Jan 2014 15:38:11 +
From: st...@parabola.me.uk
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing
Hi Gerd,
the new NodDisplay tool reports a lot of errors
On 14/01/14 15:48, Gerd Petermann wrote:
yes, I see 'unknown alt6 0x4 flag' a few lines before the
error message.
Ah, road-class can go from 0-4 and so does go into 3 bits like the
code previously had it. I had got convinced that there was just 4
different values...
So bit 0x04 is part of
Hi
I've made a few more fixes and I now don't get any
error where it mis-reads the file and gets out of sync.
So let me know if you find any now.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
Nice simple test case. I can reproduce on a similar version of mapsource
that you used, but not on an older version.
I hope you can reproduce the problem and find out what goes wrong...
Interestingly if set to shortest time and avoid u-turns, then it goes
straight down w1, w2 and
Hi Steve,
Nice simple test case. I can reproduce on a similar version of mapsource
that you used, but not on an older version.
I hope you can reproduce the problem and find out what goes wrong...
Interestingly if set to shortest time and avoid u-turns, then it goes
straight down w1, w2
Hi,
I have no idea how to find the right order in a network.
In NOD3, we sort the nodes lexicographically by longitude, then latitude.
Maybe we should do the same for NOD1?
Tried that. It fixes the problems in my test case, but creates similar problems
in other cases, so sorting seems not
Hi all,
really confusing...
The strange bug disappears in MapSource (6.16.3) when I (re-)activate option
Try to avoid..
U-turns
In Basecamp (4.25) , the bug appears as well when I deactivate Feature type
avoidance
U-Turns.
Regarding the order of the ways in the OSM file:
It seems that the only
Hi Steve,
I think I found a very old bug in mkgmap, it seems to exist since at least
r2210.
I found it while testing a patch for r2914 and found it in all older versions
that I tried.
Attached are two test files and a gdb for MapSource.
The command that I use:
java -jar
Hi,
I have commited the new (undocumented) option --x-no-mergeroads to
disable merging of roads. I think this is useful for chasing problems.
WanMil
Hi Steve,
I think I found a very old bug in mkgmap, it seems to exist since at
least r2210.
I found it while testing a patch for r2914 and
Thanks Gerd.
Given that using routable types in this way is known to be a problem, I'll
just stop using them.
Steve
On 20 June 2013 05:43, GerdP gpetermann_muenc...@hotmail.com wrote:
Steve Brophy wrote
Upon further investigation, I think this is caused by my use of routable
types as
Upon further investigation, I think this is caused by my use of routable
types as non-routing overlays on roundabouts. When I stop using them, the
problem goes away.
Strange that this didn't cause a problem with earlier mkgmap builds.
Steve
On 19 June 2013 20:27, Steve Brophy
Steve Brophy wrote
Upon further investigation, I think this is caused by my use of routable
types as non-routing overlays on roundabouts. When I stop using them, the
problem goes away.
ok, this is a known problem and --check-styles will help here.
Steve Brophy wrote
Strange that this didn't
Hi,
Garmin will do strange loops when routing this way:
http://osrm.at/3yV
(OSRM is routing correctly here).
Default mkgmap style. V2606
Options:
description=OSM_CityMap
series-name=OSM_CityMap
family-name=OSM_CityMap
country-name=Deutschland
country-abbr=DEU
family-id=66
product-id=1
Hi Chriss,
I can reproduce it with r2644, and I guess it is an old problem.
I don't know why, but the road
http://www.openstreetmap.org/browse/way/23101541
which is tagged with motorcycle=no
sets this road as not routable for cars because
motorcar and motorcycle have the same hard coded
Am 10.06.2013 15:34, schrieb GerdP:
I can reproduce it with r2644, and I guess it is an old problem.
I don't know why, but the road
http://www.openstreetmap.org/browse/way/23101541
which is tagged with motorcycle=no
sets this road as not routable for cars because
motorcar and
Am 10.06.2013 17:06, schrieb chris66:
Thank you for the quick solution. Indeed when I remove
the motorcycle=yes in my local osm file routing is ok.
-yes +no
Should we add a rule in default style to delete motorcycle ?
Chris
___
mkgmap-dev
Hi Chris,
don't know. A person that wants to create a map for a motorcycle needs it.
I have no idea why the Garmin IMG format doesn't separate between cars and
motorcycles.
Gerd
Chris66 wrote
Am 10.06.2013 17:06, schrieb chris66:
Thank you for the quick solution. Indeed when I remove
the
Hi Gerd,
maybe it would be better to have for each Garmin-routing-group a
mkgmap:*-tag. E.g. mkgmap:car=*
These tags have to be set in style-file. So you have full control about
it and no black box.
Henning
Am 10.06.2013 20:21, schrieb GerdP:
Hi Chris,
don't know. A person that wants to
Hi all,
Garmin has special devices zümo for motorcycles:
http://sites.garmin.com/zumo/
The manual shows that they have a motorcycle mode and a motorcar mode,
so it seems that at least NT maps are able to distinguish between them.
I don't know if old img format also does that, but I found no
Hi,
for details see also
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756068.html
For those that did not follow this thread:
I hope we found the explanation for some strange routing problems which
occur in combination
with styles that assign routable
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function is_connected may help a little.
Also ORS is not able to find a foot-route to the hospital:
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function is_connected may help a little.
Also ORS is not able to find a foot-route to the hospital:
Strange it seems for me ORS is working,
http://www.zimagez.com/zimage/screenshot-04062013-095909pm.php
On Fri, Apr 5, 2013 at 11:36 AM, chris66 chris66...@gmx.de wrote:
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing
Am 06.04.2013 22:04, schrieb Enrico Liboni:
Strange it seems for me ORS is working,
Yes, because you have set ORS to car mode. The highway=steps are not
routable for cars, so in car mode they are no routing-islands.
Garmin is working a little bit different, because the routing network
is the
Marko, Chris
thanks a lot, I'll give a try with the styles - actually I'm not using
any custom style. One strange behavior I loaded the very same map in
another Garmin device (different model) and I can route to it properly -
but I did not disable the basemap so maybe it's defaulting to it and
On Thu, Apr 04, 2013 at 11:05:55PM +0200, Enrico Liboni wrote:
One strange behavior I loaded the very same map in another Garmin
device (different model) and I can route to it properly - but I did not
disable the basemap so maybe it's defaulting to it and since it is
surely different from the
On Sun, Mar 31, 2013 at 12:38:25AM +0100, Enrico Liboni wrote:
Back to the POI I was experiencing the issue with, if I try to reach it
now, the device does not try even to calculate the route, as if the POI
was really not defined correctly. If I navigate to another POI in front
of the former or
Am 31.03.2013 09:45, schrieb Marko Mäkelä:
Look at the ways around the POI. Could the nearest routeable way be a
routing island (not connected to the rest of the road network, for
example because of a missing junction node)?
The only routing island I find in this area is this footway:
Hello,
one of the users from my bicycle map reported to me a strange error:
When he selects the pedestrian mode in Mapsource the routing at tile
borders goes really bad.
A trip line of sight about 250m is routed showing a really long detour
Am 31.03.2013 12:23, schrieb chris66:
The only routing island I find in this area is this footway:
Also could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function
Am 31.03.2013 13:22, schrieb chris66:
The new mkgmap function is_connected may help a little.
So what you could try in your style:
highway=steps {add mkgmap:check_connected = true}
preceeding your ordinary highway=steps ...
Chris
___
mkgmap-dev
Do you use toll=yes in your scripts? I have the same issue , does it route if
you select avoid toll roads?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Minko ligfiet...@online.nl wrote:
Do you use toll=yes in your scripts? I have the same issue , does it
route if you select avoid toll roads?
Yes, I use toll=yes, but only for high traffic roads without a cycleway, so
he roads in the Exempel do not have toll=yes
Greetings
Johannes
Folks, I'm sometime getting routing issues to some POIs - most seems ok but
some are always showing the problem. I'm wondering if what I'm hitting is
the problem described at:
http://wiki.openstreetmap.org/wiki/Mkgmap/known_issues#add-pois-to-areas_sometimes_places_the_POI_outside_the_polygon
Him
On Sat, Mar 30, Enrico Liboni wrote:
Folks, I'm sometime getting routing issues to some POIs - most seems ok but
some are always showing the problem. I'm wondering if what I'm hitting is
the problem described at:
If I go to Tools-Settings-Map-Map Info only the OSM map is enabled.
However I believe the basemap - if I understood correctly what the
basemap is - is always enabled
by default since when zooming out I can see mountains and (high)ways
outside the tiles I used for my osm map.
I tried by renaming
On Sat, Mar 30, Enrico Liboni wrote:
If I go to Tools-Settings-Map-Map Info only the OSM map is enabled.
However I believe the basemap - if I understood correctly what the
basemap is - is always enabled
by default since when zooming out I can see mountains and (high)ways
outside the tiles
Thorsten many thanks for your help!!!
My osm generated map is routable and I was wrong in my previous post: I did
some further tests with renaming the base map to gmapbmap.iii - so the
device can't use the basemap - and I can properly navigate to address/pois,
just in some pretty long routes
2013 22:44:12 +0200
From: marko.mak...@iki.fi
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Routing graph analysis
Hi Gerd,
I wrote some months ago about a possible project to highlight
dead-ends on the map, but nobody replied. I think it should be a set
of 'dead-end
Gerd,
Tested today with 2530 and everything appears to be fine. Time to update
my GPS map with the new one.
Francisco
On 3/16/2013 2:01 PM, chris66 wrote:
Am 16.03.2013 18:37, schrieb Francisco Moraes:
Gerd,
I don't see a version 2530 for download yet, only 2529.
Francisco
Note on
Hi Geoff,
In both cases, the paths were not joined up in the OSM data. I have fixed
it now.
Steve
On 16 March 2013 11:47, Geoff Sherlock geoffrey_sherl...@btinternet.comwrote:
Hi,
I generate routable maps for walking in the UK, but have come across a
couple of problems trying to route
Strange, I checked for that in JOSM at least I did for the bridleway?!
Perhaps I need glasses ;-)
Thanks for the corrections, I'll give it a test.
Cheers, Geoff
Steve Brophy steve.bro...@gmail.com wrote:
Hi Geoff,
In both cases, the paths were not joined up in the OSM data. I have
fixed
it
Hi,
I've noticed some strange routing on certain junctions, where it either
gives me a routing error on MapSource/Basecamp or the GPS does something
crazy, like a zigzag or a direct line that doesn't follow a road. I can
show a picture of basecamp showing the problem.
I've generated the map
Hi Francisco,
please try if you can reproduce the problem with r2530. A routing error was
fixed with 2475.
Gerd
Francisco Moraes wrote
Hi,
I've noticed some strange routing on certain junctions, where it either
gives me a routing error on MapSource/Basecamp or the GPS does something
page than in JOSM).
Cheers, Geoff.
From: Geoff Sherlock
Sent: Saturday, March 16, 2013 3:08 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Routing Problems in Mapsource
Steve, thanks for that, I do need glasses!
First routing problem now fixed (could see the change you made
Gerd,
I don't see a version 2530 for download yet, only 2529.
Francisco
On 3/16/2013 12:21 PM, GerdP wrote:
Hi Francisco,
please try if you can reproduce the problem with r2530. A routing error was
fixed with 2475.
___
mkgmap-dev mailing list
Am 16.03.2013 18:37, schrieb Francisco Moraes:
Gerd,
I don't see a version 2530 for download yet, only 2529.
Francisco
Note on download page:
These snapshots are created automatically each night when there are
changes.
r2530 was commited today, so you will see this in the download folder
Hi Gerd,
I wrote some months ago about a possible project to highlight
dead-ends on the map, but nobody replied. I think it should be a set
of 'dead-end layers', one for each mode of routing. Then you could
easily survey all those nearby suspectable cases when going for a walk
or a bicycle
Road class can be tweaked to make the road more preferred. The results
are obvious especially on a longer routes.
Unfortunately if you have too much roads on a higher class the routing
time can be seriously impacted.
On 02/08/2013 09:35 PM, mkgmap-...@salo.mailrange.com wrote:
Yeah, but it
El 08/02/13 20:31, GerdP escribió:
yes, --ignore-maxspeed is useful if you want to use the maps for biking
Not only for biking. It's also useful for car routing to get more
accurate route time calculation, taking advantage of maxspeed tag in OSM
data, and thus to better calculate fastest route.
Hi there!
we are having a problem with the maps: In some cases, the routing uses
streets that don't exist!
Here's a video that shows the problem:
http://www.youtube.com/watch?v=SUG370VDBFY
We are using the following commands with r2479:
wget -O map1.osm
Thanks Jaakko, I'm pretty sure that the problem is indeed related to
gmapbmap.img (the wrong street has the same shape as one of the
streets that show up when I disable my gmapsupp.img).
However, when I delete the gmapbmap.img, I loose routing capabilities to
many of the POIs and addresses! Is
I think it makes a lot of sense. Maybe I should clarify it further:
- If I calculate a route that is completely within the top part of the
island, everything's fine.
- If I calculate a route that is completely within the bottom part of
the island, everything's fine.
- If I calculate a route that
In general it is not possible to download data this way and combine it.
There is a high chance that the boundary nodes are missing and that is
where routing brakes. To some extend Garmin devices will fix missing
connections and fall back to the basemap routing to find a rout between
tiles.
It is
Thanks guys. Getting it from overpass now as a whole. Still, as long as
the base map is there, it will sometimes use the streets from the base
map. But it's okay for me to delete the base map. Sad that there isn't a
nicer solution.
Another problem that I have is that the routing is not giving
Hi Fabian,
yes, --ignore-maxspeed is useful if you want to use the maps for biking
Gerd
Fabian S. wrote
Thanks guys. Getting it from overpass now as a whole. Still, as long as
the base map is there, it will sometimes use the streets from the base
map. But it's okay for me to delete the base
Yeah, but it still doesn't use the highway as often as it should. I'm
wondering if Garmin's routing algorithm actually gives any precedence to
highways if they have the same maxspeed as a normal street? Do I have to
increase the maxspeed of the highway ever so slightly to make it more
attractive?
0x11501 is not a routable line type so thats why the routing breaks.
Use it as overlay like in your second example, thats's right thing to do.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Thanks Minko, I guess that is why the bridge worked - it was always an overlay.
Is there anywhere to say which codes are routeable, or is it try it and see (I
guess it needs to be a low number).
Cheers, Geoff.
Minko ligfiet...@online.nl wrote:
0x11501 is not a routable line type so thats
The type you've picked for tunnels (0x11501) is not routable.
On 11 Dec 2012, at 21:24, Geoff Sherlock geoffrey_sherl...@btinternet.com
wrote:
I decided I wanted to show bridges and tunnels on my maps; bridges were easy
but I have trouble with tunnels.
If I try the following as a
Thanks Minko, I guess that is why the bridge worked - it was always an
overlay. Is there anywhere to say which codes are routeable, or is it
try it and see (I guess it needs to be a low number).
As far as I know only these are routable (except 0x14?)
R HexDescription
Y 0x01 1 Major
Thanks again Minko, I may have to do some swapping. I think I tried 0x0b before
but it did not show in basecamp, but as it's free I'll give it a go.
Cheers, Geoff.
Minko ligfiet...@online.nl wrote:
Thanks Minko, I guess that is why the bridge worked - it was always
an
overlay. Is there
-
From: Minko
Sent: Tuesday, December 11, 2012 6:18 PM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Routing and tunnels
Thanks Minko, I guess that is why the bridge worked - it was always an
overlay. Is there anywhere to say which codes are routeable, or is it
try it and see (I
in some of the new versions of either osm, or pbf extensions , the
routing is now broken , because of the number of ways has reached
32767 espeically from http://download.geofabrik.de/
also now the new version of australia-oceania is now on a 0x200 and
the tile splitter , now spits the dummy at
One of my cycle map users reported an issue about non routable roads across
tile borders.
I investigated the case and came to the following conclusion:
-roads marked with toll=yes are not routable across a tile border in case of
pedestrian routing.
-within the tile itself, routing is ok
-Car
I am having problems with the following intersection between the N402 and the
N201 on my generated map:
http://www.openstreetmap.org/?lat=52.22506lon=5.01017zoom=16
The problem occurs on the N201 at the point where the two one-way roads merge
again, just to the west of the intersection.
On 2:59 PM, Francisco Moraes wrote:
Can you download the region around your route and compile it with
mkgmap with logging enabled? Does it complain anything relevant?
I will try it tomorrow if I hae time.
I did this yesterday and generated a map and didn't see any issues on
the mkgmap log.
On Wed, Jan 11, 2012 at 10:02:16AM -0500, Francisco Moraes wrote:
I did this yesterday and generated a map and didn't see any issues on
the mkgmap log. Mapsource routing works fine. I tried to test it on the
GPS, but the move to location didn't appear to be working, so I can't
verify the
On Oregon you can force it with setting GPS-mode to GPS-simulation. Now
you can route to any point and the Oregon can jump to that point or
simulate the route.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Fri, Jan 06, 2012 at 06:05:06PM -0500, Francisco Moraes wrote:
I have seen some strange routing issues with the way below. If I am
driving south, my GPS wants me to make a U-turn where the divided
highway ends. It seems like the ways are not connected but I checked and
I can't find anything
On 2:59 PM, Henning Scholland wrote:
Hi
The fault is in osm-data. There is no turn restriction tagged. I've
added such an restriction.
But why do I need the turn restriction here? I haven't seen this type of
routing problem in other roads that have a similar layout where the
split/divided ways
On Sat, Jan 07, 2012 at 09:13:25AM -0500, Francisco Moraes wrote:
But why do I need the turn restriction here? I haven't seen this type
of routing problem in other roads that have a similar layout where the
split/divided ways merge into one. I thought there would be some
discontinuity somewhere
On 2:59 PM, Marko Mäkelä wrote:
One idea is the observation that in the USA (at least California), it
seems to be common to have compulsory U-turns. On a divided street,
the divider would not be interrupted in every crossing, like it
usually is in Europe. But in this case, the Hopson Rd/Louis
On 2:59 PM, Marko Mäkelä wrote:
Right, that's why I asked where you were heading to and what the
routing suggestion looked like. Was the Garmin unit configured to
auto-recalculate, and was there some bad coverage (tunnels) that
caused it to jump somewhere else and back? Or could there be some
101 - 200 of 402 matches
Mail list logo
