Hi,
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 wrong in the OSM data.
Hi
The fault is in osm-data. There is no turn restriction tagged. I've
added such an restriction.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I use carpool lanes to avoid cars from cycleways - and it works fine.
highway = radweg {add mkgmap:carpool=1}
highway = radweg {add access = no; add bicycle = yes; add foot = yes}
Regards Klaus
--
View this message in context:
Am 22.11.2011 09:30, schrieb toc-rox:
highway = radweg
Wie wär's mit 'highway=cycleway', oder fällt dies auch unter die
Kategorie 'jeder kann amchen, was er will.'
--
PGP Schlüssel: 311D1055
http://keyserver.pgp.com
___
mkgmap-dev mailing list
In Basecamp, I tested the routing on one highway=unclassified and added extra
tags in my style file.
Here are some test results:
highway=unclassified
{ set motorcar=no; set motorcycle=no } or
{ set motorcar=no } or
{ set motorcycle=no } or
{ set access=no }
- carpool avoidance NOT
Your testing rubbish, sorry to say so.
mkgmap:carpool is more or less equal to access=no; it should actually
never be implemented in a map, as it mainly causes trouble, there is not
proper use for it.
destination and no should be handled equally by mkgmap, Garmin only
knows no or yes. So if
Check it your self Felix, I'm not talking non sense. Chris confirmed this too.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Just check up the the list on carpool. There is an old post by Mark that
explains what it does. But go ahead with the carpool stuff if you like
to. I don't think carpool is useful at all and you can achieve the same
things otherwise. Moreover I take you destination difference 100%
attributed
Actually see here what carpool means from the person who implemented it
( it is therefore in reality no avoidance, but just an combined setting
of no on several vehicles):
/That's because the carpoolness of a way is specified by
having all of the access bits except for CARPOOL, EMERGENCY (and,
Am 18.11.2011 13:04, schrieb Minko:
Interesting tests Chris.
I wonder how this works out on Basecamp? I've noticed that using 'avoid
carpool' the routing gets very unpredictable, but maybe because I don't use
it in my styles.
In BaseCamp (v3.2.2) it's more or less the same:
Am 17.11.2011 19:17, schrieb Chris66:
but I think 'mkgmap:carpool' flag is not
working.
More testing with this flag on my etrex 20:
it don't works if set alone (without other access flags).
what works:
mkgmap:carpool=1 + access=no
blocks motorcars and bicycles from this road if
Interesting tests Chris.
I wonder how this works out on Basecamp? I've noticed that using 'avoid
carpool' the routing gets very unpredictable, but maybe because I don't use it
in my styles.
To use a gmapsupp.img in Basecamp, you can reset the MS flag in the gmapsupp
header from 1 to zero and
Chris,
As I mentioned here before, I noticed that with the map I downloaded
from garmin.openstreetmap.nl that the new eTrex 30 always acts as if I
had selected pedestrian even when I select motorcar.
Regards,
Frank
2011/11/16 Chris66 chris66...@gmx.de:
Hi,
here some testing results
On Tue, Nov 15, 2011 at 11:38:45PM +0100, fla...@googlemail.com wrote:
I read http://wiki.openstreetmap.org/wiki/Key:construction
construction=minor means that a road can be driven but at lower speed.
construction=yes mean that a road with the roadtype highway=* will be
build, and you cant drive
El 16/11/11 09:26, Marko Mäkelä escribió:
On Tue, Nov 15, 2011 at 11:38:45PM +0100, fla...@googlemail.com wrote:
I read http://wiki.openstreetmap.org/wiki/Key:construction
construction=minor means that a road can be driven but at lower speed.
construction=yes mean that a road with the
On Mon, Nov 14, 2011 at 02:11:37AM +0100, fla...@googlemail.com wrote:
Perhaps we should also reduce roadspeed for construction = minor
highway=* construction=minor [0x16 road_speed=3 resolution 22] ?
What about construction=minor on a tertiary or lesser road? That should
not increase the
On Sun, Nov 13, 2011 at 06:37:53PM +0100, Minko wrote:
* highway=construction
I would suggest this, which would not grant or forbid access, but only
lower the road_class and road_speed:
-# Treat ways under construction as highway=path
-highway=construction | highway=* construction=* {add
El 15/11/11 22:19, Marko Mäkelä escribió:
On Sun, Nov 13, 2011 at 06:37:53PM +0100, Minko wrote:
* highway=construction
I would suggest this, which would not grant or forbid access, but only
lower the road_class and road_speed:
-# Treat ways under construction as highway=path
I read http://wiki.openstreetmap.org/wiki/Key:construction
construction=minor means that a road can be driven but at lower speed.
construction=yes mean that a road with the roadtype highway=* will be
build, and you cant drive it at the moment with an car.
Thats the way i unterstand the wiki.
I
Marko,
I've tested the rules for (motor_)vehicle, seems to work well in Mapsource.
It does not work in Basecamp but that is another issue.
The fact that bicycles are also a vehicle is not widely known, so this changed
routing will cause some confusion.
Hi Minko,
I've tested the rules for (motor_)vehicle, seems to work well in
Mapsource. It does not work in Basecamp but that is another issue.
Thank you, I will commit it then.
When it comes to the highway=construction or construction=*, I will wait
for some feedback first.
The fact that
On http://forum.openstreetmap.org/viewtopic.php?id=13257p=3 a few suggestions
were posted to improve the routing:
Maybe Marko can have a look at this to see if this can be added to the default
style?
* highway=construction
Be careful with construction=minor.
Thanks Minko, the suggestions look reasonable to me. I responded to the
thread, advertising the TYP compiler branch too, hoping to attract other
testers for it.
I had to fix some coastline issues this weekend, and could not proceed
with splitting the default style yet. I will implement the
Perhaps we should also reduce roadspeed for construction = minor
highway=* construction=minor [0x16 road_speed=3 resolution 22] ?
http://forum.openstreetmap.org/viewtopic.php?pid=202133#p202133
___
mkgmap-dev mailing list
On Tue, Oct 18, Felix Hartmann wrote:
As I already wrote long time ago on the Basecamp forum, I don't think
Garmin cares at all. Cause NO single map Garmin ever published does use
bicycle or related settings. Hence not mkgmap does something wrong, but
Garmin just eliminated sthg they never
Am 16.10.2011 20:34, schrieb Frank Fesevur:
My conclusion is that car navigation does send me over cycleways and
footways. It also sends you the wrong way in a oneway street.
Funny, so Garmin seems to have new flags for the new models.
Interresting question is: are old garmin maps (city
2011/10/18 Chris66 chris66...@gmx.de:
Funny, so Garmin seems to have new flags for the new models.
Yes, apparently something has changed for the new devices.
Interresting question is: are old garmin maps (city navigator) still
working on the new models?
I always have used OSM based maps on
I've tested an old CN on Basecamp and couldnt find any new issues compared to
the Mapsource version.
Cyclists are still routed to national routes that are forbidden to cycle on,
but this is because Garmin doesn't care about bike riders. Of course cars are
not routed on bikepaths because CN
As I already wrote long time ago on the Basecamp forum, I don't think
Garmin cares at all. Cause NO single map Garmin ever published does use
bicycle or related settings. Hence not mkgmap does something wrong, but
Garmin just eliminated sthg they never used. Probably in a few versions
the mode
Hi all,
A couple of weeks ago some of you asked me about the routing
capabilities of the new eTrex 30 model. First of all, as I said
before. My previous model was a Venture HC, so without routing. I had
nothing to compare to, when it comes to routing on an eTrex.
Today I finally had time to do
Thanks Frank,
Thats what I already feared.
Hofzicht (Cycleway) is a created line by mkgmap with the make-all-cycleways
tag (cycleway=opposite)
make-all-cycleways
If you are using a style file this option is not necessary because it can be
created in the line styles with continue statements and
Just for the record, finally I got routing working on MapSource by
changing FID from 18 to a number higher than 100, as suggested by Felix
on http://openmtbmap.org/tutorials/install/gmaptool-install-maps/
El 29/09/11 13:33, Carlos Dávila escribió:
I still have the same problem on MapSource.
I still have the same problem on MapSource. The full map is now
available at [1]. If anyone is willing to give it a try I would thank
very much.
[1] http://mapas.alternativaslibres.es/MapSource_india.zip
El 13/09/11 23:22, Carlos Dávila escribió:
El 13/09/11 21:36, michael lohr escribió:
Ralf,
I don't think it will work in Mapsource/Basecamp with two different routing
layers in one map.
For instance you have a car based routing map in Layer 1:
family-name=Layer1
input-file: 1001.osm.gz
input-file: 1002.osm.gz
And a bicycle/foot routing map in Layer 2:
family-name=Layer2
El 12/09/11 20:48, michael lohr escribió:
have you tried routing a short way in a densely mapped area (e.g.
delhi)? the density of roads in many parts of india is so low that
routing breaks because of lack of information.
Yes, I have tried to route even with origin and end points in the same
can you upload a map tile somewhere?
Am 13.09.2011 19:04, schrieb Carlos Dávila:
El 12/09/11 20:48, michael lohr escribió:
have you tried routing a short way in a densely mapped area (e.g.
delhi)? the density of roads in many parts of india is so low that
routing breaks because of lack of
El 13/09/11 20:22, michael lohr escribió:
can you upload a map tile somewhere?
http://mapas.alternativaslibres.es/55180001.img
Am 13.09.2011 19:04, schrieb Carlos Dávila:
El 12/09/11 20:48, michael lohr escribió:
have you tried routing a short way in a densely mapped area (e.g.
delhi)? the
i noticed that a lot of roads have no road id. mumbai area seems ok at
the first glance, does the routing work there?
Am 13.09.2011 20:46, schrieb Carlos Dávila:
El 13/09/11 20:22, michael lohr escribió:
can you upload a map tile somewhere?
http://mapas.alternativaslibres.es/55180001.img
El 13/09/11 20:50, michael lohr escribió:
i noticed that a lot of roads have no road id. mumbai area seems ok at
the first glance, does the routing work there?
No. still the same problem. I tried ten short routes in different types
of ways and it doesn't work.
Am 13.09.2011 20:46, schrieb
routing in gpsmapedit works ok (tools - test routing graph), even over
longer distances. you're trying on a gps or in mapsource?
Am 13.09.2011 21:19, schrieb Carlos Dávila:
El 13/09/11 20:50, michael lohr escribió:
i noticed that a lot of roads have no road id. mumbai area seems ok
at the
El 13/09/11 21:36, michael lohr escribió:
routing in gpsmapedit works ok (tools - test routing graph), even
over longer distances. you're trying on a gps or in mapsource?
In Mapsource 6.13.7 and 6.16.3. I sent the map to gps from MS and I can
simulate routing from one location to a given point,
I have compiled a map of India from Geofabrik extract, using the
commands below, similar to the ones I use for other countries. The map
compiles without errors but routing doesn't work on MapSource, only a
straight line is drawn from point A to B. I have tried with different
days extracts with
On Mon, Sep 12, Carlos Dávila wrote:
I have compiled a map of India from Geofabrik extract, using the
commands below, similar to the ones I use for other countries. The map
compiles without errors but routing doesn't work on MapSource, only a
straight line is drawn from point A to B. I
El 12/09/11 16:21, Thorsten Kukuk escribió:
On Mon, Sep 12, Carlos Dávila wrote:
I have compiled a map of India from Geofabrik extract, using the
commands below, similar to the ones I use for other countries. The map
compiles without errors but routing doesn't work on MapSource, only a
have you tried routing a short way in a densely mapped area (e.g.
delhi)? the density of roads in many parts of india is so low that
routing breaks because of lack of information.
Am 12.09.2011 16:23, schrieb Carlos Dávila:
I have compiled a map of India from Geofabrik extract, using the
On 2:59 PM, Marko Mäkelä wrote:
Is this just a Garmin bug? Can you try routing a shorter distance? For
example, start from the Davis Dr close to the Old Jenkins Rd and ask
for a route to the US64W ramp.
I tried this. There several points south of Old Jenks Rd that still want
to do that funny
Hi,
When I am going south on Davis Dr and want to merge into US-64 West, the
GPS and MapSource choose to turn left into Old Jenks Rd, right into N
Salem St and then get the ramp to enter US 64W instead of the direct
route from Davis Dr, turn right into the ramp.
Any ideas why this happens? I
On Fri, Sep 09, 2011 at 09:04:14AM -0400, Francisco Moraes wrote:
When I am going south on Davis Dr and want to merge into US-64 West,
the GPS and MapSource choose to turn left into Old Jenks Rd, right into
N Salem St and then get the ramp to enter US 64W instead of the direct
route from Davis
I have tested the routing behavior on my Dakota-20 with firmware 4.70.
The behavior is as expected and totally different from BaseCamp (Windows, OS
X).
Maybe a bug in BaseCamp ...
--
View this message in context:
i think one could make 2 extra tdb files/overview maps for mapsource - 1
to bundle base/car, another to bundle base/cycle
Am 28.08.2011 18:33, schrieb Minko:
Sounds interesting, but how will you do that?
Can you give an example which I can download?
I don't see how you can tell mapsource
On 08/28/2011 06:33 PM, Minko wrote:
Sounds interesting, but how will you do that? Can you give an example
which I can download?
Sure. I first run mkgmap on the OSM files to generate the IMGs and the
gmapsupp.img. The config file looks somewhat like this:
gmapsupp
[more options ...]
Yes Klaus,
I already wrote that in my first reply to your question. In the latest releases
of Basecamp (since 3.2.1) all access rules are ignored. Some things still work,
like oneway=yes. And the avoidance options.
I reported this bug on the Garmin Forum but I doubt they will ever look on it,
Sounds terrible - devaluates *all* OSM garmin maps.
Next week I will do further test on my Dakota-20 with Firm 4.30.
Klaus
PS:
My workaround is to use the toll and ferry bits (toll for footways and
ferry for cycleways).
Yes I agree, it's a dirty workaround.
And I hope that someone finds the
As the Garmin developer writes on the forum, they don't recognize it as a bug
unless someone can show this behaviour affects also their official Garmin maps
like Topo Germany. Maybe someone can test this?
Klaus wrote:
And I hope that someone finds the reason for the new routing behavior.
On 28.08.2011 10:43, Minko wrote:
As the Garmin developer writes on the forum, they don't recognize it as a bug
unless someone can show this behaviour affects also their official Garmin
maps like Topo Germany. Maybe someone can test this?
Garmin never included such information into any of
I just noticed that even cars are routed on cycleways on OSM maps...
This happens only in Basecamp, not in the latest Mapsource 6.16.3 nor on the
GPS.
Although they have never supported OSM tags, why is this changed? There must be
some bug in the latest BC releases.
Minko-2 wrote:
I just noticed that even cars are routed on cycleways on OSM maps...
Yes you are right.
BTW: This was the reason why I have started this thread.
I have always tested my maps with BaseCamp (3.2.1 / 3.2.2, Windows, OS X)
and on my Dakota-20 with the new Firmware 4.30.
I though
You can see this phenomenon also with CN-Maps ;)
Am 28.08.2011 um 11:10 schrieb Minko:
I just noticed that even cars are routed on cycleways on OSM maps...
This happens only in Basecamp, not in the latest Mapsource 6.16.3 nor on the
GPS.
Although they have never supported OSM tags, why
I don't agree, this is totally different, CN-maps never supported bike routing.
Even in Mapsource and on the GPS cyclists are routed on major highways on CN
maps. There are no cycleways on CN either so cars will never be routed on
cycleways simply because they don't show them. This post is
The last time my new garmin (Nüvi 1390) tried to route via pedestrian...
Am 28.08.2011 um 12:13 schrieb Minko:
I don't agree, this is totally different, CN-maps never supported bike
routing. Even in Mapsource and on the GPS cyclists are routed on major
highways on CN maps. There are no
this might be slightly off-topic, but still: why not avoid the whole
problem altogether?
i use a non-routable base map containing everything you see on the
screen, on top of that 2 transparent routable maps, one for car, one for
bicycle, switched on/off according to the vehicle used.
this
Unfortunately Garmins mapbrowser don't support multi-layered maps :-(
You have either a basemap that doesn't route, or an empty map with just roads.
Not both, unless we stick to the discontinued Mapsource or we can find a trick.
___
mkgmap-dev
On 08/28/2011 01:29 PM, Minko wrote:
Unfortunately Garmins mapbrowser don't support multi-layered maps :-(
You have either a basemap that doesn't route, or an empty map with just roads.
Not both, unless we stick to the discontinued Mapsource or we can find a
trick.
You can make a
Sounds interesting, but how will you do that?
Can you give an example which I can download?
I don't see how you can tell mapsource which tile to take when you switch
vehicle in the routing menu.
Ralf wrote:
You can make a special TDB file and overview map file for Mapsource with
just one family
Further investigation has shown a significant difference (concerning routing)
between MapSource (Windows, 6.16.3) and BaseCamp (Windows, OS X, 3.2.2).
It seems that the access bits (e.g. access=no; bicycle=yes; ...) in BaseCamp
are not working as expected.
Could someone verify my observation?
Am 22.08.2011 14:40, schrieb Minko:
I've tried it to avoid steps in the bicycle routing but this doesn't always
work as expected:
toll roads - yes
ferry - yes
unpaved - no (does work on track roads)
What is the tracktype?
The rule is handling grade2 - grade6 as unpaved.
highway=*
Hi Chris,
Finally I managed to get the avoidance of steps working with mkgmap:unpaved=1
I had to move it to the front of the action block.
This rule didn't work for me in Basecamp (altough it worked in Mapsource!):
highway=steps {add access = no; add foot = yes; set mkgmap:unpaved=1} [0x13
Could someone describe the unwanted side effects of the avoid carpool
roads setting ?
Thanks - Klaus
--
View this message in context:
http://gis.638310.n2.nabble.com/Routing-Documentation-and-Best-Practice-tp6710634p6715703.html
Sent from the Mkgmap Development mailing list archive at
Unexplainable long detours if the carpool avoidance is set.
Could someone describe the unwanted side effects of the avoid carpool
roads setting ?
Thanks - Klaus
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Currently I'm working on the routing feature of my garmin maps and run into
some problems. I was looking for detailed information concerning routing
(incl. best pratice) but couldn't find such a document.
Question: Could someone point me to such a documentation or describe the
best practice?
Currently I'm working on the routing feature of my garmin maps and run into
some problems.
I was looking for detailed information concerning routing (incl. best
pratice) but couldn't find such a document.
Question: Could someone point me to such a documentation or describe the
best practice?
On Mon, Aug 22, 2011 at 01:41:04AM -0700, toc-rox wrote:
Currently I'm working on the routing feature of my garmin maps and run
into some problems. I was looking for detailed information concerning
routing (incl. best pratice) but couldn't find such a document.
Question: Could someone point me
Since Garmin has stopped the development of Mapsource in favour of Basecamp,
it's maybe necessary to have a closer look at the routing scripts. In the
latest releases of Basecamp parameters like bicycle=no, foot=no etc don't work
anymore as expected. This leads to unwanted routing like cycling
Thanks for the response - I have something like this:
highway = path foot = designated {set highway = fussweg}
highway = footway foot = designated {set highway = fussweg}
...
# Routing (nur Fussgaenger zulassen)
highway = fussweg {add access = no; add foot = yes}
highway = fussweg [0x16
On 22/08/2011 10:54, Minko wrote:
I'm afraid that if Garmin is updating the firmware of their units according
to the newer Basecamp procedures routing will also fail on the GPS.
The new eTrex series is due out real soon now - it'll be interesting
to see what if anything they've changed.
On Mon, Aug 22, 2011 at 03:08:42AM -0700, toc-rox wrote:
Thanks for the response - I have something like this:
highway = path foot = designated {set highway = fussweg}
highway = footway foot = designated {set highway = fussweg}
...
# Routing (nur Fussgaenger zulassen)
highway = fussweg
The effect on BaseCamp OS X (3.2.1)
Map with routing (red line = foot only; blue line = foot + bicycle):
http://gis.638310.n2.nabble.com/file/n6710993/Map.png
Map with unexpected motorcar routing:
http://gis.638310.n2.nabble.com/file/n6710993/Unexpected_Routing.png
Map with expected
I think Klaus deals with the same problems that my cycle map users have pointed
me when using the latest releases of Basecamp.
See http://forum.openstreetmap.org/viewtopic.php?id=13384p=2 (in Dutch but you
can use google translate)
Not only my maps are affected but in fact all OSM/mkgmap and
It seems that the avoid features (toll, carpool, ferry, unpaved, ...) are
still working as expected.
Maybe a workaround ...
Klaus
--
View this message in context:
http://gis.638310.n2.nabble.com/Routing-Documentation-and-Best-Practice-tp6710634p6711106.html
Sent from the Mkgmap Development
I've tried it to avoid steps in the bicycle routing but this doesn't always
work as expected:
toll roads - yes
ferry - yes
unpaved - no (does work on track roads)
carpool - no (plus unwanted side effects)
Klaus wrote:
It seems that the avoid features (toll, carpool, ferry, unpaved, ...) are
Toll roads and ferries seems to have the highest priority.
Both have something to do with money - sounds reasonable.
Klaus
--
View this message in context:
http://gis.638310.n2.nabble.com/Routing-Documentation-and-Best-Practice-tp6710634p6711963.html
Sent from the Mkgmap Development mailing
Hi,
Routingerror on Felbertauerntunnel (Austria) in BaseCamp and (concerning
to a user report in the OSM forum) also on GPSMAP62 Device :
http://up.picr.de/7750089mbq.png
Routing N-S ok, S-N not ok (straight line).
Routing in Cloudmade is OK:
Hi!
How to make a restriction of access on the road if it contains a point with
barrier=bollard or barrier=gate?
I mean are the same as the turn restrictions with relations
type=restriction.
--
View this message in context:
On Tue, Jun 07, 2011 at 04:28:28AM -0700, ValentinAK wrote:
Hi!
How to make a restriction of access on the road if it contains a point
with barrier=bollard or barrier=gate? I mean are the same as the
turn restrictions with relations type=restriction.
As far as I understand, --link-pois-to-ways
This restriction is not the property of ways. This is a property of point.
But this is not POI!
--
View this message in context:
http://gis.638310.n2.nabble.com/Routing-restriction-points-tp6449115p6449705.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 07/06/2011 13:28, ValentinAK wrote:
Hi!
How to make a restriction of access on the road if it contains a point with
barrier=bollard or barrier=gate?
I mean are the same as the turn restrictions with relations
type=restriction.
In my experience these barrier nodes are effectively ignored,
I'm talking about restrictions contained in routing parameters of some
points. Not all the points but only some of which specifies the possibility
of a turn or reversal. Usually this points located at the intersection of of
ways.
This is an example of routing parameters of the barrier point in
Am 07.06.2011 15:40, schrieb Marko Mäkelä:
How to make a restriction of access on the road if it contains a point
with barrier=bollard or barrier=gate? I mean are the same as the
turn restrictions with relations type=restriction.
As far as I understand, --link-pois-to-ways does this. I
On Wed, May 18, 2011 at 07:27:35AM +0200, Thorsten Kukuk wrote:
The only solution is to fix the data. Here in Nuernberg, somebody did
draw all plattforms for public transport and marked them as footway,
but didn't connect them with the street. As result, you always get an
routing error if you
On 5/18/2011 2:03 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote:
This can only be fixed by fixing the OSM data: Either connect all
routeable ways or mark this special bridge as not routeable.
Is there a recommended tag for this? Should I just add motorcar=no or
something else to that bridge
On Wed, May 18, 2011 at 07:53:31AM -0400, Francisco Moraes wrote:
On 5/18/2011 2:03 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote:
This can only be fixed by fixing the OSM data: Either connect all
routeable ways or mark this special bridge as not routeable.
Is there a recommended tag for
On Wed, May 18, 2011 at 08:47:58AM -0400, Francisco Moraes wrote:
The problem this is a company building (Cisco) and I have no idea what
the layout is.
You could add source=extrapolation to the corridor footways you make up,
or you could add access=private to the bridge and modify the style so
I had a routing problem a long time ago and never understood the reason.
Now that I have made several map contributions, fixes and compiled my
own map, I thought I found the reason for the routing failure. This is
the area in question:
On Tue, May 17, Francisco Moraes wrote:
I had a routing problem a long time ago and never understood the reason.
Now that I have made several map contributions, fixes and compiled my
own map, I thought I found the reason for the routing failure. This is
the area in question:
Sorry I was mistaken, I didnt search well. If I don't specify the place name,
all the streets are found. If I specify a place name, less results show up.
About the other routing problems, I think I've found a solution to the overlay
lines which are routable (had to add road_speed and road_class
Wanmil,
Speaking about the index, do you have an idea why when in Mapsource the address
search streets are connected with the right city (map made with the locator
jar) on the gps the address search is not as good and many streets are not
connected to a place name?
If I compile the map with
Wanmil,
Speaking about the index, do you have an idea why when in Mapsource the
address search streets are connected with the right city (map made with the
locator jar) on the gps the address search is not as good and many streets
are not connected to a place name?
I have no idea.
Hmm maybe it helps if I edit my style file rules, it could be an error in the
style files...
Routing goes well though in Mapsource and on the GPS when pointing on the map.
This was not going to work in combination with address routing:
highway=primary bicycle=no [0x0301 road_class=0
BTW it seems to happen more often with the locator jar than the regular mkgmap
version.
In Mapsource it works ok, but when the map is send to the device, some
streetnames are not connected to a placename.
I wrote:
Another problem with address search is that although Mapsource finds the
Conclusions:
-If two routable lines are combined, routing breaks when address search is
used (btw I have used mkgmap-locator-r1912.jar, same happened with previous
version)
I think (I haven't confirmed) that the address point of a street is the
center point of the streets bounding box
201 - 300 of 402 matches
Mail list logo
