Re: [mkgmap-dev] Clearing mapsource tile cache
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. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Large multipolygons not working?
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 in the one resulting from test2.osm. This may be the result of a bug in the polygon splitting algorithm. This problem also occurs when I try to create a map of Corsica with the sea added by hand. Best wishes Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] More barriers, kindergarten and shop polygon
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
===
--- polygons (revision )
+++ polygons (working copy)
@@ -2,6 +2,7 @@
aeroway=aerodrome [0x07 resolution 18]
aeroway=terminal [0x13 resolution 20]
+amenity=kindergarten [0x0a resolution 18]
amenity=college [0x0a resolution 18]
amenity=grave_yard [0x1a resolution 18]
amenity=hospital [0x0b resolution 18]
@@ -59,6 +60,8 @@
place=village [0x03 resolution 18]
+shop=* [0x08 resolution 20]
+
# squares and plazas
highway=pedestrian & area=yes [0x17 resolution 20]
# other highways that have area=yes set must be parking lots
Index: points
===
--- points (revision )
+++ points (working copy)
@@ -196,6 +196,7 @@
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
-barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
-barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
-
+barrier=bollard | barrier=bus_trap
+{add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 21]
+barrier=block | barrier=cycle_barier | barrier=stile | barrier=kissing_gate
+{add access = no; add foot = yes} [0x660f resolution 21]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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 home to my parents (MapSource didn't do that correctly) and to my wife's family (where MapSource did not route at all). So this seems a MapSource issue with the map, not a generic mapping issue. I could check/doublecheck the MapSource settings (i.e. check if there's any caching, remove and reload the TDB file again etc etc). Will do that, but as my Nuvi works, it's not high on the list. And now for something completely different: I think the mailing list noticed some time ago that bike routing is a wholly different thing on the Garmin, right? I'm still getting weird results when I let the Nuvi route by bicycle - simple routes will have the weirdest deviations, letting you drive 35 kilometers where the regular Garmin map has a 14 kilometer route. Now this regular map has no knowledge of bicycle paths, so sometimes the routing is wrong because of that. Anyway, I'm pretty confident now that the routing by car is pretty much as expected. I will keep using my Garmin for reference testing, however, and tell my experiences here on the mailing list. Back to the original topic: if you want me to do anything on the weird route, please tell me so. Thanks for your great work again! Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
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 just committed a fix. Do you agree all is well with it? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1114: Allow numeric quantities to be negative.
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
Re: [mkgmap-dev] comparing numeric values
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 9912 -> 0x02 9922 -> 0x08 9932 -> 0x03 9952 -> 0x03 Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1113: Test for comparasons in style files.
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
Hi > And in my style the lines-file contained the following rules: > highway=null_null& layer<0 [0x01 resolution 10] > highway=null_null& layer=0 [0x02 resolution 10] > highway=null_null& layer>0 [0x03 resolution 10] > highway=null_null& layer='-1' [0x04 resolution 10] > highway=null_null& layer='0' [0x05 resolution 10] > highway=null_null& layer='1' [0x06 resolution 10] > highway=null_null& layer='+1' [0x07 resolution 10] > highway=null_null [0x08 resolution 10] > > As a result I expected the following conversions > 9902 -> 0x01 > 9912 -> 0x02 > 9922 -> 0x08 > 9932 -> 0x03 > 9952 -> 0x03 > > Against my expectations the conversions were the following: > 9902 -> 0x03 > 9912 -> 0x05 > 9922 -> 0x08 > 9932 -> 0x03 > 9952 -> 0x03 I've just written a test to duplicate this problem. I see the first unexpected result, but the not the second (9912). I suspect the first is just that negative numbers are not recognised. 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. > What is wrong? > - My understanding of the style rules? > - The documentation of the style rules? > - The behaviour of mkgmap? The behaviour of mkgmap. But could you re-check the 9912 result as that one works as I (and you) would expect for me. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1112: Improve (perhaps even completely fix) the behaviour at the edge of a map.
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 tool tips not appearing when hovering over roads. This fixes the subdivision width and height calculations to be more correct at lower zooms, especially when the full width is an odd number. I was going to do more than this, but it seems to work well as it is. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
Ondrej Novy schrieb: > try this: > > highway=null_null & layer='0' [0x05 resolution 10] > highway=null_null & layer=0 [0x02 resolution 10] > highway=null_null & layer='1' [0x06 resolution 10] > highway=null_null & layer='+1' [0x07 resolution 10] > highway=null_null & layer='-1' [0x04 resolution 10] > highway=null_null & layer<0 [0x01 resolution 10] > highway=null_null & layer>0 [0x03 resolution 10] > highway=null_null [0x08 resolution 10] Why? My example shall show, that the layer>0 and layer<0 rules are not working as expected. Putting this rules behind the other rules makes the whole test useless. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] comparing numeric values
Hi, 2009/7/29 Torsten Leistikow > And in my style the lines-file contained the following rules: > highway=null_null & layer<0 [0x01 resolution 10] > highway=null_null & layer=0 [0x02 resolution 10] > highway=null_null & layer>0 [0x03 resolution 10] > highway=null_null & layer='-1' [0x04 resolution 10] > highway=null_null & layer='0' [0x05 resolution 10] > highway=null_null & layer='1' [0x06 resolution 10] > highway=null_null & layer='+1' [0x07 resolution 10] > highway=null_null [0x08 resolution 10] try this: > highway=null_null & layer='0' [0x05 resolution 10] > highway=null_null & layer=0 [0x02 resolution 10] > highway=null_null & layer='1' [0x06 resolution 10] > highway=null_null & layer='+1' [0x07 resolution 10] > highway=null_null & layer='-1' [0x04 resolution 10] > highway=null_null & layer<0 [0x01 resolution 10] > highway=null_null & layer>0 [0x03 resolution 10] > highway=null_null [0x08 resolution 10] -- 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] comparing numeric values
Moin, in the style rules documentation in the WIKI it is stated, that a comparison of numeric quantities is possible, e.g. "maxspeed>=30". Is this really working? I tried the following example: In my osm file I had five ways: And in my style the lines-file contained the following rules: highway=null_null & layer<0 [0x01 resolution 10] highway=null_null & layer=0 [0x02 resolution 10] highway=null_null & layer>0 [0x03 resolution 10] highway=null_null & layer='-1' [0x04 resolution 10] highway=null_null & layer='0' [0x05 resolution 10] highway=null_null & layer='1' [0x06 resolution 10] highway=null_null & layer='+1' [0x07 resolution 10] highway=null_null [0x08 resolution 10] As a result I expected the following conversions 9902 -> 0x01 9912 -> 0x02 9922 -> 0x08 9932 -> 0x03 9952 -> 0x03 Against my expectations the conversions were the following: 9902 -> 0x03 9912 -> 0x05 9922 -> 0x08 9932 -> 0x03 9952 -> 0x03 What is wrong? - My understanding of the style rules? - The documentation of the style rules? - The behaviour of mkgmap? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Building resolution
Ondrej Novy writes: > hi, > > 2009/7/29 Greg Troxel > >> Here's an example of what I'm talking about: >> >> >> http://www.openstreetmap.org/?lat=42.3921&lon=-71.15861&zoom=16&layers=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 all buildings. You can > guess where you can go by foot - usefull for Geocaching :]. > > ... >> >> [I am still trying to get maps of mass made, and my first step after >> that is to tweak unnamed buildings down in importance or out.] > > > i think good point should be to create two 'official' styles, CityNavigator > and TOPO. There are plenty of useless thing in default style for road > navigation and few missing things for TOPO. > > What do you think? That would be great. We have 'default' style now, which makes sense to make be the right thing for car-centric navigation, and another style for topo/detailed makes sense. I'll see what I can do once I get past whatever problem I'm having. pgplFRJqDfiHZ.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Building resolution
hi, 2009/7/29 Greg Troxel > Here's an example of what I'm talking about: > > > http://www.openstreetmap.org/?lat=42.3921&lon=-71.15861&zoom=16&layers=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 all buildings. You can guess where you can go by foot - usefull for Geocaching :]. ... > > [I am still trying to get maps of mass made, and my first step after > that is to tweak unnamed buildings down in importance or out.] i think good point should be to create two 'official' styles, CityNavigator and TOPO. There are plenty of useless thing in default style for road navigation and few missing things for TOPO. What do you think? -- 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Clearing mapsource tile cache
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Building resolution
Ondrej Novy 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: http://www.openstreetmap.org/?lat=42.3921&lon=-71.15861&zoom=16&layers=B000FTF >> A random building outline seems far less important than a restaurant >> POI. > > sorry, but disagree. No problem - that's one of the great things about osm/mkgmap is that people can adjust it to make maps they find useful. I wonder if adding support to put larger buildings at lower-numbered levels makes sense. And suppressing lots of small buildings in dense areas, similar to the USGS "house omission tint". (I know, ENOPATCH :-) [I am still trying to get maps of mass made, and my first step after that is to tweak unnamed buildings down in importance or out.] pgpvftyqPxz0i.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Hi Garvan, > 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 > immediately reflected in mapsource. It would still display the old map > until I changed map to something else and back again a few times. This > proved to be a problem in checking my changes, so I downgraded to > 6.13.7, which is still available from garmin. Yes, the caching is a real pain. > If you know how to make the maps refresh with the latest versions this > would be useful to share. I don't know how to do that, it would be good to know. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Building resolution
Hi, 2009/7/29 Greg Troxel > > Ondrej Novy 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 Mass we have > MassGIS building footprint ways for every house, and it's basically > clutter on the garmin display and seems to slow down map rendering. > It's very cool this data is in OSM, but I don't find it helpful when > navigating. 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. > A random building outline seems far less important than a restaurant > POI. sorry, but disagree. -- 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Mark Burton wrote: > > I am using the latest version (as downloaded by the "check for > software updates" option on the help menu). > 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 immediately reflected in mapsource. It would still display the old map until I changed map to something else and back again a few times. This proved to be a problem in checking my changes, so I downgraded to 6.13.7, which is still available from garmin. If you know how to make the maps refresh with the latest versions this would be useful to share. Thanks Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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 New version to work. Oh well, it says that "De MapSource versie 6.15.6.0 update is voor downloaden beschikbaar". But I'd really rather not try it, actually. I'll put the map in my Nüvi instead. >> I was thinking about trying to synchronize the vertical split line (i.e. >> have both maps split at 0x39000, just to make sure that's not the problem. > Could be worth trying to see if it changes anything. Makes no difference (please note that 0003 is out of bounds but that doesn't matter as it is not used). 63240003: 0x24d000,0x34000 to 0x251000,0x39000 63240006: 0x24d000,0x39000 to 0x251000,0x41000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 Same routing for A, B and C. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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 menu). > "Utrecht, we have a problem" ;) > > I was thinking about trying to synchronize the vertical split line (i.e. > have both maps split at 0x39000, just to make sure that's not the problem. Could be worth trying to see if it changes anything. > Oh, btw: the reason I found this strange route is that a much longer > inter-tile route, from my home in Zaandam to my parents in Houten, made > a weird deviation half way (went off the A2 for no reason, somewhere > above point A); also, a route to my wife's family in Culemborg could not > be calculated at all. Yes, it's not specific to that particular piece of road. It must be a general problem with being unable to route across a tile in certain circumstances. > 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). Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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. have both maps split at 0x39000, just to make sure that's not the problem. Oh, btw: the reason I found this strange route is that a much longer inter-tile route, from my home in Zaandam to my parents in Houten, made a weird deviation half way (went off the A2 for no reason, somewhere above point A); also, a route to my wife's family in Culemborg could not be calculated at all. Just to be sure, I'll check my Nüvi this evening. Best regards, Valentijn Mark Burton schreef: > 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 canonical Acacia Avenue!), but if you move the destination a little > to the S so that it is in the lower tile, it fails to route - see > attached gdb. It's almost as if having traversed B tile it then is > happy to locate a destination in it but, for some reason, it's unhappy > with a destination in C tile. -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sess...@openoffice.nl +31(0)20-4214059 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Building resolution
Ondrej Novy 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 Mass we have MassGIS building footprint ways for every house, and it's basically clutter on the garmin display and seems to slow down map rendering. It's very cool this data is in OSM, but I don't find it helpful when navigating. Or perhaps unnamed buildings should be shown only when POIs are shown. A random building outline seems far less important than a restaurant POI. pgpDWCPdKzvE6.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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 canonical Acacia Avenue!), but if you move the destination a little to the S so that it is in the lower tile, it fails to route - see attached gdb. It's almost as if having traversed B tile it then is happy to locate a destination in it but, for some reason, it's unhappy with a destination in C tile. I can't think at this time what would cause this to happen. It may be a limitation of the Garmin routing engine and it needs something extra from us to cope? Cheers, Mark plutoniumweg.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
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 way to know which map part is which split is using the "Map" button in the tool bar. It has an icon that vaguely resembles a Cubism sort of Pac Man (what if... Picasso would have been a game developer?) Also: trying to route back (just put points D, E and F on the opposite lane of the A2 highway) shows the same problems: routing from D to E and E to F is OK, but D to F fails. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Building resolution
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 === --- polygons (revision ) +++ polygons (working copy) @@ -10,7 +10,7 @@ amenity=supermarket [0x08 resolution 21] amenity=university [0x0a resolution 18] -building=* [0x13 resolution 20] +building=* [0x13 resolution 21] landuse=allotments [0x4e resolution 20] landuse=basin [0x3f resolution 18] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] a routing problem
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: 0x241000,0x42000 to 0x24b000,0x53000 63240006: 0x24b000,0x3b000 to 0x251000,0x41000 63240007: 0x24b000,0x41000 to 0x251000,0x53000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 63240010: 0x255000,0x25000 to 0x263000,0x4 63240011: 0x251000,0x4 to 0x259000,0x49000 63240012: 0x251000,0x49000 to 0x259000,0x53000 63240013: 0x259000,0x4 to 0x263000,0x48000 63240014: 0x259000,0x48000 to 0x263000,0x53000 (You don't need all areas, but I don't know a trivial way to know which map part is which split). Then run: java -Xmx1600m -enableassertions -jar ../splitter/dist/splitter.jar --split-file=areas.list netherlands.osm java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args Then load the attached tdb-file in MapSource.exe. You'll notice three waypoints, A, B and C, all three on a different tile, A and B being adjacent and B and C also. Mapsource will route from A to B, from B to C and from A to B via C, but it will not route from A to C. I don't have my Garmin Nüvi at hand, so I can't test it there - if you want me to, I'll be able to do that in the evening if you want me to. Best regards, Valentijn routing problem.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] vanishing map
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 ready for some splitting ;) So the patch works! Wonderful! V. Steve Ratcliffe schreef: > 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 as well. -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sess...@openoffice.nl +31(0)20-4214059 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] vanishing map
On Wed, Jul 29, 2009 at 12:03 PM, Steve Ratcliffe 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! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] vanishing map
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 as well.
..Steve
Index: src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java
===
--- src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java (revision 988)
+++ src/uk/me/parabola/imgfmt/app/trergn/Subdivision.java Wed Jul 29 10:53:31 BST 2009
@@ -96,15 +96,16 @@
this.zoomLevel = z;
int shift = getShift();
+ int mask = getMask();
this.latitude = (area.getMinLat() + area.getMaxLat())/2;
this.longitude = (area.getMinLong() + area.getMaxLong())/2;
- int w = (area.getWidth() + (1<> shift;
+ int w = (area.getWidth()/2 + mask) >> shift;
if (w > 0x7fff)
w = 0x7fff;
- int h = (area.getHeight() + (1 << shift)) / 2 >> shift;
+ int h = (area.getHeight()/2 + mask) >> shift;
if (h > 0x)
h = 0x;
@@ -167,6 +168,16 @@
}
/**
+ * Get the shift mask. The bits that will be lost due to the resolution
+ * shift level.
+ *
+ * @return A bit mask with the lower shift bits set.
+ */
+ public int getMask() {
+ return (1 << getShift()) - 1;
+ }
+
+ /**
* Get the resolution of this division. Resolution goes from 1 to 24
* and the higher the number the more detail there is.
*
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across multiple tiles
Am 29.07.2009 um Uhr haben Sie geschrieben: > 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 Germany and the > Netherlands with a map made with r1065. Used Geofabrik Europe data and > mkgmap-splitter. > > What are the command line options you used? > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1111: Now calls incHighwayCount() for all points in all ways (not just highways).
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 style file, it should not cause any short arcs to be produced. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across multiple tiles
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 Germany and the Netherlands with a map made with r1065. Used Geofabrik Europe data and mkgmap-splitter. What are the command line options you used? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
