On 07/28/2009 08:04 PM, MarkS wrote:
However, if I route across multiple tiles then it always fails.
Mapsource just spends ages and then draws a straight line whilst my
garmin counts to 100% and says their was a calculation error.
It does work for me. I routed successfully through half of
Version was commited by markb on 2009-07-29 08:16:51 +0100 (Wed, 29 Jul
2009)
Now calls incHighwayCount() for all points in all ways (not just highways).
This will now detect nodes in ways that are not highways or ferry routes.
So if a way is later mutated into some kind of road by the
Hi
Could everyone who is interested in this please try the attached patch.
It seems to work on the example I was looking at, but of course problems
may just have moved elsewhere so please check thing are OK
more widely. It would be good to know if it makes a difference to
inter tile routing
On Wed, Jul 29, 2009 at 12:03 PM, Steve Ratcliffest...@parabola.me.uk wrote:
Hi
Could everyone who is interested in this please try the attached patch.
I tried the patch on Valentijn's example, and it solved the problem. I
will now try it on a larger area and report the results.
Thanks!
Hey you incredible wizzard :)
Seems you fixed it :)
I cannot find any places where things go wrong now. Found a routing
problem while looking though, but that was not induced by your patch (I
reversed your patch it and it's still there). I'll send a report
shortly. (Have your netherlands.osm
Hello list,
The following inter tile routing gives nice and unexpected results.
areas.list:
63240001: 0x241000,0x25000 to 0x24d000,0x3b000
63240002: 0x24d000,0x25000 to 0x251000,0x34000
63240003: 0x24d000,0x34000 to 0x251000,0x3b000
63240004: 0x241000,0x3b000 to 0x24b000,0x42000
63240005:
Hi,
this patch fix showing building too early on Garmin device. building=*
should have same resolution as highway=residential.
Thanks
--
S pozdravem/Best regards
Bc. Ondrej Novy
Email: n...@ondrej.org
Jabber: on...@njs.netlab.cz
ICQ: 115-674-713
Tel/Cell: +420 777 963 207
Index: polygons
Valentijn Sessink schreef:
The following inter tile routing gives nice and unexpected results.
areas.list:
You only need:
63240003: 0x24d000,0x34000 to 0x251000,0x3b000
63240008: 0x251000,0x25000 to 0x255000,0x39000
63240009: 0x251000,0x39000 to 0x255000,0x4
Just found out: the trivial
Hi Valentijn,
What's really fascinating about your example is that mapsource will
happily route from A to a point within the tile containing B passing
right past point C. For example, route from A to the end of Plutoniumweg
(damn it, why can't we have funky road names like that instead of
the
Ondrej Novy n...@ondrej.org writes:
this patch fix showing building too early on Garmin device. building=*
should have same resolution as highway=residential.
No objections to that as an incremental improvement, but I am tempted to
say that building=yes without name= should not show up. In
Mark,
For me, routing to the Plutoniumweg doesn't work at all - but my
Mapsource is older than yours, I could not read your Plutoniumweg.gdb
(MapSource complains about the file being newer).
Utrecht, we have a problem ;)
I was thinking about trying to synchronize the vertical split line (i.e.
Hi,
For me, routing to the Plutoniumweg doesn't work at all - but my
Mapsource is older than yours, I could not read your Plutoniumweg.gdb
(MapSource complains about the file being newer).
I am using the latest version (as downloaded by the check for
software updates option on the help
Hi Mark,
Mark Burton schreef:
I am using the latest version (as downloaded by the check for
software updates option on the help menu).
I can't run a later version, I use the version for older operating
systems, as that is what runs nicely under Linux under Wine. I could not
get the Splendid
Mark Burton wrote:
snip
I am using the latest version (as downloaded by the check for
software updates option on the help menu).
snip
Hi Mark,
I tried the latest mapsource update, and I liked the rendering of the
maps, but it was caching my maps so when I made updates, they were not
Hi,
2009/7/29 Greg Troxel g...@ir.bbn.com
Ondrej Novy n...@ondrej.org writes:
this patch fix showing building too early on Garmin device. building=*
should have same resolution as highway=residential.
No objections to that as an incremental improvement, but I am tempted to
say that
Ondrej Novy n...@ondrej.org writes:
i find building REALLY usefull when navigation. When you are not in car,
but going by foot it's really usefull information.
Or perhaps unnamed buildings should be shown only when POIs are shown.
Here's an example of what I'm talking about:
Hi Garvan,
I just deleted this folder
C:\Documents and Settings\markb\Application Data\GARMIN\MapSource\TileCache
and I think it did the trick (obviously, change the user name to your
own)
Cheers,
Mark
___
mkgmap-dev mailing list
hi,
2009/7/29 Greg Troxel g...@ir.bbn.com
Here's an example of what I'm talking about:
http://www.openstreetmap.org/?lat=42.3921lon=-71.15861zoom=16layers=B000FTF
yes, exactly this is what i want to have on my Garmin - without kidding.
Better TOPO maps (for example TOPO 3 Pro Czech) have
Hi,
2009/7/29 Torsten Leistikow de_m...@gmx.de
And in my style the lines-file contained the following rules:
highway=null_null layer0 [0x01 resolution 10]
highway=null_null layer=0 [0x02 resolution 10]
highway=null_null layer0 [0x03 resolution 10]
highway=null_null layer='-1' [0x04
Version 1112 was commited by steve on 2009-07-29 19:24:44 +0100 (Wed, 29 Jul
2009)
Improve (perhaps even completely fix) the behaviour at the edge of a map.
The bug was that if you were close to the edge you could get strange behaviour
such as disapearing map when zooming in really close and
Hi
And in my style the lines-file contained the following rules:
highway=null_null layer0 [0x01 resolution 10]
highway=null_null layer=0 [0x02 resolution 10]
highway=null_null layer0 [0x03 resolution 10]
highway=null_null layer='-1' [0x04 resolution 10]
highway=null_null layer='0'
Version 1113 was commited by steve on 2009-07-29 20:37:25 +0100 (Wed, 29 Jul
2009)
Test for comparasons in style files.
Next will get it to work.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Steve Ratcliffe schrieb:
I would say that the second result would
be very strange as the rules for 0x2 and 0x5 are exactly
the same and the 0x2 one comes first and so should win.
You 're right, I have to apologise for mixing the numbers.
The actual conversions are as follows:
9902 - 0x03
Version 1114 was commited by steve on 2009-07-29 21:01:06 +0100 (Wed, 29 Jul
2009)
Allow numeric quantities to be negative.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 29/07/09 20:53, Torsten Leistikow wrote:
Steve Ratcliffe schrieb:
I would say that the second result would
be very strange as the rules for 0x2 and 0x5 are exactly
the same and the 0x2 one comes first and so should win.
You 're right, I have to apologise for mixing the numbers.
OK, I've
Hi Mark,
I'm not sure if this is good or bad news, but the Nuvi works!
Just to be sure, I'll check my Nüvi this evening.
Please do, it would be useful to know if a real GPS has the same
problem (my guess is that it will).
It also works out of the box, routing perfectly, when I route from
Hi,
attached patch add more barriers types, kindergarten and for every shop
render polygon.
Thanks.
--
S pozdravem/Best regards
Bc. Ondrej Novy
Email: n...@ondrej.org
Jabber: on...@njs.netlab.cz
ICQ: 115-674-713
Tel/Cell: +420 777 963 207
Index: polygons
Attached are two very simple osm files which show an island in a water
polygon added by hand. Both are connected with a multipolygon relation.
The difference between the to files is just the size of the island.
The multipolygon is rendered correctly in the map resulting from
test1.osm but not
Mark Burton wrote:
Hi Garvan,
I just deleted this folder
C:\Documents and Settings\markb\Application Data\GARMIN\MapSource\TileCache
and I think it did the trick (obviously, change the user name to your
own)
Cheers,
Mark
_
Thanks for this tip. Now I can try the upgrade again.
29 matches
Mail list logo
