[mkgmap-dev] generating custom maps (stylesheet or typ files)
I want to create additional custom maps aside from the regular standard map from the default stylesheets. What I want are maps for cycling/mtb. But I am a bit confused with two options, 1. creating custom styles by editing the default stylesheet, or 2. creating typ files. Can somebody explain the difference of the two options? Advance thanks! -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (almost) duplicated node issue
Wow... things get tough... I've three things to say in a single mail: First: I think the encoding is just a 24 bits rounding of the coordinates. You should know at the first run all the nodes that collapses in the same IMG point. But I understand when you say that is complicated to find all the collapsed nodes in a million nodes map. Well, after encoding you should order the nodes per latitude and then order the nodes with the same latitude per longitude. Then all collapsed nodes are in a row. (quicksort is able to sort a vector "in place" without memory wasting: in C I remember I ordered a vector of 1 million elements in few seconds). Second: But maybe the problem is somewere else, or there is a simpler solution then forcing a collapse of nodes: If the IMG specification accepts 2 (or more) independent nodes with the same coordinates (after encoding), maybe it is the routing info that should be encoded in some "smart" way (to be discovered...) that avoids routing engine hangs, infinite loops or errors. Or it could be just a "simple" mkgmap bug: the routing info of the two close nodes does not relates correctly to the two nodes individually. It looks strange to me the fact that the problem in one point creates routing errors rather far in the map. Like a mis-alignemt of routing info vectors vs. node vectors. Third: I made this further experiment you can reproduce: (1) compiled the osm file I've attached some mail ago: Routing error (2) I moved one node of the 2 almost duplicated 10 meters away, compiled the osm file again: NO ROUTING ERROR since the 2 compiled IMG do contain the same nodes, it should be easy for people who know IMG encoding and routing info encoding to discover the difference between the two IMG and understand what happened (a info vector shift, a missing info, a wrong info). Of course if you have a java debugger environment you can check variables before the IMG is even created (I think it's easier) Hope this help. Ciao, Marco. --- Lun 25/5/09, gyp...@gmx.eu ha scritto: > Da: gyp...@gmx.eu > Oggetto: Re: [mkgmap-dev] (almost) duplicated node issue > A: "Development list for mkgmap" > Data: Lunedì 25 maggio 2009, 22:34 > Just a few thoughts... > > 1. Why not giving a special mark to such nodes which have > been generated by a clipping process? Maybe there is own tag > for this? Then you would know that merging is not > appropriate. > > 2. And... please be careful when merging nodes which are > parts of ways with different layers. These could represent > separate floors of a public lift, e.g. > > 3. Is there special a tag for marking those nodes which > must not be merged although they have the same coordinates? > This tag could be used to prevent automatic merging. > > > > Original-Nachricht > > Datum: Mon, 25 May 2009 21:12:07 +0100 > > Von: Mark Burton > > An: mkgmap-dev@lists.mkgmap.org.uk > > Betreff: Re: [mkgmap-dev] (almost) duplicated node > issue > > > > > Hi Marco, > > > > > I want to say: duplicated nodes and almost > duplicated nodes are map > > errors (expecially if they describe an highway). We do > not know wich was the > > right intention of the mapper (make routing > possible/impossible). > > > > > > I think that the best we can do when mkgmap finds > 2 nodes that encode in > > the same IMG point (so in both cases: duplicated nodes > or > > almost-duplicated nodes) is to collapse the 2 nodes in > one node exacly as JOSM validator > > would do if they were duplicated. > > > > > > Does it sound good? > > > > > > Just my proposal... > > > > I should think that it would be reasonably easy to > merge close nodes > > using a first pass before any ways are processed. > > > > However, tricky issues remain. Like, how do you cope > with the situation > > of a node being generated by the clipping process and > that node is > > within the critical distance of an existing node on > the same way? > > > > Cheers, > > > > Mark > > ___ > > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (almost) duplicated node issue
Just a few thoughts... 1. Why not giving a special mark to such nodes which have been generated by a clipping process? Maybe there is own tag for this? Then you would know that merging is not appropriate. 2. And... please be careful when merging nodes which are parts of ways with different layers. These could represent separate floors of a public lift, e.g. 3. Is there special a tag for marking those nodes which must not be merged although they have the same coordinates? This tag could be used to prevent automatic merging. Original-Nachricht > Datum: Mon, 25 May 2009 21:12:07 +0100 > Von: Mark Burton > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] (almost) duplicated node issue > > Hi Marco, > > > I want to say: duplicated nodes and almost duplicated nodes are map > errors (expecially if they describe an highway). We do not know wich was the > right intention of the mapper (make routing possible/impossible). > > > > I think that the best we can do when mkgmap finds 2 nodes that encode in > the same IMG point (so in both cases: duplicated nodes or > almost-duplicated nodes) is to collapse the 2 nodes in one node exacly as > JOSM validator > would do if they were duplicated. > > > > Does it sound good? > > > > Just my proposal... > > I should think that it would be reasonably easy to merge close nodes > using a first pass before any ways are processed. > > However, tricky issues remain. Like, how do you cope with the situation > of a node being generated by the clipping process and that node is > within the critical distance of an existing node on the same way? > > Cheers, > > Mark > ___ > 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
Re: [mkgmap-dev] (almost) duplicated node issue
Hi Marco, > I want to say: duplicated nodes and almost duplicated nodes are map errors > (expecially if they describe an highway). We do not know wich was the right > intention of the mapper (make routing possible/impossible). > > I think that the best we can do when mkgmap finds 2 nodes that encode in the > same IMG point (so in both cases: duplicated nodes or almost-duplicated > nodes) is to collapse the 2 nodes in one node exacly as JOSM validator would > do if they were duplicated. > > Does it sound good? > > Just my proposal... I should think that it would be reasonably easy to merge close nodes using a first pass before any ways are processed. However, tricky issues remain. Like, how do you cope with the situation of a node being generated by the clipping process and that node is within the critical distance of an existing node on the same way? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
Thanks to you all for the ideas!
Now I see that a lot can be achieved by editing the style file. A lot good
things, and a lot nonsense as well. ;-)
The default style adds a "foot=yes" for cycleways, which should not be assumed
as a default permission, imho. But I'm not sure about this.
Bicycle routing against one-ways
As far as I understand the style rules, I could add this one:
bicycle=opposite { set oneway=no }
Some other rules should be established too:
bicycle=opposite_lane { set oneway=no }
bicycle=opposite_track { set oneway=no }
Having generated a map with this rules, it will be of no use for motor
vehicles, of course. But as my only goal is to optimize a map for bicycles,
that would be no problem so far.
In the long run, this feature should be adapted so that the user can select at
the GPS device whether bicycle routing or motorcar routing is to be used.
Road preferences
There is a key "road_speed" in the style file. I assume that this is meant to
be a means for road preferences.
What speed values are associated with this speed classes? E.g., is road_speed=4
twice as fast as road_speed=2? I ask this because I want to give cycleways a
slight preference against other roads, and this preference should really be
"slight".
Markus
Original-Nachricht
> Datum: Mon, 25 May 2009 19:54:05 +0100
> Von: Mark Burton
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
>
> Hi Marko,
>
> > What would it take to duplicate the way in mkgmap, as highway=cycleway,
> > oneway=-1? This could of course be done relatively easily by
> preprocessing
> > the OSM data before feeding it to mkgmap, but I would consider it an
> ugly
> > workaround.
>
> This has been discussed before but I don't think anyone implemented
> anything. I would be happy to give it a go.
>
> > > Of course, such a map would not be useful for routing vehicles.
> >
> > Nitpicking: I thought that bicycles are human powered vehicles. :-)
>
> Agreed, but you know what I was trying to say!
>
> Cheers,
>
> Mark
> ___
> 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] (almost) duplicated node issue
Well, when a node is duplicated (I think, latitudes and longitudes matches up to the last digit), JOSM validator detects it as a map error and offers the possibility to automatically correct the issue. I think there are two cases: (1) the 2 duplicated nodes are not connected by any arc. Well, if JOSM collapses the two nodes in one, it connects each other arcs that weren't connected before. (2) the 2 duplicated nodes are connected by an arc (a zero length arc). Well, if JOSM collapses the two nodes in one, I guess it just deletes the zero length arc. But if the deleted arc was one way, the deletion makes possible routes that weren't possible before I want to say: duplicated nodes and almost duplicated nodes are map errors (expecially if they describe an highway). We do not know wich was the right intention of the mapper (make routing possible/impossible). I think that the best we can do when mkgmap finds 2 nodes that encode in the same IMG point (so in both cases: duplicated nodes or almost-duplicated nodes) is to collapse the 2 nodes in one node exacly as JOSM validator would do if they were duplicated. Does it sound good? Just my proposal... --- Lun 25/5/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: Re: R: [mkgmap-dev] (almost) duplicated node issue > A: mkgmap-dev@lists.mkgmap.org.uk > Data: Lunedì 25 maggio 2009, 16:26 > > Hi Johann, > > > Would it be an idea to enter a slightly longer > distance for the arc in > > the routing db? > > I tried that, it didn't help. > > > I really dont like such things, as they are only are > just workarounds, > > but it seems the easiest solution until the correct > encoding is known. > > I don't think the issue is the correctness of the encoding, > it's more > to do with the fact that the OSM map can contain nodes that > are closer > together than the Garmin can accept. The thorny issue is > how to munge > the data so that the GPS (or mapsource) doesn't barf but > the map is > still usable (connections not broken, etc.) > > One trivial fix is to delete any way that would otherwise > cause a > problem. That should stop the garminware from barfing but > would not be > ideal from the user's point of view because it would break > the routing. > > Cheers, > > Mark > ___ > 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
Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
Hi Marko, > What would it take to duplicate the way in mkgmap, as highway=cycleway, > oneway=-1? This could of course be done relatively easily by preprocessing > the OSM data before feeding it to mkgmap, but I would consider it an ugly > workaround. This has been discussed before but I don't think anyone implemented anything. I would be happy to give it a go. > > Of course, such a map would not be useful for routing vehicles. > > Nitpicking: I thought that bicycles are human powered vehicles. :-) Agreed, but you know what I was trying to say! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Precision circle
Hi! Johann Gail schrieb: Subtract one of the two :-) I have only a 'problem', when using the testmap or no map at all (i.e. basemap of unit). Btw: Maybe the big circle only occurs when the unit is *off* the testmap. I'm not sure what happens if the actual position is *on* the map. If I use a reasonable map with the default style and the latest revision (or some older) of mkgmap then everything works fine for me. Hm, I am definitely on the map. I use a highly customized style, but no dirty tricks included, only a lot of simple rules. bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] "Unpaved Road"
On Sun, May 24, 2009 at 11:55:21PM +0300, Marko Mäkelä wrote:
> Recently, I mapped some disused roads and the like, including this one:
>
> http://www.openstreetmap.org/browse/way/34929277/history
>
> highway=track
> motor_vehicle=unknown
> surface=sand
> tracktype=grade1
> width=2
>
> The map cursor tooltip of the Garmin Edge 705 calls this way
> "Unpaved Road" in English.
>
> I am using the default style of mkgmap -r1040. It remains to be seen
> if this is related to the "Avoid unpaved roads" routing option, but
> it sure looks promising. Then again, maybe not. This ought to be
> line style 0x0a, which highway=track and highway=unsurfaced map to.
> I will make some experiments later.
Sorry, it looks like a dead end. Apparently, the tooltip "Unpaved Road"
for unnamed lines of type 0x0a has nothing to do with the routing data.
For what it is worth, I used the attached patch in my experiment.
Marko
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 1040)
+++ resources/styles/default/lines (working copy)
@@ -19,8 +19,12 @@ junction=roundabout [0x0c road_class=0 r
#highway=* {name '${name} (${ref})' | '${ref}' | '${name}' }
highway=bridleway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
highway=byway [0x16 road_class=0 road_speed=0 resolution 23]
-highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=1 resolution 23]
-highway=footway {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
+highway=cycleway {add access = no; add bicycle = yes; add foot = yes}
+highway=cycleway & surface=unpaved [0x0a road_class=0 road_speed=1 resolution 23 ]
+highway=cycleway [0x16 road_class=0 road_speed=1 resolution 23]
+highway=footway {add access = no; add foot = yes}
+highway=footway & surface=unpaved [0x0a road_class=0 road_speed=0 resolution 23]
+highway=footway [0x16 road_class=0 road_speed=0 resolution 23]
highway=minor [0x06 road_class=1 road_speed=2 resolution 21]
highway=motorway {add oneway = yes; add bicycle = no; add foot = no } [0x01 road_class=4 road_speed=6 resolution 12]
highway=motorway_link {add oneway = yes; add bicycle = no; add foot = no } [0x09 road_class=4 road_speed=3 resolution 16]
@@ -29,7 +33,9 @@ highway=primary [0x02 road_class=3 road_
highway=primary_link [0x08 road_class=3 road_speed=3 resolution 19]
highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21]
highway=secondary [0x04 road_class=2 road_speed=3 resolution 20]
-highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 20]
+highway=path {add access = no; add bicycle = yes; add foot = yes}
+highway=path & surface=unpaved [0x0a road_class=0 road_speed=0 resolution 20]
+highway=path [0x16 road_class=0 road_speed=0 resolution 20]
highway=service [0x07 road_class=0 road_speed=1 resolution 22]
highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
highway=tertiary [0x05 road_class=1 road_speed=3 resolution 20]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Precision circle
Hi! Marco Certelli schrieb: Just a little bit of info. I made some experiments with a GPS72 with other maps (POI only, not OSM) a couple of years ago. I remember the radius of the circle precision is something like "GPS real-time in-accuracy" + "displayed level map in-accuracy". The map in-accuracy depends on the "garmin" level. If a map shows a level 24 (the most possible "accurate" level), the map precision is 3/4 meters. If the map has only levels up to 23, the precision is 6/8 meters. If the map has a maximum level of 22, precision is 10/15 meters, and so on. Ciao, Marco. P.S. Level 24 means using 24 bits to store coordinates (lat/lon). And so on... Thank you for the hints. My map contains Objects down to Level 24. I am usually at a zoom of 200m or 120m. Maybe it has something to do with the level distribution - but I did not change that recently. bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
On Mon, May 25, 2009 at 05:27:52PM +0100, Mark Burton wrote: > > Hope you can help... because there's a great number of one-way streets > > in my city, which may be used by bike in opposite direction. > > At this time, I believe the only way you can achieve what you want is > to create a map specifically for bicycle navigation that ignores the > oneway=yes if the cycleway=opposite* tag(s) are set. This would involve > writing some rules for the style file. I am sure that the style file > gurus on the mailing list will suggest something appropriate. What would it take to duplicate the way in mkgmap, as highway=cycleway, oneway=-1? This could of course be done relatively easily by preprocessing the OSM data before feeding it to mkgmap, but I would consider it an ugly workaround. > Of course, such a map would not be useful for routing vehicles. Nitpicking: I thought that bicycles are human powered vehicles. :-) BTW, are there any non-OSM Garmin maps that feature routeable cycleways? Such a map could be useful for reverse engineering. (I have only used OSM on my Edge 705, and I read that a commercial map of Finland lacks routing data for cycleways, even though some ways are visible on the screen.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
Hi Markus, > Hi - I'm new on this mailing list an try to understand what's going on... :-) > > One observation regarding bicycle routing: > The tag combination > > oneway=yes > cycleway=opposite_lane > > seems not to work correctly. I.e., routing suggests a detour because it does > not consider that you could use the one-way street in opposite direction. > > This applies to the tags "cycleway=opposite_track" and "cycleway=opposite" as > well. > > Is there a solution for this problem? Is, in this case, Garmin routing > software able to distinguish between car routing and bicycle routing at all? > > Hope you can help... because there's a great number of one-way streets in my > city, which may be used by bike in opposite direction. At this time, I believe the only way you can achieve what you want is to create a map specifically for bicycle navigation that ignores the oneway=yes if the cycleway=opposite* tag(s) are set. This would involve writing some rules for the style file. I am sure that the style file gurus on the mailing list will suggest something appropriate. Of course, such a map would not be useful for routing vehicles. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bicycle routing, cycleway=opposite
Hi - I'm new on this mailing list an try to understand what's going on... :-) One observation regarding bicycle routing: The tag combination oneway=yes cycleway=opposite_lane seems not to work correctly. I.e., routing suggests a detour because it does not consider that you could use the one-way street in opposite direction. This applies to the tags "cycleway=opposite_track" and "cycleway=opposite" as well. Is there a solution for this problem? Is, in this case, Garmin routing software able to distinguish between car routing and bicycle routing at all? Hope you can help... because there's a great number of one-way streets in my city, which may be used by bike in opposite direction. Regards, Markus ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] (almost) duplicated node issue
Hi Johann, > Would it be an idea to enter a slightly longer distance for the arc in > the routing db? I tried that, it didn't help. > I really dont like such things, as they are only are just workarounds, > but it seems the easiest solution until the correct encoding is known. I don't think the issue is the correctness of the encoding, it's more to do with the fact that the OSM map can contain nodes that are closer together than the Garmin can accept. The thorny issue is how to munge the data so that the GPS (or mapsource) doesn't barf but the map is still usable (connections not broken, etc.) One trivial fix is to delete any way that would otherwise cause a problem. That should stop the garminware from barfing but would not be ideal from the user's point of view because it would break the routing. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] (almost) duplicated node issue
I know about IMG resolution, Mark. That is the reason I think there is a bug. If the Garmin cannot handle such short arcs, mkgmap shall compile the case in a way that does not violate the garmin specs. It would be nice if mkgmap could work around the problem of short arcs so I am looking into what it needs to do to achieve that. Unfortunately, it's not an easy problem to solve so it will take a little thought. Would it be an idea to enter a slightly longer distance for the arc in the routing db? I really dont like such things, as they are only are just workarounds, but it seems the easiest solution until the correct encoding is known. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Precision circle
Ok, so we have 2 with the problem, one without. Let's try to figure out the difference. Subtract one of the two :-) I have only a 'problem', when using the testmap or no map at all (i.e. basemap of unit). Btw: Maybe the big circle only occurs when the unit is *off* the testmap. I'm not sure what happens if the actual position is *on* the map. If I use a reasonable map with the default style and the latest revision (or some older) of mkgmap then everything works fine for me. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] (almost) duplicated node issue
Hi Marco, > I know about IMG resolution, Mark. That is the reason I think there is a bug. > If the Garmin cannot handle such short arcs, mkgmap shall compile the case in > a way that does not violate the garmin specs. It would be nice if mkgmap could work around the problem of short arcs so I am looking into what it needs to do to achieve that. Unfortunately, it's not an easy problem to solve so it will take a little thought. > But I'm not really sure that the problem is exactly this. It might be that > mkgmap has a bug in the routing data base compiling. Well I'm not expert, but > I guess something goes wrong when the 2 so close nodes collapses in a single > node when the garmin encoding is applied. Then 2 nodes in OSM, 1 node in > Garmin... and the routing DB gets corrupted. Something like that (but I'm > really speculating). The nodes are separate, just too close together. > Someone should check the code to track the situation. The osm file I've > attached (that reproduce the error) is small enough to be tested carefully. Thanks for the sample. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Precision circle
Just a little bit of info. I made some experiments with a GPS72 with other maps (POI only, not OSM) a couple of years ago. I remember the radius of the circle precision is something like "GPS real-time in-accuracy" + "displayed level map in-accuracy". The map in-accuracy depends on the "garmin" level. If a map shows a level 24 (the most possible "accurate" level), the map precision is 3/4 meters. If the map has only levels up to 23, the precision is 6/8 meters. If the map has a maximum level of 22, precision is 10/15 meters, and so on. Ciao, Marco. P.S. Level 24 means using 24 bits to store coordinates (lat/lon). And so on... --- Lun 25/5/09, Felix Hartmann ha scritto: > Da: Felix Hartmann > Oggetto: Re: [mkgmap-dev] Precision circle > A: "Development list for mkgmap" > Data: Lunedì 25 maggio 2009, 08:48 > For me on Vista HCx it's working as > well. Once position is accurate, precision circle is very > small. > > Nop wrote: > > > > Hi! > > > > Ralf Kleineisel schrieb: > >> Nop wrote: > >> > >>> The discussion over at the GPS forum points > towards a setting inside the > >>> map, too. It seems mkgmap marks the maps as > terribly inaccurate so the > >>> maximum precision is an inaccuracy of 260m. > >> > >> With my maps generated with mkgmap my eTrex Legend > HCx shows the circle > >> correctly, i.e. it disappears when the GPS > position precision is good enough. > > > > Ok, so we have 2 with the problem, one without. Let's > try to figure out the difference. > > > > Does anybody have any idea where in the map this > setting is stored? > > > > bye > > Nop > > ___ > > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
